[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Other use cases RE: Trading Partner/Party Discovery/Agreement UseCases
David,
That's a good set of working definitions. It's not clear that (5) is
needed alongside (4), however. I'll add this to the collection of input to
the team.
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/08/2000 06:40:04 PM
To: Martin W Sachs/Watson/IBM@IBMUS, 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC