Flylib.com

Books Software

 
 
 

Multiple-Tier Architecture

Multiple- Tier Architecture

The multiple-tier architecture is a true enterprise-caliber solution (Figure 4-3). By breaking out the EJBs onto their own dedicated servers, you incrementally increase the availability and performance of the cluster as a whole. The architecture is reliable, scalable, and complicated to administer.

In order to take advantage of multiple-tier architecture, your EJB application must be designed with replica-aware stubs. The actual implementation of these stubs is outside the scope of this book. However, for purposes of this discussion, it's worth providing a brief background description. (Also see the discussion on EJBs in the Introduction.)

Replica-Aware Stubs

To the caller, a replica-aware stub appears to be a normal RMI stub. However, the stub must contain program logic for locating a replica of an EJB or RMI class on any WebLogic server in the cluster in which it is deployed.

In a multitier architecture, all the presentation logic occurs on the standard servers. Consequently, no client ever gets a replica-aware stub that is located on the same server as the clustered object. Therefore, the calls to the clustered objects are load balanced according to the logic implemented in the replica-aware stub.

Proxies

As mentioned earlier, it is also possible to incorporate other types of HTTP servers into your WebLogic installation. This is a big selling point for BEAamong other things, it means that WebLogic server can be integrated into existing Web sites with relatively little trauma. In order to interact with WebLogic server, an HTTP server must be configured with a plug-in. Plug-ins are available for the following server classes:

  • Apache

  • Netscape Enterprise server

  • Internet Information server

Ideally, these servers should handle only requests for static Web pages. To support legacy applications it may be necessary to permit them to serve some interpreted code, either as CGI or from a script module such as mod_perl. However, it will always be a bad idea for JSPs and servlets to be handled by anything other than WebLogic server. Note also that for administration purposes plug-in enabled HTTP servers are not really part of the cluster. In particular, they cannot be configured or invoked through the Administration Console.

In the configuration shown in Figure 4-4 there are two tiers to the application architecture. The Web tier consists of some number of plug-in enabled HTTP servers. These servers handle all requests for static Web pages. Requests involving servlets, JSPs, and EJBs are passed through the proxy plug-in to a WebLogic server cluster that incorporates servers capable of servicing the requests.

This architecture is interesting in that it provides an opportunity for additional security. To the outside world, it appears as though all requests are being handled by the HTTP servers. The WebLogic servers are invisible, shielded from hacking eyes by carefully configured HTTP servers that now stand between them and the cruel, cruel world. Only the HTTP servers should be accessible through the firewall. The truly paranoid will also be tickled by the addition of a second firewall between the WebLogic servers and the database cluster.

Note that the above architecture is essentially a variation on the basic architecture shown in Figure 4-1. The details that we are primarily concerned withEJBs, JSPs, and servletsare housed together on each server.

A more interesting configuration is shown in Figure 4-5. As you can see, this is a variation on the enterprise architecture of Figure 4-3 in the sense that there are two tiers of WebLogic servers. The presentation tier handles the generation of conventional dynamic content via JSPs, servlets, and the like, and the object tier provides a pool of WebLogic servers dedicated to handling object requests. Note also that, as in Figure 4-1, we have a layer of plug-in enabled HTTP servers between the WebLogic servers and the outside world. [3]

[3] Yes, I'm familiar with the term "DMZ." I avoided using it on purpose. My feeling is that if your job does not place you in danger of attack by mortar or machine gun, the use of military acronyms is a little silly. I also don't say "niner."