Sequence chart script provided by http://www.websequencediagrams.com

Architectural Overview

This page describes architectural approaches to support of connectionless Push for HTML5's Server-Sent Events API. It covers approaches possible today using standardized protocols, e.g. OMA Push as is currently widely deployed and supported on most mobile phones.

Connectionless Push refers to the delivery of server-initiated events without an established user-plane IP bearer, by leveraging signaling networks as the bearer, e.g. in the current examples:

• the GSM Short Message Service (SMS): as a bearer, SMS supports delivery of application data through use of registered SMS ports, various data coding schemes (e.g. enabling delivery of compressed content), and message segmentation. For example, these capabilities are used by the OMA Push Over-the-Air Protocol to support SMS-based delivery of OMA-standardized content types e.g. Service Indication and Service Load, which can reliably be used to deliver up to 1000-byte URLs with optional text for presentation to users.
• SIP e.g. in a 3GPP IMS network or other SIP-enabled network: For example, OMA SIP Push can be used to deliver up to 1300 bytes of compressed content in SIP MESSAGE, or essentially unlimited sized content via using SIP INVITE to establish a user-plane connection over which MSRP is used to deliver the content.

The following named entities are referred to:

• A client application, which is an application running on a device as a web application executing in browser or widget context, or other web-enabled application.
• A Push Client, which is either the application user agent (e.g. browser, widget engine, or other application engine), the application itself, or another device software entity that exposes a Push event interface to the others (user agent or application). The Push Client is assumed to have these capabilities:
  • Supporting the Server-Sent Events API.
  • Supporting connectionless event delivery, e.g. via OMA Push/SMS or Push/SIP. For example, basic requirements of OMA Push/SMS include the ability to registered with the device OS service that handles incoming SMS events, as a listener for incoming SMS events on the standardized WAP Push/SMS ports (2948 or 2949), and ability to decode binary (WBXML) Push messages prior to delivery to the client application. New requirements supporting delivery of Server-Sent Events via WAP Push include handling the text/event-stream content type, e.g. delivery to the client application using the eventsource API.
• A Push Server, which has connectionless Push ability. The Push Server may have further context-aware bearer/protocol selection capabilities, e.g. supporting the OMA Push Proxy Gateway (PPG) service, with enhancements to support Server-Sent Events requirements.
• A server application, which is an application running on a web server, supporting HTML5 Server-Sent Events, and optionally the OMA Push Access Protocol (PAP). If acting directly as a Push Server, the server application (or its supporting framework) supports one or more connectionless Push protocols that are also supported by the Push Client.
• Signaling network entities as applicable, e.g. GSM Short Message Service Center (SMSC), or SIP/IP Core network (e.g. a 3GPP IMS)

Server-Sent Events Basic Operation

Taking the example in Server-Sent Events as a base, an event stream as below, followed by a blank line:

	data: YHOO
	data: +2
	data: 10

...would cause an event message with the interface MessageEvent to be dispatched on the EventSource object. The event's data attribute would contain the string YHOO\n+2\n10 (where \n represents a newline). This could be used as follows:

		
	var stocks = new EventSource("http://stocks.example.com/ticker.php");
	stocks.onmessage = function (event) {
		var data = event.data.split('\n');
		updateStocks(data[0], data[1], data[2]);
	};
	function updateStocks(symbol, delta, value) { ... }

participant "Server\nApplication" as SA
participant "User Agent" as UA
participant "Client\nApplication" as CA

CA->UA: 1) Call EventSource(url)
UA->SA: 2) Open connection
SA->UA: 3) Deliver event stream\ndata: YHOO\ndata: +2\ndata: 10\n(blank line)
UA->CA: 4) Deliver event stream\n through onmessage method\n(YHOO 2 10) 
CA->UA: 5) Call close() on\nEventSource object
UA->SA: 6) Close connection

Server-Sent Events Fallback to Connectionless Delivery over WAP Push/SMS

This example shows use of a Push Server which is not involved in server-sent event delivery until needed, to deliver connectionless events. In this example:

• The server application (or a framework on which the application depends) must explicitly use the Push Server for events to be delivered outside of an established eventsource connection. Various standardized and non-standard API's can be used to invoke event delivery via the Push Server, e.g. the OMA Push Access Protocol (PAP) or other API which exposes the same service.
• The client application is aware that connectionless delivery is an option, and has a way of opening the eventsource for connectionless-only delivery.

participant "Server\nApplication" as SA
participant "Push Server" as PS
participant "Short Message\nService Center" as SMSC
participant "User Agent" as UA
participant "Client\nApplication" as CA

