Difference between revisions of "JWT and STP STPIM"

Revision as of 05:47, 10 December 2008

Overview

This join STP - JWT discussion aims to put STP and JWT face to face and outline their respective vision, offering and features, weight their oppositions and complementarities, in an attempt to foster a common, consistent vision and tooling of BPM and SOA.

A key link is the STP Intermediate Metamodel, which aims to be the "glue" in the SOA space between the various STP tools, and that has already been integrated in JWT.

Next step : draft & to be discussed at ESE'08

TODO

• http://wiki.eclipse.org/STP/IM_Component/STP_Use_Cases

Existing ties between JWT and STP

• STP and JWT "friend projects" and discussions from as far back as '06
• the SCA service platform-themed SCOrWare research project has provided both STP and JWT with committers (Adrian, Stéphane, Alain, Vincent, Marc...) and contributions (among others, in STP its SCA Editor and in JWT its BPMN and XPDL transformations, as well as a more flexible metamodel and upcoming BPM for SOA/SCA features)
• JWT - STP-IM transformation by Augsburg University

These ties, along with JWT's intent to address classic BPM lifecycle problems using SOA benefits, push both closer.

Marc Draft

Complementarity

What STP may lack and JWT could provide

• which runtime platform does it work for,
• which BPM engine,
• tooling use integration (STP-IM provides an answer, but for the user it is still not a consistent SOA experience)

This outlines several axis of possible complementarity with JWT

• ex. JWT as the complete BPM solution (including engine(s)) for STP,
• or as the open, flexible BPM modeler for STP.

What JWT lacks

• addressing the SOA space itself

Differences in vision

STP-IM allows the integrated tools to share information in the SOA space. However much other information remains in each tool. Therefore STP-IM allows tools that are complementary within the SOA space to work together (ex. a BPMN modeler and a web service deployer), but it is much harder for tools that do the same job or overlap (ex. two JBI service tools).

JWT wants integrated tools to open up their information, in order to foster emerging consensus on subspaces metadata. It does so by promoting metadata that is consistent across all formats / languages / models, through consistent "rules of the good citizen" in WE metamodel, transformations and WAM APIs.

What is "JWT and STP-IM"

Goals : to build the vision of what is "JWT and STP-IM"

• in theory (how do they complement each other, or not)
• and in practice (consistency of complete tooling solution : where does jwt2stp-im fit in the soa development process...).

TODO see STP-IM layers of the SOA space theory : is JWT vis-à-vis STP-IM (and therefore their metadata integration)

• only in the business / design space ?
• vertically in the BPM "column" part of it ?
• how does it concretely map to already STP-IM-integrated STP tools ?

Florian Draft

It's probably important to realize where the strength, advantages and disadvantages of the two projects are in order to further discuss the collaboration. My two coins:

Advantages of STP

• Sticks pretty well to standards:

 * BPMN editor (nearyl) according to the OMG
 * Policy editor considering WS-Policy
 * SCA editor for the Open SOA SCA standard

• STP Intermediate Model as an attempt to get the different standards working together and enable transformations
• Many people/companies involved in STP

Advantages of JWT

• Currently proprietary graphical format in the workflow editor, but can be easily changed by different vendors
• One process can be modeled abstract first and then be adapted via aspects to fit to several process engines
• Transformations from/to existing standards available: BPMN, BPEL, XPDL and also to STP-IM
• Top-down-approach: where most workflow engine vendors have a bottom-up approach and often create a modeling tool that is only compatible with their own workflow engine, we work top-down in order to be adaptable with several workflow engines.
• We do not only consider design time, but also runtime and are working on integrating both.

Adrian Draft

(From mail)

It will definitely be interesting to see how JWT and STP can collaborate, and I think probably a good next step would be to think about some scenarios which would show how end-users could use JWT and STP in an "ideal" world, where all tools/editors can communicate  :) This would give some concrete fuel to the discussion on what to develop next (and the existing transformation from JWT to STP-IM is definitely a great start).