IBM WebSphere Application Server - WAS Tutorial: FREE Guide [STEP-IN]
IBM WebSphere Application Server Tutorial

IBM WebSphere Application Server – WAS Tutorial: FREE Guide [STEP-IN]

Last updated on 12th Jun 2020, Blog, Tutorials

About author

Usha Ramkumar (Software Developer )

Usha Ramkumar is an industry expert and subject specialist who have mastered running applications and providing the Best Quality Management training to the students. She is a qualified professional with seven years of XSD, WSDL, XML, XPATH, XSLT, XQuery, JSON, Schema Validations, WebSphere MQ, OSB, SOAP, BPEL., FTP Adapter, Database Adapter, and UMS Adapter XSD experience.

(5.0) | 19937 Ratings 5068

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.

Subscribe For Free Demo

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.

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

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.



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

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/host name 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.

Java EE application components

The product supports application components that conform to Java Platform, Enterprise Edition (Java EE) specifications.

Web applications run in the web container

The web container is the part of the application server in which web application components run. Web applications are comprised of one or more related servlets, JavaServer Pages technology (JSP files), and Hyper Text Markup Language (HTML) files that you can manage as a unit. Combined, they perform a business logic function.

The web container processes servlets, JSP files, and other types of server-side includes. Each application server runtime has one logical web container, which can be modified, but not created or removed. Each web container provides the following.

Web container transport chains

Requests are directed to the web container using the web container inbound transport chain. The chain consists of a TCP inbound channel that provides the connection to the network, an HTTP inbound channel that serves HTTP requests, and a web container channel over which requests for servlets and JSP files are sent to the web container for processing.

Servlet processing

When handling servlets, the web container creates a request object and a response object, then invokes the servlet service method. The web container invokes the servlet’s destroy method when appropriate and unloads the servlet, after which the JVM performs garbage collection.

  • Servlets can perform such tasks as supporting dynamic web page content, providing database access, serving multiple clients at one time, and filtering data.
  • JSP files enable the separation of the HTML code from the business logic in web pages. IBM extensions to the JSP specification make it easy for HTML authors to add the power of Java technology to web pages, without being experts in Java programming.

HTML and other static content processing

Requests for HTML and other static content that are directed to the web container are served by the web container inbound chain. However, in most cases, using an external web server and web server plug-in as a front end to the web container is more appropriate for a production environment.

Session management

Support is provided for the javax.servlet.http.HttpSession interface as described in the Servlet application programming interface (API) specification.

An HTTP session is a series of requests to a servlet, originating from the same user at the same browser. Sessions allow applications running in a web container to keep track of individual users. For example, many web applications allow users to dynamically collect data as they move through the site, based on a series of selections on pages they visit. Where the user goes next, or what the site displays next, might depend on what the user has chosen previously from the site. To maintain this data, the application stores it in a session.

SIP applications and their container

SIP applications are Java programs that use at least one Session Initiation Protocol (SIP) servlet. SIP is used to establish, modify, and terminate multimedia IP sessions including IP telephony, presence, and instant messaging.

Portlet applications and their container

Portlet applications are special reusable Java servlets that appear as defined regions on portal pages. Portlets provide access to many different applications, services, and web content.

EJB applications run in the EJB container

The EJB container provides all of the runtime services needed to deploy and manage enterprise beans. It is a server process that handles requests for both session and entity beans.

  • Enterprise beans are Java components that typically implement the business logic of Java EE applications, as well as accessing data. The enterprise beans, packaged in EJB modules, installed in an application server do not communicate directly with the server. Instead, the EJB container is an interface between EJB components and the application server. Together, the container and the server provide the enterprise bean runtime environment.
  • The container provides many low-level services, including threading and transaction support. From an administrative perspective, the container handles data access for the contained beans. A single container can host more than one EJB Java archive (JAR) file.

Web services

The diagram shows the web services engine, part of the web services support in the application server runtime. Web services are self-contained, modular applications that can be described, published, located, and invoked over a network. They implement a service-oriented architecture (SOA), which supports the connecting or sharing of resources and data in a flexible and standardized manner. Services are described and organized to support their dynamic, automated discovery and reuse.

The product acts as both a web services provider and as a requestor. As a provider, it hosts web services that are published for use by clients. As a requester, it hosts applications that invoke web services from other locations. The diagram shows the web services engine in this capacity, contacting a web services provider or gateway.

