Hi Stefan,
Thanks for your reply. First off, I intended my previous email to be
direct but not inflammatory, so my poor wording. Clearly this is
becoming a stressful issue for all.
You bring up several points.
1) You are correct that the BPEL Designer project is strictly focused
around UI. Specifically: editor, model, validation, deployment hooks.
No runtime. So I agree that there is no functional overlap with the
BPEL Designer work. Actually, we're keen for good runtimes for BPEL.
2) It seems there is more to B2J than I am "getting". You said,
>>B2J will - among other things - align with and provide reference
>>implementations for key models in the STP project
What are these "key models"? My assumption was that the "B" in B2J is
for BPEL, and when I hear someone is writing a "B2J" converter, I
interpret that as, "they are writing a BPEL runtime". But your wording
indicates something larger, or different. Supporting a wide set of
models and languages is obviously a good goal. I am trying to
understand whether you view that all your "key models" will be BPEL
based, or if you are creating a framework for *2J deployment, where *
is any language? Will the B2J output be a supported reference BPEL
runtime?
3) >>I will leave it to the appropriate parties to comment on BPMN.
This is actually the one that has me the most concerned wrt. overlap
and direction.
4) I understand your point about creation review. Perhaps a source of
confusion is that both projects started at about the same time. I
don't remember the BPMN subproject (nor B2J for that matter)
discussion in the material I saw around the time of your creation
review, so either I just missed that, or it grew after. If I
understand right the BPEL work came via TPTP and was after, no?
I'm not trying to turn back the clock. Clearly there is no sense
though both of us developing BPEL models and UIs. Our decision to
create the BPEL Designer project would've been affected by an
understanding that there was a competing BPEL effort in Eclipse. We
were aware of the BPEL work in TPTP but understood that to be focused
on a particular purpose, rather than a general choreography component.
5) There has been some expression of interest in joining forces on
BPEL. That's excellent. However, STP is looking to BPMN and we are
not. I would like to understand better whether BPMN is a specific
requirement for how the processes should be expressed, or if it was
picked simply because its a standard (and as good a starting point as
any)? As in my previous note, the choice of BPMN has caused me some
confusion over the goal of STP because its aimed at business users and
modelling, which seems to me beyond the mission of creation of a SOA
platform.
6) Do you forsee STP growing subprojects for other component types? I
would like to understand how subprojects for component types fits in
with the STP charter (perhaps I just missed something in it) since the
charter in my read was around platform creation, not additionally the
creation of components which consume that platform.
Cheers,
Kevin McGuire
*Stefan Daume <Stefan.Daume@xxxxxxxxxxxxx>*
Sent by: stp-dev-bounces@xxxxxxxxxxx
03/15/2006 04:50 AM
Please respond to
STP Dev list
To
STP Dev list <stp-dev@xxxxxxxxxxx>
cc
Kevin McGuire/Ottawa/IBM@IBMCA, Greg Adams/Ottawa/IBM@IBMCA,
mike.norman@xxxxxxxxxxxxx, Ward Cunningham
<ward.cunningham@xxxxxxxxxxx>, Mike.Milinkovich@xxxxxxxxxxx,
michal.chmielewski@xxxxxxxxxx
Subject
Re: [stp-dev] Re: [Open letter to STP regarding BPEL and other
verticals, from the Eclipse BPEL Designer team
Hi all.
First of all let me state that no-one questions the effort, commitment
or competence of individual committers in any project whatever its
nature or state.
Furthermore, let me add a few points about B2J to this rather surprising
discussion. I will leave it to the appropriate parties to comment on BPMN.
On the technical side:
- the BPEL Designer project presents itself as a UI project; that's what
B2J is definitely not; B2J will not deliver a BPEL editor (as stated
multiple times now); B2J would be completely misplaced in the BPEL
Designer project because it intends to deliver something that is
broader; we invite people from other projects to hook into the
integration framework that STP B2J already provides and will extend; as
an aside let me say that I always felt that indeed the BPEL designer
project should be a subproject of WTP
- I do not think that "dinky examples" do provide a great value; every
project must or should provide valuable reference implementations to
serve the most important objective: broad adoption; that is a goal that
we all share; references to other projects were made that underline this
point
- STP B2J will - among other things - align with and provide reference
implementations for key models in the STP project; more importantly
however it will contribute to establish a deployment integration
framework specification which is envisaged to have a broader impact,
namely - as Carl pointed out earlier - to ensure we have the frameworks
in place to have STP extensible enough to support other languages (C++,
COBOL, BPEL, PHP, etc); with regard to that notion of extensibility B2J
will contribute an important piece to STP; again there is a huge impact
on adoption here
On procedure:
The timing and nature of this discussion concerns me. Labelling any
contribution in this exchange as silly or spurious does not help. In any
case all of these exchanges should be public on STP-DEV and not just be
addressed to a few individuals.
Trustworthiness of open source artifacts and processes is a key theme in
the industry these days and should not be taken for granted. Eclipse
established a well-defined process for projects and contributions to
establish trust in the Eclipse open source processes and artifacts. This
applies both to the exploiters of Eclipse as well as people wishing to
contribute.
The creation review period is an open process. All information is
available. STP went through this process. The community through the
board approved STP as a top-level project with its current structure,
intent and scope. The available information was plentiful especially
with regard to B2J as the basic contribution already existed publicly.
Obviously, in future there will always be issues and concerns that are
raised and discussed and in a few cases could even result in structural
changes or the creation of new projects. In fact, that is what happened
with the previous incarnation of B2J.
However, with regard to the STP creation review, the Eclipse ecosystem,
the process or the technical arguments nothing has changed at this point
that would suggest to question the current structure of STP. Finally, I
would like to point out that we were aware of the BPEL designer project.
B2J was deliberately taken to the STP project and not the BPEL designer
project because we were and still are convinced that it belongs in STP.
And indeed so was the STP community that conceived this project when
they invited B2J as a subproject.
I am happy to have a chat about this at EclipseCon. In the meantime I
refer you to the available information.
Regards,
Stefan
*********************************
Stefan Daume
CTO, Scapa Technologies
125 McDonald Road
Edinburgh EH7 4NW
Scotland
UK
Tel: +44 (0)131 652 3939
Fax: +44 (0)131 652 3299
*********************************
Kevin McGuire wrote:
>
> There's been a lot of activity in this mail list and its difficult to
> know which to respond to.
>
> First, I would like to say that as a long time Eclipse committer (one
> of the original, actually) I am disappointed by the direction these
> discussions have taken. Mostly I've heard spurious and defensive
> arguments about why this current situation is acceptable. But plainly
> it is not. It is silly to argue that there is no overlap, and that's
> its ok that there is overlap. The current climate is not healthy for
> the Eclipse open source community.
>
> My single goal is to deliver the best open source software for process
> choreography, and to support an open source community of SOA
> components, because I believe that this is in the best interest of the
> industry and the community. I believe that the majority of the people
> involved in this effort have this shared goal. If however someone has
> a goal that is different than this, then they should be contributing
> through a private commercial offering, not through the Eclipse
community.
>
> Given that both projects (BPEL Designer, STP and its subprojects) are
> relatively new, it is not surprising that decisions were made in
> isolation which now perhaps do not make sense.
>
> I believe the BPEL Designer position is clear, which is that we will
> deliver a BPEL compliant extensible editor, model, and validation,
> with support for deployment to a number of executable environments.
> BPEL is a thing unto its own. It can exist in an SOA environment, or
> not. STP is just one of many contexts for BPEL.
>
> Thus to us on the BPEL Designer project, it would make sense to have
> bindings for STP, because we believe STP is important, and it seems
> natural to us that those bindings should be hosted by the BPEL
> Designer project, just like we'll be hosting bindings for other
> execution environments.
>
> Because of this runtime context neutrality of BPEL, its unclear to the
> BPEL Designer team why one would host BPEL work under the STP project,
> because again the applicability of BPEL is much larger than just STP.
> We can understand how one might've found oneself there because (A)
> SOA without choreography isn't that useful in practice and (B) the
> BPEL Designer project either didn't exist or wasn't clearly viable at
> the time. That is not the situation today.
>
> The BPEL Designer project has a UI and EMF model seeded from
> commercial code which shipped in major products. It has development
> resources dedicated to it, on both the IBM and Oracle sides, with new
> resources being contributed from academia in the UK. It is relevant,
> with interest mounting, staffed by excellent people with experience
> shipping BPEL choreography. If someone wants to roll their own open
> source BPEL editor then they can go ahead but the community will
> gravitate to the one which is first and with the strongest editing
> experience and backing. Having two in Eclipse open source is pretty
> clearly a waste of time.
>
> I understand STP wanting to encourage and support the development of
> SOA components. This is a good thing. We support it too. And I can
> understand how that might've led to the notion of subprojects to host
> component work such as BPMN (since maybe there was nowhere else to do
> that work). However, I believe that is the wrong structure. STP
> should of course host work which is SOA specific. However, as above,
> BPEL is not SOA technology, nor is BPMN. As contributors come to the
> table with their own components, be them choreography or otherwise, I
> do not expect them to be hosted as subprojects of STP. In my mind,
> the whole point of SOA is the clean separation of framework and opaque
> component. The STP project should reflect this architectural
> separation in its project organization.
>
> BPMN is a modelling language aimed at business users. STP is a
> platform to support SOA components. Hosting both is I believe beyond
> the STP charter, confuses the notion of SOA separation, and provides
> an implicit advantage to one Eclipse choreography component over
> another. By analogy, this is like Windows (OS) including IE
> (application).
>
> I believe STP needs to make its position clear on hosting of
> components as subprojects, BPMN now and others in the future, and how
> this is in keeping with its charter.
>
> Yours,
> Kevin McGuire
>
>------------------------------------------------------------------------
>
>_______________________________________________
>stp-dev mailing list
>stp-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/stp-dev
>
>
_______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-dev
------------------------------------------------------------------------
_______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-dev
