incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: Let's rewind!!! (Re: [VOTE] accept donation of a business process engine into the ServiceMix project)
Date Fri, 17 Feb 2006 16:37:15 GMT
On 17 Feb 2006, at 16:17, wrote:
> Thanks, James.  I appologize if I am being overly dense... :)
> So, to summarize my understanding:
> 1) JBI defines a number of services that are required to support  
> process
> integration/service orchestration/what have you

It defines an API, component model and container of those services,  
yes. The service implementations are separate things to be plugged  
in. The ServiceMix project happens to define a whole bunch of  
concrete JBI components too - together with a reusable container.

> 2) Those same same services will not be incorporated into Apache  
> Ode proper

Yes - they are trivial to reuse without any code changes, once you've  
integrated with the JBI API. Ode may have other services it wishes  
too though.

> 3) In order to make practical use of Apache Ode, one would need to:
>       A) Deploy Apache Ode within ServiceMix
>       B) Deploy Apache Ode within some other JBI compliant container
>       C) Extend Apache Ode with needed services (which would be an
> initiative seperate and distinct from Apache Ode proper)


Incidentally you could split A into 2 parts. You could deploy ODE as  
a JBI deployment unit within ServiceMix, or you can just use the JBI  
API without the whole container & deployment model if you wish. This  
is analogous to making an EAR and deploying it in a J2EE container to  
reuse MDB versus using JBI as a kinda 'JMS' API inside your process.

So there's a full container & deployment model if you want to use it  
- but its completely optional in ServiceMix (you can use the  
container and components as lightweight POJOs without using the  
deployment model if you wish).

Its common in orchestration use cases to want to deploy a set of  
BPELs together as a deployment unit. So the BPEL engine will be  
deployed and running in an ESB (you may for backwards compatibility  
reasons want to deploy 2 different versions of a BPEL engine in an  
ESB at the same time; e.g. use a BPEL 1.1 and BPEL 2.0 engine for  
different sets of business process).

Then you might want to deploy a new deployment unit of some BPEL  
documents -  or at runtime deploy a new set or change the version of  
the ones running. So being able to hot-deploy/undeploy bundles of  
BPEL (or any other integration component configuration) together with  
different versions of BPEL engine is very useful. Though you don't  
have to use this model if you don't want -  you can just have one  
single process wired together in a single classloader that you start/ 


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message