SCA composites

Service Component Architecture (SCA) composites consist of components that implement business functions in the form of services.

  • Data access, messaging, and Java EE resources
  • Data access resources

Connection management for access to enterprise information systems (EIS) in the application server is based on the Java EE Connector Architecture (JCA) specification. The diagram shows JCA services helping an application to access a database in which the application retrieves and persists data.

  • The connection between the enterprise application and the EIS is done through the use of EIS-provided resource adapters, which are plugged into the application server. The architecture specifies the connection management, transaction management, and security contracts between the application server and EIS.
  • The Connection Manager (not shown) in the application server pools and manages connections. It is capable of managing connections obtained through both resource adapters defined by the JCA specification and data sources defined by the JDBC 2.0 Extensions specification.
  • JDBC resources (JDBC providers and data sources) are a type of Java EE resource used by applications to access data. Although data access is a broader subject than that of JDBC resources, this information often groups data access under the heading of Java EE resources for simplicity.
  • JCA resource adapters are another type of Java EE resource used by applications. The JCA defines the standard architecture for connecting the Java EE platform to heterogeneous EIS. Imagine an ERP, mainframe transaction processing, database systems, and legacy applications not written in the Java programming language.
  • The JCA resource adapter is a system-level software driver supplied by EIS vendors or other third-party vendors. It provides the connectivity between Java EE application servers or clients and an EIS. To use a resource adapter, install the resource adapter code and create configurations that use that adapter. The product provides a predefined relational resource adapter for your use.

Messaging resources and messaging engines

JMS support enables applications to exchange messages asynchronously with other JMS clients by using JMS destinations (queues or topics). Applications can use message-driven beans to automatically retrieve messages from JMS destinations and JCA endpoints without explicitly polling for messages.

For inbound non-JMS requests, message-driven beans use a Java EE Connector Architecture (JCA) 1.5 resource adapter written for that purpose. For JMS messaging, message-driven beans can use a JCA-based messaging provider such as the default messaging provider that is part of the product.

The messaging engine supports the following types of message providers.

  • Default messaging provider (service integration bus): The default messaging provider uses the service integration bus for transport. The default message provider provides point-to-point functions, as well as publish and subscribe functions. Within this provider, you define JMS connection factories and destinations that correspond to service integration bus destinations.
  • WebSphere MQ provider: You can use WebSphere MQ as the external JMS provider. The application server provides the JMS client classes and administration interface, while WebSphere MQ provides the queue-based messaging system.
  • Generic JMS provider: You can use another messaging provider as long as it implements the ASF component of the JMS 1.0.2 specification. JMS resources for this provider cannot be configured using the administrative console.

Course Curriculum

Weekday / Weekend BatchesSee Batch Details

Service integration bus

The service integration bus provides a unified communication infrastructure for messaging and service-oriented applications. The service integration bus is a JMS provider that provides reliable message transport and uses intermediary logic to adapt message flow intelligently into the network. It supports the attachment of web services requestors and providers. Its capabilities are fully integrated into product architecture, including the security, system administration, monitoring, and problem determination subsystems.

The service integration bus is often referred to as just a bus. When used to host JMS applications, it is often referred to as a messaging bus. It consists of the following parts (not shown at this level of detail in the diagram).

  • Bus members
  • Application servers added to the bus.
  • Messaging engine

The component that manages bus resources. It provides a connection point for clients to produce or from where to consume messages as follows.

  • Destinations: The place within the bus to which applications attach to exchange messages. Destinations can represent web services endpoints, messaging point-to-point queues, or messaging publish and subscribe topics. Destinations are created on a bus and hosted on a messaging engine.
  • Message store: Each messaging engine uses a set of tables in a supported data store (such as a JDBC database) to hold information such as messages, subscription information, and transaction states.

Through the service integration bus web services enablement, you can:

  • Make an internal service that is already available at a service destination available as a web service.
  • Make an external web service available at a service destination.
  • Use the web services gateway to map an existing service, either an internal service or an external web service, to a new web service that appears to be provided by the gateway.

Additional services for use by applications:

Naming and directory

Each application server provides a naming service that in turn provides a Java Naming and Directory Interface (JNDI) name space. The service is used to register resources hosted on the application server. The JNDI implementation is built on a Common Object Request Broker Architecture (CORBA) naming service (CosNaming).

