Re: PIP IDs

[christopher ferris <chris.ferris@east.sun.com>]

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" <david.burdett@commerceone.com> on 07/19/2001 03:17:41 PM
> 
> To:   "'Arvola Chan'" <arvola@tibco.com>, Martin W Sachs/Watson/IBM@IBMUS,
>       David Fischer <david@drummondgroup.com>
> cc:   ebXML Msg <ebxml-msg@lists.oasis-open.org>, Pete Wenzel
>       <Pete.Wenzel@RosettaNet.org>
> 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:arvola@tibco.com]
> 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 (arvola@tibco.com)
> TIBCO Software (on loan to  RosettaNet)
> +1-650-846-5046 (US-Pacific)
> 
> ----- Original Message -----
> From: "Martin W Sachs" <mwsachs@us.ibm.com>
> To: "David Fischer" <david@drummondgroup.com>
> Cc: "Burdett, David" <david.burdett@commerceone.com>;  "ebXML Msg" <
> ebxml-msg@lists.oasis-open.org>
> 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 <david@drummondgroup.com> on  07/19/2001 10:45:54 AM
> 
> To:   "Burdett, David" <david.burdett@commerceone.com>
> cc:   ebXML Msg <ebxml-msg@lists.oasis-open.org>
> 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: ebxml-msg-request@lists.oasis-open.org
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org