On Monday this week I got a call from goods inwards at work to tell me I had a package for me from Poughkeepsie. This was a surprise, I wasn't expecting anything, and although I do know people who work in Poughkeepsie if they were going to send me something they would have mentioned it. So down I trotted to pick up my package, and as it turned out seven other packages for people I work with.
The package contains a copy of the new WebSphere Application Server V7 Messaging Administration Guide. Well I say new, it was published in July, but I didn't realize. The book was reviewed by several people who work on developing WebSphere Messaging, hence me walking back with seven copies of the book.
The best thing about the Redbook is that although you can purchase it, you can also download it for free as a PDF, or view it online.
Another good resource for WebSphere Messaging users everywhere.
Alasdair
Saturday 29 August 2009
Tuesday 2 June 2009
Listener Ports and EJB 3
About a year ago we released the EJB 3 Feature Pack for WebSphere Application Server v6.1. This introduced the EJB3 programming model for the first time, and many people rushed up and downloaded it for their application development. Some of the more eagle eyed people noticed a restriction. Message Driven Beans had to use activation specifications, no listener ports here. While this seems to be a simple restriction, when you realize that the only supported way of getting WebSphere MQ working with an MDB in v6.1 is with a listener port you realize the problem. The non-alignment of the release dates for the feature pack and the availability of activation specs in the Application Server led to an unforeseen gap. Oops you might say.
Without going into all the gory details we have been busy working on a solution and until now we have been able to say very little about what has been going on behind the scenes. Now things are different though we have published APAR PK86005 EJB 3.0 MESSAGE-DRIVEN BEANS CANNOT BE USED WITH LISTENER PORTS. This APAR is targeted for inclusion in 6.1.0.25 (and 7.0.0.5) at which point you can bind an EJB3 MDB against a listener port, just like you could an EJB 2.1, or 2.0 MDB.
Without going into all the gory details we have been busy working on a solution and until now we have been able to say very little about what has been going on behind the scenes. Now things are different though we have published APAR PK86005 EJB 3.0 MESSAGE-DRIVEN BEANS CANNOT BE USED WITH LISTENER PORTS. This APAR is targeted for inclusion in 6.1.0.25 (and 7.0.0.5) at which point you can bind an EJB3 MDB against a listener port, just like you could an EJB 2.1, or 2.0 MDB.
No code changes are needed to make this work, all you need to do is set the message listener bindings to name a listener port.
Alasdair
Wednesday 27 May 2009
Listener Ports and WebSphere Application Server v7
When we released WebSphere Application Server v7 one of the things people were most shocked about was the following statement in the list of deprecated features:
Support for configuring and using message-driven beans (MDBs) through JMS listener ports is deprecated.
I would like to attempt to put peoples minds at rest here by explaining the motivation behind the deprecation.
When J2EE 1.3 was released it added in message driven beans support, but without specifying how this should work. So we invented listener ports (WAS v5). Then J2EE 1.4 came a long and told us how it should work. It introduced this new mechanism called "activation specifications" which are part of a resource adapter. So we went ahead and implemented activation specifications (WAS v6), but we still maintained listener ports as this was still how we integrated WebSphere MQ as a JMS provider into message driven beans.
More recently we released a resource adapter for WebSphere MQ and in WAS v7 we integrated this into WAS as the way to integrate WebSphere MQ with MDBs. As a result we now have two ways to do the exact same thing. Having two ways of doing things often causes confusion because people want to know which they should use. In general we want our answer to be to use activation specifications. There are lots of good things about activation specifications, like being able to define them once for a cluster, rather than once per cluster member, so in an effort to avoid confusion we deprecated listener ports.
While this is good for new application developers, as they have a clear direction on which to use. It is not so good for existing users of listener ports who might worry that the rug is being pulled out from under them. So for those people who are using listener ports, don't worry we have no plans to remove them from the product. They are there for the foreseeable future.
For those who are happy to migrate we have endeavoured to make this as simple as possible, and applications do not need to be re-written to take advantage of activation specifications, they do not even need to be redeployed, a simple change to the message listener bindings followed by a restart of the application is all that is needed. We even have a nice whizzy button to convert a listener port to an activation specification.
So in summary, if you are writing new applications then we recommend that you use activation specifications, for existing applications then don't worry - listener ports are still there, and we won't be getting rid of them for some time to come. I wouldn't want anyone to worry that a crack team of IBM engineers will blast a hole in their data centres to surgically remove the listener ports from their product.
Support for configuring and using message-driven beans (MDBs) through JMS listener ports is deprecated.
I would like to attempt to put peoples minds at rest here by explaining the motivation behind the deprecation.
When J2EE 1.3 was released it added in message driven beans support, but without specifying how this should work. So we invented listener ports (WAS v5). Then J2EE 1.4 came a long and told us how it should work. It introduced this new mechanism called "activation specifications" which are part of a resource adapter. So we went ahead and implemented activation specifications (WAS v6), but we still maintained listener ports as this was still how we integrated WebSphere MQ as a JMS provider into message driven beans.
More recently we released a resource adapter for WebSphere MQ and in WAS v7 we integrated this into WAS as the way to integrate WebSphere MQ with MDBs. As a result we now have two ways to do the exact same thing. Having two ways of doing things often causes confusion because people want to know which they should use. In general we want our answer to be to use activation specifications. There are lots of good things about activation specifications, like being able to define them once for a cluster, rather than once per cluster member, so in an effort to avoid confusion we deprecated listener ports.
While this is good for new application developers, as they have a clear direction on which to use. It is not so good for existing users of listener ports who might worry that the rug is being pulled out from under them. So for those people who are using listener ports, don't worry we have no plans to remove them from the product. They are there for the foreseeable future.
For those who are happy to migrate we have endeavoured to make this as simple as possible, and applications do not need to be re-written to take advantage of activation specifications, they do not even need to be redeployed, a simple change to the message listener bindings followed by a restart of the application is all that is needed. We even have a nice whizzy button to convert a listener port to an activation specification.
So in summary, if you are writing new applications then we recommend that you use activation specifications, for existing applications then don't worry - listener ports are still there, and we won't be getting rid of them for some time to come. I wouldn't want anyone to worry that a crack team of IBM engineers will blast a hole in their data centres to surgically remove the listener ports from their product.
Alasdair
Wednesday 18 February 2009
Updated: How MDBs work in a cluster
It has been a long time since I blogged, and then an email question dropped in my inbox, so I thought I would respond with a blog post. The question was:
I have an application that uses MDB's. I have set up 2 messaging engines in a cluster and both are running concurrently (active/active) on 2 different app servers within a WAS cluster. My application is deployed in the same WAS cluster as the SIBus. My activation specs reference the SI Bus. But I find that only MDB's in 1 app server are active.
Is it possible to make use of both app servers so that MDB's on both app servers can process messages from the queue? My understanding was that destination gets partitioned across the messaging engines. I am confused about why only one of the messaging engine is being used.
When you deploy an application containing a Message Driven Bean (MDB) to a cluster and it is hooked up to a bus, you need to be aware of how the bus topology affects delivery to the Message Driven Beans. If the cluster the application is deployed to is also a member of the bus then the MDB will only receive messages if the cluster server member also has a messaging engine running on it. This means that if you have a cluster of five servers, and only three messaging engines, only MDBs on three of the servers will get driven.
In some scenarios this is undesirable because you are not sharing the work out across all the application servers, reducing the scalability of message receipt. In v6.x the only solution to this problem is to have two distinct clusters. One for the messaging traffic, and one for the applications. This also gives the benefit that the messaging traffic cannot starve the application of resources, and vice versa. The downside is that you need a TCP/IP connection to get messages, rather than using Java method calls.
The good news is that in v7 we added a new option on an activation spec called Always activate MDBs in all servers which when specified will cause all MDBs in the cluster to receive messages. The v7 infocenter has a really good article on how all this works, which is well worth reading, it is also relevant to the old v6.1 behaviour, just ignore the section showing cross connections. To save you searching just click here.
Updated (Thursday 19th February 2009): It has been pointed out that I have failed to mention one caution with the remote cluster solution. You need to carefully configure your activation specifications to ensure that all the MDB's do not connect to the same messaging engine in the remote cluster. If all the MDB's connect to a single engine then messages that have been sent to the partitions on the other messaging engines will be marooned and not received. An easy solution to this problem is to have a single messaging engine in the remote cluster which will give you H.A., but not scalability.
Alasdair
I have an application that uses MDB's. I have set up 2 messaging engines in a cluster and both are running concurrently (active/active) on 2 different app servers within a WAS cluster. My application is deployed in the same WAS cluster as the SIBus. My activation specs reference the SI Bus. But I find that only MDB's in 1 app server are active.
Is it possible to make use of both app servers so that MDB's on both app servers can process messages from the queue? My understanding was that destination gets partitioned across the messaging engines. I am confused about why only one of the messaging engine is being used.
When you deploy an application containing a Message Driven Bean (MDB) to a cluster and it is hooked up to a bus, you need to be aware of how the bus topology affects delivery to the Message Driven Beans. If the cluster the application is deployed to is also a member of the bus then the MDB will only receive messages if the cluster server member also has a messaging engine running on it. This means that if you have a cluster of five servers, and only three messaging engines, only MDBs on three of the servers will get driven.
In some scenarios this is undesirable because you are not sharing the work out across all the application servers, reducing the scalability of message receipt. In v6.x the only solution to this problem is to have two distinct clusters. One for the messaging traffic, and one for the applications. This also gives the benefit that the messaging traffic cannot starve the application of resources, and vice versa. The downside is that you need a TCP/IP connection to get messages, rather than using Java method calls.
The good news is that in v7 we added a new option on an activation spec called Always activate MDBs in all servers which when specified will cause all MDBs in the cluster to receive messages. The v7 infocenter has a really good article on how all this works, which is well worth reading, it is also relevant to the old v6.1 behaviour, just ignore the section showing cross connections. To save you searching just click here.
Updated (Thursday 19th February 2009): It has been pointed out that I have failed to mention one caution with the remote cluster solution. You need to carefully configure your activation specifications to ensure that all the MDB's do not connect to the same messaging engine in the remote cluster. If all the MDB's connect to a single engine then messages that have been sent to the partitions on the other messaging engines will be marooned and not received. An easy solution to this problem is to have a single messaging engine in the remote cluster which will give you H.A., but not scalability.
Alasdair
Subscribe to:
Posts (Atom)
