[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [stp-dev] Re: [stp-newsgroup] Open letter to STP regarding BPEL and other verticals, from the Eclipse BPEL Designer team

Hi all.

Karl, thanks for your response and the points of clarification. I would like to add a few points to this. Let me make clear upfront that I think it is not only the case that the B2J project is best placed in the STP it would indeed be misplaced in the BPEL designer project.
I appreciate that some of the concerns simply originate from the fact that only limited information is published yet about the different (sub-)projects, which probably leads to misunderstandings (similar maybe to the ongoing discussion about suitability of SCA vs JBI). Unfortunately, not everyone may have taken the opportunity to attend the creation review which offered a detailed discussion and information on STP, B2J and other sub-projects. I am convinced that things will become clearer as detailed information on the current state of the contribution and the (sub-)project plans becomes available. The creation review is completed and the project is up and running. I think at this point we are all keen to see steady progress with the STP project.

On the subject I would like to add a few points of clarification as taken from the sub-project description:

- B2J does not create an alternative BPEL model, thus there is no overlap or competition with the BPEL designer model
- B2J does not create a BPEL UI/editor and thus functionally there is no overlap or competition with the BPEL designer
- B2J is actually part of the deployment area in STP; one of the main deliverables is to establish a deployment integration framework specification and reference implementation of the integration framework: more importantly it intends to integrate with (and provide implementations) for relevant models of the STP Service subproject; as such it will help to provide and align key standards in the STP project as well as provide reference implementations

Furthermore, I would like to point you to the available contribution that has just gone into the CVS. The sub-project website should be available shortly as well. Please feel free to ask questions at this stage if they are not answered by the available resources.



***************************************** Stefan Daume CTO, Scapa Technologies

125 McDonald Road
Edinburgh EH7 4NW

Tel: +44 (0)131 652 3939
Fax: +44 (0)131 652 3299

Karl.Reti@xxxxxxxxxx wrote:

Hi Kevin,

Thanks for posting this position statement to the newsgroup, I think it does bring to a head certain concerns that have been circulating regarding the subprojects of STP, specifically BPMN and B2J. Before I move on I would like to add one point of clarification to your note. The B2J subproject is not in fact developing any diagramming or editing tools for designing BPEL processes but is purely a translation tool for converting BPEL to Java and is an existing component already implemented in the TPTP project - although this does not necessarily invalidate your points.

Regarding your points on the housing of the technology, STP's main goal is to provide a place where all tools that are relevant to Service construction, SOA assembly and provisioning can come together in a coherent and meaningful manner. STP must encompass the strong diversity of approaches to policy expression, interface vocabulary and implementation language. The only way that STP can do this, as you express in your message, is to be a real platform into which verticals can integrate.

The BPMN and B2J subprojects are in STP for two specific reasons.

1. The committers of these projects approached STP and we accepted them, the reason as you state is because the BPEL project was not up and running at that point.
2. The committers wanted to be involved in a larger SOA oriented project for their own particular reasons and no alternative location was relevant at that time.

If we can convince these committers that it is in everyone's interest to merge with the BPEL project then I think that would be a reasonable outcome. I don't think that it is for the PMC to demand that they do so, this needs to be evaluated and discussed and hopefully sense will prevail.

We invite the BPEL project to join us for a discussion at EclipseCon, so that we can smooth the track for further collaboration. In the meantime, let's continue our conversations on the stp-dev list.


Oisin Hurley (IONA) STP PMC Lead
Karl Reti (Sybase) STP PMC Co-Lead
Carl Trieloff STP PMC Co-Lead
Alain Boulze (ObjectWeb) STP PMC Co-Lead


*Kevin McGuire <kevin_mcguire@xxxxxxxxxx>* Sent by: stp-newsgroup-bounces@xxxxxxxxxxx

03/09/2006 03:29 PM
Please respond to
"Gateway between eclipse.stp and stp-newsgroup"


[stp-newsgroup] Open letter to STP regarding BPEL and other verticals, from the Eclipse BPEL Designer team

Hi folks,

We (Eclipse BPEL Designer) are somewhat confused about the STP strategy
around BPEL.

Our understanding is that the STP project's goal is to provide an SOA
framework which verticals can plug into.

So why is STP doing java gen of BPEL models and BPMN tooling?  These are

This approach competes with the Eclipse BPEL open source project
(http://www.eclipse.org/bpel/, proposal at
http://www.eclipse.org/proposals/bpel-designer/).  This situation is not
in the best interest of the Eclipse community because we are splitting
our efforts across two models, two UIs, etc.

---Why write your own BPEL component?---

We can understand that there isn't much point having an SOA platform
without some way of choreographing the services.  Given that STP
predates the BPEL project, we could understand why rolling your own BPEL
model and editor seemed at the time like a necessary step.  However, we
do now have a BPEL open source project, and we'd be happy to see its
integration into an STP environment.

BPEL aside, we think there is a larger concern with STP rolling its own
choreography and service components.  There are a number of programming
languages and metaphors which can be used for the choreography of
services. For example, if someone were to come along with a different
open source choreography service, say based on state machines, one would
not expect it to be hosted as subproject of STP.  If you include BPEL,
you should include other services as well, yet clearly STP can't become
"the place for all interesting web services".   Doing so weakens the
notion of STP as a platform.

STP should be exactly what the "P"  stands for -- a platform.  It should
not be in the business of providing vertical applications which will by
their nature compete with other efforts either underway or future. A
clear delineation is required between framework with *supporting*
tooling and vertical applications in order to create a healthy ecosystem
for the development of innovative service choreography components.

Instead, it seems our efforts would be better spent on the integration
glue for the BPEL open source component to live in an STP environment.

---Java Gen of BPEL?---

In order to support Java gen of BPEL, you will need a model.  The
Eclipse open source BPEL project already has a product quality model,
one which has been vetted through the rigors of being shipped in
WebSphere Integration Developer 6.0.  To not use that means you will
need to develop and support your own model (with presumably BPMN tooling
as the visual language).  As we already have a model, that seems a waste
of effort.

Instead, wouldn't it be a better use of our collective resources to Java
gen the eclipse BPEL model?  We would be very open to this and would be
happy to host this effort.

--- Why BPMN? ---

There is nothing I can see from the STP charter that motivates BPMN as
the preferred visual expression of BPEL processes.  BPMN just happens to
be one way of visualizing BPEL flows.  This visualization seems
orthogonal to STP as a platform.


I see there has been discussion on this general topic in the thread:
but the answer to me was not clear (the answer seeming to be, "Yes its
ok we have our own BPEL but sure others can join as subprojects").
There is at its heart here a very basic question of whether STP should
be creating its own vertical components such as BPEL engines/editors.

The counter proposal on the table is one of combined forces, where:
1) The Eclipse BPEL component becomes a client of STP platform APIs, and
2) The B2J work be written against the Eclipse BPEL model.

We believe this approach is the most beneficial to both projects and
more importantly the community at large. We would be happy to host the
STP extension effort for our BPEL engine.

Kevin McGuire (IBM), Eclipse BPEL Designer co-lead
Michal Chmielewski (Oracle), Eclipse BPEL Designer co-lead


stp-dev mailing list