geronimo-dev 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 02:26:22 GMT
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.

david jencks

> 	--- Noel

View raw message