Arvola,
Thanks for the clarification. As you are probably aware, there are other
response routing issues that have surfaced lately to the CPPA team, so this
topic will be on the CPPA agenda as well. This is an area where the MSG
and CPPA teams will have to work together.
I have been assuming that for RosettaNet, a conversation equals one
execution of one PIP. I believe that your note says that a single unit of
business in RosettaNet can involve several PIPs. What is your view of the
relationship of a PIP to a coversation. Is each PIP a separate
conversation or should execution of all the related PIPs in a unit of
business be treated as a single conversation? Since the conversation
boundaries are determined by the application, this is really your call for
RosettaNet but I am interested in your thinking.
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
*************************************************************************************
Arvola Chan <arvola@tibco.com> on 07/19/2001 12:03:32 PM
To: Martin W Sachs/Watson/IBM@IBMUS, David Fischer
<david@drummondgroup.com>
cc: Burdett David <david.burdett@commerceone.com>, ebXML Msg
<ebxml-msg@lists.oasis-open.org>, Pete Wenzel
<Pete.Wenzel@RosettaNet.org>
Subject: Re: PIP IDs
Marty,
Up to now, RosettaNet PIPs are either request-response (two-actions) or
notification (one-action) style business processes. Earlier versions of
PIP 3A4 are an exception in the sense that�PIP 3A4�covers Create Purchase
Order (request-response), Change Purchase Order (request-response) and
Cancel Purchase Order (request-response) interactions. Recently, PIP 3A4
has been split into 3A4 (Create Purchase Order), 3A8 (Change Purchase
Order), and 3A9 (Cancel Purchase Order) in order to achieve some degree of
uniformity across PIPs (I believe). Therefore, I think it is reasonable to
equate�existing RosettaNet PIPs with BPSS Business Transactions.
In the RosettaNet message header, there are separate elements to identify
the PIP ID, the PIP action and the Service. Multiple PIPs may be
implemented by the same service, e.g., there may be a Buyer service
implementing PIPs 3A4, 3A8, 3A9 from the buyer perspective, and a Seller
service implementing the same PIPs from the seller perspective.
I don't think we should equate PIP ID with Service and action with "the
particular business transaction within the PIP". Otherwise, we will not be
able to capture the role information, e.g., the ability to distinguish a
Buyer Service from a Seller Service, and a request action from a response
action.
From the RosettaNet point of view, it will be desirable if we can have
distinct Service, PIP (equivalently BPSS Business Transaction), and action
elements in the message header. Alternatively, we can use the Service
element to capture role information (e.g., Buyer vs Seller), and use the
Action element to capture the PIP ID. Whether we are dealing with a
request action or a response action will have to be inferred from the
Service element.
Regards,
-Arvola
Arvola Chan (arvola@tibco.com)
TIBCO Software (on loan to RosettaNet)
+1-650-846-5046 (US-Pacific)