ebXML provides a complete set of services for business to business integration. STAR specifies a reduced set of ebXML that uses message services and collaboration protocol to meet transport requirements.

Figure 3.1. STAR ebMS Stack

STAR adds few more layers to the Web Services stack to provide support for OEM to DMS communication in a well-defined way.

Figure 3.2. STAR Web Services Stack

Delivery Assurance is the ability of a message sender to be assured that a message will be delivered. This delivery guarantee protects the sender from network or system failures that may occur along the way. Based on factors ranging from the type of endpoint to the type of data, various levels of protection may be needed. Thus, it is important to be able to “customize” the reliability effort required into well-understood Delivery Assurance Profiles.

STAR recommends support of four levels of Delivery Assurance:

“Best-Effort” is the absence of any reliability features. A sender sends a message and assumes that the intended party received it.

“At-Least-Once” requires the sending party to uniquely identify a message and the receiving party to acknowledge the receipt of the message, giving the sender an auditable record stating that the message has been received. If the sender does not receive an acknowledgment of receipt in a reasonable amount of time (Time-Out), it MUST retry the message send. The sender and receiver should agree upon a reasonable Number-of-Retries and a reasonable RetryInterval to avoid unnecessary network traffic.

“At-Most-Once” requires a sending party to uniquely identify messages, to retry failed messages and requires the receiving party to identify and ignore any duplicate messages. In order to know which messages to ignore, it is strongly recommend that the receiving party persist received messages in a durable store. Note that the receiver is not required to acknowledge receipt of a message.

“Once-And-Only-Once / Exactly-Once requires the sender to uniquely identify each message and to retry any message that the receiver fails to acknowledge. The receiver must acknowledge receipt of messages and ignore duplicate messages. It is strongly recommended that the receiver persist messages in a durable store to enable duplicate elimination.

Message Routing

Message Routing refers to the ability of an Endpoint to figure out where to send a message. Routing can be specified per message and/or by leveraging some sort of Partner Management system.

It is necessary that business partners agree on which data elements in a message determine routing and the type of data, for example a URI. These agreements enable predictability between partners:

Retry and Acknowledgment are key mechanics for Reliable Messaging and require the parties to agree on the data elements that describe Routing.

STAR recommends that ebMS version 2.0 Routing features be used in conjunction with ebXML CPPA, or STAR recommends the use of WS-Addressing.

Acknowledgment of Receipt

A Message receiver must implement Acknowledgment of Receipt to enable:

Acknowledgment of Receipt means that an endpoint has received a message, and the endpoint believes the message can be processed. In other words, the message appears to be valid for an agreed upon format, appears to be received as sent, has not failed any initial security checks and the endpoint will attempt to take action that results in the processing of the business request represented by the message.

Acknowledgment of Receipt is not a business level acknowledgment such as AcknowledgmentOfPartsOrder.

STAR recommends that WS-ReliableMessaging Acknowledgment messages are used, or STAR recommends that ebMS version 2.0 Acknowledgment messages be used.

Partner Policy Agreements

To enable Reliable Messaging, business partners must agree on how to share the Policy details that govern the level of reliability. This Policy information might be set per message using data elements in the message, or may be shared out-of-band using persistent Policy Agreement records. To enable the automation of these agreements, STAR Recommends ebXML CPPA for ebMS. STAR has identified the WS-Policy framework of standards as the long-term solution for STAR Web Services Guideline. The WS-Policy recommendation will be expanded in future STAR Transport Guidelines documents.

Policy Agreements related to Reliable Messaging should include the ability to specify:

Message Integrity

STAR recommends three characteristics of Message Integrity:

Content Integrity is the ability of the receiver to ensure that a message has been received byte-for-byte exactly as sent. The typical solution for ensuring Content Integrity is for the sender to digitally sign the original message, providing a hash or content-digest of the message that the receiver can use to verify the message is a an exact representation of the intended message and has not been altered in transit.

Message Sequencing is the ability to label multiple messages as being part of a coherent ordered set of messages. In other words, message 3 follows message 2, which follows message 1.

TimeToLive is a timestamp associated with a message that defines its useful processing life. If the receiver receives a message who’s TimeToLive has expired, the message should be ignored.

STAR recommendations on Reliable Messaging are focused on point-to-point systems. From a technical perspective, STAR does not describe Multi-Hop features for Web Services or ebXML. STAR may address this in the future.

STAR workgroups have engaged in many discussions on how parties can identify themselves and what implications this has for intermediaries. There is a desire to support a model where a Dealer can identify itself to an Intermediary, and that Identification will be passed on to the end receiver, an OEM.

STAR currently allows for Authorization and Authentication based on Digital Certificates or Username / Password.

From a technical perspective STAR ebMS does not address any differences for an intermediary, the assumption is that Authorization and Authentication will be based on Digital Certificates and will be:

or

STAR Web Services do describe a model for the presence of Intermediaries where security information, including security tokens used for Authentication and Authorization can be targeted at an Intermediary. This capability is based on the ability of WS-Security 2004 constructs to leverage the SOAP Actor data fields. If security information is targeted at the “Next Actor”, an Intermediary may use this security information to Authenticate and or Authorize the message originator, and then the Intermediary is required to remove this specific security information from the message before forwarding.

In order to support interoperability and message handshaking, standardized error handing and monitoring should be used. STAR recommends the following error conditions be addressed:  

Resend

A Message sender must implement resend of messages to enable At-Least-Once, At-Most-Once or Once-And Only-Once / Exactly-Once profiles. Messages that are retransmitted should repeat the original message's MessageID (allowing the receiver to determine whether a duplicate has been received or not).

MaxNumberRetries

