[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
