If Web Services Is the Solution, What's the Problem?





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,[1] while others became established as best practices. However expressed, there were two patterns that kept recurring.

[1] Design Patterns, Elements of Reusable Software, [Gamma]

  • Most fundamental is that distinct behavior should be isolated. In OO languages, when each class has a well-defined set of responsibilities, the result is an object model that has a cleanly factored set of interfaces. Adaptation to new business requirements results in minimal impact to existing classes, reducing the cost of development and testing.

  • There should be a layer of indirection in place when establishing a reference to an object. There are several techniques used to accomplish this, many of them covered in the Creational Patterns section in the Design Patterns book [Gamma].

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.

Defining Web Services

"A Web service is an interface that describes a collection of operations that are network accessible through standardized XML messaging. Web services fulfill a specific task of a set of tasks. A Web service is described using a standard, formal XML notion, called its service description, that provides all of the details necessary to interact with the service, including message formats (that detail the operation), transport protocols, and location."[2]


[2] http://www.ibm.com/software/solutions/webservices/pdf/WSCA.pdf; pg.6.

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.


     Python   SQL   Java   php   Perl 
     game development   web development   internet   *nix   graphics   hardware 
     telecommunications   C++ 
     Flash   Active Directory   Windows