Blog Xebia France

SOA: Of the component in service: Without state (Stateless)

As its name suggests it, the key element of SOA (Oriented Architecture service) is Service. It is however difficult to make consensus around service notion and it is often difficult to answer this simple question  What a service?  . This subject comes out invariably on, in the choice: A white; a convoluted and uncertain answer; an ignited debate (or a sterile debate).

It would be possible to offer following definition:  A Service is a distributed software component, displaying functionality to strong added value of a domain job  . Unfortunately, such short definitions (although precise) are necessarily incomplete and bring an anthology of questions.

To answer question more precisely, we offer you to review eight aspects which characterise a service:

• Standardised contract: All the services of the same Technical System are displayed through contracts respecting the same rules of standardization.
• Coupling gives way: The contract of a service must impose a cowardly coupling of his clients.
• Abstraction: The contract of a service must contain only information essential for its conjuration. Only this information must be published.
• R utilisabilit : A service expresses a logic agnostic and can so be positioned as a r utilisable resource.
• Autonomy: A service must exercise a strong control of its subjacent environment of execution. The more this control is strong, the more the execution of a service is pr dictible.
• Stateless (without state): A service must minimise the consumption of resources by delegating the management of state information when it is necessary.
• D couvrabilit : A service is supplemented by group of m tas given by communication through whom he can be discovered and interpreted in a real way.
• Composabilit : A service must be conceived in order to participate in service compositions.

These 8 aspects come from the book    of Thomas Erl, also author of the site SOA Principles.

In this ticket, we will stay over the notion of "Statelessness" .

As we explained it in the previous ticket of this series: To put grandiloquence on the R utilisabilit of services begins with the service supply offering a r utilisable logic, but also implicates that the realisation of this logic is really r utilisable an unfolded time.
In an optics of massive solicitation, it is important to conceive the realisation of services by paying particularly attention to the competition of access. The rival accesses to a service have to change under no circumstances his behaviour, his reliability or his performances. In other words, a service must respect its contract (and its SLAS), whatever is the volume of solicitations to which he is subjected: A service must be a pr dictible.
To guarantee this pr dictibilit as part of rival accesses, two principles must be applied during the development of services:

• A service must be autonomous.
• A service must be without state.

These two aspects are strongly linked: The principle of autonomy of services implicates that the behaviour of a service does not depend on the context in which it is invoked (functional context or technical context). From this perspective, to include the management of states within our services is a not sense.

In a more general way, the management of states (of information of context) within a service poses problems:

• Of understanding and of maintenabilit :
  The management of states is appreciably going to augment complexity cyclomatique of the realisation and therefore makes difficult its reading, its material, its testabilit (the more this cyclomatique complexity is high, the more it is difficult to get a cover of allowable code), As part of a service composition, the complexity of compound being directly linked to that of its components, the complexity of the services of higher level can therefore become fast unmanageable.
• Of reuse:
  The management of states within service blurs the legibility of its contract since the adaptation of its behaviour according to its state does not show through in its contract. And legibility and transparency of service contracts key factors of the reuse of services are.
  On the other hand, the use of states within a service often presupposes the use of this service within a continuity of conjurations defined beforehand. It will be therefore difficult to reuse service within another orchestration or composition.
• Of performances: because the management of the state is consumer of resources systems, notably in term of stocking of these states (in memory or on disc).

Conception and service realisation Stateless will be therefore preferred. The responsibility of the management of states will then be delegated to the users (consumers) of services: compositions, orchestrations, process, This transfer of responsibility (delegate the management of states to the client) joined the principles of an approach REST of services.