Architecture Examples

This section describes three architecture designs. Deciding which architecture to choose can be reduced to identifying the following design objectives:

  • Application partitioning – The application itself might make better use of resources by segregating or collapsing the Web tier from the Application tier. If an application makes heavy use of static Web pages, JSP software, or servlet code, and minimal EJB architecture, it might make sense to horizontally scale the Web tier and have only one or two small application servers. Similarly, at the other end of the spectrum, it might make sense for an application to deploy all the servlet and EJB war, jar, and ear files on the same application server if there is a lot of servlet-to-EJB communication.

  • Security level – Separating the Web tier and Application Server tier with a firewall creates a more secure solution. The potential drawbacks include hardware and software costs, increased communication latencies between servlets and EJB components, and increased manageability costs.

  • Performance – In some cases, customers are willing to forego tight security advantages for increased performance. For example, the firewall between the Web tier and the Application Server tier might be considered overkill because the ingress traffic is already firewalled in front of the Web tier.

  • Scalability – Applications can be partitioned and deployed in two ways:

    • Horizontally scaled, where many small separate Web systems are utilized

    • Vertically scaled, where a few monolithic systems support many instances of Web servers

  • Manageability – In general, the fewer the number of servers, the lower the total cost of operation (TCO).

The next three sections describe three architecture designs.

Designing for Vertical Scalability and Performance

The architecture example shown in FIGURE 2-6 provides enhanced security. The Web server can be configured as a reverse proxy by receiving an HTTP request on the ingress network side from a client, then opening another socket connection on the appserver side to send an HTTP request to the Web server running inside the Sun ONE Application Server instance. Alternatively, the Web server instance could instantiate EJB components after performing a lookup on the home interface of a particular EJB component. One advantage of this decoupled architecture is independent scaling. If it turns out that the Web server servlets need to scale horizontally, they can do so independently of the application server logic. Similarly, if the EJB architecture's logic needs to scale or be modified, it can do so independently of the Web tier. Potential disadvantages include increased latency between the Web tier and Application Server tier communications and increased maintenance.

Figure 2-6. Decoupled Web Tier and Application Server Tier—Vertically Scaled


Designing for Security and Vertical Scalability

The example shown in FIGURE 2-7 represents a collapsed architecture that takes advantage of the Web server already included in the Sun ONE Application Server instance process. This architecture is suitable for applications that have relatively intensive servlet-to-EJB communications and less stringent security requirements. From an availability standpoint, fewer horizontal servers result in lower availability. A potential advantage of this architecture is lower maintenance cost because there are fewer servers to manage and configure.

Figure 2-7. Tightly Coupled Web Tier and Application Server Tier—Vertically Scaled


Designing for Security and Horizontal Scalability

The architecture shown in FIGURE 2-8 is a more horizontally scaled variant of the architecture shown in FIGURE 2-6. This results in increased availability. More server failures can be tolerated without bringing down services in this configuration.

Figure 2-8. Decoupled Web Tier and Application Server Tier—Horizontally Scaled


..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset