[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: PIP IDs
Chris,
See my notes below <srh>.
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
christopher ferris <chris.ferris@east.sun.com> on 07/31/2001 04:12:58 AM
To: "Burdett, David" <david.burdett@commerceone.com>
cc: Martin W Sachs/Watson/IBM@IBMUS, "'Arvola Chan'" <arvola@tibco.com>,
David Fischer <david@drummondgroup.com>, ebXML Msg
<ebxml-msg@lists.oasis-open.org>, Pete Wenzel
<Pete.Wenzel@RosettaNet.org>, ebxml-cppa@lists.oasis-open.org
Subject: Re: PIP IDs
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.
<srh> This has not been my experience either. Engine logic is nicely driven
by external an configuration file, which at the software level is what a
CPA
is. However, David's words "not easy" I will interperet to mean as "alot to
buy into", which I would agree to. The CPA is not simple, and there has
been
clear feedback in the Dallas meeting along the lines.
I would add also that a good msh engine design that needs configuration
information would abstract away the detail of the CPA, and allow obtaining
that information from alternate places. For this design reason, I am not
in favor of *explicitly requiring* a CPA.
> 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.
<srh> I agree it should be as *aligned* as possible. That *could* mean some
common structure for fundamental information. That type of approach would
indeed make the CPA 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.
<srh> I agree.
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.
<srh> absolutely.
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:mwsachs@us.ibm.com]
> Sent: Sunday, July 29, 2001 6:32 PM
> To: Burdett, David
> Cc: 'Arvola Chan'; David Fischer; ebXML Msg; Pete Wenzel;
> ebxml-cppa@lists.oasis-open.org
> 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" <david.burdett@commerceone.com> on 07/26/2001 12:05:01
PM
>
> To: Martin W Sachs/Watson/IBM@IBMUS
> cc: "'Arvola Chan'" <arvola@tibco.com>, David Fischer
> <david@drummondgroup.com>, ebXML Msg
> <ebxml-msg@lists.oasis-open.org>, Pete Wenzel
> <Pete.Wenzel@RosettaNet.org>, ebxml-cppa@lists.oasis-open.org
> 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:mwsachs@us.ibm.com]
> Sent: Wednesday, July 25, 2001 8:51 PM
> To: Burdett, David
> Cc: 'Arvola Chan'; David Fischer; ebXML Msg; Pete Wenzel;
> ebxml-cppa@lists.oasis-open.org
> 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" <david.burdett@commerceone.com> on 07/25/2001 12:50:31
PM
>
> To: Martin W Sachs/Watson/IBM@IBMUS
> cc: "'Arvola Chan'" <arvola@tibco.com>, David Fischer
> <david@drummondgroup.com>, ebXML Msg
> <ebxml-msg@lists.oasis-open.org>, Pete Wenzel
> <Pete.Wenzel@RosettaNet.org>
> 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:mwsachs@us.ibm.com]
> 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" <david.burdett@commerceone.com> on 07/19/2001 04:51:03
PM
>
> To: Martin W Sachs/Watson/IBM@IBMUS
> cc: "'Arvola Chan'" <arvola@tibco.com>, David Fischer
> <david@drummondgroup.com>, ebXML Msg
> <ebxml-msg@lists.oasis-open.org>, Pete Wenzel
> <Pete.Wenzel@RosettaNet.org>
> 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: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
>
> ------------------------------------------------------------------
> 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-cppa-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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC