Marc, I must admit you have perfectly expressed my thoughts about
all this. My main concern is really to get things clearly
separated between a common independant representation and
implementation specific details. We should be able to go back and
forth between these two representation *if possible* (as I know
it is sometimes not achievable or even not recommandable).
I understand the point of view of Andrea and undestand the
difficulty he tries to address. But my feeling is that things are
a little bit mixed together. I have to get deeper in this to
clear my mind about this.
On 1/8/08, *Andrea Zoppello* <andrea.zoppello@xxxxxx
See comments inline
Marc Dutoo ha scritto:
Hi Adrian, Fabrice
I think by "platform specific" Fabrice means "implementation
in contrast to "standard". In the case of a Bonita XPDL
file, it would
be hooks ; in case of a JBI component's jbi.xml, it would be the
extended information that is specific to this particular
underlaying ESB implementation). And his mean to achieve
this would be
"marks", i.e. annotations I guess.
I actually didn't stress enough the difference between
standard(format)-specific and implementation(runtime)-specific
properties and transformation parts, because I was focusing
metamodel problematic of JWT and STP-IM. Here are my
it, they extend the "Architecture side / templating and
reuse" part of
my previous email.
I really think that in the IM we should keep properties
generic, so to
avoid discussion on which are "standard" and which
I think we should not make the error trying to define another
"common-model", in my opinion the IM is useful beacuse it's very
generic, and specific details are
not there, but in the "code generators" or "specific editors".
I think that Intermediate Model, "must ensure" to "transport
from "editors" to other "editors or code generator".
The information of which properties are implementation
be" in my opinion in the code generation part, and each code
part must use additional configuration ( xml, properties file
specific editor to add specific properties ) to generate what a
particular technology need.
The code generator could simply ignore the step properties
that are not
interesting for a particular runtime.
For example in JBI a very important concept is the service
but there's no property in the steps saying this step belong to a
service unit, instead the code generator use a specif
section that map a ( Service/ServiceBinding couple ) to
service unit and
use this information for JBI, but this does not affect the IM.
About the transformation in my opinion is very difficult to
"common part" infact the types of "deployable artifact you
are very different according to the runtime.
For Example : For JBI i must create a zip file with a
strcuture and a configuration file foe each service unit,
bpel i need to get .bpel file
and so on.
Takink this two eaxmples, it seem very complicated to me to
shared code generation part??
Do you agree??
This would be very useful, in that
* often implementations have bonus features or even
features (ex. Bonita XPDL's hooks) whose declaration stray
standard, and that would require specific support in the
transformations and even the common metamodel
* it would ease the development of transformations
same format but a different runtime : once one has been
done, at worst
copy & paste it, remove the implementation-specific
transformation parts, then add the additional right ones.
* it would still provide (by only applying standard-level
and transformation parts) a transformation whose output is fully
standard-compliant (for whatever need, ex. opening in
require standard compliance, easing migration etc.)
How to do it :
This is easier if there is a strong line between
* standard(format)-specific and
subsections. This is
properties ; ex. if those two kind of properties have different
prefixes, if they are documented in two different
still methodology - unless we add a (non-strict) validation
* and transformation parts, ex. if those two kind of
parts are declared in different files or classes (XSL, JET,
if they share files or classes for the standard-level part.
rather architecture. Here we should promote their sharing,
but I'm not
sure what would be best : different subprojects or merely a
transformation architecture (ex. if in XSL, at least two
files "jwt2<language>.xsl" and "jwt2<language>-<runtime
NB. It would obviously be very nice to be able to share
tranformation parts between transformations targeting the
(but not the same runtime), but this is not guaranteed out
of the box
and may require some refactoring work in both.
My 2 cents... I admit I'll have to do one first to have a
of what can be done and what is useful (validation, 2 level
transformation architecture etc.).
Your thoughts ?
Adrian Mos wrote:
Thanks for your interest in the work around STP-IM. I will
respond about the monitoring part of Spagic. Regarding your
on STP-IM, could you elaborate a bit with maybe an example
mean here by platform specific and platform independent
understand the terminology as defined in MDA but I'd like
grasp your meaning of these terms in the context of the
is itself a platform independent metamodel. If by "platform
you mean the content of the properties containing data
such as JBI and BPEL, do you mean to make a stronger
such properties from the rest of the model? If this is what
could you perhaps make a suggestion of how you'd see this
Spagic and I
On Jan 4, 2008, at 11:14 AM, Fabrice Dewasmes wrote:
I've had the opportunity to assist to a presentation of
think that it
must admit I was very interested by what it covers. I
could be the missing link between everything when you want
will be your
in a top-down SOA approach and already have chosen what
is a nice
backend (JBI, Mule, ...). It seems to me that the STP-IM
idea and should be able to support very different use
quite some work.
It's great news that both projects are OK to collaborate.
from STP-IM to JWT meta-model and vice versa should be
for a first step. But for me both projects should work
of JWT. As
What I find interesting for spagic could be the WAM part
a matter of fact, Spagic already supports some kind of
and monitoring but most of it is done through their web
this part, it
Could be interesting to be able to :
* deploy and debug step by step the processes
* do the monitoring using a tool like Eclipse. And for
may be interesting to have the WAM part usable as a RCP
For STP-IM, I haven't looked at how the model is done but
specific parts of
think it could be interesting to have the platform
the model represented as marks so that those platform
things end up in something like an independant layer that
applied or not on the Platform independant model ?
On Jan 3, 2008 7:15 PM, Marc Dutoo <
Hi Adrian, Florian
What a highly interesting succession of emails !
I'm all the more sorry I couldn't participate to it
STP-IM and its
have hold this against me)
Anyway, thanks for all who did ;)
Nevertheless, it clarifies major elements concerning
interactions with JWT, and I personally very much
that has been said here.
To sum it up, STP-IM properties play the same role as
STP BPMN Ed.'s format, i.e. they are to be used to
source format specific information might be useful in
transformation to another target format. This implies
not only to the source or target format, but to the very
algorithm that is used to transform the one into the
"at worst" there is a risk of "noodle plate" or
I believe reducing and managing this problem is of the
importance in JWT and in STP-IM as well, as Adrian
paragraph : "It might be a good idea to properly
the properties that are used in different
people can easily use them when adding other
think the answer is a combination of proper guidelines
naming guidelines) for writing transformations,
(project organisation, documentation) and why not a bit of
to ease and unify a source or target format's most
Here is what I've thought about for JWT in order to
(it may obviously be useful for STP-IM) :
on the side of methodology and tests :
* definition of a set of meaningful (especially
the "Business" part in BPM ) samples that cover as
definition of "unit
(XOR, subprocesses...) as possible. Possibly,
samples", but those would be harder to delineate at a
* one dev subproject per transformation, each with
samples, and more if
algorithms, and its own version of all default
* a single common jwt-samples subproject, where are
consistently merged samples from as many as possible
The idea is to have ex. a single set of BPMN samples,
set of BPEL
XPDL samples, a single set of JWT samples, a single
and that all transformations (ex. BPMN2JWT, JWT2XPDL,
including reverse ones) work using the same samples.
* source or target format specific guidelines, along
"officially recognized" properties for this format.
by transformation implementors who have a working
or / and in
doesn't break the existing list and common jwt-samples
agreement with implementors of already existing
"officially recognized" properties.
* common guidelines to transforming to and from the
including default advised property / annotation/ ...
enriched by format specific guidelines contributors,
the others. NB. there is no "officially recognized"
level, since it should be the JWT model.
Obviously, those last two should be made available as
EAnnotations or STP
date as possible (wiki, web site...).
on the side of architecture :
* extended JWT model using ex. STP BPMN-like
* using ATL for transformations (as for now)
I'm also thinking of a mechanism of templating
* to ease their development, including testing against
* to ease and unify the use of "officially recognized"
each source and target format (without forbidding to
I really believe the key to long term success is to at
well as their
keep a strong consistency within a growing set of core
and ease the development of new transformations as
model is not just
contributions of new "officially recognized" properties.
Any feedback welcome !
Adrian Mos wrote:
> Hi Florian,
> You are right in thinking that the intermediate
ServiceMix in two
> used for one transformation between BPMN and
> It is a generic means of moving information between
> and platforms and currently we have the support for
> between BPMN, BPEL and ServiceMix.
> The question you are raising about the generality of
how if the
> definitions is a good one. Basically you are asking
> is generic, can you define things that all downstream
> can understand. The simple answer is, somebody must
target. The IM
> with the shared understanding of the needs of the
> ALLOWS the definition of properties with specific
This is the
> not specify the semantics of each set of properties.
> price for generality, you can't have a model that
to provide the
> and specific at the same time, and we didn't want
metamodels in the IM.
> union of all the elements of the supported
> So, somehow, the information about how to map
useful in a
> JBI (for example) must be put in the IM. And here is the
> made: the concepts that are general enough to be
> of situations (such as binding, or step, or service)
> represented as elements in the IM. The other concepts,
> one technology or editor, are injected using the
This is a
> have rightly noticed, from the BPMN editor we already
> properties needed to go from BPMN to JBI or BPEL.
> that allows very good integration of editors using
> points of BPMN and the IM. Since all the information
> put in the properties directly from the BPMN editor,
> directly generate JBI. However for BPEL, some
editor must be
> be added using the BPEL editor, which is why this
> opened and used before being able to completely
> executable BPEL (Andrea correct me if I'm wrong here).
> So you already see two approaches for putting
> generic enough) information in the IM, needed for
> transformations. One is by directly defining the
information in the
> source editor, the other by adding specific
> editor. You can also imagine using an intermediate
use BPMN to
> when generating SCA deployable artefacts. You can
> describe a process, open the SCA editor to add and
> specific information and finally generate the
properties that can
> So, while the IM allows the definition of
this is of
> different semantics under different contexts, it only
> some elements, the ones deemed generic enough (and
generic set to
> work in progress as we'll keep improving this
semantics of the
> correspond to the needs of STP). Again, the
> properties is in the hands of the transformation
> that specify how to move to and from the IM and
> It might be a good idea to properly document and
transformations. This way,
> properties that are used in different
> people can easily use them when adding other
> result in artefacts generated for editors already having
> transformations (to or from the IM). This and
to/from the IM are
> description of the way to add transformations
> important for the understanding and adoption of the
> done as soon as possible.
> Hope this clarifies things a bit...
> Happy New Year! :)
> On Dec 28, 2007, at 10:29 AM, Florian Lautenbacher
IM. Yes, we
>> Hi Adrian, hi Andrea,
>> thanks a lot for the clarification about the STP
>> looking forward to work with you. Currently we have
>> transformations between BPMN and JWT resp. XPDL and
mapping STP IM
>> that is
>> finished we are looking forward to work on a
>> One last question: you say that STP IM is a
>> model as I understand it), so I only need
But how do
>> BPMN to
>> STP IM and from there to e.g. ServiceMix Assembly.
>> that my
>> first transformation from BPMN to STP IM needs to
>> such as "interface", "method call" or "participant"
>> transformations (to ServiceMix, to BPEL, to XPDL,
>> where to look for? Adrian said that STP IM could be
>> "intersection" between other relevant standards..
convention for the
>> good! But
>> then there needs to be a mechanism or naming
>> and added properties, every transformation should
(from BPMN to
>> stick to
>> in order to have several model transformations
>> JWT to STP IM, from STP IM to BPEL, from STP IM to
>> working after
>> each other, am I right?
>> Or is the "transporter model" thought of as a model
>> transformation from BPMN to ServiceMix, but this
transformation has two
>> steps inside!? But what would be the use of such a
2008 to all
>> model? So I
>> don't think its like that.
>> Thanks for this last answer and a happy new year
>> Best regards,
>> -----Ursprüngliche Nachricht-----
>> Von: jwt-dev-bounces@xxxxxxxxxxx
<mailto:jwt-dev-bounces@xxxxxxxxxxx>> [mailto: jwt-dev-
<mailto: bounces@xxxxxxxxxxx <mailto:bounces@xxxxxxxxxxx>>] Im
<mailto: jwt-dev- <mailto:jwt-dev->>
>> bounces@xxxxxxxxxxx <mailto:bounces@xxxxxxxxxxx>
questions, so I
>> 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
transformations you can
>> want to
>> say that if you're looking for help with
>> count on us. So if you have any questions about
>> elements from
>> JWT to STP-IM or the other way around, feel free to
>> the STP
>> mailing list, you'll get an answer quickly.
>> Also, to follow up on what Andrea said and what I
to bridge the
>> STP-IM is a generic "transporter" model, intended
>> variety of
>> SOA editors in STP. So, the semantics of properties
going to use
>> can differ based on the transformation that is
>> The idea
>> is that we do not try to offer all the semantics in
>> just the
>> means to attach it, so that we can keep a high level of
>> still preserving the most important SOA concepts as
>> Looking forward to working with you guys, Best
>> 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
SVN and it
>>>> I now had a closer look at the metamodel in your
on your web
is (in my
>>>> much better designed than the one that is shown
>>>> In fact
>>>> the core concepts are very similar to the core
>>>> (which can be found on ). In STP IM you got a
a name, a
>>>> contains * Steps and * Transitions. Each step has
>>>> description, a number of sourceTransitions and
>>>> well as several observableAttributes. You also got
>>>> with subclasses like SplitControl or JoinControl.
>>>> Transitions or TransitionsUnderCondition. And
>>>> a configurable
>>>> Now looking at the JWT metamodel it is very much
>>>> everything is a ModelElement. There are
target, in and
>>>> connected via ActivityEdges (using source,
>>>> same cardinality as sourceTransitions,
etc. in STP
>>>> IM). There can be several types of ActivityNodes:
>>>> Action (probably a Step in
>>>> IM) or it
>>>> could be a ControlNode such as a ForkNode or a
>>>> ActivityEdge might have a Guard (making it a
>>>> "TransitionUnderCondition") whereas the Guard is
>>>> GuardSpecification (with only a proprietary
>>>> Regarding your description of Properties and
>>>> guess that data that is necessary for execution
>>>> been added to BPMN and shall be transformed into
>>>> as a property to the relevant step, am I right?
>>> For example for a Step that is configured
>>> ServiceBinding [HTTP-InputBindingComponent] the
step will have
>>> driven by the HTTP-InputBindingComponet, So the
>>> properties like:
>>> and so on.
>>> Quite different is the concept of relevant data:
>>> Relevant data are extracted when the process is
the case of
>>> expression on messages ( exchanged by endpoint in
extracted by /RECORD/
Jbi ) or
>>> variable in the case of ( BPEL).
>>> An example of relevant data is customerID
attribute. Yes, I
>>> Thanks for clarification about the owner
>>>> about a participant or role than about an owner.
added as a
data ( e.g.
>>>> which is
>>>> available in a swimlane or pool in BPMN) then
>>>> right now to each Step?
>>> As i say in previous post we'e not yet provided in
editor in two
>>> intermediate model the concept of participiant role.
>>> BTW i think that we could support this in BPMN
>>> 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
in the im
anbd drop on
>>> the activities
>>> We cannot use the BPMN pool concept beacuse a pool
>>> in to a process.
>>>> I agree with Adrian and Marc that a first step
>>>> transformation from JWT to STP IM (and the other
>>>> However, since
>>>> the metamodels are quite similar, this should not
hard. Here at
>>>> JWT we need to discuss who will be responsible
>>>> 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
>>>> from one metamodel in a way that it is clear in a
owner of a
>>>> step where it should go. So, if I specify the
kept in STP IM
step in a
>>>> pool or lane in BPMN, how is this information
so I can
>>>> work with that when generating e..g. BPEL or
>>>> need some predefined values as properties that
>>>> transformations use!? Or will there be a query
(such as RQL
>>>> or SPARQL) where you can find the "semantics" of
>>>> Best regards and looking forward to some more
>>> Intermediate Model is a very generic model so you
the step )
>>> situations where some properties ( for example of
be need by
>>> important by code generator A and others will
in a very
>>> generator B.
>>> The concept is that IM bring you the information
>>> way, than is responsibility of specific code
>>> that information in something executable.
>>> To bring you an example, now i'm working in generating
>>> service assembly applications from intermediate
>>> codegenerator plugins that knows ( for example how to
>>> units, how to make cfg files and so on .... ).
>>> I don't know if it's clear, if you've some doubt
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: Andrea Zoppello [mailto:
>>>> 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
>>>> See comments inline
>>>> Adrian Skehill ha scritto:
>>>>> Florian Lautenbacher wrote:
>>>>>> I am wondering what the current state of the STP
>>>>>> is? Is the version on the Wiki  up to date?
>>>> I think version on the wiki is not updated. The
process, but the
>>>> going to commit will be the really the first version.
>>>>>> If so, I am curious why a step is part of a
>>>>>> transition is not?
>>>>>> And, on the other hand, why there is only one
>>>>>> and a transition with cardinality *. In many other
>>>>>> UML activity diagrams) there are always two
>>>>>> (=ActivityNode in UML) and a transition
>>>>>> UML) specifying that a transition has exactly
>>>>>> of 1 at each edge)?
>>>> In the version that we're going to commit a
wil have a
have a set
>>>> of steps and a set of transitions. A transition
>>>> step and a target step then in the A step there
>>>> relations a relation called sourceTransitions 1.*
>>>> for which the step is a source step ) and a
>>>> targetTransition ( all transition for whcih the
OR, XOR and
>>>>>> How are the conditions at TransitionUnderCondition
>>>>>> these boolean conditions connected with AND,
NOT? Or is
>>>>>> this open to each implementation (BPMN, SCA,
>>>> The transition under condition will have a
groovy, or a
>>>> abstract entity ) where a condition could be an
>>>> ( a condition expressed in some language Xpath,
>>>> condition on header properties "PropertyCondition".
>>>>>> Do only Transitions have ObservableAttributes?
>>>>>> that are specified at a step?
>>>> In the actual version of the Intermediate Model we've
>>>> relation between Observable Attribute and Step (
>>>> could have one or more observable attribute ).
>>>> By the way what's important is to clarify the
the step in a
>>>> "ObservableAttribute" and "Property" of a Step.
>>>> Properties are information needed to configure
>>>> particular runtime,and the properties set depends by
>>>> Observable attribute are data that will be
>>>> will be executed to be visualuzed and monitored, by
>>>>>> Does a process or a step has no owner, but only
>>>> A process is a subclass of service so process
>>>> What's important is to make distinct the concept
>>>> concept of "Participiant/Actor/Role" as we mean
>>>> workflow and in general process that require
>>>> At the moment we've not in the model the concept of
>>>> for the support of worflow concept, but in the
>>>> introduce something about.
>>>> Basically ( it's just an idea that we need to
>>>> ) we'll introduce the concept of role, and a
>>>> ( let me say RoleAssignedStep or HumanTaskStep )
>>>> relation beteween a step and a role.
>>>> For "Owner" instead we mean the provider of a
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
>>>>>> Florian Lautenbacher
>>>>>> -JWT project lead-
>>>>> Hi Florian,
>>>> Andrea Zoppello
>>> *Andrea Zoppello*
>>> <www.spagoworld.org <http://www.spagoworld.org/> <
>>> 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
>>> * www.eng.it <http://www.eng.it/> <
www.spagoworld.org <http://www.spagoworld.org/> <
<mailto: jwt-dev@xxxxxxxxxxx <mailto:jwt-dev@xxxxxxxxxxx>>
>> jwt-dev mailing list
>> jwt-dev@xxxxxxxxxxx <mailto:jwt-dev@xxxxxxxxxxx>
> jwt-dev mailing list
> jwt-dev@xxxxxxxxxxx <mailto:jwt-dev@xxxxxxxxxxx>
jwt-dev mailing list
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx <mailto:jwt-dev@xxxxxxxxxxx> <mailto:
jwt-dev mailing list
< www.spagoworld.org <http://www.spagoworld.org/>>
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
jwt-dev mailing list