|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/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:HiAndrea, 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 thecode 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 allHope now, is more clear. AndreaAs 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, FabriceOn 1/8/08, *Adrian Mos* <adrian.mos@xxxxxxxx <mailto:adrian.mos@xxxxxxxx>> wrote:Hi guys,So now I understand what Fabrice meant by implementation-specificand 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 SOAeditors 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 betweenJWT 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 aboutall 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 "implementationspecific"in contrast to "standard". In the case of a Bonita XPDLfile, it wouldbe hooks ; in case of a JBI component's jbi.xml, it would be the extended information that is specific to this particularcomponent (orunderlaying ESB implementation). And his mean to achievethis 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 focusingon themetamodel problematic of JWT and STP-IM. Here are mythoughts aboutit, they extend the "Architecture side / templating andreuse" part ofmy 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 verygeneric, 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 otherspecific editor to add specific properties ) to generate what aparticular 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 aservice 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 strayfrom thestandard, and that would require specific support in the transformations and even the common metamodel * it would ease the development of transformationstargeting thesame format but a different runtime : once one has beendone, at worstcopy & paste it, remove the implementation-specificproperties andtransformation parts, then add the additional right ones. * it would still provide (by only applying standard-levelpropertiesand transformation parts) a transformation whose output is fully standard-compliant (for whatever need, ex. opening ineditors thatrequire standard compliance, easing migration etc.) How to do it : This is easier if there is a strong line between * standard(format)-specific andimplementation(runtime)-specificproperties ; ex. if those two kind of properties have different prefixes, if they are documented in two differentsubsections. This isstill methodology - unless we add a (non-strict) validationmechanism.* and transformation parts, ex. if those two kind oftransformationparts are declared in different files or classes (XSL, JET,ATL...),if they share files or classes for the standard-level part.This israther architecture. Here we should promote their sharing,but I'm notsure what would be best : different subprojects or merely apromotedtransformation architecture (ex. if in XSL, at least twodifferent XSLfiles "jwt2<language>.xsl" and "jwt2<language>-<runtime implementation>.xsl"). NB. It would obviously be very nice to be able to shareproperties andtranformation parts between transformations targeting thesame format(but not the same runtime), but this is not guaranteed outof the boxand may require some refactoring work in both. My 2 cents... I admit I'll have to do one first to have aclearer viewof 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 willlet Andrearespond about the monitoring part of Spagic. Regarding yourquestionon STP-IM, could you elaborate a bit with maybe an examplewhat youmean here by platform specific and platform independentmodel? Iunderstand the terminology as defined in MDA but I'd liketo bettergrasp your meaning of these terms in the context of theSTP-IM, whichis itself a platform independent metamodel. If by "platformspecific"you mean the content of the properties containing dataabout thingssuch as JBI and BPEL, do you mean to make a strongerseparation ofsuch properties from the rest of the model? If this is whatyou mean,could you perhaps make a suggestion of how you'd see thisrealised?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 ofSpagic and Imust admit I was very interested by what it covers. Ithink that itcould be the missing link between everything when you wantto havein a top-down SOA approach and already have chosen whatwill be yourbackend (JBI, Mule, ...). It seems to me that the STP-IMis a niceidea and should be able to support very different usecases withquite some work. It's great news that both projects are OK to collaborate.The switchfrom STP-IM to JWT meta-model and vice versa should besufficientfor a first step. But for me both projects should workmore closely.What I find interesting for spagic could be the WAM partof JWT. Asa matter of fact, Spagic already supports some kind ofdeploymentand monitoring but most of it is done through their webapplication.Could be interesting to be able to : * deploy and debug step by step the processes * do the monitoring using a tool like Eclipse. And forthis part, itmay be interesting to have the WAM part usable as a RCPapplication.For STP-IM, I haven't looked at how the model is done butdon't youthink it could be interesting to have the platformspecific parts ofthe model represented as marks so that those platformspecificthings end up in something like an independant layer thatcould beapplied 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 holidayswould have hold this against me) Anyway, thanks for all who did ;) Nevertheless, it clarifies major elements concerningSTP-IM and itsinteractions with JWT, and I personally very muchagree witheverything 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 toprovide whateversource format specific information might be useful ina giventransformation to another target format. This impliesthey arespecific not only to the source or target format, but to the very transformation algorithm that is used to transform the one into theother,meaning that "at worst" there is a risk of "noodle plate" orexponentialproperty definitions. I believe reducing and managing this problem is of thehighestimportance in JWT and in STP-IM as well, as Adrianproposed inhis last paragraph : "It might be a good idea to properlydocument andclassify the properties that are used in differenttransformations. Thisway, people can easily use them when adding othertransformations...". Ithink 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 mostrecognized and"mainstream" properties. Here is what I've thought about for JWT in order totackle thisproblem (it may obviously be useful for STP-IM) : on the side of methodology and tests : * definition of a set of meaningful (especiallyimportantbecause of the "Business" part in BPM ) samples that cover asmuch BPMfeatures (XOR, subprocesses...) as possible. Possibly,definition of "unitsamples", but those would be harder to delineate at atruly"unitary" level. * one dev subproject per transformation, each withits ownalgorithms, and its own version of all defaultsamples, and more ifrequired. * a single common jwt-samples subproject, where aregathered andconsistently merged samples from as many as possible transformations. The idea is to have ex. a single set of BPMN samples,a singleset of XPDL samples, a single set of JWT samples, a singleset of BPELsamples, and that all transformations (ex. BPMN2JWT, JWT2XPDL,JWT2BPMN...including reverse ones) work using the same samples. * source or target format specific guidelines, alongwith thelist of "officially recognized" properties for this format.Those areenriched by transformation implementors who have a workingtransformationwhich doesn't break the existing list and common jwt-samplesor / and inagreement with implementors of already existingtransformationsusing "officially recognized" properties. * common guidelines to transforming to and from theJWT model,including default advised property / annotation/ ...naming.Those are enriched by format specific guidelines contributors,with theassent of the others. NB. there is no "officially recognized"properties atthis level, since it should be the JWT model. Obviously, those last two should be made available aspublic andup to date as possible (wiki, web site...). on the side of architecture : * extended JWT model using ex. STP BPMN-likeEAnnotations or STPIM-like properties * using ATL for transformations (as for now) I'm also thinking of a mechanism of templatingtransformations* 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 toadd others)I really believe the key to long term success is to atthe sametime keep a strong consistency within a growing set of core transformations, and ease the development of new transformations aswell as theircontributions of new "officially recognized" properties. Any feedback welcome ! Regards Marc Adrian Mos wrote: > Hi Florian, > > You are right in thinking that the intermediatemodel is not just> used for one transformation between BPMN andServiceMix in twosteps. > It is a generic means of moving information betweendifferenteditors > and platforms and currently we have the support for transformations > between BPMN, BPEL and ServiceMix. > > The question you are raising about the generality ofproperty> definitions is a good one. Basically you are askinghow if themodel > is generic, can you define things that all downstream transformations > can understand. The simple answer is, somebody mustput themthere > with the shared understanding of the needs of thetarget. The IM> ALLOWS the definition of properties with specificsemantics butdoes > not specify the semantics of each set of properties.This is the> price for generality, you can't have a model thatis bothgeneric > and specific at the same time, and we didn't wantto provide the> union of all the elements of the supportedmetamodels in the IM.> > So, somehow, the information about how to mapconcepts fromBPMN to > JBI (for example) must be put in the IM. And here is the choice we > made: the concepts that are general enough to beuseful in avariety > 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 theproperties.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 achoice > that allows very good integration of editors usingstandardextension > points of BPMN and the IM. Since all the informationfor JBIcan be > put in the properties directly from the BPMN editor,we areable to > directly generate JBI. However for BPEL, someinformation muststill > be added using the BPEL editor, which is why thiseditor must be> opened and used before being able to completelygenerate the> executable BPEL (Andrea correct me if I'm wrong here). > > So you already see two approaches for puttingnon-standard(i.e. non > generic enough) information in the IM, needed forparticular> transformations. One is by directly defining thepropertiesfrom the > source editor, the other by adding specificinformation in thetarget > editor. You can also imagine using an intermediateeditor forexample > when generating SCA deployable artefacts. You canuse BPMN to> describe a process, open the SCA editor to add andmodify SCA> specific information and finally generate therunning SCAartefacts. > So, while the IM allows the definition ofproperties that canhave > different semantics under different contexts, it only standardises > some elements, the ones deemed generic enough (andthis is ofcourse > work in progress as we'll keep improving thisgeneric set to> correspond to the needs of STP). Again, thesemantics of the> properties is in the hands of the transformationdevelopers,the ones > that specify how to move to and from the IM anddifferenteditors. > > It might be a good idea to properly document andclassify the> properties that are used in differenttransformations. This way,> people can easily use them when adding othertransformationsthat can > result in artefacts generated for editors already having > transformations (to or from the IM). This andespecially the> description of the way to add transformationsto/from the IM are> important for the understanding and adoption of theIM andwill 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 Lautenbacherwrote:> >> Hi Adrian, hi Andrea, >> >> thanks a lot for the clarification about the STPIM. Yes, weare also >> looking forward to work with you. Currently we havesomeefforts on >> transformations between BPMN and JWT resp. XPDL andJWT, butafter >> that is >> finished we are looking forward to work on amapping STP IM<-> JWT. >> >> One last question: you say that STP IM is atransporter model(or Pivot >> model as I understand it), so I only needtransformationsfrom say >> BPMN to >> STP IM and from there to e.g. ServiceMix Assembly.But how doI know >> that my >> first transformation from BPMN to STP IM needs towrite specific>> properties >> such as "interface", "method call" or "participant"that ALLupcoming >> transformations (to ServiceMix, to BPEL, to XPDL,to whatever)>> understand >> where to look for? Adrian said that STP IM could bedescribedas an >> "intersection" between other relevant standards..And that'sreally >> good! But >> then there needs to be a mechanism or namingconvention for the>> generated >> and added properties, every transformation shouldtake careof and >> stick to >> in order to have several model transformations(from BPMN toSTP IM, >> from >> JWT to STP IM, from STP IM to BPEL, from STP IM toSCA, etc.)>> working after >> each other, am I right? >> >> Or is the "transporter model" thought of as a modelsimplyused in >> *one* >> transformation from BPMN to ServiceMix, but this transformation has two >> steps inside!? But what would be the use of such atransporter>> model? So I >> don't think its like that. >> >> Thanks for this last answer and a happy new year2008 to allof 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- <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 yourquestions, so Ijust >> want to >> say that if you're looking for help withtransformations you can>> definitely >> count on us. So if you have any questions abouttransforming>> elements from >> JWT to STP-IM or the other way around, feel free tofire themup on >> the STP >> mailing list, you'll get an answer quickly. >> >> Also, to follow up on what Andrea said and what Inotedpreviously, the >> STP-IM is a generic "transporter" model, intendedto bridge the>> variety of >> SOA editors in STP. So, the semantics of propertiesto different>> elements >> can differ based on the transformation that isgoing to usethem. >> The idea >> is that we do not try to offer all the semantics inthe 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 astop-level.>> >> Looking forward to working with you guys, Bestwishes, 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 themetamodel ofSTP IM. >>>> I now had a closer look at the metamodel in yourSVN and itis (in my >>>> opinion) >>>> much better designed than the one that is shownon your website. >>>> In fact >>>> the core concepts are very similar to the coremetamodel ofJWT >>>> (which can be found on ). In STP IM you got aProcess which>>>> contains * Steps and * Transitions. Each step hasa 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 canbe normal >>>> Transitions or TransitionsUnderCondition. And(nearly?)everything is >>>> a configurable >>>> >>> >>>> element. >>>> >>>> Now looking at the JWT metamodel it is very muchalike: here>>>> everything is a ModelElement. There areActivityNodes whichare >>>> connected via ActivityEdges (using source,target, in andout with >>>> same cardinality as sourceTransitions,targetTransitionsetc. in STP >>>> IM). There can be several types of ActivityNodes:one wouldbe an >>>> Action (probably a Step in >>>> IM) or it >>>> could be a ControlNode such as a ForkNode or aJoinNode. An>>>> ActivityEdge might have a Guard (making it a >>>> "TransitionUnderCondition") whereas the Guard isspecifiedin a >>>> GuardSpecification (with only a proprietarynotation allowed).>>>> >>>> Regarding your description of Properties and ObservableAttributes I >>>> guess that data that is necessary for execution(which mighthave >>>> been added to BPMN and shall be transformed intoBPEL e.g.)is added >>>> as a property to the relevant step, am I right? >>>> >>> Yes. >>> >>> For example for a Step that is configuredwith Service[StartService] >>> ServiceBinding [HTTP-InputBindingComponent] thepropertieswill be >>> driven by the HTTP-InputBindingComponet, So thestep will have>>> properties like: >>> >>> URL: >>> isSoap: >>> and so on. >>> >>> >>> Quite different is the concept of relevant data: >>> >>> Relevant data are extracted when the process isexecuted,evluating >>> expression on messages ( exchanged by endpoint inthe case ofJbi ) or >>> variable in the case of ( BPEL). >>> >>> An example of relevant data is customerIDextracted by /RECORD/>>> @customerId >>> >>> Thanks for clarification about the ownerattribute. Yes, Iwas more >>> thinking >>> >>>> about a participant or role than about an owner.Is thisdata ( e.g. >>>> which is >>>> available in a swimlane or pool in BPMN) thenadded as aproperty >>>> right now to each Step? >>>> >>> As i say in previous post we'e not yet provided inthe stp>>> intermediate model the concept of participiant role. >>> BTW i think that we could support this in BPMNeditor in twoways: >>> >>> 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 wecould draganbd drop on >>> the activities >>> >>> We cannot use the BPMN pool concept beacuse a poolin the imis mapped >>> in to a process. >>> >>>> I agree with Adrian and Marc that a first stepwould behaving a >>>> transformation from JWT to STP IM (and the otherway round).>>>> However, since >>>> the metamodels are quite similar, this should notbe sohard. Here at >>>> JWT we need to discuss who will be responsiblefor thistask. 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 toinclude theinformation >>>> from one metamodel in a way that it is clear in anexttransformation >>>> step where it should go. So, if I specify theowner of astep in a >>>> pool or lane in BPMN, how is this informationkept in STP IMso I can >>>> work with that when generating e..g. BPEL orXPDL-code? Iguess you >>>> need some predefined values as properties thatboth model>>>> transformations use!? Or will there be a querylanguage(such as RQL >>>> or SPARQL) where you can find the "semantics" ofthe property?>>>> Best regards and looking forward to some morefruitfuldiscussions, >>>> >>>> Florian >>>> >>>> >>> Intermediate Model is a very generic model so youcould have>>> situations where some properties ( for example ofthe step )will be >>> important by code generator A and others willbe need bycode >>> generator B. >>> >>> The concept is that IM bring you the informationin a verygeneric >>> way, than is responsibility of specific codegenerator totransform >>> that information in something executable. >>> >>> To bring you an example, now i'm working in generating servicemix >>> service assembly applications from intermediatemodel, andit'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 doubtpleasehttp://wiki.eclipse.org/images/2/2f/AgilPro_MetamodelDescription.pdf <http://wiki.eclipse.org/images/2/2f/AgilPro_MetamodelDescription.pdf>write me. >>> >>> Regards >>> Andrea >>> >>>>  >>>>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>>] 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 comeback fromJavapolis. >>>> >>>> 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  up to date? >>>>>> >>>> I think version on the wiki is not updated. Theversion thatwe're >>>> going to commit will be the really the first version. >>>> >>>> >>>>>> If so, I am curious why a step is part of aprocess, but the>>>>>> transition is not? >>>>>> And, on the other hand, why there is only oneedge betweena step >>>>>> and a transition with cardinality *. In many other standards (like >>>>>> UML activity diagrams) there are always twoedges betweena node >>>>>> (=ActivityNode in UML) and a transition(=ActivityEdge in>>>>>> UML) specifying that a transition has exactlytwo ends(cardinality >>>>>> of 1 at each edge)? >>>>>> >>>> >>>> In the version that we're going to commit aprocess willhave a set >>>> of steps and a set of transitions. A transitionwil have asource >>>> step and a target step then in the A step therewill betwo inverse >>>> relations a relation called sourceTransitions 1.*( alltransition >>>> for which the step is a source step ) and arealtion called>>>> targetTransition ( all transition for whcih thestep istarget ) >>>> >>>> >>>>>> How are the conditions at TransitionUnderCondition specified? Are >>>>>> these boolean conditions connected with AND,OR, XOR andNOT? 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 aboutattributes >>>>>> 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..* eachstep >>>> could have one or more observable attribute ). >>>> >>>> By the way what's important is to clarify thedifferencebetween >>>> "ObservableAttribute" and "Property" of a Step. >>>> >>>> Properties are information needed to configurethe step in a>>>> particular runtime,and the properties set depends by ServiceBinding. >>>> Observable attribute are data that will beextracted whenthe process >>>> will be executed to be visualuzed and monitored, by monitoring tools. >>>> >>>> >>>>>> Does a process or a step has no owner, but onlya service?>>>>>> >>>> >>>> A process is a subclass of service so processcould haveowner. >>>> What's important is to make distinct the conceptof "Owner"from the >>>> concept of "Participiant/Actor/Role" as we meanwhen wetalk 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 thefuture we'regoing to >>>> introduce something about. >>>> >>>> Basically ( it's just an idea that we need todiscuss withother >>>> members >>>> ) we'll introduce the concept of role, and asubclass ofStep entity >>>> ( let me say RoleAssignedStep or HumanTaskStep )where wemodel the >>>> relation beteween a step and a role. >>>> >>>> For "Owner" instead we mean the provider of aservice (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 otherinformation.>>>> >>>>>> Florian Lautenbacher >>>>>> -JWT project lead- >>>>>> >>>>>> >>>>>> 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/> <>>> >>> 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><mailto: jwt-dev@xxxxxxxxxxx <mailto:jwt-dev@xxxxxxxxxxx>>>> >> > _______________________________________________ > jwt-dev mailing list > jwt-dev@xxxxxxxxxxx <mailto:jwt-dev@xxxxxxxxxxx>_______________________________________________ jwt-dev mailing list jwt-dev@xxxxxxxxxxxhttps://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>>_______________________________________________ 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
Back to the top