Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: AW: [jwt-dev] Re: STP IM and JWT metamodel

Hi Florian,

You are right in thinking that the intermediate model is not just used for one transformation between BPMN and ServiceMix in two steps. It is a generic means of moving information between different editors and platforms and currently we have the support for transformations between BPMN, BPEL and ServiceMix.

The question you are raising about the generality of property definitions is a good one. Basically you are asking how if the model is generic, can you define things that all downstream transformations can understand. The simple answer is, somebody must put them there with the shared understanding of the needs of the target. The IM ALLOWS the definition of properties with specific semantics but does not specify the semantics of each set of properties. This is the price for generality, you can't have a model that is both generic and specific at the same time, and we didn't want to provide the union of all the elements of the supported metamodels in the IM.

So, somehow, the information about how to map concepts from BPMN to JBI (for example) must be put in the IM. And here is the choice we made: the concepts that are general enough to be useful in a variety of situations (such as binding, or step, or service) are directly represented as elements in the IM. The other concepts, specific to one technology or editor, are injected using the properties. As you have rightly noticed, from the BPMN editor we already populate the properties needed to go from BPMN to JBI or BPEL. This is a choice that allows very good integration of editors using standard extension points of BPMN and the IM. Since all the information for JBI can be put in the properties directly from the BPMN editor, we are able to directly generate JBI. However for BPEL, some information must still be added using the BPEL editor, which is why this editor must be opened and used before being able to completely generate the executable BPEL (Andrea correct me if I'm wrong here).

So you already see two approaches for putting non-standard (i.e. non generic enough) information in the IM, needed for particular transformations. One is by directly defining the properties from the source editor, the other by adding specific information in the target editor. You can also imagine using an intermediate editor for example when generating SCA deployable artefacts. You can use BPMN to describe a process, open the SCA editor to add and modify SCA specific information and finally generate the running SCA artefacts. So, while the IM allows the definition of properties that can have different semantics under different contexts, it only standardises some elements, the ones deemed generic enough (and this is of course work in progress as we'll keep improving this generic set to correspond to the needs of STP). Again, the semantics of the properties is in the hands of the transformation developers, the ones that specify how to move to and from the IM and different editors.

It might be a good idea to properly document and classify the properties that are used in different transformations. This way, people can easily use them when adding other transformations that can result in artefacts generated for editors already having transformations (to or from the IM). This and especially the description of the way to add transformations to/from the IM are important for the understanding and adoption of the IM and will be done as soon as possible.

Hope this clarifies things a bit...

Happy New Year! :)

On Dec 28, 2007, at 10:29 AM, Florian Lautenbacher wrote:

Hi Adrian, hi Andrea,

thanks a lot for the clarification about the STP IM. Yes, we are also
looking forward to work with you. Currently we have some efforts on
transformations between BPMN and JWT resp. XPDL and JWT, but after that is
finished we are looking forward to work on a mapping STP IM <-> JWT.

One last question: you say that STP IM is a transporter model (or Pivot model as I understand it), so I only need transformations from say BPMN to STP IM and from there to e.g. ServiceMix Assembly. But how do I know that my first transformation from BPMN to STP IM needs to write specific properties
such as "interface", "method call" or "participant" that ALL upcoming
transformations (to ServiceMix, to BPEL, to XPDL, to whatever) understand
where to look for? Adrian said that STP IM could be described as an
"intersection" between other relevant standards. And that's really good! But then there needs to be a mechanism or naming convention for the generated and added properties, every transformation should take care of and stick to in order to have several model transformations (from BPMN to STP IM, from JWT to STP IM, from STP IM to BPEL, from STP IM to SCA, etc.) working after
each other, am I right?

Or is the "transporter model" thought of as a model simply used in *one* transformation from BPMN to ServiceMix, but this transformation has two steps inside!? But what would be the use of such a transporter model? So I
don't think its like that.

Thanks for this last answer and a happy new year 2008 to all of you!

Best regards,


-----Urspr√ľngliche Nachricht-----
Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev- bounces@xxxxxxxxxxx] Im
Auftrag von Adrian Mos
Gesendet: Samstag, 22. Dezember 2007 12:53
An: Florian Lautenbacher; Andrea Zoppello
Cc: Oisin Hurley; Java Workflow Toolbox; Adrian Skehill
Betreff: [jwt-dev] Re: STP IM and JWT metamodel

