XML Protocols

Analysts have predicted that by the end of 2003, 80% of interapplication traffic will be XML-based. Furthermore, they predict that such traffic will grow 10 times more quickly than application-to-person traffic. This is being driven by the growing adoption of XML by the business community and the increasing maturity of Web technology around XML transport, routing, and transformation.

It's also generally agreed that it's the simple and lightweight nature of XML solutions that fuels their rapid uptake and allows them to be used by a wider developer community than more complex "enterprise" technologies.

Basically, XML will democratize Internet software.

Not to say that existing technologies will be swept aside in a rush to rebuild the world in XML. Enterprise systems such as J2EE and CORBA provide the environment for building highly scalable, secure, transactional, or fault-tolerant systems. By combining the strengths of XML and enterprise systems, we have the opportunity to provide these "bullet-proof" services to a wider Web audience.

Most software vendors plan to offer XML-based access to their applications and services. The clear assumption is that these enterprise-quality servers will remain the core of the corporate systems, but that the Internet application infrastructure will consist of XML-based technologies.

This article describes the current "state of the art" in using XML with CORBA and J2EE.

Web Services
The opportunities provided by XML are not limited to building gateways to legacy systems. XML has the potential to transform the model for Web development. XML-based technologies such as SOAP and WSDL provide the means to build a "Web Services" model where business transactions can be catalogued via UDDI and WSDL, then invoked over the Web via SOAP requests.

The Internet services of the future will comprise many software elements. They'll be loosely coupled and accessible over the Internet using XML technologies such as SOAP, rather than tightly coupled, monolithic integrations.

These Web Services are just starting to appear, but it's clear they'll become the basis for an entirely new way of building Internet applications. In a sense the design center for these new applications has become the Internet or Web Services, rather than the underlying enterprise servers, databases, or messaging systems.

Just as the Web server created a new, less-skilled design center, populated by the "Webmaster," the SOAP-based XML Web Services will do the same for business applications. Business processes will be published, customized, and integrated using graphical tools and scripting technologies.

The result of this shift from skilled systems developers to a new class of business developers will be to devolve the responsibility for developing business applications away from corporate IT departments. Line managers and end users will be able to build the business systems they want - themselves.

These new Web Services developers need tools that allow them to concentrate on business problems, not enterprise integration issues. The real challenge for J2EE and CORBA developers is to broaden their technology base to include this community, rather than treating XML and the Web as merely an adjunct to their existing product set.

Using XML Within
Enterprise Systems
Given the increasing number of Web Services available via XML, it's becoming more important for enterprise developers to deal with XML documents directly. While it's possible to manipulate XML documents as plain strings, this is very cumbersome for anything beyond the simplest of formats. Both CORBA and J2EE provide type systems rich enough to represent XML documents in a simpler and more efficient manner.

Enterprise vendors are starting to address this direct use of XML within their environments, though in both cases the technologies are very new, hence support is limited.

The OMG has developed a standard that defines how XML documents may be represented as CORBA value types - the XML/Value specification. Value types are a relatively new feature in CORBA; unlike other CORBA objects, which are passed by reference, value types explicitly contain data that may be passed from one CORBA application to another (pass by value).

The XML/Value specification considers two distinct cases: dynamic and static scenarios (see Figure 1). These are analogous to the dynamic and static interfaces available in the ordinary CORBA model.

In the dynamic scenario the CORBA programmer has no knowledge of the type of XML document that must be manipulated. In this case the only API that can be used is a CORBA version of the DOM. This XML/Value DOM interface has a number of advantages for the CORBA developer over the existing Java or C++ DOM APIs:

• It provides a standard API that insulates developers from the underlying DOM implementation.
• The DOM value types may be sent to another CORBA application without having to parse the XML document a second time.

The static scenario provides a much tighter coupling of XML and CORBA. It depends on a DTD being available to define the format of the messages to be used. This DTD is parsed to generate hard-coded value types that correspond to the XML document defined in the DTD. Rather than using the generic DOM-style API, the developer can manipulate the value types directly, like any other native programming object. The generated code can also validate the XML document to ensure that it's both well formed and valid.

The same commercial and technical opportunities have led to new developments in integrating XML with J2EE. Although J2EE is more Web-friendly than CORBA, it still poses significant end-to-end integration challenges. XML technology is beginning to appear, and Sun Microsystems has recently announced the JAX extensions to the Java platform. JAX technologies provide low-level programming APIs that allow Java developers to parse, manipulate, and transmit XML documents:

JAXP-JAX Parsing: This is Sun's toolkit for parsing XML in Java and supports both DOM and SAX. There are many other XML parsing toolkits available for Java; one of the most popular is the Xerces parser, available from the Apache project (see the Resources section at the end of the article).

