[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: minutes and call info - metamodel mtg.
Stefano, >Scott, > if I understand it correctly, the "IdentifiableProcess" approach is the top-down approach where you >first draw the Business Process and, then, you derive the PPs from it. Almost. But I would say not "then, you derive the PPs from it", but "then, Parties can update their PPs to indicate which Roles they support in the new IdentifiableProcess". >If my understanding is correct: > - would a "One-to-One" exchange between two partners be a BP? > - in a more sophisticated BP, which involves more partners and more steps, > could I (in a first approximation) consider the BP as a collection of > PAs ? >/Stefano A would think that under this model, a "one-to-one" exchange between two Parties would indeed be an IdentifiableProcess. This model, the predefined process, is built on the foundation that in order to indicate support from a Party, the process has to be understood and have identity, simple or complex. It would be closer to my view to say that you could consider *an instance* of the BP as a collection of PAs, but this is yet insuffiently detailed. We will need to come to terms with the model of PAs across a multi-Roled process, and where it's entirety links together. Scott Hinkelman, Senior Software Engineer XML Industry Enablement IBM e-business Standards Strategy 512-823-8097 (TL 793-8097) (Cell: 512-940-0519) firstname.lastname@example.org, Fax: 512-838-1074 "Stefano POGLIANI" <email@example.com> on 10/09/2000 09:22:12 AM Please respond to <firstname.lastname@example.org> To: Scott Hinkelman/Austin/IBM@IBMUS, "Karsten Riemer" <Karsten.Riemer@east.sun.com> cc: <email@example.com>, <firstname.lastname@example.org> Subject: RE: minutes and call info - metamodel mtg. Scott, if I understand it correctly, the "IdentifiableProcess" approach is the top-down approach where you first draw the Business Process and, then, you derive the PPs from it. If my understanding is correct: - would a "One-to-One" exchange between two partners be a BP? - in a more sophisticated BP, which involves more partners and more steps, could I (in a first approximation) consider the BP as a collection of PAs ? /Stefano > -----Original Message----- > From: Scott Hinkelman/Austin/IBM [mailto:email@example.com] > Sent: Monday, October 09, 2000 4:02 PM > To: Karsten Riemer > Cc: firstname.lastname@example.org; email@example.com > Subject: Re: minutes and call info - metamodel mtg. > > > BP/CCers, > My appologies for not being at this meeting last Monday. Here is what > is in my head on some of this. I have also copied in a reference to discussion > on some of this we have had on the Transport/TP lists. > > >We discussed BP relation to TPA. Question of 'what comes first' the BP or the > >TPP. In all industry standard scenarios BP comes first, TPP is derived and > >augmented. In the more entrepreneurial .com world TPP's might come first, and > >BP becomes an assembly of existing TPP's. We agreed to focus on the former > >scenarios for now. Bob pointed out that the core process work migh also > >provide a bottom-up or middle-up approach where you build bigger processes > >from core processes. > > I agree there are two models. I would characterize these two models as > an "IdentifiableProcess" and a "DynamicConversation". > > IdentifiableProcess: > is predefined with predefined sequencing and has a set of unique Roles > that can be played by Parties. A Party's PartyProfile can reference > the Roles it supports for a given IdentifiableProcess. > It does seem aligning a building block approach (CoreProcess) makes > sense. This is along the lines of the current MM, and should be/is the > current ebXML focus. > > DynamicConversation: > This supports a model where a DyanmicConversation is started with a > fixed set of initial Parties. There is a form of understanding > of the interaction content capability for each involved Party, > but there is no predefined sequencing. I believe accomplishing > this within the fixed ebXML life is not achieveable. > > >We need access to the actual .mdl model, not just the .doc > >specification document. > > Agreed. > > >Next meeting October 10. at 9 am PST, 12 pm EST. > >Preliminary agenda: > >..... > >Discussion of BP elements needed for TP. > >Discussion of Partner definition. > >............ > > Agree we need this but a focus on the PP (PartyProfile) not the > Partner/Party (which is it anyway?). > I am now thinking that there is no real "merge" of the BP MM and a PA. A PP > should be registered and reference which IndentifiableProcesses/Roles it > supports. > From there, Parties negotiate a PA (PartyAgreement) instance to support the > runtime. > [some of these terms, PP, PA, have now become firm in other groups, so lets > use them]. > > This week in the TP f2f we will have this discussion. Here is a pointer to > some of the same converstation........ > > http://lists.ebxml.org/archives/ebxml-tp/200009/msg00090.html > > Scott Hinkelman, Senior Software Engineer > XML Industry Enablement > IBM e-business Standards Strategy > 512-823-8097 (TL 793-8097) (Cell: 512-940-0519) > firstname.lastname@example.org, Fax: 512-838-1074 > > > > Karsten Riemer <Karsten.Riemer@East.Sun.COM> on 10/08/2000 09:41:06 PM > > Please respond to Karsten Riemer <Karsten.Riemer@East.Sun.COM> > > To: email@example.com, firstname.lastname@example.org > cc: > Subject: minutes and call info - metamodel mtg. > > > > Minutes from Metamodel meeting 10/2/2000 > > Agenda: > > 1. Review of context matrix, and identification of metamodel element > representing each context > > 2. Discussion of plans for arriving at XML representation for business > processes defined against the metamodel > > 2.a. Identification of minimal required content of an XML document > representing a business process in order for it to be the functional basis > for > deriving a Trading Partner Profile (i.e. half of a Trading Partner > Agreement) > > 2.b. Discussion of use of XMI > > 3. Feedback from last weeks walk-through of the AIAG example > expressed as > a > model against the metamodel. > > > Attendees: > > Bill McCarthy > Bob Haugen > Edwin Young > Core Casanave > Mike Rowley > Jean-Jacques Dubrais > Anne Hendry > Antoine Lonjon > Paul Levine > Stefano Pogliani > Sharon Kadlec > Tim McGrath > Karsten Riemer > > We went over the table of contexts with Jim Clark's annotations of meta > model > elements. Bill McCarthy and Bob Haugen to update document with > comments and > corrections, and to work with Jim Clark to update metamodel where > required. > > We discussed classification schemes. Reg/Rep model of a hierarchy of > classifiers and a type of relationship called classification appears to > cover > all the needs. However, it is unclear who in BP/CC is responsible for > providing list of possible values for these classifiers. Sharon said that > this > was up to trade/industry bodies. But we at least need examples. > > We discussed XML formats. Antoine had been working on conversion to XMI of > example activity diagram and sequence diagram. Antoine sent the resulting > XMI > to the ccbp-context list. These XMI documents will be discussed at > Tuesday's > meatamodel meeting. There was a comment that perhaps the recommended XML > format is a TA issue. Antoine will contact Duane. > > Sharon asked whether ebXML would/should provide stylesheets to convert the > contents of a BP model to html. Group agreed that that is not in scope for > BP > team. However, we will see what Sig Handelman and POC comes up with. > > We discussed BP relation to TPA. Question of 'what comes first' the BP or > the > TPP. In all industry standard scenarios BP comes first, TPP is derived and > augmented. In the more entrepreneurial .com world TPP's might come first, > and > BP becomes an assembly of existing TPP's. We agreed to focus on the former > scenarios for now. Bob pointed out that the core process work migh also > provide a bottom-up or middle-up approach where you build bigger processes > from core processes. > > We solicited feedback on last week's review of AIAG example. None offered. > Karsten to schedule to schedule the review of the FSV layer. We > need access > to > the actual .mdl model, not just the .doc specification document. > > Next meeting October 10. at 9 am PST, 12 pm EST. > > Preliminary agenda: > Review of XMI documents. > Attempt to settle on XML format for POC. > Discussion of BP elements needed for TP. > Discussion of Partner definition. > Scheduling of FSV review. > Process for review of metamodel. > > To access the call, dial 888-699-0348 domestically and +1 732-336-6000 > internationally, with a PIN of 8955#. > > > >
Powered by eList eXpress LLC