[slaboure]

Guys, I think we need to clarify a few things.

First, the relationship between the MC (or MK, that's the same here) and the AS. The AS is JUST a SPECIFIC set of services running on top of the AS. Consequently, if you:
- take JBoss AS
- drop ALL services from /deploy and unneeded files from /lib and /conf
- add your ESB JAR and services definition

This IS your ESB and has NOTHING to do with the AS. Again, this is just about what services YOU decide to deploy, or not, this is MARKETING: at heart, EVERYTHING is just a MC on steroids.

Now, on the MC vs. MK. MC will obviously offer MUCH MORE than what the MC offers, but I DOUBT that the MK currently lacks ANYTHING you need for the ESB: For example, starting a few mbeans and putting your esb configuration at the MBean levels rather than inside a conf file, is really trivial. Also, your MK MBean definitions ARE totally backward compatible with the MC => you will be able to deploy your MK files/services/MBeans definition AS-IS, without the need to first POJO-ize them. That offers a VERY smooth migration path for the ESB and should be leveraged IMHO.

Last point: OSGi vs. MC. We should definitively leverage the MC. Our MC offers more than what an OSGi implementation would: OSGi is just a "personnality" of the MC, nothing more. Also, the JBoss strategy is really to use the MC as a way to embed our JEMS components (*including* things such as the PORTAL) in other AS or other environments. Then, it is UP TO the MC to do that "mapping job": it shouldn't be the job of the ESB team to map the ESB to the MC, then to a phone, then to Weblogic, then to OSGi, then to Webshpere, etc. your responsibility is to map the ESB to the MC and that's all, then it will be the MC's responsibility to map the MC services to all of these environments. That way, if we want to have, let's say, the portal run in Weblogic, we trivially get it as well: once the MC is migrated to WL, anything that runs on the MC would now run on WL. You should really discuss with Scott and/or Adrian I think, that might clarify a few things. Also, Adrian has been working on a "Servivces API and SPI" so that if you need specific services, you can bind in this MC API instead, so that the MC can then properly do its mapping job to services offered by the hosting environment.

Also, the MC is the way to get support from JBoss ON (through the Profiles service).

Cheers,


sacha

[marklittle]

Sacha, we'll definitely support MC in the next release. That's on our roadmap. OSGi is something we're seeing requests for, but it's a longer term issue. Since the ESB architecture is not to mandate any implementation of anything (e.g., service or container) in order to ensure we offer customers a much better capability to leverage their existing infrastructural investments, how we approach that from an implementation perspective is important. It sounds like MC could be the basis for this multi-container support. But for the 4.0 release, where we won't have MC (or OSGi) support, we still need configurations that are simple enough for people to understand and use. Those configurations will change for the better in the next GA release.