Leveraging Architecture Adapters in the Case Study
Leveraging Architecture Adapters in the Case Study
The P.T. Monday Coffee Company application uses architecture adapters only when interfacing with Web Services. Further, Axis generates the architecture adapters, and they have no impact on developers in terms of coding responsibilities. On the other hand, the build environment is definitely more complex with the extra generation steps. Direct usage of architecture adapters occurs in three places:
-
When service behaviors require interactions with external Web Services
-
When you expose service behaviors as Web Services
-
When service behaviors must interact with the service directory to publish or locate a service
In the case of interacting with the service directory, you use an off-the-shelf package, UDDI4J, to interact with the service directory. The client-side class library handles service interactions. It is likely that developers built much of the client-side access library with a tool similar to the Apache Axis WSDL2Java tool.
Generation of the architecture adapters that connect SOAP messages to the service behaviors occurs upon deployment of a service through the administration facilities of Apache Axis, as discussed in this chapter and the previous chapter. Generation of the architecture adapters from WSDL files, for your service behaviors to access outside Web Services, occurs using the WSDL4Java tool at build time for your application.
Identifying Important Classes and Files in the Case Study
Table 4-1 shows the primary code discussed in this chapter that you should browse in the downloaded source code.
|
FILE |
LOCATION |
DESCRIPTION |
|---|---|---|
|
CustomerCollectionImpl.java |
src\com\servicefoundry\books\
|
The primary Java class that becomes a Web Service by using the Apache Axis deployment mechanisms. This class uses JDO as a persistence mechanism. |
|
CustomerImpl.java |
src\com\servicefoundry\books\webservices\entities |
A class whose object instances represent customers in your application. In this chapter, the customer implementation is not aWeb Service; however, the customer collection implementation does serialize instances of customers to your client application. |
|
CustomerInformationImpl.java |
src\com\servicefoundry\books\webservices\entities |
Additional information about customers, such as credit card
|
|
TestCustomerCollection WebService |
src\com\servicefoundry\books\webservices\tests |
A client-side test program that uses the client-side architecture adapter to access the customer collection Web Service. |
Using Ant Targets to Run the Case Study
Table 4-2 describes the targets to run for the ant environment to see the programs and chapter samples in operation. Before running any samples, be sure you read and perform all of the install steps in Appendix A.
|
TARGET |
DESCRIPTION |
|---|---|
|
testcustomercollectionwebservice |
This runs the TestCustomerCollection WebService program. You must have deployed the Web Services according to the instructions in Appendix A. |
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
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
