IBM Websphere

The following link explains websphere application server communication process in layman’s term, a very good read – http://www.coderanch.com/t/446735/Websphere/IBM-HttpServer-websphere-Appserver [pic]

The WebSphere Application Server consists of the following components:

Administrative Server - responsible for maintaining the configuration of a WebSphere domain, providing security services, Work Load Management, and monitoring the run-time state. The Adminserver process runs in its own JVM on each node in a WebSphere domain (“cluster”).

Application Server - An Application Server in WebSphere is the process that is used to run your servlet and/or EJB-based applications, providing both the servlet run-time components (Servlet Engine, Web applications) and EJB run-time (EJB container). Like the Adminserver, each WebSphere Application Server runs in it’s own JVM.

Administrative Repository - stores the configuration for all WebSphere Application Server components inside a WebSphere domain. Each Adminserver communicates changes in configuration and run-time state to all other Adminservers through the Administrative Repository.

Administrative Console - Administrative Console provides an easy to use, graphical “window” to a WebSphere domain (“cluster”). The Administrative Console connects to one of the Adminservers running in a cluster and can be used change to the configuration or run-time state on any machine in a domain.

HTTP Server and HTTP Server Plugin - While the HTTP Server is not strictly part of the WebSphere runtime. WebSphere communicates with your HTTP server via a plug-in. This plug-in communicates requests from the HTTP server to the WebSphere runtime.

[pic]

Stateless: If the server processes each request based solely on information provided with that request itself, and not based on information that it “remembers” from earlier requests. In other words, the server does not need to maintain state information between requests.

Stateful: If the server that processes a request does need to access and maintain state information generated during the processing of an earlier request.

WAS Application Server in a Nutshell
Port 80 is for the connection between the browser and webserver (such as, IHS or IIS). Once webserver sends the request to WAS, request get routed to the respective jvm servlet port based on the plug-ins. In a clustered environment, no need to mention the port number. Plug-ins will route the request through whichever port is is available.
[pic]

Virtual Host
Virtual Host is associated with cell, not Node. It enables plug-ins to route requests to correct server. 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. 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.

Application Server is a Java process that encapsulates many services, including the web containers and EJB container, where business logic executes.

Web Container executes servlets and Java Server Pages (JSPs), that generate markup to be viewed by a Web browser. Traffic into and out of the Web container travels through the embedded HTTP Server. Servlets and JSPs most commonly make calls to Enterprise Java Beans(EJBs) to executes business logic or access data. Web container is essentially a Java-based web server contained within an application server’s JVM

Enterprise JavaBeans (EJB) technology is the server-side component architecture for the Java 2 Platform. They most commonly communicate with a relational database or other external source of application data, either returning that data to web Container or making changes to the data on behalf of the Servlet/JSP.
Web services engines enables application components to be exposed as Web services, which can be accessed using Simple Object Access protocol (SOAP).

HTTP Server Plug-in determines what HTTP traffic is intended to be handled by WebSphere, and routes the requests to the appropriate server. The plug-in is also a critical player in workload management of HTTP requests as it can distribute the load to the multiple application servers, as well as steer traffic away from unavailable servers.

A Node can be a member of multiple Node Group. To delete a node group, the node group must be empty. The default node group cannot be deleted. Nodes that are organized into a node group should be enough alike in terms of installed software, available resources, and configuration to enable servers on those nodes to host the same applications as part of a server cluster. The deployment manager does not validate the nodes in a given node group have anything in common. Managed nodes use node agent to manage web server and unmanaged nodes use IHS Admin Service.

A shared library is an external Java archive (JAR) file that is used by one or more applications. Using shared libraries enables multiple applications deployed on a server to use a single library, rather than use multiple copies of the same library. After you associate shared libraries with an application or module, the application or module class loader loads classes represented by the shared libraries and makes those classes available to the application or module.
Resources, such as, JDBC providers, namespace bindings, or shared libraries can be defined at multiple scopes. Resources that are defined at more specific scopes override duplicate resources that are defined at more general scopes: • The application scope has precedence over all the scopes. • The server scope has precedence over the node, cell, and cluster scopes. • The cluster scope has precedence over the node and cell scopes. • The node scope has precedence over the cell scope.

Admin console cannot directly communicate with application server. It communicates with dmgr, to node agent to AppSrver.
Admin Console=>DMGR=>Node Agent=>AppServer

Profile defines the runtime env for either dmgr or app server.
Cluster is a logical grouping of same application for workload management.
Plug-ins detect when app server stops responding to requests.
Web container processes servlets, jsp files and other types of server side includes.

