RE: [wsrm] [REL-14] WSDL for WSRM ??

[Scott Werden <scottw@wrq.com>]

The need to advertize that a Web service provider supports WS-RM I think is
important. The question is whether WSDL is the best mechanism by which to do
that. I suggest we research what is going on with the other WS-XXX specs (in
particular WS-Security since it is the only "open" one at this point) since
this problem is not at all unique to WS-RM.

One suggestion: the WSDL could import the WS-RM schema and namespace without
actually creating message parts or bindings. The semantic here is that the
service is saying that it fully understands WS-RM but that it is optional.
Of course this would not work if the service wants to claim only partial
support of WS-RM.

Scott

> -----Original Message-----
> From: Paolo Romano [mailto:Paolo.Romano@dis.uniroma1.it] 
> Sent: Friday, July 11, 2003 5:08 AM
> To: Sunil Kunisetty; Paolo.Romano@dis.uniroma1.it
> Cc: Scott Werden; wsrm@lists.oasis-open.org
> Subject: Re: [wsrm] [REL-14] WSDL for WSRM ??
> 
> 
> 
> >  WS-RM is not offering a new service (by itself), but 
> rather a QoS to an
> >  existing service.
> >
> >  So I don't see a good reason that WS-RM MEPs be defined in the WSDL
> >  which was meant to be the application client's view point 
> of the service
> >  being offered. Marking the service with RM 
> features/properties is different
> >  and some what useful thing, and which is what we are 
> achieving with the
> >  annotations (REL-49).
> >
> >  I don't believe in infrastructure's (whether it is WS-RM 
> or some other
> >  QoS provider) properties being defined in the WSDL. Just because
> >  we use tcp (soap/http/tcp), do we have defined tcp linger 
> or tcp_nodelay
> >  properties in the WSDL? No. I see the same analogy with WS-RM MEPs.
> >
> >
> >
> The main reason to incluse a WSDL description of a ws-rm 
> header is to allow the
> service provider to advertize the fact it is able to use such 
> protocol in a
> standard way. I agree with you, ws-rm does not actually 
> define a new service,
> but for sure it modifies the application level service 
> itself, because it
> enhances it with reliabilty features. But this is philosophy...
> With WSDL you make available to clients the information 
> concerning the transport
> protocol you use, SOAP over HTTP, SOAP over SMTP. Including a 
> WS-RM description
> in WSDL a service provider may state that it is using WS-RM 
> over SOAP over
> HTTP/SMTP/etc.
> 
> >  Yes, the WS-RM client infrastructure  has to 'imply' a MEP based on
> >  the original MEP + Ack. Pattern Selected + Some other dependent
> >  and should enforce that MEP. However, I don't see a requirement
> >  that it be defined in the Service's WSDL.
> >
> 
> Are you saying that the spec should not make mandatory ONLY 
> the defition of
> additional operations just to take into account the WS-RM 
> additional MEPs for
> ACKs/FAULTs, or also the fact that a WS-RM header should be 
> included in the
> requesting message to exploit WS-RM functionalities? I may 
> agree with the first
> resolution, but not on the second. Please see below.
> 
> > >
> > > 2- A service which relies on WS-RM headers for 
> reliability should be able to
> > > advertize it in a standard way, i.e. WSDL. I do not like 
> the idea of setting up
> > > an out-of-band agreement for discovering wheter a given 
> web-service supports or
> > > not ws-rm... UDDI and WSDL are standardized solutions for 
> doing that.
> >
> >  I'm totally against  the Spec. mandating that these 
> Headers be defined in the wsdl
> >  binding section (using soap:Headers).
> >
> >  - By defining the soap:Headers in the binding section, 
> there won't be any
> >    dynamic way of toggling whether we need to send RM Headers per
> >    message or not. This is because all the M Headers will 
> have mU=1, and
> >    any Header defined in wsdl with mU=1 should always be sent.
> >    Because of this:
> >      -- Client (or Sender) will never have a say and the 
> Service provider
> >         (Receiver) will always have the control - which is 
> a very inflexible.
> >      -- Say you define the MessageOrder Header in the 
> wsdl:binding, and the
> >         client application wants to send only One message 
> in some transaction.
> >         Client infrastructure may want to do some 
> optimization such as sending
> >         it as a stand alone message rather than as a group. 
> However, it cannot do
> >         so as it has to always send the MessageOrder header.
> >     -- If the client for some reason wants to send an 
> un-reliable message to the
> >         same operation, it cannot as it is forced to send 
> reliable headers ALL the
> >         time.
> >     -- Service providers should generally list the 
> options/features it supports
> and the
> >        consumers are the ones who should pick the option it 
> applies to them. Not
> >        the other way around.
> 
> 
> 
> I understand these comments. These are related to a 
> well-known WSDL 1.1 limit:
> not being able to define optional headers. Anyway (please 
> correct me if I am
> wrong) a feasible solution (while we wait for WSDL 1.2) for 
> all of these issues
> could be defining two WSDLs, one for the reliable and one for 
> the unreliable
> service. This way the client may pick up its favorite one.
> 
> 
> >
> >  - Also, defining Headers in the wsdl:binding as parts is 
> some what questionable IF
> >    the Headers  are processed by some sort of Handlers. It 
> makes sense to define
> >    them in wsdl:binding mapping to parts if they are 
> processed by the Service
> itself.
> >    Since WS-RM Headers will be processed by a WS-RM 
> Processor and not by
> >    the service, I don't a see big advantage. The only adv. 
> of defining the Headers
> >    in the binding section and mapping them to parts would 
> be when the Service
> >    provider wants to FORCE WS-RM Headers (with mU = 1) all 
> the time. The
> >    disadvantage is that we loose the flexibility.
> >
> 
> I guess we could still have flexibility with the above solution.
> 
> >  - Having said the above, if some service provider wants to 
> use Headers, they
> >    should be able to do so even today by importing the 
> WS-RM schema in their
> >    wsdl and defining them in the binding section. There is 
> nothing in the spec.
> >    prohibits this. Since the spec. doesn't say it shouldn't 
> be, anyone can add it
> >    by their mercy.
> 
> >
> >  So for all the above reasons, I believe that the Spec. 
> shouldn't mandate that
> >  the headers be explicitly defined in the wsdl.
> 
> I see that WSDL currently lacks several features (optionality 
> of header
> elements, complex MEPs) so I can understand your reasons. I 
> think we could
> manage a way to reasonably use the current version of WSDL 
> with our spec. We
> have to choose whether to provide a non normative way of 
> using WSDL with WSDL or
> just leave any implementor free to do it its own way. 
> Personally I prefer the
> first choice, but I also think that a reasonable solution 
> could be stating that
> currently WSDL 1.1 is too limited to efficiently describe the ws-rm
> functionalities and that a standard way to use WSDL will be 
> provided as soon as
> WSDL 1.2 becomes a standard.
> 
> >
> >  Btw, I did mention some of these points in the last con. 
> call and hence we
> >  closed REL-14 and created REL-49. I'm not sure whether you 
> were there
> >  or not.
> 
> Unfortunately I could be present only for a short while at the last
> teleconference, and I have missed this discussion.
> 
> >
> >  I'm noticing that many closed resolutions have been deliberately or
> un-deliberately
> >  being reopen. I hope this doesn't become the trend.
> >
> >  -Sunil
> >
> >
> >
> >
> >
> 
> 
> 
> 
> --
> Paolo Romano
> 
>