David,
Please see my comments below.
Cheers,
Chris
"Burdett, David" wrote:
>
> Hi Marty ...
>
> I think there is more of a inconsistency rather than a separation between
> the specs. As using the CPA and the Messaging specs together is not easy.
This has not been my experience. Quite the contrary I find them
quite complementary. If the statement is more along the lines of:
"we find it difficult to modify our implementation to leverage a CPA..."
then that may be so. However, a blanket statement such as the above
needs substantive evidence to back the (fairly inflamatory, IMO) claim.
> How about the following as a way forward ...
>
> 1. The Messaging Specification:
> a) Identifies the set of parameters that need to be agreed/shared for MSHs
> to interact successfully and that this information can be held:
> i) within the ebXML Message Header, or
> ii) elsewhere as separately agreed
> b) States that the CPAId identifies the values to be used for the
> information that needs to be agreed.
The specification pretty much does this now, and that IMHO is part of the
problem. I think that rather than make continuted efforts to further
separate these specs, we should instead be working more closely
to align them and to make the use of a CPP/A more compelling.
> c) States that **a** method of representing and exchanging the data that
> needs to be agreed is defined by the CPPA specification
> 3. The CPPA specification describes how those MSH parameters can be recorded
> and linked and related to a business process/transaction, etc
>
> I think that could meet all of our objectives. Does this make sense?
I disagree that it meets our objectives.
A natural aspect of any b2b exchange is that there is an AGREEMENT
between the parties. Even an IMPLICIT agreement is an AGREEMENT.
I will grant that without a dynamic negotiation
capability, that certain use cases are made more difficult. I DO agree
that we should resolve this as part of the work going forward.
I also agree that we should look to making the CPP/A as well as the
Message Service headers more generally useful by making them more modular.
Finally, I also agree that we should be looking to make the
Message Service and the CPP/A more useful/applicable in multi-hop
environments. I don't think that we've really done this area
effectively as we were possibly too focused on getting the
point-to-point usage right.
>
> David
>
> -----Original Message-----
> From: Martin W Sachs [mailto:]
> Sent: Sunday, July 29, 2001 6:32 PM
> To: Burdett, David
> Cc: 'Arvola Chan'; David Fischer; ebXML Msg; Pete Wenzel;
>
> Subject: RE: PIP IDs
>
> David,
>
> I believe that we have achieved the desired separation between the two
> specs, all too well. As I pointed out earlier, one of my colleagues who is
> doing a prototype implementation of the message service is having a lot of
> trouble understanding those aspects related to where the configuration
> information comes from. I have asked the CPPA team to include among its
> work items, the appendix which is supposed to describe the CPA-related
> information used by the message service. Think of it is "How to Interpret
> the Message Service Specification when you are using a CPA."
>
> 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/26/2001 12:05:01 PM
>
> To: Martin W Sachs/Watson/IBM@IBMUS
> cc: "'Arvola Chan'" <>, David Fischer
> <>, ebXML Msg
> <>, Pete Wenzel
> <>,
> Subject: RE: PIP IDs
>
> Marty
>
> You said ...
>
> >>>The CPPA team is always happy to receive suggestions for improving the
> CPP-CPA definition although we would not be too happy to receive a proposal
> to simply eliminate it.<<<
>
> ... that is not my intention. I do think that a CPAs have a role it's just
> that I would like to see a clear separation between the ebXML Messaging and
> the CPA specs so that they can be used independently of one another. Chris
> Ferris described this well in a recent email.
>
> David
>
> -----Original Message-----
> From: Martin W Sachs [mailto:]
> Sent: Wednesday, July 25, 2001 8:51 PM
> To: Burdett, David
> Cc: 'Arvola Chan'; David Fischer; ebXML Msg; Pete Wenzel;
>
> Subject: RE: PIP IDs
>
> David,
>
> The thrust of the prior discussion was along the lines of "it can't be
> done". From that viewpoint, it is sufficient to develop an existence proof
> consisting of one way of doing whatever it is (generating the necesary
> configuration information). Certainly, there is nothing in the CPP-CPA
> specification that precludes RosettaNet or any other industry community
> from setting up a small number of prototype CPAs that members of the
> community can use.
>
> The CPPA team is always happy to receive suggestions for improving the
> CPP-CPA definition although we would not be too happy to receive a proposal
> to simply eliminate it.
>
> 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/25/2001 12:50:31 PM
>
> To: Martin W Sachs/Watson/IBM@IBMUS
> cc: "'Arvola Chan'" <>, David Fischer
> <>, ebXML Msg
> <>, Pete Wenzel
> <>
> Subject: RE: PIP IDs
>
> Marty
>
> Apologies for the delay in responding ... I've been busy elsewhere.
>
> I agree with everything you say about how databases work and how they
> **could** be used to solve the problem. It's just that you are
> pre-supposing
> a particular internal design for a solution when there are other
> alternatives. I also disagree that the information **has** to be entered
> into each partners system.
>
> For example, a community of users, e.g. RosettaNet could define a set of
> three or four standard "agreements" that everyone should use for messaging
> which exclude partner specific information, e.g. URLs and certificates. The
> URL and other information could then be recorded in a registry (UDDI?)
> which
> a trading partner could look up to determine where to send a message. This
> information could also be cached.
>
> Once the URL was determined, then a message could be sent where the CPAId
> referenced one of the "standard" agreements. If the sender of the message
> was not previously to the message recipient then they could look up the
> information in the registry and decide what to do with the message.
>
> Marty, I am not saying that your approach is wrong, it's just that there
> are
> alternaive equally valid approaches which the current definition of the CPA
> does not easily support. I think we should support both. Do you agree?
>
> David
>
> -----Original Message-----
> From: Martin W Sachs [mailto:]
> Sent: Friday, July 20, 2001 7:17 AM
> To: Burdett, David
> Cc: 'Arvola Chan'; David Fischer; ebXML Msg; Pete Wenzel
> Subject: RE: PIP IDs
>
> David,
>
> The usual approach to digesting information from CPAs is to have a database
> that has an entry for each CPA. Hence your problem about all the messages
> from company A to company B going to the same endpoint doesn't exist. For
> each message, the middleware will look at the CPAId and get the right
> information out of the database. Of course, once a conversation starts, a
> smart system will cache the configuration information for that conversation
> so it doesn't have to go back to a disk-based database on every message.
>
> Database technology has existed for generations that can execute query or
> an update against multiple selected rows.
>
> The rule in your second paragraph is certainly support when all those
> messages are associated with the same CPA. For the more general case that
> you have in mind, as I said, database technology is well up to it. ...and
> don't forget that the changes you have in mind are very infrequent compared
> to the frequency of messages in a large, active system.
>
> Your third paragraph: I disagree. The current perception is that whether
> there is a CPA or not, the configuration information has to be entered into
> each partner's system and managed there. Some people believe that the CPA,
> with suitable tools, is a lot easier to use than the manual methods.
>
> ****************************************************************************
>
> *********
>
> 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 04:51:03 PM
>
> To: Martin W Sachs/Watson/IBM@IBMUS
> cc: "'Arvola Chan'" <>, David Fischer
> <>, ebXML Msg
> <>, Pete Wenzel
> <>
> Subject: RE: PIP IDs
>
> 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:]
> 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" <> 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:
>
> ------------------------------------------------------------------
> 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:
>
> ------------------------------------------------------------------
> 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:
