Posts Tagged ‘websphere’

Ralationship between Webspere App Server and IBM Http Server(plugin)

May 7th, 2011 No comments

Here’s some excerpts from webspere redbook:

Web servers

Although Web servers are independent products, they can be defined to the WebSphere Application Server administration process. The primary purpose for this is to enable the administrator to associate applications with one or more defined Web servers in order to generate the proper routing information for Web server plug-ins if multiple servers are used.
Web servers are associated with nodes. These nodes can be managed or
1)Managed nodes have a node agent on the Web server machine that allows the deployment manager to administer the Web server. You can start or stop the Web server from the deployment manager, generate the Web server plug-in for the node, and automatically push it to the Web server. In most installations, you have managed Web server nodes behind the firewall with the WebSphere Application Server installations.
2)Unmanaged nodes are not managed by WebSphere. You usually find these outside the firewall or in the demilitarized zone. You have to manually transfer the Web server plug-in configuration file to the Web server on an unmanaged node. In a z/OS environment, you have to use unmanaged nodes if the Web server is not running on the z/OS platform.

Special case: If the unmanaged Web server is an IBM HTTP Server, you can administer it from the Integrated Solutions Console. This allows you to automatically push the plug-in configuration file to the Web server with the deployment manager using HTTP commands to the IBM HTTP Server administration process. This configuration does not require a node agent.
The IBM HTTP Server is shipped with all WebSphere Application Server packages.

Web server plug-ins

A Web server can serve static contents and requests, like 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 transfer (manually or automatically with the deployment manager) an Extensible Markup Language (XML) configuration file, configured 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 (Figure3-10).

The plug-in is used for routing requests to one of multiple application servers.

OK, now let’s take my system for demonstrating:

I’ve websphere 5.1 for windows installed, and the install_root is C:\Program Files\IBM\WebSphere\AppServer, node name & cell name are both user. The plug in file locates at C:\Program Files\IBM\WebSphere\AppServer\config\cells\plugin-cfg.xml.

Now let’s take http://localhost:9080/PlantsByWebSphere for example(This is an app attached with installation of websphere 5.1).

In file C:\Program Files\IBM\WebSphere\AppServer\config\cells\plugin-cfg.xml we can see there’re lines below:

<Uri Name=”/PlantsByWebSphere/*”/>
<Uri Name=”/PlantsByWebSphere/docs”/>
<Uri Name=”/PlantsByWebSphere/docs/*”/>

This means that all requests end with PlantsByWebSphere/*, PlantsByWebSphere/docs/, PlantsByWebSphere/docs/* are passed to websphere app servers for handling, and after that, websphere app server will give the results back to web server.

For more obvious example, we can see in plugin-cfg.xml these lines:

<Uri Name=”/hitcount”/>
<Uri Name=”*.jsp”/>
<Uri Name=”*.jsv”/>
<Uri Name=”*.jsw”/>

Which means only requests end with *.jsp, *.jsv, *.jsw are handled by websphere app server, others are directly handled by http server.

If you want to see the servlet class, servlet mapping and ejb etc definition, you can view C:\Program Files\IBM\WebSphere\AppServer\installedApps\user\PlantsByWebSphere.ear\PlantsByWebSphere.war\WEB-INF\web.xml for more information.

Categories: IT Architecture Tags:

configure syslog to redirect WebSphere Message Broker (mq) messages to file

April 29th, 2011 No comments

On Linux® and UNIX® systems, all WebSphere® Message Broker messages (other than those generated by the command line utilities) are sent to the syslog, so it is useful to redirect user messages to a separate file.

Start of changeOn UNIX, syslog entries are restricted in length and messages that are sent to the syslog are truncated by the new line character. To record a large amount of data in a log on UNIX, set the Destination property on the Trace node to File or User Trace instead of Local Error Log.End of change

Before you create a broker on Linux or UNIX systems, configure the syslog daemon to redirect user messages to a file called user.log:

Log on as root.
Enter the following commands to create a file called user.log.
On UNIX systems, enter the command:

touch /var/adm/user.log
chown root:mqbrkrs /var/adm/user.log
chmod 640 /var/adm/user.log

On Linux, enter the command:

touch /var/log/user.log
chown root:mqbrkrs /var/log/user.log
chmod 640 /var/log/user.log

Add the following line to the /etc/syslog.conf file Start of change(on later versions of SUSE Linux, this is /etc/syslog-ng.conf)End of change to redirect debug level messages to the file user.log:
On UNIX systems, enter the command: /var/adm/user.log

On Linux, enter the command: /var/log/user.log

You can use user.* – instead of in the preceding examples.
* means that information, notice, warning, and debug messages are caught
- means that syslog does not synchronize the file after writing to it.
You might experience a performance gain, but you can lose some data if the computer fails immediately after it has written to the file.
Start of changeAdd a line to ensure that messages at the required level from the user facility are recorded. If you specify a level of info, all operational messages are recorded; these messages provide important information about the operation of the broker, and can be useful in diagnosing problems.End of change
Restart the syslog daemon.
On AIX®, enter the command:

refresh -s syslogd

On HP-UX and Solaris, enter the command:

kill -HUP ‘cat /etc/’

On Linux, enter the command:

/etc/init.d/syslogd restart


/etc/rc.d/init.d/syslogd restart

for systems where rc.d is not a soft link
For other syslog options, see the documentation for your operating system.

About other websphere message broker documents, please refer to

Categories: IT Architecture, Linux Tags: , ,