Parties must be able to agree to a maximum number of times a message can be retransmitted and should establish a Policy for what happens if the maximum number of retries is exceeded and a message still has not been delivered.

Timeout

Parties must be able to agree on a Time-Out value. This is how long a sender waits for Acknowledgment of Receipt before retransmitting a message.

STAR strongly recommends that sent and received messages are placed in a durable store, enabling correct processing, including the identification of duplicate messages, in the case of system failure.

Parties that choose to implement At-Most-Once or Once-And-Only-Once / Exactly-Once profiles must support the ability to identify and ignore messages with duplicate message IDs.

ebMS views sequencing as an optional feature, separate and distinct from ReliableMessaging, while WS-ReliableMessaging requires the sequencing of messages. ebMS uses sequencing to order messages. An ebMS sender expects that the first message will be processed before the second message. WS-ReliableMessaging uses sequencing generally to enable performance management of the flow control of messages that carry reliability artifacts such as Acknowledgments.

ebMS guarantees delivery of individual messages. WS-ReliableMessaging guarantees delivery of a group of messages based on their common SequenceIdentifier. A WS-ReliableMessaging Acknowledgment gives you information about one or more messages that were sent as a sequence.

To implement ReliableMessaging, parties MUST make out-of-band agreements on many parameters including which Delivery Assurance Profile is in use.

The WS-Policy framework is the stated direction for establishing agreements between parties for Reliable Messaging using STAR Web Services Guideline. WS-Policy and related specifications are relatively new and best practices are probably yet to emerge using these capabilities. Some of the capabilities are detailed below under “WS-ReliableMessaging Implementation”, but STAR anticipates that parties may use implementation specific or manual out-of-band agreements for the time being, and future releases of these guidelines will leverage industry experience to clarify best practices around Policy.

The STAR Transport guidelines are not intended to address the special needs of intermediaries. All discussions on Reliable Messaging, Authentication, Network architecture, etc. are intended to be applied to point-to-point architectures. STAR does not preclude the use of Web Services technologies such as ebXML Multi-Hop, but recognizes that there are too many business and technical models for Business Intermediaries to create useful recommendations. Individual parties may have to negotiate details to apply STAR recommendations in intermediary scenarios.

The only exception to this are statements in the STAR Web Services Specification that allow for Intermediaries to Authenticate and Authorize message senders through the use of WS-Security 2004 and SOAP Actor constructs.

The STAR Transport guidelines can be applied to Routing Intermediaries. In other words, if an intermediary makes absolutely no changes to a message, but simply forwards it, STAR REQUIREMENTS for Reliable Messaging, Authentication, Network Architecture, etc are directly applicable.

Typical XML based business messages range in size from a few kilobytes to a few dozen kilobytes. In most modern industries, including upstream automotive, it is still common for messages to be larger, in some cases above 1 megabyte than or even as large as 50-100 megabytes.

These very large messages create many challenges for system designers. The sheer size of the transfer does not lend itself to memory based processes; parts of the message may have to be saved to disk during processing. Sometimes these large files represent a “batch” of transactions that must be parsed and individually forwarded or executed.

The STAR Transport message services STAR ebMS and STAR Web Services are HTTP based (STAR ebMS also allows for SMTP). In practice HTTP is capable of transporting files between 1-100 megabytes or even larger, but these types of transfers are typically slow (minutes or hours, not seconds) and can cause performance issues for message gateways that are designed and tuned for significantly smaller messages.

As a best practice, STAR recommends that business partners avoid system designs that require extremely large messages. For example, an inventory update could be separated into multiple updates each covering a category of closely related products.  

STAR is not precluding batch processing, which is a reality in corporate systems, but is suggesting that analysts use common sense when designing business message transfers, so that a partner is not overwhelmed by extremely large message receipts.

STAR will not recommend or require a standard for “chunking” large messages into multiple smaller messages, there does not appear to be a widely accepted standard for chunking business messages over HTTP.

STAR does define requirements and recommendations for compression of large messages, see the performance section for more information.

STAR requires that entities acting as Addressable Hubs or Addressable Endpoints must support bi-directional messaging, where each endpoint can act as either the sender or the receiver. STAR also defines an entity known as a Non-Addressable Endpoint, which supports only client initiated messaging. Non-Addressable Endpoints are intended to describe the architecture of dealer systems which may not have the business need, technology or staff to support bi-directional messaging. Addressable Hub and Addressable Endpoint are intended to describe the architecture of OEM Manufacturers and Retail Service Providers, which in general provide highly available systems that can both send and receive messages.

For a complete discussion on architecture and message patterns please review the Internet Connectivity section.

STAR requires that all messaging solutions and business partners be able to support asynchronous messaging. For systems acting as Non-Addressable Endpoints, asynchronous or delayed response messaging can be accomplished by the Client polling the Server for outstanding messages.

For a complete discussion on architecture and message patterns please review the Internet Connectivity section.

STAR requires that all messaging solutions and business partners be able to support synchronous messaging and, as mentioned above, STAR Transport is based on HTTP and can leverage the synchronous request-response nature of HTTP to implement synchronous messaging.

STAR cautions that synchronous messaging is not always a good fit for business messages whose target systems are legacy applications which operate asynchronously, such as batch processing systems or systems accessed through message queues. A specific issue is handling message timeouts, if the synchronous request times out, the state of the transaction may not be clear. STAR strongly recommends that asynchronous messaging Transport be used if the backend application systems are incapable of rolling back or compensating for timed out transactions.

For a complete discussion on architecture and message patterns please review the Internet Connectivity section.

The STAR Transport message services STAR ebMS and STAR Web Services both provide optional features that enable message ordering.

