The need for communications between applications across enterprises is well recognized; EDI has been serving this need for a number of years now. The Internet is providing a means for secure transactions between applications on a public network, bringing down the price point considerably. This makes electronic communication affordable for even smaller businesses.
Exploiting this development, a new genre of applications, known as EAI (Enterprise Application Integration), are entering the market. Players include TIBCO, NetFish, and SeeBeyond.
All of these tools have the following characteristics:
Applications built with these facilities are especially important for industries that are supply-chain-centric, transportation-centric, and e-commerce-centric. The specific application areas may include warehouse management, inventory control, flow of goods across the entire supply chain, customer visibility, and tracking.
Driving this revolution from the data perspective and transformation perspective is the increasing role of XML.
In an interconnected enterprise, the primary task is the movement and interpretation of messages. It is important that there is a common language and structure for interpreting these messages. XML offers the following benefits for representing these messages:
This means any communication with the external world has an advantage when it uses XML. Let's take a look at the essential components for XML interconnectivity.
An application must have an easy way of receiving XML messages. This could be done using any of the following ways: FTP, email, SOAP, enterprise connectors for Oracle, SAP, PeopleSoft, etc.
Regardless of the way a message is received, it has to adhere to the following:
This is where lot of the EAI tools can help in unifying the gateways through which messages can be received. Nevertheless, if a company has a Web server infrastructure, there is a cheaper alternative to buying a fully-functional EAI tool. The solution is to adopt SOAP. SOAP is widely available and has the following benefits:
SOAP does have some drawbacks, however:
Much of the data in the enterprise sits in relational databases. An important question is how one can generate and send an XML message to a requesting customer. Let us list a few of the ways this can be done:
While the Java solution is open and can accommodate all data sources, the GUI solution may be limited only to relational database tables and SQL (not even stored procedures).
Another interesting observation in this XML generation is this: when an IT company develops a Web-based solution using JSPs, the company is already converting relational data to XML data -- the XML just happens to be HTML. So why not architect your Web solutions so that you can deliver your data either in HTML or XML? This way, you can have one solution that accommodates B2C and B2B simultaneously. This last approach is what I recommend to companies trying to integrate themselves into a global community of companies.
Security. When you receive XML messages, it is important that they arrive through secure channels. The SOAP protocol makes use of SSL and HTTP to satisfy this requirement. In addition, you can make use of sessions supported by the servlet framework.
Transactions. When you receive an XML message, you may have to call a series of business processes to satisfy that XML message. These business processes will have to be executed within well-defined transactional boundaries. The transactional boundaries could have the following possibilities: no transaction at all, single-phase commits, two-phase commit protocols, or long-running transactions.
The solution should accommodate these transactional requirements. A Web server and its accomdating infrastructure, such as EJBs or MTS, can take care of this situation quite well.
Another important aspect of an integrated enterprise is how easy it is to discover useful services between the collaborating parties. The mechanisms of publishing available services may range from informal conversations to Web-based documentation to more recent technologies such as UDDI. The visibility of newer technologies promises to revolutionize inter-company communications because of the new levels of access to information.
The solution offered by SOAP as a transport for XML messages is compelling. SOAP runs on HTTP, thereby co-opting a publicly available network that can go through corporate firewalls, and makes use of SSL for security purposes. SOAP is typically implemented on well-known platforms, such as servlets, at little or no cost. SOAP uses the Web server infrastructure you already have in place for your B2C applications; no additional infrastructure is required.
UDDI (Universal Description, Discovery, and Integration) is a public registry for all of the companies in the world to register their services under secure conditions. UDDI defines a standard way to publicize the services offered by a company. This discovery and visibility should revolutionize the communications puzzle. Any XML interoperability solution should seriously look at registries similar to UDDI to publish their services.
WSDL (Web Service Definition Language) is another standard that allows you to declare your services in XML, allowing you to automatically register those services in UDDI. WSDL is a structured way to define your services to the outside world. WSDL identifies input and output XMLs for each message between participating companies. Typically, WSDL documents for each message are exposed through UDDI.
The final effort required to adapt services infrastructure is to identify the business processes in a company and arrive at a series of refactored services that can be defined in XML. This process is similar to Object Oriented Analysis and Design (OOAD), where your domain object models are defined.
Similar to OOAD, UML (Unified Modeling Language) can quite effectively define what these services are, and what their inputs and outputs are. And the UML can be used directly to generate the necessary WSDL and UDDI documents. Once these services are identified, registered companies can start to collaborate using these well-defined API-level XML services.
As mentioned earlier, when a company has invested in B2C infrastructure (J2EE, WebLogic, WebSphere, etc.), it already has the needed infrastructure to participate in XML communication. SOAP implementations are readily available for all J2EE Web servers. These solutions allow you to immediately converse with the outside world using XML. When a proper Java architecture is chosen to develop your HTML pages, it if fairly easy to use the same architecture to develop XML messages in place of HTML. Technologies such as Transparent Data Pipelines can be readily used (with no changes) to serve the same HTML data as XML data.
No one can deny the immense value provided by the EAI programming suites, the cost of which may run into a few million dollars. At their core, these programming suites consist of:
But often the solutions offered by SOAP sitting on top of your favorite Web server can more than adequately solve the inter- company communication problem. Here are the components of such a simplified solution:
J2SE and J2EE have a large number of APIs that can help the implementer make this XML vision a reality today. The relevant APIs are Sun's JAX Pack (JAXP, JAXB, JAXM, JAX-RPC, JAXR) and EJBS/JMS. The JAX Pack APIs are discussed in detail in Al Saganich's "Hangin' with the Jax Pack" series.
JAXP (Java API for XML Processing) is your Level 1 support for XML. This API allows you to parse XML documents and to use third-party parsers in a vendor-independent fashion. Before JAXP, one had to use vendor-specific classes to access the XML parsing functionality; both SAX and DOM parsers. JAXP is dearly loved by Java programmers, as it reduces the impedance mismatch between Java objects and XML representation and provides a reasonable solution for mapping between the two.
Of the APIs discussed here, JAXM (Java API for XML Messaging) is truly relevant for our purposes. First of all, it is not hiding behind an object veil (as SOAP does) and declares itself a "message oriented" protocol, allowing you to work with messages directly. In an interconnected enterprise this level of abstraction is very productive, as one can now write Java programs that simply send XML messages with minimal fanfare -- just create an XML message and send it; don't worry about low-level things like SOAP. Expected support in JAXM for guranteed delivery and security are quite exciting and relevant for this message-oriented paradigm. In addition, JAXM also supports synchronous/asynchronous calls with acknowledgements and the fire/forget messaging option.
JAX-RPC (Java API for XML-based RPC) is more closely related to SOAP and WSDL than JAXM is. While JAXM is message-oriented, JAX-RPC is call-oriented, with a set of well-defined Java objects (defined by WSDL). This is a reasonable assumption if you are dealing with Java clients and Java servers, as you rarely have to deal with XML messages directly. There is no question of impedance mismatch, but obviously your granularity is finer. It is, in a sense, command-oriented.
JAXR (Java API for XML Registries) is available to work with UDDI and ebXML service registries. The goal here is again to provide a common API for working with multiple registries. This specification and API is currently in its beginning stages. The key challenge/success of this API is to simplify the wide open data model presented by the service registries. To understand the task at hand of representing a UDDI registry, refer to the UDDI data model documents.
Finally, EJBS/JMS have a role to play in the interconnected enterprise as well. If JAXM is providing message-oriented services off of an HTTP server, a JMS/EJB combination gives you similar capabilities on an EJB server. An EJB server can also provide transactionally-secure ways of dealing with messages. As this solution also demands a JMS server, the store/forward facilities are automatically taken into consideration. This EJB/JMS combination has the desirable characteristics of store/forward messaging, the publish/subscribe model, and being transactionally secure. The drawbacks are related to the additional costs imposed by the requirements of running EJB and JMS servers.
Almost every software vendor has a set of XML parsers, and JAXP provides a uniform way to deal with all of these vendors. Xalan and Xerces from Apache.org are a popular combination of tools that can parse, generate, and transform XML documents. A release of JAXP includes both of these tools.
The 2002 O'Reilly Emerging Technologies Conference explored how P2P and Web services are coming together in a new Internet operating system.
This standard is still in its API level and the JAX Pack from Sun can satisfy this requirement at this time. Potentially, all implementations of J2EE will include this toolset. One can use Tomcat and Jax Pack for many of these needs today.
This is an often neglected area. The question here is, "How can pervasive relational data get converted to XML data sets so that it can transported and used?" The expectation from Sun is that you will use the JDBC and other Java Data APIs to retrieve data, and somehow generate Java objects and then convert them to XML. There is a new breed of tools that can overcome this impedance mismatch and provide a better declarative route to generate XML, thereby satisfying the need for declarative Web services as well. The two tools that come to mind are XSQL from Oracle, and Aspire/J2EE from Active Intellect. Although they use different approaches, both products allow you generate XML on the fly from relational databases (and other data sources if need be) declaratively.
Satya Komatineni is the CTO at Indent, Inc. and the author of Aspire, an open source web development RAD tool for J2EE/XML.
Return to ONJava.com.
Copyright © 2009 O'Reilly Media, Inc.