David Currie

On the basis of a thread of notes I was involved in this week, I was considering a post on the WebSphere Application Server support for JMS providers that don’t implement the Application Server Facilities (ASF) part of the JMS specification. As the name suggests, these facilities cover aspects of integration between a JMS provider and a J2EE application server such as transactionality and message-driven bean support. Paul Titheridge (who works in the service team covering the WebSphere MQ and WebSphere Application Server JMS providers) has done the hard work for me and written a developerWorks article on the subject.

(more…)

In a previous posting I covered the Feature Pack for Web services. This week’s developerWorks Making SOA real with WebSphere podcast includes an interesting interview with Nathan Goike on this subject. Points of particular interest to me was the inclusion of Apache Axis2 and the use of policy sets to ease Web service configuration.

Keys Botzum has provided updates to his security hardening and programming presentations, written in combination with my UK colleagues Cameron Martin and Peter Kovari, to cover Version 6.0 and 6.1 of WebSphere Application Server.

Ben Bakowski, Chris Whyley and Matt Roberts have written a nice developerWorks article introducing WS-Notification in WebSphere Application Server Version 6.1. For once I’ve actually sat down myself and worked my way through it so I know it’s good! It illustrates the use of a publisher, asynchronous consumer and pull point for lightweight consumers, along with mixing WS-Notification and JMS. One thing to watch out for though: the authors have chosen to use scripting for the setup and pre-written applications which, although providing useful examples, means it’s easy to get to the end of the article without knowing what you’ve done if you don’t take the time to look at the content of the scripts and code.

I’ve had a couple of queries in the past week about whether or not service integration bus messaging engines using a database for the message store need an XA capable JDBC data source. Thanks to Gareth Bottomley in the development team for locating the appropriate section hidden away in the InfoCenter that indicates you should configure a Connection pool data source i.e. non-XA capable. The messaging engine does not use the XA capabilities of the database, instead acting as a resource manager in its own right. So, for example, when you receive a message under a global transaction it is not deleted from the data base at that point under a JDBC transaction. Instead, it is non-transactionally marked with the Xid of the global transaction so that it is not received by other consumers and then, only when the transaction is commited, is the record removed. This is particularly important to note when using Oracle as the database as the Oracle XA driver has notoriously poor performance.