STAR has chosen to specify two Transport Methods based on two similar but different industry specifications:

This dual specification approach offers a significantly less complex landscape for moving data documents among automotive manufacturers, dealership management systems, and Retail Service Providers (RSP) than the current situation.

Previously, manufacturers use privately-owned satellite systems, leased satellite services, VPN technologies, private telecommunications and networks, proprietary protocols across the Internet, and dialup connections. This complex landscape of technologies was used to normally move flat-files or DTS files between automotive trading retail partners.

However, the emergence of several Web services specifications from the W3C and OASIS are based on a different model for document transfer. This has allowed several STAR members to identify a model for transport that addressed development and deployment issues they had with ebXML. At the same time, the requirements for transporting STAR BODs were revised to more accurately reflect the needs of the STAR community.

These changes in the industry gave STAR members a choice between a growing and stable standard in ebXML Message Services and a set of emerging Web services specifications from the W3C and OASIS that provided desirable deployment alternatives. Over time, this dichotomy in transport standards may resolve itself in the marketplace, but STAR Architecture Working Group (WG) determined current value by being able to reduce the wide variety of proprietary transport approaches into two industry-leading message transport models.

The STAR Architecture Working Group also identified messaging requirements that are not covered or are not described completely enough by ebMS or Web services. These requirements led to the development of conventions or specifications beyond the specifications in their current form. One example of this is Compression another is the elaboration of handling non-addressable end-points.

ebMS version 2.0 is a recent update to a relatively mature standard with significant and growing global interest and some production implementations. ebMS fits well with up-stream automotive requirements; it provides a clear prescription for secure and reliable document based business to business messaging. ebMS is flexible in the type of data payloads it carries. Though STAR's focus is on BODs, STAR members could use ebMS to move digital content of any type. There are dozens of software vendors who support ebMS version 2.0. The designers of ebMS focused on the business-to-business problem space and coined the concept of a Message Handler, a gateway that is responsible for message Transport within each business partner's infrastructure. ebMS architecture provides sophisticated and broad functionality in a single specification which is most appropriate for larger companies who can enable 24/7 services and who have the needs and abilities to deploy advanced messaging features.

ebMS clearly defines many sophisticated features that map directly to STAR Requirements, as a result the STAR Transport Working Group can recommend ebMS conformant applications, and include only minor further recommendations in the form of a profile for using ebMS as a STAR Standard Transport Method. In accordance with the ebMS specification, a conformant ebMS application must support all Core features and if an application supports any additional ebMS features, it must support all the requirements of that feature.

To be compliant with the STAR ebMS Profile, implementations MUST be conformant to ebMS version 2.0 and follow the STAR ebMS Standards and Recommendations described below in this document. Conformance to ebMS version 2.0 means that an implementation supports all ebMS Core features and if any ebMS Additional features are supported, then all requirements associated with that feature are supported.

A recommendation for transport based on Web Services specifications has also been adopted for the guidelines. Abstractly, in this context, a web service is a piece of business functionality that can be invoked easily over the Internet and a set of industry specifications have been developed and released from various sources to address the interoperability of such Web Services. The software industry has demonstrated an enormous amount of interest and support for the core Web Services standards SOAP and WSDL. Practically every software vendor has support, or is planning support for SOAP. Many SOAP implementations are in production as part of integrated, loosely-coupled systems.

Several Web Services specifications have been created and proposed that rely on the core standards of SOAP, and WSDL; these specifications we loosely refer to as WS-*. The designers of these various Web Services specifications have a wider focus than document-based, business-to-business messaging and include additional key concepts such as Remote Procedure Calls and internal application integration often referred to as EAI (Enterprise Application Integration). Since SOAP, and WSDL can be implemented with light weight infrastructures and WS-* specifications can be selected as needed, the implementation of WS-* specifications can be scaled downward and functionality selectively reduced to be appropriate for many scenarios involving intermittently connected dealership systems.

Many specific Web Services standards fit well with up-stream community requirements. The STAR Web Services Guideline recommendation is clear on exactly what WS-* specifications are in scope, which features of the specifications are relevant and how the recommendations fit together to describe methods for packaging and transporting secure and reliable business to business messages.

To be compliant with the STAR Web Services Profile, implementations MUST be compliant to WS-I Basic Profile and MUST support all Standards and Recommendations as described below. The STAR Web Service Profile is based on:

3.1.1. STAR ebMS Stack

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

3.1.2. STAR Webservices 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