camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: Process Activation Framework
Date Sun, 20 Sep 2009 07:40:58 GMT

Sorry for any late replies. As always I am busy.

On Tue, Sep 15, 2009 at 9:44 PM, olegp <> wrote:
> Hello,
> Please help me with your advice regarding Camel's possibilities for
> implementing the following scenario:
>  1) There is a subsystem based on jBPM and JBoss AS, which is hosting
> various business processes
>  2) Facade of Stateless EJB is being currently used for implementing Service
> Activator pattern - instantiating the necessary business process upon
> request
>  3) Things are getting really complicated and effort-consuming - manual
> coding of the mediation and activation logic resulted in a huge and fragile
> pile of the hardcoded sequences

Yeah I know it usually starts out easy and then over time grow and
suddenly its complex and fragile to maintain.

>  4) I'm currently evaluating Apache Camel for the needs of implementing a
> certain Process Activation Framework - infrastructure for a clean and
> generic approach to instantiating the business processes based on the
> following input criteria:
>   -- Invoked service
>   -- Invoked method of this service
>   -- Passed arguments (payload values)
>   -- Returned result of the invoked method
>  All these 4 items can influence the choice of business processes to
> instantiate, so basically our pipeline of "routers" and "activators" will
> have 4 input parameters for making the corresponding decisions.

You can take a look at some of the EIP patterns which can be of some help   (the dynamic recipient list)

>  5) Another important comment - API should provide both synchronous and
> asynchronous invocation options.

James Strachan had a couple of fun days in which he created annotations for that
if you a into spring remoting.

And there is also a bit of async info here

>  For now I've come up with the following architecture:
>  1. Activation will be arranged as a pipeline of processors
>  2. Main target of the activation pipeline - to create a special signature
> of the business process, which will be later used for instantiation needs.
> Signatures are mapped to the business process names.
>  3. Every processor in the pipeline will handle one specific input parameter
> (4 parameters as a total)
>  4. Result of the processor invocation - signature part (4 parts as a
> total), which will be also used by the pipeline-level router for invoking
> the next processor. Every processor will be mapped as the handler for a
> certain set of signature parts.
>  5. In the end of pipeline we will have a full signature of the business
> process - 4 signature parts obtained after the invocation of 4 processors.

Yeah sounds good with divide and conquer approach.

> I guess Camel has all the necessary infrastructure in place for such kind of
> mediation, routing and activation needs. Right? For now I'm looking closer
> to Pipes&Filters pattern implemented in Camel... seems to be the appropriate
> pattern. At the same time - I'm bothered with the big amount of resulting
> "routing paths" caused by 4 input parameters mentioned above (especially
> parameter #3)... It may become another hell in the nearest future, when the
> amount of routing options will keep growing.

If the routes are similar then you can have skeleton routes and have
the diversity in different services being invoked.

Or you could add new routes on the fly, if you really need this.

> Maybe Camel has a very simple solution for this case? And all my above
> descriptions are worth nothing comparing to this possible lightweight and
> straightforward solution from Camel?

Well many days have passed since you first post. Maybe you got far and
have a prototype/concept working.

> Many thanks in advance.
> Regards,
> Oleg
> --
> View this message in context:
> Sent from the Camel - Users mailing list archive at

Claus Ibsen
Apache Camel Committer

Open Source Integration:

View raw message