[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 Andrea

OK, it's clearer now ^^
I guess how hard it is to share parts of the transformation depends on what's shared in the output (admittedly not much in case of a custom component's jbi.xml) and on the transformation technology of choice.


I don't know how hard this "share and reuse part" might be with ATL. Stephane, any idea ?

Now, going on with this interesting example, without being an STP-IM or JET expert - and I'm sure you've already done tons of things like this, why couldn't you do it with JET this way :

in jbi.xmljet :

<jbi version="1.0"
xmlns="http://java.sun.com/xml/ns/jbi";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:petals="http://petals.objectweb.org/";
xmlns:extensions="http://petals.objectweb.org/extensions";>
<services binding-component="false">
<provides interface-name="p<%=$service/serviceType%>"
service-name="<%=$service/serviceName%>"
endpoint-name="<%=$service/endpoints[0]/URI%>">
<c:if test="$service/properties['engineType'] = 'petals__xslt'">
<c:include template="templates/petals/xslt.jet" passVariables="$service"/>
</c:if>
<c:if test="$service/properties['engineType'] = 'petals__groovy'">
<c:include template="templates/petals/groovy.jet" passVariables="$service"/>
</c:if>
</provides>
</services>
</jbi>


and in petals__xslt.jet :

<extensions:params>
<extensions:param name="xsl"><%=$service/properties['xslt__filename']%></extensions:param>
</extensions:params>


Now jbi.xmljet is quite "generic", while petals__xslt.jet is specific to the xslt component provided by the petals ESB.

Notice the "template/petals" subdirectory of templates specific to JBI components provided by the petals JBI implementation ESB.

Notice also that the xsl file is provided by a property without "petals" in its name, because the same should (has been recognized / published in order to) be used by transformations to other implementations (ex. serviceMix XSLT component)'s jbi.xml .

Regards
Marc

Andrea Zoppello wrote:

Hi,

See the comment inline about the example.
Marc Dutoo ha scritto:

Hi

Andrea, I mostly agree ^^ Actually, none of my pieces of advice require to change or enhance the STP-IM - as you say, it is fine and the most useful because of its genericity. By the way we discussed with Florian that JWT would need the same kind of generic, annotation-driven extensibility.

Adrian, you pretty much summed my thoughts up : "I think that with proper architecture of the transformers (generators) we can make this separation clear and we can also encourage reuse."

Fabrice, glad I was in line, I also think we have now to dirty our hands to see how the "manage, share and reuse" part might be usefully done.

Andrea, about your example : what I'm saying is, were I to develop a transformation from a STP-IM Service to an XSL SE JBI ServiceUnit, and another one from a STP-IM Service to a Script SE JBI ServiceUnit, I'd for example use JET and would share the generic transformation parts ex. generation of the Provide elements. That might be also useful for other STP-IM to JBI transformation developers who chose to use the JET technology, and that will avoid a throng of copy-pasted JET templates parts that does the same thing. Note that generic STP-IM property translation (i.e. translating all of them along some naming guidelines, regardless whether they are required by the target format or not) should also help avoiding too many specific transformation parts, at least in the way <language> to STP-IM or JWT.

Just to explain:

Suppose we've a very simple process StartStep--->TaskStep--->EndStep, and as your example TaskStep is a Transformation that could be implemented as for
example with XSLT Transformation, or with a Groovy Script transformation ok???


What you've actually have in the Intermediate Model, is a process like:

1) First Use Case ( Use XSLT SE )
StartStep ( where Service: StartService, ServiceBinding HTTPBindingComponent )
TaskStep( where Service: TransformationService, ServiceBinding XSLT Service Engine )
EndStep ( where Service: EndService, ServiceBinding ConsoleService )


2) Second Use Case ( Use Groovy SE )
StartStep ( where Service: StartService, ServiceBinding HTTPBindingComponent )
TaskStep( where Service: TransformationService, ServiceBinding Groovy Service Engine )
EndStrp ( where Service: EndService, ServiceBinding ConsoleService )


What to notice is that in both use case the Service is the same, what's really changing is the ServiceBinding, that in JBI code generator will drive the
code generator part ).


What i think it's that is very difficult to share, the same JET file beacuse the configuration section need to be produced are quite different that's all
Hope now, is more clear.


Andrea


As you say, there's however little to be shared in other cases, like between transformations targeting JBI and BPEL.


Regards,
Marc

Fabrice Dewasmes wrote:

Hi adrian,
the goals are a bit more clear for me. I agree with you, Adrian, when you say that it will be a bit more clear once things will be started.
regards,
Fabrice


On 1/8/08, *Adrian Mos* <adrian.mos@xxxxxxxx <mailto:adrian.mos@xxxxxxxx>> wrote:

    Hi guys,

So now I understand what Fabrice meant by implementation-specific
and platform-independent. However, given the purpose and scope of
the STP-IM, I fully agree with Andrea that we should leave
properties as generic as possible and put the semantics into the
transformation logic. I understand that this may seem like some
things are mixed up a bit, in that there is no obvious separation
between different standards and different implementations when
looking at a model instance. However, I think that with proper
architecture of the transformers (generators) we can make this
separation clear and we can also encourage reuse.


I must emphasise again that the STP-IM aims to unify different SOA
editors and platforms in STP with a very pragmatic approach, and
not define a conceptual meta-model for all things SOA. Another
important factor for STP-IM is also simplicity in order to
guarantee adoption. In a way this probably differs from the
approach taken in JWT which aims to provide a coherent and
conceptual superset for all things "process in the SOA world" if
you don't mind this gross simplification :) This difference
between the two actually highlights the interest in bridging them
together :)


I think that once we start working on the transformations between
JWT and STP-IM, we'll hopefully see things a bit more clear and we
can better realise what lacks in the models.


         Cheers,
    Adrian.

    On Jan 8, 2008, at 1:06 PM, Fabrice Dewasmes wrote:

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



_______________________________________________ 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



_______________________________________________ jwt-dev mailing list jwt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/jwt-dev