JAXM-JAX Messaging: Provides an API for XML messaging based on ebXML.

JAXB-JAX Data Binding: Provides functionality that's directly analogous to the CORBA XML/Value static scenario. It's still at an early review stage and there's no technology available as yet. XML Schemas and DTDs will be parsed to create Java classes that manipulate the documents in terms of native Java types. SOAP and ebXML are the two major protocols promoted for use in Internet applications. SOAP is a simple protocol ideal for lightweight, everyday use. ebXML is an ambitious framework designed for high-end use, covering business models, processes, and collaborations. In the past SOAP and ebXML were seen as rivals. However, ebXML now uses SOAP messaging internally, so a potentially damaging protocol war seems to have been averted.

There are several low-level SOAP toolkits available (the Apache Software Foundation has developed a widely used library). These low-level APIs and encoding mechanisms allow developers to build SOAP systems from the ground up.

More sophisticated J2EE/SOAP tools read WSDL definitions of SOAP-based Web Services and use this information to generate matching EJB stubs (see Figure 2). These stubs present native Java APIs, but translate the requests into SOAP for invocation on the back-end Web Services.

Accessing Enterprise Systems from XML
While there's a real need to provide XML access from within CORBA and J2EE, at Cape Clear we believe that it's even more important to provide access in the other direction: allow XML users to invoke CORBA and J2EE servers. In other words, open up these enterprise-level services to a wider, Web-based community by enabling them as Web Services.

The OMG has started working on standardizing this for CORBA systems through its SOAP/CORBA Interworking RFP, but it's still at a preliminary stage (see Figure 3). Meanwhile, commercial vendors have started shipping SOAP/ CORBA products. SOAP has usually been selected over other protocols because of its existing user base and the widespread support for the protocol throughout the industry.

At a minimum, SOAP/CORBA tools need to parse the CORBA IDL and generate corresponding SOAP schemas. However, to be used as Web Services, WSDL definitions also need to be generated and registered with a WSDL server on the Web.

In practice, the J2EE case is very similar to the CORBA one. Instead of parsing IDL files, the SOAP mapping tools can perform Java reflection on a bean to generate a SOAP schema representation. This can be used to generate WSDL representations of the bean interfaces and to dynamically map SOAP requests onto EJB invocations.

Unfortunately there's little cooperation as yet between the CORBA and J2EE communities in this area (see Figure 4). Standards-neutral Web Services platforms can effectively mask the difference between back-end enterprise systems. These services may be implemented in terms of CORBA, J2EE, .NET, or whatever, but they can all be accessed via standard XML-based mechanisms such as UDDI, WSDL, and SOAP.

This is just the beginning. The continuing democratization of software will force vendors to make it easier for end users to combine and customize Web Services. Today's solutions are based around APIs and platforms, but expect to see customer demand drive the development of graphical development environments that deal with Web Services at a native level. Broad adoption and ease-of-use are the basic prerequisites for automating this "Business Internet."

While there has been a huge amount of hype about XML recently, it's important to see things in perspective. Web Services technology around SOAP, WSDL, and UDDI will dominate everyday transactions on the Internet; however, existing enterprise technologies such as CORBA and J2EE will continue to be the solutions of choice for "industrial strength" services within corporations. The exciting and compelling opportunities lie in the combination of these two technologies to provide real business services to ordinary users and, for the first time, to empower them to customize these services for their own needs.

Resources

1. Cape Clear Software provides a range of products supporting Web Services development, including CapeConnect, a Web Services platform for J2EE and CORBA systems: www.capeclear.com
2. The W3C Web site is the best place to look for the latest versions of XML standards: www.w3c.org
3. The latest news on XML and CORBA: www.omg.org
4. Sun's site for J2EE and XML: http://java.sun.com/xml
5. The UDDI initiative: www.uddi.org
6. The draft WSDL specification: http://msdn.microsoft.com/xml/general/wsdl.asp
7. Information on the ebXML specifications: www.ebxml.org
8. The XML-specific software developed by the Apache project: www.apache.org/xml
9. A public directory of existing Web Services: www.xmethods.com

Published Jun. 3, 2001— Reads 8,000
Copyright © 2001 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.

Related Links

▪ Figure 1

▪ Figure 2

▪ Figure 3

▪ Figure 4

About Hugh Grant
Hugh Grant is founder and chief technology officer of Cape Clear
Software Limited, a leading provider of XML infrastructure. He holds
degrees in mathematics and computation from Oxford University and
Trinity College, Dublin.