Application architecture has somewhat fuzzy lines drawn with respect to where application architecture
Architecture goes through
during which you choose and recommend technologies for system implementation. In the process of choosing those technologies and
Table 2-5 contains a list of decisions and the simplified reasons for those decisions. In many cases, the decisions are based on deeper requirements or experience that is not portrayed entirely in the requirements listed.
The Java Platform is ideal for deploying Web Services because of its maturity and first-class integration into most Web Service platforms.
Java Data Objects (JDO)
The persistence mechanism to use from the Java platform is a difficult choice. There will always be programmers who can handle databases through the JDBC Data Access API, but you are looking for a more natural programming environment. The JDO specification and
The Apache Tomcat application server is free, mature, and common in the business world. That combination creates a competitive environment for hosting your Web Service technologies.
Although not as mature as Apache Tomcat, Apache Axis is shaping up to be both competitive and robust in terms of supporting different programming environments. Apache Axis will be your choice for the Web Service environment. It also plugs
Choosing a database is a tricky proposition. You need it to be robust and manageable while maintaining a low total cost of ownership. MySQL is an
This is a JDBC driver for MySQL. JDO uses a JDBC driver for accessing the database.
Choosing the Java platform and JDO as the internal service implementation and persistence model is difficult to legitimize without completely exposing the requirements and architecture process. The primary reason for the selection is the open and accessible standards through the Java Community Process (JCP),
The high-level application structure you use is an important place to start the application case study. The requirements of the application help to determine the structure of the application. Fortunately, where requirements leave off, architectural patterns begin. Three architectural patterns are of interest as you get started. The
After reviewing each of these important architectural patterns, you will finally produce the overall architecture of the P.T. Monday Coffee Company application. The basic architecture presented is a derivative of the patterns presented in the
The Layers architectural pattern is basic in nature but important in practice. The essence of the pattern is that you should design applications in layers, with each layer representing a
Layers typically stack on top of one another, building capabilities of the overall application, as shown in Figure 2-3. It is common that each layer
Figure 2-3: Layers architectural pattern
The most difficult part of working with layers is determining what layers to separate and how to embody the separation between the layers. The layer separation should make sense from a technical grouping standpoint as well as an organizational structure standpoint. Keep in mind that the technical content will outlast your personnel structure, so be careful to consider technical merit as the primary organizational principle. Typical layers are the presentation layer, the business content layer, the persistence layer, and the client layer. For example, the concerns of presentation to a browser are
You can create separation between layers in different ways. It is entirely possible to implement architecture with layers yet have the entire application run within a single physical process. In this scenario, you only leverage the layered approach at development time, not at deployment time. You can also separate layers by process on a single computer or by process on separate computers. This technique introduces performance penalties in terms of intercomponent communication, but you may be able to compensate for the performance loss by the flexibility in which you can deploy each layer. Further, each layer can focus on optimization within their own components as long as they
The N-Tier Architecture pattern is a generalization of a three-tier architectural pattern. The three-tier architecture consisted of a workstation presentation, the business logic, and a database and the logic to support it. In today's component architectures, including Web Services, a three-tier architecture simply does not properly portray the flexibility with which you can use a component architecture.
A description of the tiers as well as a description of how the tiers communicate typically
Figure 2-4: N-Tier Architecture pattern
Looking back at the case study requirements (including B1, B2, F3, and F8), you can see that there are multiple access points to your system. Users can access your system through a visual interface, and programs can access your system through a programmatic API. You do not
By locking yourself into a three-tier architecture, you may inhibit your flexibility to create a malleable system that fulfills as many requirements and scenarios as possible. The n-tier architecture will suit your requirements and give developers and designers a better place to start than simply identifying the Layers pattern.
The J2EE architectural blueprints expound further on n-tier architectures. The more detail and examples that you, as
Examples of J2EE application architecture are
The three-tier J2EE base implementation consists of a client tier, a middle tier, and an enterprise information services tier, as shown in Figure 2-5. The middle tier is more complex than a traditional middle tier and facilitates both rendering for
Figure 2-5: J2EE architectural blueprint
Variations of the J2EE architecture include the insertion of additional tiers between the middle tier and the client tier. For example, a Webtop (a thin client that contains a Java operating system)
One of the problems with layered architectures comes in the development of a product on top of a layered architecture. Business logic developers adhering to the strict definition of tiers or layers will want to build interfaces
The P.T. Monday Coffee Company application structure
Figure 2-6: High-level application structure
The application structure consists of the following:
Client tier: This tier contains the different devices and mechanisms your customers will use to access the application. Your two primary accessors are users accessing the application from a browser and other computers accessing the Web Services that you expose. The primary support protocols are Extensible HTML (XHTML) over HTTP and Simple Object Access Protocol (SOAP) over HTTP. Your implementation must be flexible enough to adapt to other channels of access, perhaps with the addition of a tier to support the other access channel, such as the Webtop in the J2EE example.
Web tier: This tier has two responsibilities: accepting requests from browser-based clients and accepting requests from other business logic tiers accessing logic through a programmatic API. Both types of
requestsforward business logic to the business logic tier for processing, and the Web tier handles any presentation or request/response transformations.
Business logic tier: This tier contains the logic that the application must use to fulfill
userrequirements. There are cases when business logic to fulfill a particular process actually exists outside of your application. In this case, the business logic tier contains the logic required to integrate the external logic into your own application.
Persistence tier: The ever-present database makes up the persistence tier. Although no explicit coding is required in the presentation tier because of the technologies in use, it is important to
acknowledgeits existence up front so that you can consider it during deployment.
Although the client tier and the persistence tier are relatively straightforward and are
The Web tier facilitates the connection between client requests and the business logic that fulfills the client requests. There are a variety of ways to structure the Web tier depending on the types of clients it facilitates. The Web Service path facilitates the programmatic access to business logic, and a
There are two paths through the Web tier, as
Figure 2-7: Web tier components
This book does not cover the presentation path and the Front Controller pattern; see the "Additional Reading" section for more details on the presentation path. Your concern is the Web Service path through the Web tier. This book looks at how clients interact with business logic, how you leverage the Web Service environment in the Web tier, and how you structure business logic for access through the Web Service environment.
With respect to how the Apache Axis Web Service environment runs, you have some interesting issues. These issues are not fully addressed until Chapter 13, "Exploring the Physical Tiers Pattern." In short, there are different mechanisms for deploying a Web Service using the Apache Axis engine. Using the Java 2 Standard Edition (J2SE) and the simplest mechanism for developing Web Services with Axis, your business logic tier gets
The business logic tier handles the processing of all business logic and behavior that is not
In your application, you should be concerned with two types of business logic:
Objects that represent a physical business domain.
Objects that represent processes that your business logic must carry out. In many ways, business processes compose interactions between other business processes and activities as well as the objects that represent the physical business domain.
Depending on the type of technical infrastructure you use, there are additional forms of logic, such as declarative business rules, that help facilitate replacing behavior in one of the two primary categories of logic. This book does not focus on the more advanced systems and mechanisms for altering behaviors.
J2SE is the language of choice for implementing business logic in your application. Evolving Web Service standards could replace Java as the language of choice for complex business processes. Although it is important to keep track of these standards, they do not change the overall concepts behind what a business process is. Further, because this book focuses on Java, it leaves the topic of advanced business process metadata for your own extracurricular activities.
Four chapters discuss business object and business process structuring for Web Services. Although these patterns are
The J2EE architecture blueprint represents its logic tier with Enterprise JavaBeans (EJBs). By nature, EJBs run within their own container (a manageable context that applies to all of the classes running within it). By choosing to stay with J2SE technologies, you do not have the benefit of a first-class container mechanism, nor is it necessary for the concepts introduced in this book. I strongly suggest you take some time to understand the idea of a container [Volter] and the advantages that a container yields. The Physical Tiers pattern (see Chapter 13, "Exploring the Physical Tiers Pattern") yields more information on using a container mechanism, such as EJB or your own self-