RE: [wsrm] WSDL for WSRM ??

[Scott Werden <scottw@wrq.com>]

After thinking about how to deal with ws-rm being added to a previously
defined binding, I think the best option is minimal impact on the original
MEP and WSDL.

- The original message that is sent will have ws-rm headers added on to it.
The WSDL may define those headers and may define header bindings, but as
Sunil pointed out, it does not have to. The point of defining the headers is
so both sides know what they are - but that is already known from the spec
so there is no added value in defining them in the WSDL, unless the provider
wants to advertize that it only supports a subset of WS-RM. The MEP for the
message is whatever it was for the original message - WS-RM must not affect
that part of the WSDL contract.

- If the original MEP is one-way, the ws-rm ACK will be a separate one-way
MEP. If the original MEP is req/resp, the ACK will be a wsrm:header added to
the response. In either case, the ACK does not need to be added to the WSDL
since the purpose of the WSDL is to form a message contract between the
sender and receiver, and in the case of the ACK, it is really an out-of-band
communication from the ws-rm processor on the receiving side to the one on
the sending side, and that contract is already defined in the ws-rm spec.
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. In any event, this would not
affect the original message binding. The original sender  must be able to
receive the ACK either as an end-point (for the case of the ACK sent in a
one-way) or as simply part of the SOAP processing stack (for the case of the
ACK sent in a response). Likewise, the ACK sender must be able to generate a
one-way MEP and send it to the sender. 

The end result of the above is that nothing needs to be done to the WSDL.
The important thing is that the MEP stays the same. All of this must be
specified in the ws-rm spec, and hence is not needed in WSDL.

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.

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 
>