OASIS ebXML Messaging Services TC

 View Only
  • 1.  Re: PIP IDs

    Posted 07-19-2001 14:43
    >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)