Supporting Connected Clients

In supporting connected clients, the primary assumption is the endpoints will always be available on the network and will have a unique addressable identifier. Universal Resource Identifier as specified in RFC 1630 will be required to provide this identifier. The URI expected by the STAR transport will be HTTP or SMTP. Additional name services may be implemented based on user needs, such as DNS, WINS and NIS, however the mapping of these name services to URI’s is out of scope of the transport and is the responsibility of applications.

Supporting Disconnected Clients

Supporting a disconnected endpoint REQUIRES special handling because an OEM may want to send a message to an endpoint when that endpoint is not connected to the Internet. The STAR groups have devised two architectures to handle this situation. The first is a polling architecture that allows the disconnected client to request data when it is connected to the Internet. This polling architecture is also used to support endpoints that do not have an Internet addressable endpoint.

A key point to be aware of in developing a polling architecture is that most backend architectures that support disconnected or non-addressable endpoints process data asynchronously. Thus, in order to support a polling infrastructure additional backend infrastructure must be developed. This infrastructure is REQUIRED to support the storage and indexing of messages so they can be polled when the disconnected client requests the messages. Several ways exist to build out this additional infrastructure. One is to leverage an existing protocol that was designed to support non-addressable endpoints and disconnected endpoints such as SMTP. Another way is to implement or integrate a local message queuing system without regard for protocol dependence. This provides flexibility to use HTTP, SMTP or other network protocol and handle message persistence independently. Web services specifications allow for construction and implementation of these queuing systems. ebMS includes message queuing systems that allow us to leverage the HTTP and SMTP protocols.

Synchronous and Asynchronous Messaging

STAR has identified two messaging paradigms as synchronous and asynchronous. The synchronous messaging paradigm REQUIRES that an initiator of a message wait for a response from the receiver of the message before continuing with processing. The asynchronous messaging paradigm states that an initiator will send a message with delivery criteria and continue processing without waiting for response. This implies that the initiator can independently react to messages received and determine how those messages align to outstanding requests to a receiver. This also implies that receivers are able to receive messages with delivery criteria and respond appropriately. ebMS is primarily but exclusively designed to support asynchronous messaging. Web services specifications do not favor implementation of one paradigm over another, therefore it is up the implementers to determine how to design and build this.

It is RECOMMENDED that asynchronous messaging paradigms be used whenever possible. One scenario that requires synchronous messaging is the polling infrastructure to support disconnected or non-addressable endpoints. Synchronous messaging may be selected when backend processing is minimal and the results can be returned with in a few seconds. Decision criteria are based on the performance verses the trade-off of scalability of performing rapid request reply models asynchronously.

Client initiated and Bi-Directional Messaging

Directional messaging and two way messaging are also supported by both RECOMMENDED messaging paradigms. Similarly to synchronous/asynchronous messaging each default to a different paradigm, but can be configured to support either. It is RECOMMENDED that bi-directional messaging be used when possible. Again, the polling infrastructure is the exception to this recommendation.

Polling is necessary in certain situations but introduces risks in polling latency, server performance overhead handling poll requests, and additional infrastructure to preserve data. There are ways to address these issues that are not in the scope of this document.

One type of polling is implemented with SMTP to email servers. This type of client initiated messaging is well understood, since it is used for many email systems. SMTP alone is a clear text protocol and can expose sensitive data and passwords across the Internet. SMTP with TLS, also known as SMTP with SSL, provides an encrypted SMTP channel and is implemented in several SMTP servers. Message reliability and XML security is provided for payloads over SMTP and SMTPS by the ebMS message handler which uses SMTP directly or by certain Web services specifications as implemented in applications or products.

Cost of Implementation

The costs of implementations are driven by many factors that need to be considered. These factors are mitigated or exacerbated by existing strategies, infrastructures, and business environments at each trading partner. When assembling cost models for implementing STAR Transport Guidelines the following MUST be accounted for:

In general, developed code REQUIRES that support and maintenance costs are absorbed and should be included in total cost of ownership. Even custom code that conforms to conventions specified in these documents MUST be supported and maintained internally. These are all factors that need consideration in any cost model.

The value of an interoperable transport MUST be measured against the existing costs of various transport systems in use, including development, deployment, support, and maintenance of VPNs, Satellite networks, VANs, and private telecommunications. STAR realizes there will be cases where the cost models of or strategies for existing transports will lead STAR members away from implementing STAR Transport Guidelines. This will not directly affect the interoperability of STAR XML BODs as long as security and reliability can be assured as needed.

Finally the cost of implementing messaging handlers, services, or functions MUST be separated from the costs of integrating the STAR XML BODs to back end systems. The costs of development and maintenance of interfaces for the STAR XML BODs are independent of the costs of the mechanisms to move payloads between partners and any accurate cost analysis must be able to separate those costs.