RE: Other use cases RE: Trading Partner/Party Discovery/Agreement UseCases

[Stefano POGLIANI <stefano.pogliani@sun.com>]

I like this but I think it is a bit too generic. Would it be possible to instantiate some concrete examples associated to each of the five categories?

/Stefano

P.S.	Wouldn't this be part of an general "Glossary" ?

> -----Original Message-----
> From: Burdett, David [mailto:david.burdett@commerceone.com]
> Sent: Saturday, September 09, 2000 12:40 AM
> To: 'Martin W Sachs/Watson/IBM'; ebxml-tp@lists.ebxml.org
> Cc: ebxml-transport@lists.ebxml.org
> Subject: RE: Other use cases RE: Trading Partner/Party
> Discovery/Agreement Use Cases
> 
> 
> Marty
> 
> This might be a nit pick, but I do think that calling everything 
> a "Trading
> Party Agreement" is confusing since:
> a) you might want to use the information for non-trade purposes
> b) there isn't always a prior agreement.
> 
> I propose therefore the following draft definitions to facilitate 
> a common,
> and clearer understanding:
> 1. Document. A Document is any data that can be represented in a digital
> form.
> 2. Party. A Party is a company, organization or individual or other entity
> that can generate, receive or relay Documents.
> 3. Party Profile. A Party Profile is information about a Party that can be
> used to determine the alternative ways to send documents to that Party. A
> Party Profile may be represented as a Document.
> 4. Party Agreement. A Party Agreement is information agreed 
> between two (or
> more) parties that defines how they will exchange Documents. A Party
> Agreement may be represented as a Document.
> 5. Trading Party Agreement. A Trading Partner Agreement is a 
> Party Agreement
> that is designed to be used for Commerce. A Trading Party Agreement may be
> represented as a Document.
> 
> Thoughts?
> 
> David
> 
> -----Original Message-----
> From: Martin W Sachs/Watson/IBM [mailto:mwsachs@us.ibm.com]
> Sent: Friday, September 08, 2000 11:13 AM
> To: ebxml-tp@lists.ebxml.org; ebxml-transport@lists.ebxml.org
> Subject: Other use cases RE: Trading Partner/Party Discovery/Agreement
> Use Cases
> 
> 
> FYI
> 
> ******************************************************************
> **********
> *********
> 
> Martin W. Sachs
> IBM T. J. Watson Research Center
> P. O. B. 704
> Yorktown Hts, NY 10598
> 914-784-7287;  IBM tie line 863-7287
> Notes address:  Martin W Sachs/Watson/IBM
> Internet address:  mwsachs @ us.ibm.com
> ******************************************************************
> **********
> *********
> ---------------------- Forwarded by Martin W Sachs/Watson/IBM on 
> 09/08/2000
> 02:12 PM ---------------------------
> 
> "Moberg, Dale" <Dale_Moberg@stercomm.com> on 09/08/2000 12:13:07 PM
> 
> To:   Martin W Sachs/Watson/IBM@IBMUS, "Burdett, David"
>       <david.burdett@commerceone.com>
> cc:
> Subject:  Other use cases RE: Trading Partner/Party 
> Discovery/Agreement Use
>       Cases
> 
> 
> 
> I would like to propose that the survey
> of the use cases be opened up a bit,
> if only to decide that
> the scope has to be constrained.
> ==========================
> 
> 
> David's two cases seem to me to be fairly
> characterized over all as:
> 
> 1. manual TPA formation process
> 2. registry-facilitated-discovery TPA formation process
> 
> There are other broad families of TPA formation
> that may or may not involve a registry
> (or only registry like services privately
> hosted)
> 
> 
> 3. direct solicitation family (TP1 may
> be averse to publication of its TP template
> for business process BPn)
> 
> a. a potential TP1 sends its TPA template  (or whatever
> object ends up being necessary here-- I don't
> believe the current Role based binding process
> is going to be adequate) to TP2 with e.g. a specific
> BP in mind, with a specific data format (eg, cxml),
> but an open communication.
> 
> b. TP2 sends responds with a proposed TPA bound
> in all respects or
> b'. negack-- no TPA -- stop.
> 
> c. TP1 acknowledges acceptance of TP2s proposal or
> c'. negack -- no TPA --stop.
> 
> d. TPA in place between TP1 and TP2 and no public
> registry holds this TPA (which may be desired
> for commercial privacy reasons)
> 
> 4. real negotiated TPA formation -- registry based
> (By negotiation I mean something like
> what modems do when they agree on their
> connection or what PPP does when it sets
> up the IP layer... so these use cases
> will not be much like what I have
> seen so far in these threads. Also
> the process flow here can be embellished
> in several ways.)
> 
> a. TP1 registers BP and communications ("channels")
> capabilities and for simplicity, a rank
> ordered preference list of communication channels.
> 
> b. TP2 likewise registers its capabilities and
> preferences.
> 
> c. TP1 initiates TPA negotiation by retrieving
> TP2 and submitting proposed TPA. Registry
> notifies (?) TP2.
> 
> loop:
> 
> d. TP2
>   1. accepts, go ok
>   2. counteroffers then notification
>   3. naks, go fail
> 
> e. TP1
>   1. accepts, go ok
>   2. counteroffers, notification, go loop
>   3. naks, go fail
> 
> fail:
> f. failure no TPA formed. notify as needed. halt
> 
> label3.
> g. register TPA with registry. notify as needed. halt.
> 
> 
> 
> 
> 
> 
> 
> 5. real negotiated TPA formation, ad hoc.
> 
> 
> 
> -----Original Message-----
> From: Martin W Sachs/Watson/IBM [mailto:mwsachs@us.ibm.com]
> Sent: Thursday, September 07, 2000 4:32 PM
> To: Burdett, David
> Cc: Burdett, David; 'EbXML Trading Partner (E-mail)'; 'ebXML Transport
> (E-mail)'
> Subject: RE: Trading Partner/Party Discovery/Agreement Use Cases
> 
> 
> 
> David,
> 
> This looks very good.  Let's build it!
> 
> Regards,
> Marty
> 
> ******************************************************************
> **********
> 
> *********
> 
> Martin W. Sachs
> IBM T. J. Watson Research Center
> P. O. B. 704
> Yorktown Hts, NY 10598
> 914-784-7287;  IBM tie line 863-7287
> Notes address:  Martin W Sachs/Watson/IBM
> Internet address:  mwsachs @ us.ibm.com
> ******************************************************************
> **********
> 
> *********
> 
> 
> 
> "Burdett, David" <david.burdett@commerceone.com> on 09/05/2000 06:36:48 PM
> 
> To:   "Burdett, David" <david.burdett@commerceone.com>, Martin W
>       Sachs/Watson/IBM@IBMUS
> cc:   "'EbXML Trading Partner (E-mail)'" <ebxml-tp@lists.ebxml.org>,
>       "'ebXML Transport (E-mail)'" <ebxml-transport@lists.ebxml.org>
> Subject:  RE: Trading Partner/Party Discovery/Agreement Use Cases
> 
> 
> 
> Forgot the attachments ...
> 
> 
> -----Original Message-----
> From: Burdett, David
> Sent: Tuesday, September 05, 2000 3:35 PM
> To: 'Martin W Sachs/Watson/IBM'
> Cc: EbXML Trading Partner (E-mail); ebXML Transport (E-mail)
> Subject: RE: Trading Partner/Party Discovery/Agreement Use Cases
> 
> 
> Marty
> 
> You make good points. An updated use case is attached which also includes
> other example of what can happen in step 4.
> 
> For the benefit of others on this list. If we accept use case 2 in the
> attached document, it means that:
> 1. There is a use case where there is no prior "Trading Partner 
> Agreement".
> Instead,
> 2. Information about one of the parties is sent in the same message as a
> business document.
> 
> I'd appreciate others views on use case 2 and how to handle it.
> 
> David
> -----Original Message-----
> From: Martin W Sachs/Watson/IBM [mailto:mwsachs@us.ibm.com]
> Sent: Thursday, August 31, 2000 11:57 AM
> To: David Burdett
> Cc: EbXML Trading Partner (E-mail); ebXML Transport (E-mail)
> Subject: Re: Trading Partner/Party Discovery/Agreement Use Cases
> 
> 
> Sorry, I hit the wrong button.  Here is the full posting.
> 
> 
> I finally caught up to the discovery use case description.  It looks very
> good.  I am not speechless, however.
> 
> In use case 2:
> 
>    Step 3, last paragraph:  I think that some people would argue 
> that Party
>    A sending Party B a message containing the reference or 
> pointer to Party
>    B's information constitutes Party A's acceptance of Party B's terms and
>    therefore agreement with Party B's terms.  To me, this is the same as
>    clicking "accept" on Netscape's T's and C's panel when I download a new
>    version.  In neither case, however is there any negotiation.  You might
>    want to change "agreement" to "negotiation" in the last line of the
>    paragraph.
> >>>Agreed.<<<
> 
>    Step 4:  It might be interesting to add the following step 5:
> 
>      Step 5:  If party B did not find the Party A information 
> acceptable in
>      step 4, then perform use case 1.
> 
> 
> Regards,
> Marty
> 
> 
> 
> 
> 
> ******************************************************************
> **********
> 
> 
> *********
> 
> Martin W. Sachs
> IBM T. J. Watson Research Center
> P. O. B. 704
> Yorktown Hts, NY 10598
> 914-784-7287;  IBM tie line 863-7287
> Notes address:  Martin W Sachs/Watson/IBM
> Internet address:  mwsachs @ us.ibm.com
> ******************************************************************
> **********
> 
> 
> *********
> 
> 
> 
> David Burdett <david.burdett@commerceone.com> on 08/22/2000 05:35:30 PM
> 
> To:   "EbXML Trading Partner (E-mail)" <ebxml-tp@lists.ebxml.org>, "ebXML
>       Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
> cc:
> Subject:  Trading Partner/Party Discovery/Agreement Use Cases
> 
> 
> 
> Folks
> 
> A couple of use cases for the TP group that I am also copying to the
> Transport Group. Do folks these these use cases are reasonable?
> 
> David
>  <<Party Discovery Use Cases 01.doc>>
> 
> Product Management, CommerceOne
> 4400 Rosewood Drive 3rd Fl, Bldg 4, Pleasanton, CA 94588, USA
> Tel: +1 (925) 520 4422 (also voicemail); Pager: +1 (888) 936 9599
> mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>