Having written a very similar exercise for the Connecting Enterprise Application to WebSphere Enterprise Service Bus ITSO Workshop, it was interesting to read Rich Johnson’s article on creating custom data bindings for the WebSphere Flat File adapter. In particular, the step required to actually add the custom data binding so that it shows up in the Enterprise Service Discovery wizard is not exactly obvious.
Archive for the ‘Technology’ Category
Flat file custom data bindings
Monday, October 22nd, 2007Best Practices for Large WebSphere Topologies
Monday, October 22nd, 2007If you’re looking to scale out your WebSphere solution then this paper on developerWorks is one you must read. It provides guidelines on cell sizes and discusses when you should consider multiple core groups and how to bridge them, as well as other important considerations. Go read it!
Job ad
Tuesday, October 16th, 2007Couldn’t help laughing at this job ad for a “WebSphere ESB Developer”. On closer inspection said developer needs “proven experience of WebSphere Message Broker V6” i.e. the “Advanced Enterprise Service Bus”!
JMS problem determination
Friday, October 12th, 2007The JMS Problem Determination Redpaper covering WebSphere Application Server Version 6.1 was published at the start of the month. As the long list of authors indicates, Rich Coppen has done a fantastic job in getting input from the whole of the development team so this is a pretty comprehensive resource.
Ruby and Zero
Sunday, October 7th, 2007Out of the box, Project Zero supports PHP and Groovy as scripting languages but, as this developerWorks article demonstrates, extending Zero to support other languages is pretty trivial. In this instance, they show how adding support for Ruby (specifically JRuby) can be achieved with one simple class. Now Rails developers have no excuse not to take a look at Zero!
Messaging identities
Friday, October 5th, 2007Given Alasdair has been kind enough to include me in the acknowledgements, that guarantees him a plug for his developerWork’s comment line entitled “Connect an application to the default messaging provider using the run-as identity“. This describes how to connect to the default messaging provider in WebSphere Application Server using the application’s current runtime run-as identity rather than, as is usually the case, the credentials administratively associated with the connection factory or resource reference. As always, just because something is possible, doesn’t mean you should do it, so please head Alasdair’s comments about what to consider before implementation.
WebSphere MQ 5.3 and WebSphere Application Server 6.1
Monday, September 3rd, 2007A 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, 2007WebSphere 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.
RSS - Posts