JWT and STP STPIM

Problematic

How are STP and JWT best put to use together ?

This joint STP - JWT discussion aims to answer this question by identifying use cases, putting STP and JWT face to face and outlining their respective vision, offering and features, weight their oppositions and complementarities, in an attempt to foster a common, consistent, integrated vision and tooling of BPM and SOA.

Note that a key technology is the STP Intermediate Metamodel, which offers to be the "glue" in the SOA space between the various STP tools, and that has already been integrated in JWT for a given use. See older and more theory-grounded, STP-IM focused discussion at STP/IM Component/Discussion on STP IM and JWT.

Next steps :

• implement "Workflows on top of an SOA" use case and enrich STP/IM_Component/STP_Use_Cases

Vision : STP handles SOA, JWT handles workflows

This vision stems of the use case analysis below and has been presented at Eclipse Summit Europe 2008 (thanks STP head Oisin Hurley for lending the last minutes of his session talk).

In short, STP designs and manages the Service Oriented Architecture and its infrastructure, JWT designs and manages business-driven workflows that are built like good SOA citizens.

Use cases

Workflows on top of an SOA

or "STP designs the SOA, JWT designs business workflows on top of it". Based on synchronizing service definitions between STP and JWT.

• STP first designs the SOA. Here can be used WSDL designers, SCA editors, policy editors, service packaging tools... The SOA can then be deployed on the chosen service platform(s).
• the whole set of this SOA's services are gathered and managed in a single STP-IM model. From now on, this model's service definitions become pivotal and the single touchpoint between STP and JWT.
• In JWT, we then import this SOA's services in a workflow model as service calling applications (typically using an "Import SOA > STP-IM" action implemented by a JWT transformation). We can now design workflows sitting on top of this SOA, and deploy & execute them using the chosen JWT runtime.
• Further in the SOA lifecycle, new services & new workflows can be alternately be designed, with the SOA's single STP-IM model being used at each step to again transport service definition information and reconcile service and process space.
  • this can be improved by automatic model reconciliation done in an Eclipse builder

Top-down help to SOA design

• in the course of business analysis, out of user requirements, JWT drafts business processes in a top down manner, first in the design view, then in the technical view
• and there drafts the service calling applications required
• then exports those service definitions to STP using STP-IM (typically using an "Export SOA > STP-IM" action implemented by a JWT transformation)
• where they are used as a business-driven draft to further design the whole SOA
  • at which point the "Workflows on top of an SOA" use case can take place

Import / Export SOA

The previous use cases rely on STP-IM-managed service definitions. In order to make it as painless as possible the first step of getting its existing service definitions in STP-IM, users should be able to import service definitions from the simplest kind of service definitions (a set of WSDL files, of SCA files, of URLs, or even of Java interfaces...). That can be thought of as migration or wizards stuff and would be useful to both STP and JWT tools, and vice versa : Export SOA as well. Question to STP : does it exist already ?

Further, the need appears to centralize / unify the use of STP-IM across tools. This culminates in the idea of an STP-IM builder. But before even getting there, it would be nice not to have to select in each tool which STP-IM model is in use to synchronize the tools in use. That could be done by configuring one (or more ?) STP-IM model(s) in use in a common STP-IM Preferences pages.

Ideas for other use cases

• Using JWT transformations & STP-IM to synchronize process definitions :
  • Interoperability between JWT & STP process runtimes (typically by using JWT transformations & STP-IM to synchronize process definitions). This would allow ex. to 1. design a service orchestration process using STP BPMN and make it executable on its runtime and 2. design business-driven workflows in JWT that at some point calls 1.
  • Compatibility between JWT & STP design tools (ex. STP BPMN & JWT)
• BPM as full fledged SOA citizen, i.e. process engines are themselves used and managed through SOA-managed services across STP and JWT.
• Additional tool-specific features, ex.
  • to SCA editor : process component or service, shared service-level semantic layer
  • to STP Policy Editor : policies that impact servce-calling processes
• *yours*

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. TODO describe what it does.
• JWT's SOA vision : JWT intends to address classic BPM lifecycle problems using SOA benefits. The upcoming JWT 0.7 "SOA" release will allow JWT workflows to call services using a unified design & API, and a Nova Bonita-based runtime will be made available.

---

Discussions

complementarity, vision and integration (Marc D. 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 ?

Reciprocal advantages (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.

Use-case driven integration (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).

At Eclipse Summit Europe 2008 STP meeting

A lot of things have been said. Quoting STP head Oisin Hurley's notes, "these guys can help us, we can help them". Answering "why and how better integrate together" starts by looking at use cases. Marc introduced the use case "STP designs the SOA, JWT designs business workflows on top of it", which bore the "STP for SOA, JWT for workflows" vision and diagram presented the next day at the end of Oisin's session talk.

Advanced topics been adressed include streamlining the use of STP-IM through a model reconciliation / synchronization technology-based Eclipse builder.