Embedded Messaging has been renamed in WAS 6 to V5 Default Messaging. The V5 Default Messaging provider is for backwards compatibility only. (Interestingly, I haven't found any official support statement that V5 Default Messaging will not be in future versions of WAS, but three different Redbooks say it's only for backwards compatibility. So think of it as a deprecated feature; it works for now, but won't in the future.) The main use for V5 Default Messaging is to support a WAS 6 cell which contains both WAS 5 and WAS 6 nodes, and uses the built in messaging provider. But once all of your nodes are upgraded to WAS 6, you shouldn't need the V5 Default Messaging provider anymore.
So the simple answer is: When you migrate your app from WAS 5 to WAS 6, if it's using WAS 5 Embedded Messaging, migrate it to use the WAS 6 Default Messaging provider, which is built on the Service Integration Bus. There's even a topic on this migration in the WAS 6 InfoCenter: Migrating from version 5 embedded messaging.
Why use the (V6) Default Messaging provider? It serves the same purpose in WAS 6 that Embedded Messaging serves in WAS 5. It's a full JMS implementation built into WAS, so you don't have to buy and install a separate product like WebSphere MQ. The downside is that Default Messaging only works with J2EE apps running in WAS 6 servers and client apps connected to WAS 6 servers via WebSphere MQ client link, whereas WMQ works with lots of different languages and platforms. Whereas Embedded Messaging gives lower quality of service than full WMQ, Default Messaging's capabilities are equivalent to WMQ's, and in some ways are even better.
When developers migrate to V6 default messaging, the main change that they see is that the Listener Ports that MDBs use, defined in the deployment descriptor, don't work anymore. Instead, you now have to use Activation Specs to configure the MDBs. This is simply a consequence of the trend in J2EE 1.4 to implement JMS 1.1 using J2EE Connector Architecture 1.5, which uses activation specs. Default messaging is implemented this way. In the big scheme of things, though, how MDBs connect to the messaging system is a small consideration; the big decision is what messaging system to use in the first place.
So if your WAS 5 app is using Embedded Messaging, as part of migrating it to WAS 6, migrate it to V6 default messaging and the SIB as well.
Here are some additional references:
- Service Integration Bus
- Listener Port vs. Activation Spec, Part 1 and Part 2
- WebSphere Application Server V6 System Management and Configuration Handbook
- WebSphere Application Server V6 Technical Overview
- Introduction: Messaging resources and Learn about messaging resources
- Deploying message-driven beans and JMS applications into the Service Integration Bus
- Building an Enterprise Service Bus with WebSphere Application Server V6 -- Part 1
- Make WebSphere MQ the JMS provider for applications deployed in WebSphere Application Server
- JMS Topologies and Configurations with WebSphere Application Server and WebSphere Studio Version 5