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
