RE: [wsrm] WSDL for WSRM ??

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

For Sunil:
I'd be glad if you would put me in the wsdl sub-mailing list.

For Szabolcs:

>
>   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.
>
How would the WS-RM WSDL look like in this case? We would just define the
structure
of the header without specifying any supported MEP? In this case, if an already
existing WSDL exists for an up to now unreliable service exists, it could be
described as reliable by extending its previous wsdl to include the new header.
The
original supported MEPs at this point should be managed and possibly altered by
the
ws-rm processor to support reliability.
I see that the problem gets quite simpler this way. My concern is that this way
we
are not fully exploiting the WSDL descriptive power: the actual MEPs used by the
ws-rm processors may be different by those originally supported by the
application
offering the service. Consider the case of a one-way operation, which could be
mapped to a synch. req-response (message on the req, ack on the response): in
this
case the service exposed is actually a req-response and not a one-way. If I do
not
misunderstand what you mean with this first possibility, in this case the
original
WSDL (describing the one-way operation at the application level) should be used
and
the WS-RM processor would be free to implement any different MEP.
An other point is that if we do not describe the MEPs supported by the ws-rm
processors in the WSDL, where
are the parties going to collect these informations?




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

I have been thinking a while about this possibility. Unreliable services are
commonly described only (WS-I states so) as WSDL one-way and synch req-resp
operations.
My proposal is: in case  services choose to rely on the ws-rm layer, then the
original WSDL file should be translated into a new one which
1) import the WS-RM header definition
2) describe the MEPs actually used by the ws-rm processor to support the service.
Just as an example consider the case where the original service was described as
a
one-way operation. We may define two possible ways to support these operations at
the ws-rm layer:
- 2 one way operations, one carrying the message to be acknowledged and
one carrying the ack itself (body empty).
- a single request-response, message on the req/ack on the response
(body empty).
The SOAP request-response MEP could become:
- a req-resp (defined at the service provider side) + a single one-way (defined
at the service provider side) to send the acknowldegment of the
response to the service provider.

An other possible choice could be restricting the set of supported MEPs just to
one-way, like in the BEA solution. The point I am missing in this case is: what
if
an application requires a req/response MEP and the ws-rm processors only use
one-way operations? The services offered by the ws-rm would be described as
one-way.
This implies that the receiving ws-rm should act like a gateway which translates
the incoming
one-way MEP (i.e. the only supported one) in a req/resp for the existing
applications? How will the WS-RM processor know how/wether to make such
translation?

In this moment, the option I like most is the second: ws-rm should offer to the
application layer (1) reliable one-way and (2) req-response MEPs. These might be
supported at ws-rm layer by using several standard SOAP MEPs. All of these MEPs
should be described through WSDL 1.1, to allow interoperability. In our spec we
would have to define the possible translations of reliable MEPs to "unreliable"
standard SOAP
MEPs.
What about this solution?


Best Regards,
Paolo










> 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