ebMS provides an optional Message Ordering module. Both partners must agree that message ordering is to be used. ebMS Message Ordering guarantees that messages are processed in a sequence defined by the message sender. For more discussion see the sub-section entitled Message Sequencing under Reliable Message Delivery.

STAR Web Services leverages WS-ReliableMessaging to define sequences of messages through an optional Delivery Assurance profile named InOrder. Both partners must agree to use the InOrder profile. InOrder guarantees that messages are delivered to the end application in the exact order as received. For more discussion see the section entitled Reliable Messaging in the STAR Web Services Specification document.

The ability of a partner to poll or “pull” messages from a second partner is important for systems that are defined as Non-Addressable Endpoints. In other words, small organizations not capable of providing a 24/7 environment that listens for incoming messages, need to be able to poll partners for outstanding messages.

STAR Web Services defines a specific format and process for pulling messages. In the STAR Web Services Specification, see the sections entitled Interface Specifications and Communication Patterns. The STAR Web Services Specification also has complete code examples for Pull Message Request and Pull Message Response.

STAR ebMS supports pull messaging through optional support of SMTP (email based transport). STAR SMTP ebMS clients can download queued messages, in the same fashion as a mail client downloads new mail.

The discussion on very large messages focused on the significant effect on the design of messaging endpoints. Endpoints cannot assume that all messages can be processed in memory, and may need to be able to chunk portions of received messages to disk.

Also, discussion revealed that at least one STAR BOD, Inventory Update, may result in very large messages.

Business analysts and BOD designers should take into account that extremely large messages can cause both business and technical problems, BOD designers should strive for flexible patterns business patterns that allow for small messages.

Discussion centered on the complexity of handling time out issues; if a synchronous message times out the receiving system should be able to back out any changes. Systems that are unable to support back-out of transactions should lean toward asynchronous messaging styles.

Discussion was that business analysts and BOD designers need to discuss these requirements before the issues can be related to Transport.

The initial STAR Collaboration requirements included a requirement for Push Messaging. Discussion focused on the fact that the Push requirement is similar to the concept of store-and-forward, in other words the message sender is queuing outbound messages. Consensus was reached that system implementers can queue and push messages and no specific changes need to be made to the guidelines to support this model.

There was discussion on the possible use of cell phones and or PDA (Personal Digital Assistant) devices for STAR Transport messaging. There was no consensus on any needed changes to the Guidelines to support these devices, and this is still an open issue that should be raised with STAR membership in general to understand if there are requirements to support these types of devices.

There was discussion on how STAR Transport and STAR BOD specifications can address long running business processes. There was no consensus on making changes to the STAR Transport Guidelines to support these concepts, the discussion focused on the Transport not needing to be aware of long running processes, but that the Transport SHOULD be able to easily share key information, in particular the MessageID of messages, so that backend applications can correlate messages and implement higher level business processes that span multiple messages.

STAR RECOMMENDS that STAR Transport implementations be capable of easily sharing key message data with backend applications, allowing the backend applications to correlate messages for the purpose of executing or tracking long running business processes.

In particular, STAR RECOMMENDS that STAR Transport implementations be capable of easily sharing the MessageID of sent and received messages. STAR ebMS implementations SHOULD be capable of sharing the MessageID and ConversationID fields. STAR WS implementations SHOULD be capable of sharing the WS-Addressing MessageID and the WS-ReliableMessaging Sequence and MessageNumber data fields.

As a best practice, STAR RECOMMENDS that business partners avoid system designs that require extremely large messages. STAR is not precluding batch processing. STAR will NOT RECOMMEND or REQUIRE a standard for “chunking” large messages into multiple smaller messages. STAR does define requirements and recommendations for compression of large messages, see the performance section for more information.

STAR REQUIRES that entities acting as Addressable Hubs or Addressable Endpoints MUST support bi-directional messaging, where each endpoint can act as either the sender or the receiver. Addressable Hub and Addressable Endpoint are meant to describe the architectures of OEM Manufacturers and Retail Service Providers.

STAR REQUIRES that all messaging solutions and business partners be able to support asynchronous messaging.

STAR REQUIRES that all messaging solutions and business partners be able to support synchronous messaging.

Message Ordering is an OPTION that is supported by both STAR ebMS and STAR WS. Both partners in an exchange MUST agree that message ordering is to be used.

Use of Pull Messaging is an OPTION, specifically aimed at entities acting as Non-Addressable Endpoints. STAR Web Services defines a specific format and process for pulling messages. STAR ebMS supports pull messaging through optional support of SMTP (email based transport).

The goal of compression is reduce the size of the large documents so that transfer across the Internet can be expedited. There is a cost to compress and decompress a document, but with modern processing speed it may be advantageous to spend the processing resources to gain network efficiency.

Reduction of Size

STAR BODs are textual XML documents that can be reduced in size by compression, which translates the inefficient human readable format of the documents to a smaller binary format. The amount of compression is dependent on the variety and complexity of the actual text.

Not all messages need to be compressed. Implementing compression/decompression on smaller size would be counterproductive and prove to be an overhead on the Sender/Receiver systems, and result in increasing response time. A common observation about BODs is that although most will not be greater then 1MB, the small percentage that is will likely be significantly larger then 1MB.

Since small BODs may not yield much benefit in compression, it is not recommended that small BODs be compressed. Larger BODs, however, can yield great benefits and it is recommended that BODs larger then 1MB should be compressed using the gzip compression scheme. This may vary based on the quality and speed of the Internet connection at the Sender/Receiver. Given the compression point of 1MB, it is estimated that a large percentage of the BODs will not require compression.

Bandwidth between business partners

