During the realisation of a service for an architecture SOA, it happens to have to introduce, in some situations, the notions of context or of session. We are going to see which are the impacts of such mechanisms and as it is enough to apply famous method KISS (Keep It Simple, Stupid) to take out there.

• Definitions of terms "context" and "session" 
• Session harms performances

Definitions

What mean terms "context" and "session" ?:

• the context of a service is the functional environment (for example a case of use) or technology (for example an application web J2EE) in which this one is invoked.
• session allows to keep information through several conjurations of the same service up to the liberalisation of this session.

Context and session harm understanding and maintenabilit

It happens very often to meet services which perform different treatments according to cases of use, channel (web, intranet, batch, etc.) or other contexts jobs. These conditions are often based on what they call magical numbers (or of character strings) which must have passed in parametre by calling it. This can completely harm the reading of code and its service.

Indeed, one of the criteria of the analysers of code which determines the quality of a source code is cyclomatique complexity (number of independent ways of a programme). This criterion augments with the number of conditions existing in code. The more the treatment is linear, the more it is easy to read, to d bugger, and to support (by somebody who did not work over).

In the same mind, to use in the treatment of a service result, data or the state of a treatment performed before and stocked in session contributes to make code dark. This sometimes implicates to read two services at the same time to succeed in understanding in which case they pass by this or that piece of code. If a service needs particular data to perform its treatment, he must simply have passed in parametre explicitly.

What to make when desire takes us to change the behaviour of service according to context?

Especially do not panic!
The simplest solution (who is often the best) consists simply in creating two services since there are two different needs. If both services have a part of their treatment together, we are capable with most languages to apply precepts objects to avoid copying. The important is that the external interfaces of these two services am distinct and apparently researches.

Context and session harm reuse

It also happens that context of calling him is implicitly used to accomplish a specific treatment:  This service is called (at the moment!) exclusively by our IHM of management of the clients then  . This type of reasoning is going to prevent the reuse of this service in the state. It will be necessary to go past again by a stage of development to make him adopt good behaviour. It is therefore very important to develop services which answer job a need and not at the need of an application. The stage of definition of service is here primordial.

Session also harms reuse. To use data of session implicates that a call to another service was before made. Let us take as a model:

• Let us imagine that a B service uses data of session. He assumes therefore that a call towards service A was already made to put data in session. This is probably suitable for current services.
• Let us imagine now that a new C service needs to call, also, B service, but that the treatment or data returned by service A do not interest it.

In this situation, C service must nonetheless make a call to service A before the call to service B. B service is not therefore entirely r utilisable. Besides, to force this call can have an impact in term of performances and of time of development. This type of situation drives very often to the copying of service B to meet the needs of new calling.

Point out: Introduced case ci over (A service, B and C) am simple, imagine this combination for several dozens services, you will get a true spaghetti and a rate of extremely weak reuse of services.

To avoid this type of case, it is necessary to favour the passage of information by parametre. Services are so less restrictive and easier to reuse, what is one of the objectives of SOA. It is therefore necessary to be very vigilant on quality and r utilisabilit of displayed services.

Session harms performances

Naturally, to support a session requests resources machines. As long as session is not ended, this one must be safeguarded, what can implicate an occupation important memory. It also happens that these data are safeguarded not in memory but on a physical support (what also has a cost in performance). In an environment clusteris with replication of session, servers are permanently exchanged of information to synchronise sessions. In all these situations, management and maintenance of session draw away additional, expensive treatments in performance.

Where to manage context or notion of session?

Who better than calling him knows in which context he is? The conscript should be never influenced by context or data of session.

The notion of session should be implemented only in the zones which are already specific for a particular need. The classical place where appara ssent the notions of context and of session is IHM. Another possibility exists in an architecture SOA: an orchestrator of process (BPM) can be led to support a context or a session between several service calls when he includes into his treatments of human activities.

To introduce contextual services (or Stateful) into an architecture SOA should not be made in the light and can seriously have an impact on r utilisabilit , on service and on performances of services.

In summary, it is therefore needed:

• define simple services which answer the single need,
• use the explicit passage of information by parametres

Although the installation of SOA gives us agility, it is necessary to keep at the head that a good definition of services is important. By defining r utilisables services, we avoid spending our time to be made, to undo and to do again the same services. It is so possible to concentrate on the services which answer jobs the new needs and bring a real added value.