[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrm] NEC position on WS RM Requirements suggested by Nokia
Hi Alan and all,
Though the document commented already changed, you raised valid questions. See my answers below.
br,
Magdolna
-----Original Message-----
From: ext Alan J. Weissberger [mailto:ajwdct@technologist.com]
Sent: April 21,2003 21:14
To: wsrm-TC
Subject: [wsrm] NEC position on WS RM Requirements suggested by Nokia
Importance: High
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>"
[MG] WS-RM specification is an input and not the final specification. We can extend it if we agree on the requirement of req/resp MEP support. It's already on the issue list.
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.
[MG] Yes, but we have to take into account:
SOAP 1.1:
"The (Fault) detail element is intended for carrying application specific error information related to the Body element. It MUST be present if the contents of the Body element could not be successfully processed. It MUST NOT be used to carry information about error information belonging to header entries. Detailed error information belonging to header entries MUST be carried within header entries."
This is a problem in the WS-RM v1.0.
SOAP 1.2 does allow the Fault detail usage in all cases (error in Body or header entry)
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?
[MG] Currently there is only one another "standard" SOAP binding exists, a W3C Note for SOAP e-mail binding, which specifies ONLY the req/resp MEP binding.
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.
[MG] Agreed...and all the other definitions/terminologies, what we use in the spec.
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.
[MG] You are right, that the settings used by the reliability mechanism should be clarified (all of them), but I think, only in the specification as technical details.
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.
[MG] Why not ? The message ordering mechanism ensures, that based on the header information the messages can be reconstructed evenif they are not received in the correct order. That's true for the SOAP intermediaries as well, if they implement WS Reliability and are involved in the message path between the originator and ultimate receiver, but the difference is, that their reliability processing rules should differ a bit: e.g. the duplicates must not be re-processed, just forwarded, etc..
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.
[MG] If I understand well, WS-RM v1.0 even allows the non-guaranteed delivery in case of guaranteed duplicate elimination. I suppose, that in this case the transport duplicates are filtered if no Acknowledge is requested (Retry works only if Acknowledge is requested).
You are right, that this requirement is somekind of permutation of the MEPs and SOAP versions.
l] R4.5 and R4.5.1 "Crash tolerance, persistent storage, and levels of
message persistence" all need to be clearly defined.
[MG] Levels of message persistence here means, e.g:
- the whole message and its context are stored persistently (at least for a given time)
- only some meta data of the message is stored persistently (e.g. MessageID,...) (at least for a given time)
-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.
[MG] Yes, depending on the level of the message persistency.
-Persistant storage is supported in WS-RM, but no definition is given.
Whether it is mandatory or optional depends on the definition.
[MG] WS-RM v1.0 mandates persistent storage, but doesn't define how long.
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?
[MG] The question is valid for the receiver as well. How long the the message related informations should be stored ?
-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?
[MG] True. All these needed to be defined. The simpler case is the out-of-band agreement, otherwise the specification should define the policy handling in the protocol.
m] R5.1 and R5.1.1 Interoperability seems to be same as R2.2.1 Backward
Compatibility. These could also be policy agreements.
[MG]
Backward compatibility : if an application is based on the req/resp MEP, the reliability layer must provide the reliable req/resp MEP as well, i.e. can not offer less, than the current stack without reliability.
Interoperability: if an application is intended to use both reliable and unreliable MEPs, this should be available, i.e. the application on top of reliability layer should be able to interoperate with applications not having reliability layer implemented (of course on unreliable way).
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.
[MG] yes. The detection mechanism could be the Fault indication.
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?"
[MG] Interface means here the communication between the reliability layer and the upper (application) layer.
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.
[MG] Yes, the detection of the unsupported reliability is necessary.
That's an application decision, whether it wants to fall back to unreliable mode or not (e.g. the service is possible on unreliable way or not).
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.
[MG] It is not so complicated. Acks already have end-to-end significance.
4. State synchronization: a requirement in Nokia's presentation, but not in
draft document"
[MG] This is, what we think is a bit more complicated and may be a next version issue. But let's see the progress of the specification.
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]