XML messaging, Part
3
Tutorial Details:
XML messaging, Part 3
XML messaging, Part 3
By: By Dirk Reinshagen
The JAXM and ebXML APIs set the new standard for XML messaging
ith the advent of Web services, XML messaging has become an important component of the J2EE (Java 2, Enterprise Edition) technology solution set. Within the XML messaging realm, JAXM (Java API for XML Messaging), Sun's general-purpose API for creating and processing XML messages, combined with the ebXML (electronic business XML) standard for conducting electronic business, help standardize and simplify XML messaging.
Read the whole "XML Messaging" series:
Part 1: Write a simple XML message broker for custom XML messages
Part 2: XML messaging the SOAP way
Part 3: JAXM and ebXML set the new standard for XML messaging
In this article, the last of three, I cover JAXM and ebXML in three sections. First, I discuss JAXM: its purpose, the APIs it defines, its configuration, and so on. After JAXM, I move on to ebXML and its major features. Finally, I wrap up with JAXM and ebXML examples.
What is JAXM?
The JAXM specification's stated mission is to provide a SOAP (Simple Object Access Protocol)-message-oriented API for Java. Note: I've based this JAXM overview on the JAXM specification version 0.9.3 and its latest available reference implementation, August 2001.
You'll find the JAXM API straightforward. The API has roots in JMS (the Java Message Service), and so you'll notice the close similarity between the two. JMS has a ConnectionFactory , JAXM also has a ConnectionFactory ; JMS has a MessageListener interface, as does JAXM; and so on. On another point, JAXM uses DOM4J and JDOM as the encapsulation mechanism for XML documents (which are messages).
JAXM clients can assume two basic roles in JAXM: sender and/or receiver. The sender role sends messages to other JAXM clients acting as receivers. The receiver role receives messages sent by other sender JAXM clients. A JAXM client can play either one or both of these roles.
To work with JAXM, you also need to understand the concept of providers. A JAXM provider is a product or package that provides an actual implementation of the JAXM APIs, allowing different packages to offer a JAXM layer over an existing product. Again, there are parallels with JMS.
JAXM supports both the SOAP specification and the SOAP Attachment specification. JAXM assumes this base level of support. In addition, although SOAP messaging standards such as ebXML or BizTalk are not yet specified, message profiles layer them onto JAXM.
JAXM APIs
Now that you understand some of JAXM's concepts, let's now dive into the actual API, which is broken into a messaging package and a soap package.
javax.xml.messaging
The messaging package holds the classes, interfaces, and so on required for sending and receiving SOAP messages. Moreover, it contains the Connection class to connect to the JAXM provider and to send messages, as well as the MessageListener class for receiving messages.
javax.xml.soap
The soap package provides the classes necessary for encapsulating SOAP messages. You'll find classes for SOAP header, body, elements, and so on. Many classes in the current implementation extend DOM4J and JDOM classes to achieve their functionality, so familiarity with both technologies will help you here.
So far, so good
While JAXM accomplishes many of its goals, today it remains an unfinished API. For instance, JAXM currently supports only DOM4J and JDOM for message encapsulation. While DOM4J and JDOM prove easy to use, they do not yet have the industry support DOM enjoys (nor the support in other products). Also, the current JAXM release lacks a fully formed implementation message-profile support -- an important part of supporting different messaging standards. Look for the final and follow-up JAXM releases to resolve some of these issues.
Now that you've learned about JAXM, let's build on this by turning our attention to ebXML.
What is ebXML?
The ebXML initiative by UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business) and OASIS (Organization for the Advancement of Structured Information Standards) aims to create and conduct business over the Internet. ebXML comprises message formatting, business processes, and registry services specifications, among others. In this article, I discuss only ebXML message formatting, as detailed in the ebXML message service specification.
ebXML components
In ebXML, an entire message is called a message package. A message package has one header container and zero or more payload containers. Only the header container is a SOAP envelope; the payload containers are SOAP attachments to the header container SOAP envelope.
As such, most of the ebXML-specific elements exist in the header container, which includes the elements that describe how the message will route, what type of operations it will perform, the unique identifier for the message, and so on.
The payload container(s) hold the message package's content, which can range from XML content (such as an invoice) to a TIFF image (such as a scanned-in legal contract). You refer to the payload container in the header container with an xlink reference in the header container's body.
ebXML header elements
Given that most of ebXML's features exist in the header container (and, more specifically, in the header elements), it's important to know some of the elements there. Although I can't present an exhaustive list here, in the sections immediately below I've outlined some of an ebXML header container's required fields.
To and From header elements
The To and From header elements in an ebXML message refer to a unique identifier for the sender ( From ) and a unique identifier for the receiver ( To ). It's recommended that both be URIs.
CPAId header element
The CPAId header element usually refers to an ID defined according to the Collaboration Protocol Profile and Agreement Specification. This ID defines how the two parties interact, both from a messaging perspective and from a business-process perspective.
ConversationId header element
A ConversationId header element uniquely identifies a set of related message exchanges. The ID must be unique.
Service header element
The Service header element denotes the service that processes the message at the destination (the To element). As an example of what might exist in the Service header element, consider the text urn:Invoice , denoting a message that should be processed by the invoice service.
Action header element
The Action header element, a subtype of the Service element, specifies what action the service should take.
MessageId header element
The MessageId header element uniquely identifies this particular message, usually in some form of a GUID (Globally Unique Identifier).
Timestamp header element
The Timestamp header element's timestamp field marks the message package's creation time.
An ebXML example
Now that you've seen an ebXML message's structure and some of the header elements, it's time to look at a complete example. The following ebXML message shows the message received by the messaging client in the next section:
--777426.996476529290.JavaMail.Administrator.u8222
Content-Type: text/xml
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:eb="http://www.ebxml.org/namespaces/messageHeader"
xmlns:xlink="http://www.w3.org/1999/xlink">
mailto:queryresponse@companyb.com
mailto:query@companya.com
123
20002
urn:services:QueryTransfers
QueryAllTransfers
996476529250
2001-07-20T9:31:12Z
Money Transfer
--777426.996476529290.JavaMail.Administrator.u8222
Content-Type: text/xml
Content-Id: transfer1@companya.com
2323444
998822
$22,000.00
--777426.996476529290.JavaMail.Administrator.u8222--
At first glance the message may look slightly unwieldy. Fear not: it's not as complex as it initially looks. First, notice the MIME headers that separate the header container from the payload container portions of the message package.
Also note the way in which the header container points to the payload container. In the header container, there is an xlink to "transfer1@companya.com" . This relates to the payload container in that the MIME content ID of the payload is "transfer1@companya.com" . This is how ebXML correlates the header to the documents' payloads.
You're now ready to see JAXM and ebXML working together.
A JAXM/ebXML example
The next example -- comprising two Web applications -- employs JAXM and ebXML to query for money transfers. In the example, the companya Web application uses JAXM and ebXML to query the companyb Web application for money transfers. The companyb Web application responds with a list of such transfers.
The message package sent by companya contains a query specified in the header container. You won't find any payload containers in the message request. In companyb 's response is a message with the To fields flipped and a payload container with the query results.
Setup
You'll need the following packages to run the example:
Tomcat 3.2.2
JAXM early access implementation
The companya and c
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: XML messaging, Part
3
View Tutorial: XML messaging, Part
3
Related
Tutorials:
 Messaging helps move Java into the
enterprise - JavaWorld January 1999
Messaging helps move Java into the
enterprise - JavaWorld January 1999
|
Process XML with
JavaBeans, Part 3 - JavaWorld January
2000
Process XML with
JavaBeans, Part 3 - JavaWorld January
2000
|
JMS: An infrastructure for
XML-based business-to-business communication - JavaWorld February
2000
JMS: An infrastructure for
XML-based business-to-business communication - JavaWorld February
2000
|
Programming XML in Java, Part 3 - JavaWorld July
2000
Programming XML in Java, Part 3 - JavaWorld July
2000
|
Validation with Java and XML Schema, Part 2 - JavaWorld October 2000
Validation with Java and XML Schema, Part 2 - JavaWorld October 2000
|
Add the power of asynchronous processing to your JSPs - JavaWorld February 2001
Create custom JSP tags to use with JMS ost JavaServer Pages (JSP) developers that
|
XML messaging, Part 1 - JavaWorld March 2001
XML messaging, Part 1 - JavaWorld March 2001
|
Jato: The new kid on the open source block - JavaWorld March 2001
Jato: The new kid on the open source block - JavaWorld March 2001
|
Jato: The new kid on the open source block, Part 2 - JavaWorld April
2001
Jato: The new kid on the open source block, Part 2 - JavaWorld April
2001
|
XML messaging, Part 2 - JavaWorld June
2001
XML messaging, Part 2 - JavaWorld June
2001
|
XML messaging, Part
3
XML messaging, Part
3
|
Rumble in the
jungle: J2EE versus .Net, Part
1
Rumble in the
jungle: J2EE versus .Net, Part
1
|
Jabber away with instant
messaging
Jabber away with instant
messaging
|
Yes, you can secure your Web services documents, Part 1
Yes, you can secure your Web services documents, Part 1
|
Yes, you can secure your Web services documents, Part 2
Yes, you can secure your Web services documents, Part 2
|
Sun boosts
Sun boosts enterprise Java
|
The Java Web Services Tutorial
This tutorial is a beginner\'s guide to developing Web services and Web applications using the Java Web Services Developer Pack (Java WSDP).
|
SAAJ: No strings attached
SAAJ: No strings attached
|
JSP 2.0: The New Deal, Part 3
JSP 2.0: The New Deal, Part 3
More Flexible JSP Document Format Rules
The JSP specification supports two types of JSP pages: regular JSP pages containing any type of text or markup, and JSP Documents, which are well-formed XML documents; i.e., docum
|
The JavaTM Web Services Tutorial
A beginner's guide to developing Web services and Web applications on the Java Web Services Developer Pack
|
|
|
|
