Re: [ebxml-cppa] MessagingCharacteristics and the Messaging groupssyncReply QOS flag

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

Dale,

Issue 1

If SyncReply has to be per message, then the CPA should indicate that it is
per message.  Once two partners agree that it is per message, then it
should be implicit that each of them receiving a message must honor the
flag whichever way it is set in the message.

In other words, to me it doesn't make sense for the CPA to indicate
agreement on whether the flag is honored not.  The CPA can indicate the
following possibilities for SyncReply:

   Used for all messages over this delivery channel (flag in message
   ignored
   Not Used for any message over this delivery channel (flag in message
   ignored)
   Indicated Per Message; receiving party must honor the flag whichever way
   it is set in the message.

I think that you have a third case that may not be necessary.  In a CPP,
canUse... and mustUse... are really equivalent since the per-message mode
is any negotiable in creating the CPA.

Issue 2

The MSH sending the message knows what is in the CPA and therefore whether
or not the response will come back on the same channel as the original
message.  If the CPA indicates different channels for the request and the
response, the response has to be asynchronous and the message should not
specify syncReplyMode.  With the sets of cases that you and I are
suggesting, if the CPA indicates that syncReply is per message, then the
two parties' paired delivery channels must permit this.  This is another
example of why we may have erred in simply defining a delivery channel as
receive properties.

Your point at the end of the first paragraph is just an example of the
general rule that the more options, the more complexity.  I believe that
all those checks would have to be made.

The rest of your posting amplifies the point that the more flexibility, the
more complexity.

I believe that the simplest case is when syncReply is a static property of
the delivery channel (or pair of delivery channels), stated in the CPA.
Would it not be sufficient for an application that requires per message to
define two different actions in the BPSS (one for messages requiring sync
replies, the other for nonsync replies).  These could then have two
different delivery channels associated with them. We should see a real use
case that demands that the same action be able to send some messages with
syncReply=true and others with syncReply=false.

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
*************************************************************************************



Dale Moberg <dmoberg@cyclonecommerce.com> on 11/09/2001 12:15:57 PM

To:    ebxml-cppa@lists.oasis-open.org
cc:
Subject:    [ebxml-cppa] MessagingCharacteristics and the Messaging groups
       syncReply QOS flag





Issue 1: If the Messaging group does retain their
syncReply boolean, and it is used in
a per-Message fashion (which apparently it can be),
should a CPA be able to indicate agreement upon
whether the flag is honored or not?

If we decide to make this functionality a matter
for a CPA, the elements/attributes used should, IMO,
go under our new proposed MessagingCharacteristics element
(I just made up that tag--Avola is the tag-meister!)

I could imagine that the CPP/As could use
attributes or enumerated values
(I am open to the syntactical
treatment adopted) like:

canUseSyncReply -- meaning a willingness to
  adopt per Message values (can send either
  asynchronously or not) (Mainly a CPP semantic item.)
syncReplyFlagIgnored -- meaning that whatever
  DeliveryChannel(s) are agreed to are used, no
  perMessage changes (CPA or CPP semantic value)
mustUseSyncFlag -- meaning to adhere to the flag
  and when absent, adopt the convention that it
  is equivalent to having a false value
  (CPP or CPA semantic value)

Issue 2:
Also, currently the MSG spec says that the presence
of the flag means that any response
must be returned synchronously.
How do we understand the behavior
requested, when the actual responses can
go back along different return paths?
Within the CPPA, we have
several options: Messaging Signals only (other
stuff along asynchronous path(s),
Messaging Signals Plus BP Signals
(with just the BPResponse back along the asynch path),
Messaging Signals Plus BPSignals Plus BPResponse
(that is, everything returned back in the
HTTP reply's MIME entity). When using the syncReply
flag, we seem to be
saying to return something synchronously, but
how much is left open! Do we check whether
RM is used, and then put in the ack? Do
we check whether a BP level signal is
used for non-repudiation of receipt and
include that also? The MSG says that the
Response is to be returned, but leaves
the BP and MSH signals a little underspecified,
IMO.

Finally, there is currently a remark in the
Messaging spec about what to do with
the syncReply flag value when using a CPA.
The statement (labeled 1 below) seems
to imply that when using a CPA,
there is really only a variable syncReply
value, when syncReplyMode is None.
(When syncReplyMode is not None, the
flag is to be set to a constant
True value.)

I am struggling to understand what this
means for the actual behavior of software.
A vendor's ebXML MSH software either draws some of
its configuration from a CPA or from
some other source, such as a configuration
editor tool. I assume that software that supports
configuration either way
will have to be able to set up service
bindings among collaboration participants.

Now to obey the Messaging spec, do I have
to track whether my configuration information
came from a CPA, then check whether it has
a syncReplyMode of none, and then decide
to ask to ignore this configured value?
(I hope this is not really what is meant.)

If so, it seems I really need to have a
configured mode of operation that says:
"Decide whether there will be a synchronous
or asynchronous reply on the basis of
the ebXML message QOS attribute, then
consult other configuration information
to decide exactly what goes in the
synchronous entity and what, if anything,
still goes back asynchronously". At this
point, I am losing track of why we have
the QOS flag anyway. Is its main use
to ask to return something synchronously
after we have agreed not to do so?

I could see the point of having a flag to
back down from an agreement to return
something synchronously (because we will
have to hold the connection open too long
to service the request), but I am not certain
why the reverse is useful.

Overall, I do not think that we yet have
a harmonious treatment of how to combine
the QOS per message syncReply functionality
with the agreements made in a CPA. I think
it might be cleaner to have an explicit
CPA agreement to use the QOS value to
determine sync vs async or to disallow
per message semantics for these values,
and use the CPA values to govern behavior.







(For reference, here is what MSG spec says about syncReply flag so far:

The syncReply attribute is used only if the data transport protocol is
synchronous (e.g. HTTP).
It is an [XMLSchema] boolean.
If the transport protocol is not synchronous, then the
  value of syncReply is ignored.
If the syncReply attribute is not present, it is semantically
 equivalent to its presence with a value of false.
If the syncReply attribute is present with a value of true,
 the MSH must return any response from the application or business
 process in the payload of the synchronous reply message, as required.
See also the description of syncReply in the [ebCPP] specification.

(1)If there is a CPA, the value of syncReply MUST be
   true if the value of syncReplyMode in the CPA is not None.)

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