[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: message routing
David,
The whole point of putting quantities like service and action in the
message header is that they enable routing directly to the application's
proper software entry point without something deeper in the system having
to parse the payload to figure out what is to be done with the message. The
question is whether the current set of message header quantities (service,
action, CPAId, conversationId, and, I hope, refToMessageId) is or isn't
sufficient for any conceivable application software structure. Arvola has
pointed out that two levels, service and action, are not sufficient and we
need to come up with a more general hierarchy.
Let's not confuse service/action and role. Service/action represents the
hierarchy of the application software structure; role represents the party
that performs the service in question.
Karsten Riemer has pointed out that the BPSS already provides for reusable
modules (representing specific services) that an be incorporated into a
BPSS instance document that represents a larger collaborative process.
Role, mentioned in the CPA is the anchor for connecting a particular party
with a particular role in the BPSS instance document. So, you might say
that role in the CPP is advertising which role in the BPSS document the
party plays. (I am "seller" vs. I am "buyer").
Service and action in the CPP/CPA enable specific properties defined in the
CPP/CPA, such as particular delivery channels, to be associated with
specific business transactions in the BPSS instance document. While service
and action in the CPP are the same as service and action in the message
header, they serve a different purpose in the two places. As I just said,
in the CPP/CPA, they are anchors for properties like specific delivery
channels. In the message header, they are part of the information for
routing the message to the appropriate software entry point.
How a message is handled at the recipient is up to the recipient. However
the whole purpose of teams like us is to figure out how to do things that
assist the job of the application writer. They are called operating
systems and middleware. It is well known that application-independent
middleware can play a big role in simply and efficiently routing the
messages to the right places, as long as the message header contains
elements that help the middleware do its job without looking into the
payload.
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 03:40:35 PM
To: "'Dale Moberg'" <dmoberg@cyclonecommerce.com>, Martin W
Sachs/Watson/IBM@IBMUS, ebxml-cppa@lists.oasis-open.org
cc: "ebXML Messaging (E-mail)" <ebxml-msg@lists.oasis-open.org>
Subject: RE: message routing
Dale
I agree with a lot that you have to say. But to call out a few points ...
>>>I think we are also going to need to revisit terminology, because the
tag "Service" has gotten just too tangled up now to use.<<<
I agree. What I think we are really lacking is some good examples that
show the relationship between a Business Process Collaboration, Business
Transaction, Role, Service and Action. I have a clear picture in my mind
of the relationship ... but I don't know if everyone will agree. I hope to
send something to the list soon that we can have a constructive discusion.
>>> ... talking about the selling service or buying service is
semantically like what had previously been called the role in a BP.<<<
I think they are very similar however there are some differences to my
mind. Specifically, I think that services are re-usable in many roles and
therefore many business processes. For example consider a company which
sends an invoice to one of their customers and also makes an insurance
claim of some kind ...
EXAMPLE 1
Buyer Seller
<----------------------Invoice
Invoice Response ------------>
...
Payment --------------------->
<-------------Payment Response
EXAMPLE 1
Insurer Insured
<------------------------Claim
Claim Response -------------->
...
Payment --------------------->
<-------------Payment Response
The "Payment" part could be common to both even though the business
process and the roles are the same. It could also result in the same
messages being sent to the company's bank. I don't think that the bank
would want to offer two different payment "services" just because they are
part of a different business process.
>>>... what capabilities are being advertized when the "service" ,
"action" and "role" fields are included in a CPP? or 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 nterested parties in the multilateral case)?<<<
I don't think so. How a message is handled by the recipient is up to that
recipient. The sender of the message should not need to know.
Regards
David
-----Original Message-----
From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
Sent: Friday, July 20, 2001 8:57 AM
To: Martin W Sachs; ebxml-cppa@lists.oasis-open.org
Subject: RE: message routing
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
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC