Standalone JBoss Messaging

[arvinder]

Here is a summary of what I have done.

AFAIK, from looking at the codebase

1) Messaging is dependant on jboss-remoting + jmx ( possibly the mbeanserver aswell unless its jdk5, but in anycase this may be needed), additionally "JNDI server, Logging, Remoting and AOP support." see http://jira.jboss.org/jira/browse/JBMESSAGING-26

2) For a standalone messaging release the microcontainer will need to startup pojo wrappers of the required services or directly, see services above & http://www.jboss.com/index.html?module=bb&op=viewtopic&t=76335

3) I have upload a skeleton project that compiles + runs a standalone microcontainer bootstrapper. Its just been started but its in Jira - http://jira.jboss.com/jira/browse/JBESB-13

Thats where i'm at. In addition to the services defined above, there will probably need to be deployers to dynamically startup endpoints - but this is a long way off.

We could use the current jboss-messaging 1.0 GA standalone release as a basis for development and convert over later AFAIK work on the micrcocontainer is still in progress ?

Thoughts ?

[marklittle]

We need a JBossMessaging deployment that runs in as cut-down a fashion as possible. Ideally this should be within the MC. So it seems to me that we have a couple of options:

(i) backoff from using the MC for now (until JBossMessaging integration is done) and look at prototyping against a stripped down version of JBossAS 4.0.3SP1

or

(ii) see if it's possible to help on the JBossMessaging MC integration.

My preference would be (ii), but I'd be interested in hearing other opinions and options.

Mark.

[timfox]

I can see that ii) would be preferable from an ESB POV.

However i) is actually fairly trivial (famous last words) to do, whilst ii) probably requires more thought (and time).

To be honest I have avoided the MC until now so I'm not really sure exactly what and how much is involved, although it's fair to say it's not a 10 minute job ;)

If you really need to get moving quick, then i) is probably the way to go. If you're happy to wait a bit longer then I would suggest ii).

I'm not sure how much grief it would be for you to move from using i) to ii) a bit further down the road.

[marklittle]

Let's wait and see what Ovidiu thinks, but they're not mutually exclusive. Arvinder could look at the cut-down (AS dependent) MS approach while you guys work on (i).

[arvinder]

As you said option (ii) would probably be best due to the coupling between the 2 projects and it may provide clearer usecases/scenarios/ways to use the microcontainer within the esb and its associated services.

[arvinder]

The kernel roadmap http://docs.jboss.org/nightly/microkernel/docs/roadmap/en/pdf/kernel-roadmap.pdf
indicates jmx support in Milestone 3. AFAIK the current release is M2,
http://labs.jboss.com/portal/jbossmc/index.html so option (ii) would depend on M3 for the microcontainer - i think ?

[marklittle]

So I think we need to backtrack and start on option (i) first, while lending input to (ii) as and when it's needed. Sound reasonable?

[arvinder]

Yes i think you are right. Ok, let me put some my thoughts and questions together about the infrastructure setup w.r.t services/components/deployables which may initially end up being a sar deployed alongside standalone messaging .. is this ok ?

[marklittle]

Yes, that sounds good.

[ddossot]

Here too ;-)

From a management/administrative standpoint, it is easier to swallow deploying something on JBossAS than a new stand-alone component.

The reason is that IT operations already have SLAs/procedures/people for JBossAS so deploying a SAR is the best for such an existing infrastructure, as it does not create the need to discover/establish a new environment.

D.

[marklittle]

The JBossESB architecture is meant to be agnostic to the deployment container, and obviously we don't want to prevent people from deploying into existing JBossAS infrastructures. So both approaches will need to be supported. We were thinking of MC to start with simply because a) it's closer to the plug-and-play POJO style and looks a nice, simpler and cleaner approach and b) you've got to start somewhere ;-)

Mark.