Hi Florian,

Andrea gave you the detailed answers for your questions, so I just want to say that if you're looking for help with transformations you can definitely count on us. So if you have any questions about transforming elements from JWT to STP-IM or the other way around, feel free to fire them up on the STP
mailing list, you'll get an answer quickly.

Also, to follow up on what Andrea said and what I noted previously, the STP-IM is a generic "transporter" model, intended to bridge the variety of SOA editors in STP. So, the semantics of properties to different elements can differ based on the transformation that is going to use them. The idea is that we do not try to offer all the semantics in the IM, rather just the means to attach it, so that we can keep a high level of generality while
still preserving the most important SOA concepts as top-level.

Looking forward to working with you guys, Best wishes, Adrian.

On Dec 21, 2007, at 11:36 AM, Andrea Zoppello wrote:


See the comments inline.

Florian Lautenbacher ha scritto:
Hi Adrian, hi Andrea,

thanks for your helpful clarification about the metamodel of STP IM.
I now had a closer look at the metamodel in your SVN and it is (in my
much better designed than the one that is shown on your web site.
In fact
the core concepts are very similar to the core metamodel of JWT
(which can be found on [1]). In STP IM you got a Process which
contains * Steps and * Transitions. Each step has a name, a
description, a number of sourceTransitions and targetTransitions as
well as several observableAttributes. You also got ControlServices
with subclasses like SplitControl or JoinControl. There can be normal Transitions or TransitionsUnderCondition. And (nearly?) everything is
a configurable


Now looking at the JWT metamodel it is very much alike: here
everything is a ModelElement. There are ActivityNodes which are
connected via ActivityEdges (using source, target, in and out with
same cardinality as sourceTransitions, targetTransitions etc. in STP
IM). There can be several types of ActivityNodes: one would be an
Action (probably a Step in
IM) or it
could be a ControlNode such as a ForkNode or a JoinNode. An
ActivityEdge might have a Guard (making it a
"TransitionUnderCondition") whereas the Guard is specified in a
GuardSpecification (with only a proprietary notation allowed).

Regarding your description of Properties and ObservableAttributes I
guess that data that is necessary for execution (which might have
been added to BPMN and shall be transformed into BPEL e.g.) is added
as a property to the relevant step, am I right?


For example for a Step that is configured with Service [StartService]
ServiceBinding [HTTP-InputBindingComponent] the properties will be
driven by the HTTP-InputBindingComponet, So the step will have
properties like:

and so on.

Quite different is the concept of relevant data:

Relevant data are extracted when the process is executed, evluating
expression on messages ( exchanged by endpoint in the case of Jbi ) or
variable in the case of ( BPEL).

An example of relevant data is customerID extracted by /RECORD/

Thanks for clarification about the owner attribute. Yes, I was more
about a participant or role than about an owner. Is this data (e.g.
which is
available in a swimlane or pool in BPMN) then added as a property
right now to each Step?

As i say in previous post we'e not yet provided in the stp
intermediate model the concept of participiant role.
BTW i think that we could support this in BPMN editor in two ways:

1) Using the lane ( ant this will add some additional property on the
step, or better it will configure a particular
 RolebAssignedStep, HumanTaskStep )
2) Get a view with a participiant list that we could drag anbd drop on
the activities

We cannot use the BPMN pool concept beacuse a pool in the im is mapped
in to a process.

I agree with Adrian and Marc that a first step would be having a
transformation from JWT to STP IM (and the other way round).
However, since
the metamodels are quite similar, this should not be so hard. Here at
JWT we need to discuss who will be responsible for this task. Maybe
somebody of STP might be able to assist us here!?

You're welcome. Ask what you want???
I am still wondering how you are planning to include the information
from one metamodel in a way that it is clear in a next transformation
step where it should go. So, if I specify the owner of a step in a
pool or lane in BPMN, how is this information kept in STP IM so I can
work with that when generating e.g. BPEL or XPDL-code? I guess you
need some predefined values as properties that both model
transformations use!? Or will there be a query language (such as RQL
or SPARQL) where you can find the "semantics" of the property?
Best regards and looking forward to some more fruitful discussions,


Intermediate Model is a very generic model so you could have
situations where some properties ( for example of the step ) will be
important by  code generator A and others will be  need  by code
generator B.

The concept is that IM bring you the information in a very generic
way, than  is responsibility of specific code generator to transform
that information in something executable.

To bring you an example, now i'm working in generating servicemix
service assembly applications from intermediate model, and it's my
codegenerator plugins that knows ( for example how to organize service
units, how to make cfg files and so on .... ).

I don't know if it's clear, if you've some doubt please write me.


-----Urspr√ľngliche Nachricht-----
Von: Andrea Zoppello [mailto:andrea.zoppello@xxxxxx] Gesendet:
Montag, 17. Dezember 2007 10:15
An: Florian Lautenbacher
Cc: Adrian Skehill; Adrian Mos
Betreff: Re: Current state of STP IM?


Sorry for the late response but i'm just come back from Javapolis.

See comments inline
Adrian Skehill ha scritto:

Florian Lautenbacher wrote:


I am wondering what the current state of the STP Intermediate model
is? Is the version on the Wiki [1] up to date?

I think version on the wiki is not updated. The version that we're
going to commit will be the really the first version.

If so, I am curious why a step is part of a process, but the
transition is not?
And, on the other hand, why there is only one edge between a step
and a transition with cardinality *. In many other standards (like
UML activity diagrams) there are always two edges between a node
(=ActivityNode in UML) and a transition (=ActivityEdge in
UML) specifying that a transition has exactly two ends (cardinality
of 1 at each edge)?

In the version that we're going to commit a process will have a set
of steps and a set of transitions. A transition wil have a source
step and a target step then in the A step there will be two inverse
relations a relation called sourceTransitions 1.* ( all transition
for which the step is a source step ) and a realtion called
targetTransition ( all transition for whcih the step is target )

How are the conditions at TransitionUnderCondition specified? Are
these boolean conditions connected with AND, OR, XOR and NOT? Or is
this open to each implementation (BPMN, SCA, JBI, etc.)?

The transition under condition will have a "Condition" ( Condition
abstract entity ) where a condition could be an "ExpressionCondition"
( a condition expressed in some language Xpath, groovy, or a
condition on header properties "PropertyCondition".

Do only Transitions have ObservableAttributes? How about attributes
that are specified at a step?

In the actual version of the Intermediate Model we've introduced the
relation between Observable Attribute and Step ( 1..*  each step
could have one or more observable attribute ).

By the way what's important is to clarify the difference between
"ObservableAttribute" and "Property" of a Step.

Properties are information needed to configure the step in a
particular runtime,and the properties set depends by ServiceBinding.
Observable attribute are data that will be extracted when the process will be executed to be visualuzed and monitored, by monitoring tools.

Does a process or a step has no owner, but only a service?

A process is a subclass  of service so process could have owner.
What's important is to make distinct the concept of "Owner" from the
concept of  "Participiant/Actor/Role" as we mean when we talk about
workflow and in general process that require "human task".

At the moment we've not in the model the concept of "Particpiant/
for the support of worflow concept, but in the future we're going to
introduce something about.

Basically ( it's just an idea that we need to discuss with other
) we'll introduce the concept of role, and a subclass of Step entity
( let me say RoleAssignedStep or  HumanTaskStep ) where we model the
relation beteween a step and a role.

For "Owner" instead we mean the provider of a service ( process ) as
it is in service registry ( UDDI ) world.
But this part is not complete yet.

Looking forward to your answers,

Feel free to contact me if you need other information.

Florian Lautenbacher
-JWT project lead-


Hi Florian,

Andrea Zoppello


*Andrea Zoppello*

Spagic Architect

Research & Innovation Division
*Engineering Ingegneria Informatica S.p.A.
Corso Stati Uniti, 23/C - 35127 Padova - Italy
Phone:  +39-049.8692511    Fax:+39-049.8692566

*          *

jwt-dev mailing list

Back to the top