WebSphere Application Server, often referred to simply as WAS, is a JEE-compliant application server platform. JEE stands for Java Enterprise Edition and was previously referred to as J2EE. JEE application servers provide functionality to deploy fault-tolerant, distributed, and multi-tier Java software. They also provide the runtime environment and management interface to manage the many modular components that make up JEE applications. Before we begin to look into the specifics of WebSphere Application Server 8 administration, it is important to understand what the product is, why it is often the product of choice to provide a base for an enterprise JEE SOA (Service Oriented Architecture) along with support for the many Java-based standards, and how an organization can benefit from using WAS. We also need to cover some specific WAS terminology and concepts used throughout the book.
In this first chapter, we will cover the following:
What is WebSphere Application Server
Why choose WAS
Previous versions
Enhancements and capabilities
WebSphere Application Server architecture
WAS concepts and terminology
WebSphere Application Server products
IBM WebSphere Application Server, is IBM's answer to the JEE application server. WAS first appeared in the market as a Java Servlet engine in June 1998, but it wasn't until version 4 (released in 2001) that the product became a fully JEE 1.2-compliant application server.
Over the last 10 years, since version 1.2 was released, IBM has invested heavily in WAS and it is developed with open industry standards in mind such as Java EE, XML, and Web Services. WebSphere Application Server is now IBM's flagship for the WebSphere brand and forms the base of many of IBM's extended product range.
The latest release of WebSphere Application Server version 8, is a JEE 6-compliant application server. Every new version is required to provide improved efficiency and continued compliancy with standards, allowing customers who invest in WAS to make use of the new Java capabilities of each new JEE release.
When choosing an application server platform on which to run applications and services, architects and developers need to know that WAS will support new JEE features and improved coding practices. WAS has evolved as a product with each new update of the JEE standard, and IBM has continued to provide new versions of WAS to support available features of each new JEE release.
The following table shows a simple comparison of current and previous WAS versions and its compliancy to JEE specifications:
|
Version |
Compliancy | |||
|---|---|---|---|---|
|
JEE |
EJB |
Servlet |
JSP | |
|
WebSphere 8 |
6 |
3.1 |
3.0 |
2.2 |
|
WebSphere 7 |
5 |
3.0 |
2.5 |
2.1 |
|
WebSphere 6.1 |
1.4 |
2.1 |
2.4 |
2.0 |
|
WebSphere 6 |
1.4 |
2.1 |
2.4 |
2.0 |
|
WebSphere 5.1 |
1.3 |
2.0 |
2.3 |
1.2 |
|
WebSphere 5 |
1.3 |
2.0 |
2.3 |
1.2 |
|
WebSphere 4 |
1.2 |
1.1 |
2.2 |
1.1 |
|
WebSphere 3.5 |
1.2 |
1.0 |
2.1 |
1.0 |
JEE is an ever-changing world, and as soon as a new application server is released by IBM, new standards and approaches become available, or they become the preferred method of choice by the JEE community. Organizations who have invested in JEE technology require an application server platform that allows them to extend their existing legacy systems, and provide services-based frameworks on which their enterprise applications and systems can be based. So there is a continuing need for IBM to facilitate all the facets of the new JEE enterprise features, namely JMS, Web Services, Web Applications, and Enterprise JavaBeans, ensuring their product continues to innovate and provide the ability for their customers to extend their own core systems.
IBM is committed to ensuring WAS negates the need for complex architectures, while at the same time providing a platform for servicing business applications, process automation/workflow, and complex bus topologies as required. The WAS product is continually being updated and improved to bring in new technologies as they are released or accepted by the community as a whole.
WAS can be considered the base of your enterprise JEE application service provisioning toolbox, and can be extended with custom business solutions as required. Developers and architects want to ensure that their application designs use the latest JEE standards and programming models. Reading through the WAS product specification sheet, which can be downloaded from http://www.ibm.com/developerworks/downloads/ws/was/, you can see that there are many new features in WebSphere Application Server version 8 supporting many industry JEE API's (Application Programming Interfaces) and standards.
Let's now turn to a quick, but not so brief, overview of the new capabilities under WebSphere 8.
Note
Not all new JEE features are chosen by IBM to be fully supported in the new versions of WAS. IBM assesses every new specification, and determines the features they will implement. Sometimes their decision can be entirely commercial, that is how they can implement an IBM-specific solution within the bounds of WebSphere; other times they are influenced by their customers and/or industry needs.
Improving WebSphere Application Server's capability offering is something that IBM is very good at. Each new release offers more support for the ever changing JEE specification and industry/community-provided Java APIs. IBM evaluates customer and industry feedback when building new versions of the WAS. These considerations influence how WebSphere supports JEE applications.
Details of new capabilities have been included in this chapter as it is important to have knowledge of what WebSphere actually supports. This is not a book on architecture; it is about administering WebSphere Application Server. However, in your job as a WebSphere administrator, you will need to provide a WebSphere environment designed by architects to support applications built by developers, who will have incorporated new JEE features in the application(s) requiring deployment. You will find yourself setting up resources to support these new APIs. You will also often find yourself debugging applications, which may not be running correctly due to conflicts of APIs packaged in the application with those already provided by WebSphere within its internals.
Note
If you require an in-depth view of what's new in WAS 8, it is recommended you visit the official WAS 8 features page at the following URL: http://www-01.ibm.com/software/webservers/appserv/was/features/. It is also good practice to review the product data sheet, which can be downloaded from the aforementioned URL.
Architects require common standards. Because IBM continually welcomes and supports new development and design approaches within the JEE application community, it gives architects the confidence that any inter-communicating systems they design for WAS 8 will communicate and work with external systems with much less effort.
An enterprise will contain many third-party systems and interfaces. By using WAS 8, companies can feel confident that their design approach will be consistent with other industry solutions, standards, and practices. This allows for quicker integration due to the fact that systems will require less design and development to interface the third-party products and systems, that is fewer barriers to integration and interconnectivity.
The following table gives a summary of key standards that WebSphere 8 supports:
There have been many internal product improvements for efficiency in both resource management and administration time saving. The following table gives an overview of new enhancements to WAS realized in version 8:
The following table is a quick reference, listing the new standards mentioned previously as adhered to, or provided, by WebSphere Application Server v8:
We have mentioned that WebSphere Application Server 8 has been developed to adhere to the new JEE 6 specification. We will now quickly look at what JEE 6 is made up of, so we can see how WAS maps out.
It is important for a WAS 8 administrator to have a good awareness of the JEE 6 server architecture model. Let's look at Java EE 6 and quickly run though the internal JEE containers. This should give you an insight and understanding into what WebSphere 8 has to offer in the way of JEE 6 support for these containers. We cannot delve into every API/Standard of JEE 6 as we are here to learn WebSphere Application Server, but I think the overview of the containers will help provide context for the specific features of the JEE specification.
The JEE specification outlines four types of container, as shown in the following diagram. These containers form the guidelines of the services, which are to be provided by a JEE application server as implemented by a software vendor like IBM:
Note
A JEE application will use one or more of the previous four components, that is an application can simply be a web application running in the Web Container alone, or a JEE application can be more complex and contain both Web components and EJB components, and so more than one container can be used in serving an application.
The Applet container manages Java applets. An Applet is a Java program that can be embedded into a web page. Most web pages are rendered using HTML/XML-based technology. By embedding the tags <APPLET> and </APPLET> a browser will load a Java applet, which can use the Java AWT/Swing interface APIs, allowing a traditional client-like application to run within the browser. The Applet container manages the execution of the applet, and contains the web browser.
The Web container, also known as a Servlet container, provides web-related services. In a nutshell, this is the component of a web-server which serves web content, web-services, facilitates web-security, application deployment, and other key services. The following diagram shows the availability of the Java EE 6 APIs in the web container:
The EJB (Enterprise JavaBean) container manages the services of the EJB API and provides an environment for running the enterprise components of a JEE application. Enterprise JavaBeans are used in distributed applications, and facilitate transaction services and appropriate low-level implementations of transaction management and coordination, as required by key business processes. They are essentially the business components of an application.
The EJB container also manages database connections and pooling, threads, and sockets on behalf of enterprise beans, as well as state and session management. The following diagram shows the availability of the Java EE 6 APIs in the EJB container:
An application client runs on a user's client machine and provides a traditional rich Graphical User Interface (GUI) created from the Swing or the Abstract Window Toolkit (AWT) API. Application client's access enterprise beans running in the business tier—which we explained earlier—run in the EJB container. An application client can use RMI (Remote Method Invocation) or other protocols, such as SOAP (Simple Object Access Protocol) , over HTTP (Hypertext Transfer Protocol). The following diagram shows the Java EE 6 APIs within the application client container:
If you would like to know more about the Java 6 API, this link has a great walkthrough of the Java EE 6 Tutorial: http://download.oracle.com/javaee/6/tutorial/doc/index.html.
Now that we have seen the various APIs contained within the four component containers for the JEE 6 platform, we can now look at the internal architecture of WebSphere with some context established.
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.
Throughout this book we will be referring to WAS-specific terminology. There are some key points and terms we need to clarify to aid in understanding WAS as we discuss the finer points of WAS administration. The following section outlines important keywords and terminology, referred to in later chapters.
The core product files are the actual product binary files, and can be shared by many profiles. The directory structure for the product has two major divisions of files in the installation root directory for the product. One division is the runtime binaries and the other is for profiles. We will discuss this in detail in Chapter 2, Installing WebSphere Application Server.
A profile is an 'instance' of a WebSphere Application Server configuration. A profile contains its own set of administration scripts, its own environment, its own repository, and its own node agent. Many profiles can be created from a single install. Profiles can be installed to share runtime binaries allowing multiple profiles to benefit from a single maintenance update. It is also possible to allow each profile to have its own copy of the runtime binaries allowing profiles to update independently.
An example of using multiple profiles might be that a developer needs to create separate profiles of the product in order to segregate development and testing, each profile being based on a different fix-pack level, and/or containing specific configuration settings. In the following chapters, we will explain profiles in more detail.
A unit of management is a Cell. The entire administrative configuration data is stored in XML files containing the master configuration of the Cell. It is also a grouping of nodes into a single administrative domain. For WebSphere Application Server, it means you group (federate) several servers within a Cell, then you can administer them with a single administrative console. Federating multiple application servers into a single administrative console is covered in Chapter 9, Administrative Features.
The following diagram outlines the components of a Cell:
A node is the term which can be given to the physical OS instance on which the WebSphere process will run. Another important term related to nodes is the Node Agent. Node Agents are responsible for spawning or killing server processes and also configuration synchronization between the Deployment Manager and the Node in the WebSphere Network Deployment product.
When using WebSphere Application Server, there is no node agent process available for a standalone application server node, unless you decide to federate the application server node with a Deployment Manager for a given Cell of an existing WebSphere Network Deployment installation. In short, a standalone installation of a WebSphere is in fact a single Cell, Node, Node Agent, and Server all in one.
It can be quite confusing at times, because WAS is designed for scalability and extension, so depending on the version of WAS purchased, you can extend its architecture and infrastructure footprint. Some of these terms come into their own once you upgrade to WebSphere Network Deployment and other extended variants of WAS.
Since version 7, the administrative agent has become available. This provides a single interface to administer multiple standalone application servers. Multiple servers may exist for development, test, staging, pre-production, and so forth, thus having a single administration console to manage many servers provides administrators with new capability.
Each standalone Application Server node needs to run a JVM in which a deployed JEE application will run. With WAS base, each profile will have a single JVM. In WAS ND, we can have multiple JVMs per node, which is part of the highly-available design architecture of WAS ND. You could say an installation of a standalone WebSphere application server is a cell, a node, and a server with a single JVM all in one along with an administration console.
WebSphere Application Server also forms the base of WebSphere Application Server 8 Network Deployment (WAS-ND) Edition, which is designed for the more complex enterprise, with support for high availability such as clustering, failover, load balancing and work load management, and so on.
Other products in the WebSphere range include WebSphere Portal, WebSphere ESB, WebSphere Process Server, and many others. The following table provides a quick review of WebSphere Application Server products:
|
Description | |
|---|---|
|
Application Server |
Build, deploy, and manage SOA business applications and services of all types. Application Server also known as Application Server Base is the foundation of the WebSphere Application Server suite. |
|
An affordable solution at a reduced cost. | |
|
Lightweight Java EE application server based on open source Apache Geronimo. | |
|
Provides high-availability with near-continuous availability along with advanced performance and management capabilities, for mission-critical applications. ND provides JVM clustering, data replication services, and advanced workload management. | |
|
WebSphere Application Server for Developers provides simplified access to enable developers to build and test in the same environment that will ultimately support their applications. | |
|
Takes advantage of the qualities of service of IBM z/OS, by harnessing the full capabilities of the z/OS. |
|
Product Edition |
Description |
|---|---|
|
Optimized to instantly run in VMware and other server virtualization environments. | |
|
Consolidate application servers and maximize utilization while monitoring application health. | |
|
Provides distributed object caching for elastic scalability and cloud environments. | |
|
Enable practical reuse of on-line Java™ assets in the batch workloads. |
WebSphere is supported on the following OS (Operating System) platforms:
Windows
AIX
Linux
Solaris
i/OS
z/OS
Beginning with Version 6.1 and now with Version 8, IBM is supporting open standard specifications and have aligned WAS with a view to a more common approach across all the platforms, to the extent that WAS now works with a large number of Web servers including Apache HTTP Server, Netscape Enterprise Server, Microsoft Internet Information Services (IIS), IBM HTTP Server for i5/OS, IBM HTTP Server for z/OS, and IBM HTTP Server for AIX/Linux/Microsoft Windows/Solaris.
Following is a table of Platforms and recommended versions of OS:
In this chapter, we have been introduced to WebSphere Application Server v8 capabilities and features to be compliant with JEE version 6. We had a look at the four main components of the JEE 6 platform to provide some context for understanding the WAS 8 internals.
We have explained key terms relating to WAS and explained WebSphere Application Server profiles. We learned that WebSphere Application Server base is the base product on which a suite of extended business products are offered by IBM, which include Application Server, and we briefly covered these products.
Understanding WAS is critical to understanding all the other products in the WebSphere brand. Becoming familiar with WAS is important to anyone who works in the Java enterprise community whether he/she is a programmer, administrator, or an architect. In the remaining chapters of this book, we will cover installing, configuring, administering, and maintaining WAS, and in the next chapter we will learn two different methods of installing WAS. One method will cover a GUI (Graphical User Interface) based install using the IBM Installation Manager. The other method is a demonstration of how to use command-line tools, which are designed for scripting automated installations.
