How do Large Scale Web Service Applications Maintain Session State?

[Joseph Geretz]

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

[Joseph Geretz]

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" <jg*****@nospam.comwrote in message
news:un**************@TK2MSFTNGP05.phx.gbl...

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

[John Saunders]

"Joseph Geretz" <jg*****@nospam.comwrote in message
news:Oe**************@TK2MSFTNGP02.phx.gbl...

Doesn't anyone use server side caching to manage session state?

If there's something fundamentally wrong with this approach, please let me
know.

Joseph,

One of the principals of SOA is to try to keep web services stateless. There
would be one large, coarse-grained operation rather than a number of
fine-grained operations which need to execute in a particular order and
maintain state between calls.

John

[Radek Cerny]

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" <jg*****@nospam.comwrote in message
news:Oe**************@TK2MSFTNGP02.phx.gbl...

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" <jg*****@nospam.comwrote in message
news:un**************@TK2MSFTNGP05.phx.gbl...

>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

[John Saunders]

Radek,

Perhaps you could describe, in general, what it was about your application
which prevented you from using a stateless model?

Thanks,
John

"Radek Cerny" <ra*********@nospam.c1s.com.auwrote in message
news:uJ**************@TK2MSFTNGP06.phx.gbl...

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" <jg*****@nospam.comwrote in message
news:Oe**************@TK2MSFTNGP02.phx.gbl...

>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" <jg*****@nospam.comwrote in message
news:un**************@TK2MSFTNGP05.phx.gbl...

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

[Joseph Geretz]

Hi John,

Here's are a few specific example, in our case. First of all, our
application implements application defined authentication. To keep every
transaction absolutely stateless, this will require authentication on every
single application call. Won't it be much more efficient to allow the client
application to authenticate once against the database and then to maintain
that authenticated state for every transaction which is submitted by that
authenticated client, until the client logs off, or the time-out period
expires?

Second, and tangentially related issue, our application defines detailed
user profiles which define what a particular user can and cannot do. Again,
absolute statelessness on the Server would require us to check the database
on every single transaction to authorize the transaction. Our concept is to
cache these profiles on the server in order to increase performance.

Naturally, I agree with you that specific application classes (i.e. classes
providing direct services to application clients) on the server should not
maintain state, since this limits their usability to a single client.
However, the caching of session state on the server is a different issue and
can have tremendous benefits for performance, without compromising
scalability, if done correctly (as far as I can imagine). Our proposed
architecture would implement a stateful Web Service server application,
which is something different than stateful Web Service classes.

Again, if this is fundamentally a bad idea, I'd be interested to learn why.
But if others have implemented server side caching successfully, I am
interested to hear about that as well.

Thanks!

- Joseph Geretz -

"John Saunders" <john.saunders at trizetto.comwrote in message
news:e9**************@TK2MSFTNGP02.phx.gbl...

Radek,

Perhaps you could describe, in general, what it was about your application
which prevented you from using a stateless model?

Thanks,
John

"Radek Cerny" <ra*********@nospam.c1s.com.auwrote in message
news:uJ**************@TK2MSFTNGP06.phx.gbl...

>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" <jg*****@nospam.comwrote in message
news:Oe**************@TK2MSFTNGP02.phx.gbl...

>>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" <jg*****@nospam.comwrote in message
news:un**************@TK2MSFTNGP05.phx.gbl...
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

[John Saunders]

"Joseph Geretz" <jg*****@nospam.comwrote in message
news:Os****************@TK2MSFTNGP03.phx.gbl...

Hi John,

Here's are a few specific example, in our case. First of all, our
application implements application defined authentication. To keep every
transaction absolutely stateless, this will require authentication on
every single application call. Won't it be much more efficient to allow
the client application to authenticate once against the database and then
to maintain that authenticated state for every transaction which is
submitted by that authenticated client, until the client logs off, or the
time-out period expires?

You can authenticate once, and have the "login" operation return an
authentication token in a SOAP header. All subsequent operations would
include the token in a SOAP header they send. I've implemented this, and
it's very simple.

Second, and tangentially related issue, our application defines detailed
user profiles which define what a particular user can and cannot do.
Again, absolute statelessness on the Server would require us to check the
database on every single transaction to authorize the transaction. Our
concept is to cache these profiles on the server in order to increase
performance.

The profiles can certainly be cached. You would use the authentication
information in the token (or referred to by the token) to determine which of
the cached profiles to use for the current operation. This is application
state, not operation state.

Naturally, I agree with you that specific application classes (i.e.
classes providing direct services to application clients) on the server
should not maintain state, since this limits their usability to a single
client. However, the caching of session state on the server is a different
issue and can have tremendous benefits for performance, without
compromising scalability, if done correctly (as far as I can imagine). Our
proposed architecture would implement a stateful Web Service server
application, which is something different than stateful Web Service
classes.

We may be using the term "stateful" to mean different things. "Stateless" to
me doesn't mean that the server doesn't maintain any state. It means that
the server doesn't depend on the saved state from previous operations in
order to process the current operation. It means that the operations aren't
constrained to execute in a particular order because the results of one
operation are required before the next can execute.

For instance, I said you can cache the profile information. But if the
profile isn't in the cache when you need to use it, you don't fail - you
load the profile into the cache.

As an example of what not to do, it would be better to create a file system
access service by creating a "ListDirectory" operation rather than
"FindFirst" and "FindNext" operations. "FindNext" requires the server to
maintain state from the "FindFirst" and previous "FindNext" operations.
HTH,
John

[Joseph Geretz]

Hi John,

I think we are on the same wavelength.

For instance, I said you can cache the profile information.
But if the profile isn't in the cache when you need to use it,
you don't fail - you load the profile into the cache.

Yes, this is exactly the approach we will use for data which we cache on the
server. The only question that I have is regarding the 'key' to any
user-specific information which is cached on the server. The options I've
been considering have been either to implement this in a session cookie, or
as a specific parameter. Either of these approaches has a drawback; use of
the cookie will tie the Web Service implementation to HTTP, the other
approach will require an extra parameter to be supplied with every method
call. You describe a third alternative, which is unfamiliar to me:

You can authenticate once, and have the "login" operation return an
authentication token in a SOAP header. All subsequent operations would
include the token in a SOAP header they send. I've implemented this, and
it's very simple.

I'd be interested to hear more about how this is implemented.

Once a session is established, I think I'd like to assign a GUID as a
session ID. The GUID would be the index into the cache for any session
related data which is cached on the server. I'd encapsulate the session ID
as well as the user's account credentials into the SOAP header (or cookie,
or token). Let's say the session in the server cache expires after 10
minutes of inactivity. On the next transaction I could simply use the
account credentials to re-login and recreate the cache on the server. With
this approach, I can accumulate data on the server for performance purposes
and expire data on the server to avoid unnecessary resource consumption
without impacting the user (except for the performance drop on the first
transaction following an idle timeout).

Naturally, I need some way to keep password information secure. This is true
regardless of which approach I use. Even if the password is only sent across
the wire during initial login, I need a way to ensure that this is secure.

Any advice regarding the use of SOAP headers as you suggest, and/or the
implementation of secure web services will be very much appreciated.

Thanks!

- Joe Geretz -

"John Saunders" <john.saunders at trizetto.comwrote in message
news:em**************@TK2MSFTNGP04.phx.gbl...

"Joseph Geretz" <jg*****@nospam.comwrote in message
news:Os****************@TK2MSFTNGP03.phx.gbl...

>Hi John,

Here's are a few specific example, in our case. First of all, our
application implements application defined authentication. To keep every
transaction absolutely stateless, this will require authentication on
every single application call. Won't it be much more efficient to allow
the client application to authenticate once against the database and then
to maintain that authenticated state for every transaction which is
submitted by that authenticated client, until the client logs off, or the
time-out period expires?

You can authenticate once, and have the "login" operation return an
authentication token in a SOAP header. All subsequent operations would
include the token in a SOAP header they send. I've implemented this, and
it's very simple.

>Second, and tangentially related issue, our application defines detailed
user profiles which define what a particular user can and cannot do.
Again, absolute statelessness on the Server would require us to check the
database on every single transaction to authorize the transaction. Our
concept is to cache these profiles on the server in order to increase
performance.

The profiles can certainly be cached. You would use the authentication
information in the token (or referred to by the token) to determine which
of the cached profiles to use for the current operation. This is
application state, not operation state.

>Naturally, I agree with you that specific application classes (i.e.
classes providing direct services to application clients) on the server
should not maintain state, since this limits their usability to a single
client. However, the caching of session state on the server is a
different issue and can have tremendous benefits for performance, without
compromising scalability, if done correctly (as far as I can imagine).
Our proposed architecture would implement a stateful Web Service server
application, which is something different than stateful Web Service
classes.

We may be using the term "stateful" to mean different things. "Stateless"
to me doesn't mean that the server doesn't maintain any state. It means
that the server doesn't depend on the saved state from previous operations
in order to process the current operation. It means that the operations
aren't constrained to execute in a particular order because the results of
one operation are required before the next can execute.

