RE: Trading Partner/Party Discovery/Agreement Use Cases

[David Burdett <david.burdett@commerceone.com>]

Farrukh

I agree that we need to involve the TP and the reg/rep teams. I know that
there are representatives of the TP team on the transport list (e.g. Marty
and me), but is there a representative of the Reg/Reg team? If there is can
they send an email to the list and let us know if we can forward the use
case to the Reg/Rep team.

David

-----Original Message-----
From: Farrukh Najmi [mailto:Farrukh.Najmi@east.sun.com]
Sent: Friday, August 25, 2000 1:00 PM
To: David Burdett
Cc: 'Moberg, Dale'; 'Mark CRAWFORD'; mwsachs@us.ibm.com;
ebxml-tp@lists.ebxml.org
Subject: Re: Trading Partner/Party Discovery/Agreement Use Cases



I agree that the dynamic discovery of trading partners and dynamically
assembling a TPA on the fly is a very real use case, though in the advanced
category. To properly address this I think we need to involve both the TPA
and
reg/rep teams. There has been some discussion in POC on whether this may be
a
candidate for the Tokyo POC.

--

Regards,
Farrukh

David Burdett wrote:

> I agree with Dale especially where he says ... "Discovery _may_ involve
> certain "bootstrap" issues that impact what elements are mandatory within
a
> header."
>
> Particularly I think that there is a use case where there is no prior
> *direct*" contact between two parties before one of those parties sends
the
> other an ebXML compliant message. In this case the party sending the
message
> needs to be able to include, or refer to, information about themselves
**in
> the message**. This is described in the second use case I put forward. The
> current version of of the Message Header does not allow this type of
> interaction. I think it must though since it is a very common style of
doing
> eCommerce that is being used right now as I described in an email earlier
> today subject: "Trading Partner/Party Discovery/Agreement Use Cases",
time:
> "Fri 08/25/2000 9:22 AM"
>
> David
>
> -----Original Message-----
> From: Moberg, Dale [mailto:Dale_Moberg@stercomm.com]
> Sent: Friday, August 25, 2000 6:47 AM
> To: 'Mark CRAWFORD'; mwsachs@us.ibm.com
> Cc: David Burdett; ebxml-tp@lists.ebxml.org
> Subject: RE: RE: Trading Partner/Party Discovery/Agreement Use Cases
>
> I cannot speak for the others on why this discussion
> is taking place but I have two motivations for
> trying to find out about discovery methods
> within ebXML.
>
> First, the ebXML header and message documents
> are currently assuming that every ebXML message
> has a header. Discovery requests are one proposed
> type of ebXML message. Discovery _may_ involve
> certain "bootstrap" issues that impact what
> elements are mandatory within a header. So it is
> important to understand the scope of
> discovery requests and how they are proposed to
> work.
>
> Second the POC group is considering checking
> out the functionality of the registry and
> discovery requests in the next round. So
> requirements sufficiently definite to assist
> implementation were needed yesterday :-)
> Since you (Mark C.) indicate that these
> discussions are completed or near completed
> by other working groups, I would very
> much appreciate receiving some references
> to the core documents that the POC group
> can read. I for one am not interested
> in any turf war and am happy to build
> on what has been thought through already.
>
> -----Original Message-----
> From: Mark CRAWFORD [mailto:mcrawfor@lmi.org]
> Sent: Friday, August 25, 2000 6:52 AM
> To: mwsachs@us.ibm.com; Moberg, Dale
> Cc: david.burdett@commerceone.com; ebxml-tp@lists.ebxml.org
> Subject: Re:RE: Trading Partner/Party Discovery/Agreement Use Cases
>
> I am not sure why this discussion is taking place.  The purpose of this
> group is
> not to determine the components of ebXML, nor its basic requirements.  The
> basic
> requirements are documented, and Architecture, Business Process, and R&R
are
> well down the path on the discovery issue.
>
>     Mark
> Mark Crawford
> Research Fellow
> E-business Strategies
> ______
> LMI Logistics Management Institute
> 2000 Corporate Ridge, McLean, VA 22102-7805
> (703) 917-7177   Fax (703) 917-7518
> mcrawfor@lmi.org
> http://www.lmi.org
> "Opportunity is what you make of it"
>
> ____________________Reply Separator____________________
> Subject:    RE: Trading Partner/Party Discovery/Agreement Use Cases
> Author: <mwsachs@us.ibm.com>
> Date:       8/24/00 6:09 PM
>
> The discovery capability will be important to spontaneous e-commerce, but
> it should not be required by ebXML.  Another scenario is that
> representatives of the two partners sit together, agree on the application
> process and jointly compose a TPA containing the information they must
know
> about each other.
>
> 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
>
****************************************************************************
> ****
> *****
>
> "Moberg, Dale" <Dale_Moberg@stercomm.com> on 08/23/2000 11:48:18 AM
>
> To:   "'David Burdett'" <david.burdett@commerceone.com>, "EbXML Trading
>       Partner (E-mail)" <ebxml-tp@lists.ebxml.org>
> cc:
> Subject:  RE: Trading Partner/Party Discovery/Agreement Use Cases
>
> >(Dave Burdett) Assumptions
> >>Assumption 1 - Each party must know sufficient information about each
> other that they can send each
> >>other messages that each will be able to successfully process.
> >>This assumption is illustrated in the diagram below
> >> that shows the "end state" of the discovery process.
> >>[omitted]
>
> 1.   Do the trading parties both need to be involved in discovery?
> It might be possible to consult a clearinghouse with searches
> over "stainless steel ball bearing supplier adhering to specifications
> MIL-STD 322332" and proceed to obtain or negotiate a TPA. What kind
> of query messages are allowed for discovery? Is it to be hard-wired
> into the protocol that it would be necessary to know the contact URL
> for a specific trading partner? Will discovery of candidate trading
> partners by categories of goods/services be supported? Can this
> discovery then itself supply references to contact URLs for negotiatiated
> TPAs, template TPAs (take it or leave it TPAs), and so on. In general
> what kinds of discovery services will be available?  Might additional
> parties be involved in the TPA setup (legal reviewers, financial
reviewers,
> business strategists, ...) so that there is a workflow component to a
> negotiated TPA setup?
>
> >>Assumption 2 - The method by which a party discovers
> information about another party is immaterial.
> 1.   Some methods may be made available to "the public at
> large"; other methods might be reserved to entities
> fulfilling some special condition (certified by some
> financial agency or whatnot) I am not certain what
> this assumption really is trying to indicate. Here are some guesses:
> that however one arrives at a TPA, once the TPA is in place,
> the TPA governs the business and ebxml processes.
> Or possibly, parties may choose to divulge information about
> themselves through a third party or not. Whatever they choose as
> policy here does not make a difference in how the discovery
> process works. (I think this might well be false, though.)
> At any rate, I am uncertain what this assumption is really saying,
> so I would like to see it restated somehow.
>
> >> If a first party wants to send a message to
> a second party all they need to know is:
> ·    the types of process that the second party supports
> and the specifications that they follow
> 1.. I take it that this list is a list of prior knowledge
> that is a prerequisite for discovery  Actually I would
> think that at least some discovery processes would make
> very minimal demands on what needs to be known. So I am
> unclear why it should be assumed that the first party needs
> to know in advance what specifications and types of business(?)
> processes are supported by the second party. This needs some
> explanation before I would buy in. Wouldn't these data items
> be things we might want to discover?
>
> ·    the transport/data communications that should be used to send a
> message to the second party
> 1. Again, why wouldn't this be something that we are trying to discover?
>
> ·    whether or not the second party will accept the message from the
> first party
>
>     I don't think this would be good to require. Leave the
>  "listening ports" unconstrained for at least submitting
> the request and then allow there to be a response to say
> that authorization is needed to continue. Here I assume that
> the message to be accepted is the "ebXML discovery" message.
> Otherwise, why wouldn't this be something that we are trying to discover?
>
> -----Original Message-----
> From: David Burdett [mailto:david.burdett@commerceone.com]
> Sent: Tuesday, August 22, 2000 5:36 PM
> To: EbXML Trading Partner (E-mail); ebXML Transport (E-mail)
> 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