Re: BPEL contribution from Sybase
On 14 Feb 2006, at 01:25, 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, BPEL4WS and the W3C Choreography Working Group. JBI is applicable outside the context of J2EE. Agreed So if ServiceMix is intended to be embedded exclusively in Geronimo (the subject of a whole other discussion), Its not. You can use ServiceMix inside Geronimo, J2EE or J2SE. JBI should be available separately. It is, inside the ServiceMix project. James --- http://radio.weblogs.com/0112098/
Re: BPEL contribution from Sybase
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. I am not worried about barriers to any committers, accidental too-tight binding or UNrelated mail on mailing lists. All of these issues are worked out every day on mailing lists at Apache. I am much more worried about this donation falling into Apache politics that result in a sausage project that no one wants to eat. Sybase wants to donate to the service-mix community and the ServiceMix community wants to work with the code. Any contributor will be welcomed by the ServiceMix community (as required by the apache way), and *if* a large community develops that wants to split off later they can (as is allowed by the apache process). Right now, I don't see this large community; all I do see is a few very grumpy individuals. If the webservice project really really want to control this code, they can always fork it (as is allowed by the apache process). So: My recommendation is that the donation be accepted directly into ServiceMix and we all move on to more important issues. -dain On Feb 13, 2006, at 12:21 PM, Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After re-reading all the discussion threads and getting some technology education from people kind enough not to bash me on the bonce, my strong recommendation is that the Sybase contribution be made as a new podling proposal to the incubator. That's after also considering the following: 1. The full expanded name of BPEL is 'Business Process Execution Language for Web Services;' 2. We have a TLP devoted to Web Services; and 3. A BPEL engine would be a component useful to a broader range of projects that just Geronimo. It just doesn't make sense to me to embed this into ServiceMix, which is intended to be embedded into the Geronimo project. The issues about who wants to work on it and their current distribution through ASF projects (namely, the claim that most of them are already working on the ServiceMix package) I don't see as being particularly relevant. Having the BPEL effort outside of ServiceMix is a better solution, IMHO, because 1. There's no barrier to ServiceMix people working on it; 2. There's less chance of accidental too-tight binding to the ServiceMix/Geronimo packages; 3. People working on it will see just messages relating to it, and not a bunch of UNrelated mail as well. That last one is pretty important, I think. I suspect that people from outside ServiceMix would be a bit daunted or put off at having to deal with the flux of ServiceMix-specific mail in order to see the BPEL-related messages which might be their sole interest. So: My recommendation is that a new proposal be drafted, and Sybase's BPEL contribution be subnmitted to the incubator as a new standalone podling. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ/DqMZrNPMCpn3XdAQI3EwP6Aj+Rlg5+8c4HwNm9rfN/PlCnN0QwDLu+ vCEYIZy7YsHQ0fr/7TNuN5Xn1M+xFtvhw4v4HMrVHhUYLnToyDtob/uyyIrcLpZR 1yH3krVSarHJobtoAiGh/Z9VBvIU/deGNqR7tpfL/3RvtG26HQlTiR/4tRXNCZbY a1xVRt2c34g= =ge/u -END PGP SIGNATURE-
Re: BPEL contribution from Sybase
I agree with Dain; let's get the code running in ServiceMix, and then we can break it off when it's ready to stand alone. Thanks, Aaron On 2/13/06, Dain Sundstrom [EMAIL PROTECTED] 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. I am not worried about barriers to any committers, accidental too-tight binding or UNrelated mail on mailing lists. All of these issues are worked out every day on mailing lists at Apache. I am much more worried about this donation falling into Apache politics that result in a sausage project that no one wants to eat. Sybase wants to donate to the service-mix community and the ServiceMix community wants to work with the code. Any contributor will be welcomed by the ServiceMix community (as required by the apache way), and *if* a large community develops that wants to split off later they can (as is allowed by the apache process). Right now, I don't see this large community; all I do see is a few very grumpy individuals. If the webservice project really really want to control this code, they can always fork it (as is allowed by the apache process). So: My recommendation is that the donation be accepted directly into ServiceMix and we all move on to more important issues. -dain On Feb 13, 2006, at 12:21 PM, Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After re-reading all the discussion threads and getting some technology education from people kind enough not to bash me on the bonce, my strong recommendation is that the Sybase contribution be made as a new podling proposal to the incubator. That's after also considering the following: 1. The full expanded name of BPEL is 'Business Process Execution Language for Web Services;' 2. We have a TLP devoted to Web Services; and 3. A BPEL engine would be a component useful to a broader range of projects that just Geronimo. It just doesn't make sense to me to embed this into ServiceMix, which is intended to be embedded into the Geronimo project. The issues about who wants to work on it and their current distribution through ASF projects (namely, the claim that most of them are already working on the ServiceMix package) I don't see as being particularly relevant. Having the BPEL effort outside of ServiceMix is a better solution, IMHO, because 1. There's no barrier to ServiceMix people working on it; 2. There's less chance of accidental too-tight binding to the ServiceMix/Geronimo packages; 3. People working on it will see just messages relating to it, and not a bunch of UNrelated mail as well. That last one is pretty important, I think. I suspect that people from outside ServiceMix would be a bit daunted or put off at having to deal with the flux of ServiceMix-specific mail in order to see the BPEL-related messages which might be their sole interest. So: My recommendation is that a new proposal be drafted, and Sybase's BPEL contribution be subnmitted to the incubator as a new standalone podling. - -- #ken P-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ/DqMZrNPMCpn3XdAQI3EwP6Aj+Rlg5+8c4HwNm9rfN/PlCnN0QwDLu+ vCEYIZy7YsHQ0fr/7TNuN5Xn1M+xFtvhw4v4HMrVHhUYLnToyDtob/uyyIrcLpZR 1yH3krVSarHJobtoAiGh/Z9VBvIU/deGNqR7tpfL/3RvtG26HQlTiR/4tRXNCZbY a1xVRt2c34g= =ge/u -END PGP SIGNATURE-
Re: BPEL contribution from Sybase
After a quick chat with Dims, I think I need to make a quick correction to this email On Feb 13, 2006, at 12:42 PM, 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. I am not worried about barriers to any committers, accidental too-tight binding or UNrelated mail on mailing lists. All of these issues are worked out every day on mailing lists at Apache. I am much more worried about this donation falling into Apache politics that result in a sausage project that no one wants to eat. Sybase wants to donate to the service-mix community and the ServiceMix community wants to work with the code. Any contributor will be welcomed by the ServiceMix community (as required by the apache way), and *if* a large community develops that wants to split off later they can (as is allowed by the apache process). Right now, I don't see this large community; all I do see is a few very grumpy individuals. If the webservice project really really want to control this code, they can always fork it (as is allowed by the apache process). I picked up on Ken's comments about having a TLP devoted to Web Services and I should not have picked on the Web Services, instead I think my point is made more clear by replacing the last line with: If any project inside or outside of Apache wants their own copy of this code to develop they can always fork the code (as is allowed by any open source project). I apologies to Dims and the Web Services project for dragging them back into this debate as they have clearly tried to remove themselves. Sorry, -dain So: My recommendation is that the donation be accepted directly into ServiceMix and we all move on to more important issues. -dain On Feb 13, 2006, at 12:21 PM, Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After re-reading all the discussion threads and getting some technology education from people kind enough not to bash me on the bonce, my strong recommendation is that the Sybase contribution be made as a new podling proposal to the incubator. That's after also considering the following: 1. The full expanded name of BPEL is 'Business Process Execution Language for Web Services;' 2. We have a TLP devoted to Web Services; and 3. A BPEL engine would be a component useful to a broader range of projects that just Geronimo. It just doesn't make sense to me to embed this into ServiceMix, which is intended to be embedded into the Geronimo project. The issues about who wants to work on it and their current distribution through ASF projects (namely, the claim that most of them are already working on the ServiceMix package) I don't see as being particularly relevant. Having the BPEL effort outside of ServiceMix is a better solution, IMHO, because 1. There's no barrier to ServiceMix people working on it; 2. There's less chance of accidental too-tight binding to the ServiceMix/Geronimo packages; 3. People working on it will see just messages relating to it, and not a bunch of UNrelated mail as well. That last one is pretty important, I think. I suspect that people from outside ServiceMix would be a bit daunted or put off at having to deal with the flux of ServiceMix-specific mail in order to see the BPEL-related messages which might be their sole interest. So: My recommendation is that a new proposal be drafted, and Sybase's BPEL contribution be subnmitted to the incubator as a new standalone podling. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ/DqMZrNPMCpn3XdAQI3EwP6Aj+Rlg5+8c4HwNm9rfN/PlCnN0QwDLu+ vCEYIZy7YsHQ0fr/7TNuN5Xn1M+xFtvhw4v4HMrVHhUYLnToyDtob/uyyIrcLpZR 1yH3krVSarHJobtoAiGh/Z9VBvIU/deGNqR7tpfL/3RvtG26HQlTiR/4tRXNCZbY a1xVRt2c34g= =ge/u -END PGP SIGNATURE-
Re: BPEL contribution from Sybase
On Mon, Feb 13, 2006 at 12:42:58PM -0800, Dain Sundstrom wrote: ... Sybase wants to donate to the service-mix community and the ServiceMix community wants to work with the code. Any contributor It should be donate to APACHE. The various people can come to it. To be frank, some communities can bias against newcomers. That isn't right for the ASF, and it *absolutely* is not write for podling communities within the Incubator. This doesn't apply to just BPEL. I had the same reaction to the recent Ajax proposals. oh, sure, Dojo can come and join this new community. Right. They'll feel like outsiders right from the start. Euh. We have some code? Yah, I know you have some, but will you look at ours? Bah. This isn't about control, this is about inclusivity. Targeting one group of folks (... to the service-mix community ...) over another is exclusion, not inclusion. Cheers, -g -- Greg Stein, http://www.lyra.org/
RE: BPEL contribution from Sybase
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, BPEL4WS 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. 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. 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. 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. --- Noel
Re: BPEL contribution from Sybase
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, BPEL4WS 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
Re: BPEL contribution from Sybase
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. I am not worried about barriers to any committers, accidental too-tight binding or UNrelated mail on mailing lists. All of these issues are worked out every day on mailing lists at Apache. I am much more worried about this donation falling into Apache politics that result in a sausage project that no one wants to eat. IMHO, it's being *pushed* into 'Apache politics.' If it's worthwhile, it will survive wherever it goes. Coming in as a standalone podling will be a measure of its worth. If it can't get enough momentum that way, why do you think it would get any more as part of ServiceMix? If it wouldn't get the momentum standalone, then I think it's much more likely that being embedded into ServiceMix would result in a bolus of legacy code. An inedible and unremovable sausage in a larger sandwich. Sybase wants to donate to the service-mix community In other words, they *don't* want to contribute it to Apache. They want it to go into a specific and particular niche *at* Apache. Why the specificity? Why does Sybase care where it goes? and the ServiceMix community wants to work with the code. A BPEL podling would not be an obstacle to that. Any contributor will be welcomed by the ServiceMix community But if BPEL is all they wanted to work on, they wouldn't be *part* of the ServiceMix community. Right now, I don't see this large community; all I do see is a few very grumpy individuals. Such as whom? *I* see an enormous pressure to bring this into ServiceMix, and a good bit of grumpiness that anyone would have the temerity to opine that there might be a better approach. Since you were replying to my message, which recommended against bringing BPEL into ServiceMix, I infer that I'm one of these 'very grumpy individuals.' Why am I grumpy? What am I grumpy about? You said it, so please tell me what you meant. If the webservice project really really want to control this code, Who said anything about WS 'controlling' the code? I commented that 'Web Services' is part of BPEL's name, and we already have a bunch of people and an effort dedicated to that specific topic. I don't see 'J2EE' in the BPEL name; I *do* see 'Web Services.' So: My recommendation is that the donation be accepted directly into ServiceMix and we all move on to more important issues. The amount of opinion diversity on this issue makes it clear that it's quite important enough on its own, and in fact is *not* a simple thing to 'just do.' - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ/FDyJrNPMCpn3XdAQLjXQP/URqbW5Qmtirvt9HSdQJWQByRBzh4wV+Q OrV38DhewUtdUmsjQNvYenkPs9odbacP1Op79ZIkh6EiM0hnwIwnfLPfklDUrp+S fmfRuNmHH4N6fSh7PFK28Zh6GlY/MXpgdI2XDh7n9JGcGBNHTI4kq+YmAsJH/tFr ZnURkBQkRIY= =s2ms -END PGP SIGNATURE-
Re: BPEL contribution from Sybase
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, BPEL4WS 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BPEL contribution from Sybase
On 2/13/2006 6:43 PM, Rodent of Unusual Size wrote: Dain Sundstrom wrote: Sybase wants to donate to the service-mix community In other words, they *don't* want to contribute it to Apache. They want it to go into a specific and particular niche *at* Apache. Why the specificity? Why does Sybase care where it goes? I think that Sybase has or had an opinion as to where would be a nice place to start but is not married to it. I'm certain that they will be happy w/ what ever the community decides. Regards, Alan
