API Design and WebSocket WoT Next?
@frankgreco
Background
§ Director of Technology @ Kaazing § Chairman NYJavaSIG (javasig.com) § Largest JUG in North America
8,000+ members § Financial Services, Architecture, Cloud § [email protected], @frankgreco
History
History
A Primary Tenet of Computing
If History Repeats Itself, Is There No Future?
A Trip Down Memory Lane…
In the beginning…
Client-Server
tcp
Enterprise – “inside the firewall” (1980’s – early 90’s)
tcp http
web server and/or
app server
app protocols
Not efficient or effective for event-based systems…
Web – “over the firewall” (early 90’s – 2011)
FX trading
Monitoring
Stock trading Utilities trading
XaaS
Logistics Notification Compliance
Betting & bidding
Voting In-store & online Collaboration
But Modern Applications are Dynamic and Event-based
u Designed for document transfer – HTTP
ü Short-lived Request / Response interaction
u Bidirectional, but half-duplex
ü Traffic flows in only one direction at a time
u Stateless
ü Large amounts of metadata resent for each request
The Web was not originally designed for “real-time”, event-based services…
Legacy Web
u IETF Protocol and W3C JavaScript API for real-time, bi-directional, always-on connections
u RFC 6455 – Dec 2011
u Easily add event-based data to web apps ü ws://mycompany.com/collaboration_svc
ü wss://anothercompany.com/marketdata
u Avoids polling
u Avoids HTTP meta-data overhead
u Shares port with HTTP (80/443)
u Traverses Firewalls
WebSocket – “TCP for the Web”
The WebSocket Handshake
Legacy HTTP vs WebSocket
http:// ws://
u Application-level Socket over the Web u Supported by all Modern Browsers u Event-based Applications
For Event-based Web Communication…
W3C WebSocket JavaScript API
HTML5 WebSocket API
Dealing with WebSocket is like dealing with TCP. It’s a streams-based model. You need to understand how to handle streams-based data over the wire. e.g., How do I do publish/subscribe?
But…
W3C WebSocket JavaScript API
Where is the Application-level Protocol?
Who handles retries?
How do we handle publish/subscribe semantics?
How do we handle market data?
How can we guarantee delivery?
What do we do with slow consumers, last value cache, etc?
What if the client is not currently active?
What about partial data? How do I handle
entitlements? ACL?
What is Missing?
WebSocket
TCP/IP
JMS XMPP AMQP B2B FTP VNC MQTT etc
Browser and Native Applications
WebSocket Gateway
Internet
WebSocket Gateway
Protocol Layering is Possible
WebSocket is a Transport layer
Simplicity is a Useful
Abstraction!
Simplicity enables Innovation
Complexity
Innovation
Higher Level APIs Reduce Complexity
So if you can layer application protocols and APIs over WebSocket, what do you have? u Easier WebSocket programmability u Event-driven applications over the web u Event-driven APIs over the web u Not necessary to open non-standard ports u Web infrastructure now truly “disappears” u Reduction in complexity u Further opportunities to innovate u Mobile + cloud + HTML5/WebSocket u Internet of Things -> Web of Things u “Imagination is Everything”
Higher Level APIs (over WebSocket) for JavaScript
Publish/Subscribe
Java Message Service (JMS) over
WebSocket
For Example…
u Java EE Message Oriented Middleware
u JMS 1.0 2001, JMS 1.1 2002, JMS 2.0 2013
u Asynchronous Messaging vs. RPC
u Loosely coupled vs. Tightly coupled
u Pub/Sub, Topics, Queues
u Transactions, Reliable
Java Message Service (JMS)
conn = createConnection(); sess = conn.createSession(); topic = jndiContext.lookup(topic); pub = sess.createProducer(topic); pub.send(“hey Frank”);
conn = createConnection(); sess = conn.createSession(); topic = jndiContext.lookup(topic); sub = sess.createConsumer(topic); sub.setMessageListener(this); … public void onMessage(Message m) { String s = m.getText(); … do stuff… }
conn = createConnection(); sess = conn.createSession(); topic = jndiContext.lookup(topic); sub = sess.createConsumer(topic); sub.setMessageListener(this); … public void onMessage(Message m) { String s = m.getText(); … do stuff… }
conn = createConnection(); sess = conn.createSession(); topic = jndiContext.lookup(topic); sub = sess.createConsumer(topic); sub.setMessageListener(this); … public void onMessage(Message m) { String s = m.getText(); … do stuff… }
msg broker
Basic JMS
JMS Over the Web (JavaScript)
Browser app - 100 msg/sec over port 80/443
u It is not a New AJAX AJAX was a lovable hack
u It is not a Push mechanism WebSocket is full-duplex, bi-directional
u It is not a Messaging system It’s an agnostic wire protocol It’s a low-level transport API
u It is not a Replacement for HTTP HTTP is still great for static, cacheable info
What WebSocket is Not
What’s next for WebSocket?
Internet of Things (IoT) +
Heterogeneity + Scale + Usability
Futures
Communication
Presentation Music Logistics
Big Data
Risk Management
Home Security
Health Monitoring
Intelligent Appliances
Local Transportation
Monitoring/Management
Remote control
The World is Naturally Event-based (“real-time”)
u Internet – Global system of interconnected networks that use IP to communicate
u Internetworking – Connecting one network with another through a series of Gateways that provide a common method of communication
Let’s Take 1 Step Back to go 2 Steps Ahead…
u A popular application service on the Internet
u Based on TCP/IP
u Advantages
§ Application deployment simplified – URI
§ Interoperable open standards and specifications
§ Ease of programmability – scripting
§ Global reach and Economy of scale
§ Accessed by ubiquitous Browsers and also non-Browsers
u Two major protocols
HTTP (1988/1999) and WebSocket (2007/2011)
The Web
The Hidden Web – Most of the Web is Not Visible
http://thumbs.dreamstime.com/x/iceberg-23503494.jpg
browsers
APIs
u A riff on “Ubiquitous Computing” (“Pervasive”)
• Mark Weisner PARC 1988
u Its early so there’s different definitions
• Similar to early days of Cloud Computing
u M2M has been around for decades.
• Primarily proprietary embedded systems and typically point-to-point (RPC)
u IoT/IIoT (Industrial IoT)
• Adds Internet connectivity
• Networks of M2M systems connected via IP
Now… IoT, IIoT and M2M
u No formal API standards
u Many protocol standards – interoperability low
u No common, wide-reaching frameworks
u No composition possibilities
u Difficult to leverage economies of scale
u Barrier to entry is high for millions of app developers
u Also… we’re in a cloud, mobile, web api world
IoT/IIoT – Connectivity isn’t Sufficient
u IoT – Internet of Things • Embedded computing endowed with Internet connectivity
u WoT – Web of Things • Application and Services layer over IoT
u Apply the benefits of the Web to IoT
u WoT is a uniform interface to access IoT functionality u Provides the abstraction for control/monitoring (sensors/
actuators) u Accelerates innovation u Deployment, development, interoperability, economy of
scale…
IoT
WoT
Developers!
Here’s Where the Web Comes In
u Disadvantages of HTTP Request/Response u Lack of resiliency and robustness u Enterprise events retrieved by resource intensive polling
techniques • Much bandwidth is wasted • Information can be delayed
u Composite services brittle and lack transactionality u Enterprises learned advantages of ESB 10+ years ago u See failures of CORBA, Sun RPC, etc. u Clumsy AJAX/Comet workarounds to simulate real-time
But Is HTTP the Right Choice?
RPC
Asynchronous RPC
Messaging
Enterprise Web/WoT
REST
Asynchronous REST
Messaging
• Can wait for response • Tight coupling • Centralized business
processes • Vertical interaction • Easy to understand (xact)
• Future response • Loose coupling • Independent business
processes • More complexity (xact)
Did I mention History repeats itself?...
ESB ISB?
History Repeats Itself…
“…terse, self-classified messages, networking overhead isolated to a specialized tier of devices, and publish/subscribe relationships are the only way to fully distill the power of the coming Internet of Things” – Francis daCosta
The Message is the Medium
Typically an App Server and DB
App Server is probably not the
right architecture
Human Web
WoT
Large data to client
Small data to server
Data Flow – Human Web vs WoT
Do human-readable protocols make sense for non-humans?
GW
GW
GW
IoT/IIoT
WoT
WoT
WoT
Event Gateway Architecture
GW
GW
GW
GW
GW
GW
GW
Aggregator nodes
• Scalability • Querying • Performance • Manageability • Composition • Circles of Trust • Event processing • CDN++
Event Gateway Architecture – Future Directions
Click to Edit Master Title Style
Demos
Thank You!
@frankgreco