David Currie

I’ve just been asked to review a new book entitled “Application Development for IBM WebSphere Process Server 7 and Enterprise Service Bus 7“. I can certainly vouch for the credentials of one of the two IBM authors having worked with Salil Ahuja. As part of the AIM Early Programs team he’s in a perfect position to have both a breadth of knowledge across the products and a good understanding of what customers need and want to know. The sample chapter online (which happens to cover mediation module development) looks promising so I look forward to receiving my review copy.

Building WebSphere ESB and Process Server on WebSphere Application Server means that they benefit from the scalability, reliability, transactionality and security of the underlying platform. Another advantage is that you, as a developer, have access to all of the underlying capabilities of the application server. In a recent article, Alan Hopkins (Dr Alan to you apparently!) demonstrated the use of the object cache to provide a shared variable between two modules. On a similar vein, another UK ISSW consultant Gabriel Telerman has just published a detailed tutorial describing how to use DynaCache from an SCA Java component to improve performance in a WebSphere ESB or Process Server environment. Now Gaby, can I have that pint now for the plug?

Thanks to my colleague Dave Screen for highlighting a useful technote relating to sharing library modules in WebSphere ESB and Process Server. The WebSphere Integration Developer concept of a library is typically only used for development time sharing of artifacts i.e. when you deploy a module that depends on that library, a copy of the JAR file is included in the enterprise application that is deployed. The technote describes how to deploy the library as a WebSphere shared library and have multiple modules depend on the same instance at runtime. This has the potential to reduce memory usage (the library is on a shared classloader) and ease managability. It does, however, mean that you need to be more careful about versioning of the library and breaking other dependent modules. If you’re not on 6.2 then note the list of APARs at the bottom of the document.

Today I was trying to work out why a WebSphere ESB customer wasn’t seeing the default deployment environment created when using manageprofiles to create a Network Deployment topology. They had specified the appropriate topologyPattern and topologyRole parameters. It turned out that they were missing the ndtopology option which should be set to true. This was perhaps excusable as the help for the template doesn’t list this option and even the InfoCenter documentation manages to get the case incorrect. As on previous occasions, I spotted this omission by running through the graphical Profile Management Tool and comparing the parameters that it generates in the invokeWSProfile entry near the top of the logs/manageprofiles/<profile_name>_create.log file.