RE: [wsrm] WSDL for WSRM ??

[Paolo Romano <Paolo.Romano@dis.uniroma1.it>]

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

The tricky point is that a generic service provider will probably combine the
services  offered by a ws-rm processor with its own "unreliable" services. Such
a combination of services is not easily expressible in WSDL, expecially because
of the fact that application dependant MEPs could even be modified to accomodate
the need for sending back acknowledgments. Several solutions have been proposed
up to now. Personally, at this point my favorite one is Payrit's 1).
  - Not to modify the application defined MEP.
  - Introducing apposite WSDL operations to allow reception of messages.



> The ACK sent as one-way MEP could have a binding defined for it in the WSDL,
> but it cannot be bound to an address anyway.

I do not see your point Scott, but may be it's just my fault. WSDL 1.1 defines 4
communication primitives, but only one-way and req/resp are practically used and
IMO these should the only primitives we should use.
If any ws-rm processor exposes a WSDL one-way operation to receive
acknowledgments, such an operation would be bound to the actual URL the WS-RM is
listening on. Am i missing something?


> I do not think that we can allow piggy-backing the ACK for the above
> scenario, or for option #1 from Szabolcs, unless the message receiver
> "knows" that the ws-rm processor will be part of the processing chain for
> the message being piggy-backed onto. (I assume here that piggy-backing is
> different than ACK consolidation, and refers to inserting an ACK into an
> unrelated SOAP message going to the same end-point). Imagine that I have an
> end-point in which more than one Web services stack is loaded. Or even a
> single WS stack, but multiple SOAP processor instances. SOAP messages are
> dispatched to the correct stack (or processor) based on operation (or
> SOAPAction). The message might be processed by a SOAP processor that knows
> nothing about the ws-rm header. If we explicitly allow piggy-backing in the
> spec it will put a much greater burden on providers to support it.

Once again I can't see your point. Sender "A" discovers a web service "WS"
through some UDDI repository and finally reads "WS"'a wsdl. In this WSDL, A can
find out that "WS" supports (actually requires, since WSDL 1.1 does not allow
headers to be optional) WS-RM headers along with some service dependant body.
Then "A" and its WS-RM processor compose a request message, say one way.
Next, the WS-RM processor of "WS" has to reply with an ACK. I guess this WS-RM
processor, based on the information in the from or reply to headers will
determine where to send the ack. The specified return address should correspond
to an end-point which does know how to handle acks. It will also have an
apposite WSDL operation for this purpose...

Any comments?

BR
Paolo

>
> Scott
>
> > -----Original Message-----
> > From: Szabolcs.Payrits@nokia.com [mailto:Szabolcs.Payrits@nokia.com]
> > Sent: Monday, June 30, 2003 2:36 AM
> > To: Paolo.Romano@dis.uniroma1.it; scottw@wrq.com;
> > tom@coastin.com; sunil.kunisetty@oracle.com
> > Cc: khookguy@yahoo.com; wsrm@lists.oasis-open.org
> > Subject: RE: [wsrm] WSDL for WSRM ??
> >
> >
> > 		Hi,
> >
> > > Suppose the original "unreliable" web service has some
> > > operations which support
> > > only the (synchronous) request response  MEP.
> > > The SOAP node including both the ws-rm layer and the final
> > > webservice at this
> > > point disagrees with the WS-RM supported MEP.
> >
> >
> > I think your concerns are definitely valid. We also think
> > that easy intergration of WRSM with existing
> > applications/interfaces is a major concern.
> >
> > However, I think the root of the problem is not with the WSDL
> > description. The problem is more general, the basic question is if we
> >
> >   1) define WSRM functionalities TRANSPARENT to existing SOAP MEP
> >      ------------------------------------------------------------
> >       - Basically: We don't limit where Acknowledgements are
> > sent. They may even "piggyback" other SOAP messages.
> >       - It would mean that we don't limit the
> > "Acknowledgement Binding Patterns", we may just define these
> > patterns only as possible scenarios. (Polling for Ack as a
> > funtionality may still remain, of course).
> >       - There is no problem with WSDL description, and
> > integration with existing applications/interfaces would be easy.
> >       - The WSRM processor implementation must be flexible
> > enough to receive and recognize Acknowledgements anywhere
> > they appear in incoming messages.
> >
> >   2) we define Reliable-MEPs OVER the existing SOAP MEPs
> >      ---------------------------------------------------
> >      - Basically: We specify exactly where Acknowledgements
> > must be returned by the Responder.
> >      - It would mean that we define exactly the
> > "Acknowledgement Binding Patterns", and how they map to SOAP MEPs.
> >      - In this case the problems you described appear.
> >      - However, implementation of WSRM processor would be
> > easier, as there would be strict rules for placement of
> > AckRequest and Acknowledgements.
> >
> >  So from your and Senil's mail it looks to me that
> > compatibility with WSDL 1.1 tools (code generation etc.)
> > looks to be a major concern here.
> >
> > Therefore we may want to consider option 1) above, i.e. to
> > DETACH  AckRequested - Acknowledgement pairs from SOAP MEPs
> > and let them be connected by the WSRM processor (to put it
> > simple: Acknowledgement may come anywhere)
> >
> >  Note that with our Requirement R6.2.1 (sending multiple
> > acks), we do already have a kind of detaching of the
> > acknowledgement mechanisms from the SOAP message exchange.
> >
> >
> > 	BR,
> > 		Szabolcs
> >
>
> You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php
>
>




--
Paolo Romano