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



Scott Werden <scottw@wrq.com> 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

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:Paolo.Romano@dis.uniroma1.it]
> > Sent: Friday, July 11, 2003 5:08 AM
> > To: Sunil Kunisetty; Paolo.Romano@dis.uniroma1.it
> > Cc: Scott Werden; wsrm@lists.oasis-open.org
> > 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




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