Giao thức giao tiếp client - server

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