JNDI provides the client-side access to naming and presents the programming model used by application developers. CosNaming provides the server-side implementation and is where its name space is actually stored. JNDI essentially provides a client-side wrapper of the name space stored in CosNaming, and interacts with the CosNaming server on behalf of the client.

Clients of the application server use the naming architecture to obtain references to objects related to those applications. The objects are bound into a mostly hierarchical structure called the name space. It consists of a set of name bindings, each one of which is a name relative to a specific context and the object bound with that name. The name space can be accessed and manipulated through a name server.

This product provides the following naming and directory features.

  • Distributed name space, for additional scalability
  • Transient and persistent partitions, for binding at various scopes
  • Federated name space structure across multiple servers
  • Configured bindings for defining bindings bound by the system at server startup
  • Support for CORBA Interoperable Naming Service (INS) object URLs

Note that with the addition of virtual member manager to provide federated repository support for product security, the product now offers more extensive and sophisticated identity management capabilities than ever before, especially in combination with other WebSphere and Tivoli products.

Object Request Broker (ORB)

The product uses an ORB to manage interaction between client applications and server applications, as well as among product components. An ORB uses IIOP to enable clients to make requests and receive requests from servers in a network distributed environment.

The ORB provides a framework for clients to locate objects in the network and call operations on those objects as though the remote objects were located in the same running process as the client, providing location transparency. Although not shown in the diagram, one place in which the ORB comes into play is where the client container is contacting the EJB container on behalf of a Java client.


Part of the application server is the transaction service. The product provides advanced transactional capabilities to help application developers avoid custom coding. It provides support for the many challenges related to integrating existing software assets with a Java EE environment. These measures include ActivitySessions.

Applications running on the server can use transactions to coordinate multiple updates to resources as one unit of work such that all or none of the updates are made permanent. Transactions are started and ended by applications or the container in which the applications are deployed.

The application server is a transaction manager that supports coordination of resource managers and participants in distributed global transactions with other compliant transaction managers. The server can be configured to interact with databases, JMS queues, and JCA connectors through their local transaction support when distributed transaction support is not required.

How applications use transactions depends on the type of application, for example:

  • A session bean can either manage its transactions itself, or delegate the management of transactions to the container.
  • Entity beans use container-managed transactions.
  • Web components, such as servlets, use bean-managed transactions.

The product handles transactions with the following components.

  • A transaction manager supports the enlistment of recoverable XAResources and ensures each resource is driven to a consistent outcome, either at the end of a transaction, or after a failure and restart of the application server.
  • A container manages the enlistment of XAResources on behalf of deployed applications when it performs updates to transactional resource managers such as databases. Optionally, the container can control the demarcation of transactions for EJB applications that have enterprise beans configured for container-managed transactions.
  • An API handles bean-managed enterprise beans and servlets, allowing such application components to control the demarcation of their own transactions.

WebSphere extensions

WebSphere programming model extensions are the programming model benefits you gain by purchasing this product. They represent leading edge technology to enhance application capability and performance, and make programming and deployment faster and more productive.

In addition, your applications can use the Eclipse extension framework. Your applications are extensible as soon as you define an extension point and provide the extension processing code for the extensible area of ​​the application. You can also plug an application into another extensible application by defining an extension that adheres to the target extension point requirements. The extension point can find the newly added extension dynamically and the new function is seamlessly integrated in the existing application. It works on a cross Java Platform, Enterprise Edition (Java EE) module basis. The application extension registry uses the Eclipse plug-in descriptor format and application programming interfaces (APIs) as the standard extensibility mechanism for WebSphere applications. Developers who build WebSphere application modules can useWebSphere Application Server extensions to implement Eclipse tools and to provide plug-in modules to contribute functionality such as actions, tasks, menu items, and links at predefined extension points in the WebSphere application. For more information about this feature, see Application extension registry .

The various WebSphere programming model extensions, and the corresponding application services that support them in the application server runtime, can be considered in three groups:

  • Business Object Model extensions,
  • Business Process Model extensions, and
  • extensions for producing Next Generation Applications.

Extensions pertaining to the Business Object Model

