Before we look at installing WAS and deploying an application, we will quickly run over the internals of WAS. The anatomy of WebSphere Application Server is quite detailed so, for now, let's briefly outline some of the more important parts, discovering more about the working constituent parts as we work through each of the remaining chapters.
The following diagram shows the basic architecture model for a WebSphere Application server JVM:
All WebSphere Application Servers are essentially Java Virtual Machines (JVMs). IBM has implemented the JEE application server model in a way that maximizes the JEE specification, and also provides many enhancements creating specific features for WAS. JEE applications are deployed to an Application Server.
A common type of business application is a web application. The WAS web container is essentially a Java-based web server contained within an application server's JVM, which serves the web component of an application to the client browser.
Applications need not only comprise of web components. In a more complex enterprise-based application, business objects are created to provide a layer of abstraction between a web application and the underlying data. The EJB container provides the services required to manage the business components as implanted with EJBs.
A virtual host is a configuration element that is required for the web container to receive HTTP requests. As in most web server technologies, a single machine may be required to host multiple applications and appear to the outside world as multiple machines. Resources that are associated with a particular virtual host are designed not to share data with resources belonging to another virtual host, even if the virtual hosts share the same physical machine. Each virtual host is given a logical name and assigned one or more DNS aliases by which it is known. A DNS alias is the TCP/host name and port number that is used to request a web resource, for example, <hostname>:9080/<servlet>.
By default, two virtual host aliases are created during installation. One for the administration console called admin_host and another called default_host, which is assigned as the default virtual host alias for all application deployments, unless overridden during the deployment phase. All web applications must be mapped to a virtual host, otherwise web browser clients cannot access the application that is being served by the web container.
WebSphere uses Java environment variables to control settings and properties related to the server environment. WAS variables are used to configure product path names, such as the location of a database driver, for example, ORACLE_JDBC_DRIVER_PATH, and environmental values required by internal WAS services and/or applications.
Configuration data is stored in XML files in the underlying configuration repository of the WebSphere Application Server. Resource definitions are a fundamental part of J2EE administration. Application logic can vary depending on individual business requirements, and there are several resource types that can be used by an application. The following table shows a list of some of the most commonly used resource types:
|
Description | |
|---|---|
|
Used to define providers and data sources. | |
|
Used to define end-points for external services, for example, web services. | |
|
Used to define messaging configurations for Java Message Service, Message Queuing (MQ) connection factories and queue destinations, and so on. | |
|
Enable applications to send and receive mail, typically using the SMTP (Simple Mail Transfer Protocol). |
The Java Naming and Directory Interface (JNDI) is employed to make applications more portable. JNDI is essentially an API for a directory service, which allows Java applications to look up data and objects via a name. Naming operations, such as lookups and binds, are performed on contexts. All naming operations begin with obtaining an initial context. You can view the initial context as a starting point in the namespace. Applications use JNDI lookups to find a resource using a known naming convention. You can override the resource the application is actually connecting to without requiring a reconfiguration or code change in the application. This level of abstraction using JNDI is fundamental and required for the proper use of WAS by applications.
There are four main file types we work with in Java applications. An explanation of these file types is shown in the following table:
|
File Type |
Description |
|---|---|
|
A JAR file (or Java ARchive) is used for organizing many files into one and employ the The actual internal physical layout is much like a ZIP file. A JAR is generally used to distribute Java classes and associated metadata. In JEE applications, the JAR file often contains utility code, shared libraries, and EJBs. An EJB is a server-side model that encapsulates the business logic of an application and is one of the several Java APIs in the Java Platform, Enterprise Edition with its own specification. You can visit http://java.sun.com/products/ejb/ for information on EJBs. | |
|
A RAR (Resource Adapter Archive) is a special Java archive (JAR) file that is used to package a resource adapter for the Java 2 Connector (J2C) architecture and has the Stored in a RAR file, a resource adapter may be deployed on any JEE server, much like the EAR file of a JEE application. A RAR file may be contained in an EAR file or it may exist as a separate file. WebSphere supports both. A resource adapter is analogous to a JDBC driver. Both provide a standard API through which an application can access a resource that is outside the JEE server. For a resource adapter, the outside resource is an EIS (Enterprise Information system ) and allows a standard way for EIS vendor's software to be integrated with JEE applications; for a JDBC driver, it is a DBMS (Database Management System). Resource adapters and JDBC drivers are rarely created by application developers. In most cases, both types of software are built by vendors who sell products such as tools, servers, or integration software. | |
|
A WAR file (Web Application) is essentially a JAR file used to encapsulate a collection of JavaServer Pages (JSP), Servlets, Java classes, HTML, and other related files, which may include XML and other file types depending on the web technology used. For information on JSP and Servlets, you can visit http://java.sun.com/products/jsp/. Servlet can support dynamic web page content; they provide dynamic server-side processing and can connect to databases. JavaServer Pages (JSP) files can be used to separate HTML code from the business logic in web pages. Essentially, they too can generate dynamic pages; however, they employ Java beans (classes), which contain specific detailed server-side logic. A WAR file also has its own deployment descriptor called | |
|
An Enterprise Archive file represents a JEE application that can be deployed in a WebSphere Application Server. EAR files are standard Java archive files (JAR) and have the file extension One or more web modules packaged in WAR files. One or more EJB modules packaged in JAR files. One or more application client modules. Additional JAR files required by the application. Any combination of the above. The modules that make up the EAR file are, themselves, packaged in archive files specific to their types. For example, a web module contains web archive files and an EJB module contains Java archive files. EAR files also contain a deployment descriptor (an XML file called |
Note
When an EJB module or web module (WAR) is installed as a standalone application, it is automatically wrapped in an Enterprise Archive (EAR) file by the WebSphere deployment process, and is managed on disk by WebSphere as an EAR file structure. So, if a WAR file is deployed, WebSphere will convert it into an EAR file.