[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: RE: Trading Partner/Party Discovery/Agreement Use Cases
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC