RE: [ebxml-msg] Some implementation feedback from Fujitsu MSH tea m

[Jacques Durand <JDurand@fs.fujitsu.com>]

Title: RE: [ebxml-msg] Some implementation feedback from Fujitsu MSH team

Here it is.
(note I tagged it: <priority>implementation</priority> )

Jacques

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@sun.com]
Sent: Friday, February 15, 2002 5:56 AM
To: Jacques Durand
Cc: 'ian.c.jones@bt.com'; 'david@drummondgroup.com';
ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] What format for implementation feedback?

I'm sure that Ralph would find that most useful:)
Either that, or have the comments use the same
information items to facilitate cut-n-paste.

Cheers,

Chris

Jacques Durand wrote:

> Fujitsu developers (currently developing 2.0) have
> some comment on the spec, and ask me to relay these to the TC.
> I am not sure what is the format/process to submit
> an "implementation feedback".
> Should I use the same XML format currently used for "editorial" and
> "technical"?
>
> thanks
>
> Jacques Durand
>

 

<issue>
<issue-num>1002</issue-num>
<title>syncReply processing</title>
<locus></locus>
<section>5 (SyncReply)</section>
<priority>implementation</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:jdurand@fs.fujitsu.com'>Jacques Durand</a></originator>
<responsible></responsible>
<description><a></a>
(Reporting for Fujitsu development team)
The implementation of syncReply and syncReplyMode for non-mshSignals (i.e. for
all business-level responses), significantly adds to the complexity of the development,
which affects our product schedule, for a meager benefit to us and our partners.
More importantly, it leaves some scalability and reliability issues unresolved. 
Explanation: On receiver side, the processing of syncReply messages (for non-mshSignals) 
is quite different from the processing of "asynchronous" messages. 
The MSH must hold the connection and wait for the application response.
There may be an unexpected large number of such connections being held open, 
especially in scenarios where the receiving app is not responding. 
The response has to be matched to the waiting thread/connection, based on RefToMessageId,
since many concurrent connections will be open. Proper management of these
connections is tightly dependent on the proper use of RefToMessageId by an application. 
Open connections should be timed-out based on CPA specs, yet the configuration of
HTTP or of the other synchronous transport server may decide otherwise, based on other 
constraints. Also, when used with Reliability, the msh signals (Acks) have to be 
piggibacked on the synchronous business response/signal. This may introduce quite
some delay in the acknowledgement, which will very likely conflict with the reliability timeout.
(It would really make no sense to have a sync business response and an async Ack.)
Because of all the above reasons, the robustness is seriously affected.
In addition, syncReply for business responses only applies to business exchanges that 
distinguish "Receipts" and "Responses" from regular messages,
without even allowing for symmetry (a "Response" is not allowed itself a synchronous receipt).
This specificity is not worth a core feature status and its implementation cost. 

On the other hand, the syncReply feature implementation for "mshSignalsOnly" mode is quite
safe and straightforward to implement, as the MSH is sole responsible for the (fast) response. 
It is in particular welcome for reducing the communication overhead (Acks) in case of guaranteed 
delivery. This would also remain compatible with Ordering (sync does not always guarantee order), 
which always requires being used with Reliability. 
</description>
<proposal>
Either remove syncReply from core features in spec and classify it as an additional feature,
or, if left as a core feature, an implementation should only be required to implement it
for the "mshOnlySignals" value of syncReplyMode.
</proposal>
<resolution>none</resolution>
</issue>