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
