Enterprise Resource Planning

ERP Journal on Ulitzer

Subscribe to ERP Journal on Ulitzer: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get ERP Journal on Ulitzer: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


ERP Journal Authors: Steve Mordue, Elizabeth White, Automic Blog, Louis Nauges, Progress Blog

Related Topics: XML Magazine, Java Developer Magazine, ERP Journal on Ulitzer

XML: Article

Developing B2B Applications Using XML and JMS

Developing B2B Applications Using XML and JMS

This article explains the use of XML and Java messaging technology in intra-enterprise or inter-enterprise (B2B) applications.

XML technology allows for a common representation of a wide variety of data and is quickly becoming a leading standard for data representation on the Web. It's difficult to imagine any new Web application effort, or data representation effort for that matter, proceeding without involving XML technology.

Java Message Service (JMS) is a specification from Sun that enables Java developers to write enterprise applications that will be portable across various message-oriented middleware (MOM) products. When used together, these two technologies provide a compelling option to develop business-to-business applications. This article is intended for enterprise-solution architects seeking answers to the questions in the B2B integration arena.

Problem Definition
Let's talk first about B2B. Suppose, in general terms, Enterprise A and Enterprise B would like to collaborate within a certain context. Enterprise A would like to share some data/process information with Enterprise B as this leads to competitive benefits for both of them. This requires a process workflow to span both enterprises. Data needs to be manipulated and transformed not only across the network, but also across several applications. What makes it difficult? Well, the following to start with:

  • Data representation differences: For example, the way Enterprise A defines a purchase order will be different from the way Enterprise B defines it.
  • Application differences: Both enterprises may use different applications to run their business. For example, Enterprise A may have standardized internally on Oracle ERP, while Enterprise B may be using SAP.
  • Network protocol differences: The networks used by the enterprise can be based on different protocols.
  • Platform differences: Both enterprises may have standardized on different platforms like Sun Solaris, NT or IBM AIX.
  • Security and firewall issues: Both enterprises may be using firewalls to protect enterprise data.
Most of these difficulties can be categorized as data-formatting or data-transport problems (see Figure 1). XML solves the former while MOMs solve the latter.

XML/JMS
XML is different from HTML. HTML has a well-defined set of tags that describe a fixed number of elements. XML, however, is a meta-markup language in which you make the tags you need when you need them. In HTML you wait for the next release, hoping it'll contain the tag you want.

The tags you define can be documented in a Document Type Definition (DTD), the vocabulary and syntax for the language you defined using XML. XML describes structure and semantics, not formatting. What does all this mean to a solution architect challenged by the problems in B2B integration? This article doesn't go into the programming details of XML. However, for the current discussion it's important to note its key benefits:

  1. XML is a self-describing data format. Applications exchanging XML information can infer the content of a data file without having any prior information by looking for the tags in the document.
  2. XML allows the design of business-specific markup languages. Different industry segments can define their own markup languages as a common vocabulary. Examples are Chemical Markup Language (CML), which describes molecular sciences, and Wireless Markup Language (WML), which describes Web content for wireless devices.
  3. The structure of an XML document is similar to that of a business object with various attributes. This allows for the natural conversion of application-specific objects to XML documents and vice versa.
Thus XML is capable of solving data-formatting problems. Let's see how JMS, a specification from Sun, addresses data-connectivity problems.

To connect disparate enterprise applications, it's important to use an architectural approach that facilitates addition, removal and modification of applications without affecting the existing ones. The need for B2B connectivity places strenuous demands on the communication and transaction infrastructure. By adopting a loosely coupled approach, nagging issues such as system maintainability and robustness can be handled effectively. This decoupling goes a long way in building flexible, reliable and highly scalable infrastructures.

MOMs are based on the concept of loosely coupling applications by allowing applications to send guaranteed or reliable messages to one another.

The two major paradigms in messaging are publish/subscribe and point-to-point.

Point-to-Point Messaging
Software applications have unique addresses or associated queue names. The sender application needs to know the identity of the receiver application(s) before it sends messages. The messages may be stored and forwarded by the MOM. This paradigm works fine with a relatively static set of communicating entities.

Publish/Subscribe Messaging
A set of applications register their interest in different subjects or topics with the MOM. Publishing applications don't have any knowledge of the subscribers; they simply publish messages based on subjects. The MOM forwards a message to the subscriber when it pertains to a subject that is subscribed to. The publishers and subscribers may come and go without affecting any peer applications. This paradigm works fine with a dynamic set of communicating entities. It promotes a high decoupling of applications and scalability of the overall system.

Various vendors have implementations of message-based middlewares. IBM's MQSeries is an example of a MOM and Microsoft has a product called Microsoft Message Queue (MSMQ). Both are based on the point-to-point paradigm. IBM's MQSeries, however, also supports a publish/subscribe paradigm in version 5.1. Tibco is another vendor of a MOM called TIB/Rendezvous, based on the publish/subscribe paradigm.

JMS is an elegant way to write messaging-based client programs and deploy them on top of any JMS-compliant MOM. JMS makes your application code or business logic code portable across MOMs. This assumes greater importance in the B2B e-commerce scenario as the collaborating enterprises may work with different MOMs. For any enterprise, deploying and maintaining a MOM that constantly carries mission-critical data is a significant investment. This can't be changed overnight because your partner is using another MOM product. Using JMS, the same client program will work fine with both MOM products. Now the business application logic programmer doesn't have to learn the programming APIs for each specific MOM. The end result? Savings both of time and the cost of developing business applications, and quicker time-to-market.

We saw the integration problem in Figure 1. Figure 2 shows the results of introducing XML and JMS.

Application of XML/JMS to B2B
In the health-care industry it's normal to find a highly diverse range of IT infrastructure. Various hospitals have proprietary platforms, with different enterprise resource planning (ERP) applications communicating over various proprietary protocols. They need to submit health insurance claim forms to insurance companies, which have their own set of proprietary data formats and communication protocols. Within each of these insurance companies and hospitals are several software applications that need to interact. And there's a constant need to add new applications and modify the existing ones.

For this example we'll consider Acme Medical Center: they have three ERP applications and two medical insurance companies, Universal Insurance and Flexible Health Care Insurance, each with three applications. Acme wants to collaborate with both insurance companies and possibly others in the future. These companies need medical claim forms in a format different from what the claim entry system at Acme Medical Center produces. The IT staff at Acme realizes that a future insurance company may need a totally different format.

Another problem with these three organizations is that the ERP applications need to exchange data with each other and all of them need data in a different format (see Figure 3). Although it looks strange, it's typical of an enterprise scenario.

Most enterprise applications were designed with the functional aspects of the system in mind rather than networking needs with other applications.

It's likely that there may be more ERP applications within each of these organizations that need intra-enterprise integration. At the same time, more insurance companies may come on board, also resulting in a need for inter-enterprise integration. It doesn't make sense to do a point-to-point data format conversion and integration for all the cases, since that will result in a large number of custom integrations that need ongoing maintenance and updating. In addition, every time a new insurance company comes on board, a whole new integration will need to be done with all ERP applications inside Acme Medical Center (see Figure 4).

There's a point-to-point integration between every two applications. Think about adding one more application. It isn't going to work. Introduce XML and JMS into the picture and life becomes simpler. As shown in Figure 5, there's only one integration from each application to the central hub. This is achieved by abstracting the data format using XML and connecting the applications using JMS. Every application should read and write data in XML format and send and receive it using the JMS API.

Solution Architecture
The IT department at Acme receives the mandate to come up with a solution architecture that allows seamless integration of various in-house ERP systems, an easy way to add more applications. The architecture should also support easy integration with the existing insurance companies as well as future ones. The IT department at Acme talks to each insurance company's IT department; they weren't surprised to see that both companies were facing similar problems. After weeks of architectural discussions and evaluating various available products, all three IT departments agreed that it would be best to follow open standards (such as XML), a cross-platform language (such as Java) and messaging standards (such as JMS).

Intra-Enterprise Integration
Messaging Paradigm

To integrate their internal ERP applications, they go with a publish/subscribe messaging paradigm since it allows them to seamlessly add more applications without doing numerous point-to-point integration.

Data Format
They decide that the data format between applications should be a self-describing, extensible format that allows them to accommodate any future applications without modifying existing ones. Hence they opt for XML.

Integrating XML with the ERP Applications
The next problem is integrating XML with each of the ERP applications. They contact the ERP vendors and find that several of them already support XML as a data transfer format. For the remainder of the applications they realize it's not feasible to rewrite them to use the new technologies from the ground up. So they agree to write adapters for each application that will convert XML into the format the ERP applications expect.

Inter-Enterprise Integration
There are more issues for integration between the organizations.

Security
Data should be secure over the Internet. This has three aspects:

  • Encryption: This refers to ciphering of data while on the wire.
  • Authentication: Only valid applications and users should be allowed to send and receive messages.
  • Data integrity: Data shouldn't be tampered with while in transit.

Firewall Issues
They need to do messaging across each organization's corporate firewall. They could open a port in the firewall; however, for security reasons not every partner likes to do that. The other option is to do what's called HTTP tunneling - sending the data as HTTP traffic through well-known port number 80 for HTTP and then, once inside the firewall, converting this data into messages.

Selection of MOM
They look at various MOM systems available in the market and decide to go with IBM's MQSeries version 5.1 that supports both point-to-point and publish/subscribe messaging paradigms. It also has an add-on called IBM Internet Gateway that allows messages to go through firewalls using HTTP tunneling. With MQSeries it's also possible to send encrypted messages over the Internet.

Messaging Paradigm
Although the messaging paradigm within the corporate firewall is publish/subscribe, a point-to-point approach is taken outside simply because no organization wants its messages to be available to others. For this they decide to develop a simple application that will receive the messages from the partners in a point-to-point fashion and publish it on the message bus. On the outgoing side it'll subscribe to certain subjects that define outgoing messages and send them to one of the partner organizations as point-to-point messages. This is called partner interface application.

The overall solution architecture is shown in Figure 6. Conclusion
XML is a standard that provides portability with respect to various data formats; JMS is a standard that provides transport-level portability. Logically, when these two technologies are applied together, we get solutions to many of the B2B integration problems.

Considering how rapidly these technologies are advancing, don't be surprised to see JMS come up with one more message format, XMLMessage, that allows direct access to and manipulation of an XML document. When that happens, enterprise architects will find this duo even more valuable.

Further Reading

  1. XML Language Specification: http://www.w3.org/XML
  2. XML Catalog for Vertical Industry Segments: www.xml.org/xmlorg_registry/index.shtml
  3. JMS Specification: www.javasoft.com/products/jms
  4. IBM MQ Series: www.software.ibm.com/mqseries
  5. Tibco Rendezvous: www.rv.tibco.com
  6. Vendors and MOMs supporting JMS: www.javasoft.com/products/jms/vendors.html

More Stories By Majeed Ghadialy

Majeed Ghadialy, a Sun-certified Java architect, works with I2 Technologies in their B2B Marketplace effort and business intelligence. He has over five years of OO design and evelopment experience in Java, CORBA and messaging.

More Stories By Nirmal Patil

Nirmal Patil is a software developer working with I2 Technologies. A Sun-certified Java architect with four years of Java experience, he focuses on designing and eveloping object systems. Nirmal holds an MS in computer science.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.