Re: Maintain session state between Calls

[Andy Longshaw <an...@blueskyline.com>]

Hi Glen,

I'm not convinced about the statement below:

> In general, I agree with what you say here except to say that there are also
> plenty of cases where you DO want to use an underlying transport mechanism for
> things like session IDs.  In many cases this mechanism will be already built
> into the underlying protocol engine, and it's more efficient to take advantage
> of that mechanism than to use SOAP headers.  The same holds for things like
> security - you might encrypt the body and build a SOAP header which contains a
> certificate, or you might just be running over HTTPS, which would save you the
> trouble.  The XML Protocol groups' Transport Binding Task Force is working on
> just these kinds of issues for SOAP 1.2.

Although I agree that it would be more efficient to use an existing underlying
mechanism to provide things like encryption and authentication, this only holds
for point-to-point exchanges. In the context of Axis as basically a SOAP-based
RPC engine for Java then this is generally OK. However, if any part of the
message being passed will be propagated onwards (as in message-based systems)
then the point-to-point security and authentication is not enough - it needs to be
end-to-end. My concern then is over having two different styles of security - one
form for RPC and one form for messaging since this begs the question "where
does RPC end and messaging begin with regards to SOAP messages?". What is
the difference between a point-to-point "message" and an RPC with one literal
XML parameter?

Cheers

Andy