axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sanjiva Weerawarana" <>
Subject Re: How to get/pass header session information
Date Mon, 01 Oct 2001 17:20:53 GMT
Doug Davis writes:
> The way I look at is this...would a Web service ever want to get
> access to other parts of the SOAP envelope besides the body?
> Chances are yes (which is one of the reasons people were asking
> for access to the SOAPContext object back in v2).

That was for the server side, not the client .. 

> So, if someone can come up with a use-case
> where is makes sense for a service (not a handler) to access
> a header, then I see no reason why a client app wouldn't want
> the same functionality.

If client apps can manipulate headers arbitrarily, then they may
affect the execution in unintended or inappropriate ways. For 
example, if the service is "instanced" and there's a correlation 
header being sent back and forth, that's really context the 
runtime (the "orb") needs to handle and not expose at all to 
the client. Otherwise the client may mess with it!

> I agree with you that from a pure architectural point of view
> not mucking with the envelope is better - that way you can
> switch-out SOAP for some other protocol - but I do believe
> that there will be people who will want to add specialized
> headers without having to write handlers.

I don't think the client API should support that; if you want to mess
with headers then you have to write a handler and have the authority
to deploy the handler.

There are people out there who will want to do pretty much any
thing. The question is what's the right thing to do?!

> BTW - to say that they contain information that isn't part of
> the request isn't totally correct.  Headers can contain anything.
> And the spec itself even says that certain headers (MUs) will
> probably change the semantics of the processing, so I don't think
> we can assume they'll just contain "contextual info".

Mathematically SOAP lets you put the message itself in a header.
However, the intent is that that's not what would be done. Similarly
if applications start using headers for non "header-like" stuff, 
then that (IMO) is going out of the intended usage of headers.


View raw message