J-Log

Context Architectural Pattern

This is the fifth in a series of related architectural patterns. The others, in order, are :

Intent

Provide a common and efficient mechanism for the storage and retrieval of ad-hoc and arbitrary data that allows loosely-coupled entities to exchange information without the explicit cooperation of any other entities in the process flow.

Problem

There are many places where information has to be exchanged between two or more entities that are separated from each other by at least one intermediary. A problem arises when that intermediary does not provide a mechanism for the information to be transferred. The problem can arise wherever there is a well-defined and constrained boundary between two extensible systems.

One possible solution would be to modify the intermediary to accommodate the exchange of every new data item. This would lead to a combinatorial explosion in the complexity of the intermediary (or its interface) and would also provide a maintenance nightmare.

Another solution is to provide a direct link between the entities that need to exchange data. This would reduce the complexity but still leave each individual entity with the responsibility of implementing each new exchange requirement as it arose. In addition it would violate the isolation that the intermediary is providing and it would quickly become untenable if multiple entities were involved in the data exchange – each one having to communicate with every other one.

Solution

Use a third-party – the context - whose role is to provide a mechanism for storing and retrieving arbitrary data and ensure that all entities that might need access to it, have access to it. In this way there is a single interface to the data that all parties can use to exchange data.

This would typically require that the intermediary understands the context sufficiently to make it available to all the entities that need to access it.

What makes this different from, say, a relational database or shared memory or thread-local storage? Nothing. They all provide one mechanism by which context can be maintained. The key is that all of the entities that need to access the context need to agree on where it is and what the interface to it is.

A context usually exhibits the following characteristics:

Lifetime
Location
Visibility
Structure

Lifetime defines the how long the entire context will last. Possibilities include:

Forever
Until explicitly destroyed
For a specific period of time
Until it isn\&amp;amp;amp;amp;#39;t referenced by anything
For a session
For a flow
For a call sequence

Data items within a context will also have a lifetime that is agreed upon by the entities sharing the data.

Location is usually well-known for any given context. This could be a shared reference that is passed between cooperating entities or simply a hard-coded location.

Visibility defines the scope within which a context can be accessed. For example by:

Account
Thread
Process
Session
Flow

Structure. There is usually no limit to what can be stored in a context either in terms of type or quantity. This obviously requires that entities using a particular data item agree in advance what the format of the data is.

The structure of any given context itself is well defined. That structure forms part of the interface to the context. A context is typically an associative store. i.e. items are stored and retrieved by name.

Applicability

An end-user always has a context. For example:

Identity
- Username
- Certificate

In this case the lifetime of the context is \&amp;amp;amp;amp;#39;forever\&amp;amp;amp;amp;#39;. The lifetime of the data item that describes the user is defined by the existence of the user in the system.

When a user starts a session extra data can be added to the data item for that user