Summary

The Connector pattern focuses on the mechanics of communicating between physical tiers. This pattern is critical for allowing communication from a Web Service to a stand-alone application or a separate logic tier . This chapter covered the necessity of physical tiers by first looking at the Physical Tiers architecture pattern and then looking at two scenarios that illustrate the need for the Physical Tiers pattern. The first of these illustrations was a stand-alone application that uses a Web tier to interact with event services that reside in the Web Service architecture. The second of the illustrations showed some downsides to having asingle physical tier deployed entirely within an Apache Tomcat container. The Connector design pattern illustrates how to facilitate communication between physical tiers.

Application builders can often implement this pattern with native support in their chosen Web Service environment. For example, Apache Axis contains an EJB provider that separates the Web Service interactions from the fulfillment of the behavior portion of a Web Service operation. With the Connector pattern, the Web Service communicates to a container hosting EJBs to execute business logic and return the results back to the client. In this chapter, you implemented this functionality using a service implementation and Java's RMI implementation.

Because of this pattern, much of the P.T. Monday Coffee Company application can become a physically separated logic tier with both stand-alone applications and Web Services communicating through the same instances of the classes in the logic tier. This centralization helps you optimize the business logic, data caching, and memory footprint of the entire software stack. You also increase your options for application deployment. An administrator can deploy the logic tier to one computer system while the Web tier deploys to another computer system. Further, the Web tier's footprint shrinks and you no longer have to deploy JDO and JDBC to the Web tier applications.