Startup of a modularized ESB system

[tomeicher]

Hi all,

we have a nice setup of our ESB system where all use cases are deployed as their own modules, and one common module that contains common stuff. Among that, we have a spring registry where "use cases" are looked up and delegated to the correct submodule, i.e. the correct

pipeline.

So it looks like:

• Common.esb:
  Spring Registry
  HTTP Gateway (SOA Listener)
  JMS Gateway (JMS Listener)
  common actions, connectors, routers, helper classes, ...
• UseCase1.esb:
  actions specific to this use case
  action pipeline for this use case
• UseCase2.esb ...

Now, since all Use Case modules depend on Common (using helper classes from there, implemening common interfaces and superclasses...),

common is independant, whereas all use cases have

<jbossesb-deployment>
    <depends>jboss.esb:deployment=Common.esb</depends>
</jbossesb-deployment>

But, since the gateways are in common, messages received directly upon startup will sometimes not reach their use cases,

as it has not been completely deployed yet...

How would you fix such a setup ?

Some possibilities exist, but none makes completely sense to me...

• make Common depend on all Use Cases
  but I need the classes and helpers in it...
  and then my system will never start up when I try to disable one Use Case ...
• move the gateways to another module "Gateways" and have that depend on all others
  but then my system will never start up when I try to disable one Use Case ...
• try to somehow start the gateways deactivated / delayed
  but the delay would have to be complete arbitrary... (and how to do...)
  or try to lookup the services, with sensible retry and timeout, and only start connectors after a final "give up on undeployed use cases" timeouts...
  
  

Any ideas, thought, insights are welcome.

Cheers, Tom.

[noelo]

I'm not sure of the functionality on the AS 5 base platform but if you create an artifact called deploy.last it will be the last file that the deployer deploys. If you make your common.esb depend on that it may give you the deployment sequencing that you require....

[tfennelly]

Sounds like a chicken and egg type scenario

You can't have common be last to deploy if the use case esbs are depending on it... they need to deploy after common.

[kconner]

The answer really comes down to your application and what is intended if the gateways receive a request that cannot be fulfilled, either because the child use case has not yet, or will not, be deployed.

If the dependent esbs should always present, then the best course of action would be to split the gateway/services from common out into another esb.  You can then have the external esb dependent on the internal functionality.

Of course the HTTP gateway will not be able to consume any requests until the server has been deployed, common with all HTTP requests, so your only concern appears to be the JMS gateway.

What are your restrictions?

Kev

[tomeicher]

Hi,

well, yes, it is a chicken ./. egg problem I'm having here. :-)

Basically, do you have any idea how I could accomplish this "delay startup of gateways" thing?

I see no possibility to say "do not call start() upon deployment".

I could try overriding the Gateway's start(), or place a locking method where the messages are received.

But it's probably hard to oversee all consequences this has within ESB.

Failing that, I guess I have to separate the Connectors into a new .esb, that depends on all others.

But this means I have to change that dependency whenever I choose not to deploy one use case, and that is what I would like to avoid.

Cheers, Tom.

[tomeicher]

Ideas on "delayed startup of gateways", anyone ?