Re: How do Large Scale Web Service Applications Maintain Session State?
- From: "Radek Cerny" <radek.cerny@xxxxxxxxxxxxxxxxx>
- Date: Sun, 11 Feb 2007 08:26:46 +1100
Joseph,
I completely understand your puzzlement... we went through the same issues
and finally decided that we will build stateful server sessions, and have
been very happy with the results. We do pass a session token as a parameter
on every call, and have only 1 asmx file with a handful of methods (public -
there are another 20 or so administrative and instrumentation).
There is a whitepaper showing the topology, but there is much more as well.
http://www.c1s.com.au/C1prod/files/Whitepaper.pdf
Having systems deployed through web services allows clients to access via
rich [thin] clients, browsers via AJAX, etc.
Cheers,
Radek
"Joseph Geretz" <jgeretz@xxxxxxxxxx> wrote in message
news:Oe2Gk0HTHHA.2212@xxxxxxxxxxxxxxxxxxxxxxx
Doesn't anyone use server side caching to manage session state?
If there's something fundamentally wrong with this approach, please let me
know.
Thanks!
- Joseph Geretz -
"Joseph Geretz" <jgeretz@xxxxxxxxxx> wrote in message
news:unvWIcBTHHA.4252@xxxxxxxxxxxxxxxxxxxxxxx
I've been looking at two approaches for the maintenance of Session state
for a Web Service application.
One approach uses the old familiar Session object which I've used in the
past for Web applications. As far as I can see, the Session approach is
non-standard since Web Services are supposed to be agnostic with respect
to their clients. It seems that cookies are outside the Web Service
standard; therefore, such a Web Service application won't work for those
clients which are not equipped to shuttle the Session cookie back and
forth.
The second approach I have researched uses the Context.Cache object, plus
a unique session ID which is shuttled back and forth as a parameter on
every method call. The unique session ID is of course, the index into the
Cache object for the retrieval of session related data. I see two
drawbacks to this approach. The first issue, is that this approach
affects the parameter signature practically every single public method in
the entire application. OK, this is perhaps a minor detail. For all I
know, this may be standard practice?
The second issue however, is that for a large scale Web Services
application, supporting thousands of concurrent sessions, the Cache
memory consumption on the server is liable to be quite large and this
could be a problem.
So I'm wondering, what is the best way to do this?
Tangentially, I'm also curious how you typically engineer your Web
Service applications. Would the server side application consist of a
single ASMX page with all application methods in a single page, or would
you break your application into separate pages? I'm thinking that from
the standpoint of team development alone, the latter method is the
correct approach.
I appreciate any advice which you can offer.
Thanks!
Joseph Geretz
.
- Follow-Ups:
- Re: How do Large Scale Web Service Applications Maintain Session State?
- From: John Saunders
- Re: How do Large Scale Web Service Applications Maintain Session State?
- References:
- How do Large Scale Web Service Applications Maintain Session State?
- From: Joseph Geretz
- Re: How do Large Scale Web Service Applications Maintain Session State?
- From: Joseph Geretz
- How do Large Scale Web Service Applications Maintain Session State?
- Prev by Date: Re: Connecting .mdb to webservice through firewall
- Next by Date: Re: How do Large Scale Web Service Applications Maintain Session State?
- Previous by thread: Re: How do Large Scale Web Service Applications Maintain Session State?
- Next by thread: Re: How do Large Scale Web Service Applications Maintain Session State?
- Index(es):
Relevant Pages
|
