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

[Sunil Kunisetty <Sunil.Kunisetty@oracle.com>]

 Paolo,

Paolo Romano wrote:

> I  do not think it would be a good idea just
> not to describe the services
> offered by a ws-rm processor for several reasons:
> 1- The ws-rm is infact offering a service, a messaging service, and
> as any
> web-service it should be described.
 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.

 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.

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

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

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

 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.

 I'm noticing that many closed resolutions have been deliberately or un-deliberately
 being reopen. I hope this doesn't become the trend.

 -Sunil