WAS file directory – was_home is /usr/websphere610/appserver bin directory contains all the .sh files and lib directory contains all the jar files
Profile contains dmgr and node.

When an application or ear file is deployed, it is deployed within a respective jvm and whatever port that jvm is assigned with application use that port to communicate.

There is only one deployment manager (dmgr) per cell and it provides a central administrative console. Node Agent is responsible for administration at the node level.

** Important IBM Redbbok link – http://www.redbooks.ibm.com/redbooks/SG246451/wwhelp/wwhimpl/js/html/wwhelp.htm The flow of an application

[pic]

• A Web client requests a URL in the browser input page • The request is routed to the Web server over the Internet. • The Web server immediately passes the request to the Web server plug-in. • The Web server plug-in examines the URL, verifies the list of host name aliases from which it will accept traffic based on the virtual host information, and chooses a server to handle the request. • A stream is created. A stream is a connection to the Web container. It is possible to maintain a stream over a number of requests. The Web container receives the request and, based on the URL, it dispatches the request to the proper servlet. • If the servlet class is not loaded, the dynamic class loader loads the servlet (servlet init(), then doGet() or doPost()). • JNDI is used for lookup of either datasources or EJBs required by the servlet. • Depending upon whether a datasource is specified or an EJB is requested, the JNDI directs the servlet - to the corresponding database and gets a connection from its connection pool in the case of a data source. to the corresponding EJB container, which then instantiates the EJB when an EJB is requested. • If the EJB requested involves a SQL transaction, it goes back to the JNDI to look up the datasource. • The SQL statement is executed and the data is sent back either to the servlet or to the EJB. • Data beans are created and handed off to JSPs in the case of EJBs. • The servlet sends data to JSPs. • The JSP generates the HTML that is sent back through the WebSphere plug-in to the Web server. • The Web server sends the output HTML page to the browser.

System management in a distributed server environment

Websphere can be clustered horizontally or vertically. In a clustered environment, shared drive support is required which serves as a repository for common configuration files and data shared by all the management servers that are members of the cluster and should be accessible from all clustered servers.
Horizontal clustering is about adding physical machines to increase the performance or capacity to the cluster pool – it is referred to as scaling out. Horizontal cluster requires multiple physical servers, it is scalable, provides hardware failover and can be used in conjunction with vertical clusters.

The following diagram illustrates a horizontal cluster. All of the cluster nodes are on individual servers. The nodes are grouped into a cell and managed by a single Deployment Manager. All of the node use a common database and LDAP server. The database and LDAP server could also be clustered and in high traffic networks or networks where failover and recovery are critical, the database and LDAP server would typically be clustered in order to avoid a single point of failure.
[pic]

Vertical clustering is adding websphere application server instances to the same machine and referred to as scaling up. It is useful for taking advantage of unused resources in large servers. Vertical clustering can be used to create multiple jvm processes that, together, can use all of the available processing power. A vertical cluster provides process failover, increase efficiency with multiple jvm, provides load balancing through workload management, offers minimum scalability and doesn’t provide hardware failover.

How many vertical instances that can be created in a single node or server depends on the availability of physical resources in the local system (CPU and memory).
The following diagram illustrates a vertical cluster. The node is managed by the Deployment Manager. Each instance on the node authenticates with the same LDAP server and store data in the same database server. Although not depicted in the illustration, the database and LDAP servers could also be clustered if needed for failover, increased performance, and high availability.

[pic]

Hybrid Cluster – Most large-scale portal sites incorporate a combination of horizontal and vertical clustering to take full advantage of the resources of a single machine before scaling outward to additional machines.

[pic]

Load balancer – a load balancer distributes load across a number of systems. If there is more than one http server, you must use a load balancer. For moderately sized deployments, use a software based load balancer, such as, Edge Component. For larger deployments, which support a large number of concurrent users, use a hardware-based load balancer.
In a distributed server environment, administration tasks and configuration files are distributed among the nodes, reducing the reliance on a central repository or administration server for basic functions and bring-up. The administrative services and the administrative console are hosted on the deployment manager.
Managed application servers are installed on nodes. Each node has a node agent that interacts with the deployment manager to maintain and manage the processes on that node.
Multiple sets of the configuration files exist The master configuration is maintained on the deployment manager node and pushed out, synchronized, to the nodes. Each managed process starts with its own configuration file.

Deployment Manager
In a distributed server environment, the deployment manager maintains a master configuration repository that contains all of the cell's configuration data. The configuration repository at each node is a synchronized subset of the master repository. The node repositories are read-only for application server access. Only the deployment manager can initiate their update and push out configuration changes from the cell master configuration repository.

Node Agent
The node agent is an administrative process and is not involved in application serving functions. It hosts important administrative functions such as:
|[p|[|[|File transfer services |
|ic|p|p| |
|] |i|i| |
| |c|c| |
| |]|]| |

|[p|[|[|Configuration synchronization |
|ic|p|p| |
|] |i|i| |
| |c|c| |
| |]|]| |

|[p|[|[|Performance monitoring |
|ic|p|p| |
|] |i|i| |
| |c|c| |
| |]|]| |

The node agent aggregates and controls all the managed processes on its node by communicating with:
|[pic|The deployment manager to coordinate configuration synchronization and to perform management operations on behalf of the |
|] |deployment manager. |

|[pic|Application servers and managed Web servers to manage (start or stop) each server and to update its configuration and |
|] |application binaries as required. |

Only one node agent is defined and run on each node. In a stand-alone server environment, there is no node agent.

[pic]

Configuration should always be done at the deployment manager and synchronized out to the nodes. Although theoretically, it is possible to configure nodes locally using wasdmin, it is not recommended and any changes made will be overwritten at the next synchronization.
Each node agent and deployment manager maintains status and configuration information by using discovery addresses, or ports. On startup, processes discover other running components, and create communication channels between them, through the discovery addresses:

[pic]

The master repository located on the deployment manager installation contains the serverindex.xml file for each node. The deployment manager reads this file on startup to determine the host name and IP port of each node agent's NODE_DISCOVERY_ADDRESS. • The default port for the NODE_DISCOVERY_ADDRESS is 7272. You can verify this by looking at the NODE_AGENT stanza in the serverindex.xml file of each node located at: /config/cells//nodes//serverindex.xml

[pic]

• The copy of the configuration repository located on each node contains the serverindex.xml file for the deployment manager. The node agent reads this file on startup to determine the host name and IP port of the deployment manager's CELL_DISCOVERY_ADDRESS. The default port for the CELL_DISCOVERY_ADDRESS is port 7277.

/config/cells//nodes//serverindex.xml

[pic]

• The copy of the configuration repository located on each node also contains the serverindex.xml file for the node. Each managed server reads this file on startup to determine the host name and IP port of the node agent's NODE_MULTICAST_DISCOVERY_ADDRESS The default port for the NODE_MULTICAST_DISCOVERY_ADDRESS is 5000.

** A multicast address is a logical address. Therefore it is not bound to a real, physical network interface, and will not be the same as the host name (or IP address) of the host on which the node agent is executed. Multicast host addresses must be within a special range (224.0.0.0 to 239.255.255.255) defined by the IP standards and must never be a host name value. The default for WebSphere node agents is 232.133.104.73. Here is the IP (232.133.104.73) from our Test env –

[pic]

The order of process startup needs to adhere to the following rules: • A node agent can be running while the deployment manager is not, and vice versa. When the stopped process is started, discovery will occur automatically. • The deployment manager can be running while a managed server is not, and vice versa. The execution of a managed server is not dependent on the presence of a running deployment manager. The deployment manager is only required for permanent configuration changes written to the master repository. • The node agent should be started before any application servers on that node. The node agent contains the Location Service Daemon (LSD) in which each application server registers on startup. • The node agent is purely an administrative agent and is not involved in application serving functions. Each managed server has the data necessary to start itself.

Each node contains a separate copy of the repository containing only the files required for that node, including:
During the synchronization operation, the node agent checks with the deployment manager to see if any files that apply to the node have been updated in the master repository. New or updated files are sent to the node, while any deleted files are also deleted from the node. Synchronization is one-way. The changes are sent from the deployment manager to the node agent. No changes are sent from the node agent back to the deployment manager.

Websphere Directory Structure
Each node, deployment manager, and standalone application server has its own profile directory under the /profiles directory.
The /config directory is the root of the repository for each profile. It contains the following directory structure: cells// [pic]

This is the root level of configuration for the cell. The directory contains a number of cell-level configuration settings files. Depending on the types of resources have been configured, you might see the following subdirectories:

- cells//applications/ contains one subdirectory for every application that has been deployed within the cell. - cells//buses/ contains one directory for each service integration bus (bus) defined. - cells//coregroups/ contains one directory for each core group defined. - cells//nodegroups/ contains one directory for each node group defined. - cells//nodes/ contains the configuration settings for all nodes and servers managed as part of this cell. The directory contains one directory per node. Each cells//nodes/ directory will contain node-specific configuration files and a server directory which in turn will contain one directory per server and node agent on that node. - cells//clusters/ contains one directory for each of the clusters managed as part of this cell. Each cluster directory contains a single file, cluster.xml, which defines the application servers of one or more nodes that are members of the cluster. - cells//applications/.ear Each application's directory in the master repository contains the following: 1) A copy of the original EAR, called .ear, which does not contain any of the bindings specified during installation of the application 2) A deployments directory, which contains a single directory used to contain the deployed application configuration. - cells//applications/.ear/deployments/ The deployment directory of each application contains the following: deployment.xml=>this file contains configuration data for the application deployment, including the allocation of application modules to application servers, and the module startup order. META-INF/ => contains application.xml (application deployment descriptor), ibm-application-bnd.xmi (application bindings), ibm-application-ext.xmi (application extensions), was.policy (Java 2 security configuration)

The overall structure of the master repository is the same for both a standalone server environment and a distributed server environment. The differences are summarized in the following sections.
In a standalone server environment, the structure has the following: - The master repository is held on a single machine. There are no copies of this specific repository on any other node. - The repository contains a single cell and node. - There is no node agent because each application server is stand-alone so there is no directory for the node agent (nodeagent). - Clusters are not supported, and therefore will not contain the clusters directory or subdirectories.

In a distributed server environment, the structure has the following: - The master repository is held on the node containing the deployment manager. It contains the master copies of the configuration and application data files for all nodes and servers in the cell.

- Each node also has a local copy of the configuration and application data files from the master repository that are relevant to the node. - Changes can be made to the configuration files on a node, but the changes will be temporary. Such changes will be overwritten by the next file synchronization from the deployment manager. Permanent changes to the configuration require changes to the file or files in the master repository. Configuration changes made to node repositories are not propagated up to the cell. - The applications directory of the master repository contains the application data (binaries and deployment descriptors) for all applications deployed in the cell. The local copy of the applications directory on each node will only contain the directories and files for the applications deployed on application servers within that node.

What Happens when an application ear file is deployed into Websphere WAS?
The installation of an application onto a Websphere Application Server results in: The storage of the application binaries (ear) and deployment descriptor within the master repository. The publishing of the application binaries and deployment descriptors to each node that will be hosting the application. These files are stored in the local copy of the repository of each node.
However, each node then installs applications ready for execution by exploding the ear under the /installedApps// as follows: /installedApps//=>this directory contains a subdirectory for each application deployed to the local node. The name of each application’s directory reflects the name under which application is installed, not the name of the ear file. For example, if an application is called myapp, then the installedapps/ directory will contain a myapp.ear subdirectory. /installedApps//.ear/ =>each application-specific directory contains the contents of the original ear used to install the application – deployment descriptor from the original ear, all application binaries (jar, classes, jsp) Following figure summarizes how the node’s local copy of the repository contains the application’s installed deployment descriptors, while the directory under installedApps contains the application binaries.

[pic]

How Websphere WAS executes an application?
Websphere application server executes an application by 1) loading the application binaries stored under /installedApps//.ear/ and 2) configuring the application using the deployment descriptors stored /config/cells//applications/.ear/deployments/

Websphere Plug-ins
Although the Web container can serve static content, a more likely scenario is that you will use an external Web server to receive client requests. The Web server can serve requests that do not require any dynamic content, for example, HTML pages. However, when a request requires dynamic content, such as JSP or servlet processing, it must be forwarded to WebSphere Application Server for handling.
To forward a request, you use a Web server plug-in that is included with the WebSphere Application Server packages for installation on a Web server. You copy an Extensible Markup Language (XML) configuration file, located on the WebSphere Application Server, to the Web server plug-in directory. The plug-in uses the configuration file to determine whether a request should be handled by the Web server or an application server. When WebSphere Application Server receives a request for an application server, it forwards the request to the appropriate Web container in the application server. The plug-in can use HTTP or HTTPs to transmit the request.

DB2 II4C (Information Integrator for Content)
DB2 Information Integrator for Content (II4C) Version 8 provides a rich set of APIs which allows developers to build transparent access to critical unstructured and structured information across and beyond the enterprise. IBM Information Integrator for Content can combine data from several different data sources (for example, library server and ImagePlus) and join this data into one view for the client. This allows clients maintaining databases from several different vendors, possibly also using a Content Management system backend, to query across all databases efficiently. This distributed querying and joining is called federation.

Websphere IICE (Information Integrator for Content Edition)
IBM’s Information Integrator Content Edition (IICE) provides the framework to enable organizations with an enterprise content integration strategy, resulting in multiple disparate content sources looking and acting as one system.