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

[Kevin McGuire <Kevin_McGuire@xxxxxxxxxx>]

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