The routing problem can be described in a postal service metaphor representing the messaging architectures in use today. A document is destined for a particular individual in an office building. The document is packaged in an envelope. There are different methods in use to get the document to the individual:

The first relates to advanced architectures where the routing information is carried in standard routing elements in the message header and can be routed to the destination for consumption without opening the message. These technologies are not yet ubiquitous. Therefore, some support is often necessary for the second method.

The second method requires that a process take the message from the transport end point and open it to determine what service will consume the message. STAR has defined routing elements, outlined below, that can be used to contain the routing information.

In both cases, some routing of the message to its destination is required once the transport end point has received the message. This process is often referred to as message brokering.

STAR proposes no standard message brokers and, other than the goals of using the standard routing elements, there are no standard requirements for message brokers. However, it is important to make the distinction that message brokers act on messages after the transport end point has received them.

Identifying Destinations in the Automotive Industry

Currently, most OEM's communicate with their dealers identifying them with a numeric dealer code. This accommodates the OEM but presents message routing problems for the applications and components within the dealership's architecture.

In traditional dealer to OEM communication, a central OEM site typically receives all transactions from the dealer and relies on transaction type data to route transactions to appropriate destinations. This model has served well for the traditional store and forward, batch-oriented architectures.

As OEM and RSP begin to deploy updated technology, these models become less effective as the dealer code, even if OEM code is added, does not provide enough granularity for communicating to applications.

Other problems develop when more than one dealership is operated by the same entity. In these cases, the dealers may share computing resources. This presents increasingly complex use cases for sending transactions, receiving acknowledgements, as well as delivering goods based on the content of the transactions.

STAR has documented a common set of requirements and routing elements that can be used by the community to target components, services, applications, and infrastructure.

Message Handling and Addressing

There are two message handling components in the infrastructure: transport and message brokers. Transport message handlers are the physical end points. Message brokers are the components between the application that creates or receives the message and the transport end point.

Figure 1.1. System Migration

Not shown above is that the destination message handler may have several physical locations or services that it must route the message to.

The layer between application and transport is often blurry as some transport message handler implementations can perform some of the functions of message brokering.

Addressing Elements

There are a variety of implementations of message handling components in production or design. Advanced architectures can use routing information in the message headers. To facilitate architectures that do not pass routing information on message headers, addressing elements have been added to the BOD and DTS definitions.

The following elements are used in both the Sender and Destination components in the BOD Application Area. Destinations can use the Sender elements as a return address. These elements also exist on the Identification Record of the DTS.

Party Id

The Party Id field can be used as the unique identifier of the Sender or Receiver of the message. This element would be used for parties within the community as well as external parties. Party Id is not intended as a replacement for the Dealer Number.

Location Id

The Location Id field can be used to uniquely identify the location of the Sender or Receiver of a message. This element can be aligned with a physical address. Location Id can provide an additional level of granularity beyond the usage of the Party Id for additional routing and delivery of data.

Service Id

The Service Id field can be used to identify the particular service to which a message is being sent to or sent from. Through the use of a logical name versus hard-coded application names, these can be easily changed or redefined within an organization, without impacting applications at either end.