Overview

Earlier in the book we explained how middle- tier patterns don't necessarily dictate a physical deployment designation. In reality, any of the following patterns, whether they are considered design-oriented, architectural-oriented, or the like, can be implemented and physically deployed anywhere in an application. The middle-tier "category" does not necessarily predicate that these patterns belong on a server somewhere physically separated from a user client. When considering the location transparency of Web services, what makes up a middle tier can mean any logical combination of pattern, structure, or logic. The only really identifying characteristic among these patterns is the fact that they typically help implement components that:

• Do not provide any graphical or console interface characteristics (aside from debugging, e.g., using trace output to a debugger)

• House business rules

• Do not directly interact with persistent storage

That does not mean these cannot be applied to some graphical interface or even be part of a sophisticated data persistence design. These patterns simply belong to the category most likely to house the nonvisual business rules of the application.

Because middle-tier patterns cannot simply be considered strictly "design" patterns, they are more difficult to classify. Depending on how you implement them, they may have the ability to be part of several more traditional categories (see Design Patterns ”Elements of Reusable Object-Oriented Software ^[1] ” GoF). For example, the Product Manager pattern can be considered both creational and behavioral . The middle-tier classification only helps group a broadened combination of "middleware-friendly" patterns without having to give them a more traditional classification that you would find in these other sources of information. That is the point. We wouldn't have even organized them at all except that they become difficult to reference once there are several patterns to select from. For these reasons, the following patterns can be classified as middle-tier patterns.

^[1] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissades. Addison-Wesley, 1995. ISBN 0-201-63361-2.

Most of the following examples keep with the general solution "theme" and use our credit card processing application to drive the example code. We cover the following patterns in this chapter:

Chained Service Factory ” Creating a single entry point for Web services

Unchained Service Factory ” A late-bound single entry point for the Web services

Product Manager ” Handling unmanaged code in a managed way

Service Fa §ade ” Delegating complex logic from Web services

Abstract Packet ” Passing complex parameter sets into Web services

Packet Translator ” Translating those complex parameters sets

With important (and related ) mention to the following design patterns:

• Factory Method (GoF)

• Abstract Factory (GoF)

• Fa §ade (GoF)

• Builder (GoF)

• Value Object (Sun)

• Proxy (GoF)

• Adapter (GoF)