There has been much focus in yours and
other emails on B2J, but not on BPMN, and these I believe need to be discussed
together. This was certainly my intent although my original note
did not do so clearly.
From your project page I see:
"The BPMN subproject will provide
an editor and a set of tools to model business processes diagrams using
the BPMN notation and allow validation and generation of BPEL artifacts
from those diagrams."
This has huge overlap with the BPEL
we both have visual editors capable of capturing BPEL choreography semantics
we both have validation (we'll both need EMF models or equivalent to validate,
plus validations based against the same BPEL semantics)
we both require generation and execution (B2J or some other).
We can debate whether BPMN is a better
notation than BPEL Designer, but the fact remains, they are both
BPEL process flow choreography editors and are more similar than different.
From an eclipse community perspective,
this is splitting the relatively small resources we have to devote to the
production of a quality choreography component. Thus I don't believe
the current course we are on is in the best interest of our shared goals
of a strong SOA based platform and tooling ecosystem.
Note: I'm afraid I didn't understand
your last comment that the B2J work:
"intends to integrate with (and provide implementations)
for relevant models of the STP Service subproject" But perhaps I am just hung up on the
"B" part of the "B2J" component, since I assume you
don't intend all your service models to be BPEL based.
2. The role of STP
Unfortunately I was not on the STP review
call so perhaps this is just my misinterpretation of your project charter.
Your charter states the project as being:
... dedicated to providing a generic,
extensible, standards-based tool platform for producing Service Oriented
Architecture (SOA) applications based around the Service Component Architecture
... extensions to assemble, coordinate,
and deploy participants ...
It describes a SOA platform framework
approach based on industry accepted standards (SOAP, WSDL), to support
third-party components. We are in enthusiastic support of this approach!
The only place where I see it discussed
that STP will create its own components is the line:
... an exemplary set of plugins to demonstrate
and validate the platform.
Where by "exemplary", I take
this to mean in the documentation sense, with no intention of their use
in a production environment.
So it was with some surprise that we
saw the creation of subprojects for BPEL specific work (B2J, BPMN) because
in our view, BPEL is not part of the SOA framework but rather is
just one choreography model (among others) which exists as a consumer
of the component framework.
To add to the confusion, I will note
that BPMN is a modelling notation targeted at business users.
Modelling for business users is getting pretty far afield from a
service component platform.
Thus through the inclusion of BPMN and
BPEL subprojects, STP is moving from the stated platform role, to one of
a product role, which IMHO is beyond its charter. As such, it is
creating some confusion in the community with regards to which work should
be done where.
If I have misunderstood or misinterpreted
your intents then I am happy to better understand how you view these two
projects can complement each other successfully.
WID & WSADIE UI Development Lead
Assitant: Jennifer Collins/Ottawa/IBM
Stefan Daume <Stefan.Daume@xxxxxxxxxxxxx>
03/13/2006 10:55 AM
STP Dev list <stp-dev@xxxxxxxxxxx>
Re: [stp-dev] Re: [stp-newsgroup]
Open letter to STP regarding BPEL and other verticals, from the Eclipse
BPEL Designer team
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.
CTO, Scapa Technologies
> 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
> 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
> 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
> so, this needs to be evaluated and discussed and hopefully sense will
> 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.
> STP PMC
> 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"
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
> framework which verticals can plug into.
> So why is STP doing java gen of BPEL models and BPMN tooling? These
> 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
> 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
> predates the BPEL project, we could understand why rolling your own
> model and editor seemed at the time like a necessary step. However,
> 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
> 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
> not expect it to be hosted as subproject of STP. If you include
> 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
> their nature compete with other efforts either underway or future.
> 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
> need to develop and support your own model (with presumably BPMN tooling
> as the visual language). As we already have a model, that seems
> of effort.
> Instead, wouldn't it be a better use of our collective resources to
> gen the eclipse BPEL model? We would be very open to this and
> happy to host this effort.
> --- Why BPMN? ---
> There is nothing I can see from the STP charter that motivates BPMN
> the preferred visual _expression_ of BPEL processes. BPMN just
> 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
> 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,
> 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
> 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