Archive for the ‘WebSphere Application Server’ Category

WebSphere MQ 5.3 and WebSphere Application Server 6.1

Monday, September 3rd, 2007

A question from a colleague had me wondering about the following restriction stated in the WebSphere Application Server Version 6.1 pre-reqs:

IBM WebSphere MQ 5.3 CSD 12 and IBM WebSphere MQ 5.3.1 for z/OS + PK10303 are supported for client mode connections only.

Fortunately, Paul Titheridge from the service team was able to provide me with an explanation. The use of the WebSphere MQ 5.3 JMS client is not supported in a Java 5 JVM which is, of course, what Version 6.1 of the application server is running on. For a client connection, you should use the WebSphere MQ Version 6 JAR files which are supported under Java 5, and also provide backwards compatibility when making a client connection to a Version 5.3 queue manager.

That said, with WebSphere MQ Version 5.3 due to go out of service at the end of next month then this is probably a largely academic discussion.

Updated: Paul’s explanation of the reasoning behind this statement is entirely correct but, it transpires, that statement is now out-of-date and only tells part of the story. WebSphere MQ 5.3 is now supported with WebSphere Application Server 6.1 providing you have at least CSD 13 of the former and 6.1.0.5 (6.1.0.6 on z/OS) of the latter. You also need to set the MQ_INSTALL_VERSION WebSphere variable as explained in the InfoCenter and this tech note. Thanks to Alasdair Nottingham for picking me up on this.

WebSphere MQ and the client container

Friday, August 17th, 2007

WebSphere Application Server has shipped with JAR files for the WebSphere MQ JMS provider since Version 5.0 as they were, at the time, required for the embedded messaging provider. However, if those JAR files do not match the version of WebSphere MQ you are using (as is the case with WebSphere Application Server V6.0 and WebSphere MQ V6) you may see error messages such as java.lang.NoSuchFieldError: msgToken. As documented on the support site and in the InfoCenter, on the server-side the correct thing to do is update the MQ_INSTALL_ROOT WebSphere variable to point to your real WebSphere MQ installation. What I haven’t seen documented anywhere is what to do in the case where you are using the WebSphere Application Server client container. In that scenario, you need to modify the JMS_PATH environment variable defined in the launchClient batch file in the application server bin directory.

JMS connection pooling

Thursday, August 16th, 2007

I’ve mentioned one of my colleague Paul Titheridge’s articles before (on JMS Application Server Facilities) and he’s just started a new related series which is well worth taking a look at. This time Paul has turned his attention to the myriad of connection pool properties provided by WebSphere Application Server and what they mean when using WebSphere MQ as the JMS provider. As before, Paul has provided some thoroughly worked examples to help explain the implications of changing different values.

IBM Resource Adapter for JMS with WebSphere Application Server

Thursday, July 5th, 2007

I’ve mentioned the IBM Client for JMS on J2SE with IBM WebSphere Application Server on a couple of occasions. As the name suggests, this provides you with a couple of JAR files that allow a standalone J2SE application to act as a JMS client to the WebSphere Application Server default messaging provider. What it isn’t good for, is acting as a client from another, third-party, application server. Yes it may work but you don’t get all those good things that an application server provides, like XA transaction coordination and parallel message consumption using MDBs. Enter the IBM Resource Adapter for Java Message Service with WebSphere Application Server which allows you to do just these things. Note that it’s currently only tested on Apache Geronimo V1.2 and WebSphere Application Server Community Edition V1.1 but it’s a JCA 1.5 compliant resource adapter so should work with any J2EE 1.4 application server. Also note that, as with the original client, this download is initially only available with an early access license. If you are interested in using it in production though, drop a note to the e-mail address in the technical support section.

Spring certified on WebSphere Application Server

Friday, June 22nd, 2007

As reported over on the WebSphere Community Blog, Interface21 has announced certification of the Spring framework with WebSphere Application Server. The article on developerWorks describing using Spring and Hibernate with WebSphere Application Server has also been just updated to cover Spring Framework 2.1.

WebSphere proxy server

Tuesday, June 19th, 2007

I tend to consider myself more of an application architect than an infrastructure expert when it comes to WebSphere Application Server and this is exemplified by my total lack of knowledge about WebSphere’s proxy server. Although shipped as part of WebSphere Application Server Network Deployment I have to confess to only having a rather fuzzy idea about its capabilities. It was therefore good to read Erik Burckart’s column reviewing the capabilities of the product and discussing where and when it may be used.

My Tasks

Tuesday, June 12th, 2007

The WebSphere Application Server administrative console isn’t always the easiest beast to navigate and I often find myself having to repeat those five clicks to get back to the page I was just on a moment ago and wishing that there was some sort of bookmarking support. I’m therefore surprised I’ve failed to spot the My Tasks support in Version 6.1 before, which goes at least part of the way to solving that problem.

JAX-RPC Web Services

Saturday, June 9th, 2007

There is an interesting developerWorks article covering the JAX-RPC Web Services support in WebSphere Application Server Version 6.1. It demonstrates how this support alone can provide some of the benefits normally associated with an enterprise service bus, namely location transparency (WSDL endpoints can be overridden in the administrative console) and protocol transparency (SOAP/HTTP, SOAP/JMS or RMI/IIOP). As the article goes on to state, the combination of WebSphere ESB and Service Registry and Repository can give you much more dynamic behaviour when trying to achieve the first of these but if all you need is the ability to modify endpoints when, for example, moving from the development environment in to production, then this may suffice.