- From: David Hull <dmh@tibco.com>
- Date: Mon, 05 Dec 2005 16:01:03 -0500
- To: Marc Hadley <Marc.Hadley@Sun.COM>
- Cc: Anish Karmarkar <Anish.Karmarkar@oracle.com>, "Yalcinalp, Umit" <umit.yalcinalp@sap.com>, public-ws-addressing@w3.org
Marc Hadley wrote: > +1, I don't like the requirement to include an empty SOAP envelope in > the 202 reply and note that this is contrary to the WS-I recommendation. I thought that was a typo in the first place? > > Marc. > > On Dec 5, 2005, at 3:11 PM, Anish Karmarkar wrote: > >> >> One comment below. >> -Anish >> -- >> >> Yalcinalp, Umit wrote: >> >> <snip/> >> >>> *3.1.2 SOAP 1.1/HTTP Extension Semantics by using >>> wsaw:UsingAddressing element:* >>> The presence of the wsaw:UsingAddressing element in the binding or >>> endpoint (port) components of the endpoint description extends the >>> semantics of the SOAP 1.1/HTTP binding. In the case of the WSDL >>> SOAP/HTTP synchronous binding for request-response operations, the >>> presence of the wsaw:UsingAddressing element changes the >>> requirement that the response message be sent over the same HTTP >>> channel over which the request was received. Further, the presence >>> of the wsaw:Anonymous element may specify how anonymous addresses >>> are treated specific to an operation defined in a binding. >>> Therefore, the wsa:replyTo header in the request MAY contain an >>> address with a value different from the anonymous URI when >>> wsaw:UsingAddressing marker is used by extending the semantics of >>> SOAP1.1/HTTP binding. >>> Usage of wsaw:UsingAddressing element indicates that SOAP1.1/HTTP >>> binding is allowed to use a separate connection for sending >>> response messages, instead of using the same HTTP connection. This >>> extension allows SOAP 1.1/HTTP to be used asynchronously. Hence, >>> the response message MAY be sent over the same HTTP channel over >>> which the request was received or by opening a separate connection, >>> depending on the following conditions: >>> · When the value of the [reply endpoint] in the request >>> message contains the anonymous URI as its address, the response >>> MUST be sent over the same HTTP channel. · When the value >>> of [reply endpoint] contains an address that is different than the >>> anonymous URI, this extension requires that >>> o The receipt of the request message MUST be acknowledged >>> with a status message (202) by the receiver using the HTTP >>> connection that generated the request. The receipt message MUST >>> contain an empty SOAP envelope. / (Lets discuss this further)/ >> >> >> Why is the empty SOAP Envelope required? >> >> Does empty SOAP envelope mean: no SOAP headers and an empty body? >> >> What seems strange about the empty SOAP envelope is that: >> The MEP (or transmission primitive) says that the exchange is req- >> res and the requester gets back 2 soap messages (one "empty" >> envelope sent on the HTTP back channel and the other "real" reply on >> the ReplyTo EPR). Where is the empty envelope processed? Is it >> delivered to the App? >> >> Thanks. >> >> -Anish >> -- >> >>> o The actual response MUST be sent using a separate >>> connection using the address value of the response message >>> specified by [reply endpoint]. >>> The wsaw:Anonymous element specifies the following semantics for a >>> specific operation in SOAP1.1/HTTP: >>> · “optional” value indicates the same semantics that is >>> defined for wsaw:UsingAddressing above, namely anonymous URIs are >>> allowed, but not required. >>> · “required” value indicates that the response message be >>> sent over the same HTTP channel over which the request was >>> received. In essence, it indicates requirement for always using >>> synchronous responses. >>> · “prohibited” value indicates that SOAP1.1/HTTP binding >>> must always use a separate connection for sending response >>> messages, instead of using the same HTTP connection. In essence, it >>> indicates requirement for always using asynchronous responses. >>> /Note: We may consider including a paragraph here as a note to >>> indicate that SOAP processing rules dictate how responses/errors >>> are generated and sent to appropriate destinations depending on >>> when the extensions are processed and engaged following the >>> discussion in the wg. **/ >>> * * >> >> >> <snip/> >> > > --- > Marc Hadley <marc.hadley at sun.com> > Business Alliances, CTO Office, Sun Microsystems. > >
Received on Monday, 5 December 2005 21:05:43 UTC