OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrm] Rel49


Jacques Durand wrote:
> 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.
> 

I think there is some confusion here.
What the document says is that --
when used, F&P mean what they say. Declaratively the service is stating
what is supported/required/whatever.
It is optionally for the client to recognize the syntax of F&P and
process it. The client may know the same information through some other
channels. It is RECOMMENDED that clients understand the syntax/semantics
of F&P, but not required to. But the clients must still be within the
boundaries of the semantics defined by F&P.
E.g., if a service requires 'polling' and expresses this using F&P then
the client must use polling. The client may get that information by
processing the F&P syntax, OR making a phone call OR by calling
1-900-PSYCHIC to find out what 'pattern' is used and do things accordingly.

IOW -- the client must comply with what is specified by F&P (in the
abstract sense), but there isn't a requirement that the server must use
this mechanism to describe capabilities/requirement and there isn't a
requirement that the client must recognize the syntax/semantics of this
mechanism.

Make sense?

> ----------- 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:
> 

I thought the general sentiment was to make this a WSRM specific thing.

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

We do need to specify that, but how is this different than specifying
this for any extensibility element that WSRM may define.

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

I hope i addressed your concern above.

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

+1 we should remove any (and all) examples that is not related to
ws-reliability

> -------------- comment 3: about some examples:
> 
> - VI.B Example 2: "A simple client side DD" is really about representing 
> a client-side agreement.

My understand was that the TC decided to have a client side
configuration (rather than an agreement) -- independent of the syntax.

> Although we'll ultimately need that, that goes 
> far beyond the announced intent. To me, a 1.1 or beyond feature!
> 

R u saying that client side config does not belong in 1.0 (regardless of
how it is represented)?

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

+1
Make sense to me.

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

Yes, the intend of the example is to show that the server is making an
assertion that the clients must use dup elimination + msg ordering +
guaranteed delivery.

Agreed that it makes more sense to have a choice instead of one-or-more
for the patterns.
So +1.

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

Possibly.
The reason I thought it made sense to have separate properties is
because it provides a lot of flexibility in composing these properties.
I suspect we could go either way.

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

Not sure how "capability" semantics solves this problem. Can you please 
elaborate?

One could potentially come up with complex dependencies. Whether we need 
this for wsrm -- I am not sure. Such complex dependencies can be 
represented either through compositors or by using appropriate schema 
types for properties. But as things get more complex it would be harder 
for "human parsers" to understand the dependencies (as with any boolean 
expression).

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]