Re: [stp-dev] Intermediate Meta-Model Discussion - Update

["Alex Boisvert" <boisvert@xxxxxxxxxxx>]

On 8/22/07, Adrian Mos <adrian.mos@xxxxxxxx> wrote:

Here's a basic example: Suppose we want to show via BPMN or BPEL that we want to call services A and B to fulfil a business requirement. I would have (for BPEL) a resulting orchestration R that involves the sequence of operations from A and B. When I move to my SCA editor, I want to have a composite corresponding to this orchestration. This composite C will contain inside the services R, A and B with wires between R - A and R - B. The service offered by C is in fact the service offered by R and we would have the service of R promoted to the composite C (wire between C's service and R's service). This is an architectural choice of representing processes that might not be what everybody needs, but it may be a good pattern for SCA. 

Obviously the two diagrams (BPEL and SCA) would convey different semantics, each focused on their own usage domain. However, using the intermediate meta-model, we could transport information between the two editors. If we only had the WSDL-specific stuff in there, we would lose the interactions therefore having to duplicate work. 

In other words, the "steps" in the intermediate model would mean different things to different editors (real steps for BPMN/BPEL), hints for composition in SCA, hints for assembly in JBI etc.

Thanks for the example.  I see the need for annotating relations to contextualize the dependencies, but I'm still not clear on how "steps" would be modeled in a SCA/JBI composition.

<Elephant_In_The_Room>
At a different level, I would advise picking one of the two existing composition model as "reference".   With two models (SCA and JBI) this would save a lot of work.  Besides saving the time required to define a new meta-model, it would avoid a lot of confusion by diluting/overloading existing semantic into a single model.  I understand there's plenty of political bias going against this, but it's the pragmatic choice.   The reference model would need to be extended to support the (union) of semantic to cover all surrogate models.    From experience, the gains from having a concrete reference model have "network effect" properties and provide greater benefits than having an abstract meta-model, especially as you add surrogate models.

Applying this reasoning to process models (BPMN/BPEL), I would pick BPEL as the reference model and consider BPMN a surrogate model.  In my opinion, even if you considered, say, XPDL as another candidate process model, you would still have better conversion between XPDL, BPEL and BPMN if you converted via BPEL than through some abstract process meta-model.    Although in this case, it might be worth splitting the conversion into two levels...  execution semantic and visual notation depending on your needs.
</Elephant_In_The_Room>

alex