The Enigma of WebSphere Application Server Plug-in, Part-1: What, why and How


This is a 4 part series which covers WebSphere Application Server Plugin related topics like: what is plug-in, why should you use plug-in, how does plug-in works, Different components invloved in plugin operation, Plgin configuration file, Configurable parameters, Troubleshooting and merging multiple plug-in files. This article series is written assuming that IBM http server is used as web server in front of the WebSphere application server. 

The first part of this article, discuss the basics of the websphere application server plug-in. In this part, you’ll understand what is plugin, advantages of plugin and how a plugin routes requests to the backend web containers.

What is WebSphere Application Server Plugin?
The IBM WebSphere Application Server Web server plug-in is the “glue” between a Web server and WebSphere Application Server. The plug-in was developed using native programming language “C”.

What does plugin do?
Plug-in forwards HTTP requests from the Web server to the WebSphere Application Server.

How do i get the Plugin?
It comes along with the WebSphere Application Server installation CD or part of your downloaded image.

Before we start ……
take a look at the below image.


In general, there will a web server sitting infront of the websphere application server. The request from browser/internet will first comes to web server and then it gets redirected/forwarded to application server. This forwarding/redirection is handled by the plugin. This redirection happens based on a set of rules defined in the plugin configuration file. The Web server gives the WebSphere plug-in an opportunity to handle every request first, and only when WebSphere is not configured to service that URL does the request go to the Web server for servicing.

What are advantages of using webserver and plugin?

  1. The plug-in provides work load management and failover capabilities by distributing requests evenly to multiple application servers and routing requests away from a failed application server.
  2. Static content can be served by the Web server without doing a full round trip to the application server.
  3. The Web server provides an additional hardware layer between the Web browser and the application server, thus strengthening the application server’s security.

components involved in plugin operation

  • Web server : which first receives the request
  • httpd.conf : This contains the reference to the plugin so/dll file and reference to the plugin configuration file.
  • Plugin : It is loaded into memory by the Web server during startup and runs inside the same process as the Web server.
  • plugin-cfg.xml : configuration file of the plugin, which contains iinformation about which URLs will be served by backend application servers
  • http transport : which accepts the forwarded request from plugin, on the application server side
  • web container: which actually handles the request

How does Plug-in work ?

A)Plug-in initialization

  • When web server is starting, httpd.conf will be read
  • httpd.conf will have: 1)LoadModule reference to the path of the plugin so/dll file. 2)WebSpherePluginConfig reference will have the path to plugin-cfg.xml
  • While web server is starting , it loads websphere plugin using LoadModule reference
  • Plugin will load configuration file using WebSpherePluginConfig reference, into the plugin process.
  • Then configuration file will be parsed and validated

Whenever the Web server receives a new HTTP request, it first passes that request to the plug-in. The plug-in determines whether this request should be handled by WebSphere by matching the URL requested to all the URLs defined in plugin-cfg.xml.

If plugin-cfg.xml is updated, it can automatically be reloaded by the plug-in without requiring a restart of the Web server. By default, the plug-in attempts to reload the plug-in configuration file every 60 seconds

<?xml version=”1.0″ encoding=”ISO-8859-1″?>
<Config ASDisableNagle=”false” AcceptAllContent=”false” AppServerPortPreference=”HostHeader” ChunkedResponse=”false” FIPSEnable=”false
” HTTPMaxHeaders=”300″ IISDisableNagle=”false” IISPluginPriority=”High” IgnoreDNSFailures=”false” RefreshInterval=”60″ ResponseChunkSi
ze=”64″ SSLConsolidate=”false” TrustedProxyEnable=”false” VHostMatchingCompat=”false”>
<Log LogLevel=”Error” Name=”/www/logs/ibmhttp/http_plugin.log”/>
<Property Name=”ESIEnable” Value=”true”/>
<Property Name=”ESIMaxCacheSize” Value=”1024″/>
<Property Name=”ESIInvalidationMonitor” Value=”false”/>
<Property Name=”ESIEnableToPassCookies” Value=”false”/>

The plug-in does this by checking the timestamp of plugin-cfg.xml, and if the timestamp has changed since the previous check, it reloads it.

B) How does plug-in determines where to send the request?

The plug-in compares the request to each route.

<Route ServerCluster=”app1_cluster” UriGroup=”joseph-app1_app1l_cluster_URIs” VirtualHostGroup=”joseph-app1″/>

<UriGroup Name=”joseph-app1_app1l_cluster_URIs”>
<Uri AffinityCookie=”JSESSIONID” AffinityURLIdentifier=”jsessionid” Name=”/app1_context/*”/>
</UriGroup>

<VirtualHostGroup Name=”joseph-app1″>
<VirtualHost Name=”testapp1:80″/>
<VirtualHost Name=”testapp1.joseph.com:80″/>
<VirtualHost Name=”app1-dev.joseph.com:9081″/>
<VirtualHost Name=”app1-dev.joseph.com:9444″/>
<VirtualHost Name=”app2-dev.joseph.com:9081″/>
<VirtualHost Name=”app2-dev.joseph.com:9444″/>
</VirtualHostGroup>

If a match for URIGroup and VirtualHostGroup is found, the plug-in sends the request to the associated Server.

If there are multiple servers in the servercluster, the request is sent to one of them depending upon various factors such as WLM policy, session information, etc.

<ServerCluster CloneSeparatorChange=”false” GetDWLMTable=”false” IgnoreAffinityRequests=”true” LoadBalance=”Round Robin” Name=”appl
_cluster” PostBufferSize=”64″ PostSizeLimit=”-1″ RemoveSpecialHeaders=”true” RetryInterval=”60″>

<Server CloneID=”abcdxyz” ConnectTimeout=”0″ ExtendedHandshake=”false” LoadBalanceWeight=”2″ MaxConnections=”-1″ Name=”appnode1_server1_app1″ ServerIOTimeout=”0″ WaitForContinue=”false”>
<Transport Hostname=”app1-dev” Port=”9081″ Protocol=”http”/>
<Transport Hostname=”app1-dev” Port=”9444″ Protocol=”https”>
<Property Name=”keyring” Value=”/www/ibmhttp/Plugins/config/dev/plugin-key.kdb”/>
<Property Name=”stashfile” Value=”/www/ibmhttp/Plugins/config/dev/plugin-key.sth”/>
</Transport>
</Server>

<Server CloneID=”xyzabcd” ConnectTimeout=”0″ ExtendedHandshake=”false” LoadBalanceWeight=”2″ MaxConnections=”-1″ Name=”appnode2_server1_app2″ ServerIOTimeout=”0″ WaitForContinue=”false”>
<Transport Hostname=”app2-dev” Port=”9081″ Protocol=”http”/>
<Transport Hostname=”app2-dev” Port=”9444″ Protocol=”https”>
<Property Name=”keyring” Value=”/www/ibmhttp/Plugins/config/dev/plugin-key.kdb”/>
<Property Name=”stashfile” Value=”/www/ibmhttp/Plugins/config/dev/plugin-key.sth”/>
</Transport>
</Server>

<PrimaryServers>
<Server Name=”appnode1_server1_app1″/>
<Server Name=”appnode2_server1_app2″/>
</PrimaryServers>

</ServerCluster>

C) Sending requests to application server?

This is handled in two steps:

  1. Once the server/clone determination has been made [step-B], the plug-in breaks down the HTTP request into its various components such as HTTP header, GET/POST data, etc. A new data packet is created by populating an empty HTTP client object with data from the user request. Once this new HTTP client object has been populated, it is ready to be sent. If the plug-in is configured to communicate with the HttpTransport over SSL, it is required to perform security functions as well.
  2. The request will be sent by flushing out the client object stream to the network using TCP/IP.

D) Receiving response from application Server

After sending a request to the application server, plug-in will wait for the response.

  • If a response from the application server has been received by the plug-in, the response is passed on to the Web server and then to the Web browser
  • If there is no response from the selected server, then that application server is marked as unreachable and is then taken out of the routing algorithm for a period specified by the RetryInterval. In a ServerCluster, request will be passed on to other clones. If communication with every clone in the cluster fails due timeouts, then you receive an HTTP 500 error.

<ServerCluster CloneSeparatorChange=”false” GetDWLMTable=”false” IgnoreAffinityRequests=”true” LoadBalance=”Round Robin” Name=”appl
_cluster” PostBufferSize=”64″ PostSizeLimit=”-1″ RemoveSpecialHeaders=”true” RetryInterval=”60″>

References:

In the next part, we will learn about different parameters, how plugin handles servers and configuration options.

Advertisements

12 thoughts on “The Enigma of WebSphere Application Server Plug-in, Part-1: What, why and How

  1. Waldauf says:

    Hello,

    very good serieses. Thx for that. But I cannot find out all articles (3rd and 4th). Can you write URL of these articles?

    Thx,

    Waldauf

  2. BodySoulKiller says:

    Thank you very very much for your explanation.

    Seriously, WebSphere components are hell of tools (they are might and power) but without the knowledge we keep burning ourselves try to handle it.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s