Standards for Technology in Automotive Retail
| Standards for Technology in Automotive Retail | |
Section three details how to take manage your network for optimal performance and functionality.
Chapter 9, Internet Connectivity
An Internet connection is an essential infrastructure requirement to support the Transport Methods describe in this document. STAR supports three levels of internet connectivity implementation patterns to accommodate varying needs and cost factors. The chapter addresses in detail the unique characteristics and minimum requirements of each application.
From the highest service level to the basic functionality to be STAR compliant the Internet Connectivity Solutions are:
Addressable Hub – Level required by an OEM or large messaging center
Addressable Endpoint – Level required for business to business needs
Non-Addressable Endpoint – Lowest level that maintains the capability of a reliable secure messaging endpoint
Selection of an Internet Connectivity mechanism depends on the needs of the complete set of the involved trading partners. STAR has identified the minimum requirements that all internet connection should have to successfully interact with business partners; including:
The capacity to exchange business messages between users over standard Internet transport Protocols (TCP/IP HTTP/S and optionally SMTP/S) in a secure, consistent reliable manner
The ability to pass messages synchronously and asynchronously
A messaging solution that supports connected and disconnected modes of operation, addressable and non-addressable endpoints, and; client initiated and bi-directional messaging
STAR supports open standards based messaging solutions. The following implementation requirements increase quality and lower cost across the automotive industry:
The implementations should be supported on multiple platforms, operating systems, using multiple component models and languages.
Node implementation of each should not be bound to proprietary specifications or
products
Solutions should protect the automotive industry from the potential of proprietary dependencies such as vendor lock in, or “Internet messaging tolls”.
The solutions define a full stack of cross-vendor B2B Interoperability among participants.
STAR message exchanges take place across the automotive industry using different architectures and diverse software packages. Because of this, management requirements are necessary to ensure that reasonable and carefully considered Administration, Monitoring and Diagnostic measures are applied to EndPoint Gateways involved in STAR messaging.
SNMP (simple network management protocol) has been applied to monitoring hardware and network devices for years. The OASIS Web Services Distributed Management Technical Committee is in the process of developing standards regarding management of software/hardware via Web Services and management of Web Services in general. However, these standards are still in the beginning stages.
ebMS provides a Ping/Pong feature that can be used to monitor status of remote partner endpoint gateways and allows an end point to determine the availability of a partner’s web service. It is strongly recommended that Ping/Pong messages are digitally signed. In depth analysis of this feature can be found in the chapter and also in the ebMS Implementation Guidelines.
Below are recommended management requirements for STAR messaging:
Administration: Administration facilities should have predictable and reliable starting and stopping of endpoint gateways. Also, back-up and recovery systems should be applied on an ongoing basis to ensure that messages and other critical data are preserved.
Monitoring and Diagnostics: STAR encourages the use of monitoring and diagnostic tools that can analyze sent and received message traffic through an endpoint gateway. Monitoring and Diagnostic Devices include 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.
Synchronized System Time and Consistent Timestamps: STAR Transport requires that all Timestamp data elements used at the Transport level (which includes all SOAP Header elements) must use xmlschema datetime format with values that are UTC (Universal Coordinated Time) codes. The use of NTP (Network Time Protocol) is also strongly recommended. These formats enable Reliable Messaging features and allow implementation of trusted timestamps and digital signatures.
Message Logging: STAR requires transport systems to provide logging capability and recommends logging all message traffic in a manner that supports activity, performance and security monitoring. The log entries should contain information about the transfer, including message ID, sender, receiver, timestamp of transmission and receipt, type of message, and sender network ID.
Message Status: STAR Transport strongly recommends that transport systems architectures allow for manual and or automated status requests. The system should be able to display the status of message based upon the MessageID Discussions.
Security Tokens: STAR recommends technologies that can support binary security tokens including Digital Certificates and Username/Password combinations.
Registries make Service Descriptions available to other businesses partners and/or the public which accelerates the development of production data exchanges.
The STAR registry standard is UDDI (Universal Description, Discovery and Integration). It was chosen because UDDI is required by the WS-I Basic Profile and it supports STAR’s registry requirements which are:
Non-proprietary Discovery standards
Service Transparency
Location Transparency
Capacity to manage multiple versions of services, including versions that are backward compatible, non-compatible and changes that have occurred beneath the public interface.
The STAR Web Services Specification includes a detailed discussion on implementing these features under UDDI in the section entitled UDDI and Versioning.
Other recommended registry features are CPPA to accelerate trading partner integration and Digital Certificates to enable Digital Signature.
Currently, the only public registry is UBR (Universal Business Registry) A key benefit of the UBR is that it has special versions of UDDI registries that provide platforms to test UDDI prototypes before moving it to production.
UBR registries may be used to host STAR production Service Descriptions. However, all information posted in the UBR should be considered public and, therefore, appropriate care should be taken to secure web services against unauthorized access or other types of security risks before publishing access point URLs.
In the future, STAR may consider hosting a Registry/Repository that includes the following features to support the upstream automotive community:
Physical process of registering a Dealer, RSP, OEM with the Registry.
Processes
Business Types - Dealer, OEM, RSP, STAR
Service Types – STAR BODs, etc
Chapter 12, STAR Transport Testing
STAR does not conduct or sponsor interoperability testing. Compliance with the STAR Transport Guidelines is voluntary and performed by the development teams of individual companies. However, STAR does believe that making testing results available to business partners will benefit the automotive industry as whole by reducing cost and making interactions more compatible and predictable.
The Transport Guidelines team has created a set of conformance checklists to facilitate self testing and a repository to post testing results. The checklist can be found at the back of the chapter. Descriptions are below:
The Transport Guidelines checklist captures the general requirements that are applicable to both ebXML and Web services implementations. The requirements are taken from the STAR Transport Guidelines document.
The STAR ebMS Guidelines Checklist is a collection of requirements from the STAR ebMS Guidelines document and applies to transport implementations that utilize ebXML Messaging Specification.
The STAR Web Services Specification Testing Checklist is a collection of requirements taken from the STAR Web Services Specifications that applies to implementations that use Web services-based products.
Completed checklists should be dated and submitted to STAR. Submitting test results is also voluntary and will be made available only to STAR members.
