2. Background
§ Director of Technology @ Kaazing
§ Chairman NYJavaSIG (javasig.com)
§ Largest JUG in North America
8,000+ members
§ Financial Services, Architecture, Cloud
§ frank.greco@kaazing.com, @frankgreco
3. A Primary Tenet of Computing
History
History
If History Repeats Itself, Is There No Future?
6. Web – “over the firewall” (early 90’s – 2011)
http tcp
web server
and/or
app server
app protocols
Not efficient or effective for event-based systems…
7. But Modern Applications are Dynamic and Event-based
FX trading
Monitoring
Stock trading Utilities trading
XaaS
Logistics Notification Compliance
Betting & bidding
Voting In-store & online Collaboration
8. Legacy Web
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…
9. WebSocket – “TCP for the 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
11. For Event-based Web Communication…
Legacy HTTP vs WebSocket
http:// ws://
u Application-level Socket over the Web
u Supported by all Modern Browsers
u Event-based Applications
13. W3C WebSocket JavaScript API
HTML5 WebSocket API
But…
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?
14. What is Missing?
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?
15. Browser and Native Applications
JMS XMPP AMQP B2B FTP VNC MQTT etc
WebSocket
TCP/IP
Internet
WebSocket
Gateway
WebSocket
Gateway
Protocol Layering is Possible
WebSocket is a
Transport layer
16. Simplicity is a
Useful
Abstraction!
Simplicity enables
Innovation
Complexity
Innovation
Higher Level APIs Reduce Complexity
17. Higher Level APIs (over WebSocket) for JavaScript
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”
19. Java Message Service (JMS)
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
20. Basic 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
21. JMS Over the Web (JavaScript)
Browser app - 100 msg/sec
over port 80/443
22. What WebSocket is Not
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
25. The World is Naturally Event-based (“real-time”)
Presentation Music
Communication
Logistics
Big
Data
Risk
Management
Home
Security
Health
Monitoring
Intelligent
Appliances
Local
Transportation
Monitoring/
Management
Remote
control
26.
27. Let’s Take 1 Step Back to go 2 Steps Ahead…
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
28. The Web
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)
29. The Hidden Web – Most of the Web is Not Visible
browsers
APIs
http://thumbs.dreamstime.com/x/iceberg-23503494.jpg
30. Now… IoT, IIoT and M2M
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
31. IoT/IIoT – Connectivity isn’t Sufficient
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
32. u IoT – Internet of Things
• Embedded computing endowed with Internet connectivity
u WoT – Web of Things
• Application and Services layer over IoT
Developers!
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
Here’s Where the Web Comes In
33. But Is HTTP the Right Choice?
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
34. History Repeats Itself…
RPC
Asynchronous
RPC
Messaging
REST
Asynchronous
REST
Messaging
ESB ISB?
Enterprise Web/WoT
• 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?...
35. The Message is the Medium
“…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
36. Typically an App
Server and DB
App Server is
probably not the
right
architecture
Data Flow – Human Web vs WoT
Human
Web
WoT
Large data to client
Small data to server
Do human-readable protocols make sense for non-humans?