Message Services | ebXML: The New Global Standard for Doing Business on the Internet

The ebXML message services make it possible to exchange electronic business documents between trading partners , using any standard communications protocols, such as HTTP over the web or SMTP with Internet email. ebXML developed these transport, routing, and packaging functions earlier than the other parts of the technology, and as a result they are probably the most stable parts of the architecture. All of the ebXML proof-of-concept tests have demonstrated the draft messaging specifications, so they have gone through several iterations of testing.

The ebXML message format relies largely on the Simple Object Access Protocol (SOAP) specification. SOAP is an initiative started by four companies ” Microsoft, IBM, DevelopMentor, and Userland Software ”and later adopted by many more. It presents a simple XML-based message package, offers encoding guidelines for data used in applications connected by these messages, and provides rules for representing remote procedure calls (RPCs), a type of online interaction in a distributed environment. The authors submitted version 1.1 of SOAP to the W3C as a Note in May 2000.

At first, ebXML defined its own message format. When SOAP enhanced its specifications to include a version with attachments using a packaging scheme based on Multipurpose Internet Mail Extensions (MIME), a standard of the Internet Engineering Task Force, ebXML found it could use SOAP instead of its own format.With MIME packaging, SOAP (and ebXML) can send non-XML binary payloads, such as digitized graphics files, making the format more usable for business purposes.[54]

ebXML message services offer several key functions to exchange business messages between trading partners:

Message header processing. Message headers provide the end-point address for the message, as well as routing information, a description of the contents, security information, and other important details about delivery. Creation of these headers by message senders draws data from the end- user application, collaboration protocol agreements (CPAs), and digital signatures, among other sources.
Message header parsing. On the receiving end, the message service handler extracts or transforms the data in the headers for processing.
Security services. These services include creation and interpretation of digital signatures, as well as authentication of the parties and authorization for further access.
Reliable messaging. ebXML defines reliable delivery of messages with rules for persistence, retries, error messages, and acknowledgments.
Packaging. This function includes the envelopes for the message as a whole, as well as dividing the message into containers for headers and payloads.
Error handling. When the message service handler or user application encounters an error, this function reports the error to the parties.
Message service interface. This function connects the user applications to the message service handler.[55]

Message Package

Business messages of any kind, whether postal mail, faxes, telegrams and telexes,[56] email, or over the web, have some characteristics in common. For example, they all have addresses formatted to enable accurate delivery of the message, routing instructions, and dates and times for logging or verification (for example, postmarks on postal mail). These data items, designed to help manage the flow of message traffic, are often grouped together at the top or head of the message (or on an outside envelope), and thus have the name headers. This separation of headers from the body or payload of the message ”the business stuff ”is a common feature of business messages, including SOAP and ebXML messages.

To cover the situation where a message has an attachment, particularly one in a different digitized format from the message itself, first ebXML and then SOAP adopted the Multipurpose Internet Mail Extensions (MIME) packaging for its messages. MIME was originally designed by the Internet Engineering Task Force to transmit non-text files via email. A specific flavor of MIME, called the Multipart/ Related media type, allows for putting together multiple separate parts in a MIME package, which makes it applicable to the kinds of business messages envisioned for SOAP and ebXML.[57]

The basic SOAP message calls for an envelope with a header and a body enclosed . The enhancements to SOAP to allow for attachments wraps the SOAP envelope in one MIME part, and creates a separate MIME part for the message payload. Figure 8.9 shows the configuration of these pieces in an ebXML message.

Figure 8.9. Message structure: envelopes, headers, and body.

graphics/08fig09.gif

As Figure 8.9 illustrates, ebXML configures the message as a series of layers . The communications protocol for the message, such as HTTP over the web or SMTP for email, provides the outermost envelope. Everything within this first layer includes the message specifications as defined by ebXML.

A MIME envelope encompassing the total SOAP with Attachments package provides the next layer in the structure. Within this total package layer comes a set of two MIME containers, each with its own envelope, one for the ebXML message headers and another for the payloads.

ebXML leaves the definition or selection of message payloads to the discretion of the sender. A message can carry multiple payloads if necessary. They can be any digitized content, from simple text messages (such as XML documents) to complex configurations of nested objects. However the message's manifest, part of the headers (see the next section), must list each payload in the message.

The contents of a SOAP envelope, defined as an XML file, includes the overall ebXML message headers but is itself a complete basic SOAP (version 1.1) document, and has two parts corresponding to a SOAP header and body. As in most structured business messages, the headers contain important addressing, security, and management details, which ebXML divides between the SOAP header and body segments.[58]

ebXML Message Headers

The ebXML message has two groups of headers, divided between the SOAP header and body. The first group contained in the SOAP header has five XML elements, described in the following sections.

MessageHeader

This element, required in each ebXML message, has data on the basic identity of the parties and references for the message. Its child elements and attributes include the following:

From , To . As you might guess, these elements indicate the sender and receiver of the message and thus are required in each message. They each contain a PartyId element with a type of identifier (for example D-U-N-S or tax ID numbers ) agreed upon by both parties. The type of identifiers is itself identified as an attribute to PartyId and the specifications strongly recommend using a standard Internet resource, such as a web address, as the source of the identifiers.
CPAId . This required element references the appropriate documents or agreements that define the interactions between the parties, which can be an ebXML collaboration protocol agreement (CPA); see earlier discussions of CPAs.
ConversationId . A conversation is a set of related messages, such as a paired invoice and remittance advice, and this required element makes it possible to locate the current message in the context of the overall business process.
Service . This required element identifies the service within the receiving company that acts on the message. For example, the trading partners may agree to identify Accounts Payable as the service to process an invoice.
Action . Also required, this element specifies the type of activity or processing desired for the message, and must be understood by the service identified in the headers (see the preceding bullet). An invoice, for example, could have Electronic Payment specified as an action.
MessageData . This required element has a series of sub-elements providing for a unique message identifier, date/time stamp, reference to an earlier message ( RefToMessageId , required in error and acknowledgment messages), and deadline by which the receiving party needs to receive and process the message.
QualityOfServiceInfo . This element contains attributes for delivery semantics that indicate the need for reliable messaging (defined further below), request for a delivery receipt, and need to meet the precise order of delivery as specified by the sender.
SequenceNumber . With this element, the receiving party can process the messages in a specified order, unique within a specific ConversationId . The specifications provide detailed rules for numbering messages and using sequence numbers when requiring reliable messaging.
Description . This optional element provides a human-readable text explanation of the message's purpose or intent.
Version . This required attribute of the MessageHeader element refers to the version of the ebXML message service specifications to which the message must conform (1.0 at the time of this writing). This version number can change as ebXML updates the specifications.
mustUnderstand . This attribute of the MessageHeader element, provided by SOAP and required in ebXML messages, indicates that the receiving party must understand the contents of the MessageHeader element. In ebXML, this attribute must have a value of 1 , meaning True or Yes.[59]

TraceHeaderList Element

If a message needs multiple hops to go from the sending to the receiving party, the TraceHeaderList gives the order of those hops from one message service handler to the next. Each hop has a TraceHeader child element that gives the Internet address for the sender and receiver, a date/time stamp, and a wildcard element for extensibility. The message can omit the TraceHeaderList if it has only one hop. The element has the version and mustUnderstand attributes discussed earlier.[60]

Via Element

The Via element conveys data from the sender of the message to the next ebXML message service handler to receive the message. Like the TraceHeader , the Via element services multi-hop message traffic, but this element is more applicable to scenarios where the data varies from one hop to another. Like the TraceHeaderList , the Via element has version and the SOAP mustUnderstand attributes. It also has a SOAP actor attribute, which requires the next SOAP-compliant recipient to process the message and not forward it without processing.

This element has the sub-elements CPAId , Service , and Action described earlier. In this case, CPAId applies only to the exchange of messages between the message service handler addresses, and not the trading partners. The Via element has an attribute for a synchronous reply that requires a response if the communication protocol supports two-way ( Request/Response ) conversations. The element also has attributes to indicate reliable messaging methods ”ebXML's or from the transport protocol's method ”and the type of acknowledgment required.[61]

ErrorList Element

Messages should use this element to report errors in the previous message if noted in the RefToMessageId in the MessageHeader element. As the name implies, this part of the header provides a list of errors, detailed in one or more Error sub-elements. The Error sub-element has a series of attributes describing various properties of the error:

codeContext , giving a URI with the XML namespace or schema with the error codes.
errorCode , a list of predefined codes referring to the MIME or XML headers or the delivery of the message itself. The codes do not apply to the business content or payloads, where any error messages are dependent on the user applications operating the payloads.
severity , which indicates either a Warning or Error. Warnings mean that the problem is not so troublesome as to interrupt the flow of other messages in the conversation. An Error, on the other hand, indicates an unrecoverable problem, and no further messages will flow until resolved.
location , which tells where in the message ” except for the payload ”the error occurred. If the message is a well- formed XML document, the attribute uses the XML Pointer Language (XPointer) syntax to identify the location. For MIME errors, location indicates the contentid of the MIME part containing the error.
xml:lang , from the basic XML specifications, which gives the human language used for the text description of the error message.

The Error element can also give a text description of the error, although it's not required.[62]

Signature Element

Digital signatures verify the identity of the message senders and are an important factor in assuring the security of electronic business messages. While not required for ebXML messages, digital signatures are highly recommended. If the message header has more than one signature, the first signature must apply to the sender.

ebXML requires a namespace conforming to the XML Signature specification, a joint endeavor of the W3C and Internet Engineering Task Force. The specifications give detailed rules for the generation of signatures in ebXML messages.[63]

Manifest Element

The Manifest is the first element in the second part of the ebXML message headers contained in the SOAP body envelope (refer to Figure 8.9). This element describes the contents of the payloads, which makes it possible for the receivers to check the integrity of the contents, and can help the receivers extract the payload and determine whether they can process it before opening. ebXML requires a Manifest element if there is any data associated with the message but not in the header container. The most obvious data is found in the payload, but a Manifest is also required if the message references data elsewhere through an Internet address.

The key component in the Manifest is the Reference sub-element. Reference itself has sub-elements listing the schema from which the payload is defined, and a text description of the payload. The Schema sub-element gives the Internet address where it can be accessed and the version of the schema if needed. Reference also has an optional wildcard sub-element to provide extensibility.

Reference also has a series of attributes based on the XML Linking Language (XLink) that link the manifest to the Internet addresses of the payload object (required) and resources that describe the payload object.[64]

StatusResponse Element

This element, also among the second group of message headers, reports on the processing status of messages sent previously. It contains sub-elements with a reference to the previous message, a date/time stamp, and attributes for message status, as well as version and mustUnderstand attributes described earlier.

The messageStatus attribute indicates whether the target message service received the referenced message, or the message identifier was not recognized by the receiver. It can also tell if the status request is not authorized or accepted.[65]

DeliveryReceipt Element

Another element in the second group of headers tells the sender of a message that the target message service received the message. The MessageData element under MessageHeader has a RefToMessageId sub-element used for errors and acknowledgments, and in the case of acknowledgments identifies the previous message.

The DeliveryReceipt element has sub-elements indicating the sender of the acknowledgment and giving a date/time stamp. The element also has an attribute indicating the type of receipt, either a delivery receipt (the default) or an acknowledgment generated by a party other than the designated recipient. In this latter case, the acknowledgment gives an indication of processing by an intermediary or forwarder. The DeliveryReceipt also has an attribute noting whether it's digitally signed.[66]

The acknowledgment function provided by this element only tells the sender that the message got delivered to the receiving system. As in the case of EDI and other e-business messages, receipt implies neither an understanding of the message content nor a commitment to act on the message. One of the contributions of EDI is the pairing of action messages to provide a substantive business-level dialogue that goes well beyond simple acknowledgments. For example, as indicated in examples earlier in this book, ship notices can have corresponding receiving advice messages to show the shipper the items accepted into inventory by the recipient.

Message Handling Services

ebXML specifies two kinds of services to support business messaging: message status requests and message service handler pinging. Both sets of services use several of the header elements described earlier.

The message status requests and responses let a sender of a previous message know about the current state of the message. The status request message consists of the following:

MessageHeader (required) with From , To , RefToMessageId , Service , and Action sub-elements. The RefToMessageId refers to the original message.
TraceHeaderList element (optional).
Signature element (optional).
StatusRequest element (required).

The message status response has the following content:

MessageHeader (required) with From , To , RefToMessageId , Service , and Action sub-elements. In this case, the RefToMessageId refers to the message status request.
TraceHeaderList element (optional).
Acknowledgment element (optional).
StatusRequest element (required).
Signature element (optional).

The message service handler ping service determines whether another comparable service is in operation. The ping message consists of the following:

