Session and Distribution

Session State

A stateless server doesn't retain state between requests. On the other hand, some sessions are inherently stateful.

Session state is different to record data, which is the long-term persistent data held in the database and visible to sessions.

Session state needs to be committed to become record data.

Ways to store session state

Client Session State:stores the data on the client

    encoding data in a URL

    using cookies

    serializing data into a hidden field on a Web form

    holding the data in objects on a rich client.

Server Session State:

    hold the data in a session object between requests

    store in a durable way such as in a database table with session ID as a key and using a serialized object.

Database Session State:

    storing the session state in the database in the same way as record data

Bandwidth issues

Client session state means that session data need to be transferred  across the network with everyrequest. The upload bandwidth of the client may be significantly less than its download bandwidth.

Also, all of the session state may not be used for display to the user, which is a waste.

Security issues

Security and integrity become a problem for client session state, malicious users can edit session data;or gain information about the system that should not be known to the users.

Isolation

Session data needs to be isolated- one session should not affect another session. This can be tricky with Database Session State, since the session data has to be isolated from the record data in the database.

Clustering

Clustering is used to improve throughput.

Session migration allows a session to move from server to server.It leads to good load balancing for systems with long sessions.

Server affinity is the opposite, one server is forced to handle all requests for a given session.

Server Session State makes it hard to apply session migration.

Responsiveness

Server Session State implies the data is available at the server immediately in a convenient form.

For client session state, the data is readily but may be in a form that requires some parsing.

For database session state, requests to the database are required and some transformations to the data may be needed.

The size and complexity of the data will have an effect on the responsiveness of these methods.

Canceled Sessions

Users can cancel the session or simply close the browser window at any time.

Client session state is easily handled in this case - just forget about the user.

Server session state and database session state require to timeout and remove stale session state information.

Crashes

Crashes include client crash, server crash and network connection failure.

Database session state usually survives all three.

Server session state may or may not survive depending on how the session state is stored.

Client session state can survive the last two, but will not survive a client crash.

Distribution Strategies

Distributed object platforms try to make distribution as transparent as possible.

Placing different components of the application on different nodes may seem like it can lead to performance and scalability, however it may cripple performance, and make the system much harder to build and deploy.

Remote and Local Interfaces

Procedure calls with a process is very fast, between processes is orders of magnitude slower, and between hosts is still more orders of magnitude slower.

As a result, the interface for an object to be used remotely must be different from that for an object used locally with the same process:

    A local interface is best as fine-grained interface; This is good for OO design.

    A remote interface is best as coarse-grained interface; This is because a fine-grained interface results in too many remote calls which is bad for performance.

Transparent object distribution

Distributed object platforms will usually allow you to use the same method calls regardless of  whether an object is local or remote; which is an attempt to make distribution transparent.

However, remote objects should use coarse-grained interfaces and local objects should use fine-grained interfaces. This means that whenever two objects communicate the programmer has to choose which interface to use.

Transparent distribution of objects can end up with a lot of remote calls and the need for coarse-grained interfaces in most objects.

Clustering

In the clustering approach, all of the components of the application are put on the same host and different instances of the application are run on different hosts.

Interactions between the different applications instances are less frequent and easier to program for.

When is Distribution Required

obviously between the client on a desktop and the server

server applications and the database (unless stored procedures are used)

can happen between the web server and the web application, depending on implementation

different software packages may run in their own processes (like the database)

some other reason that the software must be split into different pieces.

Remote Facade

Remote facade allows fine-grained object design within a process via coarse-grained objects at the distribution boundaries.

In the coarse-grain, remote facade objects do nothing other than delegate for the fine-grained objects.

The remote facade makes remote access explicit.

The data transfer object works with the remote facade object.

The remote facade contains no domain logic, but merely translates between coarse-grained methods and the underlying fine-grained methods.

Data Transfer Object

The data transfer object can hold all of the data for a given remote call. It needs to be serialized to go across the network. Usually an assembler is used on the server side to transfer data between the DTO and any domain objects.