incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <guillaume.no...@worldonline.fr>
Subject Re: Let's rewind!!! (Re: [VOTE] accept donation of a business process engine into the ServiceMix project)
Date Fri, 17 Feb 2006 07:56:21 GMT
A BPEL engine is integrated within JBI using a JBI component.
In such a case, the BPEL engine should only communicate
with the JBI bus (excluding direct http calls or whatever else).
The JBI container is really a container which communicates
with a component using a set of specified interfaces, but in no way
there is a strong tie from the bpel engine to jbi: it is more like
having the right entry points to be able to perform everything
needed by the jbi spec: retrieving the wsdl, finding inputs and
outputs. 

If I have to make a comparison, it would say it is similar to the
database and its jdbc driver: the database does not need to be
dependant on jdbc, but they offer a driver that wraps jdbc specific
stuff to native calls..  Here the component wraps JBI calls to
BPEL events. The main difference is that usually, the BPEL
engine will be embedded in the JBI component ...

Cheers,
Guillaume Nodet

ian.d.stewart@jpmchase.com 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?
>
>
>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                                                 
                                                 
>                      <james.strachan@g        To:       general@incubator.apache.org
                                                 
>                      mail.com>                cc:       dev@geronimo.apache.org, geir@pobox.com,
dims@apache.org                      
>                                               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/
>
>
>
>
>
>  
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message