MessageHeader (required) with From , To , Service , and Action sub-elements. The Action in this case is Ping .
TraceHeaderList element (optional).
Signature element (optional).

The response to a message service handler ping is (of course) a pong that consists of the following:

MessageHeader (required) with From , To , RefToMessageId , Service , and Action sub-elements. In this case, the RefToMessageId refers to the ping and the Action is Pong .
TraceHeaderList element (optional).
Acknowledgment element (optional).
Signature element (optional).

Both sets of service messages have security implications. Recipients of status requests may ignore the request messages if they consider the senders unauthorized. Also, recipients of pings may ignore the messages if they believe the pings are a prelude to some kind of denial-of-service or comparable attack.[67]

Reliable Messaging

A key part of the message services as defined by ebXML is the concept of reliable messaging. One facet of ebXML reliable messaging is the storage of the message through its lifetime in a way that persists through any failure of system components . Another facet is delivery to the recipient once and only once.

The persistent storage requirement of reliable messaging recommends that parties configure their systems so the message data can survive a failure of any single equipment or software component. Also, in case of failure, messages still need to be processed as if the interruption never occurred. The specifications recommend that companies keep in persistent storage the complete message, as well as separate instances of the message identifiers and time of receipt.This maintenance of message data in persistent storage can reduce the occurrence of duplicate message receipts in case of interruption or failure.

Trading partners can choose to adopt reliable messaging as one of their protocols, either as part of the collaboration protocol agreement, or one message at a time. The MessageHeader element has a QualityOfServiceInfo sub-element with a deliverySemantics attribute. This attribute has values of OnceAndOnlyOnce or BestEffort . If set to OnceAndOnlyOnce , trading partners need to take steps guaranteeing that messages are re-sent in case of failure, and persistent storage is implemented to check against duplicate deliveries. If set to BestEffort , the trading partners can ignore these properties.

If the trading partners choose to implement reliable messaging, they need to take the following steps in their messaging systems. Senders need to do the following:

Create a message with a TraceHeader element identifying the sender and recipient Internet addresses.
Save the message in persistent storage.
Send the message to the recipient message service handler.
Wait for an acknowledgment from the recipient or take the appropriate action if none is returned.

Recipients of messages need to take these steps:

If the message is an acknowledgment, look for a message in persistent storage with the same identifier as in the RefToMessageId element and, if found, mark it as delivered.
If the message is not an acknowledgment, check whether it's a duplicate (a message identifier in persistent storage with the same value as the message).
If neither an acknowledgment nor a duplicate, then save the message identifier or entire message (if practical to do so) in persistent storage, compare the message identifier to the reference, mark the message as delivered, and send an acknowledgment.
If the message is a duplicate, check for the first response to the received message in persistent storage and re-send the initial response.

The specifications give rules for acknowledgments. Recipients of messages must send acknowledgments if the deliverySemantics attribute is set to OnceAndOnlyOnce or the reliableMessagingMethod attribute is set to ebXML . The minimum requirement for an acknowledgment is a MessageData element with a RefToMessageId set to the same value as the MessageId element in the message being acknowledged .

If trading partners agree to reliable messaging and a message fails to be delivered, the appropriate message service handler (it can be either the sender or receiver) should generate a delivery failure notification message. This message has an error code reflecting a delivery failure.[68]

Security

The specifications recognize and list some of the risks inherent in a business messaging service:

Unauthorized access ” Parties that are not allowed to gain access to resources or services trying to do so.
Data-integrity attacks ” Attempts to disrupt the contents of messages.
Confidentiality attacks ” Attempts to read the contents of messages.
Denial of service (DoS) attacks ” Attempts to overwhelm the ability of resources to cope with a flood of fake message traffic.
Spoofing attacks ” Similar to unauthorized access, but by groups of attackers rather than an individual.
Bombing attacks ” Similar to data-integrity attacks, but against an entire site or resource rather than individual records.

The messaging specifications recommend a series of countermeasures, beginning with due diligence by the managers of the message services and appropriate safeguards listed in the collaboration protocol agreement between the trading partners.

The document discusses a number of technical countermeasures either as requirements or recommendations. These steps include the use of digital signatures both on the original messages and receipts. Some of the steps discussed, however, are still in development, such as XML encryption and trusted date/time stamps.[69]