Remoting Retrospective: DCE, COM, CORBA, RMI, RMI/IIOP, SOAP, REST, WebSockets
Use-cases
SOAP
- enterprise
- service description
- static typing
- end-to-end security
- third-party authentication
- interoperability
REST
- public APIs
- small footprint
- loose-coupling
- interoperability
WebSockets
- browsers as universal clients for event oriented apps (full duplex low latency)
- multiplayer games, chat, live tickers (e.g., sport/stock), social streams
- service push; pub/sub
- alternative to AJAX, Comet, long polling, HTML5/SSE, …
- async, frame-oriented and state-oriented app protocols layered on top
- e.g. AMQP, XMPP, JMS, STOMP, VNC (RFB),
- private subprotocols (e.g., small, binary)
- potential performance improvement
- tight-coupling
Timeline details
- HTTP
- strict request-response model
- client sends request, waits until response received
- AJAX/XMLHttpRequest
- pulls data "requests" from server
- XMLHttpRequest just does HTTP request in background (no UI blockage) with callback handling response
- polling: apps periodically do AJAX request to ask if server has an "event"
- event latency depends on polling period
- can increase polling rate
- but wastes resources and scales poorly (most polls return empty)
- COMET/LONG-POLLING ("reverse AJAX")
- client does request; service maintains connection
- fakes notifications by sending "event"/response when ready
- then client send request again, and wait for next event
- always a pending request
- HTTP STREAMING
- service keeps response message open
- response body never closed after sending event
- new events written to same stream
- response message body represents a unidirectional event stream to the client
- requires proxies to forward "partial" responses
- HTML5 SERVER-SENT EVENTS (SSE)
- standardizes COMET
- client API to open HTTP conn for receiving push notification
EventSource represents client endpoint to receive events
- mime
text/event-stream for event framing format
EventSource impl can do connection management to share connections
- period reconnections under the covers
- service should send periodic "keep-alive" comments
- to avoid proxies killing the connection
- WebSockets
- server can send info to client anytime: update latency reduced
- server handles fewer connection requests
- some requests transformed into updates to WebSockets
- but then connection management
- client heartbeats be required so server can cleanup dead connections
- service heartbeat not required
- service pushes shows it is alive
- but might need to reset connection if no updates
- support WebSockets but fall back to HTTP Streaming and HTTP Long Polling dynamically
- no connection reliability
- no reconnect handling
- no guaranteed message delivery (like Server-Sent Event does)
- reliability has to be in app (same as "keep alive" message in SSE)
- sharing WebSocket between different pages must lock writes/reads
- no same origin policy limitation
- enabling siloed apps
SOAP/WebSocket potential benefits
- can tunnel out of a firewall
- use instead of WS-MakeConnection
- connection-based
- use instead of WS-ReliableMessaging
- multi-message communication
REST/WebSockets potential benefits
- multi-message communication
- existing apps use REST/WebSockets lib
- reduced overhead of single connection without refactoring code
- Transactional-REST
- beginTransaction; REST/WebSocket calls, … ; endTransaction;
- if connection drops before commit then rollback TX
Ref:
https://weblogs.java.net/blog/haroldcarr/archive/2012/10/02/soap-andor-rest-andor-websockets
EventSource represents client endpoint to receive eventstext/event-stream for event framing formatEventSource impl can do connection management to share connections
Software that does not work. Software that does the wrong thing. Money paid to set up an offshore team that never produces any software. Can these outsourcing nightmares be avoided?