March 28, 2002

United Front

Web services are only a partial answer to the complexities of enterprise application integration. Complementary approaches may enable a full solution

By Art Taylor

Web services have garnered a lot of press in recent months, which is unusual for a technology that's largely untested. No doubt, Web services have the potential to transform information interchange, an important capability for any information-driven enterprise, but are they the final answer to this challenge?

Not necessarily. As I'll explain in this article, even assuming that Web services deliver to their full potential, you would still have work to do to develop strategic business applications for information interchange. Fortunately, Java 2 Enterprise Edition (J2EE) technology provides a potential complement to Web services; together, the two technological approaches can provide a cost-effective, strategic business application solution.

What They Are, What They Aren't

Although you'd never know it from the hype, Web services don't represent a specific technology. The most popular definition (and there are several of them) is relatively open-ended: Web services are components available over the Internet via HTTP and involve the exchange of messages in XML format.

For example, a supplier could create (or expose) a Web service that allows stock levels to be queried, giving consumers of this service dynamic access to this information using a consistent, well-known protocol.

This definition doesn't imply a structure or format for the application using (or consuming) the service; rather, the application could be any application written in any language. So even though some great tools will soon be available to create Web services relatively easily, you would still need to build an application that uses them, whether it's based on J2EE, .Net, Visual Basic, or Cobol.

Web services imply a loosely coupled architecture in which existing disparate applications interoperate and exchange information. Applications can be integrated regardless of implementation language or operating environment. This approach is relatively coarse-grained and operates at a higher level of abstraction than the protocols currently used to perform this task (such as RPC, CORBA or J2EE components, and EDI).

Web services may offer more flexibility for IT managers who want to widely expose a large, diverse set of information assets across a variety of platforms and systems. But as I'll explain in more detail later, most of the open standards involved (such as simple object access protocol [SOAP], universal description, discovery, and integration [UDDI], and Web services description language [WSDL]) are still in flux, and important issues such as security and transaction management remain unresolved.

The potential benefits I've described could have an effect on business information systems that require a high degree of interoperability, but do Web services imply a radically new process for creating all enterprise applications? Not really. A large number of existing applications, and applications yet to be written, have no need to interoperate with other applications per se. These applications have little more to do than extract data from existing databases and provide a user interface; for them, Web services would have little relevance.

Gaps in the Wall

Some experts have suggested refactoring existing applications to take advantage of this new approach. But before doing so, you must evaluate the risk vs. potential value involved. Furthermore, when evaluating alternatives, you should consider the J2EE architectural approach both as an alternative and as a complement. Here's why: Historically, J2EE and the distributed object framework it represents have involved tightly coupled components — those that contain a great deal of knowledge about the business process and its data. The knowledge of these components is reflected in the code used to develop the component. Conversely, as I mentioned earlier, Web services ostensibly involve a more loosely coupled architecture in which components negotiate to determine services and then exchange XML documents that detail the information they will receive from the Web service (provide the binding).

On the surface, these are two distinctly different approaches to creating an enterprise application. But does the Web services approach really create a loosely coupled application — an application that doesn't require drastic changes should the Web service change? Not necessarily. Rather, before we slip into euphoria, the variability of business data schemas must be considered carefully.

Consider, for example, a Web service-enabled data store containing customer intelligence information. This information would include details on the buying habits of customers and could be collected and consolidated by a vendor that would then allow this information to be accessed (for a fee) via a Web service. This customer information would almost certainly contain details about the products the customers have purchased. There's the catch: Data such as product categories, packaging, and other attributes can vary greatly even within an industry. To solve these data incompatibilities, data processing filters would need to be developed to encapsulate business logic.

These programming efforts represent some degree of coupling of the front-end program — the consumer — to the Web service. Although there's much more flexibility for negotiating and selecting data binding information with Web services than with traditional J2EE components, the need to couple the application or component to the Web service still exists. (Good programming practice would isolate and encapsulate this processing, but it would still exist.) Even with the simplification and standards that Web services provide, these data issues would still need to be resolved.

I don't mean to imply Web services have no value. Rather, they have significant value for improving the process of business process integration — an important aspect of managing the supply chain and for the management of enterprise information assets as a whole. But the same data schema issues that have plagued IT for decades still exist and must be resolved. Fortunately, J2EE technology may be a partial answer.

Web Services and the J2EE Architecture

Comparing Web services to J2EE is a common but somewhat unfair exercise: Web services define information interchange and J2EE defines a set of technologies for delivering enterprise applications using distributed components. Nevertheless, if we are asked to consider Web services a "new development paradigm" — as we typically are — a comparison with J2EE isn't only justified, but necessary.

On a high level, .Net technology is similar to J2EE technology — they both represent a toolset for developing applications comprising distributed components. For Microsoft, Web services are an important and very visible part of the .Net architecture. The J2EE specification had no specific analog until Sun Microsystems added Web services to its Sun Open Net Environment (ONE) approach.

• Privacy
• Your California Privacy Rights
• Copyright © 2008 United Business Media LLC