IBM WebSphere Application Server (WAS) V9.0 Tutorial

This IBM WebSphere Application Server tutorial gives you an overview and talks about the fundamentals of the Websphere Administration Server.

WebSphere Application Server 9.0: Product Overview

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 the 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 makeup 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 tutorial.

Table of Content - IBM WebSphere Application Server

What is WebSphere Application Server? Why choose IBM WebSphere Application Server? Features Of IBM Inside WebSphere Application Server WebSphere Architecture Overview WebSphere technology stack view

What is WebSphere Application Server?

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.

Are you interested in taking up for IBM WAS Course? Enroll for a Free Demo on IBM WebSphere Application Server Training

The following table shows a simple comparison of current and previous WAS versions and their compliancy to JEE specifications:

Version	Compliance
	J2EE	EJB	Servlet	JSP
WebSphere 8	6	3.1	3	2.2
WebSphere 7	5	3	2.5	2.1
WebSphere 6.1	1.4	2.1	2.4	2
WebSphere 6	1.4	2.1	2.4	2
WebSphere 5.1	1.3	2	2.3	1.2
WebSphere 5	1.3	2	2.3	1.2
WebSphere 4	1.2	1.1	2.2	1.1
WebSphere 3.5	1.2	1	2.1	1

Why choose IBM WebSphere Application Server?

Architecture And Internals

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.

JEE 6 Server architecture model

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 through 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.

Java EE containers

The JEE specification outlines four types of containers, 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

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 it 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

The JEE specification outlines four types of containers, 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.

Applet container

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 and 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.

Web container

The Web container, also known as a Servlet container, provides web-related services. In a nutshell, this is the component of a web server that 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:

EJB 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:

Application Client 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 clients 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:

Inside WebSphere Application Server

Before we look at installing WAS and deploying an application, we will quickly run over the internals of WAS. The anatomy of the 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:

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.

Web container

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.

EJB container

Applications need not only comprise 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.

Virtual hosts

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/hostname and port number that is used to request a web resource, for example,:9080/.

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.

Environment settings

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.

Resources

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:

Resource types	Description
JDBC (Java database connectivity)	Used to define providers and data sources.
URL providers	Used to define end-points for external services, for example, web services.
JMS providers	Used to define messaging configurations for Java Message Service, Message Queuing (MQ) connection factories and queue destinations, and so on.
Mail providers	Enable applications to send and receive mail, typically using the SMTP (Simple Mail Transfer Protocol).

JNDI

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.

Application File Types In Java Applications.

There are four main file types we work within Java applications. An explanation of these file types is shown in the following table:

File Type	Description
JAR file	A JAR file (or Java ARchive) is used for organizing many files into one and employ the .jar file extension. 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.
RAR file	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 .rar file extension. 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.
WAR file	WAR file 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 web.xml, which is used to configure the WAR file and can contain instructions for resource mapping and security.
EAR file	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 .ear. An EAR file can consist of the following: 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 are 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 application.xml) that describes the contents of the application and contains instructions for the entire application, such as security settings to be used in the runtime environment.

WebSphere Architecture Overview

The next view to be presented is that of the WebSphere Application Server product architecture. In a nutshell, the WebSphere Application Server product is an implementation of the J2EE set of specifications with some added functionality only found in this IBM product. Therefore, as opposed to the previous section, this view is unique to WebSphere.

Consequently, this section briefly presents the salient components of the J2EE technologies and their relation to each other from functional and architectural points of view. Furthermore, emphasis will be placed on aspects that affect or may be affected by security considerations.

WebSphere Application Server simplified architecture

The following diagram depicts a simplified version of the WebSphere Application Server architecture. It presents the application server in the context of a WebSphere node. The application server is the implementation of a JVM. The JVM is made up of various components and at the same time, the JVM interacts with several external components that make up the WebSphere node. So, the diagram presents two major components of a WebSphere environment. On the one hand, the JVM is represented by the parallelogram (purple ) labeled Application Server. On the other hand, a larger parallelogram (teal) labeled node represents the WebSphere node.

Keep in mind that the simplification to the architecture has been done to concentrate on how it relates to application hosting in a secure environment.

WebSphere node component

The node component of this simplified architecture occupies itself with administrative and thus security aspects between the WebSphere environment and the infrastructure. In the previous diagram, three components can be observed. The first component is the node agent; represented by the small parallelogram labeled Node agent. Notice that the node agent in itself is implemented by a specialized JVM, containing the components required to efficiently perform administrative tasks, which will include security-related tasks. The node agent will interact with WebSphere environment administrative components externals to the node (and not included in the diagram). The chief among those external WebSphere components is the Deployment Manager. One of the responsibilities of the node agent as it pertains to the node and thus, to the application server JVM, is to maintain updated and valid copies of the node configuration repository. Such a repository may include information dealing with security domain information, either inherited from the WebSphere cell global security or customized for the node, represented by the parallelogram (black) labeled Local Security Domain.

