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.