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] WSDL for WSRM ??


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


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