[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] [REL-14] WSDL for WSRM ??
Paolo Romano wrote:
I do not think it would be a good idea just not to describe the servicesWS-RM is not offering a new service (by itself), but rather a QoS to an
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.
So I don't see a good reason that WS-RM MEPs be defined in the
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
I don't believe in infrastructure's (whether it is WS-RM or some
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
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.
I'm totally against the Spec. mandating that these Headers be defined in the 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.
- By defining the soap:Headers in the binding section, there won't
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
-- 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
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
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
I'm noticing that many closed resolutions have been deliberately
being reopen. I hope this doesn't become the trend.