incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: BPEL contribution from Sybase
Date Tue, 14 Feb 2006 05:45:38 GMT
I'd like to retract this email.  I have doubts on both sides of this  
and may try to explain them in a clearer way in another message.

My apologies
david jencks

On Feb 13, 2006, at 6:26 PM, David Jencks wrote:

> After being nervous for quite a while I have come to think that the  
> sybase bpel engine should go in as part of servicemix and if  
> further uses outside servicemix develop we can see about splitting  
> it off.
> more comments inline.
> On Feb 13, 2006, at 5:25 PM, Noel J. Bergman wrote:
>> Dain Sundstrom wrote:
>>> I think ServiceMix is the perfect home for a BPEL engine.  Every
>>> JBI implementation that I am aware of has and integrated  
>>> orchestration
>>> engine exposed via the BPEL specification.
>> If every JBI implementation has an integrated orchestration  
>> engine, then we
>> should factor out the orchestration engine.  Furthermore, as per  
>> the JBI
>> Specification, "Java Business Integration JSR (JBI) extends J2EE  
>> and J2SE
>> with business integration SPIs. These SPIs enable the creation of  
>> a Java
>> business integration environment for specifications such as WSCI,  
>> and the W3C Choreography Working Group."  JBI is applicable  
>> outside the
>> context of J2EE.  So if ServiceMix is intended to be embedded  
>> exclusively in
>> Geronimo (the subject of a whole other discussion), JBI should be  
>> available
>> separately.
> To me this appears to assume that the interface between the  
> orchestration engine and the JBI container is well defined and all  
> parties agree on it.  I haven't heard any claims that this is the  
> case, although I'm still completely unfamiliar with the subject.
>> Also, we already have two engines in the Incubator, with two more  
>> pending,
>> so we may have three implementations of BPEL.  I would expect to  
>> see at
>> least one of them close down, and would like to see the orchestration
>> communities merge, if possible.
> This appears to me to be a strong indication that BPEL engines  
> cannot live an independent life and that we should try one as part  
> of another project such as servicemix.  If the BPEL part of the  
> servicemix community turns out to be big vibrant and wanting its  
> own project, all the better.  If not, servicemix gets a component  
> it needs.
>> I've heard nothing to provide a reason for not bringing in the  
>> contribution
>> as a standalone podling, which ServiceMix and others can consume.   
>> This
>> would be in accord with Ken and Mads.
> Through all this I don't think I've seen anyone actually say they  
> want to work on the code other than servicemix people.  (If I've  
> missed anyone I apologize).  It's been on the table a rather long  
> time for that not to mean that there isn't much interest outside  
> servicemix for actually working on it.  The incubation process is  
> not a trivial amount of work and having 2 podlings rather than one  
> pretty nearly doubles a good deal of it IMO.  Since the original  
> request was to be a part of servicemix, and AFAICT no one outside  
> that group has said they want to work on the project over the last  
> x weeks of stewing, what exactly can we gain by forcing a decision  
> on this group of people who want to work together?
>> On a related note, I believe that we need to evaluate projects for
>> graduation based in part on how well the community collaborates  
>> with other
>> ASF projects, and become part of the ASF community.  I don't consider
>> ghettos to be healthy for the ASF, no matter how internally  
>> successful.
> After looking at this for a while I don't have any idea what you  
> mean.  Could you provide some concrete examples of projects that  
> should not have graduated based on this criterion and pre-incubator  
> projects that would not graduate had they gone through incubation?   
> While this appears at first to be a very nice idea I can't see any  
> way it could mean anything but stifling innovation.  I hope you can  
> clarify what you mean.
> thanks
> david jencks
>> 	--- Noel
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message