Application Architecture for Applications Built on BEA WebLogic Platform 8.1
Pages: 1, 2, 3

Physical View

The Physical View (aka Deployment View) shows the hardware upon which the application will be deployed. It also describes which parts of the application are deployed to which physical pieces of hardware.

The hardware and software deployment described in this section is an example of how an application built on the WebLogic Platform can be deployed and represents the "most common" or "best practice" architecture. However, there are many possible alternate configurations; the actual hardware architecture will depend on the actual application and balances a multitude of often conflicting constraints including budget, reliability, availability, scalability, security, and preexisting network and computing resources.

Hardware Deployment

Figure 2 illustrates a typical hardware environment onto which an application built on the WebLogic Platform could be deployed.

Hardware Deployment
Figure 2. A typical hardware environment

This diagram shows three servers in both the Web tier and the Application tier. There could be any number of servers in either of those tiers. Additionally, each server might have one or many CPUs. The parts of the hardware environment are described in the following sections.

Clients

This hardware architecture shows three different clients: Internet clients, intranet clients, and internal clients. This is intended as a purely illustrative choice of clients and where they would connect into the network. Nonetheless, it does illustrate that a broader audience requires more layers of security to prevent unauthorized access into the system.

Each of the clients depicted could be accessing the system via a browser (using HTTP(S), via a Web service (using SOAP), via RMI or RMI/IIOP (perhaps tunneled through HTTP), or even via a B2B protocol such as ebXML or RosettaNet. Regardless of the access protocol, the request is handled by the Presentation and Interface Layer of the software architecture.

Firewalls

Three firewalls are shown in this hardware architecture. The first firewall protects the Web tier from malicious Internet denizens. The second firewall protects the Application tier, and the optional third firewall protects the EIS tier, which contains the corporate data.

Web Tier

The Web tier exists between the first and second firewall. This is also sometimes referred to as the DMZ. Its primary function is to provide a security layer between the Internet and the rest of the corporate computing environment. The Web tier also provides several other functions including load balancing and static content delivery. If Single-Sign-On (SSO) is desired, then the initial authentication is generally performed in this tier.

The computing resources in the Web tier are used to run a web server farm (for example, Apache, Netscape, IIS, BEA WebLogic Express). There should be no application code deployed to this tier. Only static content (that is, images and HTML) should be served from this tier. Client requests for the application are forwarded to the Application tier via a WebLogic proxy installed in the web server.

Application Tier

The Application tier is where the application is deployed. All four layers of the application architecture (see Figure 1) are deployed in this tier. If high availability is desired, then a WebLogic cluster should be configured as part of the deployment process. This diagram shows the existence of a WebLogic domain. The hardware could host one or many WebLogic domains, and each domain could have one or many applications.

Because J2EE defines a web container and an EJB container, some companies have chosen to deploy these containers on separate hardware tiers. This is not a recommended approach when using the WebLogic Platform. Separating the web container from the EJB container makes deployment of the application more difficult and results in severe performance degradation. The performance degradation is due to the extra network round trips and the marshalling and demarshalling required to go over the network. Conversely, if an application is deployed as a single EAR file, then local interfaces and pass by reference can be used in calls between components in the application.

EIS Tier

The Enterprise Information Systems (EIS) tier is the primary location for storage of all information for the business domain. In the enterprise today, this data can be stored in an enterprise database management system, by a legacy or mainframe system, in a Commercial-Off-The-Shelf (COTS) product (for example, Siebel, SAP, PeopleSoft), or in some unknown location abstracted behind a messaging transport or Web service.

Software Deployment

The following diagram shows the deployment of an application to the Application tier shown above in Figure 2.

Software Deployment
Figure 3. Deployment of an application to the Application tier

This shows a single, clustered application deployed to all three servers in the Application tier. This is the simplest way to deploy an application build on the WebLogic Platform, but there are many other possibilities. The next diagram illustrates another type of deployment:

Portal App and BPM
Figure 4. Portal application and BPM

This figure shows a portal application on two servers in a cluster and a separate application for Business Process Management (BPM) deployed to a single server. In this deployment the portal application provides high availability while the BPM application does not. Such a deployment might be appropriate if the portal application is critical and uses a non-critical BPM application.

These examples show three servers with one WebLogic instance on each. However, there could be any number of servers and one or multiple WebLogic instances per server. In fact, there is a tremendous amount of flexibility in the way that applications can be deployed on the BEA WebLogic Platform. Some deployment "rules of thumb" are:

  • One instance of WebLogic for every two or three CPUs
  • Applications that are to be administered together should be in a common WebLogic domain
  • Applications that are unrelated should go in separate WebLogic domains even if they are sharing hardware resources
  • WebLogic instances should be clustered if high availability or fault tolerance is a requirement
  • If the application needs N servers to provide the necessary performance and throughput, then the application should be deployed on N+1 servers to allow for server outages (either planned or unplanned).

This section concludes the discussion of hardware and software deployment in the Physical View. The next section will examine the Process View of the 4+1 View Model.

Process View

The Process View (aka Concurrency View) shows the various processes and the communication that occurs between the processes. The following diagram illustrates the processes that are involved in servicing a web browser request for data that resides in a relational database.

Process View
Figure 5. Process View

This simple example of a process diagram shows that multiple processes and threads are involved in servicing a single browser request. The process diagram could be much more complex especially if asynchrony and multiple back end systems are involved in servicing a single request.

The next diagram illustrates the processes and threads of the WebLogic Platform.

Threads
Figure 6. Processes and threads of the WebLogic Platform

As illustrated in the above diagram, a single instance of WebLogic Server corresponds to a single process with multiple threads. By default, WebLogic Server is configured with a single request queue. Additional request queues can be configured to separate different types of requests. For example, it might be desirable to separate higher priority requests from low priority computationally expensive requests.

When using the pure-Java socket reader implementation, the Socket Reader threads and Worker threads both come from the same thread pool. When native IO is configured, the native socket reader multiplexor threads have their own execute queue and do not borrow threads from the request queue thread pool.

Communication

By and large, the communication within an application built on the WebLogic Platform is handled transparently by the platform. However, there are some communication constructs supported by the platform that may have important architectural impacts.

Conversations

The Web services provided by the WebLogic Platform provide a mechanism to easily create a conversation between the client and the application. The state of the conversation is stored persistently so the conversation can be long lived and can survive even a complete system shutdown. (Conversation timeouts can also be set so that abandoned conversations are cleaned up automatically.)

Asynchronous Support

The WebLogic Platform provides several mechanisms for asynchronous communication.

  • The control architecture provides a simple mechanism to create and register for callbacks.
  • An asynchronous web service can be easily constructed with a Java Web Service (JWS) file.
  • The platform includes a reliable SOAP messaging framework whereby an application running in one WebLogic instance can asynchronously and reliably invoke a web service running on another WebLogic instance.
  • The platform includes a message broker that allows asynchronous communication to and from Process Definitions.
  • The platform includes JMS and MDB support, which are the J2EE standard mechanisms for asynchronous communication.

Security

Security is not generally thought of as part of the communication between components within an application. However, WebLogic Platform includes an industry-leading security infrastructure that is transparently intercepting and taking action on communications within the application. This security infrastructure is part of WebLogic Server and is leveraged by the rest of the platform to create consistent, declarative, policy-based security for all aspects of the application. The need to write custom code to enforce security within the application should be very rare.

The WebLogic Platform also supports WS-Security. This not only provides encryption of web services messages but also ties the web services stack into the underlying security infrastructure.

WebLogic Enterprise Security (WLES) is another BEA product that can be incorporated into a solution built on the WebLogic Platform. WLES provides enhanced application security that includes: policy-based delegated administration, authentication with single sign-on, consolidated auditing, and dynamic-role and policy-based authorization with delegation.

Conclusion

The goal of this article is to present the extensive functionality provided by the BEA WebLogic Platform in a high-level view easily digestible by application architects and designers. To accomplish this, the 4+1 View Model was used to describe the architecture of applications built on the WebLogic Platform. The Developer View provides a unified view of the components provided by WebLogic Server, WebLogic Portal, WebLogic Integration, WebLogic Workshop, and Liquid Data for WebLogic. This view also shows the architectural layers in a well-designed application and identifies the components used in each of the layers. The Physical View provides a simple example of a deployment of an application built on the WebLogic Platform. Both the software deployment and the physical hardware deployment are depicted. The Process View describes the threads and processes involved in servicing a user request. It also touches on application communication issues such as conversations, asynchrony, and security.

We hope that this furnishes a better understanding of the WebLogic Platform and the robust foundation that it provides for application development and that this understanding can be used to help build and design applications that leverage the capabilities provided by the WebLogic Platform.

Additional Reading

Bob Hensle has over 20 years of industry experience including more than eight years with BEA Consulting.