WebSphere JVM component

The second major component of this simplified architecture is the implementation of a JVM. It is represented in the diagram by a large parallelogram (purple) labeled Application Server. A WebSphere JVM is made of, among other components, several containers such as the Web and EJB containers. Containers, on top of hosting instantiations of Java classes such as servlets and beans, that is, offering the runtime environment for those classes to execute, deal with security aspects of the execution. For instance, a Web Container may, given the appropriate settings, oversee that hosted resources only execute if the principal making the request has the required proof that entitles such principal of receiving the result of said request.

In addition to containers, a WebSphere JVM may also instantiate a service integration bus (SIB) if a hosted application makes use of the JVM messaging engine. In the diagram, the arrow (brown) labeled SIB represents the bus. Finally, the other JVM components included in this simplified architecture are the administrative component and the JVM security mechanism. This mechanism will interact with the containers to ensure that security is propagated to the classes executing in the said containers.

From this discussion, it can be extrapolated that each vendor has certain leniency as to the actual implementation of Sun’s JVM. IBM is not an exception to this practice. If you wish to find out more about the particulars of the IBM JVM implementation for WebSphere please refer to the Information Center article “Specifications and API” (HTTP://PUBLIB.BOULDER.IBM.COM/INFOCENTER/WASINFO/V7R0/INDEX.JSP?TOPIC=/COM.IBM.WEBSPHERE.ND.DOC/INFO/AE/AE/ROVR_SPECS.HTML). In that article you will find out which Java specifications and application programming interfaces are implemented as well as the version each implements. This information is presented in a neat table that helps you compare each specification and API version to earlier editions of the WebSphere Application Server product (that is, 5.1, 6.0, and 6.1).

Using the WebSphere architecture view

The main benefit of analyzing your WebSphere environment using this view is that it will provide you with the vocabulary to better understand the needs of application developers and architects and, equally important, to communicate back to them the special features the WebSphere environment may offer them as well as any possible restrictions imposed by security or other infrastructure characteristics.

An additional benefit provided by this view is that it offers alternatives to troubleshooting application-related issues, as you will become more familiar with which JVM components are being used as the runtime environment for a given enterprise application.

WebSphere technology stack view

Finally, the third view covered in this chapter is that of the WebSphere environment technology stack. In other words, this view presents which technologies from the operating system to the WebSphere Application product are involved, highlighting the aspects related to security. This view is broken down into three categories, which are described in the following paragraphs. The stack and its categories are depicted in the diagram shown in the next sub-section.

OS platform security

At the bottom of the stack, there are primitive technologies. The term primitive in this context does not carry the meaning of backward, but rather that of foundation technologies. In the following diagram, the rectangular (bright green) area located at the bottom of the stack represents the OS platform layer.

In this layer, the presence of the underlying operating system can be observed. In the end, it is the responsibility of the OS to provide the low-level resources needed by the WebSphere environment. Furthermore, it is also its responsibility to enforce any security policies required on such resources. Two of the more prominent OS components, as they relate to a WebSphere environment, are the file system and the networking infrastructure. Both the file systems and the networking infrastructure are handlers of special resources.

Java technology security

The next layer in this architecture is that of Java technology. This layer comprehends the core Java technologies and APIs used within the WebSphere environment. In the previous diagram, the layer is represented by the rectangle (teal) in the middle of the stack.

The layer is further broken down into three distinct groups among the Java stack. At the bottom sit the foundational bricks. The Java Virtual Machine and the Java Language Specification. The JVM is the enabler whereas the Language Specification lays down basic and general rules that must be obeyed by the entities that will populate the JVM.

The middle brick of this layer is that of Java 2 Security. It includes more sophisticated rules that will enable entities in the JVM to achieve more complex behaviors in harmony with the rest of the inhabitants.

Finally, at the top of this layer, there is the J2EE Security brick. It brings additional enablers to the JVM and rules that must be followed by the entities that populate these remote areas of the Java galaxy.

WebSphere security

At the top of the technology stack, sits the WebSphere security layer. It builds upon the previous layers and brings on board open and proprietary security bricks to supplement the Java foundation.

In other words, the WebSphere high-level security layer offers conduits using a number of technologies such as LTPA, Kerberos, and so on, that make the WebSphere environment more robust. This layer is represented in the previous diagram by the rectangle (maroon) located at the top.

In general, the number of technologies supported by this layer as well as the implementation version of such technologies is one of the aspects that make up each new WebSphere release.

Using the technology stack view

One of the main benefits of the technology stack view is that it helps WebSphere practitioners involved in various roles to map the various technologies included in this stack to the functional blocks that make up the other two views. Some practitioners will benefit by selecting the most appropriate subset among the classes offered by the WebSphere environment to implement the required functionality. Other practitioners will benefit by integrating into the WebSphere environment the best infrastructure component that will help to enable a piece of functionality required by a hosted application.