The WAS Core Architecture

The WAS Core Architecture

At last it's time to look deeper into the process architecture of WAS. We will first examine the components of a base WAS installation, and then examine how an installation of WSAD ND differs from an installation of base WAS.

Let's begin by talking about how the J2EE specification describes a standard for packaging applications. An enterprise application contains the hierarchy of resources for your J2EE application to function. It can contain any combination of the following:

  • Web modules (Web archive [WAR] files)— These files contain servlets and JSP components as well as other classes and resources (like property files and static web content) used by those components.

  • EJB modules (packaged into EJB Java archive [JAR] files)— These files contain EJBs and their associated classes.

  • Application client modules— These files contain the code for application clients that use EJBs and other J2EE services. This code runs on the client, not on the server. We will cover this in detail in Chapter 22.

  • J2C connector modules (resource archive [RAR] files)— These files contain J2C connectors and their definitions. If, for instance, you needed to connect to a mainframe CICS transaction, you would need to include an appropriate J2C connector enabling this inside your EAR file.

  • Utility JAR files— If you have Java code that is used by more than one module within your EAR, it is a best practice to separate it into its own JAR file and package that file in the EAR file as well.

Each of the J2EE module files has a similar structure. They are all packaged as JAR files, which combine Java .class files for a logical set of packages and any necessary configuration property files together with a JAR manifest. In addition to Java .class files, a J2EE module will also contain deployment descriptors (which are specific to each module type) and IBM extension and binding documents (again, specific to each module type).

Enterprise applications are packaged together as EAR files. A typical example of how an EAR file is laid out is shown in Figure.

2. Typical EAR file structure.


WebSphere is different from some other application servers in that it adheres strictly to the J2EE specification and does not allow deployment of applications in any way other than through the standard EAR format (e.g., there is no special directory in WebSphere in which you can place JSP or servlet .class files in order to make them run).

We will revisit EAR files (and their constituent parts) in later chapters. For now, you need to have a basic understanding of EAR files to understand how applications are deployed into WAS, and how this fits with the WAS process model. Figure shows the parts of a base WAS installation.

3. WAS process architecture.


By far the two most common means for a user to access a WebSphere application is by requesting HTML (Web) pages from a servlet or a JSP, or by using a desktop application client written in Java that connects to services provided by EJBs running inside a WebSphere server.

Let's first consider the servlet or JSP path. The URL that the user connects to will not, in fact, be hosted by a WebSphere application server instance itself, but will instead refer to a Web server. This may be an open-source Web server like Apache, or a commercial one like Microsoft IIS, or the IBM HTTP Server (powered by Apache) which ships as part of the WebSphere base installation. This Web server must have installed within it a piece of extension code provided as part of WAS, and which is installed as part of the WebSphere installation process.

This piece of code is called the WebSphere plug-in, and it is responsible for identifying those URLs that represent services (servlets, JSPs, and other files) provided by a WebSphere application server and passing the requests on to an appropriate WAS instance.

WebSphere requires this level of indirection for a couple of reasons.

First, in most real-life situations, you would want to combine an application written in WebSphere with other Web content. This could be static HTML, JPEG or GIF files, animations written using Macromedia Flash, or even entire applications written in technologies like Perl or Microsoft ASP.NET. WAS's plug-in approach allows you to accomplish this with a minimum of additional setup. The WebSphere plug-in uses a simple XML configuration file that identifies the URLs (and virtual hosts) that correspond to WebSphere applications, and identifies the server name to which it should route requests for those URL-host combinations. The Web server and whatever other plug-ins it may host handle all other content not identified in this file.

The second reason WebSphere uses a Web server plug-in is that in WAS ND the plug-in can also spread work among several different WebSphere application server instances. We will discuss more about this behavior of the plug-in in the next section.

Once the plug-in identifies the correct final endpoint for an HTTP request, it forwards it to a WAS instance. An application server instance is a JVM that can host any number of enterprise applications, each representing different logical applications. Once the server identifies the URI for the request it can then find the appropriate enterprise application that contains that URI and invoke the Web component (servlet or JSP) that will handle the request. That component may make requests of other J2EE components (other servlets or JSPs, EJBs, etc.) or it may obtain information from an external data source like a relational database. In the end, though, it returns an HTTP response back to the browser, usually in the form of a Web page.

The other path is much simpler, but less common. In it, an application written in Java makes a request of an EJB running in a WAS using the RMI/IIOP protocol. We'll cover that architecture in detail in Chapter 22.

There are other ways to make requests of components running inside WebSphere, such as through Web services or CORBA, which we will cover in later chapters. What we covered here are the two basic approaches; other mechanisms are variations of them.

Now that you understand how a request is handled by a WebSphere installation, you're ready to understand how enterprise applications are placed into a WAS instance and what other administration steps can be done to make the application server instance ready to run the enterprise application.

     Python   SQL   Java   php   Perl 
     game development   web development   internet   *nix   graphics   hardware 
     telecommunications   C++ 
     Flash   Active Directory   Windows