Most business partners collaborating in a STAR BOD exchange would have some level of broad band set up between them. Adding compression to the data exchanged would reduce the bandwidth required for the exchange and allow for greater utilization of the available bandwidth between partners.

Increased processing time

While it is true that compression results in reduced data size and bandwidth usage it can also result increased resources consumption and processing time on both the server as well as client. This was also shown by the W3C Study. Only where network bandwidth is constrained and processing resources are relatively cheap does the cost of additional processing time justify compression.

Flexibility

One of the benefits of XML is that the self-describing, textual data format can be read and understood by humans without the aid of an application. While there is no requirement for human access to the STAR BODs, compressed BODs cannot be read by humans without decompression.

Compression may not be required for all messages because the cost of compressing the payload or implementing a compression function may not justify the value. If compression is to be used on a document, there must be a way to communicate that the payload is compressed before the receiver attempts to process the payload.

Based on a variety of research, it was determined that the most appropriate algorithm for a payload compression mechanism was that found in gzip. This section will review the key requirements that went into that selection and describe how gzip meets the criteria and why it was selected as the preferred standard compression algorithm. Other compression algorithms exist in the marketplace that may have benefits over gzip but the wide adoption of gzip makes it suitable for a minimum requirement.

Other compression algorithms are not precluded from STAR usage. Any other algorithm used must have two considerations addressed:

gzip a loss-less compressed data format and the deflation algorithm used by gzip (also zip and zlib) is an open-source, patent-free variation of LZ77. It finds duplicated strings in the input data. The second occurrence of a string is replaced by a pointer to the previous string, in the form of a pair (distance, length), distances are limited to 32K bytes, and lengths are limited to 258 bytes. When a string does not occur anywhere in the previous 32K bytes, it is emitted as a sequence of literal bytes. (In this description, "string" must be taken as an arbitrary sequence of bytes, and is not restricted to printable characters).

Since the amount of compression obtained depends on the size of the input and the distribution of common sub strings, the large amount of spaces that exist in XML documents is well suited to gzip. Typically, text such as source code or English is reduced by 60-70% while large XML document can exceed 90% compression ratios. It is covered by the GNU General Public License. gzip is supported and available on all major platforms and is widely used and implemented.

With payload compression, the compression mechanism is only needed for the compression of payloads that can benefit, such as the STAR BODs. Normally, executable, multimedia, and binary data formats are efficient enough such that little gain is realized from compression. The header of the SOAP message will maintain a relatively consistent size and will not be large enough to require compression. The effort to compress and decompress the SOAP header will affect performance especially when traversing through intermediaries that need to examine the header. Where this is a concern, the focus should be on compression of the XML to significantly reduce transmission time and increase performance, but retain uncompressed headers to avoid intermediate decompression/recompression.

Algorithm Interoperability

There are two issues while using payload compression:

The application needs to make determination on payload compression since there is no distinguishing between pre-compressed content and test content.

HTTP compression is important for both STAR Web Services and ebMS transport methods. HTTP compression is the technology used to compress contents from a Web server (also known as an HTTP server). The Web server content may be in the form of any of the many available MIME types: HTML, plain text, images formats, PDF files, XML etc.

HTTP Compression Exchange

The publicly defined exchange between the requester and the web server serving the HTTP resources can be summarized as follows:

HTTP Compression Standards

Content-Encoding, Transfer-Encoding and HTTP compression is a recommendation of the HTTP 1.1 protocol specification for improved page download time. Benefits of Using HTTP Protocol compression:

Web Server support

Most popular Web servers are still unable to handle the final step (see HTTP Compression summary above) in the HTTP exchange where they are required to perform real time compression on the resource before sending it to the client. For example:

There are third party products available that can be plugged in too web servers to enable compression, e.g. JXEL. Such plug-in type products enable HTTP compression for multiple web server types. If web servers are used to implement the STAR transport mechanism, then they must be evaluated to provide the final step of HTTP compression.

Multiple Payloads

As mentioned, compression is most beneficial for large, textual documents. When compressing a total SOAP message with multiple payloads in the body, there is no discrimination between small textual, large textual, binary, or pre-compressed payloads (such as JPEG images). The tradeoffs between processing time and benefit of compression become harder to predict. The decision to compress or not and when to break multipart messages into individual messages becomes more complex.

The STAR Web Services Guidelines assumes that messages subject to HTTP compression will normally be XML-only documents.

Compression is NOT REQUIRED for all document transfers, however if compression is agreed upon between training partners then the following requirements MUST be met.

Implementers of the STAR Transport Guidelines are encouraged to leverage Digital Signature standards that enable Non-Repudiation. Whether or not a business transaction requires Non-Repudiation is determined at the application level, but the physical implementation of Digital Signature required for Non-Repudiation occurs at the Transport level.

Signing a message lends itself to “Non-Repudiation of Origin”, in other words, the business partner receiving a message can prove at any later time that the message originated from a specific unique party. Signing a message can also guarantee that the message was received intact, byte-for-byte as sent.

Under the framework known as PKI (Public Key Infrastructure), a message sender signs each message using a specific Private Key. The Private Key is associated with a well-known Public Key, and the Public Key is known to be associated with a business partner’s computer system or one of the business partner’s employees.

“Non-Repudiation of Receipt” is a model of Non-Repudiation that requires a little more work than Non-Repudiation of Origin. To enable Non-Repudiation of Receipt, the receiver of a message creates a digest of the received message, signs the digest, and returns the signed digest within an acknowledgment to the original message. The business partner that originated the message can now prove later, that the message he/she sent was received intact by the intended business partner.

