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

>  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
>    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
>  being reopen. I hope this doesn't become the trend.
>  -Sunil

Paolo Romano

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