A big +1 to what Marc said. Cheers, Christopher Ferris STSM, Emerging e-business Industry Architecture email: chrisfer@us.ibm.com blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440 phone: +1 508 377 9295 Marc.Hadley@Sun.COM wrote on 02/01/2006 09:42:58 AM: > On Feb 1, 2006, at 1:18 AM, Anish Karmarkar wrote: > > > >>> However, given what Mark observed, I suspect > >>> that we might do well to specify that at a minimum, the SOAP > >>> processing w/r/t SOAP headers MUST be performed before any > >>> response is generated, so as to ensure that if a mU fault is > >>> generated, it can be transmitted on the HTTP response (with a 500). > >> Except I might legitimately send back a 202 Accepted following > >> securing the message in a database or putting it onto a reliable > >> message queue, well before any SOAP processing has taken place. > > > > +1 > > > That's one alternative. > > > Or In the WSRX case, I might send back a 202 with a WSRX ack after > > processing all the WSRX headers and storing the messages in a DB, > > but before processing other non-WSRX headers. > > > That idea trouble me a bit, the SOAP processing model is all or > nothing, allowing some headers to be processed and others to be > ignored (at least for mU processing) diverges from the spec as I read > it. > > Marc. > > > > >> For my money the ability to send a RX ACK in a 202 is interesting > >> and falls well within RFC2616's 202, but presumably would require > >> SOAP processing generating MU faults etc, so would require more RX > >> specific instruction in such a note building upon Dave's one-way > >> note. > >> Paul > > > > --- > Marc Hadley <marc.hadley at sun.com> > Business Alliances, CTO Office, Sun Microsystems. > >
Received on Wednesday, 1 February 2006 15:12:46 UTC