api design and websocket

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… }



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