OASIS ebXML Messaging Services TC

 View Only
  • 1.  RE: PIP IDs

    Posted 07-19-2001 15:50
    
    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