RE: T2 The answer isn't always "you need a CPA"

[Martin W Sachs <mwsachs@us.ibm.com>]

David,

Your use case is, I think, confusing the request and response for a single
business transaction with having two different business transactions
defined.  If we assume that a BPSS instance document defines the business
transactions, then a request is followed by a response in the same business
transaction.  Both the request and the response have the same service and
action.

If the two applications are really two business transactions in the same
BPSS instance documents, the response for the first transaction is followed
by the request in the second one and that request then identifies the
correct service and action for itself and for its response.

If the two business transactions are in two separate applications, the
business transactions may be in separate BPSS instance documents. For this
case, some routing ambiguities have been identified and are on the CPA work
item list.  However service and action will not disambiguate them because
there is no requirement that service and action have distinct names in the
two BPSS instance documents. There were some suggestions which I don't
recall at the moment.  This is an item that requires joint action by the
two teams.  I have copied the CPPA list on this so that it will be seen by
Tony Weida who is keeping our database.

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 09/12/2001 03:08:28 PM

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   "'Dale Moberg'" <dmoberg@cyclonecommerce.com>, "Ian. C. Jones
      (E-mail)" <ian.c.jones@bt.com>, "William J. Kammerer"
      <wkammerer@novannet.com>, "ebXML Messaging (E-mail)"
      <ebxml-msg@lists.oasis-open.org>
Subject:  RE: T2 The answer isn't always "you need a CPA"



Marty

Marty, you have not answered my original questions. I don't want to restate
the use case, covered in my earlier email, which I don't think the current
spec supports. Can you look at that use case and propose a solution to
solving the problems it presents.

Simply asserting "You are avoiding the CPA" doesn't help. I think there is
a
problem that needs to be fixed. If the problems I presented aren't problems
then the matter is closed. So far though, I have not seen an argument that
says these problems do not exist.

Regards

David

-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Wednesday, September 12, 2001 11:51 AM
To: Burdett, David
Cc: 'Dale Moberg'; Ian. C. Jones (E-mail); William J. Kammerer; ebXML
Messaging (E-mail)
Subject: RE: T2 The answer isn't always "you need a CPA"



David,

A collaborative business process is not possible if the two parties don't
agree on the details of the collaboration and of the message exchange.
Whether they do it by phone or by sharing a CPA is immaterial.  If the two
parties don't agree on the meaning of each possible value of service and
action, then each party still has to know its own service and action and
the service and action to be used by the other party. You are avoiding the
CPA and avoiding the Process Specification document.  You are not
eliminating the need for the two parties to know the equivalent
information.

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 09/12/2001 02:40:09 PM

To:   "'Dale Moberg'" <dmoberg@cyclonecommerce.com>, Martin W
      Sachs/Watson/IBM@IBMUS, "Ian. C. Jones (E-mail)" <ian.c.jones@bt.com>
cc:   "William J. Kammerer" <wkammerer@novannet.com>, "ebXML Messaging
      (E-mail)" <ebxml-msg@lists.oasis-open.org>
Subject:  RE: T2 The answer isn't always "you need a CPA"



Dale/Marty

I am not aiming to bloat the message header I am trying to fix a real
problem the same one as you. For example you say below ...

>>>The MSH has been architected under the assumption that it has in its
possession information that enables it to do "(send or receive)transport,
(un-)packaging, and (application layer) routing" for a given
sender/receiver
pair<<<

I would assert that with the current spec, the receiving MSH often will not
have the information needed as it assumes the sender of a message knows
what
to put in there and sometimes they won't. I don't think it is acceptable
that before you send anyone a message you HAVE to pre-agree in a separate
out-of-band conversation what data is to be used in the service and action
for any response.

I tried to explain the problem in my original email as well as include a
suggested solution see ...

http://lists.oasis-open.org/archives/ebxml-msg/200109/msg00079.html

The only feedback so far is "I don't want anything else in the header"
whilst the problem I raised has not been discussed. I'd really appreciate
it
if you would read the original email and:
1. Agree (or not) that there is a problem - and if not say why.
2. If you agree there is a problem suggest an alternative solution if you
don't like the one I have proposed.

I'd also like to repeat three questions from an earlier at
http://lists.oasis-open.org/archives/ebxml-msg/200109/msg00115.html email
to
which no-one has yet responded ...

"1. How does the recipient of a message know what to put in the Service and
Action for the message they return in the absence of a CPA (Please read the
Bank Payment example for more details)
2. To use RefToMessageId, the sender of a message, where a reply is
expected, would have no option but to save the data from the EVERY message
even though the message was sent with deliverySemantics of BestEffort. This
should not be necessary. How can it be avoided?
3. If you are using PartyId, Service and Action to route a message, how do
you know which MSH at the Party should receive the message when Service and
Action have fixed values (as in an error message)? With the current spec, a
Party could only have one MSH ... even if it were IBM."

A few more detailed comments below.

Regards

David

-----Original Message-----
From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
Sent: Wednesday, September 12, 2001 7:41 AM
To: Burdett, David; Martin W Sachs; Ian. C. Jones (E-mail)
Cc: William J. Kammerer; ebXML Messaging (E-mail)
Subject: RE: T2 The answer isn't always "you need a CPA" was RE: T2
PLEASE REA D -Suggested Change - add "From" Service and Ac tionto the
header



In response to David Burdett msg:

>From: Burdett, David [mailto:david.burdett@commerceone.com]
>Sent: Tuesday, September 11, 2001 10:09 PM
>To: 'Martin W Sachs'; Ian. C. Jones (E-mail)
>Cc: 'William J. Kammerer'; ebXML Messaging (E-mail)
>Subject: T2 The answer isn't always "you need a CPA" was RE: T2 PLEASE
>REA D -Suggested Change - add "From" Service and Ac tionto the header
>
>Marty (and also Ian Jones)
>
>You said ...
>
>>>The solution of piling additional information into the message header
to
>make up for the lack of a CPA should not be considered acceptable.<<<>
>
>The ebXML messaging group has **agreed** that we want to separate the
ebXML
>Messaging and CPPA specs so that they can be implemented independently
or
>together (Ian, please correct me if I am wrong).


David B,

All the groups are aiming for modularity,
which means each spec can work with
the other Oasis specs
as well as with other approaches.

What is puzzling is why you think
this principle justifies bloating
the ebXML message header.

The MSH has been architected under the
assumption that it has in its
possession information that
enables it to do "(send or receive)transport,
(un-)packaging, and (application layer)
routing" for a given sender/receiver
pair and to do those operationss down
to a granularity of a
specific BP (currently identified
by a service and action value).

While a CPAid _could_ allow a MSH
to look up sender, receiver, service,
action etc. in principle, it has been
agreed so far to put these specific items
into the header. Other items, like the
messageId and RefToMessageId, are clearly
per message values, not "per channel"
values, and so cleanly belong in
the header. ConversationId is another
one of these more "dynamic" values
of the message. Same for the dateTime.
Etc.

However, it has never been agreed, to my
knowledge, that if a use case
shows that a given item of information
would be useful configuration information
for a MSH, it should go in the header.
Yet you seem to be assuming this.
<db>I am not doing this. I believe there is a real problem that needs to be
fixed and the best way I can see to fix it is with additional information
in
the header. Let's try and agree that there is an actual problem.</db>

You offer up a "use case" where an
application could make use of some information
to find out what application had submitted
an initial request payload to it, as a part
of processing a response. The point is that
the reftomessageid, along with the conversation id,
are already available to support
this correlation of response to request.
<db>I agree that they can, but then it would require any message that is
expecting a response must be saved so that the correlation can be
done.</db>

The MSH, in an implementation
specific way, is to then make the payload
available to the right service. It may make use
of service and action values, even cpaid,
in figuring out how to handle the response.
But the specific way it makes use of those
values has so far been left as an implementation
detail.
<db>My point is that unless the sender of a request message tells the
process that is to process the request what should go in the service and
action of the response, then the sender of the response does not know what
to put in these fields.</db>

I can understand how leaving the semantics
of the use of these values open to MSH
interpretation might be regarded as a
weakness. But that weakness is not something
that adding yet more uninterpreted fields
to the header will cure.
<db>They are not uninterpreted fields. There is a very simple rule that
says, if you receive a message containing a FromService and a FromAction
then you use these values to populate the ToService and ToAction of any
normal response. For errors, you use the ToService only and inciate in the
ToAction that it is an error. The values in these fields is open to
interpreation which is as it should be.</db>

So I must agree with Marty and several others
on this list, that your proposed change
to service and action, neither fixes a bug nor provides
needed clarification.

Dale Moberg

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>