Summary

The architecture adapter is a powerful pattern that allows you to treat two architectures and the communication between them as a single component. You are able to place specific responsibilities and expectations on a construct, the architecture adapter, that allows designers to concentrate on how to best facilitate the mediation between two different architecture styles.

Web Services with Java use architecture adapters in two locations: from the client Java program to SOAP and from SOAP to the Java service implementation. Of course, you need to keep in mind that once the Java service implementation is a Web Service, there is no requirement that you use the service from Java. Architecture adapters for C#, COBOL, or any other language are possible with the communication facilitated through the third architectural style embodied in Web Services.

You saw the design of the architecture adapters built into Apache Axis for offering Web Services, as well as the architecture adapters that Apache Axis' WSDL2Java tool builds for Java clients of Web Services. The client-side and server- side adapters are similar in design and serve reverse needs, one adapting Java to Web Services, the other adapting Web Services to Java. You deployed and used services through the architecture adapters to show the simplicity that isolation of architecture conversions to a single pattern brings to the programming environments.

At this point, you should have an adequate understanding of the mechanisms you will use to expose application functionality to the outside world. You have not spent considerable time on the service directory that your partners use to locate your services. In the next chapter, you will learn about service directories and the patterns inherent in them. Chapter 5, "Exploring the Service Directory Pattern," wraps up the discussion of Web Service foundation patterns, so you can move on to designing specific entities and constructs for use with Web Services.