[
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,
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> 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>> 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-
>>> <mailto:jwt-dev->
>>> >> 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>
>>> >>>>
>>> >>>> -----Ursprüngliche Nachricht-----
>>> >>>> Von: Andrea Zoppello [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
>>> >>>>>>
>>> >>>>> Hi Florian,
>>> >>>>>
>>> >>>>
>>> >>>> Hi
>>> >>>> Andrea Zoppello
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>>
>>> >>> *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
>>> >>
>>> >>
>>> > _______________________________________________
>>> > jwt-dev mailing list
>>> >
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
>>>
>>>
>>> _______________________________________________
>>> jwt-dev mailing list
>>> jwt-dev@xxxxxxxxxxx <mailto:
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
>>
>>
>
>
>
--
*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