Auditing is useful for monitoring the security of the transport layer. Logs of messages can be reviewed to detect compromises of security or to document compliance with local security policies. Logging message information along with the disposition of such messages is a best practice for organizations that need to be able to audit activities for security policy compliance.

Signing a message provides a guarantee that a message was not altered in transit. By accepting and logging that message, a receiver keeps a record of the valid and invalid messages. If a message is invalidated, then it may be suspected of malicious tampering. Logging the entire message can help in tracking down and in prosecution when security issues arise.

When an originator needs to have assurance that a message was received, that organization could request a signed receipt acknowledgement. An audit trail of these receipt acknowledgements provides assurance that the receiver is the intended receiver.

Logging provides a record of messages that pass through the transport tier. This record is a tool that enables non-repudiation for transport of messages. Logging of all messages that specify non-repudiation is necessary to support the ability to audit the STAR Transport.

STAR does not require a specific format for logging the exchange of a message, but does specify the key fields [for those messages that are logged] which must be logged, which include time stamps, senders, receivers, message ID, and payload type. Additionally, a status field in the log record can indicate the message disposition and is recommended to track messages that are valid, have bad signatures, do not pass checksum, or other exception condition. STAR distinguishes between:

Simple logging of key fields and metadata of a message vs. saving a copy of the entire message.

STAR requires that the globally unique message ID be generated for each message, and that these message IDs must be logged as one of the key data fields related to the message. If the application does not generate the Message ID, then it must be generated by the transport.

Logging systems should make important key fields from the messages easily available. Logging systems must be able to display or export information with Timestamp formats that do not rely on local system time, but are expressed in a universal time format.

STAR recommends that logs are retained for at least 30 days. STAR recognizes that companies may retain logs for periods of several years or more, depending on the type of message.

STAR requires that all messages in transit be time-stamped using UTC (Coordinated Universal Time) in a fashion that relies on what is known as GMT (Greenwich Mean Time) and is often referred to as Zulu time. In other words, Timestamps that appear in the Headings of messages in transit must be in UTC/GMT format without local time-zone offsets. STAR does not require that messages be logged or stored using UTC/GMT, but as mentioned above, STAR requires that Logging systems when queried be able to display Timestamp information in UTC/GMT format without time-zone offsets.

The possible use of third party Trusted Timestamp Services was discussed and rejected as not being necessary for STAR Transport given that current STAR Management and Auditing requirements are sufficient to guarantee accurate message timestamps.

Currently, STAR Transport Management Guidelines REQUIRE the use of NTP (Network Time Protocol) which guarantees participating system times are accurate and STAR Management and Auditing requirements specify UTC/GMT Timestamps for in-transit messages which allows for clear and common interpretation of Timestamp values without the need to compensate for Time Zones or Daylight Savings Time.

Discussion centered on the difference between UTC with offsets and UTC without offsets. Consensus was that UTC without offsets is a desirable and beneficial common format. When two logs, such as the sending and receiving log must be compared, a common universal format that does not need interpretation due to time-zone offsets is beneficial, especially if a human being is being required to manually analyze the logs.

Discussion was that there are a small number of key fields critical to Auditing, and that Logging systems MUST save these values and enable queries based on these values, or at least be able to display the values. Initial key fields identified are Datetime, MessageID, Hostname and Activity (i.e., the service name or web method).

Discussion was that Logging systems must be capable of associating unique messages with unique business transactions. Logging systems may key off specific STAR Transport Web Services or ebMS fields including but not limited to MessageID and ConversationID. Further discussion was that it is the responsibility of the application or the transport to generate globally unique message IDs for every message.

Messages that are opened by an intermediary or repackaged messages REQUIRE new IDs. The reasoning behind this is that a message ID is associated with the integrity of that message. By opening a message, a party effectively “accepts” that message and another message with a new ID is then created to pass on the content, even if the content has not been altered. If the message is not opened or repackaged the message ID can be passed along with the message. Intermediaries are responsible for tracking transformations or mapping of message IDs for messages that are opened.

STAR REQUIREs that MessageIDs be associated with Transport level, and that these message IDs MUST be globally unique. These Message IDs can be generated by transport level software or by applications that integrate transport functionality as long as the Message IDs are globally unique. See the MessageID Format section for best practice for application generated message IDs.

STAR RECOMMENDS that back-end business applications and or middleware be capable of associating the Transport message IDs to the unique business transaction that created the message and or to business transactions that are created based on the receipt of a message.

When a business transaction contains a requirement for Non-Repudiation it SHOULD be the responsibility of the concerned trading partner to save the entire message from the Transport layer.

Key Data fields and metadata SHOULD be logged for all sent and received messages. Log information MUST be made available upon request; sharing of log information can be done “out-of-band”, meaning by some manual process outside the transport.

Timestamps for messages in-transit MUST be formatted as XML Schema Datetimes in UTC/GMT format without offsets. For example, 2003-11-05T13:15:30Z corresponds to November 5, 2003, 8:15:30am Eastern Standard Time. Logging systems must be capable of displaying message timestamp information in UTC/GMT format without offsets.

Application generated message IDs MUST be globally unique and be formatted following the specifications of the particular transport that is being used. STAR requires the following three (3) data elements within the message id:

The specific format using these data elements will be outlined in both the ebMS and WS guidelines documents. Examples of each are:

If applications do not supply a message ID, then the transport MUST generate a Globally Unique Identifier (GUID). The format of message IDs generated by transport handlers may not follow the same format, but they MUST be globally unique.

Logging systems MUST be capable of storing, displaying and being queried on key message data fields and metadata which must include:

All STAR Transport Security Requirements can be supported by using SSL over HTTP as a secure channel Infrastructure. The SSL handshake requires that the Receiver pass a Digital Certificate to the Sender. The Sender can verify that the Receiver is a known party and that the Receivers Digital Certificate has been signed by a Trusted Party, such as a Certificate Authority. In this manner, a Sender may enable Business Authentication, Party Authentication, Target Authentication, System Authentication and or Unique Party Identification, depending on how the Sender defines and uses its own security policies.

Optionally, SSL can be used by the Receiver to require the Sender pass a Digital Certificate, allowing the Receiver to enable Business Authentication, Party Authentication, Source Authentication, System Authentication and or Unique Party Identification, again depending on how the Receiver defines and uses its own security policies.

SSL enables Privacy/Confidentiality. All SSL traffic is encrypted using dynamically generated symmetric keys, which are reasonably efficient and very secure.

A Virtual Private Network can provide the Infrastructure level security needed by STAR messages. Typically VPNs are implemented as proprietary software, where both the Sender and Receiver must install and maintain similar software or in some cases two parties may install and use two messaging software packages based on a common standard such as IPSec. There are a large variety of technologies and practices that are covered by the term VPN; the primary idea of a VPN is to provide a secure channel that allows messages to be transported in a safe “tunnel” that may be running over public networks or may utilize privately leased lines or communication systems.

A Secure Channel Infrastructure MAY be used to enable all STAR Security Features including Business Authentication, Party Authentication, Privacy / Confidentiality, Source and Target Authentication, Source Only Authentication, System Authentication and Unique Party Identification.

Infrastructure Level Security is equally applicable to STAR Web Services messages and STAR ebMS messages.

STAR RECOMMENDS Parties utilize either an Infrastructure-Level Security or Message-Level Security for a single message exchange.

Parties SHOULD NOT utilize both an Infrastructure-Level Security and Message-Level Security such that the security is duplicated or redundant across both layers.

It is strongly RECOMMENDED that Parties use SSL over HTTP.

Parties MAY utilize VPN technologies such as IPSec, if the two parties can agree to use the VPN in a manner that is as reasonably secure as SSL over HTTP.

Parties MAY exchange Digital Certificates out of band.

Parties MAY utilize self issued or self signed Digital Certificates if both partners agree to use them.

STAR RECOMMENDS the use of Digital Certificates for Infrastructure Level Authentication, but does not prohibit the use of Username/Password.

STAR Message-Level Security can be defined as information carried in the message itself, which enables Privacy Identification and Authentication.

Message senders in upstream automotive typically assume one of three key roles; Dealership or Dealership Management System, Intermediary and OEM. STAR Transport does not prescribe how a receiver should view these business relationships. The Guidelines do describe a limited set of Security technologies and methods to be applied directly to a message in transit. In other words, STAR defines Identity and Authentication mechanics to enable a sender to authorize a transaction, but STAR does not prescribe how the message receiver actually decides whether a sender is authorized or not to execute a service or query for information.

A receiver must identify a sender based on:

OR

A receiver must authenticate a sender based on:

STAR currently allows for two types of security tokens - Digital Certificates & Username/Password.

STAR does not take into account security data located in the SOAP body or BOD payload of a message, all Message-Level security data is contained within SOAP Message Headers.

STAR Messages MAY be Digitally Signed using Digital Certificates as a basis of the signature. STAR recommends that Digital Certificates not be passed in the message itself. If present in a message, a Digital Certificate MUST be protected through Data Encryption. If the parties agree, a reference to a known certificate, such as a Distinguished Name, MAY be passed in a message.

By signing a message, the sender is making the statement "I am the subject represented by the Digital Certificate and this is a message from me". In other words, the sender's Identity can be determined by the fact the sender holds the private key associated with a specific Digital Certificate and the sender has digitally signed the message using that private key. STAR allows for the use of self-signed certificates. The use of self-signed certificates provides adequate security in most use cases in which STAR transactions will occur. If a trading partner needs added security above and beyond the security provided by self-signed certificates, they may use a 3^rd party root CA. Using a root CA can provide an added level of assurance that the party is who they say they are, but at significant cost to the trading partners involved.

STAR Messages MAY include a Username in the SOAP Message Headers. If present, a Username / Password combination MUST be used to Authenticate the message sender.

Senders MUST take steps to ensure the protection of passwords. If a Password is sent in the message, it MUST be obfuscated using data encryption or some other method that makes the Password unreadable to any party other than the intended recipient. If Password is not obfuscated at the message level, it must be encrypted at the Transfer Infrastructure-Level using SSL.

If the two parties agree, a hash of the Password MAY be passed in place of the Password itself.

Parts of STAR messages MAY be encrypted using XMLEncryption. Typically, a sender uses the Public Key of the receiver (based on the receivers Digital Certificate) to generate an encrypted Symmetric Key that is then used to encrypt parts of the message. When received, the receiver processes the message, which uses its Private Key to decrypt the Symmetric Key, and uses the Symmetric key to decrypt the message.

Within the message Header elements, WS-Security 2004 elements MAY be used to help a receiver determine what parts of the message are encrypted.

System, Source and Target Authentication are commonly associated with Transfer Infrastructure-Level security. Typically, HTTP/S is used in conjunction with infrastructure components such as Firewalls and LDAP Directories to establish the Identity of the Systems involved in messaging. STAR does not prescribe any methods for these features at the Message-Level. Implementations of these features are discussed in detail under Infrastructure-Level Security.

It is OPTIONAL for a specific STAR ebMS message exchange to use Digital Signature, but if a Digital Signature is applied to a message the signature MUST be in full compliance with [XMLDSIG] and [ebMS version 2.0].

ebMS version 2.0 is very specific about how to apply Digital Signatures. Though multiple signatures are allowed, only the first signature is defined. The first signature is a signature over the SOAP Envelope (excluding the Signature elements themselves) and over all Attachments. ebMS requires specific algorithms for canonicalization and transformation of the SOAP Envelope. In other words, the sender creates a digital signature over the SOAP Envelope and all payloads.

A receiver MAY make use of ebXML CPA to associate a Digital Certificate with a sender.

ebMS allows optional encryption of parts of a message. ebMS does not restrict the method/technology used for encryption, but RECOMMENDS the use of [XMLEncryption]. STAR Transport RECOMMENDS the use of [XMLEncryption] or [SMIME] based encryption for ebMS Messages.

STAR Web Services provides five options for Identification and Authentication of a message sender at the Message-Level:

Digital Signatures applied to a message MUST be in full compliance with [XMLDSIG], [WS-Security 2004 2004] and [WS-Security 2004Addendum]. STAR RECOMMENDS that digital certificates are the basis for signature and that passwords should not be used as the basis for digital signature.

STAR does not define how a message receiver authorizes a Username / Password. If a Username / Password combination is employed, the message MUST be compliant to [WS-Security 2004]. This option is fully described in [WS-Security 2004], in this option the Password is not sent as a part of the message, instead a hash of the password is calculated from:

STAR Web Services Messages may contain Clear-text Username / Passwords if they are transported over HTTPS. In this option, SSL is providing encryption of all data in transit.

Username / Password Encrypted out-of-band Digital Certificates

In this option, the Username is sent as clear-text and password is sent encrypted in accordance with XMLEncryption and [WS-Security 2004]. The digital certificate required to encrypt the Password is exchanged out-of-band between the receiver and the sender. The sender encrypts the Password using the Receiver's public key as the basis of encryption. The receiver decrypts the password using its private key.

In this option, the parties agree to the format of a binary token that serves as a shared secret, this token is exchanged out-of-band between the parties, and is used as the basis for encryption and decryption of the message.

Beginning in 2007 STAR will support SAML as an approved message-level security protocol for  the STAR Web Service.  SAML is an XML-based framework for communicating security and identity information between computing entities. SAML promotes interoperability between disparate security systems by providing a common language and semantics for exchanging security details.

There are currently several versions of SAML in wide use and security appliance vendors may support some versions of SAML but not others.  The STAR Web Service implementation of SAML has been designed to be version-neutral to allow for maximum flexibility for those members wishing to implement it.

For detailed SAML implementation information, please refer to the 2007 edition of the STAR Web Services Specifications document.

It is OPTIONAL for a specific message exchange to be encrypted, but if encryption is applied to a message the message format MUST be in full compliance with [XMLEncryption], [WS-Security 2004].

There are more than twenty unique partner-to-partner interactions defined for transporting requests and responses between dealers, manufacturers, an RSP, and 3rd parties. In order to communicate as STAR members, each partner’s Internet connection must allow it to connect to a partner system with the following capabilities:

A key requirement is for a wide range of solutions be supported regardless of the Internet connection. These solutions must range from a low cost, low footprint solution that will provide small dealerships with the necessary connectivity to a large scale solution that can scale for performance and capacity of a large automotive manufacturer. However, in all cases they must:

STAR standards selections are expected to help foster competitiveness and innovation in the industry and lead to better quality and less expensive solutions for the automotive industry as a whole. The STAR requirements that help drive competitiveness and lower cost are:

Based on the described requirements and the set of partner-to-partner interactions that have been defined, a set of Internet connectivity types have been defined. These make up the core set necessary for all types of STAR organizations to interact over the Internet. The three unique Internet connectivity groupings provide flexible, cost effective alternatives for STAR organizations to select; a large OEM and a mom and pop type dealership have different requirements and need options in how they connect to the Internet. These three classifications provide the necessary Internet connectivity solutions for all types of STAR members while maintaining the ability to provide reliable, secure, interoperable STAR messaging solutions. These Internet connectivity usage patterns are as follows:

These three Internet connectivity solutions satisfy all of the twenty-two messaging interactions and provide the flexibility and range to support the cost and capability needs for all STAR organizations.

This type of Internet connectivity provides a service level required by an OEM or large messaging concentration point for aggregating multiple messaging connections. The following details describe the minimum Internet connection expectations of the Addressable Hub:

This type of Internet connectivity provides a service level required by a large dealer or fully functional business-to-business endpoint. The following details describe the minimum Internet connection expectations of the Addressable Endpoint:

This type of Internet connectivity provides a service level required for a minimal cost and smallest footprint solution while still providing a reliable, secure messaging endpoint. This endpoint differs in two key areas, it does not require a static public DNS name and it allows for disconnected Internet access. The following details describe the minimum Internet connection expectations of the Non-Addressable Endpoint:

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.

STAR participants are encouraged to apply the same care and management to endpoint gateways and their related services as they perform for their current application architectures. Existing administration facilities should be extended to allow for the predictable and reliable starting and stopping of endpoint gateways. Data stores that persist messages or maintain configuration parameters should be built on infrastructure that are reliable and allow for recovery after system failure. Data Stores should be backed up on an ongoing basis in a manner that participants would normally apply to critical business data.

STAR participants are encouraged to develop or extend monitoring and diagnostic tools that can watch and analyze message traffic received and sent through an endpoint gateway. These tools might include such facilities as application level firewalls, network monitors, applications that monitor logs for errors, or event based monitors that listen for errors and warnings raised by the endpoint gateway.

STAR is requiring consistent and synchronized schemes for management of System Time and Timestamp data elements. This support is beneficial in many ways but more importantly, it provides consistency to ReliableMessaging features and allows for future implementation of trusted timestamps and timestamped digital signatures.

STAR requires transport systems to provide a logging capability and recommends logging all message traffic in a manner that supports activity monitoring including, but not limited to, performance monitoring and security monitoring.

STAR Transport strongly recommends that transport systems architectures allow for manual and or automated status requests. In other words, the system should be able to display the status of message based upon the MessageID.

Management of industry wide security tokens is a complex discussion ongoing within STAR Transport committees. STAR anticipates future releases of this guideline will define and make recommendations on the creation and management of binary security tokens that provide for Identity, Authentication and Privacy.

In this release STAR Transport has focused on recommending technologies that can support binary security tokens including Digital Certificates and Username/Password combinations. Field experience with the simple use of these tokens will help STAR define the requirements for management models that may include Certificate Authorities and or Federated authentication systems.

The ebMS Ping/Pong services enable one EndPoint Gateway (which ebMS refers to as a Message Service Handler) to determine if another EndPoint Gateway is operating. A sending gateway would send a Ping message to a receiving gateway which replies with a Pong. The Ping and Pong message formats are clearly defined in the ebMS 2 specification and are composed of the typical ebMS message format with no payloads and a required Service element value of “urn:oasis:names:tc:ebxml-msg:service” and a required Action element value of “Ping” or “Pong” as appropriate.

Recipients of a Ping MAY ignore the message if they determine the sender is unauthorized or that the message is part of a denial of service attack.

Parties should digitally sign Ping and Pong messages to minimize the security risks. If a Ping message is sent with a ds:Signature, the receiving party can authenticate the sending party. If the responding Pong message is sent with a Signature, the originating gateway can authenticate the original receiver. This will establish an important layer of security in implementing Ping/Pong services. If the signature verification fails on the receipt of a Ping message, the receiving gateway should not generate a pong response.

Network Time Protocol is a widely used internet standard mechanism for synchronizing computer clocks. NTP clients poll NTP servers, which are connected to precise UTC time sources via radio, satellite or other means. The net effect is that a client computer system can maintain its own system clock with milliseconds or fractions of milliseconds of UTC time, enabling networks of computers to have their internal clocks precisely synchronized.

UTC (Coordinated Universal Time) is a widely used mechanism that can be leveraged to express precise values of time a manner that makes it easy to avoid issues with changes in time zones.

UTC is the successor to what used to be generally referred to as Greenwich Mean Time and is often referred to as Zulu time. By combing XML Schema datetime elements with UTC, STAR parties can enable consistent and precise timestamps that do not suffer from time zone issues. For example a sender timestamp can always be interpreted correctly, as there is no need for the receiver to understand which time zone and or daylight savings times the sending system is subject to.

Logging all messages provides a reliable record of message traffic between two parties. Diagnostic research for issues such as lost messages, performance problems, or transmission problems is greatly improved with a message log. Logging all messages may be the only way that a single lost message can be tracked down. Logging may also be switched off or on as necessary to assist in debugging transport or message implementations.

Since the Transport layer is only concerned with message traffic, the log entries SHOULD contain information about the transfer, such as message ID, sender, receiver, timestamp of transmission and receipt, type of message, and sender network ID. Additional information may be maintained, but this is a minimum set of useful information. Message logs may be exchanged through out-of-band means such as email or FTP.

There is a concern that logging messages comes at a cost of storage and processing that depends on the retention of the logs. For example, 50 messages a day from 1000 dealers would generate 50,000 messages; if each message log entry is 200 bytes then the log will grow by 10MB each day. The storage requirements for a week’s messages would be about 50MB, for a month’s messages, 200MB. An automated system for archiving, deleting or rotating logs is necessary to manage storage of logs with continuous logging. Some parties may turn off logging to avoid consuming storage. There are no recommendations or requirements regarding the retention of logs for management purposes.

To insure that log information can be obtained, all parties MUST be able to capture and provide logging upon request. There are significant benefits to have logging always turned on, but STAR will NOT REQUIRE continuous logging.

STAR Transport STRONGLY RECOMMENDS that reasonable and prudent Administration, Monitoring and Diagnostic measures be applied to EndPoint Gateways involved in STAR messaging.

STAR Transport STRONGLY RECOMMENDS the use of NTP for all participating systems. Use of Simple NTP (SNTP) is allowed. Public NTP servers MUST meet the NIST Time and Frequency Services standard. (Ref http://pool.ntp.org)

STAR Transport REQUIRES that all Timestamp data elements used at the Transport level (which includes all SOAP Header elements) MUST use XML Schema datetime format with values that are UTC codes.

Implementations of ebMS SHOULD support Ping/Pong. It is strongly RECOMMENDED that Ping/Pong messages are digitally signed. Receivers SHOULD reply to a Ping with Pong unless the message sender cannot be authenticated or the message is determined to be part of a denial of service attack. With ebMS over SMTP, however, the ping/pong latency may be longer than is useful.

Web Services Management is an area that is evolving as more real world Web Services implementations are being rolled out. A key distinction to be aware of is the difference between how you manage Web Services versus using Web Services to manage systems in a manner similar to SNMP.

There are several proposals and individual vendors promoting management of Web Services. The OASIS Web Services Distributed Management technical committee is an effort to define standards in this area. The WSDM is working on both Management of Web Services and Management Using Web Services.

STAR will follow progress in this area and may make recommendations in future releases of this guideline.

STAR systems MUST be able to log message metadata and key fields as described in Auditing Decisions section. STAR RECOMMENDS that this logging is done for all messages, but may only be used when needed to gather debugging information.

The STAR checklists are a tool that can be used to assess your implementations of the STAR Transport Guidelines. There are three checklists: