Title: RE: PIP IDs
Dale
Here
is my first cut of the requirements for CPPA that are needed to support
intermediaries. It suggests the development of several different types of
CPA/CPP ...
1.
Transport CPP. This specifies the MSH parameter values that can be applied to
the exchange of messages that are independent of the business process, business
transaction or the needs of an individual party. A typical use of his would be
by a Community of users that agreed to exchange all messages in one (or a few
different) ways.
2.
Business Process CPP, Specifies a way of exchanging data/documents/messages that
meets the needs of a specific business process or business transaction. The CPP
should omit any data that is specific to any transport or communications
protocol. (Is this WSFL?). A typical use of this would be a standards group that
wanted to define some standard business processes that they had developed, or a
Community of Users that had identified the subset of standard transactions that
they would use.
3. An
Endpoint CPP, that identified a series of URLs and Security data that could
belonged to a Party to which messages could be sent
4. A Community CPA. This would be a combination
of Transport and Business Process CPAs which represented the standard way by
which members of that Community would carry out its business. It would omit any
specific Party information (e.g. URLs or security
information)
5. A
Party CPP that:
a) Referenced Transport CPPs, Business Process CPPs, and/or Community CPAs and
EndPoint CPPs. The EndPoint CPPs could apply to either:
i) all interactions with the
Party, or
ii) one or more combinations
of Transport CPPs, Business Process CPPs ro Community CPAs
6. A
Party-to-Party CPA.. This could either:
a) Reference a Community CPA, excluding any Business Processes/Transactions they
did not support, and:
i) add EndPoint CPP
information that applies to all Business Processes/Transactions, which could be
over-ridden by
ii) adding EndPoint CPP
information that applied to individual Business Processes/Transactions, or
...
b) Create a one-off CPA that included Transport and Businss Process level data
as well as URL and security data as currently defined.
Intermediaries could then use these CPAs/CPPs as
follows:
1. The
CPAId in the Message Header would reference a Community CPP or a
Party-to-Party CPA
2. The
CPA Id in the Via element would reference an individual EndPoint CPP (or part of
a CPP) and optionally a Transport CPP to identify where messages should be sent
to.
I am
not sure if these ideas are completely baked, but hopefully we can start a
useful discussion.
David
-----Original Message-----
From: Dale Moberg
[mailto:]
Sent: Sunday, July 29, 2001
9:46 PM
To: Burdett, David; Martin W Sachs
Cc: Arvola
Chan; David Fischer; ebXML Msg; Pete Wenzel
Subject: RE: PIP
IDs
David,
I
welcome your contributions to the Oasis CPPA WG and to make them work with
intermediaries
as
well as in the peer to peer case. But it is not helpful to have
objections raised to the
work
that are not constructive, and that provide distractions by raising
unfounded doubts
(that the specifications are tied to some specific, very specialized,
software implementations,
for
example). This is so far from being true that I felt it necessary to
spend some effort explaining why
these objections are faulty.
As
far as not supporting intermediaries, I hope that you can help us arrive at
what
is
needed in the way of requirements, first of all.
I
did not mean to ruffle your feathers about this, and I would prefer
to have you
be
interested in helping us specify what is needed for intermediaries. If
that
happens, we won't have to worry about what might explain lack of
interest!
Thanks
Dale
[Dale
Moberg] -----Original Message-----
From:
Burdett, David [mailto:]
Sent: Friday,
July 27, 2001 6:14 PM
To: Dale Moberg; Martin W Sachs
Cc:
Arvola Chan; David Fischer; ebXML Msg; Pete Wenzel
Subject: RE: PIP
IDs
Dale
You
said ...
>>> 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, <<<
This is not helpful and
unfair.
You seem to be suggesting (forgive me if I am wrong)
that I, and therefore Commerce One, are against the use of CPAs for commercial
reasons. This is just not true.
I
could also be completely scurrilous and suggest that the reason the CPA spec
only considers peer-to-peer is to make life more difficult for companies that
require the use of intermediaries ... but that would not be helpful and
probably not true either.
So lets get to the real reasons
...
Commerce One works in standards groups for the reasons
many companies do, partly altruistic partly commercial. The altruistic bit
means that if you are developing standards you must be sensitive to the needs
of others, even if those needs help your competitors and not your own company.
The commercial bit means that if a standard that you want to use does not meet
your own needs then you musty strive to get the standard changed. The current
CPA spec falls into this latter category as, in my opinion
(or is that
perception?) it only properly supports
peer-to-peer and does not work effectively when intermediaries are
involved
I think we should work together to fix the CPA spec
so that it supports peer-to-peer and intermediary based architectures equally
well. We will all get a better spec by doing
that.
Does
this make sense? I'm prepared to commit myself and Commerce One to
help make this happen. Do you agree?
David
-----Original Message-----
From: Dale Moberg
[mailto:]
Sent: Thursday, July 26, 2001
10:14 AM
To: Burdett, David; Martin W Sachs
Cc: Arvola
Chan; David Fischer; ebXML Msg; Pete Wenzel
Subject: RE: PIP
IDs
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:]
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:
