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

[Dale Moberg <dmoberg@cyclonecommerce.com>]

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.)