ebXML - Messaging Service

Advertisements

Previous Page
Next Page  

A complete message is called the message package, which is a Multipurpose Internet Mail Extensions (MIME) object. The message package contains two principal parts:

  • SOAP Message Container: This is required part of the message and contains the SOAP extension elements for ebXML, such as routing information, trading partner information, message identification, and delivery semantics information.

  • Payload Containers: This is optional part of the message and can contain any type of information that is to be exchanged between parties.

Messaging Design Criteria

According to the messaging service specification, the design goals for the ebXML message service are to:

  • Leverage existing standards wherever possible.

  • Be simple to implement.

  • Support enterprises of all sizes.

  • Support a wide variety of communication protocols (HTTP, SMTP, FTP, etc.)

  • Support payloads of any type (XML, EDI transactions, binary data, etc.)

  • Support reliable messaging.

  • Ensure security.

Messaging Architecture

The ebXML message service was designed to work within the overall context of the ebXML initiative. However, the ebXML technical architecture is modular, and the message service can be used independently of ebXML.

The ebXML message service has three logical architectural levels between the business application and the network protocols:

  • The Message Service Interface (MSI): It is an application interface for business applications to invoke message handler functionality for sending and receiving messages. Similar to ODBC, JDBC, and other abstract service interfaces, it exposes the message handler functionality as a defined set of APIs for business application developers.

  • The Message Service Handler (MSH): It has basic services, such as header processing, header parsing, security services, reliable messaging services, message packing, and error handling.

  • The Message Transport Interface (MTI): It is designed to send messages over various networks and application-level communication protocols. The transport interface transforms ebXML specific data to other forms carried by network services and protocols. This involves a complete exchange between two parties, piggybacking on top of existing protocols in the network stack.

The ebXML Messaging Architecture is shown in the following diagram.

ebXML Architecture

Message Formatting:

An ebXML message has to be formatted according to the ebXML message service specification and must conform to the MIME syntax, format, and encoding rules. The definition of the XML elements are provided by an XML schema, which extends SOAP to define the ebXML message header, trace header, manifest, status, and acknowledgment.

Conclusion

An ebXML message has to be formatted according to the ebXML Message Service Specification and must conform to the MIME syntax, format, and encoding rules. The definition of the XML elements are provided by an XML schema, which extends SOAP to define the ebXML message header, trace header, manifest, status, and acknowledgment.

The ebXML messaging -

  • Uses SOAP with Attachments as payload envelope.

  • Runs over various communication protocols such as HTTP, SMTP, FTP.

  • Supports higher-level semantics needed in business transactions. (Secuirty and Reliability)

Advertisements