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/ 
> >                              ------------------------------ 
> > 
> > 
>