"Pablo Cibraro [MVP]" wrote:

> Hi Rob,
>
> You can enable the ASP.NET session for the web services, but as you said, it
> requires a cookie on the client and it is bound to HTTP. (This article
> describes how to do that
> http://dotnetjunkies.com/QuickStartv20/webservices/doc/Intrinsics.aspx)
>
> The ASP.NET cache is another option, but since it is a cache, it can expire
> if it is not being used. All the items are kept in memory, if you want to
> store the items in different stores, you should take a look to a more
> sotisficated solution, like the Enterprise Library Caching Application
> Block. This last one allows you to keep the items in different stores, for
> instance, a SQL Server database but this cache is intended to be used as
> read-only.
>
> Regards,
> Pablo Cibraro.
>
>
>
> "theGecko" <theGecko@discussions.microsoft.com> wrote in message
> news:2A1BE468-B962-4C3B-99D3-28528FE4242C@microsoft.com...
> >I am aware that web services should be entirely stateless and it seems to
> >be
> > recognised as bad design to keep state.
> > BUT, some of the methods we are exposing are extremel complicated and need
> > various server-side structures and database information to be loaded prior
> > to
> > each call.
> >
> > To reduce overhead, we would like to implement some sort of state
> > architecture for our web service.
> > A quick internet search has shown that there seem to be two approaches to
> > this.
> >
> > 1. - Use ASP.NET sessions, storing a cookie on the client. This isn't a
> > viable option as we can't be bound to the HTTP protocol nor dictate that
> > our
> > users store the session state.
> >
> > 2. - Store state on the server and uniquely identify each visitor. I've
> > seen
> > mention that some sort of SID stored in the SOAP header is one way to do
> > this, but no examples of actually storing the information.
> >
> > We use windows authentication to authorise users to our web service, so
> > can
> > uniquely identify every visitor to the service using active directory.
> > Ideally we would like to use the username as a key to storing state
> > somewhere on the server and it would be perfect if we could 'hook into'
> > the
> > existing session functionality to take advantage of the various ways
> > sessions
> > can be stored (SQL, across farms, etc.).
> > Does anyone know a way of doing this (it may be impossible due to security
> > risks) or have a better suggestion? We are currently using dictionaries to
> > store the settings on the server but are worried they could grow and use
> > up
> > memory if the service is never allowed to unload.
> >
> > Any thoughts, suggestions or flames will be appreciated :)
> >
> > Cheers,
> >
> > Rob
> >
>
>