For instance, I said you can cache the profile information. But if the
profile isn't in the cache when you need to use it, you don't fail - you
load the profile into the cache.

As an example of what not to do, it would be better to create a file
system access service by creating a "ListDirectory" operation rather than
"FindFirst" and "FindNext" operations. "FindNext" requires the server to
maintain state from the "FindFirst" and previous "FindNext" operations.
HTH,
John

[Radek Cerny]

John,

basically it was the only way. We use Web Services purely as a deployment
mechanism. What we have, is in fact a full ERP/CRM/Financial system, that
grew up as abstract business objects in a 4GL. When a user "logs in" we
create a stateful server session. There are session sweepers and all sorts
of mechanisms to keep things in check, but we were able to port the entire
framework and ERP/Accounting application with minimum effort to c#. The
traffic between client & server is basically a delta exchange, so is
minimal. All business rules, persistence, formatting etc occur on the
server. We have a generic AJAX and rich Winforms client that understands
the framework delta exchange.

For us, stateful was the only way to go. Obviously, we had some hard
planning and thinking to do, and countless debates since then, but we've had
only success and no nasty side-effects from being stateful.

Cheers,

Radek
"John Saunders" <john.saunders at trizetto.comwrote in message
news:e9**************@TK2MSFTNGP02.phx.gbl...

Radek,

Perhaps you could describe, in general, what it was about your application
which prevented you from using a stateless model?

Thanks,
John

"Radek Cerny" <ra*********@nospam.c1s.com.auwrote in message
news:uJ**************@TK2MSFTNGP06.phx.gbl...

>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" <jg*****@nospam.comwrote in message
news:Oe**************@TK2MSFTNGP02.phx.gbl...

>>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" <jg*****@nospam.comwrote in message
news:un**************@TK2MSFTNGP05.phx.gbl...
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

[John Saunders]

"Joseph Geretz" <jg*****@nospam.comwrote in message
news:uG*************@TK2MSFTNGP05.phx.gbl...

Hi John,

....

Any advice regarding the use of SOAP headers as you suggest, and/or the
implementation of secure web services will be very much appreciated.

SOAP headers are pretty easy to use. There's a good example in the MSDN
documentation at
http://msdn.microsoft.com/library/de...ClassTopic.asp.

John

[nano2k]

On Feb 11, 8:35 pm, "John Saunders" <john.saunders at trizetto.com>
wrote:

"Joseph Geretz" <[e-mail] in message

news:uG*************@TK2MSFTNGP05.phx.gbl...Hi John,

...

Any advice regarding the use of SOAP headers as you suggest, and/or the
implementation of secure web services will be very much appreciated.

SOAP headers are pretty easy to use. There's a good example in the MSDN
documentation athttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpre....

John

I decided to include a session parameter to all my public webmethods.
Basically, it's an xml string that can be filled up with many other
values without changing the method's signature.
For example, you could pass the following xml string:
<params>
<sessID>{DB71225D-C212-4E0C-BDDC-436065FF97B7}<sessID/>
<params/>

I few days, you decide to pass more info, so you may "upgrade" the xml
as follows:
<params>
<sessID>{DB71225D-C212-4E0C-BDDC-436065FF97B7}<sessID/>
<userID>{E23DB508-C285-4FA1-82C7-F3E0E981A537}<userID/>
<params/>

etc
Anyway, this was my personal decision because I use a class to
serialize/deserialize it.
So, before calling the webmethod, I call this method:
string GetXml()
the result will be passed as parameter to the webmethod.
On the server side, I call
void SetXml(string xml)
which will simply fill the properties of my instance.

I found this method to be more simple to maintain over time.
Of course, John's method of passing "session" data is more
standardized and maybe is better than my method.

Cheers.
Adi.

[Keith Patrick]

If you'd be doing InProc session state, I guess there wouldn't be much
difference, but in either case, your memory runs the risk of getting chewed
up linearly as you add users. It's similar to an issue someone mentioned re:
..Net 2.0's on-page datasources, as they store viewstate on each client's
machine. There was a recommendation from someone to just cache on the server
instead, since memory is so much faster than encoded text, but again, doing
this puts an extra burden on the server's memory pool for each user, and
because viewstate and session state are by definition unique to each user's
login, you can't share the same data across multiple sesions.
As for me, I try to keep as much out of the session & as much in the
ViewState as possible. It spreads the memory burden a bit more evenly,
reduces database hits (for SQL session state), and treats state as the more
transient form-to-form data instead of session-wide. There's an
encoding/decoding burden at the server, but it's a one-time (per request)
CPU hit.