xml-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Blaine Horrocks <blaine.horro...@cp.net>
Subject Re: PROPOSAL on scopes (was: Re: Java Sevlet Implementation - Attachment)
Date Tue, 08 Aug 2000 18:25:49 GMT
While from an rpc perspective the application, session and request semantics
are pretty clear you could make a case for the pages semantics also.    The
real problem is that the semantics are different.  The first three express
semantics relative to state involving the user and the implementation of the
behaviour (i.e. how much state the implementation can hold across requests).
Page semantics otoh, reflect semantics between the user, implementation, and
also the resource identified by the url, making it confusing.

Really this is just another aspect of whether the soap spec should be tied to
http as a transport.  Now, according to the present spec if you have the header
=> SOAPAction: ""   <= in your http url indicates the intent (target?) of the
rpc.  Naturally this would be a page in html-land.   It would almost require
the 'page' lifecycle if you were intending to share resource state over
multiple users unless you were willing to reread it from persistent storage for
each request.   Rereading it is of course the accepted way that TP monitors
achieve load balancing.  <g>

Now it would be nice to have some way to target various resources using RPC as
well as through a browser.  If you think MVC, or just MV in this case, the
resource becomes the model, and the choice of representation would depend on
whether you accessed by requestiong a soap rpc or just a page view.   Which
I think may have been the original intent of the SOAPAction binding.

Apache-soap uses the method name namespace urn as the "target" of the rpc,
which is actually wrong wrt the spec.   The spec states (section 7) that "For
example, for HTTP the request URI indicates the resource that the invocation is
being made against".   If this is really true then 'page' sematics can make

Long and the short of it?

- Page lifecycle does make sense from the spec but we probably don't want to
support it because it implies maintaining to much state in the server.
- We should look at addressing the current limitations wrt matching the
provider up to the url and also the intent in the SOAPAction header because
these shortcomings are a big chunk of why the 'page' lifecycle doesn't make


Sanjiva Weerawarana wrote:

> - page meant all hits to the same page had the same object .. this one's
>   very flaky for our scenario because all hits are delivered via
>   rpcrouter.jsp. This definitely needs to be dropped.

View raw message