Deploying Flex on WebSphere Application Server

Increasingly as we step further in to the depths of the enterprise we find more and more of our customers are using WebSphere Application Server (WAS).

When it comes to using Flex Data Services (FDS) on WAS you must modify your Flex configuration if you want to use RTMP. I thought it would be beneficial to other developers taking their first tentative steps with FDS and WAS to walk through the steps necessary to deploy your Flex-based application on WAS. I have written this blog entry against WebSphere Application Server Base V6. This is IBM's grown-up application server for which you pay a license fee. I haven't used the community edition of WAS, which is based on Apache Geronimo. I hope to see Geronimo as a supported application server in the future.

 

So what's different?
Very briefly, the intention behind the J2EE platform. is to protect the developer from low-level coding such as multi-threading. As such, there are a number of restrictions in the J2EE programming model when it comes to multi-threading. For example, it is illegal to create your own threads in a J2EE container. This restriction makes asynchronous processing difficult. When asynchronous processing is required developers normally turn to the Java Messaging Service (JMS). However, this is not ideal when you want concurrent processing. In this case WAS provides a programming model extension (PME) for asynchronous beans that allows developers to to create work items that execute out of a thread pool (work manager) managed by the application server. The concept of a work manager is being standardised under JSR 237 (Work Managers for Application Servers) by IBM and BEA. It is also referred to as the CommonJ Work Manager specification and is part of the J2EE 1.4 specification.

There are other benefits to this PME, but we won't cover them here. All I really wanted to say is the RTMP end-point is implemented using asynchronous beans, which requires us to configure the work manager (thread pool) for the RTMP work items.

The work manager is configured under the WAS admin console and is accessed using JNDI - this is what we need to configure!

There are also a couple of bits of configuration in Flex that we need to un-comment. The Flex configuration uses a resource-ref, which is essentially an alias that the code can use to refer to the resource - the work manager in our case. At deployment time we bind the resource-ref to the JNDI name of our resource. I won't delve in to the benefits of using resource references other than to say they are considered best-practice. Finally, just so the config makes sense, an application uses the java:comp/env namespace when it is using a resource-ref.

 

So what do we do?
To start , I am going to assume you have WebSphere Application Server Base or higher installed.

Second, we need our resource-ref. Open the web desployment descriptor, web.xml, for your FDS application. At the bottom you will see the following commented out, which you need to un-comment:

<resource-ref>
   <description>Flex Messaging WorkManager</description>
   <res-ref-name>wm/MessagingWorkManager</res-ref-name>
   <res-type>com.ibm.websphere.asynchbeans.WorkManager</res-type>
   <res-auth>Container</res-auth>
   <res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>

This defines the resource-ref for our work manager with the name wm/MessagingWorkManager. As I mentioned above the code looks up a resource-ref in the java:comp/env namespace. Therefore the full name that will be used in the code is java:comp/env/wm/MessagingWorkManager. With this in mind lets move on to our third step.

Edit services-config.xml and fine the definition for my-rtmp and you will see the following commented out, again you need to un-comment it:

<websphere-workmanager-jndi-name>java:comp/env/wm/MessagingWorkManager</websphere-workmanager-jndi-name>

This tells the RTMP end-point the name of the work manager to use, which is java:comp/env/wm/MessagingWorkManager.

Next start WAS and log in to the admin console (http://localhost:9060/ibm/console/).

From the admin console navigate to Resources >Asynchronous beans > Work managers.

Click the New button and configure your work manager as follows:

Property Value
Name MessagingWorkManager
JNDI name  wm/MessagingWorkManager
Number of alarm threads  5
Minimum number of threads  1
Maximum number of threads  10
Thread Priority  5
Growable true

Tip: the Work Manager thread pool is definetly going to be something you want to monitor and tune during performance and scalability testing (before your application goes in to production). You can monitor the work manager with the Tivoli Performance Viewer, which is included with WebSphere Application Server Base (this is why I like to start to like WAS - it's the value of the supporting tools and documentation).

Save your configuration and restart your server.

You can now deploy your application using the admin console where you will be required to bind your resource reference (i.e. wm/MessagingWorkManager) to the JNDI name of your work manager (i.e. wm/MessagingWorkManager). Yes they are both called the same in our example, but they don't need to be.

 

What about deploying the application from the command line?
If you want to deploy on the command line or genrally avoid specifying the binding at deploy time you can define your resource binding in IBM's binding file (ibm-web-bnd.xmi). You will need an id on your resource-ref and an associated binding in ibm-web-bnd.xmi. The ibm-web-bnd.xmi file needs to live in the same directory as web.xml (i.e. under WEB-INF).

web.xml - resource-ref

<resource-ref id="ResourceRef_1163934666921">
   <description>Flex Messaging WorkManager</description>
   <res-ref-name>wm/MessagingWorkManager</res-ref-name>
   <res-type>com.ibm.websphere.asynchbeans.WorkManager</res-type>
   <res-auth>Container</res-auth>
   <res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>

ibm-web-bnd.xmi

<?xml version="1.0" encoding="UTF-8"?>
<webappbnd:WebAppBinding xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:webappbnd="webappbnd.xmi" xmi:id="WebAppBinding_1163849897296" virtualHostName="default_host">
  <webapp href="WEB-INF/web.xml#WebApp_ID"/>
  <resRefBindings xmi:id="ResourceRefBinding_1163934666921" jndiName="wm/MessagingWorkManager">
    <bindingResourceRef href="WEB-INF/web.xml#ResourceRef_1163934666921"/>
  </resRefBindings>
</webappbnd:WebAppBinding>

Tip: If you use the application server toolkit (AST), that comes with WebSphere it provides decent editors that do all the hard work for you :)

 

So what's next?
I plan to write a few more blog entries surronding WAS, these include:

Developer workflow - looking at how we develop against WAS when we don't want to spend a bundle on IBM tooling. I will talk more about the AST here.
Single Sign-on (SSO) - increasing we are being asked about SSO with Flex, the most common configuration being SiteMinder and WAS. I have already put together a SSO example (not using SiteMinder) that proves the concept. I will blog this when Flex 2.0.1 is released. If you want to know more in the mean time drop me a line.