RE: minutes and call info - metamodel mtg.

[Scott Hinkelman/Austin/IBM <srh@us.ibm.com>]

Stefano,
Yes we agree on the content but with different words.

Formally, the BP MM is a MOF M2. The automotive example is an M1. The
instance of that
is an M0, which is where the specific and exact Parties, etc, are defined.
In ebXML, the supporting
data for M0 needs to be defined in either implicit or explicit PA(s).

Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



"Stefano POGLIANI" <stefano.pogliani@sun.com> on 10/09/2000 01:34:42 PM

Please respond to <stefano.pogliani@sun.com>

To:   Scott Hinkelman/Austin/IBM@IBMUS
cc:
Subject:  RE: minutes and call info - metamodel mtg.



Scott,
     perhaps we agree on the content but use different words.
What do you mean by "instance" of a BP?
My meaning is the following : a BP is a "graph" describing how partners
work together to accomplish A SPECIFIC task. An instance of a BP is just a
RUN-TIME occurrence of such work.
Example : a BP can be "Airline Ticket Reservation for IATA". An instance is
an actual ticket
reservation for me for the flight Geneva->Boston

/Stefano

> -----Original Message-----
> From: Scott Hinkelman/Austin/IBM [mailto:srh@us.ibm.com]
> Sent: Monday, October 09, 2000 7:20 PM
> To: stefano.pogliani@sun.com
> Cc: ebxml-bp@lists.ebxml.org; ebxml-core@lists.ebxml.org
> Subject: RE: minutes and call info - metamodel mtg.
>
>
> Stefano,
> >This is true if a Party already provides the semantic for the Agreement,
in which case
> >teh party is "already" ready to perform the business. In case the Party
would like
> >to engage in a "new business", then he would have to "derive" the PP
from the BP
> >he would like to be engaged into.
>
> Yes, I see now how you are using the word "derived". He would have to
implement support if he
> does not already provide "the semantic" to engage in new business. We
agree.
>
> >I would agree that a BP instance is a collection of actual PA
implementations.
> >If I consider the PA as something which describes and defines the actual
> >exchanges between partners, I would consider the PA "at the same level"
of
> >the BP.
>
> If you would have said "at the same level of the BP instance" then I
would agree.
>
> >I am not sure I understand your point. A BP is, in some way,
multi-roled.
> A two-roles BP is JUST a particular case. Am I right ?
>
> Yes. If you take the perspective of a collection of PAs, what is not yet
> clear is the ownership model for
> expressing the orchestration of the PAs for a given BP. There is a need
in
> the PA to both depend on
> the RegRep, and not to. This implies that the PAs need to support
by-value
> and by-reference to the
> BP. For the case of RegRep it is more clear at this point.
> Discussion point this week in the f2f.
>
> Thanks,
> Scott Hinkelman, Senior Software Engineer
> XML Industry Enablement
> IBM e-business Standards Strategy
> 512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
> srh@us.ibm.com, Fax: 512-838-1074
>
>
>
> "Stefano POGLIANI" <stefano.pogliani@sun.com> on 10/09/2000 10:24:14 AM
>
> Please respond to <stefano.pogliani@sun.com>
>
> To:   Scott Hinkelman/Austin/IBM@IBMUS
> cc:
> Subject:  RE: minutes and call info - metamodel mtg.
>
>
>
> Scott,
>
>      find my comments to your answer embedded below.
> /Stefano
>
>
> > -----Original Message-----
> > From: Scott Hinkelman/Austin/IBM [mailto:srh@us.ibm.com]
> > Sent: Monday, October 09, 2000 5:13 PM
> > To: stefano.pogliani@sun.com
> > Cc: ebxml-bp@lists.ebxml.org; ebxml-core@lists.ebxml.org
> > 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".
>
> This is true if a Party already provides the semantic for the
> Agreement, in
> which case
> teh party is "already" ready to perform the business. In case the Party
> would like
> to engage in a "new business", then he would have to "derive" the PP from
> the BP
> he would like to be engaged into.
>
> >
> > >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.
> >
>
> I fully agree.
>
> > 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.
>
> I would agree that a BP instance is a collection of actual PA
> implementations.
> If I consider the PA as something which describes and defines the actual
> exchanges between partners, I would consider the PA "at the same level"
of
> the BP.
>
> > We will need to come to terms with the model of PAs
> > across a multi-Roled process, and where it's entirety links together.
>
> I am not sure I understand your point. A BP is, in some way,
> multi-roled. A
> two-roles
> BP is JUST a particular case. Am I right ?
>
> >
> > Scott Hinkelman, Senior Software Engineer
> > XML Industry Enablement
> > IBM e-business Standards Strategy
> > 512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
> > srh@us.ibm.com, Fax: 512-838-1074
> >
> >
> >
> > "Stefano POGLIANI" <stefano.pogliani@sun.com> on 10/09/2000 09:22:12 AM
> >
> > Please respond to <stefano.pogliani@sun.com>
> >
> > To:   Scott Hinkelman/Austin/IBM@IBMUS, "Karsten Riemer"
> >       <Karsten.Riemer@east.sun.com>
> > cc:   <ebxml-bp@lists.ebxml.org>, <ebxml-core@lists.ebxml.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:srh@us.ibm.com]
> > > Sent: Monday, October 09, 2000 4:02 PM
> > > To: Karsten Riemer
> > > Cc: ebxml-bp@lists.ebxml.org; ebxml-core@lists.ebxml.org
> > > 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)
> > > srh@us.ibm.com, 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:   ebxml-bp@lists.ebxml.org, ebxml-core@lists.ebxml.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#.
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>