What is WAS
- Provides the infrastructure for running applications that
run your business.
- Common environment and programming model
for your applications.
- Platform for developing and Deploying web
services and SOA based apps
- Secure, Scalable, reliable transaction
engine for ERP
- IBM WebSphere is architected to enable you to build
business-critical applications for the Web
- WebSphere
includes a wide range of products that help you develop and serve Web
applications.
- They are designed to
make it easier for clients to build, deploy, and manage dynamic Web sites more productively
à WAS implements J2EE specification
WebSphere Application
Server provides the environment to run your Web-enabled e-business
applications. An application server functions as Web middleware or
a middle tier in a three-tier e-business environment. The first tier is the
HTTP server that handles requests from the browser client. The third tier is the
business database (for example, DB2 UDB for iSeries) and the business logic (for
example, traditional business applications, such as order processing). The
middle tier is WebSphere Application Server, which provides a framework for a
consistent and architected link between the HTTP requests and the business data
and logic.
With the Base and Express packages, you are limited to single
application server environments. The Network Deployment package allows you to
extend this environment to include multiple application servers that are
administered from a single point of control and can be clustered to provide
scalability and high availability environments.
The typical application flow is as follows:
1. A Web client requests a URL in the browser
(input page).
2. The request is routed to the Web server over
the Internet.
3. The Web server immediately passes the
request to the Web server plug-in.
All requests go to the Web server plug-in
first.
4. 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.
5. A stream is created. A stream is a
connection to the Web container. It is
possible to maintain a connection (stream) over
a number of requests. The
Web container receives the request and, based
on the URL, dispatches it to
the proper servlet.
6. If the servlet class is not loaded, the
dynamic class loader loads the servlet
(servlet init(),
then doGet() or doPost()).
7. JNDI is used for lookup of either
datasources or EJBs required by the servlet.
8. 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.
9. If the EJB request involves an SQL
transaction, it goes back to the JNDI to
look up the datasource.
10.The SQL statement is executed and the
retrieved data is sent back either to
the servlet or to the EJB.
11.Data beans are created and handed off to
JSPs in the case of EJBs.
12.The servlet sends data to JSPs.
13.The JSP generates the HTML that is sent back
through the plug-in to the Web
server.
14.The Web server sends the output page (output
HTML) to the browser.
Functionality of WAS
WebSphere Application
Server supports asynchronous messaging through the use of a JMS provider and
its related messaging system.(JMS 1.1 Messaging Provider)
WebSphere Application
Server provides authentication and authorization capabilities to secure
administrative functions and applications, using LDAP
WebSphere Application
Server works with a Web server (such as the IBM HTTP Server) to route requests
from browsers to the applications that run in WebSphere Application Server. Web
server plug-ins are provided for installation with supported Web browsers. The
plug-ins direct requests to the appropriate application server and perform
workload balancing among servers in a cluster.
Web services enable
businesses to connect applications to other business applications, deliver
business functions to a broader set of clients and partners, interact with
marketplaces more efficiently, and create new business models dynamically.
Delivers a high
performance and extremely scalable transaction engine for dynamic e-business
applications
Differences b/n WAS Version
Version 8.5.5-
WebSphere Application Server V8.5.5 includes significant
enhancements to the Liberty profile compared to v8.5. The WebSphere Application
Server Liberty Core edition leverages the lightweight and dynamic aspects of the
Liberty profile.
Version 8.5-
WebSphere Application Server V8.5 offers the same Java EE 6
and Java SE 6 (by default) as V8.0 and also provides - and can be configured to
run on - Java SE 7. The primary new capabilities in V8.5 are the Liberty
profile of WebSphere Application Server and the intelligent management
features.
The Liberty profile of WebSphere Application Server is
included with all the commercial editions of the server, providing a
lightweight profile of the server for web, mobile and OSGi applications. It is
a functional subset of the full profile of WebSphere Application Server, for
both development and production use, with an install size of under 50 MB, a
startup time of around 3 seconds and a new XML-based server configuration which
can be treated as a development artefact to aid developer productivity. Server
capabilities are engaged through the set of features defined in the server
configuration; features are added and removed dynamically through internal use
of OSGi services. A new model is provided for moving applications through the
pipeline from development to production as a packaged server; this is a
complete archive of the server, server configuration and application for unzip
deploy. A centralized managed install is optionally available through the Job
Manager component of WebSphere Application Server Network Deployment edition.
Intelligent management capability is added in the Network
Deployment and z/OS editions of WebSphere Application server. This integrates
operational features that were previously available in the separate WebSphere
Virtual Enterprise (WVE) offering: application editioning, server health
management, dynamic clustering and intelligent routing.
Version 8.0-
This version was released on June 17, 2011. It is a Java EE
6 compliant application server and incorporates the capabilities originally
delivered as feature packs with WebSphere Application Server V7. This version
of WebSphere Application Server is installed using the IBM Installation
Manager.
Version 7.0-
This version was released on September 9, 2008. It is a Java
EE 5 compliant application server.
Following are the flagship features introduced by WebSphere
Application Server Version 7:
Flexible Management
Flexible Management facilitates administration of a large
number of WebSphere Application Server base edition and Network Deployment
topologies that might be geographically distributed.
Business-Level Application
Business-Level Application is used for managing application
artifacts independent of packaging or programming models.
Property Based Configuration
The Property Based Configuration feature simplifies the
experience of automating administration: an administrator can update the
WebSphere Application Server Version 7 configuration using a simple property
file.
Between the general availability of WebSphere Application
Server V7 and WebSphere Application Server V8 (in 2011), a number of additional
capabilities were made available for V7 in the form of feature packs which are
optionally added to a V7 install. Feature Pack content has the same quality and
support as main release content - the purpose of a feature pack is to deliver
new innovation before the next major release. The following feature packs were
provided for WebSphere Application Server V7:
Feature Pack for Modern Batch
Feature Pack for OSGi Applications and JPA 2.0
Feature Pack for SCA
Feature Pack for Web 2.0 and Mobile
Feature Pack for XML
Feature Pack for Communication Enabled Applications
Version 6.1-
This version was released on June 30, 2006. On September 11,
2012, IBM extended the end of service for V6.1 by a full year, to September 30,
2013, and announced new version-to-version migration incentives and
assistance.[9] It is a Java EE 1.4 compliant application server and includes
the following function:
Support for Java Standard Edition 1.5
Support for running JSR 168 Portlets in the application
server
Session Initiation Protocol (SIP) Servlets
Enhancements to the WebSphere Install Factory
IBM Support Assistant
IBM JSF Widget Library
Simplified Administration
Improved Certificate and Key Management
Security Enhancements
Administration of IBM HTTP Server from WebSphere Admin
Console
Support for (pre-OASIS) WS-Security 1.0
Support for Web Services Resource Framework and
WS-BusinessActivity (WS-BA)
Support for JSR160 JMX Remote Connections (From IBM Agents
Only)
Administrative Console Jython Command Assistance
Enhanced scripting. This version started the deprecation
process for the Jacl syntax.[10]
64-bit servants and a new Apache-based IBM HTTP Server for
z/OS
Support for the EJB 3.0 technology and support for some
webservices standards were provided by the EJB feature pack and the webservices
feature packs, respectively. These function in these feature packs has been
folded into the main product in version 7. Functions in the webservices feature
pack include:
Asynchronous programming model (Limited functional support)
Multiple Payload structures
StAX (Streaming API for XML)
WS-RM (Limited functional support)
Support for (OASIS specified) WS-Security 1.0.
WS-Addressing (Limited functional support)
JAX-B support
Policy Set (Limited functional support)
Secured thin client (Limited functional support)
SOAP (protocol) Message Transmission Optimization Mechanism
(MTOM)
Supports CGI and CORBA
Version 6.0-
This version was released on December 31, 2004. It is a Java
EE 1.4 compliant application server. Security enhancements include support for
JACC 1.0 and (pre-OASIS) WS-Security 1.0.
Support for Java Standard Edition 1.4
Community Edition (free, support for fee)
Code based on Apache Geronimo project
Many programming model extensions previously found in
WebSphere Application Server V5.0 Enterprise Edition were moved out of
enterprise and into Express and Base. These APIs included application profile,
startup beans, the scheduler, and async beans.
The JMS engine, now called "WebSphere Platform
Messaging," was rewritten in 100% Java and its functionality greatly
enhanced. (WebSphere MQ is still supported as the JMS provider and is
interoperable with WebSphere Platform Messaging.)
The clustering was rewritten to use the high availability
manager. This manages all singletons in the WebSphere environment and can
provide hot recovery for those singletons.
WebSphere was modified so that a shared file system can be
used to store transaction logs and this meant that any cluster member with that
shared file system mounted can hot recover in-doubt XA transactions with no
external HA software.
The Deployment Manager's role was eliminated from all
clustering runtime operations. It's only required for centralized JMX admin and
config changes.
Now supports running mixed version cells (V5 to V6) in
production.
WebSphere Application Server for z/OS
Provides the same core functionality as Network Deployment,
since it shares a common programming model, but still contains the platform
advantages such as:
z/OS Workload Manager for prioritized management of mixed
workloads
Resource Recovery Services (added transactional integrity
for complex, critical transactions)
Support for security mainframe products such a RACF
Advanced vertical scaling for application server by
featuring a unique control region (integrated control area) server region
(where workloads are completed) separation which enables the control region to
open and close server regions as needed by the volume of incoming requests
Parallel Sysplex support for full participation in the
Sysplex, enabling advanced failover support and a geographically dispersed
environment that seamlessly acts as one with a centralized logging and
management facility
WAS XD as it is known increases the functionality of the
application server in two main areas - Manageability and Performance. It also
allows makes possible new configurations, such as dynamic virtualization
between pools of application servers.
Under the performance header the ObjectGrid component was
added, which is a standalone distributed cache that can be used with any
application server (any version with a 1.4 JDK) or with any J2SE 1.4 runtime,
including zLinux and z/OS support.
With Version 6, some of the functionality previously found
in WebSphere Business Integration Server Foundation (WBISF) moved into the new
IBM WebSphere Process Server. Other function moved into the other editions
(Express and above).
Version 5.1-
This version was released on 16 Jan 2004. It is a J2EE 1.4
compliant application server.
Express
Base
Network Deployment
WebSphere Application Server for z/OS
Version 5.1 for z/OS is the first to support zAAP engines.
WebSphere Business Integration Server Foundation V5.1
This is the follow on product to WebSphere Application
Server Enterprise Edition V5.0. The workflow engine was updated to support BPEL
rather than the proprietary FDML format used in V5.0. The product was also
repriced and available on all IBM platforms from the Intel environments to the
mainframe.
WebSphere eXtended Deployment (XD)
Version 5.0-
The version released on 19 November 2002. This was a J2EE
1.3 certified application server. It was a major rewrite of the V3/V4 codebase
and was the first time WebSphere Application Server was coded from a common
codebase. Now WAS across all deployment platforms, from Intel x86 to the
mainframe, are substantially the same code. The database-based configuration
repository was replaced with a replication XML file-based configuration
repository. A service called the Deployment Manager had the master copy of the
cell configuration, and nodes had the file(s) they needed copied from this
master server whenever they changed. V5 also included a miniature version of MQ
5.3 called the embedded Java Message Service (JMS) server.
Express Edition replaces the Standard Edition. Express now
becomes the term to indicate SME-oriented offerings from IBM, across all its
software brands.
Base
Network Deployment. This version supports deployment of a
cell configuration with cluster and J2EE failover support. It now also includes
Edge Components, previously known as Edge Server. This provides a proxy server,
load balancing, and content-based routing.
Enterprise Edition. This version added a workflow engine,
called the Process Choreographer, for the first time but predates the BPEL
standard. It also added the first fully supported application threading model
called WebSphere Asynchronous Beans.
WebSphere Application Server for z/OS. This version is
essentially the same as the Network Deployment product but is optimized to take
full advantage of z/OS features, such as Workload Manager, to leverage the key
technologies that make the mainframe indispensable for mission-critical,
scalable, and secure workloads.
Questions related to Installation and Migration:
Please refer to other modules of the BLOG.
Profile Types
Cell Profile
Cell profiles are actually two profiles in one. You get a deployment manager
profile and a federated application server profile. You have a choice whether
to install Samples and the default application. The default application
provides an application server called server1 and an enterprise application
called Default Application. Both the Samples and the default application
provide servlets that you can run in a Web browser to test your installation.
Deployment Manager
Profile
The deployment manager is special type of application server that hosts
administrative console and has functionality to administer the application
servers that are federated into cell. All the cell level configuration is
stored in the deployment manager profile. It also has the master copy of the
application servers, node agents. The Deployment manager profile will have
master copy of all the installed applications.
Important Note Applications are installed at the the cell level.
Application Server
profile
Application server profile contains configuration information for one managed
server. It will has information about server level resources and configuration.
It will also have copy of the installed application
Custom Profile
Custom profiles are empty nodes that are made operational by adding a
deployment manager cell. After adding the node, use the administrative console
for the deployment manager to customize the node. For example, create
application servers on the node or clusters. A custom node does not include a
server1 process as an application server node does. Nor does it include the
default application or any Sample applications. It is truly an empty node that
you must customize.
Configuring
Lightweight Directory Access Protocol user registries
Procedure
- In the administrative console, click Security
> Secure administration, applications, and infrastructure.
- Under User account repository, click the Available
realm definitions drop-down list, select Standalone LDAP
registry, and click Configure.
- Enter a valid user name in the Primary
administrative user name field. You can either enter the
complete distinguished name (DN) of the user or the short name of the
user, as defined by the user filter in the Advanced LDAP settings panel.
For example, enter the user ID for Netscape browsers. This ID is the
security server ID, which is only used for WebSphere Application Server
security and is not associated with the system process that runs the
server. The server calls the local operating system registry to
authenticate and obtain privilege information about users by calling the
native application programming interfaces (API) in that particular
registry.
- Optional: If
you want to use the server ID that is stored in the repository, complete
the following substeps:
- Select Automatically generated server identity to
enable the application server to generate the server identity that is
used for internal process communication. You can change this server
identity on the Authentication mechanisms and expiration panel. To access
the Authentication mechanisms and expiration panel, clickSecurity >
Secure administration, applications, and infrastructure >
Authentication mechanisms and expiration. Change the value of the Internal
server ID field.
- Alternatively, specify a user identity in the
repository that is used for internal process communication in the Server
identity that is stored in the repository field.
- Alternatively, specify the user ID that is used to run
the application server for security purposes in the Server user
ID or administrative user on a Version 6.0.x node field.
- Select the type of LDAP server to use from the Type list. The
type of LDAP server determines the default filters that are used by
WebSphere Application Server. These default filters change the Type field
to Custom, which indicates that custom filters are used. This
action occurs after you click OK or Apply in
the Advanced LDAP settings panel. Choose the Custom type
from the list and modify the user and group filters to use other LDAP
servers, if required.
IBM
Tivoli Directory Server users can choose IBM Tivoli Directory Server as the
directory type. Use the IBM Tivoli Directory Server directory type for better
performance. For a list of supported LDAP servers, see the Supported hardware, software, and APIs Web site.
Attention: IBM SecureWay Directory Server has been renamed to IBM
Tivoli Directory Server in WebSphere Application Server version 6.1.
- Enter the fully qualified host name of the LDAP server
in the Host field. You can enter either the IP
address or domain name system (DNS) name.
- Enter the LDAP server port number in the Port field. The
host name and the port number represent the realm for this LDAP server in
the WebSphere Application Server cell. So, if servers in different cells
are communicating with each other using Lightweight Third Party
Authentication (LTPA) tokens, these realms must match exactly in all the
cells.
The
default value is 389. If multiple WebSphere Application Servers are
installed and configured to run in the same single sign-on domain, or if the
WebSphere Application Server interoperates with a previous version of the
WebSphere Application Server, then it is important that the port number match
all configurations. For example, if the LDAP port is explicitly specified as
389 in a version 5.x configuration, and a WebSphere Application
Server at version 6.0.x is going to interoperate with the version
5.xserver, then verify that port 389 is specified
explicitly for the version 6.0.x server.
You
can set the com.ibm.websphere.security.ldap.logicRealm custom property to
change the value of the realm name that is placed in the token. For more
information, see the security custom properties topic.
- Enter the base distinguished name (DN) in the Base
distinguished name field. The base DN indicates the starting
point for searches in this LDAP directory server. For example, for a user
with a DN of cn=John Doe, ou=Rochester,
o=IBM, c=US, specify the base DN as any of
the following options assuming a suffix of c=us):ou=Rochester, o=IBM, c=us or o=IBM c=us or c=us. For authorization purposes, this field is case
sensitive by default. Match the case in your directory server. If a token
is received (for example, from another cell or Lotus Domino) the base DN in
the server must match exactly the base DN from the other cell or Domino.
If case sensitivity is not a consideration for authorization, enable the Ignore
case for authorization option.
In
WebSphere Application Server, the distinguished name is normalized according to
the Lightweight Directory Access Protocol (LDAP) specification. Normalization
consists of removing spaces in the base distinguished name before or after
commas and equal symbols. An example of a non-normalized base distinguished
name is o = ibm, c = us or o=ibm, c=us. An example of a
normalized base distinguished name is o=ibm,c=us.
To
interoperate between WebSphere Application Server Version 5 and later versions,
you must enter a normalized base distinguished name in the Base
Distinguished Name field. In WebSphere Application Server, Version
5.0.1 or later, the normalization occurs automatically during runtime.
This
field is required for all LDAP directories except the Lotus Domino Directory.
The Base Distinguished Name field is optional for the Domino
server.
- Optional: Enter
the bind DN name in the Bind distinguished name field. The
bind DN is required if anonymous binds are not possible on the LDAP server
to obtain user and group information. If the LDAP server is set up to use
anonymous binds, leave this field blank. If a name is not specified, the
application server binds anonymously. See the Base Distinguished
Name field description for examples of distinguished names.
- Optional: Enter
the password corresponding to the bind DN in the Bind password field.
- Optional: Modify
the Search time out value. This timeout value is the maximum amount
of time that the LDAP server waits to send a response to the product
client before stopping the request. The default is 120 seconds.
- Ensure that the Reuse connection option
is selected. This option specifies that the server should reuse the
LDAP connection. Clear this option only in rare situations where a router
is used to send requests to multiple LDAP servers and when the router does
not support affinity. Leave this option selected for all other situations.
- Optional: Verify
that the Ignore case for authorization option is enabled. When
you enable this option, the authorization check is case insensitive.
Normally, an authorization check involves checking the complete DN of a
user, which is unique in the LDAP server and is case sensitive. However,
when you use either the IBM Directory Server or the Sun ONE (formerly
iPlanet) Directory Server LDAP servers, you must enable this option
because the group information that is obtained from the LDAP servers is
not consistent in case. This inconsistency affects the authorization check
only. Otherwise, this field is optional and can be enabled when a case
sensitive authorization check is required. For example, you might select
this option when you use certificates and the certificate contents do not
match the case of the entry in the LDAP server.
You
can also enable the Ignore case for authorization option when
you are using single sign-on (SSO) between the product and Lotus Domino. The
default is enabled.
- Optional: Select
the SSL enabled option if you want to use Secure Sockets
Layer communications with the LDAP server.
Important: This
step will only be successful provided that the Signer certificate for the LDAP
is first added to the truststore that will be eventually used. If the Signer
certificate from the LDAP is not added to the truststore, then
- An error will be issued by the Administrative console.
- the deployment manager (DMGR) systemout.log will show
the CWPKI0022E: SSL HANDSHAKE FAILURE message indicating
that the Signer certificate needs to be added to the truststore.
To ensure an error free operation for this step, You need to first
extract to a file the Signer certificate of the LDAP and send that file to the
WebSphere Application Server machine. You can then add the certificate to the
truststore being defined for the LDAP. In this way, you are assured that the
remaining actions for this step will be successful.
If you select the SSL enabled option,
you can select either the Centrally managed or the Use
specific SSL alias option.
Centrally managed
Enables you to specify an SSL configuration for
particular scope such as the cell, node, server, or cluster in one location. To
use the Centrally managed option, you must specify the SSL
configuration for the particular set of endpoints. The Manage endpoint security
configurations and trust zones panel displays all of the inbound and outbound
endpoints that use the SSL protocol. If you expand the Inbound or Outbound
section of the panel and click the name of a node, you can specify an SSL
configuration that is used for every endpoint on that node. For an LDAP
registry, you can override the inherited SSL configuration by specifying an SSL
configuration for LDAP. To specify an SSL configuration for LDAP, complete the
following steps:
- Click Security > SSL certificate and key
management > Manage endpoint security configurations and trust zones.
- Expand Outbound > cell_name >
Nodes > node_name > Servers > server_name >
LDAP.
Use specific SSL alias
Select the Use specific SSL alias option
if you intend to select one of the SSL configurations in the menu below the
option.
This configuration is used only when SSL is
enabled for LDAP. The default is DefaultSSLSettings. You can modify
or create a new SSL configuration. To create a new SSL configuration, complete
the following steps:
- Click Security > SSL certificate and key
management.
- Under Configuration settings, click Manage
endpoint security configurations.
- Select a Secure Sockets Layer (SSL) configuration_name for
selected scopes, such as a cell, node, server, or cluster.
- Under Related items, click SSL configurations.
- Click New.
- Click OK and either Apply or Save until
you return to the Secure administration, applications, and infrastructure
panel.
Difference between AppServer and a Web server :
(1) Webserver serves pages for viewing in web
browser, application server provides exposes businness logic for client
applications through various protocols
(2) Webserver exclusively
handles http requests.application server serves bussiness logic to application
programs through any number of protocols.
(3) Webserver delegation model
is fairly simple,when the request comes into the webserver,it simply passes the
request to the program best able to handle it(Server side program). It may not
support transactions and database connection pooling.
(4)
Application server is more capable of dynamic behaviour than webserver. We can
also configure application server to work as a webserver.Simply applic! ation
server is a superset of webserver.
Session
affinity:
Most
servers use the term "Session Affinity" to indicate that within a
cluster of servers, requests from the same client always get routed back to the
same server. (or) In a clustered environment, any HTTP requests associated with
an HTTP session must be routed to the same Web application in the same JVM.
Session Persistance:
You
use session persistence to permanently store data from an HTTP session object
to enable failover and load balancing across a cluster of WebSphere Applicaiton
Servers.
Sessiontracking:
Session
tracking enables you to track a user's progress over multiple servlets or HTML
pages, which, by nature, are stateless.
How do
you set session time out :
You
can specify an interval of time after which HTTP sessions expire.
click
Servers > Application servers > server_name > Web container settings
> Session management > Session Timeout
What are the different levels at which
session timeout can be set
application level, web module level, server level
How do
you take back ups in WAS: backupConfig.sh
[filename] -nostop
What is
the out put file: WebSphereConfig_yyyy-mm-dd.zip
How do
you restore back ups: restoreConfig.sh <filename.zip> -nostop
What are
the different kinds of sync operations
1.
Automatic synchronization.
2.
Manual synchronization.
3.
Startup synchronization.
How do
you disable auto sync
System
Administration > nodeagent > file synchronization service > Uncheck
automatic synchronization.
What is
the default interval for auto sync
60
seconds.
Explain
JNDI in WAS
Each
application server hosts a name service that provides a Java Naming and
Directory Interface (JNDI) name space. The service is used to register resources
hosted by the application server. The JNDI implementation in WebSphere
Application Server is built on top of a Common Object Request Broker
Architecture (CORBA) naming service (CosNaming).
JNDI
provides the client-side access to naming and presents the programming model
that application developers use. CosNaming provides the server-side
implementation and is where the 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.
Simple
name
The
simple name binding is guaranteed to succeed if lookup is within the same
server or when connected directly to the name space of the server containing
the target of the lookup. It can be used in a servlet or EJB, if it is certain
that the object is located on the same application server. Here is an example
of a simple name:
ejb/webbank/Account
Corbaname
The
corbaname binding is always guaranteed to work. However, it requires that you know the correct path to the object at
deployment time. Here is an example of a corbaname:
corbaname::myhost1:9812/NameServiceServerRoot#ejb/webbank/Account
Compound
name/remote/complex
Applications
that do not run in the same server cannot use simple name lookup because the
simple name is not local to the application. Instead, an application of this
type must look the object up directly from the name server. Each application
server contains a name server. System artifacts such as EJB homes are bound
relative to the server root context in that name server. The fully qualified
(compound name) JNDI name is always guaranteed to work.
Here
is an example of a compound name:
cell/nodes/node1/servers/server1/ejb/webbank/Account
When do you use dumpNameSpace.sh
Run the dumpNameSpace command against any
bootstrap port to get a listing of the names bound with that provider URL.
Explain
JDBC Connection Pooling
Each
JDBC data source has a pool of JDBC connections that are created when the data
source is deployed or at server startup. Applications use a connection from the
pool then return it when finished using the connection. Connection pooling
enhances performance by eliminating the costly task of creating database
connections for the application.
Each
data source that you configure contains a pool of database connections that are
created when the data source instance is created-when it is deployed or
targeted, or at server startup.
Connection Timeout
Specifies the interval, in seconds, after which a connection request times out and a ConnectionWaitTimeoutException is thrown.
The wait is necessary when the maximum value of connections (Max Connections) to a particular connection pool is reached . For example, if Connection Timeout is set to 300 and the maximum number of connections is reached, the Pool Manager waits for 300 seconds for an available physical connection. If a physical connection is not available within this time, the Pool Manager throws a ConnectionWaitTimeoutException. It usually does not make sense to retry thegetConnection() method, because if a longer wait time is required, you should set the Connection Timeout setting to a higher value. Therefore, if this exception is caught by the application, the administrator should review the expected usage of the application and tune the connection pool and the database accordingly.
If Connection Timeout is set to 0, the Pool Manager waits as long as necessary until a connection is allocated (which happens when the number of connections falls below the value of Max Connections).
If Max Connections is set to 0, which enables an infinite number of physical connections, then the Connection Timeout value is ignored.
| Data type | Integer |
| Units | Seconds |
| Default | 180 |
| Range | 0 to max int |
Max Connections
Specifies the maximum number of physical connections that you can create in this pool.
These are the physical connections to the backend resource. Once this number is reached, no new physical connections are created and the requester waits until a physical connection that is currently in use returns to the pool, or a ConnectionWaitTimeoutException is thrown.
For example, if the Max Connections value is set to 5, and there are five physical connections in use, the pool manager waits for the amount of time specified in Connection Timeout for a physical connection to become free.
If Max Connections is set to 0, the Connection Timeout value is ignored.
For better performance, set the value for the connection pool lower than the value for the Max Connections option in the Web container. Lower settings, such as 10-30 connections, perform better than higher settings, such as 100.
If clones are used, one data pool exists for each clone. Knowing the number of data pools is important when configuring the database maximum connections.
You can use the Tivoli Performance Viewer to find the optimal number of connections in a pool. If the number of concurrent waiters is greater than 0, but the CPU load is not close to 100%, consider increasing the connection pool size. If the Percent Used value is consistently low under normal workload, consider decreasing the number of connections in the pool.
| Data type | Integer |
| Default | 10 |
| Range | 0 to max int |
Min Connections
Specifies the minimum number of physical connections to maintain.
Until this number is reached, the pool maintenance thread does not discard physical connections. However, no attempt is made to bring the number of connections up to this number. If you set a value for Aged Timeout, the minimum is not maintained. All connections with an expired age are discarded.
For example if the Min Connections value is set to 3, and one physical connection is created, the Unused Timeout thread does not discard that connection. By the same token, the thread does not automatically create two additional physical connections to reach the Min Connections setting.
| Data type | Integer |
| Default | 1 |
| Range | 0 to max int |
Reap Time
Specifies the interval, in seconds, between runs of the pool maintenance thread.
For example, if Reap Time is set to 60, the pool maintenance thread runs every 60 seconds. The Reap Time interval affects the accuracy of the Unused Timeout and Aged Timeout settings. The smaller the interval, the greater the accuracy. If the pool maintenance thread is enabled, set the Reap Time value less than the values of Unused Timeout and Aged Timeout. When the pool maintenance thread runs, it discards any connections remaining unused for longer than the time value specified in Unused Timeout, until it reaches the number of connections specified in Min Connections. The pool maintenance thread also discards any connections that remain active longer than the time value specified in Aged Timeout.
The Reap Time interval also affects performance. Smaller intervals mean that the pool maintenance thread runs more often and degrades performance.
To disable the pool maintenance thread set Reap Time to 0, or set both Unused Timeout and Aged Timeout to 0. The recommended way to disable the pool maintenance thread is to set Reap Time to 0, in which case Unused Timeout and Aged Timeout are ignored. However, if Unused Timeout and Aged Timeout are set to 0, the pool maintenance thread runs, but only physical connections which timeout due to non-zero timeout values are discarded.
| Data type | Integer |
| Units | Seconds |
| Default | 180 |
| Range | 0 to max int |
Unused Timeout
Specifies the interval in seconds after which an unused or idle connection is discarded.
Set the Unused Timeout value higher than the Reap Timeout value for optimal performance. Unused physical connections are only discarded if the current number of connections not in use exceeds the Min Connections setting. For example, if the unused timeout value is set to 120, and the pool maintenance thread is enabled (Reap Time is not 0), any physical connection that remains unused for two minutes is discarded. Note that accuracy of this timeout, as well as performance, is affected by the Reap Time value. See Reap Time for more information.
| Data type | Integer |
| Units | Seconds |
| Default | 1800 |
| Range | 0 to max int |
Aged Timeout
Specifies the interval in seconds before a physical connection is discarded.
Setting Aged Timeout to 0 supports active physical connections remaining in the pool indefinitely. Set the Aged Timeout value higher than the Reap Timeout value for optimal performance. For example, if the Aged Timeout value is set to 1200, and the Reap Time value is not 0, any physical connection that remains in existence for 1200 seconds (20 minutes) is discarded from the pool. Note that accuracy of this timeout, as well as performance, are affected by the Reap Time value. See Reap Time for more information.
| Data type | Integer |
| Units | Seconds |
| Default | 0 |
| Range | 0 to max int |
Purge Policy
Specifies how to purge connections when a stale connection or fatal connection error is detected.
Valid values are EntirePool and FailingConnectionOnly.
- If you set the purge policy for this data source object to EntirePool, all connections in the pool are marked stale. Any connection not in use is immediately closed. A connection in use is closed and throws a StaleConnectionException during the next operation on that connection. Subsequent getConnectionrequests from the application result in new connections to the database opening. When using this purge policy, there is a slight possibility that some connections in the pool are closed unnecessarily when they are not stale. However, this is a rare occurrence. In most cases, a purge policy of EntirePool is the best choice.
- If you set the purge policy for this data source object to FailingConnectionOnly, only the connection that caused the StaleConnectionException is closed. While this setting eliminates the possibility that valid connections are closed unnecessarily, it makes recovery from an application perspective more complicated. Because only the currently failing connection is closed, there is a good possibility that the next getConnection request from the application can return a connection from the pool that is also stale, resulting in more stale connection exceptions.
WebSphere Version 4.0 data sources always have a purge policy of EntirePool; JCA data sources have the options of EntirePool orFailingConnectionOnly.
| Data type | String |
| Default | EntirePool |
| Range | EntirePool or FailingConnectionOnly |
What are stale connection exceptions
When
an application receives a stale connection exception on a database operation,
it indicates that the connection currently held is no longer valid.
(or)
Whenever a troubled connection is encountered, a
staleConnectionException is raised. (A troubled connection is an inconsitent connection
object in a connection pool)
Tuning Parameters in Websphere App Server:
- Tracing and
logging flags
Most tracing and monitoring is controlled using the administrative
console. Make sure that the appropriate level of tracing/monitoring is set
for PMI monitoring, logging, and tracing using the administrative console.
- 64-bit mode
WebSphere Process Server 7.0 runs on WebSphere Application
Server for z/OS 7.0, which can be configured to run in 64-bit mode.
Activating 64-bit mode introduces performance overhead. Some of the
measurements that are described experienced significant performance
degradations when running in 64-bit mode with no apparent benefit. The
performance degradations garbage collection statistics showed that the
Java heap was not under stress, so there was no benefit to be gained by
increasing the heap size beyond values that were available in 31-bit mode.
- Java tuning
parameters
This section lists frequently used Java Virtual Machine (JVM) tuning
parameters.
- Workload profile
The number of servant threads can be configured by setting the workload
profile for the server. The number of threads for each profile setting is
determined using a formula involving the number of processors that are
available.
- Workload manager
service class
The z/OS operating system assigns machine resources to process the
requests based on the workload manager service class which has been
assigned. Ensure that the workload manager has been configured to classify
the requests to receive an appropriate level of service.
- MDB
ActivationSpec
JMS activation specifications are used to bind application MDBs to the
message queues which drive the MDB onMessage methods. Two activation
specification parameters of particular interest are the maximum batch size
and the maximum concurrent endpoints.
- MQ listener port
For the MQ or MQJMS binding, a Listener Port is used for configuring the
delivery of inbound messages to WebSphere Process Server or WebSphere
Enterprise Service Bus. Listener Ports are the equivalent of JMS
Activation Specifications for binding application MDBs to message queues.
They have similar parameters which can be configured in the Message
Listener Service part of the WAS administrative console.
- MDB throttle
On WebSphere Application Server for z/OS, a control of the MDB processing
is the MDB throttle which is used to prevent the z/OS WLM work queue
becoming full of messages waiting to be processed by worker threads in the
WebSphere Application Server servant. The MDB throttle limits how far a
message listener port reads ahead down a JMS queue (or topic) to ensure
that the backlog of messages to be processed on the WLM request queue does
not become too large.
- Thread pool sizes
WebSphere uses thread pools to manage concurrent tasks. To set the maximum
size property of a thread pool, open the administrative console and
navigate to Servers > Application servers > server name >
Additional Properties > Thread Pools > (thread pool name).
- JMS connection
pool sizes
You can increase the maximum connection pool size to allow for greater
concurrency. Note that if only one deployed application is obtaining
connections from a particular connection factory, there is no benefit in
increasing the maximum queue connection pool size beyond the maximum
concurrency as configured within the activation specification.
- DataSource
Connection Pool Size
You can adjust the minimum and maximum number of connections to DB2 for
z/OS®, and the wait for connection timeout value.
- DataSource
prepared statement cache size
The prepared statement cache optimises the processing of prepared SQL
statements and callable statements.
- Messaging engine
properties
Two message engine custom properties can impact the messaging engine
performance.
- Minimize security
The security features of WebSphere Application Server provide
important protection against unauthorized use of resources. while not
advocating that security be completely disabled, there are various
security mechanisms available, each of which add processing overhead.
- Disable automatic
synchronization for network deployment
In a network deployment configuration the node agent synchronizes the
deployment manager configuration data with that of the node. If this
synchronization occurs too frequently, overall system performance can be
effected.
How do
you disable security for Deployment manager without logging into the console: security.xml
, enable=false
If you have to change the ports of a jvm
manually without logging into the admin console which file would you edit: serverindex.xml
What is
the plugin configuration file and where is it located
The
plug-in configuration file (plugin-cfg.xml)
contains routing information for all applications mapped from the web server to
the application server.
How do u regenerate the plugin config file
The
GenPluginCfg command is used to regenerate the plug-in configuration file.
Depending on the operating platform, the command is:
Linux
and Unix: GenPluginCfg.sh
Windows:
GenPluginCfg.bat
When do u regenerate the plugin config file
The
plug-in configuration file needs to be regenerated and propagated to the Web
servers when there are changes to your WebSphere configuration that affect how
requests are routed from the Web server to the application server.
These
changes include:
_
Installing an application (this part is not needed if you are using WAS 7 or above)
_
Creating or changing a virtual host
_
Creating a new server
_
Modifying HTTP transport settings (i.e HTTP ports)
_
Creating or altering a cluster
When do you manually edit the plugin config file
When
enabling SSL (specifying the key file name), LoadBalanceWeight, and minimum
number of connections.
What is the information in a plugin config file
Plugin
config file contains routing information along with information on virtual
hosts, clusters (cluster members), and URIs.
When the request comes to a webserver how does the
webserver know the JVM that is capable of handling that request.
The
webserver first takes the request and if it can't serve, it forwards the
request to the plugin config file . The plugin config file routes the request to the appropriate application server
(or cluster member or jvm) according to the mapping information it has.
What is the refresh interval of plugin: 60
seconds
If a change is made to the plugin config should the
webserver be restarted?
Not
Required because the plugin's automatic refresh interval is 60 seconds.
What is
collector tool
The collector tool
gathers information about your WebSphere Application Server installation and
packages it in a Java archive (JAR) file that you can send to IBM Customer
Support to assist in determining and analyzing your problem. Information in the
JAR file includes logs, property files, configuration files, operating system
and Java data, and the presence and level of each software prerequisite. Collector
tool can be run by only root or
administrator.
Syntax
It must be invoked from a temporary work directory
> WAS_INSTALL_LOCATION/bin/collector.sh | bat
Can we start Server without NA? -- No {Neither via console nor via Command Line)
How can we install same EAR file in same cluster twice - Change the context root of 2nd EAR
Impact to App if DMGR/NA are down - No Impact
Can we create 2 Data Sources with name JNDI Name - No
What is the difference between queue and topic?
A1:
A connection is created between the client and the server from a connection factory. Connections can be shared by several threads. The user credentials are supplied at this level. It is probably common for a client application to share access to a single connection to the server (unless different security credentials are required for different destinations). A session is created from a connection. The session may only be used by one thread at one time. The user credentials are inherited from the parent connection.
It is probably common for each MessageProducer (TopicPublisher or QueueSender) or MessageConsumer (TopicSubscriber or QueueReceiver) to have their own session due to the threading restriction. You can look at it like a tree. At the top you have a connection factory, beneath this you have your connections and then beneath the connections you have sessions. The leaves of the tree are the JMS actors (MessageProducers and MessageConsumers).
A2:
Both work on 2 different comminication models. Queue is point-to-point and topic is publish-subscriber.
A3:
In queues, one message can be consumed by only one client. But in the topics, one message can be consumed by many clients. Both are separate domains in MOM.
Queue represent Point-To-Point domain and Topic represent Pub/Sub domain
A4:
A point-to-point (PTP) product or application is built around the concept of message queues, senders, and receivers. Each message is addressed to a specific queue, and receiving clients extract messages from the queue(s) established to hold their messages. Queues retain all messages sent to them until the messages are consumed or until the messages expire.
In a publish/subscribe (pub/sub) product or application, clients address messages to a topic. Publishers and subscribers are generally anonymous and may dynamically publish or subscribe to the content hierarchy. The system takes care of distributing the messages arriving from a topic's multiple publishers to its multiple subscribers. Topics retain messages only as long as it takes to distribute them to current subscribers.
In what cases, App Server needs a restart:
|
