Skip to main content

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

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:

> Hi,
> 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
>> opinion)
>> 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
>> element.
>> 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?
> Yes.
> 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:
> URL:
> isSoap:
> 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/ 
> @customerId
> Thanks for clarification about the owner attribute. Yes, I was more 
> thinking
>> 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,
>> Florian
> 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.
> Regards
> Andrea
>> [1] 
>> -----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?
>> Hi,
>> Sorry for the late response but i'm just come back from Javapolis.
>> See comments inline
>> Adrian Skehill ha scritto:
>>> Florian Lautenbacher wrote:
>>>> Hi,
>>>> 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/ 
>> Actor/Role"
>> 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 
>> members
>> ) 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-
>>>> [1]
>>> Hi Florian,
>> Hi
>> Andrea Zoppello
> --
> *Andrea Zoppello*
> ___________________________________________
> <>
> Spagic Architect
> ___________________________________________
> 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