Time for the sixth principle SOA: Service Statelessness.
SOA services should not save any information about session data, previous events, or previously reported service results. That is, the services must not have status.
Services must only provide the behavior that corresponds to the input received and the business rules involved.
In my opinion, this SOA principle again has a very close relationship with other SOA principles. For example, autonomy, reusability and loose coupling.
It is not possible to maintain an adequate level of autonomy if the execution of the service requires state information to give a result. For the same reason, the rate of reuse is also seriously diminished, since the service requires a certain context of states that it has planned in its design. And as we speak of dependence we are talking about some level of coupling, clearly inadvisable.
Therefore, just because of the existence of these other SOA principles, this principle is already justified.
But not only for that.
The need for the service not to keep state is more evident than ever in a business events oriented approach, that attends to business processes and that pursues the asynchronous pattern of events suppliers and consumers. Why collecting any information about previous events or sessions, when it is the business itself that leads the information flow through the catalog of services deployed in the ESB?.
In my opinion, this principle does not make much sense in an EDA approach. It would in a request – response pattern, with synchronous messaging. In this context one system expects the response of another, and therefore the transactional coupling is present. User sessions extend beyond the boundary of their own application, and devoting more or less resources to maintaining the state or certain information of each call can be decisive for service performance, and by extension (and coupling), of the transaction itself.
But in an events driven architecture this need should not arise.
The systems identified in BPMN modeling as business event providers are limited to triggering such events to the ESB, and they end their transaction.
The systems identified as interested in knowing that event, or certain events derived from it, are simply subscribed in the ESB to certain services, that are executed as a result of the orchestration of the event received. These consumers are limited to receiving the information to which they are subscribed, and nothing more.
They do not need (or should) know who fired what event, neither when, nor where.
Another interesting aspect that justifies the importance of this principle, refers to another of the SOA principles that we have not yet discussed: service composition. If we want our services to be able to combine and compose other services of a higher hierarchical order, it is essential that each service keeps no status information.
It is a question of autonomy and decoupling.
It’s a question of reusability.
It is a question of common sense.