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



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





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


Powered by eList eXpress LLC