Chapter 13: Exploring the Physical Tiers Pattern

Overview

Chapter 2, " Introducing the P.T. Monday Case Study," discussed the n-tier application architecture used to implement the P.T. Monday Coffee Company application. Within the architecture, the logic tier separates the business-specific logic from the Web tier's logic. The Web tier is responsible for facilitating interaction with users outside of the system through one or more different types of Web clients , such as a Web Service or a Web browser.

The P.T. Monday Coffee Company application's evolution has encouraged a logical separation of the Web tier and the logic tier, but that separation has not been enforced at deployment time. At this point, the separation between the Web tier and the logic tier is at development time only. At deployment time in the current services, the business logic embodied in the service implementation runs within a thread under the control of the Web Service container, Apache Axis, and indirectly through the Apache Tomcat process. This makes the logic tier physically deployed with the Web tier, not an independent logic tier.

You have not pursued physical separation of the tiers until this stage of the book for a couple of reasons. The first reason is simplicity. Apache Axis and most Web tier environments are easy to demonstrate and learn when you do not pursue physical tier separation. The second reason you did not pursue tier separation is necessity. Only in the previous three chapters did you start to see compelling reasons, though they were only subtly implied , to create physical separation between the Web tier and the logic tier.

The event patterns in the previous three chapters introduced the first real problems with not pursuing physical tier separation. Typically, event subscribers are not self-contained application components ; rather, they are gateways into larger applications that must react to events occurring within other application components. For example, when the Web Service that subscribes to a change in aremote Web Service receives an event, it is the beginning of a larger chain of events that occurs within your own application.

On the other hand, in an enterprise application, a change to a remote Web Service often ripples further than a single business object. The result of a change in a remote Web Service may change the state of running applications or there may be a whole chain of services affected by the change. Rather than have each event subscriber manage related business objects within its own process, it is often easier to delegate handling of events to a physically separate logic tier. This separate logic tier has the advantage of being separately deployed and configurable, and it has the ability to coordinate groups of threads without ceding control to an unknown environment, your acquired Web Services environment.

In this chapter, you will spend time looking more closely at the Web Service environment you used in the previous chapters. Specifically, you will look at how Apache Axis executes the Web Service and the service implementation as well as how the current application comes together in this highly componentized environment. You will then look deeper at a desired physical process state that adheres to your n-tier architecture and enforces the architecture at deployment time. This physical separation is the Physical Tiers architecture pattern. It is subtly different from the N-Tier Architecture pattern in that it enforces physical separation and goes beyond the logical concept of tiers and layers . You will enable the Physical Tiers architecture pattern with the Connector design pattern. The Connector pattern gives you a simple design to connect tiers that span physical boundaries.