OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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#.
> >
> >
> >
> >
>
>
>
>





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC