April 12, 2011, 5:51 p.m.
posted by franni
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:
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.
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.
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.