OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: PIP IDs


Chris/Scott

It really was not my intention to make "inflamatory" statements. If they
were, I absolutely apologise.

I also agree that having a configuration file is a good idea and can make
implementation easier. The problem with current "end-point to end-point"
CPAs is that they don't work when there is an intermediary. Consider this
example ...

TP1<------------ CPA 1 ------------>TP2

In this example CPA 1 specifies the entire agreement between TP1 and TP2 and
there are no problems with a single configuration file (CPA).

However in this example:

TP1<------------ CPA 2 ----------->TP2
TP1<--- CPA 3 --->IM<--- CPA 4 --->TP2

CPA2 agrees defines how TP1 and TP2 will carry out business in terms of
business processes and business transactions *only*.
CPA3 defines how TP1 sends messages to the intermediary (IM) and CPA 4 is
the equivalent for the IM and TP2. These agreements define the format and
structure of the messages but not the business process/transactions being
followed. The value add of the intermediary is that if TP1 and TP2 do use
different protocols or standards or different versions of documents then
they translate between the different protocols/versions.

I don't think the current CPA documents easily support this use case.

David

-----Original Message-----
From: Scott Hinkelman [mailto:srh@us.ibm.com]
Sent: Tuesday, July 31, 2001 6:30 AM
To: christopher ferris
Cc: Burdett, David; Martin W Sachs; 'Arvola Chan'; David Fischer; ebXML
Msg; Pete Wenzel; ebxml-cppa@lists.oasis-open.org
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





------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-cppa-request@lists.oasis-open.org


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC