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: [WS-RM & WSDL] Task Force Discussions


Thanks for comments.  I have now read through all the posted messages
related to WSDL.  I've come to these conclusions as far as the
implementation of WSRM that I'm working on for my book:

(1) Use the "minimal impact" approach described in Scott Werden's latest
post.  This is (I think) consistent with your philosphy - leave WSRM MEP
information out of the WSDL.  I.e., do not use <soap:header ...> within
the WSDL bindings.
(2) Implement WSRM sender and receiver layers as SOAP Handlers.  Since
my implementation is in Java, I'm going to try doing this using the
JAX-RPC framework.  Any suggestions are more than welcome!  I'll let you
know how it works out.

I like your concept for the annotation of the WSDL using
<wsdl:documentation>.  I think maybe we should limit the annotation to
those parameters that define the boundaries of the service's WSRM
support.  For example, it is useful to have an annotation for
</ack-pattern> to tell the user what acknowledgement MEPs are supported
by the service.  However, I don't see why we would want to annotate
things like <wsrm:retry-count> that do not describe properties (or
limitations) of the WSRM support provided by the service.      An RM
processor is agnostic regarding the retry-count.  It is totally up to
the user of the service to decide how many retries to use isn't it?  I
guess that annotations like <wsrm:retry-count> could be used as "hints"
for code generation tools, but I think we are better off avoiding
"hints" for parameters where the service is agnostic.

-- Mark

-----Original Message-----
From: Sunil Kunisetty [mailto:Sunil.Kunisetty@oracle.com]
Sent: Monday, June 30, 2003 4:00 PM
To: Mark D. Hansen
Cc: tom@coastin.com; Peter H. Petersen; jturpin@cyclonecommerce.com;
scottw@wrq.com; venkat.danda@iona.com; Paolo.Romano@dis.uniroma1.it;
Subject: Re: [WS-RM & WSDL] Task Force Discussions


 Comments below. Btw, I've added Paolo and Szabolcs to this list and
 Venkat's email.

"Mark D. Hansen" wrote:

> Sunil,
> Thanks for your email clarifying the WSDL issues.  Here are some
> thoughts that I have.  Forgive me if some of my comments reveal a
> certain ignorance about WSDL - I'm still getting up to speed!!
> I agree with your comments about issue #1.  Certainly, we should deal
> with #1 before attempting #2.
> However, while I agree with you that #2 is tricky, I wonder if we
> need to address some of the issues raised by #2.  Given that WSDL is
> "linga franca" of Web Services, don't we need to be able to describe a
> WS-RM endpoint's behaviour using WSDL?  If we dong describe the MEPs

 Not necessarily. RM is a QoS feature and it is not imperative that it
has to be
 defined as a MEP in WSDL. It will be good if we do it, but there are so
 many issues with it and also is time consuming.

 Paolo & Szabolcs are also discussing the same on the MAIN list. I
haven't yet
 read Szabolcs's lengthy ( :-) ) mail yet, but there are indeed many
 in mapping Application's MEP to WS-RM MEP.

> WSDL, how else will a client know how to interact with a WS-RM
> Do we just assume that the MEP is documented in the WS-RM Spec and
> it is understood between the client and endpoint outside of the
> of WSDL?

 I believe so.  That would be case (1) in Szabolcs's first mail.
 Infact, none of the QoS WS Specs.  such as WS-Security, WS-Policy
defined WSDL
 mappings as they are complex, non-standard, time consuming etc....

> Here are some questions related to your  <wsdl:documentation> example:
>   (a) Why would the endpoint specify retry-count / retry-interval?
> Shouldn't the
>       endpoint be able to handle any retry-count / retry interval
> combination?

 Sure. The endpoint should be able to handle any
retry-count/retry-interval and
 infact should be agnostic about them. However, the intention of these
being mentioned
 in WSDL is not for endpoint (or platform), but for the client (sender).
WSDL is used by
 Clients/Tools to generate client proxy (or DII) code and it is for them
to have this
 in their generate coded. This information may have to be provided to
the client (Sender)
 either statically using some proprietary DDs or dynamically using some
properties or APIs.
 The latter is definitely out-of-scope of this Spec. and instead of
having proprietary DDs for
 WS-RM, an alternative would be able to supply the same in WSDL so that
they can be used
 to generate code or used by tools to do WS-RM operations.

>   (b) Regarding ack-pattern, couldn't the MEP used for acknowledgement
> depend on the
>       contents of the message?  And shouldn't the client sending a
> message to an
>       endpoint be prepared for any type of ack MEP and have to deal
> that "on
>       the fly" ??

 Yes. The Ack. pattern is definitely decided by message contents.
 RM processor needs to know some hints from the User/Application to how
 he should like to receive the Ack. Generally this will be provided in
some DD.
 Instead I'm using WSDL annotation as an User provided hint to the
 side RM processor to handle these properties.

 As an example, in the initial WS-Reliability spec. we had the
synchronous attribute
 on RM:AckRequested that indicated how the Client likes to receive the
 Though not explicitly mentioned in the Spec., it is implied that User
will provided
 (if not, defaulted to one or other) this information and Client-side RM
 will then accordingly marshall the message.

 So instead of providing these in proprietary way, we could use WSDL to
 so that User can provide this hints FOR client/tools in a much more
standard way.

 I hope I clarified. Lemme know if I'm still vague so that I can


> -- Mark
> Mark Hansen
> bus: (888) 360-7285
> fax:  (914) 723-8671
> email: khookguy@yahoo.com
> -----Original Message-----
> From: Sunil Kunisetty [mailto:Sunil.Kunisetty@oracle.com]
> Sent: Thursday, June 26, 2003 9:28 PM
> To: jturpin@cyclonecommerce.com; Mark D. Hansen; scottw@wrq.com;
> venkatd@iona.com
> Cc: tom@coastin.com; Peter H. Petersen
> Subject: [WS-RM & WSDL] Task Force Discussions
>  There are 2 main focus areas wrt to WSDL that should interest us.
>   1) Annotating (or Marking) <wsdl:operations> with WS-RM properties
>   2) Creating  WS-RM MEP Bindings. This would involve mainly declaring
>      WS-RM Headers and Async. Patterns.
>  I'd hesitate to venture into focus area 2 as there are many unknowns:
>   - Usage of Headers is non-standard. Some applications use only
>     Dynamic Headers, Some map Headers to Parts, Some declare Headers
>     separately (to be processed by Handlers etc.)
>   - If we support multiple transports, then we have to create a
>     for each of them.
>   - Whether WS-RM Async.patterns should be treated as MEPs and be
>     declared in WSDL is an arguable call.
>  What I volunteered at F2F was the focus area 1, reason being:
>   - It is simple
>   - It only touches the wsdl "abstract"  part.
>   - WSDL is the Service's window/interface for the client.
>   - If we don't do it, vendors could create their own DDs.
>   - Stub/Proxy generators could automatically generate WS-RM
>     specific code in the Stubs when they see these tags.
>  My intention here is to make it non normative only. (In Appendix
>  or Best Practices Guide).
>  If we decide to annotate <wsdl:operations>, then we have 2 choices:
>     1) Use the <wsdl:documentation> element to define the elements.
>     2) Add extensibility elements.
>  (ps: We can't use schema annotation as it should be only in the
> section)
>  Option 2 is not viable  in WSDL 1.1 as wsdl scould choke in some
> It should
>  be the option  when we move to WSDL 1.2) Option 1 is  the most
> used
>  one for  "marking".  WS-I BP Conformance Claim tags also use this
> option.
>  I believe we should do this. I'm not sure whether everyone concurs on
> this or not.
>  Here is an example of such a declaration would like:
>  <portType name="fooPortType">
>  <operation name="fooBar">
>  <wsdl:documentation>
>    <wsrm:WSRM xmlns:wsrm="spme URI">
>       <!-- Spec. version>
>       <wsrm:version>1.0</wsrm:version>
>       <!-- Indicates the RM:MessageHeader:To field contents !>
>       <wsrm:To>http://someuri</wsrm:To>
>       <!-- Indicates the RM:MessageHeader:Service field contents !>
>       <wsrm:Service>StockQuoteService</wsrm:Service>
>       <!-- No. of retries to send for non ack. messages  and return
> interval !>
>       <wsrm:retry>
>         <wsrm:retry-count>5</wsrm:retry-count>
>         <wsrm:retry-interval>10</wsrm:retry-interval>  <!-- 10 secs
>       </wsrm:retry>
>       <wsrm:gd>
>         <!-- ack-pattern sub-selement indicates the ack. receiving
>              Possible values are Response-Ack, Callback-Ack,
> !>
>         <ack-patten>Callback-Ack</ack-pattern>
>       </wsrm:gd>
>       <wsrm:de>true</wsrm:de>
>     </wsrm:WSRM>
>  </wsdl:documentation>
>  <input message="fooMessageIn" />
>  <input message="fooMessageOut>
>  </operation>
>  ...
>  </portType>
>  If we all agree that such a thing is useful, then we could enhance
> (the above example
>  is far from complete) and define the schema.
>  Thoughs???
>  Thanks,
>  -Sunil

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