Chapter 3, Transport Methods

STAR has chosen to recommend the following Transport Methods:

The goal of this dual specification approach is to simplify the transfer of data among manufacturers, dealership management systems, and Retail Service Providers (RSP).

ebMS version 2.0 is the more mature of the standards.  It has several advantages including:

Web Services specifications allow businesses to use the Internet to interact with their trading partners and have a wider focus than document-based, business-to-business messaging.  The core standards of Web Service Specification standards are SOAP, and WSDL.  Collectively, they are loosely referred to as WS-*.

To be compliant with the STAR Web Services Profile, implementations MUST be compliant to STAR Level 1 and/or STAR Level 2 rules and MUST support all Standards and Recommendations.

There are two key advantages to using WS-* specifications:

For more specific information on ebMS and Web Service specifications please consult the ebMS Implementation Guideline and/or the STAR Web Services Guideline.

Chapter 4, Reliable Message Delivery

Messages can be exchanged among business partners using a wide variety of exchange models and technology architectures.  Because of this, it is critical that reliability standards and requirements are applied to ensure data integrity.

Reliable Messaging is a combination of Delivery Assurance and Message Integrity that utilizes established Standardized Error Handling agreements.  Delivery Assurance provides a message sender a guarantee that a message will be delivered.  Message Integrity ensures that the received message is byte-for-byte the exactly the same as the message sent and is acknowledged in a set sequence within a given timeframe.  When failure occurs Standardized Error Handling agreements equip messaging systems with the ability to generate appropriate error responses.

Below are the recommended requirements for each of the components of Reliable Messaging:

Business partners need to come to a consensus on the details of the level of reliability through the use of Partner Policy Agreements.  Reliable Message agreements at minimum should specify the following issues:

STAR requires that Web Services transport implementation use WS-ReliableMessaging and that the ebMS transports use the ebMS Reliable Messaging Module.

Chapter 5, Collaboration

Typical XML based business messages range in size from a few kilobytes to as large as 100 megabytes or more. As messages have grown in size and number, system designers are forced to deal with complex issues regarding how to handle the increased load and traffic.

As a best practice, STAR recommends that business partners avoid system designs that require extremely large messages due to the technical and business problems that can result from processing oversized files. However, when using large messages is a necessity, STAR recommend that messages over one megabyte be compressed. (This is discussed in detail in Performance.) STAR recognizes that batching and chunking messages is a common practice, however no standards on these topics have been developed at this time. Currently, at least one STAR BOD, Inventory Update may result in very large messages.

STAR requires that all messaging solutions and business partners, particularly entities acting as Addressable Hubs or Addressable Endpoints be able to support bidirectional, asynchronous and synchronous messaging. Non-Addressable Endpoints that do not continuously listen for incoming messages will need to be able poll or “pull” for outstanding messages. STAR Web Services defines a specific format and process for pulling messages. These requirements are discussed in detail in Internet Connectivity.

Chapter 6, Performance

Sending large XML documents across the Internet can be problematic. As some of the STAR BODs increased in size it became evident that there was a need to address compression requirements. However, at the time, there were no well-established standards detailing how to implement compression for Web Services from OASIS, W3C, or WS-I so a STAR convention was created to fill this void.

The goal of compression is to reduce the size of the large documents so that bandwidth between partners is reduced and transfer across the Internet can be expedited. The amount of compression that can be achieved is dependent on the variety and complexity of the actual text. Not all messages need to be compressed and, in fact, using compression on smaller documents will actually result-in increasing consumption and processing time. Most of the STAR BODs are less than 1MB and do not need to be compressed.  

STAR recommends that BODs greater than 1 MB should be compressed using the gzip compression scheme. Gzip is an open-source, patent-free variation of LZ77. A detailed description of the compression method can be found within the chapter. STAR also allows other compression algorithms however the following requirements must be addressed:

HTTP compression is the technology used to compress MIME type contents (HTML, plain text, images formats, PDF files, XML etc) from a Web sever. An Accept-Encoding header that is exchanged between the web client and the web server helps determined if the receiver can handle the compressed data and/or what format the data is received.  Some Web applications may have various issues with the HTTP exchange. (Examples are provided in the chapter.)  

HTTP compression, along with Content-Encoding, Transfer-Encoding, is a recommendation of the HTTP 1.1 protocol specification for improved page download time. HTTP compression is managed by the infrastructure at the transport level and therefore requires no programmatic manipulation.

In most cases, dynamic HTTP Compression should be used on Web Servers that utilize HTTP endpoints. Static compression is not well suited to the dynamic nature of XML data.

When deploying SSL Infrastructure Level Security it is important that messages be encrypted before being compressed.  It is required that Web Servers using HTTP endpoints support dynamic compression either out of the box or through the use of third party plug-ins.

Chapter 7, Auditing

The auditing process is made possible by using Logging to record and monitor the messages that pass through the Transport layer. These logs can be used to detect security compromises, keep a record of valid and invalid messages, and provide an audit trail for security policy compliance and legal disputes.

STAR encourages the use of Non-Repudiation-in-Digital-Signature standards to verify that the sender and the recipient are, in fact, the intended parties in the message transaction and that the integrity of the data is intact.

Non-Repudiation of Origin provides proof that data has been sent by using Public Key Infrastructure (PKI) to “sign” the message. Non-Repudiation of Receipt provides proof data has been received by returning a signed digest within an acknowledgment to the original message.

Key Data fields and metadata should be logged for all sent and received messages. STAR requires that Logging systems must be capable of storing, displaying and being queried on all key message data fields and metadata including: