RE: [wsrm] Rel49

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

Title: RE: [wsrm] Rel49

Anish and all:

I am currently reviewing the details of all this.

This is a big piece to swallow and I find more "loose nuts" - or things that
require work - as I dive into it.
It looked intuitive to me at first sight a few days ago, but I had only focused on a couple of simplistic examples.

I don't think we have spent enough time on it to make sure it works well as is, and to provide all the rules users need to use it properly for WS-Reliability.

I'd be concerned that it could seriously backlash if we do not properly address that before the final draft, if we can.

If one of our objectives is to provide a stop gap solution that would still point at the direction we favor (WSDL annotation) and to a syntax we expect to be adopted later (FnP) then again I feel we could achieve that in a more "lite" way, while not departing too much from f&p schema - but enough to not have to bring-in the whole generic mechanism.

Forward compatibility of "style" seems anyway to be the best we can hope for.

See below a few major comments:

----------- comment 1: About the real semantics of the annotation:

We are talking of representing capabilities, but the described semantics seems to waver between "capability" and "agreement":

[sem1]  the f&p annotation describes what is supported by the WS end-point, that users are free to use or not. That is what is announced initially (Introduction of ws-reliability-fnp doc).

[sem2]  the f&p annotation describes profiles of usage that Clients MUST comply with when they use this WS. That seems to be implied by Example 1 (Sec VI) that I reproduced below for Comments #3.

Both are VERY different:

Sem 1 is indeed describing Capabilities, that Clients may decide to use.

Sem 2 is describing a Contract (or RM Agreement), that the WS end-point asks Clients to comply with.

Of course, features required by an agreement are supposed to be supported ( capabilities ). But nevertheless these are two different concepts, based on two different interpretations of the term "[MUST] use" in the definition of Compositors (Section II of FnP doc):

Capability: "MUST use" means "the WS end-point MUST support"
Agreement: "MUST use" means "the Client MUST use when calling"

Which one do we settle for?
I would recommend a Capability semantics, based on comments below.

----------- comment 2: About the need to bring in the a general FnP mechanism, this late:
 
The problem in proposing a general mechanism in FnP for WSDL 1.1, is that we have to tighten-up a much larger chunk of spec. Several points are left unclear:

- As these properties may annotate various artifacts in the WSDL (portType, bindings, ops...) it is unclear what is the semantics for WS-R properties, what it means at message level, what are the differences.

- the term "use" in the 4 compositors definitions is quite general and unclear as to what it means in the WS-R context (see the two interpretations in #1).

- the use of examples that belong to other specs is unwarranted and confusing in FnP doc, hinting at another agenda. Readers only want to know how to represent RM capabilities, they don't want to be sold to a general mechanism.

-------------- comment 3: about some examples:

- VI.B Example 2: "A simple client side DD" is really about representing a client-side agreement. Although we'll ultimately need that, that goes far beyond the announced intent. To me, a 1.1 or beyond feature!

- I see a few problems with VI.A Example 1 below:
1. We should reuse the abstract terminology we introduced in 1.8.2 (RM agreement items) for property names.
2. This example again seems to describes a Required usage profiles, as in a contract or agreement, rather than a capability. It tells that input messages for this portType MUST use duplicate-elimination + message-ordering + guaranteed-delivery, not that they MAY. Incidentally, the example requires "one-or-more" reply patterns. If this is per message, we can't have more than one, so it should be "choice".

3. The use of names such as "response-reply-pattern" seems to assume all values are boolean. It would be so much more intuitive to use "reply-pattern" property (rather, "ReplyPattern"), with possible enum values "response", etc.

4. In a variant of this example, if we let user use a feature or not (e.g. GuaranteedDelivery), we can certainly express this with a choice of "true" or "false". But then requirement on other dependent properties (ReplyPattern) should only apply to the "true" case. Sticking to an "Agreement" semantics will require possibly complex annotations to express combinations that are allowed and avoid ambiguities. If we stick to a Capability semantics, we don't have this problem.

<wsdl11:portType name="myReliablePort">
  <fnp:compositor uri="http://www.oasis-open.org/committees/wsrm/schema/1.1/fnp/compositor/all">
    <fnp:feature uri="http://www.oasis-open.org/committees/wsrm/schema/1.1/feature/rel/"
      <fnp:compositor uri="http://www.oasis-open.org/committees/wsrm/schema/1.1/fnp/compositor/all">
        <fnp:property name="wsrm:duplicate-elimination">
          <fnp:value>true</fnp:value>
        </fnp:property>
        <fnp:property name="wsrm:message-ordering">
          <fnp:value>true</fnp:value>
        </fnp:property>
        <fnp:property name="wsrm:guaranteed-delivery">
          <fnp:value>true</fnp:value>
        </fnp:property>
        <fnp:compositor uri="http://www.oasis-open.org/committees/wsrm/schema/1.1/fnp/compositors/one-or-more">
          <fnp:property name="wsrm:response-reply-pattern">
            <value>true</value>
          </fnp:property>
          <fnp:property name="wsrm:callback-reply-pattern">
            <value>true</value>
          </fnp:property>
          <fnp:property name="wsrm:poll-reply-pattern">
            <value>true</value>
          </fnp:property>
        </fnp:compositor>
      </fnp:compositor>
    </fnp:feature>
  </fnp:compositor>
  <wsdl11:operation>
    ...
  </wsdl11:operation>
</wsdl11:portType>

-----Original Message-----
From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
Sent: Thursday, March 04, 2004 5:10 AM
To: iwasa
Cc: wsrm
Subject: Re: [wsrm] Rel49

Attached is the modified version of my original proposal.

The change from the original proposal is:

1) Replaced "http://www.ws-standards.org/fnp/"
with "http://www.oasis-open.org/committees/wsrm/schema/1.1/fnp/"

2) Replaced "http://www.oasis-open.org/committees/wsrm/schema/1.1/fnp/"
with "http://www.oasis-open.org/committees/wsrm/schema/1.1/feature/rel/"

As before, the proposal consists of two parts:
1) FnPwsdl11-version2.txt -- this is a backport of the WSDL 2.0 Features
and Property framework [2] to WSDL 1.1.
2) ws-reliability-fnp.txt -- this contains definition of ws-reliability
specific features and properties.

I hope this addresses the concern regarding having a non-wsrm namespace.

If you prefer to have different namespaces than what is proposed, please
  let me know.

Thanks!

-Anish
--

iwasa wrote:

> Anish and all,
>
> Since we have short time remaining before
> WS-I F2F meeting, we must close Rel49 by the telecon
> next week with concrete proposal with text to be
> incorporated in the spec.
>
> *And* if we can not agree the resolution by that time,
> I would propose we do not include anything
> in the spec for Rel49 and close the issue with no action.
>
> I do not agree to spend additional one more week when
> we can't close the issue by the next telecon.
>
> So I would propose Anish to send out proposal
> ASAP (by the end of this week at latest, I would suggest)
> to discuss and agree with the proposal before the telecon,
> if you really need your proposal accepted. Otherwise there
> would be chance of running out of time.
>
> I hope we resolve issue49 before the next telecon.
>
> Thanks,
>
> Iwasa
>