Infrastructure for an Interconnected Enterprise
Pages: 1, 2
Role of Java in Fulfilling This XML Vision
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.
Return to ONJava.com.