Re: PIP IDs

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

David,

I disagree;-) If there are separate CPAs for each message
that xyz sends to IBM, then indeed, it might be cumbersome
to effect a change as to the URL that the messages should
be sent. However, there is no reason why this should be
the case. A CPA can describe all of the exchanges between
parties in a single instance and that would allow for all
message exchanges to share the same Transport binding information.
You could then effect the change to the Endpoint URL with a
single edit.

Also, consider that it may be the case that not ALL messages
between two parties are necessarily sent to the same URL. A
single rule as you describe is therefore inadequate.

Now, don't read this to infer that I think that CPAs are
necessarily perfect for all circumstances. As I think has
been pointed out, multiparty exchanges are not represented.
This should indeed be addressed by the new CPPA TC when it
convenes.

I also hear you regarding the perception that the CPA is the
only way to specify the information. However, what should be
clearly understood is that the CPA is the interoperable representation
that parties can share, regardless of runtime implementation,
not necessarily what the runtime uses directly.

Cheers,

Chris

"Burdett, David" wrote:
> 
> Marty
> 
> I agree that a sensible CPA tool should digest the CPA into a table that
> allows look up in an efficient manner. The problem is that I am not sure
> that it would (or could) actually do it. For example, if you wanted to use a
> very simple routing rule, e.g. "all the messages that company xyz sends to
> IBM go to one URL", then the CPA processor would have to **infer** this rule
> from analyzing all the CPAs that define the individual collaborations
> between xyz co and IBM. This type of inference processing is both hard to do
> and un-reliable since the inference processor cannot assume that the next
> CPA it receives will not follow the rule. Secondly, if you wanted to change
> the URL for all these messages then you would have to change all the CPAs
> rather than just change the single simple rule.
> 
> To solve this problem, you need to be able to express **directly** a rule in
> its simplest form, (e.g. all messages from xyz co for IBM go to one URL).
> However the current CPA structure doesn't support this type of rule
> definition (Is that correct?).
> 
> Finally, the current perception of a CPA is, IMO, that it is the **only**
> way to specify the information required for ebXML Messaging to work when
> clearly there could be more appropriate ways of specifying the information
> for some circumstances. Hence my reasons for wanting to be able to use ebXML
> Messaging without CPAs.
> 
> Finally, I do think that CPAs are a good idea especially where you have
> point-to-point communication, they're just not the only good idea ;)
> 
> Regards
> 
> David
> 
> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: Thursday, July 19, 2001 12:48 PM
> To: Burdett, David
> Cc: 'Arvola Chan'; David Fischer; ebXML Msg; Pete Wenzel
> Subject: RE: PIP IDs
> 
> 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
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org