Yep, the parties must agree of the semantics of the invocation elements. In
case of absence of a
community of use Profile, a negotiated CPA, is the place. In cases of
community of use Profile, in this case
verticals that use the RosettaNet Profile, it may not be required to be in
an agreement, but implied within
the scope of community interoperability. This is all a matter of stacking
profiles, starting at using SOAP,
then ebXML's SOAP profile, then RossettaNet Profile, etc, with narrowing
interoperability as the stack goes
higher. As soon as there is a community ebXML Profile, the need for a CPA
comes in question.
Ralf B:
capture for our MSH concept revision.......
Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074
Martin W Sachs/Watson/IBM@IBMUS on 07/19/2001 12:11:05 PM
To: Scott Hinkelman/Austin/IBM@IBMUS
cc: Arvola Chan <arvola@tibco.com>, David Fischer
<david@drummondgroup.com>, Burdett David
<david.burdett@commerceone.com>, ebXML Msg
<ebxml-msg@lists.oasis-open.org>, Pete Wenzel
<Pete.Wenzel@RosettaNet.org>, ebxml-cppa@lists.oasis-open.org
Subject: Re: PIP IDs
Yes, an arbitrary hierarchy of elements might solve some of the routing
problems we have been turning up. However it has to be designed in such a
way that each party to a CPA understands the other party's hieararchy. In
other words, both parties must agree to the meaning of each element and the
hierarchy has to be expressable both in the message header and in the CPA.
I don't think this is a problem; it is a piece of work to do. I believe
that the authorized roles and refToMessageId will also have to be part of
that routing information as mentioned in prior postings.
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
*************************************************************************************
Scott Hinkelman
07/19/2001 02:41 PM
To: Arvola Chan <arvola@tibco.com>
cc: Martin W Sachs/Watson/IBM@IBMUS, David Fischer
<david@drummondgroup.com>, Burdett David
<david.burdett@commerceone.com>, ebXML Msg
<ebxml-msg@lists.oasis-open.org>, Pete Wenzel
<Pete.Wenzel@RosettaNet.org>
From: Scott Hinkelman/Austin/IBM@IBMUS
Subject: Re: PIP IDs (Document link: Martin W. Sachs)
>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.
Again, my view on this is to define a Qualified Invocation sequence
generically with an arbitrary number of tags, and
drop the tag names "Service" and "Action". Just as ebXML Message Service
defines a SOAP+Attachments Profile,
RosettaNet would define an ebXML Message Service Profile, which would
contain mapping to its PIP,etc,etc, (its invocation qualification).
Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074
Arvola Chan <arvola@tibco.com> on 07/19/2001 09:03:32 AM
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)