websockets in enterprise applications

WebSocket in Enterprise apps

Pavel Bucek ([email protected]) Oracle September 30, 2014

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |


Safe Harbor Statement The following is intended to outline our general product direcPon. It is intended for informaPon purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or funcPonality, and should not be relied upon in making purchasing decisions. The development, release, and Pming of any features or funcPonality described for Oracle’s products remains at the sole discrePon of Oracle.


Program Agenda

What is WebSocket

When to use WebSocket

Security (AuthenPcaPon, SSL, …), browser support, usability

Code paUerns

Advanced topics (monitoring, tracing, clustering, …)

1

2

3

4

5


WebSocket protocol

• RFC 6455 (December 2011) •  Two way communicaPon protocol, replacement for Long-‐polling – BeUer resource uPlizaPon

• Based on the HTTP/1.1 Upgrade mechanism – IniPal (WebSocket) handshake uses HTTP •  Includes extensions and Sub protocol negoPaPon

– Everything else is then encapsulated in WebSocket frames – ConnecPon/communicaPon can be closed using WebSocket or just by closing underlying TCP connecPon (will be detected as 1006 -‐ CLOSED_ABNORMALLY)


When NOT to use WebSocket

• Non-‐interacPve applicaPons •  Single direcPonal communicaPon (client just waits/reads data from the server) – SSE – Server sent events

•  Forms based applicaPons • High throughput (*) – Video streaming can be implemented on top of WebSocket, but there are much beUer protocols for this purpose


When you should consider using WebSocket

• ApplicaPon needs to communicate with the server – Bi-‐direcPonal communicaPon (not just polling!)

•  InteracPvity •  Time criPcal data delivery – Once connecPons is established, the message overhead is quite low

• High throughput (*) – Video streaming can be implemented on top of WebSocket, but there are much beUer protocols for this purpose


WebSocket usecases • Chat-‐like applicaPons – Various implementaPons opPons – XMPP (Jabber) over WebSocket

•  Trading and transacPons – Fast feedback/execuPon

• Real-‐Pme monitoring – Depends on the data source – InteracPon with monitored object – (SSE?)

• Remote control – Input with “real-‐Pme” feedback – From industry applicaPon to fun apps

• Games – HTML5 “naPve” transport – Supported by improvements in browsers 2D/3D canvas support

• General collaboraPon – Customer service, Social apps, …


WebSocket API – Security

•  Server side – Standard servlet/container mechanism for securing web services – Container-‐related configuraPon, not all of those relevant for websockets (depends) – Origin check

• Client side – Java – Official API does not provide much in terms of AuthenPcaPon or other related sepngs support – Not only about AuthenPcaPon; SSL sepngs (TrustStore, KeyStore, HostnameVerifier) – Proxy authenPcaPon


WebSocket API – Security

• Client side – Browsers – Client can connect only to the same host/port from which was the “staPc” page opened – SpecificaPon is very vague and does not really touch this subject – Passing properPes of current HTML page to WebSocket connecPons seem to be not as common as it could be •  Using SSL client cerPficates •  Passing credenPals (BASIC, DIGEST) to the WebSocket connecPon •  Adding Cookies to headers of handshake response

– Current browser API cannot influence or intercept request/response headers


WebSocket API – Usability

• All modern browsers do support websocket – Including mobile devices (Android, iOS) – There are available soluPons for older browsers •  Fallback transport/containers •  Flash WebSocket client •  Vendor proprietary soluPons – WebSocket over Long-‐Polling etc.

• HTTP Proxy is not an issue, same for firewalls


Java API for WebSocket

•  JSR 356 – Part of Java EE 7 – 1.0 (May 2013) – 1.1 (August 2014)

• Annotated and programmaPc way how to deploy and access WebSocket endpoints •  Event-‐driven model -‐ @OnOpen, @OnMessage, @OnError, @OnClose •  Encoders/Decoders, Path/Query parameter handling, Handshake headers interceptors, CDI integraPon, …


Java API for WebSocket – Annotated Endpoint


Java API for WebSocket – ProgrammaPc Endpoint



• Different threading model compared to “standard” Servlet •  Javax.webscoket.Session is thread-‐safe. •  Each method might be invoked from different thread – There is no guarantee that @OnMessage will be always called from the same thread – InvocaPons will be made in message order and next @OnMessage won’t be called unless previous execuPon ended – ImplicaPons: • Method implementaPons must be thread safe. •  Double check the resources you are accessing from Endpoint implementaPons

Concurrency/Threading



• Reference ImplementaPon for JSR 356 • WebSocket implementaPon of Oracle WebLogic Server and Glassfish • Current version is 1.8.3 • hUps://tyrus.java.net • Highlighted features: – Client improvements (SSL, Auth, Proxies, Reconnect, …), OpPmized broadcast, Tracing, Monitoring, Clustering (*), …

Project Tyrus


Tyrus – Client improvements

• Client distributed as part of the applicaPon server or as a standalone bundle – convenient for standalone app use – Grizzly based container (JDK 1.6+) – Java 7 NIO based container (JDK 1.7+)

• Client properPes – AuthenPcaPon – BASIC/DIGEST/custom – SSL – TrustStore, KeyStore, HostnameVerifier – Proxy support – Reconnect Handler, …


Tyrus – Broadcast

• WebSocket API provides single way how to perform broadcast

•  Don’t •  Call session.isOpen() •  Throw excepPon from method or try-‐catch whole iteraPon

•  Do •  getAsyncRemote()


Tyrus – Broadcast

•  Tyrus provides single method

•  Proprietary •  No Encoders •  No need to compose new frame for each session/client.

•  Parallel (*) •  Cluster-‐ready (*)


Tyrus – Monitoring

•  Tyrus provides SPI for monitoring events – (up to session level)

•  Tyrus contains implementaPon which exposes these staPsPcs as JMX Beans • Also included in Oracle WebLogic Server • Monitored data – Sent/received messages per session (*)/endpoint/applicaPon – Message types (text/binary/control)


Tyrus – Tracing

•  Feature which allows per-‐request diagnosPcs • Useful when developing an applicaPon – Logged messages related to runPme processing – Handshake request/response – Endpoint path matching process – Encoders/Decoders, MessageHandlers


Tyrus – Clustering

•  JSR 356 does not say much about deploying applicaPons to the cluster – (There is only small noPon in Session#getUserProperPes() javadoc)

• Currently, applicaPon will behave the same way as it would be deployed to single node. – Issues with Session.getOpenSessions() and javax.websocket.Session

• Custom API required to make this work – RemoteSession – Distributed properPes


Tyrus – Clustering – Coherence

• Message based architecture with persisted state(s) – JMS does not offer to store state + harder to setup

• Coherence Cluster used as backing framework – Several NamedCaches •  Endpoints, Sessions, Messages, Broadcast, DistributedProperPes

– Scopes of the coherence values are limited by Coherence ContainerAdapter •  One scope per applicaPon per parPPon (MT)

– Each distributed operaPon can be mapped to Map.put() + corresponding listener


Tyrus – Clustering – Coherence Sending a message

Coherence Cluster

sendText()

m = new Message(…) msgCache.addListener(m.getId()) sessionCache.put(sessionId, m)

Node 2 Node 1

RemoteSession.sendText [session created] sessionCache.registerListener(…);

sessionCache.noPfy() getLocalSession(sessionId); r = localSession.sendText(m.getM()); msgCache.put(m.getId, r); msgCache.noPfy()


Tyrus – Clustering – HA

• CreaPng new Session on the server might be expensive (allocaPng resources, registraPons, gepng id(s) from database, …) •  Session cannot be persisted as a whole, since the underlying TCP connecPon will be broken and this is recognized by WebSocket protocol and MUST BE interpreted as Close with 1006: CLOSED_ABNORMALLY – We can persist part of the session – distributed properPes

• When client connects to the cluster, it will be given an ID and if this will be re-‐send when client wants to reconnect (“persistent connecPon”), server implementaPon will set distributed properPes from the lost session


Tyrus – Clustering – HA

– Client will receive tyrus-‐cluster-‐connecPon-‐id, will store it and add as a header when reconnecPng – Server: @OnOpen •  IniPalize resources and save properPes to distributed properPes (TyrusSession#getDistributedProperPes())

– Server: @On* •  Distributed properPes can be used. Please be aware that every read/write performs de/serializaPon.

– When connecPon is broken, Session is closed. Client reconnects with added header. – Server: @OnOpen •  Check whether distributed properPes already contain properPes. If not, reiniPalize, otherwise use them (meaning that this is reconnected session).


Tyrus – Clustering – Coherence

Client

Handshake request

Cluster Node 1 Node 2

Handshake response + cluster conn. ID

messages

Close (1006)

Handshake request + cluster conn. ID

Handshake response

messages

@OnOpen Distributed properPes

Are restored

TCP conn

ecPo

n #1

TCP conn

ecPo

n #2



•  SPI is part of project Tyrus, implementaPon should be available in the next Oracle WebLogic Server release – Built on top of Coherence

• Demo – Rumpetroll – hUp://rumpetroll.com


WebSocket.NEXT – QuesPons?

• WebSocket API 1.1.NEXT • WebSocket-‐spec: hUps://java.net/projects/websocket-‐spec – hUps://java.net/jira/browse/WEBSOCKET_SPEC

• Reference ImplementaPon: Tyrus hUps://tyrus.java.net – [email protected] – hUps://java.net/jira/browse/TYRUS

• Pavel Bucek: [email protected]

websockets in enterprise applications

Technology