Business object model extensions operate with business objects, such as enterprise bean (EJB) applications.

  • Application profiling
    • Application profiling is a WebSphere extension for defining strategies to dynamically control concurrency, prefetch, and read-ahead.
    • Application profiling and access intent provide a flexible method to fine-tune application performance for enterprise beans without impacting source code. Different enterprise beans, and even different methods in one enterprise bean, can have their own intent to access resources. Profiling the components based on their access intent increases performance in the application server runtime.
  • Dynamic query
    • Dynamic query is a WebSphere programming extension for unprecedented application flexibility. It lets you dynamically build and submit queries that select, sort, join, and perform calculations on application data at runtime. Dynamic Query service provides the ability to pass in and process EJB query language queries at runtime, eliminating the need to hard-code required queries into deployment descriptors during application development.
    • Dynamic query improves enterprise beans by enabling the client to run custom queries on EJB components during runtime. Until now, EJB lookups and field mappings were implemented at development time and required further development or reassembly in order to be changed.
  • Dynamic cache
    • The dynamic cache service improves performance by caching the output of servlets, commands, and JSP files. This service within the application server intercepts calls to cacheable objects and either stores the output of the object or serves the content of the object from the dynamic cache.
    • Because Java EE applications have high read-write ratios and can tolerate small degrees of latency in the currency of their data, the dynamic cache can create opportunity for significant gains in server response time, throughput, and scalability.
    • Features include cache replication among clusters, cache disk offload, Edge side include caching, and external caching – the ability to control caches outside of the application server, such as that of your Web server.

Extensions pertaining to the Business Process Model

Business process model extensions provide process, workflow functionality, and services for the application server. Use them in conjunction with business integration capabilities.

  • ActivitySessions
    • ActivitySessions are a WebSphere extension for reducing the complexity of dealing with commitment rules and limitations associated with one-phase commit resources.
    • ActivitySessions provide the ability to extend the scope of multiple local transactions, and to group them. This enables them to be committed based on deployment criteria or through explicit program logic.
  • Web services: Web services are self-contained, modular applications that can be described, published, located, and invoked over a network. They implement a services oriented architecture (SOA), which supports the connecting or sharing of resources and data in a very flexible and standardized manner. Services are described and organized to support their dynamic, automated discovery and reuse.

Extensions for creating next generation applications

Next generation extentions can be used in applications that need the specific extensions. These enable next generation development by leveraging the latest innovations that build on today’s Java EE standards. This provides greater control over application development, execution, and performance than was ever possible before.

  • Asynchronous beans: Asynchronous beans offer performance enhancements for resource-intensive tasks by enabling single tasks to run as multiple tasks. Asynchronous scheduling facilities can also be used to process parallel processing requests in batch mode at a designated time. The product provides full support for asynchronous execution and invocation of threads and components within the application server. The application server provides execution and security context for the components, making them an integral part of the application.
  • Startup beans: Startup beans allow the automatic execution of business logic when the application server starts or stops. For example, they might be used to pre-fill application-specific caches, initialize application-level connection pools, or perform other application-specific initialization and termination procedures.
  • Object pools: Object pools provide an effective means of improving application performance at runtime, by allowing multiple instances of objects to be reused. This reuse reduces the overhead associated with instantiating, initializing, and garbage-collecting the objects. Creating an object pool allows an application to obtain an instance of a Java object and return the instance to the pool when it has finished using it.
  • Internationalization: The internationalization service is a WebSphere extension for improving developer productivity. It allows you to automatically recognize the time zone and location information of the calling client, so that your application can act appropriately. The technology enables you to deliver each user, around the world, the correct date and time information, the appropriate currencies and languages, and the correct date and decimal formats.
  • Scheduler: The scheduler service is a WebSphere programming extension responsible for starting actions at specific times or intervals. It helps minimize IT costs and increase application speed and responsiveness by maximizing utilization of existing computing resources. The scheduler service provides the ability to process workloads using parallel processing, set specific transactions as high priority, and schedule less time-sensitive tasks to process during low traffic off-hours.
  • Work areas:
    • Work areas are a WebSphere extension for improving developer productivity. Work areas provide a capability much like that of global variables . They provide a solution for passing and propagating contextual information between application components.
    • Work areas enable efficient sharing of information across a distributed application. For example, you might want to add profile information as each customer enters your application. By placing this information in a work area, it will be available throughout your application, eliminating the need to hand-code a solution or to read and write information to a database.
IBM MDM Sample Resumes! Download & Edit, Get Noticed by Top Employers! Download

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:

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

Are you looking training with Right Jobs?

Contact Us
Get Training Quote for Free