| Standards for Technology in Automotive Retail |
| Home - News Feed

2.2. Message Packaging
Prev | Chapter 2. Common Components | Next

## 2.2. Message Packaging

The STAR Web Services transport was designed to provide a platform for secure and reliable delivery of any type of content in a standardized manner. The chosen architecture neither precludes nor requires attachments outside the body of the SOAP message for transportation of content. The chosen packaging methodology is well supported by all major Web Services toolkits and infrastructures and meets STAR's transport requirements.

The STAR Payload schema defines a package structure that provides additional features such as a standard way of packaging multiple contents (STAR BODs, XML documents, binary data, etc) in one payload and a message manifest that describes the contents of a message The figure below shows the structure of a valid STAR Web Services message

The first element under the SOAP:Body is the web method name. Three methods are defined: ProcessMessage, PutMessage, and PullMessage. Within the method element is the payload element, the primary element that encapsulates all transported payloads. The payload element contains one or more content elements, each of which encapsulates one and only one content element, such as a STAR BOD. The payload and content elements provide a standard format for transporting one or more XML documents inside the SOAP Body.

Figure 2.1. Message Structure

Figure 2.2. Manifest

In the SOAP:Header, STAR defines a payloadManifest element, which contains one or more manifest elements. Each manifest element corresponds to one content element in the SOAP Body and describes its contents. The payloadManifest and manifest elements provide a table of contents for the message.

The following a sample shows the structure of the STAR Web Services message, including the location of the payloadManifest, and the star payload elements.

Example 2.1. Sample STAR Web Service Message

### 2.2.1. Notes Regarding Payloads and Attachments

The decision was made to avoid dependency on Attachments. The currently defined interface specification neither requires nor prohibits attachments.While the overall message structure may not need to change, additional attributes or elements may need to be added to support the evolving web services attachments specifications in the future.

Prev | Up | Next
Chapter 2. Common Components | Home | 2.3. Namespaces