IBM WAS Tutorial
WebSphere Application Server Tutorial
This tutorial gives you an overview and talks about the fundamentals of Websphere Administration Server.
WebSphere Application Server 8.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 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 tutorial.
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.
The following table shows a simple comparison of current and previous WAS versions and its compliancy to JEE specifications:
Why choose IBM WebSphere Application Server?
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 fromhttp://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.
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.
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:
|Monitored deployments||New monitored directory-based application install, update, and uninstall of Java EE application.|
|HPEL||New High Performance Extensible Logging (HPEL) problem determination tools and enhanced security and administration features to improve administrator productivity and control.|
|Updated installation process||New simplified install and maintenance through IBM Installation Manager to improve efficiency and control.|
|Workload efficiency||Run the same workload on fewer servers, creating savings of 30 percent due to updates in the performance for EJB and web services.|
|Improved performance and high availability with WebSphere MQ||Messaging is a key part of any enterprise both in Java’s JMS and IBM’s specific messaging platform called WebSphere MQ. WAS continues to provide ease of integration with MQ.|
|Security hardening||Security domains have been improved to offer more secure protection for services provided by WAS.
Simplified exchange of user identity and attributes in Web Services using Security Assertion Mark-up Language (SAML) as defined in the OASIS Web Services Security SAML Token Profile Version 1.1.
SAML assertions represent user identity and user security attributes, and optionally to sign and to encrypt SOAP message elements.
The Organization for the Advancement of Structured Information Standards (OASIS) is a global consortium that drives the development, convergence, and adoption of e-business and web service standards.
Web Services Security API (WSS API) and WS-Trust support in JAX-WS to enable customers building single sign on Web services-based applications.
The WSS API supports Security token types and deriving keys for signing, signature and verification, encryption, and decryption.
|Security auditing enhancements||Auditable security events are security events that have audit instrumentation added to the security run time code to enable them to be recorded to logs for review.
Enhanced cookie support to reduce cross-site scripting vulnerabilities and also better support for security, for example, SSO (Single Sign On) and LPTA (Lightweight Third Party Authentication).
Enhanced security configuration reporting, including session security and Web attributes.
Additional security features enabled by default.
Security enhancements required by Java Servlet 3.0.
Java Authentication SPI for Containers (JSR 196) support, which allows third-party authentications for requests or responses destined for web applications.
Configure federated repositories at the domain level in a multiple security domain environment.
|Performance improvements||JPA L2 cache and JPA L2 cache integration with the DynaCache environment.
New caching features functionality for servlet caching, JSP, web services, command cache, and so on.
|Improved migration support||Better support for migrating applications deployed to WebSphere Application Server 6.0, 6.1, and 7.0.
The command line tools and GUI wizard have been improved.
|JDBC (Java Database Connectivity)||New and upgraded providers for database connectivity support for JDBC.|
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 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.
Java EE containers
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:
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:
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 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:
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 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:
|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).|
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
There are four main file types we work with in Java applications. An explanation of these file types is shown in the following table:
|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 aDBMS (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||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 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 the functional and architectural point 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 the 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 the 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 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.
At the top of the technology stack, sits the WebSphere security layer. It builds up on 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 a 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.