I understand services should have no state and no business logic.

  • How can you implement a service like AuthentificationService considering these rules?
  • All the methods in a service should be static?

Let's look at the various parts of your question.

I understand services should have no state and no business logic.

Your statement (and assumption) is only partly correct.

  • Services should not have state.

This is mostly true, rounded up to almost always true. The problem is that coding state into a service gets to be a real pain. Keeping track of the state; client requests; timeouts; disconnects; slow responses; load balancing; distributed service provisioning; session hijacking; etc... all adds up to a lot of overhead. So it's just easier to not have state in the service. The problems listed mostly go away, and the features are easier to implement.

  • Services should not have business logic.

Not true. In fact, a service is essentially a manifestation of business logic. A service must provide a function. That function represents something of value to the business, and is generally a piece of the organization's business logic.

All the methods in a service should be static?

I think this depends upon what you mean by static. If by static you mean only a single instance of the service, then the answer is "maybe." And I think this aspect would be driven more by your language of choice for the service than anything else.

But if you mean "unchanging" then the answer is yes. A service should provide a deterministic response to a properly formatted response. How it generates that response may change, but the form and nature of the response should be static. A service is an API, and once released to the wild then it should not change. If a change is required then consider applying versions to your services.

How can you implement a service like AuthentificationService considering these rules?

See above for the misunderstandings in your base assumptions.

Many frameworks provide this service out of the box so long as you plug the framework into your authentication provider. The general approach is that credentials are based to the Authenticate service which returns an ephemeral token upon successful authentication. The other client based calls then make that token part of their call to the other services. Those services or an intermediate layer verify that the token is still valid and then allow the service call to proceed.

You could make the semantic argument that the token represents a "state" for the client session. But the token or "state" tracking is handled by the client and there are very simplistic rules on the service side in order to validate and handle that "state." Many / all of the woes associated with stateful services are still avoided.

  • Not sure that it is really clear. But I think what you are saying is that the Authentication Token represents the state and would be stored outside the AuthenticationService, most like in the service's client (consuming class). – Seth M. Jun 12 '13 at 18:42
  • @SethM. - yes, arguing that the token represents state is a bit of a stretch and is certainly playing with semantics. It's not what most people mean by "state." The argument forces awareness of an otherwise implicit aspect of the secured service. For example, it is expected that GetEmployeeSalary() should fail if the request doesn't have a valid authentication token. That expectation presumes a state (valid | invalid authentication) based upon the token. But if that's even more confusing, just ignore the last paragraph of my answer. – GlenH7 Jun 12 '13 at 19:03
  • Yes, you are correct. the tokens really are not the state. it would be the result of the authentication. – Seth M. Jun 13 '13 at 2:33

Your Answer

