July 12, 2011, 2:37 a.m.
posted by franni
If Web Services Is the Solution, What's the Problem?
We know from reading all trade journals, conference agendas, and marketing material that Web services is the solution to all our problems. Of course, by now we've got a loaded six-gun filled with silver bullets—OOP, CORBA, EJBs, etc.—and our problems are still around. IT professionals realize that technology in and of itself does not solve problems. It is the application of technology, used in its proper context, which facilitates the construction of robust systems that solve real business problems. In other words: Use the right tool for the right job. When talking about Web services, that job is application integration.
1 The Integration Problem
Application integration is a problem that has been around for a long time. Today's companies are looking for solutions that help effectively manage the changing business environment. Companies are looking for ways to preserve the value of existing software assets because the cost and time involved in recreating them in the latest and greatest programming language is prohibitive. IT executives must manage budget decreases, forcing an even more careful evaluation of build-versus-buy decisions, with the trend being to find ready-made parts to snap into the development process.
As companies merge and form alliances with strategic partners, disparate information systems must be integrated to form a synergistic business process to provide a comprehensive solution. And throughout all of this turbulence, executives are demanding that IT managers reduce the cost of creating, maintaining, and deploying applications!
To help companies find a solution to these problems, an industry has evolved around IT. In the last decade, there has been tremendous growth in this industry and the success of companies such as Crossworlds (now part of IBM) that specialize in integration, and products like IBM's MQSeries Integrator, are evidence of the vibrancy of this industry. It is business, not technology, that is driving the application integration market. And it is business, not technology, that has driven the creation of Web services.
2 The Rise of Web Services
Despite its meteoric rise, Web services did not appear overnight. It is the result of the convergence of trends in both application architecture and business needs. As people began to assemble large-scale solutions, they realized that many of the same lessons learned from creating robust software could be applied when integrating these applications. Many of these lessons became embodied in patterns, like those described by the Gang of Four, while others became established as best practices. However expressed, there were two patterns that kept recurring.
These patterns are reflected in the EJB component model. For example, a typical J2EE implementation is for business models to be expressed as a collection of stateless session EJBs, with their state persisted using an associated set of container managed EJBs. By using the implementation JNDI provided with the WAS, along with EJB homes, application developers can properly isolate business logic as a separate tier within an application.
However, the underlying themes that these patterns address are how applications should be coupled. Previous chapters presented in detail how to build a properly layered enterprise application. The goal with Web services is to present a well-described unified logical view into the business layer of the application.
3 A Shared Understanding: Why XML?
One step in solving the integration problem is to establish a universal way to represent structured data. The industry agreed upon XML primarily for two reasons: (1) XML is a simple, text-based mechanism that allows data to be exchanged between systems in a string format; (2) XML embraces the notion of metainformation. XML documents often conform to a XML Schema definition (XSD). This XML Schema provides a means to define the structure, content, and semantics of an XML document. In this regard it plays a role very similar to a Java class in that it governs the structure of its instances. In fact, XML documents that conform to a schema are said to be instance documents.
The use of XML Schema in this manner allows the validation of data to be represented external of any programming language and platform. For example, a schema can declare that its instance documents will have a tag called id, that it is a positiveInteger, and that it must be present in the document. When this instance document is received, the XML parser uses the schema as a means to validate it without the need to invoke application logic. However, this does not eliminate the need for application validation logic. For example, a schema cannot do dependence validation; that is, if the value of Element A is 100, then Element B must be either X or Y.
A second advantage to using XML is namespaces. A common problem is that names are frequently repeated; e.g., id. However, there could be many different uses of id. In some systems, this could be an integer, in others, it is a string. Namespaces provide an elegant solution to this problem. Using Java again as a reference, an XML namespace is like a Java package in that it fully qualifies elements. Therefore, within one instance document two elements may have an identical name only if they are uniquely qualified by different namespaces.
4 What Is a Web Service?
To this point, we've described the business rationale for Web services: application integration. We've also described technical issues with existing integration techniques and distributed computing solutions. But what exactly is a Web service and how does it address these problems? Here is the formal definition provided in IBM's paper defining the conceptual architecture of Web services.
It is these basic properties that give Web services the flexibility to be an effective enterprise integration solution. Businesses experience a direct benefit in adopting Web services because it formalizes the separation of interface, implementation, and transport protocol. Thus, rates of change can be effectively managed by allowing the service API to remain constant while the underlying network location and implementation change.