You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Rodent of Unusual Size <Ke...@Golux.Com> on 2006/02/13 21:21:05 UTC
BPEL contribution from Sybase
-----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
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Feb 13, 2006 at 05:56:49PM -0800, Dain Sundstrom wrote:
> On Feb 13, 2006, at 5:34 PM, Greg Stein wrote:
>
> >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.
>
> I don't think anyone has said that this isn't a donation to apache.
> Every donation I have seen to apache, has either come to a PMC and is
> sponsored as a IP donation or incubated sub project, or comes
> directly to the incubator without a sponsoring PMC and must find one
> (which can be the incubator PMC). This is exactly what is happening
> here with the Geronimo PMC.
Of course they're all donations to Apache. But this is a donation that
is being overly-targeted, and (IMO) as a way to hit a specific subset
of people (servicemix) on the belief that it will be easier to control
access to the codebase. There is a lot of apparent resistance to the
concept of putting this code anywhere but for servicemix. "Why?", I
ask myself.
Yes, these things are donations. And the various PMCs (or the
Incubator itself, or rarely the Boar) pass this stuff to the Incubator
to manage. The Incubator has two jobs: IP clearance, and community.
The Incubator is required to manage these for the requesting PMC (and
that PMC must provide people/time/effort to assist). But the process
runs according to the Incubator's rules. It determines what will best
effect the two-job outcome. IP clearance is easy, and that is
happening now. Community is hard, and that's what we're talking about.
And what I'm seeing is that people are saying, "create a separate BPEL
community so that we get the best community."
> >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.
>
> Woha... There is no one saying the service mix community is biased
> against new comers.
And I never said it was. I said "some communities". Do I think that
ServiceMix might have bias? I've got no data to support that, so I
didn't say it :-) Do I suspect it, based on this whole string of
emails over the past couple weeks? Yes.
> I think it is the exact opposite. They are very
> welcoming and I think this is what excited them to donate the code.
Welcoming to Sybase, or to their ASF peers? Better be both.
> >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.
>
> I think that is a different case. In that case we are talking about
> two competing communities. In this case, we have a donator and a
> community that *want* to work together.
That is not the case. We have at least two BPEL implementations, with
another two potentially on the way (per Noel's email). So we have four
codebases and some number of communities.
"some number of communities" is the problem. This is the Incubator.
There is no reason to have *divided* communities. More than one means
divided, in every sense of the word. As I've said before: we need
inclusivity, not exclusivity. And that means avoiding division. That
means bringing everybody together. And it is *especially* true within
the Incubator.
> >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.
>
> I disagree. That is like saying any contributor is exclusive because
> they committ code to only one or two projects.
No. That is saying a developer has interest in just a couple projects.
And it may be that the developer likes the people on those projects.
But it is very different from targeting a community based on how they
are/will interact with others.
Targeting the servicemix community is a mechanism to work with just a
few people, unless it can be shown that the servicemix group is open
to outside contribution. And you know what? The first outside
contributor said, "hunh. that doesn't make sense there. let's move it
_over_there_", and that got rejected. Doesn't seem very welcoming :-P
> Sybase has some code
> that want to integrate into the service mix code base because they
> like the project and the community and want to work collaborate with
> them. They could have quietly showed up an built a new orchestration
> engine in service mix, but instead they are offering some existing
> code to start with. What's the big deal?
And the concept of "do it quietly" also means "do it sneaky to avoid
oversight" which is maddening to me, just at the suggestion of it. Not
very confidence-building, I might add.
The big deal here is that a number of people want to work on BPEL and
(apparently) have zero confidence in being able to do that within
servicemix. Second, that we have several BPEL implementations to sort
through, and servicemix doesn't seem amenable to that. Third, that an
outside party is trying to target one group over others. Fourth...
dunno. I'm tired of writing.
If it isn't obvious, I support the notion of a separate podling where
all BPEL implementations can gather, be sorted out, and to establish a
great community and product. Picking one, and shoving that down inside
another codebase is not the answer. It feels like servicemix is being
used as armor against outside interference, and that sucks.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: BPEL contribution from Sybase
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dain Sundstrom wrote:
>
> I don't think anyone has said that this isn't a donation to apache.
> Every donation I have seen to apache, has either come to a PMC and is
> sponsored as a IP donation or incubated sub project, or comes
> directly to the incubator without a sponsoring PMC and must find one
> (which can be the incubator PMC). This is exactly what is happening
> here with the Geronimo PMC.
No, it not what is happening here. If Geronimo sponsored
BPEL as a new podling, *then* it would be. What is happening
here is a contribution being aimed at a specific set of developers
on a specific podling in incubation. The match between the
contribution and the podling is being questioned.
> I think that is a different case. In that case we are talking about
> two competing communities. In this case, we have a donator and a
> community that *want* to work together.
And having a separate BPEL podling does not interfere with that.
It also presents no barrier to people outside ServiceMix who
might want to work on it without having to filter non-BPEL
discussions.
> I disagree. That is like saying any contributor is exclusive because
> they committ code to only one or two projects. Sybase has some code
> that want to integrate into the service mix code base because they
> like the project and the community and want to work collaborate with
> them. They could have quietly showed up an built a new orchestration
> engine in service mix, but instead they are offering some existing
> code to start with. What's the big deal?
Code contributed to Apache goes where the Apache community
thinks it should go, not necessarily where the contributor
does. In this case, the would-be contributor's desired
destination is being challenged by people who think it
should be handled elsewise.
- --
#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/FHxprNPMCpn3XdAQLwYQP8DCtvrFvJ2rmQpLmBW4c56Gr88XmH9NH/
HvCeHCTxzem/cKkhe8aF8xrmc9HVxRv9abbSQ1e2GQcrmsnCqR9BkBN+pXZGUBsd
fQ06YxZank/Dct/Dncc3NFDf2BpEEOPjUB33vyTX+StabdCImMDs6mc1QICvkv5Z
bFhmiExIrGo=
=Hss4
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: BPEL contribution from Sybase
Posted by Dain Sundstrom <da...@iq80.com>.
On Feb 13, 2006, at 5:34 PM, Greg Stein wrote:
> 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.
I don't think anyone has said that this isn't a donation to apache.
Every donation I have seen to apache, has either come to a PMC and is
sponsored as a IP donation or incubated sub project, or comes
directly to the incubator without a sponsoring PMC and must find one
(which can be the incubator PMC). This is exactly what is happening
here with the Geronimo PMC.
> 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.
Woha... There is no one saying the service mix community is biased
against new comers. I think it is the exact opposite. They are very
welcoming and I think this is what excited them to donate the code.
> 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.
I think that is a different case. In that case we are talking about
two competing communities. In this case, we have a donator and a
community that *want* to work together.
> 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.
I disagree. That is like saying any contributor is exclusive because
they committ code to only one or two projects. Sybase has some code
that want to integrate into the service mix code base because they
like the project and the community and want to work collaborate with
them. They could have quietly showed up an built a new orchestration
engine in service mix, but instead they are offering some existing
code to start with. What's the big deal?
-dain
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: BPEL contribution from Sybase
Posted by Greg Stein <gs...@lyra.org>.
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
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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
Re: BPEL contribution from Sybase
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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
Re: BPEL contribution from Sybase
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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
Re: BPEL contribution from Sybase
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
-----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.'
- --
#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/FDyJrNPMCpn3XdAQLjXQP/URqbW5Qmtirvt9HSdQJWQByRBzh4wV+Q
OrV38DhewUtdUmsjQNvYenkPs9odbacP1Op79ZIkh6EiM0hnwIwnfLPfklDUrp+S
fmfRuNmHH4N6fSh7PFK28Zh6GlY/MXpgdI2XDh7n9JGcGBNHTI4kq+YmAsJH/tFr
ZnURkBQkRIY=
=s2ms
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: BPEL contribution from Sybase
Posted by Geir Magnusson Jr <ge...@pobox.com>.
was there some crosspost dropped here?
Mads Toftum wrote:
> On Mon, Feb 13, 2006 at 02:19:56PM -0800, Dain Sundstrom wrote:
>> 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).
>>
> Whoa! Are you actively suggesting forks inside the same community? code
> duplication and competition between tlps? Somehow that doesn't sound
> like something that should happen within the ASF - and certainly another
> point in favor of Ken's suggestion of keeping it outside servicemix.
>
> vh
>
> Mads Toftum
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: BPEL contribution from Sybase
Posted by Mads Toftum <ma...@toftum.dk>.
On Mon, Feb 13, 2006 at 02:19:56PM -0800, Dain Sundstrom wrote:
> 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).
>
Whoa! Are you actively suggesting forks inside the same community? code
duplication and competition between tlps? Somehow that doesn't sound
like something that should happen within the ASF - and certainly another
point in favor of Ken's suggestion of keeping it outside servicemix.
vh
Mads Toftum
--
`Darn it, who spiked my coffee with water?!' - lwall
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: BPEL contribution from Sybase
Posted by Dain Sundstrom <da...@iq80.com>.
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.
>> - --
>> #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-----
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: BPEL contribution from Sybase
Posted by Dain Sundstrom <da...@iq80.com>.
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.
>> - --
>> #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
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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 <da...@iq80.com> 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-----
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: BPEL contribution from Sybase
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
-----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.'
- --
#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/FDyJrNPMCpn3XdAQLjXQP/URqbW5Qmtirvt9HSdQJWQByRBzh4wV+Q
OrV38DhewUtdUmsjQNvYenkPs9odbacP1Op79ZIkh6EiM0hnwIwnfLPfklDUrp+S
fmfRuNmHH4N6fSh7PFK28Zh6GlY/MXpgdI2XDh7n9JGcGBNHTI4kq+YmAsJH/tFr
ZnURkBQkRIY=
=s2ms
-----END PGP SIGNATURE-----
Re: BPEL contribution from Sybase
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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 <da...@iq80.com> 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
Posted by Greg Stein <gs...@lyra.org>.
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/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: BPEL contribution from Sybase
Posted by Dain Sundstrom <da...@iq80.com>.
On Feb 13, 2006, at 6:17 PM, Greg Stein wrote:
> On Mon, Feb 13, 2006 at 05:40:47PM -0800, Dain Sundstrom wrote:
>> On Feb 13, 2006, at 5:25 PM, Noel J. Bergman wrote:
>>> 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.
>>
>> I really detest it when people try to flip the burden of proof. The
>> donator wants to put the code into ServiceMix and ServiceMix wants to
>> work on it. I think the burden of proof is on you. Unless you come
>> up with a BIG reason that this donation must be stopped, otherwise I
>> see no reason to not proceed with the IP checklist.
>
> The IP checklist is the same either way. There is no "burden of proof"
> with respect to that. The "proof" is actually more about "expected
> outcome" and around how we believe the ASF community will end up
> managing the resulting codebase.
>
> IMO, what is happening here is that a number of people are observing,
> for all intents and purposes, a turf battle over a codebase. That is
> the antithesis of the ASF community model. This implies there are two
> problems: the battle, and the people (who see "defending turf" as okay
> behavior).
>
> The solution to erasing those turf lines is to put *everybody* into
> the same pool (the BPEL podling) and to put *all* projects outside of
> that pool (no special consideration for Geronimo, WS, or whoever).
>
> The more people play turf battles ("go into the service-mix turf"),
> the worse the whole BPEL situation looks, and the more important it is
> to stamp it out right here and now. And that is what the Incubator is
> all about. Erase the lines and create a community that can work on
> something with a cooperative atmosphere.
Good point.
-dain
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: BPEL contribution from Sybase
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Feb 13, 2006 at 05:40:47PM -0800, Dain Sundstrom wrote:
> On Feb 13, 2006, at 5:25 PM, Noel J. Bergman wrote:
> >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.
>
> I really detest it when people try to flip the burden of proof. The
> donator wants to put the code into ServiceMix and ServiceMix wants to
> work on it. I think the burden of proof is on you. Unless you come
> up with a BIG reason that this donation must be stopped, otherwise I
> see no reason to not proceed with the IP checklist.
The IP checklist is the same either way. There is no "burden of proof"
with respect to that. The "proof" is actually more about "expected
outcome" and around how we believe the ASF community will end up
managing the resulting codebase.
IMO, what is happening here is that a number of people are observing,
for all intents and purposes, a turf battle over a codebase. That is
the antithesis of the ASF community model. This implies there are two
problems: the battle, and the people (who see "defending turf" as okay
behavior).
The solution to erasing those turf lines is to put *everybody* into
the same pool (the BPEL podling) and to put *all* projects outside of
that pool (no special consideration for Geronimo, WS, or whoever).
The more people play turf battles ("go into the service-mix turf"),
the worse the whole BPEL situation looks, and the more important it is
to stamp it out right here and now. And that is what the Incubator is
all about. Erase the lines and create a community that can work on
something with a cooperative atmosphere.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: BPEL contribution from Sybase
Posted by Dain Sundstrom <da...@iq80.com>.
On Feb 13, 2006, at 5:25 PM, Noel J. Bergman wrote:
> 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.
I really detest it when people try to flip the burden of proof. The
donator wants to put the code into ServiceMix and ServiceMix wants to
work on it. I think the burden of proof is on you. Unless you come
up with a BIG reason that this donation must be stopped, otherwise I
see no reason to not proceed with the IP checklist.
-dain
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: BPEL contribution from Sybase
Posted by James Strachan <ja...@gmail.com>.
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
Posted by David Jencks <da...@yahoo.com>.
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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
Re: BPEL contribution from Sybase
Posted by David Jencks <da...@yahoo.com>.
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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: BPEL contribution from Sybase
Posted by David Jencks <da...@yahoo.com>.
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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: BPEL contribution from Sybase
Posted by James Strachan <ja...@gmail.com>.
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
Posted by David Jencks <da...@yahoo.com>.
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
Posted by James Strachan <ja...@gmail.com>.
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/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: BPEL contribution from Sybase
Posted by "Noel J. Bergman" <no...@devtech.com>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: BPEL contribution from Sybase
Posted by "Noel J. Bergman" <no...@devtech.com>.
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
Posted by Dain Sundstrom <da...@iq80.com>.
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-----
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: BPEL contribution from Sybase
Posted by Dain Sundstrom <da...@iq80.com>.
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-----