Paolo Romano wrote:
> Scott Werden <> ha detto:
>
> > 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.
> >
> These are links about WS-Security and WSDL:
> http://lists.w3.org/Archives/Public/www-ws-arch/2002Nov/0070.html
> http://www-106.ibm.com/developerworks/webservices/library/ws-security.html#IDAJWYTC
>
None of the above links provide any concrete information at all. Infact, I just checked with
the Oracle rep. for WS-Security and he mentioned that they are not looking into WSDL
binding stuff.
-Sunil
> Paolo
>
> > 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
> > >
> > >
> >
>
> --
> Paolo Romano
>
> You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php
