ebxml-tp message


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

 


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

Subject: Re: Sanity check needed for struggling TPA participant




Martin W Sachs wrote:
>
> However I think there is a problem both with this one and with the one that
> I originally suggested (below).  If I try to compose a CPA from similar
> CPPs for two parties, I don't see any way for the composition software to
> figure out which party will be "buyer" and which will be "seller".  I can
> think of two ways out of this ambiguity:
>>>>
Marty:

One way I tackled this in a very early draft (January 2000) of a
possible demonstration of a Trading Partner XML Document was to define
each Role/CP combination as a specific capability.  I made a branch of
XML similar to the following

<SupportedBusinessProcesses>
  <Process> 
    <ProcessName GUID="foo:12345">Purchase Order</ProcessName>
    <RoleSupported>Submitter</RoleSupported> 
    <ServiceBinding ID="SB04">
      ....
    </ServiceBinding>
  </Process>  
 
  <!--note new GUID for same process/different role-->
  <Process> 
    <ProcessName GUID="foo:12346">Purchase Order</ProcessName>
    <RoleSupported>Receiver</RoleSupported> 
    <ServiceBinding ID="SB04">
      ....
    </ServiceBinding>
  </Process> 

blah...

The idea is that if I want to send someone a Purchase Order,  I look for
a process with a specific GUID that represents the other party receiving
my PO.  That way there is no confusion.  

That is of course only one suggestion. THere are many ways to accomplish
the same task.
 
>    1. Admit that this case requires negotation after composition.

It may be advantageous for the Roles should be defined before the
composition of the CPA to aide in creating some specific details of the
CPA like timouts and what infromation sets are sent.  Remember,  IF one
party says send me a Purchase ORder,  they wil also specify what
business information (via Core COmponents UNique Identifiers) is
required.  IF the two sets of information are dissimilar,  one party has
to convert their data before sending it.  That will be affected by the
Roles each party assumes. 

THe business information may be currently hidden from CPP and CPA but it
will be accessable via the BUsiness Process XML documents.  
> 
>    2. Say that this CPP is invalid and if a party wants to represent itself
>    as capable of being either "buyer" or "seller" in different CPAs for the
>    same process, that it should have two CPPs, one for each role.

Possible but probably not my first vote.
> 
> I think that the above is equivalent to the ambiguity that Chris noted at
> the bottom of his posting below. I would note that the validation process
> he mentions also to has to be sure that all the three roles are filled.
>>>>>>>>>>

A real grab bag of possibilities.  YOu have done a lot fo excellent
thinking on this whole subject and I am very impressed.

Duane Nickull


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC