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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-tp message

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

Subject: RE: Trading Partner/Party Discovery/Agreement Use Cases

So many qustions ... responses inline below marked with ##.


-----Original Message-----
From: Moberg, Dale [mailto:Dale_Moberg@stercomm.com]
Sent: Wednesday, August 23, 2000 8:48 AM
To: David Burdett; EbXML Trading Partner (E-mail)
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.

1.	Do the trading parties both need to be involved in discovery? 
##No. This is illustrated in Use Case 2.##

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? 
##I give some examples in Use Case 2, e.g. URL from a web site, negotiation
protocol (TBD)##

Is it to be hard-wired 
into the protocol that it would be necessary to know the contact URL 
for a specific trading partner? 
##No in my opinion##

Will discovery of candidate trading 
partners by categories of goods/services be supported? 
##I wouldn't think so, this is a business process.##

Can this 
discovery then itself supply references to contact URLs for negotiatiated 
##I don't think you can "discover" a negotiated TPA. As negotiation must
inolve a two-way conversation.##

template TPAs 
(take it or leave it TPAs), 
##Definitely, except I wouldn't call it an "agreement" I'd call it "Terms &
conditions". It only becomes an agreement when the party that downloads the
"Terms & Conditions" accepts them in one way or another.##

and so on. In general 
what kinds of discovery services will be available?  
##Some ways it could work are given in Use Case 2##
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?
##Yes. But then we are talking about a Negotiated form of discovery.##

>>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.
##That's a fair alternative description.##
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  
##Not really, this is a pre-requisite to doing some type of co-operative
process e.g. a business process. There is a bootstrap problem. Which is why
discovery can occur in a variety of ways as suggested in Use Case 2.##

Actually I would 
think that at least some discovery processes would make 
very minimal demands on what needs to be known. 
##I agree, Use Case suggests, for example, just knowing a URL.##

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?
##I agree it is.##
	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?

##In general I was trying to giving two different use-cases that describe
how the information that you need to know before sending a message could be


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


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?

 <<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]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC