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:]
> Sent: Friday, July 11, 2003 5:08 AM
> To: Sunil Kunisetty;
> Cc: Scott Werden;
> 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
>
>
