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
2) Those same same services will not be incorporated into Apache Ode proper
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)
Ian
It's better to be hated for who you are
than loved for who you are not
Ian D. Stewart
Appl Dev Analyst-Advisory, DCS Automation
JPMorganChase Global Technology Infrastructure
Phone: (614) 244-2564
Pager: (888) 260-0078
James Strachan
<[EMAIL PROTECTED] To:
dev@geronimo.apache.org
mail.com> cc:
general@incubator.apache.org
Subject: Re: Let's rewind!!!
(Re: [VOTE] accept donation of a business process engine
02/17/2006 02:57 into the ServiceMix project)
AM
Please respond to
dev
On 16 Feb 2006, at 23:44, [EMAIL PROTECTED] wrote:
> James,
>
> I'm afraid I'm not as familiar with JBI as I probably should be
> (which is
> to say not at all). Would leveraging JBI to do Ode's heavy lifting
> introduce a dependency on ServiceMix and/or JBI into Ode, or is it
> merely a
> Java-based interface to BPEL, along the lines of JDBC or JNDI?
You'd be adding a *optional* dependency to the JBI standard (JSR 208)
(there's no reason why you couldn't support other techniques)...
http://www.jcp.org/en/jsr/detail?id=208
think of it as a bit like the JMS API for working with BPEL engines,
integration services or any WSDL defined MEP. The use of JBI is
twofold: you can use JBI (as an optional module) inside Ode to
perform all the message exchanges - avoiding the need of Ode to worry
about different SOAP stacks, transports, transactions, QoS together
with building your own mini-application server into the BPEL engine
etc. Or you can use JBI to invoke and interact with a BPEL engine if
you are some application or integration component that wishes to
reuse BPEL.
Its a little like integrating JMS or JDBC; once you've a JBI
integration point, there is a large range of providers you can then
use; in terms of JBI container (ServiceMix, Petals, OpenESB,
commercial vendors like Sonic etc) as well as integration services
like BPEL engines (Ode, maybe jBPM or Oracles' etc) and integration
components. (e.g. these are the JBI components available in
ServiceMix right now...
http://incubator.apache.org/servicemix/Components
http://incubator.apache.org/servicemix/Routing
So Ode could have other integration points too though - its just that
JBI should be the first and foremost connector, since its standards
based and already provides integration to the widest range of
different services and binding components.
James
>
>
> Thanks,
> Ian
>
> It's better to be hated for who you are
> than loved for who you are not
>
> Ian D. Stewart
> Appl Dev Analyst-Advisory, DCS Automation
> JPMorganChase Global Technology Infrastructure
> Phone: (614) 244-2564
> Pager: (888) 260-0078
>
>
>
> James Strachan
> <[EMAIL PROTECTED] To:
> general@incubator.apache.org
> mail.com> cc:
> dev@geronimo.apache.org, [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: Re: Let's
> rewind!!! (Re: [VOTE] accept donation of a business process engine
> 02/15/2006 03:27 into the ServiceMix
> project)
> AM
> Please respond to
> dev
>
>
>
>
>
> On 14 Feb 2006, at 21:38, Matthieu Riou wrote:
>>> Also, I don't at all agree with your comparison of a BPEL Engine to
>>> Geronimo. I would compare it to the transaction manager within
>>> Geronimo. It's a discrete component, and we're not going to take
>>> the
>>> best of 20 different projects to make a transaction manager, and I
>>> don't see why we'd do the same to make a BPEL Engine.
>>
>> I've been trying to stay out of the discussion so far because I'm
>> obviously partial (as a contributor on Agila BPEL), however I've seen
>> this opinion voiced many time on these threads and can't ignore it
>> anymore. Aaron it's not against you at all :)
>>
>> I've worked enough on BPEL implementing it to say, really strongly,
>> that BPEL is very far from being a discrete component. You can see it
>> as something "behind the scene" when you're working on a JBI
>> container, however when you're interested in having an orchestration
>> layer, you really don't. I don't think Oracle, IBM and many other
>> editors would be so successful in selling their product if it was so
>> discrete.
>>
>> You really don't need a JBI container if you're only dealing with web
>> services interfaces.
>
> Sure but it really helps. The JBI container does much of the heavy
> lifting, letting the BPEL engine focus on its core feature -
> correlation & orchestration and not worrying about all the other
> stuff as well.
>
>
>> Actually my view on this was that an ESB is just
>> a communication bus around an orchestration layer. Quite the reverse
>> opinion, isn't it? And I can't see any JBI implementation dealing
>> with
>> the BPEL grammar. Is the JBI implementation going to deal with
>> compensation, correlation and partner links? I don't think so.
>
> Agreed. But similarly - should a BPEL engine deal with different
> integration components, different SOAP stacks, different WS-*
> policies, monitoring, management, using HTTP or JMS or Jabber or file
> systems, deployment, versioning, runtime management & monitoring of
> each flow? The J2EE analogy is quite good; BPEL is a discrete service
> but can reuse the container environment of JBI to avoid the BPEL
> engine having to write a container, a deployment model and a suite of
> 'binding components' to different SOAP stacks, WS-* policies and
> transports - together with all the runtime management.
>
> BPEL engines and orchestration services were one of the primary
> drivers of JSR 208 (JBI)
>
>
>> What
>> about editing BPEL process descriptions? And eventually, is the JBI
>> implementation going to provide BAM interfaces?
>
> Yes - BAM hooks at least.
> http://incubator.apache.org/servicemix/Publish+Subscribe+Routing
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
>
>
James
-------
http://radio.weblogs.com/0112098/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
