« August 2006 | Main | January 2007 »
November 22, 2006
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.
Posted by at 02:03 PM | Comments (10)
November 11, 2006
FlexUnit for Ant Update#3
You can download a new release of FlexUnit for Ant, which fixes a few bugs people have experienced recently. For more details on how to use FlexUnit for Ant please see my earlier blog. There is also documentation on the flexunit Ant task parameters at the end of this blog. You can download FlexUnit from Adobe Labs.
Binary distribution
Source Distribution
Example Project
Ant Task Parameters
Attribute |
Description |
Required |
|---|---|---|
| swf | The name of SWF containing the tests to execute. | Yes |
| port | The port to receive the test results on from FlexUnit. The default port is 1024. | No |
| timeout | The time in milliseconds to wait for results from FlexUnit before stopping the building process. The default is 60 seconds. You need to allow enought time for your tests to run as the socket is opended prior to the test execution. | No |
| toDir | The output directory for the test resutlts. The default is the working directory. | No |
| haltonfailure | Stop the build process if a test fails. The default is true. | No |
| failureproperty | The name of the property to set in the event of a failure. The default is 'flexunit.failed''. | No |
| verbose | Causes the flexunit tasks to print status messages. The default is false. | No |
Posted by at 10:04 PM | Comments (1)
November 01, 2006
Beyond MAX 2006
I have now arrived back in Scotland after MAX 2006 in Las Vegas, where I presented on "Understanding Security in Flex and Flash".
It is certainly strange being back home - Vegas and Edinburgh are a world apart, but I guess you could say that about Vegas and any city.
Now MAX 2006 is over I would be interested in knowing what you thought? I found MAX 2006 to be enjoyable and informative. I have come back bursting with enthusiasm with all sorts of old and new ideas and like allot of you I am desperate to create my first Apollo application - I won't mention the $100 million dollar investment fund created by Adobe for companies building Apollo apps ;)
I was also joined by some of my fellow colleagues from Edinburgh, Steven Webster who presented on "Delivering RIA Solutions with Cairngorm 2", Ali McLeod who presented on "Increasing Efficiency and Quality with Flex Automation" and last but not least Alex Uhlmann who wowed us with his cinematic effects when he presented on "Leveraging Flex 2 and Flash Player 9 for Truly Cinematic Experiences". Next year at MAX 2007 I hope we will all be back and will be able to strengthen our Scottish contingent.
My favourite presentations from MAX other than the ones from Adobe Consulting were:
- Designing More Usable Applications with Flex UI Capabilities (Albert Poon & Brett Rampata) - a really good talk on the importance of design.
- Flex Under the Hood: A tour through the Flex Architecture (Ely Greenfield) - a detailed look at creating custom components in Flex.
- Techniques for Delivering Modular Flex Applications (Roger Gonzalez) - a good talk on how to optimise SWF files which leads in to modularising Flex apps (new in 2.0.1).
Like allot of you I enjoyed the MAXUP sessions and hope to see more of this in the future.
Over the coming weeks and months I hope to release a new version of my plugins for Eclipse that support the development of enterprise Flex applications. The objective of this release will be to support Flex 2.0.1 and the Mac and to introduce support for Cairngorm. This will closely be followed by a new Cairngorm plugin that supports the development of Cairngorm based Flex apps. In the background I am also working on an Enterprise Edition of Cairngorm 2, which Steven mentioned in his presentation.
If you have any suggestions for any of the above please let me know.
Posted by at 04:07 PM | Comments (2)