JWT and STP STPIM
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
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 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 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.
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 ?
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.