9.5 XML Messaging

XML messaging is the technology of choice for implementing business-to-business (B2B) and application-to-application (A2A) transactions and for connecting internal systems that previously operated as "stovepipes." The problem today is that so many companies and industry organizations are proposing standards for a common e-business language that it is difficult to differentiate among them or know which one to use. In this section, we look at the basic components of XML messaging, as well as several efforts to promote XML for standard communication among organizations and applications.

XML Messaging Components

An XML messaging system contains

• A set of business processes and the XML content describing the constituent transactions

• A data dictionary description of the elements that make up the XML content

• A messaging service that specifies how the XML content is packaged, transferred, and routed

The transport mechanism itself is typically not specified as a component of XML messaging. Nevertheless, the messaging service must "wrap" the XML message, as required by the selected transport protocol. Examples of transport protocols used for XML messaging are HTTP, File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP), Microsoft Message Queue (MSMQ), MQSeries, and Electronic Data Interchange (EDI).

Another element is becoming an important part of XML messaging. That is an e-commerce registry and repository structure for looking up companies, discovering products and services they provide, and learning about the types of business relationships they support.

BizTalk

BizTalk is an industry initiative headed by Microsoft to promote XML as the common data exchange language for e-commerce and application integration over the Internet. Although not a standards body per se, the group is fostering a common XML message-passing architecture to tie systems together.

BizTalk provides XML messaging services through the BizTalk Framework. Figure 9-8 presents a simple document exchange using the BizTalk Framework.

Figure 9-8. Document exchange using the BizTalk Framework

An application generates a business documenta well- formed XML document containing business dataadds any attachments, and submits it to the BizTalk Framework Compliant (BFC) server. Either the application or the BFC server can have responsibility for wrapping the business document in a BizTalk document. A BizTalk document is a Simple Object Access Protocol (SOAP) message. The body of the message contains the business document, and the header contains BizTalk-specific data. The BFC server processes the document and any attachments and constructs a BizTalk message as appropriate for the transport protocol. The BizTalk Framework does not prescribe transport protocols. Common protocols used for BizTalk are HTTP, SMTP, and MSMQ. The BizTalk Framework 2.0 documentation recommends using high-performance messaging middleware for reliable delivery and supports Secure Multipurpose Internet Mail Extensions (S/MIME) for securing BizTalk messages [Microsoft 00].

The BizTalk Framework does not prescribe the XML content or structure of the business documents being exchanged. The context and structure are defined by the organizations involved in the transaction. BizTalk.org provides an object library that can be queried and updated by its members . ^[5] This library is a set of sample schemas that members have used in their applications or schemas supported by members of the organization. These schemas can be used for communicating, but they are not a set of standard schemas that define business content to be transmitted inside a BizTalk message.

^[5] For more information, see http://www.sei.cmu.edu/cbs/mls/links.html#biztalk.

Electronic Business XML

Electronic Business XML (ebXML) is a project to standardize the secure exchange of business data, using XML. ^[6] The United Nations body for Trade Facilitation and Electronic Business Information Standards (UN/CEFACT) and the Organization for the Advancement of Structured Information Standards (OASIS) launched the ebXML project as a joint initiative. Its membership includes a wide variety of companies, ranging from major IT vendors to trade associations throughout the world.

^[6] For more information, see http://www.sei.cmu.edu/cbs/mls/links.html#ebxml.

Figure 9-9 illustrates a typical usage scenario for ebXML [Siddalingaiah 01].

1. Company A registers its ebXML-compliant application and business profile in the ebXML registry.

2. Company B discovers this application.

3. Company B submits its business profile to the registry.

4. Company A studies the information submitted by Company B and sends an acknowledgment to Company B, confirming whether their business scenarios are compatible.

5. Company B sends a proposed business arrangement automatically to company A, based on the information in the registry.

6. After company A accepts the business, the two companies are ready to engage in e-business, using ebXML messages.

Figure 9-9. Typical ebXML usage scenario

To support this scenario, the ebXML Technical Architecture Specification defines the following elements [ebXML 01]:

• Collaboration Protocol Profile ( CPP ). A CPP is the standard for describing a company's business processes and message-exchange capabilities (business service interface).

• Collaboration Protocol Agreement ( CPA ). A CPA describes the exact requirements and mechanisms for the transactions between two companies. In essence, a CPA is a contract that can be derived automatically from two or more businesses' respective CPPs.

• Business process and information modeling. ebXML includes specifications for describing a business process in XML so it can be used in the CPP or to share business processes and information formats.

• Core components. The core components are the set of XML schemas that describe business transactions.

• Messaging. The SOAP-based ebXML messaging service provides security and reliable messaging.

• Registry/repository. The ebXML registry/repository stores CPPs, CPAs, core components, and any other ebXML documents that allow enterprises to find each other, agree to become trading partners , and conduct business.

Similar to the other standards, ebXML's messaging service is transport neutral. HTTP and SMTP are commonly used protocols.

Open Applications Group Integration Specification

The Open Applications Group (OAG) is a nonprofit consortium formed in February 1995 by a group of eight software vendors, including Oracle, SAP, and PeopleSoft. ^[7] The mission of OAG was to define and promote the adoption of a unifying standard for B2B and A2A interoperability, based on XML content. The result of this work is the Open Applications Group Integration Specification (OAGIS).

^[7] For more information, see http://www.sei.cmu.edu/cbs/mls/links.html#openapplications-1.

The OAGIS prescribes a content-based, business object model (Figure 9-10). To communicate with a business object in this model, events are communicated through the integration backbone in the form of an OAGIS-compliant, business object document (BOD) to a virtual object interface [OAG 99]. This virtual object interface is basically an OAGIS-compliant wrapper built around an application so it can exchange BODs with other applications. The integration backbone should provide at least the following services: request/reply, publish/subscribe, directory services, routing, queuing, and logging.

Figure 9-10. OAGIS virtual business object model

The BOD uses metadata, in the form of an XML schema. The BOD conveys two primary components: the business service request and the business data area. This BOD structure is shown in Figure 9-11.

Figure 9-11. BOD structure

Each business service request (BSR) contains a unique verb/noun combination, such as POST JOURNAL or SYNC ITEM, that drives the contents of the business data area (BDA). This combination of BSR and BDA corresponds to the object name , method, and arguments of a procedure call or method invocation model.

OAGIS does not contain a messaging infrastructure. It is strictly an XML content repository and a set of common integration scenarios. However, its scenarios do fit best with enterprise application integration middleware, such as MQSeries.

OAGIS is also responsible for OAMAS (Open Applications Middleware API Specification). OAMAS is a proposal to the middleware community for a common, higher-level middleware API so business applications can connect in a more standard way.

RosettaNet

RosettaNet is a nonprofit organization that creates, implements, and promotes open e-business standards. ^[8] RosettaNet is defining a common parts dictionary so that companies can define the same product in the same way and is also defining up to 100 e-business transaction processes, mainly for supply chain integration. RosettaNet's members include Microsoft, Netscape, 3Com, Toshiba America, Compaq, CompUSA, Hewlett-Packard, IBM, and Intel.

^[8] For more information, see http://www.sei.cmu.edu/cbs/mls/links.html#rosettanet.

The main standard components offered by RosettaNet are

• RosettaNet Implementation Framework ( RNIF ): Encapsulates business documents along with header components and other elements that must be exchanged between end points of a RosettaNet standard interaction into a RosettaNet message. RNIF covers the transport, routing, and packaging; security; signals; and trading partner agreements (TPAs).

• RosettaNet business dictionary: Provides properties for defining business transactions between trading partners.

• RosettaNet technical dictionary: Provides properties for defining products and services.

• RosettaNet partner interface processes (PIPs): Specifies specialized system-to-system XML-based dialogues that define business processes between trading partners.

A RosettaNet-enabled trading partner uses the RNIF and the dictionaries to set up its environment. Two RosettaNet-enabled partners must agree on a PIP to use and establish a TPA before any communication takes place. From then on, every time they need to communicate, they execute a PIP instance as a sequence of business messages and signals, such as the one shown in Figure 9-12 for order placement [RosettaNet 02].

Figure 9-12. Sample PIP interaction sequence

RosettaNet business messages can be S/MIME packaged for security and can be transmitted using HTTP over SSL (HTTPS) or SMTP as protocols.

How These Standards Relate

BizTalk, ebXML, OAGIS, and RosettaNet compete and complement one another. In theory, any XML content conforming to the BizTalk, ebXML, RosettaNet, or OAGIS specifications can be transported using the BizTalk, ebXML, or RosettaNet infrastructures . OAGIS does not provide an infrastructure framework. In practice, it is not that simple. However, efforts are underway to make it happen. OAG has published several white papers on how to use OAGIS as the business content and BizTalk Framework, the RosettaNet Integration Framework, or the ebXML messaging service as part of the underlying messaging infrastructure. In addition, a product called BizTalk Accelerator for RosettaNet integrates these two products.

The process of packaging, routing, and transporting XML-based messages is not the main issue. Rather, the issue is that an implementation of XML messaging is useless if the parties involved do not agree on the semantics of the information being exchanged.

OAGIS is an XML content repository that represents common business transactions. RosettaNet and ebXML have some definitions of common content and also specifications for defining content and processes. In this case, the two parties must agree on their exchange in advance on an individual basis. The ebXML repository and the BizTalk object library try to make this agreement more automatic.

The bottom line is that XML messaging can aid data interoperability where shared semantics can be assumed. XML messaging does not guarantee semantic interoperability; nor does it solve the integration problem. But XML messaging does make solving the problem easier.

Other Standards Related to XML Messaging

Simple Object Access Protocol (SOAP)

SOAP is a platform-independent W3C protocol for applications to communicate with one another over the Internet. SOAP specifies exactly how to encode an HTTP header and an XML file so that a program in one computer can call a program in another computer and pass it information. SOAP also specifies how the called program can return a response. An advantage of SOAP is that program calls are much more likely to get through firewall servers because HTTP requests are usually allowed through. Other SOAP implementations include MSMQ, MQSeries, SMTP, and TCP/IP. ^[9]

^[9] The XML-RPC protocol, similar to SOAP and sometimes referred to as SOAP's younger sibling, is basically a remote procedure calling, using HTTP as the transport and XML as the encoding.

Universal Description, Discovery, and Integration (UDDI)

UDDI is an XML-based distributed registry that enables businesses to list themselves on the Internet and to discover one another, similar to a traditional phone book's white, yellow, and blue pages. The ultimate goal of UDDI is to allow online transactions by enabling companies to find one another on the Web and to make their systems interoperable for e-commerce. UDDI allows businesses to list themselves by name, product, location, or the Web services they offer.

Web Services Description Language (WSDL)

WSDL is an XML-based language used by UDDI to describe the services a business offers and to provide access to those services electronically .