[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]