RE: Issue 011

Hi Greg:

You make a fine point below, and indeed it may be quite reasonable to
decide that <wsa:To> shouldn't be an entire EPR due to the potential
costs of copying the whole thing.  Of course, those costs also exist
when serializing a <ReplyTo> or <FaultTo> EPR, which will be very common
to do for many MEPs, or even a <From>.

Perhaps this should open some questions about levels of serialization
for EPRs - for instance, if I know (through previous interaction or
out-of-band agreement) the complete (and very complex) policy for an
endpoint I'll be replying to, is it necessary for them to serialize the
entire policy in the <ReplyTo> EPR?

I'm not committed to a particular solution to this issue (or issue 8,
for that matter, though I do believe that refps should NOT be individual
SOAP headers, whatever their eventual serialization), I just want to
make sure we explore the landscape adequately.

--Glen 

> -----Original Message-----
> From: public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of Greg Truty
> Sent: Wednesday, November 03, 2004 11:33 AM
> To: public-ws-addressing@w3.org
> Subject: Fw: Issue 011
> 
> 
> With respect to "complexity, simplicity, clarity", I think 
> looking back at past technologies that have gone down this 
> path is useful as those who cannot learn from history are 
> doomed to repeat it.  The packaging up and usage of a subset 
> of the EPR has some past precedent.  IIOP uses EPRs as it's 
> reference it passes across.  IIOP actually doesn't send the 
> who IOR back to the server.  Instead, it just pulls out the 
> opaque key on the request (since, the host/port used to send 
> it is redundant).  If the EPRs get heavy (w/policy 
> information and the other 2 possible QNames 
> (PortType/Service)),  it may be that we are sending redundant 
> information back.   We already know that this information may 
> be large (and necessary to resend over).  So, while the 
> arguments of simplicity, consistency, clarity is nice in that 
> it's easier to copy and it's encapsulated, I'm not convinced 
> that you always want to copy/paste it as is (given the 
> current definition). 
> 
> If the decision get's made to move to this simpler mode, it 
> may appear simplier, but we will then have to look at perhaps 
> what portions of the EPR may (or may not) make sense.  In the 
> current proposal, that optimized behavior is built into the 
> solution (and I think would need to be addressed going 
> forward).  It's unclear right now then whether it will be 
> simpler, clearer to do this then. 
> 
> Regards... Greg
> 
> 
> 
> ----- Forwarded by Greg Truty/Austin/IBM on 11/03/2004 01:25 PM ----- 
> 
> "Martin Gudgin" <mgudgin@microsoft.com> Sent by: 
> public-ws-addressing-request@w3.org 
> 
> 11/02/2004 10:02 PM To
> "Glen Daniels" <gdaniels@sonicsoftware.com>, "David Orchard" 
> <dorchard@bea.com>, "Harris Reynolds" 
> <hreynolds@webmethods.com>, cc Subject
> RE: Issue 011
> 
> 	
> 
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Glen Daniels [mailto:gdaniels@sonicsoftware.com]
> > Sent: 02 November 2004 17:45
> > To: David Orchard; Martin Gudgin; Harris Reynolds; 
> > public-ws-addressing@w3.org
> > Subject: RE: Issue 011
> > 
> > 
> > As I see it, here's what we lose by having refp's in their current 
> > form:
> > 
> > * Simplicity - as a WS-Addressing implementor, if there 
> were no extra 
> > processing involved to copy each refp into a first-class 
> SOAP header 
> > on the sending side, I would be able to simply copy the 
> "to" EPR into 
> > the <wsa:To> header and be done with it.  On the receiving side, I 
> > would simply make the refp's available to the app in the exact same 
> > way I make the <wsa:Action> available, again with no extra work to 
> > separate out which headers are refp's and which are not.  Having 
> > <wsa:To> be an EPR would also make it easier to digitally 
> sign without 
> > separating out refp headers.  Splitting refp's out seems much more 
> > complicated to me.
> 
> I don't understand "make the refp's available to the app". 
> What does this mean? The piece of code that processes the 
> body? Something else?
> 
> > 
> > * Consistency - the other "address-like" headers (From, 
> Reply-To, etc) 
> > are all EPRs, so it's a little weird to do something 
> different for To.
> 
> EPRs (can) contain information other than [address] and [ref 
> props/params]. But the address a message is sent to consists 
> of ONLY the [address] and [ref props/params]
> 
> > 
> > * Clarity - it's not clear to intermediaries/observers 
> which headers 
> > are refp's and which are not.  And even though the endpoint itself 
> > "knows"
> > which are which, headers are typically processed by layers of 
> > infrastructure code as Dave and Gudge describe below, so 
> these layers 
> > need to have a tight coupling with the rest of the engine 
> in order to 
> > correctly process the refp headers.
> 
> Why? They are JUST headers. A SOAP processor doesn't need to 
> care whether a header was inserted as a 'ref prop/param' or 
> for some other reason.
> 
> > 
> > * Safety - in the normal SOAP world, you write headers into 
> a message 
> > because you understand what they mean, and accept the 
> consequences of 
> > inserting them in there.  WS-Addressing as it stands mandates that 
> > someone using an EPR to send somewhere MUST insert each refp as a 
> > first-class SOAP header WITHOUT understanding them.  As I've said 
> > before, I think this seems somewhat dangerous and counter-intuitive.
> 
> I don't understand why this is dangerous. If you're worried 
> about EPRs you receive, only accept EPRs that have been 
> signed by someone you trust.
> 
> > 
> > Now, Gudge has said that the main gain is the use of the SOAP 
> > processing model.  I have yet to hear a real use-case for 
> WHY this is 
> > a good thing.
> > Gudge, can you describe a situation where it's really 
> useful for the 
> > EPR supplier to use first-class headers to represent refp's, a 
> > situation where it wouldn't be better to use 
> extensibility/policy to 
> > tell the other side to use a particular extension?
> 
> I've found ref props very useful for, for example, 
> implementing WS-Eventing. It allows me to give out EPRs 
> containing ref props to event sources/subscribers and have 
> software that just knows how to process SOAP headers deal 
> with them. This means I process this stuff just the same way 
> I process everything else in a SOAP message; look at the top 
> level QName and dispatch to the appropriate piece of code. I 
> don't have to tell the user of the EPR anything about those 
> ref props. This means I can use whatever design I like and 
> the other side doesn't have to understand any 'extensions'. 
> Hey, constrained agreement, who'd have thought it...
> 
> Gudge
> 
> > 
> > Thanks,
> > --Glen
> > 
> > > -----Original Message-----
> > > From: public-ws-addressing-request@w3.org
> > > [mailto:public-ws-addressing-request@w3.org] On Behalf Of David 
> > > Orchard
> > > Sent: Tuesday, November 02, 2004 1:29 PM
> > > To: Martin Gudgin; Harris Reynolds; public-ws-addressing@w3.org
> > > Subject: RE: Issue 011
> > > 
> > > 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 Thursday, 4 November 2004 20:29:05 UTC