Mail Archive Home | eclipse-stp List | March 2006 Index
|<-- Date Index -->||<-- Thread Index -->|
Hi all, Any comment about this discussion ? It should be discussed during PMC audio today (7 PM CET) Alain -- Alain BOULZE mobile: +33(0)6.21.09.43.66 -----Message d'origine----- De : stp-dev-bounces@xxxxxxxxxxx [mailto:stp-dev-bounces@xxxxxxxxxxx] De la part de Antony Miguel Envoyé : vendredi 10 mars 2006 14:19 À : STP Dev list Cc : stp-newsgroup@xxxxxxxxxxx Objet : Re: [stp-dev] Re: [stp-newsgroup] Open letter to STP regarding BPELand other verticals, from the Eclipse BPEL Designer team Hi Kevin, Daniel, B2J was not created initially by the STP project. It originated from TPTP as the 'choreography' component intended to choreograph tests and couple various aspects of the project together using web services. As such, B2J is in fact quite far on in terms of implementation and the concept of building on model X instead of building on model Y is in fact more like replacing model Y with model X. However, even this is not entirely correct because B2J does not in fact define it's own BPEL model - it does not create a traversable model of the BPEL at all. It operates directly on the XML file and translates it directly into Java. I would not want to substitute this behaviour with an EMF BPEL model because I this would reduce the portability of the engine (at the moment the entire translation and execution process can run outside of Eclipse in a standard JVM with no additional libraries). As such I don't see that there is significant overlap between the BPEL project and B2J. If the BPEL designer project can produce valid BPEL 2.0 files then the B2J subproject will be able to use them. BPEL 2.0 is a well defined point of interoperability for the two and I do not see any need for B2J to be any more tightly coupled with the BPEL designer project than through that point of interoperability. The question then is whether to (again) go through a disruptive re-homing process for (as far as I can see) no real benefit. I would also say that B2J is not the vertical that you cast it as. B2J is a translation framework for vendors to incorporate BPEL process execution into their own engines, servers or applications. That the project itself provides two exemplary implementations of this framework does not make it a vertical. Sincerely Antony Daniel Berg wrote: > > Hi Kevin, > > I am forwarding your note to the stp-dev list as well. > > I want to thank Kevin for posting this note to the group. This is an > important point that we need to close on quickly. I completely agree > with Kevin that STP is a platform for other projects to extend their > contributions. We will have some contributions to show how it is done > but when there is clearly another project within Eclipse that defines > the implementation type we (STP) should not try to declare the > contribution to the platform for this type (e..g, BPEL). > > I highly suggest that we take Kevin's proposal and run with it. > > Regards, > Dan > > > > *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" > > > > To > stp-newsgroup@xxxxxxxxxxx > cc > > Subject > [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 verticals. > > 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. > > ---Summary--- > > I see there has been discussion on this general topic in the thread: > > http://dev.eclipse.org/mhonarc/lists/stp-dev/msg00005.html > 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. > > Yours, > Kevin McGuire (IBM), Eclipse BPEL Designer co-lead > Michal Chmielewski (Oracle), Eclipse BPEL Designer co-lead > _______________________________________________ > stp-newsgroup mailing list > stp-newsgroup@xxxxxxxxxxx > https://dev.eclipse.org/mailman/listinfo/stp-newsgroup > >----------------------------------------------------------------------- >- > >_______________________________________________ >stp-dev mailing list >stp-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/stp-dev > > -- Antony Miguel Scapa Technologies antony.miguel@xxxxxxxxxxxxx +44 131 550 1766 _______________________________________________ stp-dev mailing list stp-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/stp-dev
|<-- Date Index -->||<-- Thread Index -->|
Powered by MHonArc.Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster.