- From: David Orchard <dorchard@bea.com>
- Date: Tue, 2 Nov 2004 13:29:09 -0800
- To: "Martin Gudgin" <mgudgin@microsoft.com>, "Harris Reynolds" <hreynolds@webmethods.com>, <public-ws-addressing@w3.org>
- Message-ID: <32D5845A745BFB429CBDBADA57CD41AF0B6CEB48@ussjex01.amer.bea.com>
When you say "I'm a SOAP programmer", which context is the "I"? As a developer for the Indigo/.Net team that has written software that operates on .Net specific refprops as headers, or as a hypothetical application developer, or something else? When I say "processed b4 the actual service", I'm talking about layers if the app/infrastructure are built that way. A common implementation of ws-security and ws-rm will be as software modules in a pipeline that the app developer never sees. The bearing on ref properties is that the infrastructure that will do dispatch will be "b4" the app. Therefore it's not meant for the application developer but for a convenience of the infrastructure code. And I haven't yet heard of dispatch based on ref props that is done in multiple steps, ie why use more than 1 header block. Dave _____ From: Martin Gudgin [mailto:mgudgin@microsoft.com] Sent: Tuesday, November 02, 2004 1:15 PM To: David Orchard; Harris Reynolds; public-ws-addressing@w3.org Subject: RE: Issue 011 I agree that WS-A is a fundamental part of Web Services. And therefore I agree that there IS software that understands wsa:To. BUT there is also software 'outside' the WS-A layer, that understands just the SOAP processing model and the headers that are present because of RefProps/Params in some EPR. I'm a SOAP programmer. Not a WS-A programmer. I want to process things at the SOAP header layer. That's how I want to route messages to the appropriate piece of code. It's a general model that applies to ALL headers, not just those placed in as RefProps/Params. I don't understand what you mean by 'processed before the actual service', are you talking about layers of processing? If so, then sure, some (many?) headers are processed by a layer in the SOAP stack that gets invoked prior to the body being processed. I'm not sure how this bears on RefProps/Params appearing as headers. Gudge _____ From: David Orchard [mailto:dorchard@bea.com] Sent: 02 November 2004 14:26 To: Martin Gudgin; Harris Reynolds; public-ws-addressing@w3.org Subject: RE: Issue 011 Can you elaborate a bit on this? I agree that using SOAP headers for all refs is more general, but I'm not sure I quite get the use cases and hence the utility If we take a look at the WS-* specs, almost all the specs define headers that are processed before the actual service - like rm, security, etc. In fact, various vendors have worked very hard to ensure that headers are not available for the application, as we had to work very hard to get the Application Data feature in WSDL 2.0 Every use case I've heard of for refs (except the one that I introduced about statelessness) is for identifying the actual service. Thus there are separate modes of usage of the service identifier versus infrastructure headers. Given that WS-Addressing will hopefully become a fundamental piece of Web services - and arguably should have been in SOAP 1.2 - and that the To field is required, is it really that much a problem to put a dependency on wsa:To in the service identification bit? Especially when the software that wraps the ref props implicitly depends upon the ws-a processing model and explicitly relies upon the soap processing model. I believe that I'm poking at the real world use cases and implementation of soap/ws-a stacks rather than theoretical "it would be nice to separate". And I think that talking about just the header structure rather than mU and role are where we can get some fruitful discussion. Cheers, Dave _____ From: public-ws-addressing-request@w3.org [mailto:public-ws-addressing-request@w3.org] On Behalf Of Martin Gudgin Sent: Tuesday, November 02, 2004 6:47 AM To: Harris Reynolds; public-ws-addressing@w3.org Subject: RE: Issue 011 I don't believe this characterization is complete. The reason for taking advantage of the SOAP processing model is to take advantage of the whole model, not just mustUnderstand processing. The model of SOAP is that SOAP nodes process headers. Different pieces of software, possibly at different nodes, possibly at a single node, can process different headers. Pushing RefProps(Params) into the wsa:To header means that I now have to have a piece of software the processes the wsa:To header ( it needs to understand at least that much of WS-Addressing ) and then pull out the relevant descendant elements. To me, this makes the processing model 'the WS-Addressing processing model' and not the 'SOAP processing model'. I want software to be able to use the latter without having to know anything about the former. Gudge _____ From: public-ws-addressing-request@w3.org [mailto:public-ws-addressing-request@w3.org] On Behalf Of Harris Reynolds Sent: 02 November 2004 09:36 To: public-ws-addressing@w3.org Subject: Issue 011 Here is a brief restatement of the issue: Why is the To EPR not serialized in the same way that ReplyTo or FaultTo EPRs are? I understand Gudge's comment at the F2F indicating that there is a difference between using an EPR to address a message (i.e. the "To" element) and sending an EPR for subsequent use in the case of ReplyTo/FaultTo etc. However, there still seems to an opportunity to simplify the specification by serializing EPRs similarly in both requests and responses. The advantage of the current approach is that the current SOAP 1.2 processing model can be used for processing reference properties (parameters); primarily using the mustUnderstand attribute. In my view, the advantage of serializing the To element directly as an EPR instead of splitting it into Address and Ref Props is simplicity. Using this approach the specification is easier to understand for those responsible for implementing it: if you have an EPR, just stuff it into the SOAP header and your work is done. As far as processing the EPR, the same amount of work will be required either way. From a practical perspective either method of serialization would work. The question is which would produce a better specification? ~harris ------------------------------ Harris Reynolds webMethods, Inc. http://www.webmethods.com/ ------------------------------
Received on Tuesday, 2 November 2004 21:29:15 UTC