Intelligent Enterprise

Better Insight for Business Decisions

RSS
Webcasts
Whitepapers
Subscribe
Home

March 28, 2002

/020328/506feat3_1.jhtml">

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

Continued from Page 1

The Sun ONE architecture embraces Web services but only as part of a comprehensive architectural solution. Sun ONE acknowledges the need for other technologies beyond distributed components but doesn't reduce their prominence in deference to Web services. In fact, the Sun ONE architecture places emphasis on Data Applications Reports and Transactions and further clarifies the need to examine the application requirements to determine the best solution technology. Sun ONE doesn't simply recommend Web services as an all-encompassing solution.

To contrast the architectural differences of J2EE and Web services, look at how they are defined. Web services are defined in terms of messages and the request/response cycles generated by the services. Web services use HTTP protocol and transmit data in XML format. J2EE applications aren't defined in terms of messages, but instead involve a collection of J2EE components (Enterprise Java Beans [EJB], Java Server Pages [JSPs], and servlets) that communicate via several protocols, including, in the case of EJB, binary protocols.

But despite their differences, Web services and J2EE are complementary. EJB, the middleware components of J2EE, can be exposed as Web services on a number of application servers, including BEA Systems' WebLogic and IBM WebSphere. J2EE Web components (JSPs and servlets) and client components (applets and Web Start applications) can also be developed as consumers of Web services.

For example, an enterprise application that needs to access an information asset could do so by consuming a Web service. This application front end could be implemented using C# and acting as a consumer of a Web service created with a C# component deployed in a Web server that exposes that service. Alternatively, the same C# front end could consume a Web service created using an EJB deployed in a J2EE-compliant application server. Yet another alternative would be to have a JSP front end consume a Web service deployed and exposed within Microsoft IIS.

The latter two examples highlight one of the more important values of Web services: Components or applications written in different languages can easily exchange data. They also demonstrate that the concept of Web services doesn't specify a technology; rather, it specifies a development paradigm for the interaction of components or applications. The technology is irrelevant as long as the components or applications communicate via XML-formatted messages on top of recommended standards.

J2EE offers a large bag of tricks, and in practice, Web services will only be one of the tricks used by developers. Using an open-minded approach where all technologies are considered based on merit, other J2EE technologies will undoubtedly prove more appropriate for many services (for example, EJB Entity Beans for interacting with data in a relational database or EJB Message Beans for local asynchronous transactions).

Future of Web Services and the Application Server

When you step back from all the hype over Web services, you begin to get a clearer picture of what's being proposed. You also get a strong sense of deja vu. We've heard this all before: EDI, distributed components, ActiveX, and more recently XML have all been tagged as silver bullets in the past.

Rate This Article

Comments:

Optional e-mail address:

The reality is that existing application interoperability issues are difficult to solve. These issues — such as different application security models, schema incompatibilities, differences in transaction management, and complex failure scenarios — aren't completely addressed by SOAP, .Net, ebXML, or any other specification currently proposed. (See the sidebar "What About Transactional Integrity?")

It's the nature of capitalistic commerce that our organizational systems — our means of managing our information assets — vary significantly. Standards such as SOAP, UDDI, and WSDL can help manage these disparities, but only universally adopted schemas and standard transactional and security models across vast areas of commerce would make simple, "pluggable" interoperability the norm. Given our propensity to be different (and the economic benefits to doing so), universally adopted models are unlikely to happen in the near future.

Art Taylor [taylorart@blast.net] is an independent consultant and author currently at work on several technical books on Java technology. He has more than 17 years experience in the IT business.

WHAT ABOUT TRANSACTIONAL INTEGRITY?

Significant technical challenges remain before Web services can become mainstream

No consistent transactional model yet exists for Web services. The current expectation is that the underlying implementation of SOAP will manage the transaction — not a very attractive approach for complex business processes and a difficult approach to merge with J2EE applications attempting to use container-managed transactions. An Organization for the Advancement of Structured Information Standards (OASIS) group is working on a vendor-neutral transaction model (see Resources), but prominent vendors have yet to embrace this effort in any meaningful way, with Microsoft, IBM, and Oracle pursuing different approaches.

That "Insecure" Feeling
Security is another issue that isn't addressed in the current SOAP specification. Again, the architects of the underlying implementations are left to implement their own security.

This approach may work with simple operations, but the integration of numerous complex systems will require significant effort.

Stepping Up: Performance
Network latency bottlenecks may wreak havoc on applications that require synchronous access to Web services. Alternatively, for applications asynchronously accessing such services, currently no specific model can detect and manage failed transactions. This may have special significance for business intelligence (BI) applications that often retrieve large amounts of business information for reporting purposes.

The larger the Web service payload, the more likely a performance impact.

Getting the Message
Asynchronous use of Web services raises other issues that aren't addressed by the SOAP specification. For instance, if a SOAP transaction can't reach its destination, how will it be managed? These quality of service issues are nontrivial and must be addressed by complex applications.

Your Schema, My Schema
An issue that continues to persist in data interchange is that of schema incompatibilities. The "dynamic discovery" process won't manage all aspects of information exchange. An application can't dynamically discover a service, gather the binding information, and begin processing without some knowledge of the meaning behind the schema.

Consider this example. If you and I would like to exchange product information, but my product has three levels of product categories and yours has only one, how will this difference be managed in the interchange process? Say my product also has a "stock date" attribute — is that the date the product was placed into stock, or is it the date it will be restocked (if there is no stock)? These semantic issues (sometimes referred to as "the ontology of data interchange") involve a shared understanding of data and must be resolved for any Web service. The process of dynamic discovery in and of itself doesn't solve this problem.