STP/IM Component/Discussion on STP IM and JWT

Preliminary

The STP Intermediate Metamodel (STP-IM) is a "bridge" between STP editors and its elements have the role of conceptual transport between different development spaces with the purpose of capturing as much common SOA design information as possible.

Similarly, the Java Workflow Tooling project defines a metamodel as part of its mission to unify different workflow definition languages. This metamodel provides a consistent and complete set of elements to respond to the needs of a generic workflow editor and engine while at the same time covering most current workflow languages and standards.

Given the similarities in the needs and purposes of STP-IM and JWT, discussions have been initiated with the aim to improve communication, sharing and collaboration between the two projects. This page is intended as a living space where information on the status of this collaboration is kept up to date. See newer and more use case-oriented, global vision at JWT and STP STPIM.

Collaboration Scope

The STP-IM elements that correspond to process/workflow editors in STP (e.g. BPMN, BPEL) as well as to architecture definition editors and platforms in STP (e.g. JBI and SCA). For the purpose of the collaboration with the JWT project, the elements corresponding to the process/workflow part are of particular interest.

Discussions

So far the discussions between the two teams have focused primarily on the following subjects:

• deeper understanding of the general design of STP-IM and JWT metamodels
• understanding of STP-IM properties and specification of semantics for different standards and platforms
• identification of points of interest for collaboration
• definition of first practical steps to achieve interoperability

Current Understanding

While JWT and STP-IM both contain some very similar elements, there are some differences in scope between the two projects. STP-IM is a pragmatic approach to bridge editors and platforms in the STP project and its design reflects this pragmatism. In JWT, the scope can be considered larger as it tries to cover the process/workflow world in a comprehensive manner. In addition, STP-IM is equally focused on architecture definition standards such as SCA which is not a major concern for JWT. Lastly, the IM is meant to remain relatively lean and generic with a declared goal of covering only common STP semantics, in other words it can be seen as an intersection of STP-covered standards. This approach is clearly visible in the way the property elements have been designed. They facilitate the specification of semantics in the transformers and generators that use the IM to carry information between STP editors and platforms.

Follow-up Actions

• start work on basic transformations between JWT and STP-IM
• properly documents the designs of the two metamodels
• document the use of properties including naming conventions - for generators

Resources

Discussion Threads

• [1]
• [2]
• [3]
• [4]