Re: [stp-dev] Re: [Open letter to STP regarding BPEL and other verticals

[Kevin McGuire <Kevin_McGuire@xxxxxxxxxx>]

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