That's the way I see it as well.
Cheers,
Chris
Martin W Sachs wrote:
>
> David,
>
> Please forgive my repetition, but...
>
> Your two points:
>
> look up the CPA from the CPA ID and route the message to the endpoint
> identified, or
>
> look up the Party, Service and Action in a table to identify where to
> send the message to.
>
> are really one and the same since any sensible CPA tool will digest the CPA
> into a table that allows looking up the routing information in the most
> efficient manner. The only difference between them is where the table
> comes from.
>
> 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
> *************************************************************************************
>
> "Burdett, David" <> on 07/19/2001 03:17:41 PM
>
> To: "'Arvola Chan'" <>, Martin W Sachs/Watson/IBM@IBMUS,
> David Fischer <>
> cc: ebXML Msg <>, Pete Wenzel
> <>
> Subject: RE: PIP IDs
>
> Thanks Arvola !! You have saved me from writing an email. I absolutely
> concur with what you say ... you can have one "service"
> supporting multiple different business transactions. If we do this it also
> means that we can have one conversation involving multiple different
> business transactions, e.g. a 3A4 (Create Purchase Order) followed by a
> 3A8 (Change Purchase Order) where the change purchase order was for the
> order created by the create purchase order.
>
> Another use case is where you can have the same service used in multiple
> different collaborations for example consider the following two
> collaborations:
> Example 1, Invoice Payment:
> 1. BT1 - Present Invoice
> 2. BT2 - Make Payment
>
> Example 2, Pay Refund:
> 1. BT1 - Request Refund
> 2. BT2 - Make Payment
>
> Both of these involve making a payment which, in Business Transaction
> terms, would be carried out the same way.
>
> Where I think it gets really critical to separate the two is when you want
> to route messages. If Party, Service and Action are always the same,
> irrespective of the business process in which they are being used then you
> can use these three fields for routing purposes in a consistent way.
>
> On reflection this I think is one of the issues I have with always
> requiring a CPA as defined in the CPA/CPP spec as you can actually quite
> reasonably do routing in two different ways:
>
> look up the CPA from the CPA ID and route the message to the endpoint
> identified, or
> look up the Party, Service and Action in a table to identify where to
> send the message to.
>
> The former allows you to vary the endpoint very flexibly and alter where
> you send a message to depending on the business process you are in, the
> latter allows you to have simpler rules but with less flexibility.
>
> I think both use cases are valid ... and required ..
>
> David
>
> -----Original Message-----
> From: Arvola Chan [mailto:]
> Sent: Thursday, July 19, 2001 9:04 AM
> To: Martin W Sachs; David Fischer
> Cc: Burdett, David; ebXML Msg; Pete Wenzel
> 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 ()
> TIBCO Software (on loan to RosettaNet)
> +1-650-846-5046 (US-Pacific)
>
> ----- Original Message -----
> From: "Martin W Sachs" <>
> To: "David Fischer" <>
> Cc: "Burdett, David" <>; "ebXML Msg" <
> >
> Sent: Thursday, July 19, 2001 8:07 AM
> Subject: Re: PIP IDs
>
> In my opinion it makes more sense for Service to point to the PIP ID and
> action to point to the particular business transaction within the PIP. In
> other words one execution of a PIP is a conversation. I believe that some
> of the PIPs include multiple business transactions.
>
> 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
> *************************************************************************************
>
> David Fischer <> on 07/19/2001 10:45:54 AM
>
> To: "Burdett, David" <>
> cc: ebXML Msg <>
> Subject: PIP IDs
>
> David, in the F2F you mentioned the need for a new element to contain
> industry specific business process identifiers such as a RosettaNet PIP
> identifier. Could this be done with Service/Action where the Service would
> be something like RNet and the Action something like PIP3A1 (Request
> Quote)?
>
> <eb:Service>urn:services:RNet</eb:Service>
> <eb:Action>PIP3A1</eb:Action>
>
> Regards,
>
> David Fischer
> Drummond Group.
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to:
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to:
