David,
I do not think that any illustrative remarks Marty might
have provided about how a MSH
might store its configuration data forms a
basis for showing some technical shortcoming
in CPPs or CPAs.
The essential point is that the CPP and CPA schemas define
standardized patterns to exchange(!) collaboration protocol
profiles and agreements. The internal or distributed "storage"
of that information (along with other configuration information
the MSH will need) is not something we are specifying. So
the alternative storage options you raise
are irrelevant to the basic purpose
of CPPs and CPAs-- which is the specification of standardized
ways to exchange information about collaboration protocols.
This standardization is hoped to be one step in a continuing
effort to make configuration of collaborations more automated
and less onerous (less costly) for IS departments.
Likewise, while we do in effect insist that there be one
"primary key" to a collaboration profile record in its internal
representation (whatever that might be) which is, of
course, the cpaid, we do not assert that the cpaid is the only
primary key, or even that the cpaid is the primary key
that any MSH must use as a primary key
in its implementation.
So I do not believe that your point that we are somehow
constraining
software implementations is one that has a very substantial
foundation.
There may be reasons to not be interested in trying to make
peer-to-peer collaboration configuration easier. One would be
that
you are interested in alternative non peer-to-peer architectures
based
on "nanny intermediaries." That might explain a lack of
interest
in CPPs and CPAs, though I think even nanny architectures will
ultimately
benefit from things similar to CPPs and CPAs, such as the
descendents
of WSDL, or the joint offspring of our pioneer CPPA and WSDL
ancestors.
But I do not think that your lack of interest in such technologies
should be regarded as a technical problem to solve by those of us
who
are interested in pursuing these technologies.
Dale Moberg
-----Original Message-----
From: Burdett, David
Sent: Wed 7/25/2001 9:50 AM
To: 'Martin W Sachs'
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: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