Messaging Functions

The ebXML specifications describe in detail the structure of messages sent among trading partners, as well as the routing and transport mechanisms. These specifications are fundamental to any business dataexchange framework, since they define basic interconnectivity ”the ability to send and receive messages with trading partners, or between trading partners and registries. These messaging specifications were also the first ebXML draft technical documents developed and subjected to several proof-of-concept tests.[14]

Business messages need to be secure and reliable. As a result, ebXML messages include security components and allow for exchange over common leading Internet protocols:[15]

• Hypertext Transport Protocol (HTTP) and Secure Hypertext Transport Protocol (HTTP/S), used on the web

• Simple Mail Transport Protocol (SMTP), used with email

Messaging Specifications

The messaging specifications outline the basic functions for transferring documents among e-business services that comply with ebXML. The specifications enable trading partners to use existing communications methods , and allow for reliable delivery, security, persistence, and extensibility as spelled out in the requirements described earlier. To meet these requirements, ebXML adopted the Simple Object Access Protocol ( SOAP ), an XML messaging vocabulary used in several other leading web services. The specific version of SOAP used by ebXML allows for attachments, and thus has the name SOAP with Attachments. [16]

ebXML Message Package

ebXML messages are carried in a package defined by SOAP using the Multipurpose Internet Mail Extensions (MIME) protocol as well as XML documents. The Internet Engineering Task Force developed MIME as a packaging protocol for email, but because of its ability to carry messages with different kinds of file formats, it has been increasingly used with web-based transfers over HTTP. MIME not only offers a way of transporting messages in multiple formats, but also can carry encrypted content.

The ability of two or more parties to communicate in a distributed network using XML has become one of the hot topics in the XML community, and one from which we will hear much more. The W3C has established a separate XML protocol activity and working group to address these issues.[17]

Figure 2.10 shows the components of the ebXML/ SOAP message package.[18] The communications protocol, such as HTTP over the web or SMTP with email, provides the outer layer of the package. Then the outer SOAP envelope uses MIME, as do the two main parts of the message ”headers and payload ”to specify message length and formatting details. XML message headers inside the SOAP-based envelope provide the addressing and management information, while the payload has the business content of the message ”the whole reason for the message.

Figure 2.10. ebXML message components and structure.

Here's where the terminology gets a little tricky. The basic SOAP message in this package has the ebXML message headers. In Figure 2.10, the SOAP envelope with the SOAP message has two parts, what SOAP calls its Header and Body, although for ebXML it's all considered just part of the message headers. The ebXML message payloads (messages can have more than one payload) reside in the attachment part of the message. Payloads can be in any digitized format, which allows for attaching content such as patient X-rays or engineering drawings as well as simple XML-based payloads.

The ebXML message headers are defined by ebXML and supplement the SOAP specifications. The headers identify the message sender and receiver, provide date/time stamps for logging, prescribe routing if required, cite reference documents (such as collaboration protocol agreements), include digital signatures or other security objects, list the contents of the payloads in a manifest, and indicate whether the message is acknowledging a previous message.[19]

Reliable Message Flow

As noted earlier, ebXML emphasizes the need for reliable messaging service. The specifications define reliable messaging as having the following characteristics:

• For any given message generated by the sender, the receiving message service will deliver at most one copy to the receiver.

• The receiving message service will send an acknowledgment to the sending service, to indicate receipt and persistent storage of the message. The sending message service will also notify the sender if it doesn't receive this acknowledgment.

• Both the sender and receiving message services will use persistent storage for recovery.

The acknowledgment and persistent storage help improve the reliability of delivery. The ebXML header document has an attribute that indicates whether the message is a normal data transfer, an acknowledgment, or an error message. Acknowledgments also are sparse and simple; they contain no business payload, service interface, or action data in the header. They must contain the reference to the original message identifier, however.

The persistent storage feature holds the message by the sending message service, even before sending the message. The receiving message service likewise holds a copy of the message in persistent storage, in case it's needed for recovery. Once the appropriate acknowledgments are received and the need for recovery has passed, the respective messaging services can remove the message from persistent storage.[20]