Adrian Mos wrote:
> 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! :)
> Adrian.
>
> 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,
>>
>> Florian
>>
>> -----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]
>>>>
http://wiki.eclipse.org/images/2/2f/AgilPro_MetamodelDescription.pdf
>>>>
>>>> -----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]
http://wiki.eclipse.org/STP_Internal_Model_Discussion>>>>>>
>>>>> Hi Florian,
>>>>>
>>>>
>>>> Hi
>>>> Andrea Zoppello
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> *Andrea Zoppello*
>>> ___________________________________________
>>> <
www.spagoworld.org>
>>>
>>> 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
>>>
>>> *
www.eng.it www.spagoworld.org*
>>>
>>>
>>>
>> _______________________________________________
>> jwt-dev mailing list
>>
jwt-dev@xxxxxxxxxxx>>
https://dev.eclipse.org/mailman/listinfo/jwt-dev>>
>>
> _______________________________________________
> jwt-dev mailing list
>
jwt-dev@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/jwt-dev_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/jwt-dev