Marty and Prasad,
It would be useful to assemble some examples/scenarios/etc
that show why conversationId, service, and action
(and I would add Role in there to the mix) fail to capture
what needs to be asserted about multilateral conversations/flows.
I suspect that it is true, but we are saying that there
is something
not expressible by means of certain semantic elements, so
we need to be able to show and agree upon some of what is being
left out.
There was general agreement for
v1.0 that multilateral CPAs
were not in scope, but, as I recall,
it was more because there wasn't
enough time to sort all the issues out
than a highly principled omission!
I think we are also going to need to revisit terminology,
because the tag "Service" has gotten just too tangled
up now to use. For example, (referring to the
recent PIP threads), talking about the
selling service or buying service is semantically like
what had previously been called the role in a BP.
[I had always thought that the cluster part ("3A" )of a PIP
designation was like a service (which I construed
as a bundle of "actions"), whereas the "4" in 3A4 was
like the Action designator. Returning the POAck
was the Action that was the business level Response
to the PO (3A4), which was the Request. But that
might have been entirely my own picture!] And this is
still while thinking about conversations, and
before we even get to the web "services" turf!
Finally, I think the concern with what information
is needed for "routing" to the "application"
(and the related process, which is receiving payload(s)
from the application and knowing how to
send it off), are basically kinds of information
that pertain to the "private intranet side of
integration" and not to the secure packaged
transport or public side of integration. This information
is important for the configuration of a MSH on its
"application" interfacing sides, but is not clearly
something that is needed for a CPA when understood
as an agreement on those factors needed to
exchange business data interoperably. We have
always had a tension in deciding how much
of this information to capture in CPPs or a CPA.
One place to start in rethinking this issue is
what capabilities are being advertized when the
"service" , "action" and "role" fields are included
in a CPP? For example, for a recipient,
are we saying anything more than
we can handle the incoming payload so that
the output response payload(s) can eventually be
made available back to the sender (or to other
interested parties in the multilateral case)?
Similar issues can be posed about what is
being claimed within the CPA context. The
point is that the CPA pertains mostly to the contract
among/between MSHs, and not to
contracts between MSHs and "applications".
-----Original Message-----
From: Martin W Sachs
Sent: Fri 7/20/2001 7:07 AM
To:
ebxml-cppa@lists.oasis-open.org
Cc:
Subject: message
routing
FYI
*************************************************************************************
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
*************************************************************************************
----------------------
Forwarded by Martin W Sachs/Watson/IBM on 07/20/2001
10:06 AM
---------------------------
Prasad Yendluri
<pyendluri@webmethods.com> on 07/19/2001 03:58:18
PM
To: Scott
Hinkelman/Austin/IBM@IBMUS
cc: Arvola Chan
<arvola@tibco.com>, Martin W
Sachs/Watson/IBM@IBMUS,
David Fischer
<david@drummondgroup.com>, Burdett
David
<david.burdett@commerceone.com>, ebXML
Msg
<ebxml-msg@lists.oasis-open.org>, Pete
Wenzel
<Pete.Wenzel@RosettaNet.org>
Subject: Re: PIP
IDs
Folks,
I think I agree with Scott, Arvola and
Marty :). Bottomline is, the current
model based
on the
ConversationId, Service and Action is too inadequate to represent
an
arbitrarily
large "conversation", that is potentially
"multilateral" (as opposed to the
current
bilateral) and
consists of >= 1 sub bilateral business processes.
I think this
would be one of important pieces of work for the next version
of the
MS
spec. We need to come up with a more comprehensive, generic, robust
and
extensible model
of a "conversation", that identifies a specific
exchange belonging to a
"conversation", a
business process instance
within, the specific action with that process,
the originating
and
receiving parties, the originating and receiving service entities
etc.
Regards, Prasad
-------- Original Message
--------
Subject: Re: PIP IDs
Date: Thu, 19 Jul 2001 11:41:19
-0700
From: Scott Hinkelman <srh@us.ibm.com>
To: Arvola Chan
<arvola@tibco.com>
CC: Martin W Sachs
<mwsachs@us.ibm.com>,David
Fischer
<david@drummondgroup.com>,Burdett
David
<david.burdett@commerceone.com>,ebXML
Msg
<ebxml-msg@lists.oasis-open.org>,Pete
Wenzel
<Pete.Wenzel@RosettaNet.org>
>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.
Again, my view on this is to define a Qualified
Invocation sequence
generically with an arbitrary number of tags,
and
drop the tag names "Service" and "Action". Just as ebXML Message
Service
defines a SOAP+Attachments Profile,
RosettaNet would define an
ebXML Message Service Profile, which would
contain mapping to its
PIP,etc,etc, (its invocation qualification).
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
Arvola
Chan <arvola@tibco.com> on 07/19/2001 09:03:32
AM
To: Martin W Sachs/Watson/IBM@IBMUS, David
Fischer
<david@drummondgroup.com>
cc: Burdett David
<david.burdett@commerceone.com>, ebXML
Msg
<ebxml-msg@lists.oasis-open.org>, Pete
Wenzel
<Pete.Wenzel@RosettaNet.org>
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-cppa-request@lists.oasis-open.org