Hi,
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.
Fabrice
On 1/8/08, *Andrea Zoppello* <andrea.zoppello@xxxxxx
<mailto:andrea.zoppello@xxxxxx>> wrote:
Hi All,
See comments inline
Marc Dutoo ha scritto:
Hi Adrian, Fabrice
I think by "platform specific" Fabrice means "implementation
specific"
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
component (or
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
on the
metamodel problematic of JWT and STP-IM. Here are my
thoughts about
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
are "implementation"
specific properties.
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
properties"
from "editors" to other "editors or code generator".
The information of which properties are implementation
specific "must
be" in my opinion in the code generation part, and each code
generator
part must use additional configuration ( xml, properties file
or other
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
unit concept,
but there's no property in the steps saying this step
belong to a
service unit, instead the code generator use a specif
configuration
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
share a
"common part" infact the types of "deployable artifact you
must produce
are very different according to the runtime.
For Example : For JBI i must create a zip file with a
prefedefined
strcuture and a configuration file foe each service unit,
instead for
bpel i need to get .bpel file
and so on.
Takink this two eaxmples, it seem very complicated to me to
find a
shared code generation part??
Do you agree??
This would be very useful, in that
* often implementations have bonus features or even
"expected"
features (ex. Bonita XPDL's hooks) whose declaration stray
from the
standard, and that would require specific support in the
transformations and even the common metamodel
* it would ease the development of transformations
targeting the
same format but a different runtime : once one has been
done, at worst
copy & paste it, remove the implementation-specific
properties and
transformation parts, then add the additional right ones.
* it would still provide (by only applying standard-level
properties
and transformation parts) a transformation whose output is fully
standard-compliant (for whatever need, ex. opening in
editors that
require standard compliance, easing migration etc.)
How to do it :
This is easier if there is a strong line between
* standard(format)-specific and
implementation(runtime)-specific
properties ; ex. if those two kind of properties have different
prefixes, if they are documented in two different
subsections. This is
still methodology - unless we add a (non-strict) validation
mechanism.
* and transformation parts, ex. if those two kind of
transformation
parts are declared in different files or classes (XSL, JET,
ATL...),
if they share files or classes for the standard-level part.
This is
rather architecture. Here we should promote their sharing,
but I'm not
sure what would be best : different subprojects or merely a
promoted
transformation architecture (ex. if in XSL, at least two
different XSL
files "jwt2<language>.xsl" and "jwt2<language>-<runtime
implementation>.xsl").
NB. It would obviously be very nice to be able to share
properties and
tranformation parts between transformations targeting the
same format
(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
clearer view
of what can be done and what is useful (validation, 2 level
transformation architecture etc.).
Your thoughts ?
Regards,
Marc Dutoo
Open Wide
Adrian Mos wrote:
Hi Fabrice,
Thanks for your interest in the work around STP-IM. I will
let Andrea
respond about the monitoring part of Spagic. Regarding your
question
on STP-IM, could you elaborate a bit with maybe an example
what you
mean here by platform specific and platform independent
model? I
understand the terminology as defined in MDA but I'd like
to better
grasp your meaning of these terms in the context of the
STP-IM, which
is itself a platform independent metamodel. If by "platform
specific"
you mean the content of the properties containing data
about things
such as JBI and BPEL, do you mean to make a stronger
separation of
such properties from the rest of the model? If this is what
you mean,
could you perhaps make a suggestion of how you'd see this
realised?
Cheers,
Adrian.
On Jan 4, 2008, at 11:14 AM, Fabrice Dewasmes wrote:
Hi all,
I've had the opportunity to assist to a presentation of
Spagic and I
must admit I was very interested by what it covers. I
think that it
could be the missing link between everything when you want
to have
in a top-down SOA approach and already have chosen what
will be your
backend (JBI, Mule, ...). It seems to me that the STP-IM
is a nice
idea and should be able to support very different use
cases with
quite some work.
It's great news that both projects are OK to collaborate.
The switch
from STP-IM to JWT meta-model and vice versa should be
sufficient
for a first step. But for me both projects should work
more closely.
What I find interesting for spagic could be the WAM part
of JWT. As
a matter of fact, Spagic already supports some kind of
deployment
and monitoring but most of it is done through their web
application.
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
this part, it
may be interesting to have the WAM part usable as a RCP
application.
For STP-IM, I haven't looked at how the model is done but
don't you
think it could be interesting to have the platform
specific parts of
the model represented as marks so that those platform
specific
things end up in something like an independant layer that
could be
applied or not on the Platform independant model ?
Fabrice
On Jan 3, 2008 7:15 PM, Marc Dutoo <
marc.dutoo@xxxxxxxxxxx <mailto:marc.dutoo@xxxxxxxxxxx>
<mailto: marc.dutoo@xxxxxxxxxxx
<mailto:marc.dutoo@xxxxxxxxxxx>>> wrote:
Hi Adrian, Florian
What a highly interesting succession of emails !
I'm all the more sorry I couldn't participate to it
(my holidays
would
have hold this against me)
Anyway, thanks for all who did ;)
Nevertheless, it clarifies major elements concerning
STP-IM and its
interactions with JWT, and I personally very much
agree with
everything
that has been said here.
To sum it up, STP-IM properties play the same role as
EAnnotations in
STP BPMN Ed.'s format, i.e. they are to be used to
provide whatever
source format specific information might be useful in
a given
transformation to another target format. This implies
they are
specific
not only to the source or target format, but to the very
transformation
algorithm that is used to transform the one into the
other,
meaning that
"at worst" there is a risk of "noodle plate" or
exponential
property
definitions.
I believe reducing and managing this problem is of the
highest
importance in JWT and in STP-IM as well, as Adrian
proposed in
his last
paragraph : "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...". I
think the answer is a combination of proper guidelines
(ex.
property
naming guidelines) for writing transformations,
overall methodology
(project organisation, documentation) and why not a bit of
architecture
to ease and unify a source or target format's most
recognized and
"mainstream" properties.
Here is what I've thought about for JWT in order to
tackle this
problem
(it may obviously be useful for STP-IM) :
on the side of methodology and tests :
* definition of a set of meaningful (especially
important
because of
the "Business" part in BPM ) samples that cover as
much BPM
features
(XOR, subprocesses...) as possible. Possibly,
definition of "unit
samples", but those would be harder to delineate at a
truly
"unitary" level.
* one dev subproject per transformation, each with
its own
algorithms, and its own version of all default
samples, and more if
required.
* a single common jwt-samples subproject, where are
gathered and
consistently merged samples from as many as possible
transformations.
The idea is to have ex. a single set of BPMN samples,
a single
set of
XPDL samples, a single set of JWT samples, a single
set of BPEL
samples,
and that all transformations (ex. BPMN2JWT, JWT2XPDL,
JWT2BPMN...
including reverse ones) work using the same samples.
* source or target format specific guidelines, along
with the
list of
"officially recognized" properties for this format.
Those are
enriched
by transformation implementors who have a working
transformation
which
doesn't break the existing list and common jwt-samples
or / and in
agreement with implementors of already existing
transformations
using
"officially recognized" properties.
* common guidelines to transforming to and from the
JWT model,
including default advised property / annotation/ ...
naming.
Those are
enriched by format specific guidelines contributors,
with the
assent of
the others. NB. there is no "officially recognized"
properties at
this
level, since it should be the JWT model.
Obviously, those last two should be made available as
public and
up to
date as possible (wiki, web site...).
on the side of architecture :
* extended JWT model using ex. STP BPMN-like
EAnnotations or STP
IM-like properties
* using ATL for transformations (as for now)
I'm also thinking of a mechanism of templating
transformations
* to ease their development, including testing against
"official" samples
* to ease and unify the use of "officially recognized"
properties for
each source and target format (without forbidding to
add others)
I really believe the key to long term success is to at
the same
time
keep a strong consistency within a growing set of core
transformations,
and ease the development of new transformations as
well as their
contributions of new "officially recognized" properties.
Any feedback welcome !
Regards
Marc
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>
<mailto: jwt-dev-bounces@xxxxxxxxxxx
<mailto:jwt-dev-bounces@xxxxxxxxxxx>> [mailto: jwt-dev-
<mailto:jwt-dev->
<mailto: jwt-dev- <mailto:jwt-dev->>
>> bounces@xxxxxxxxxxx <mailto:bounces@xxxxxxxxxxx>
<mailto: bounces@xxxxxxxxxxx <mailto: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
<http://wiki.eclipse.org/images/2/2f/AgilPro_MetamodelDescription.pdf>
<
http://wiki.eclipse.org/images/2/2f/AgilPro_MetamodelDescription.pdf
<http://wiki.eclipse.org/images/2/2f/AgilPro_MetamodelDescription..pdf>>
>>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: Andrea Zoppello [mailto:
andrea.zoppello@xxxxxx <mailto:andrea.zoppello@xxxxxx>
<mailto:andrea.zoppello@xxxxxx
<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
<http://wiki.eclipse.org/STP_Internal_Model_Discussion>
>>>>>>
>>>>> Hi Florian,
>>>>>
>>>>
>>>> Hi
>>>> Andrea Zoppello
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> *Andrea Zoppello*
>>> ___________________________________________
>>> <www.spagoworld.org <http://www.spagoworld.org/> <
http://www.spagoworld.org <http://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 <http://www.eng.it/> <
http://www.eng.it <http://www.eng.it/>>
www.spagoworld.org <http://www.spagoworld.org/> <
http://www.spagoworld.org <http://www.spagoworld.org/>>*
>>>
>>>
>>>
>> _______________________________________________
>> jwt-dev mailing list
>> jwt-dev@xxxxxxxxxxx <mailto:jwt-dev@xxxxxxxxxxx>
<mailto: jwt-dev@xxxxxxxxxxx <mailto:jwt-dev@xxxxxxxxxxx>>
>> https://dev.eclipse.org/mailman/listinfo/jwt-dev
<https://dev.eclipse.org/mailman/listinfo/jwt-dev>
>>
>>
> _______________________________________________
> jwt-dev mailing list
> jwt-dev@xxxxxxxxxxx <mailto:jwt-dev@xxxxxxxxxxx>
<mailto:jwt-dev@xxxxxxxxxxx <mailto:jwt-dev@xxxxxxxxxxx>>
> https://dev.eclipse.org/mailman/listinfo/jwt-dev
<https://dev.eclipse.org/mailman/listinfo/jwt-dev>
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
<mailto:jwt-dev@xxxxxxxxxxx><mailto:jwt-dev@xxxxxxxxxxx
<mailto:jwt-dev@xxxxxxxxxxx>>
https://dev.eclipse.org/mailman/listinfo/jwt-dev
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx <mailto:jwt-dev@xxxxxxxxxxx> <mailto:
jwt-dev@xxxxxxxxxxx <mailto:jwt-dev@xxxxxxxxxxx>>
https://dev.eclipse.org/mailman/listinfo/jwt-dev
------------------------------------------------------------------------
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx <mailto:jwt-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/jwt-dev
--
*Andrea Zoppello*
___________________________________________
< www.spagoworld.org <http://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 <http://www.eng.it/>
www.spagoworld.org <http://www.spagoworld.org/>*
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx <mailto:jwt-dev@xxxxxxxxxxx>
https://dev.eclipse..org/mailman/listinfo/jwt-dev
<https://dev.eclipse.org/mailman/listinfo/jwt-dev>
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx <mailto:jwt-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/jwt-dev