CA->UA: 1) Call EventSource\n(Server Application url)
UA->SA: 2) Open connection
SA->UA: 3) Deliver event stream
UA->CA: 4) Deliver event stream\nas it is received
CA->UA: 5) Call close() on\nEventSource object
UA->SA: 6) Close connection
CA->UA: 7) Call EventSource\n(connectionless)
note over SA
 A new event stream is 
 ready for delivery.
end note
SA->PS: 8) PAP:Push_Message\n(event stream)
PS->SMSC: 9) SMPP:SM_SUBMIT\n(event stream\nin Push-OTA message)
SMSC->UA: 10) Deliver SMS\n(event stream\nin Push-OTA message)
UA->CA: 11) Deliver event stream

Server-Sent Events Access via Push Proxy with Fallback to Connectionless Delivery over WAP Push/SMS

This example shows use of a Push Server which acts as a proxy (either transparently, explictly, or through URL aliasing) and has context-aware bearer/protocol selection capabilities (ala an OMA Push Proxy Gateway). In this example:

• The server application can be unaware that the Push Server is in the path.
• The client application is aware that connectionless delivery is an option, and has a way of opening the eventsource for connectionless-only delivery.
• The Push Server is configured (e.g. via a eventsource URL parameter, or by service provisioning) to retain the connection to the server application when the connection to the user agent is closed. It is assumed that the server application will close the connection to the Push Server when the connection is no longer needed.

participant "Server\nApplication" as SA
participant "Push Server" as PS
participant "Short Message\nService Center" as SMSC
participant "User Agent" as UA
participant "Client\nApplication" as CA

CA->UA: 1) Call EventSource\n(Push Service url)
UA->PS: 2) Open connection (as proxy)
PS->SA: 3) Open connection
SA->PS: 4) Deliver event stream
PS->UA: 5) Deliver event stream
UA->CA: 6) Deliver event stream\nas it is received
CA->UA: 7) Call close() on\nEventSource object
UA->PS: 8) Close connection
note over CA
 Application knows it can 
 still get events via 
 connectionless Push.
end note
CA->UA: 9) Call EventSource\n("connectionless")
note over PS
 Connection to Server 
 Application is retained,
 by design of the service.
end note
note over SA
 A new event stream is 
 ready for delivery.
end note
SA->PS: 10) Deliver event stream 
PS->SMSC: 11) SMPP:SM_SUBMIT\n(event stream\nin Push-OTA message)
SMSC->UA: 12) Deliver SMS\n(event stream\nin Push-OTA message)
UA->CA: 13) Deliver event stream

Server-Sent Events Access via Push Proxy with Fallback to Connectionless Delivery over OMA Push/SIP

participant "Server\nApplication" as SA
participant "Push Server" as PS
participant "SIP/IP Core" as SC
participant "User Agent" as UA
participant "Client\nApplication" as CA

CA->UA: 1) Call EventSource\n(Push Service url)
UA->PS: 2) Open connection (as proxy)
PS->SA: 3) Open connection
SA->PS: 4) Deliver event stream
PS->UA: 5) Deliver event stream
UA->CA: 6) Deliver event stream\nas it is received
CA->UA: 7) Call close() on\nEventSource object
UA->PS: 8) Close connection
CA->UA: 9) Call EventSource\n("connectionless")
note over PS
 Connection to Server 
 Application is retained.
end note
note over SA
 A new event stream (<1300 bytes) 
 is ready for delivery.
end note
SA->PS: 10) Deliver event stream
PS->SC: 11) SIP MESSAGE\n(event stream)
SC->UA: 12) SIP MESSAGE\n(event stream)
UA->CA: 13) Deliver event stream
note over SA
 A new event stream (>1300 bytes) 
 is ready for delivery.
end note
SA->PS: 14) Deliver event stream
PS->SC: 15) SIP INVITE
SC->UA: 16) SIP INVITE
UA->SC: 17) 200 OK
SC->PS: 18) 200 OK
PS->SC: 19) SIP ACK
SC->UA: 20) SIP ACK
PS->SC: 21) MSRP SEND\n(event stream)
SC->UA: 22) MSRP SEND\n(event stream)
UA->CA: 23) Deliver event stream
UA->SC: 24) MSRP 200 OK
SC->PS: 25) MSRP 200 OK

Client Application Redirect of Server-Sent Events to Connectionless Delivery over WAP Push/SMS

participant "Server\nApplication" as SA
participant "Push Server" as PS
participant "SMSC" as SMSC
participant "User Agent" as UA
participant "Client\nApplication" as CA

