Re: [wsrm] ws processing layers with successive wsdl descriptions

Tom Rutt wrote:

> Lets look at a typical 2005 scenario.
>
> There is a user wsdl for operation foo with one message part fooInput, 
> which is specified as an operation input message, and another message
> Part fooOutput specified as the operation output message.
>
> The producer invokes the wsdl operation with fooInput on the sending 
> RMP. Now this “user” level wsdl is protected by wsrm features,
> thus the sending RMP adds the wsrm:request element to the soap header
> on the input message, and it is stripped by the receiving rmp before 
> delivering the fooInput part to the producer.
>
> The consumer does a respond invoke on the receiving rmp with the 
> fooOutput element, and the receving RMP adds the wsrm:response
> element to the soap header of the response The sending RMP receives 
> the aggregate output message, and strips off the wsrm:response, and 
> returns the fooOutput part to the producer.
>
> Now lets put ws security into the picture.
>
> The ws security processor adds the ws security element to the header 
> of the request, and the receiving ws security processor strips
> Off the ws security header and delivers the fooInput and the 
> wsrm:request header element to the receiving rmp.
>
> On response, the ws security processor adds a ws security header 
> element to the receiving RMP provided wsrm:Response plus fooOutput 
> element. The sending ws security processor strips off the ws security 
> response header, to give the sending rmp the wsrm:response with the 
> fooOutput element.
>
> This could all be described with “effective” wsdl descriptions for 
> each “level”/”Order” of the ws header processing
>
> The ws reliability wsdl would have fooRel as the operation with input 
> message parts fooInput plus wsrm:Request, and with output message
> parts fooOutput plus wsrm:response.
>
> The ws security “level” wsdl would have fooSec as the operation with 
> input message parts fooInput, wsrm:request, and wss:requestHeader, and
> output message parts fooOutput plus wsrm:response plus 
> wss:respnseHeader elements.
>
> I just want to point out that we could describe the boundaries of wss 
> processing )i.e. succesive layers)
> each having their own effective abstract. wsdl spec.
>
> This might help to explain what is going on, even if the “effective” 
> WSDL is never actually formally registered. It is useful for 
> conceptually explaining what is going on.
>
>
  While I understand your good intentions here, I think  we should not 
do this as it  complicates the
  specification by being too verbose and deviating form the fundamental 
and core reliability stuff.

   I strongly advocate that our spec. should be very simple and just 
concentrate our own protocol.
   I for one still not totally convinced that we should dwell too much 
into the abstract stuff. For that
   matter, I'm still not convinced that we need the 'Respond' abstract 
operation.

   The underlying problem (the 'Ordering' problem) you mentioned  is 
indeed a genuine problem,
   but beyond the scope of our chapter and should be dealt by a SOAP 
processors/engine.

   2 specific problems with your reasoning:
   i) I for one will desist to include WSRM Headers or for that matter 
any QoS Headers in the
      WSDL definition. While it is indeed legal, I believe part to 
Header mapping is more meant
       for application Headers and not QoS. So I don't like to talk 
about wsdl mappings/bindings
       in our specification at all.

   ii) while your solution to have different level wsdls for security 
and reliability may work, what
       if I want both security and reliability at the same time?


 -Sunil