NEC position on WS RM Requirements suggested by Nokia

["Alan J. Weissberger" <ajwdct@technologist.com>]

All

Here are our thoughts on "WS Reliability Requirements Draft Version 0.02"
from Nokia:

1.  General comment on numbering:  The Requirement numbers (e.g. R2.2) are
not aligned with the Function headings (e.g. (4.6) and this caused
confusion in reading and referencing the document.

2. Business use cases could be discussed in an introduction secion of the
document and not under Requirements section.


3.  Comments on section 4. Requirements:

a] Figure 1.  includes One Way HTTP binding + several Request/ response
bindings.  

We feel the Request - Response MEPs (with ACKs piggybacked onto Response
messages)are reasonable to consider.  However, the WS-RM spec v1.0
currently includes only the one-way message pattern.  For expediency, it
would be better to have the Request - Response MEPs  part of the
Requirements issues list.  We can retain the Figure in the Requirements
document, but note that "implementation of the Request/Response MEPs Iand
associated bindings) are for further study>"

b]  R2.1.2  Upper and lower (=adjacent) layer communications.
Our position on  inter-layer communications for WS-RM spec:

i) WS-RM Interface to APPS layer (above) should be in a separate "WS-RM
API" document
ii)  WS-RM Interface to SOAP layer (below) should  be included in an
Appendix to the protocol spec along with SOAP bindings.  This would be
consistent with the OSI protocol specs, which  include an Appendix
describing "abstract" primitives and parameters for adjacent layer
communications

c]  R3.1 and R3.1.1  are reasonable

d] R3.2 is OK, but add that management messages (e.g. Fault indication
messages) may  also use SOAP message body to convey information (e.g. about
the fault).  Later, configuration messages could use SOAP message body.

e] R3.3, R3.3.1 and R3.3.2 : we feel that only 3.3.1 One Way MEP should be
specified in the initial Requirements doc.  R3.3.2 on Req-Response MEP be
on the Requirements issues list (see a] above)

f]  R3.4.1  HTTP bindings is OK.  What about non-HTTP one way bindings?

g]  R3.4.2 We need to unambiguously define "synchronous" and "asynchronous"
before we can agree on these two different bindings.  We discussed
"synchronous" on last conference call, but "asynchronous" has not been
defined.

h]  R3.4.3 seems to be an implementation issue ("w/o any change in the
WS-Reliability implementation") and needs to be clarified.  

Does it really mean: "It must be possible to change the SOAP binding w/o
any change in SOAP message header elements which contain WS-RM
information."  That implies independence between SOAP message content and
SOAP binding.  If so, the synchronous attribute of "Ack Required" could be
a problem.

i] R4.1 Guaranteed Delivery and R4.2 Duplicate Elimination are OK.  We may
want to mention use of a No ACK timer and retry counter here as mechanisms
used to provide Guaranteed Delivery.

j]  R4.3 Ordering is OK, but not sure what 2nd sentence ("Communication
between parties usually consist of several individual MEPs") means.  Is
this an expanatory note ("usually") rather than a requirement. 

Note that in WS-RM 1.0, message ordering forces duplicate elimination. 

Suggest we clarify what Ordering means.  For example, WS-RM will NOT ensure
ordering between multiple receiver end points (i.e. when intermediaries are
present), but will preserve order between a sender - receiver pair. 

k]  R4.4  "Combining functionalities in R3.1, R3.2, R3.3 in a given message
exchange scenario"  should be clarified.  Does it include any combination/
permutation of any of the sub requirements?  Perhaps what is meant is that
WS-RM should support the  interleaving of One way and Request - Response
patterns.
 
Again, WS-RM v1.0 forces guaranteed delivery (i.e. ACK Requested) which
provides ordered messaging.

l]  R4.5 and R4.5.1  "Crash tolerance, persistent storage, and levels of
message persistence" all need to be clearly defined.  

-What fatal/ crash case is assumed? Suggest that fault handling
requirements of a "crash" should be carefully specified.  Note that WS-RM
1.0 leaves some fault handling features on the Future implementation list.

-Persistant storage is supported in WS-RM, but no definition is given.
Whether it is mandatory or optional depends on the definition.

How long must the transmitted message be stored?  [The simple answer is
until a proper ACK is received or the retry counter has expired and an
unrecoverable failure has been declared.]  Is non volatile storage
necessary so that the message can be re-transmitted after crash  (e.g. with
power failure) recovery? 
 
-What are the levels of message persistence?   Doesn't this require some
sort of configuration time negotiation to determine supported level of
message persistence?  Is that part of a "policy agreement" that is
completed prior to start up of WS-RM?  Does it also include configuration
management like specification of Timer values, retry counts, handling of
local failures?

m]  R5.1 and R5.1.1 Interoperability seems to be same as R2.2.1 Backward
Compatibility.  These could also be policy agreements.

Issue with R5.1.1 and R2.2.1:  What is the detection mechanism/ criteria to
determine that the far end entitiy does NOT support WS-RM?  Assume that if
it doesn't than the WS-RM functions are muted in the conforming
implementation.

n}  R2.2 (why is this under 4.6) For sure, a WS stack implementing WS-RM
must offer more capabilities (not less) than  a WS stack NOT implementing
WS-RM


o]  R2.2.1 What does "interface" mean?  Is it an API? 
What is a  "backward compatible extension?"  

Personal opinion:  A WS-RM entity should be able to detect when the far end
SOAP entity does not support reliable messaging, and then fall back to a
non-reliable mode where the WS-RM functions are muted.  However, we should
encourage the WS industry to implement WS-RM, so that this would happen
infrequently.

p]  R7.1 on SOAP intermediaries needs to be clarified.
Are SOAP intermediaries store and forward entities that also implement
WS-RM over SOAP?  Or are they strictly SOAP entities that are unaware of
WS-RM?

If they implement WS-RM, then there are a whole new set of WS-RM issues
(e.g. local vs end to end significance of ACKs and fault indications; end
to end sequence preservation/ message ordering, etc) which must be
resolved.  This will take quite some time to do, in my opinion.

4. State synchronization: a requirement in Nokia's presentation, but not in
draft document"


How is the MEP cancelled?  Why not use Time to Live to effectively cancel a
MEP when no ACK has been received. Note that State synchronization is not
included in WS-RM v1.0.
---------------------------------------------------------------------------
That's all for now.....
Talk to you all tomorrow (Tuesday 2:30PM Pacific Daylight time) on the
conference call.


alan
 


Alan J Weissberger
Data Communications Technology
408 863 6042 office 
408 247 9102 home
408 863 6099 fax