Chapter 3: Exploring the Service-Oriented Architecture Pattern

Overview

Until web services became a reality, making applications communicate across the Internet was a serious challenge to application programmers. Predating Web Services are three techniques, each of which vied for programmer's attention but none of which achieved ubiquity for communicating across the Internet:

• You could choose to implement your services using a particular platform, such as the Java 2 Standard Edition (J2SE) with its Remote Method Invocation (RMI) capabilities as the mechanism for communication.

• You could choose a heavier-weight standardized model, such as the Common Object Request Broker Architecture (CORBA).

• You could roll your own service access and usage protocol.

Each of these techniques (and others like them) has dramatic downsides, as well as some benefits. With Java's RMI mechanism, a client to your service is bound to being a Java program itself. Using CORBA creates a barrier to entry to your service in terms of complexity and nonconventional knowledge, yet it loosens the requirement on a particular implementation language. In fact, components and clients can freely mix implementation languages with CORBA mechanisms, facilitating the communication between the different languages. Both RMI and CORBA have a common theme: They extend the object-oriented paradigm to a distributed system. Finally, rolling your own service communication protocol is always exciting, but the clients to your service must learn your communication protocol in addition to the Application Programming Interface (API) you are surfacing . This technique is fine if you use a single service, but imagine trying to integrate 100 services from different people who chose to implement their own protocol.

Web Services embody an important shift in computing. They stress standardized communication between services above the particular platform and implementation of services. To achieve a common communication mechanism that all languages and platforms can use, Web Services rely heavily on standardized Extensible Markup Language (XML)-based mechanisms for exchanging information.

Five years ago, the requirement to move into and out of XML for every request would have brought performance to a crawl. Today, the increase in computing power and network bandwidth (through Moore's Law) makes it reasonable to insert conversions between XML and a platform language to both ends of a communication path . Further, over the past five years , XML parsing and standard document definitions have matured to a point where most programmers have some understanding of XML document parsing and the ability to understand document definitions, if necessary.

The basis of Web Services is the service-oriented architecture. This architecture pattern outlines a simple, yet effective, set of components, responsibilities, and collaborations that promote implementation and location transparency. The Web Service architecture is an implementation of the service-oriented architecture. Taking the time to understand what a service-oriented architecture is helps to understand Web Services and how you can apply Web Services to the integration scenarios in the P.T. Monday Coffee Company application.

In this chapter, you will see the Service-Oriented Architecture pattern in detail. You also will look at how Web Services embody this architecture and get your first look at the Apache Axis environment, which is an implementation of the Web Service environment. All of these topics give a foundation for how you will use Web Services and Apache Axis in the P.T Monday Coffee Company application.