CA->UA: 1) Call EventSource\n(server application url)
UA->SA: 2) Open connection
SA->UA: 3) Deliver event stream
UA->CA: 4) Deliver event stream\nas it is received
CA->UA: 5) Call close() on\nEventSource object
UA->SA: 6) Close connection
CA->UA: 7) Call EventSource\n(Push Proxy Service url\n?appid=(server application url))
UA->PS: 8) Push Service Registration\n?appid=(server application url)
PS->SA: 9) Open connection
note over SA
 A new event is 
 ready for delivery.
end note
SA->PS: 10) Deliver event stream
PS->SMSC: 11) SMPP:SM_SUBMIT\n(event stream\nin Push-OTA message)
SMSC->UA: 12) Deliver SMS\n(event stream\nin Push-OTA message)
UA->CA: 13) Deliver event stream

User Agent Redirect of Server-Sent Events to Connectionless Delivery over WAP Push/SMS

participant "Server\nApplication" as SA
participant "Push Server" as PS
participant "SMSC" as SMSC
participant "User Agent" as UA
participant "Client\nApplication" as CA

CA->UA: 1) Call EventSource\n(server application url)
UA->SA: 2) Open connection
SA->UA: 3) Deliver event stream
UA->CA: 4) Deliver event stream\nas it is received
note over UA
 Event stream reaches some 
 criteria for switching to 
 connectionless delivery.
end note
UA->SA: 5) Close connection
note over UA
 Reestablish connection through 
 Push Server, delivering some 
 session-correlating information
 e.g. Last-Event-ID header.
end note
UA->PS: 6) Open connection to Push Proxy Service\n(with Last-Event-ID header, and\nserver application url as parameter)
PS->SA: 7) Open connection\n(Last-Event-ID header)
note over SA
 A new event is 
 ready for delivery.
end note
SA->PS: 8) Deliver event stream
PS->SMSC: 9) SMPP:SM_SUBMIT\n(event stream\nin Push-OTA message)
SMSC->UA: 10) Deliver SMS\n(event stream\nin Push-OTA message)
UA->CA: 1) Deliver event stream

WAP1 Push/SMS (OTA-WSP) Message Delivery

This flow shows a Push message delivered as a new or replacement message, to a target Push Client via the WAP1 Push Connectionless Push service over the GSM SMS bearer.

participant "Push Initiator" as PI
participant "Push Proxy Gateway" as PPG
participant SMSC
participant "Push Client" as PC
participant "client application" as CA

note over PI
 Push message is ready 
 to be delivered.
end note
PI->PPG: 1) PAP Push Message
PPG->PPG: 2) Request validation
PPG->PI: 3) PAP Push Response (accepted)
PPG->PPG: 4) Request processing\ne.g. tokenization
PPG->SMSC: 5) Submit SM\n(OTA-WSP/SMS formatted\nPush message)
SMSC->PC: 5) SMS (OTA-WSP/SMS\nformatted Push message)
PC-->PPG: 6) Push message\ndelivery confirmation
PPG-->PI: 7) result notification
PC->CA: 8) Push message delivery

1. Via the PAP interface, a Push Initiator delivers a Push request to the PPG, for delivery as a new message or replacement of a prior message. The Push Initiator indicates the target Push Application and one or more target users to whom the message is to be delivered. The Push Initiator may select various options for message delivery, e.g. bearers, delivery method, delivery scheduling, etc.
2. The PPG validates the request, and may accept or reject the Push request with respect to its validation or other implementation/deployment specific criteria (e.g. policies).
3. Via the PAP interface, the PPG sends a response to the Push request, indicating acceptance. If the PPG had rejected the Push request, the flow would terminate at this point.
4. For accepted Push requests, the PPG performs Push message processing which may include replacing a Push message previously submitted, queuing, selection of the Push-OTA variant, transformation of the Push message in preparation for OTA transmission, etc.
5. Via the Push-OTA interface, the PPG delivers the Push message to the target Push Client(s). The PPG may deliver the Push request via one or more Push-OTA variants/bearers as necessary to complete delivery to all target Push Clients.
6. If applicable to the Push-OTA variant and options of the Push message, the Push Client confirms delivery of the Push message by the PPG. If the message was not accepted, the Push Client may silently ignore the Push message, or indicate an error in the delivery confirmation.
7. If the Push Initiator had requested a result notification, the PPG will send the result notification to the Push Initiator via the PAP interface after receiving the confirmation message from Push Client, and include a delivery success/failure indication. Note for some Push-OTA variants (e.g. OTA-WSP/SMS), the PPG may send the result notification earlier in this flow if explicit Push Client delivery confirmation was not possible, and another source of delivery confirmation was used (e.g. delivery confirmation by an SMSC).
8. The Push Client delivers the Push message to the target client application, based upon the indicated Push Application. The Push Client will deliver the Push message via the Push-CAI interface if the target client application had explicitly registered for Push events via the Push-CAI interface.