Standards for Technology in Automotive Retail
STAR has chosen to recommend the following Transport Methods:
ebXML Message Service Specification (ebMS) version 2.0.
WS-I Basic Profile v1.0a plus Web services specifications from OASIS and the W3C that are targeted for future profile adoption by WS-I.
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:
It fits well with up-stream community requirements.
It provides secure and reliable document based business to business messaging.
It is flexible in the type of data payloads it carries.
It has widespread vendor support.
It was designed to focus on the business-to-business problem.
Its architecture provides broad functionality in a single specification.
It clearly defines many sophisticated features that map directly to STAR Requirements.
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:
They can be implemented with light weight infrastructures.
They can incorporate selective functionality to fit varying scales and needs within dealership systems.
For more specific information on ebMS and Web Service specifications please consult the ebMS Implementation Guideline and/or the STAR Web Services Guideline.
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:
Reliable Messaging Requirements
Delivery Assurance Profiles
Once-And-Only-Once / Exactly-Once
Delivery Assurance Features
Acknowledgement of Receipt
Standardized Error Handling / Monitoring
Recovery Processes / Message Store
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:
Level Of Reliability - Best-Effort, At-Least-Once, At-Most-Once, Once-And-Only-Once/Exactly-Once
Synchronous vs. Asynchronous - Agreement on the basic message exchange pattern
Time-Out - Amount of time a sender has to wait before retry
NumberOfRetries - Maximum number of times system will retry a message
RetryInterval - Amount of time sender has to wait between retries
OutOfSequence - What actions are taken if a message is received out of order and /or what actions are taken if not all messages in a sequence can be acknowledged
STAR requires that Web Services transport implementation use WS-ReliableMessaging and that the ebMS transports use the ebMS Reliable Messaging Module.
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.
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:
The algorithm must be transmitted as an element in the uncompressed SOAP envelope. (The SOAP envelope of an ebMS message should never be compressed so that routing information can be available without the need for decompression.)
The partner agreement (CPA, WSDL, or out-of-band) specifies that both parties support that algorithm before sending the message.
When programmatically assembling and processing messages, a mechanism to programmatically handle the compressed attachments at the endpoint may be necessary.
The application needs to be able to make a determination on payload since pre-compressed content and test content is not distinguished.
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.
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:
Time message was sent or received
Key data fields from the message
Hostname of the message sender
Activity (the Service/Action name or web method)
Optional Message Disposition or Status