We have an application using a bunch of services. As soon as the application is launched it should call a webservice method, "RegisterMachineSession". In this method we accomplish some basic work that should be done before any other service call. For example, we load in memory a set of parameters associated with the machine session that should remain constant during the application usage.

I am asking myself if it is not a code smell because each service call should be independant. Is it a known antippatern or is it ok to this because we are needing a concept of session?

  • 3
    From a practical standpoint, the kind of isolation you describe doesn't really exist. The vast majority of non-trivial services require some sort of connection authentication, and as soon as you do that, you're creating a session. – Robert Harvey Oct 10 '17 at 21:16
  • You are right but in our application we are using a session "in disguise" : 1) the application should first call the service method "RegisterMachineSession", 2) then we store a point in time in database and load a list of static parameter corresponding to this point in time. We are not using any sort of authentification token or any sort authentication scheme... – Dypso Oct 10 '17 at 21:22
  • Is it your assertion that your technique is a code smell because you are "disguising" it? – Robert Harvey Oct 10 '17 at 21:24
  • Sorry I have edited my answer to give more informations. I have a bad feeling that something is not good with our implementation. So I was making some research about that... But at the end of the day the application is working :-) – Dypso Oct 10 '17 at 21:29
  • Isn't your "session" a way to centralized some common parameters ? Or does they may change depending on the client ? – Walfrat Oct 11 '17 at 14:16
up vote 1 down vote accepted

In general, an imposed workflow would imply that your services are not stateless. Statefulness isn't necessarily an anti-pattern but it is undesirable as it makes scaling your design much more difficult. Statelessness in this context is the lack of server state between calls. If you move session state to a database, for example, it isn't considered stateful from a service perspective. If I make 3 calls, it shouldn't matter if they are satisfied by three different servers. If you can eliminate sessions, that's even better but if not, moving them to a shared datastore eliminates most of the issues.

I'm not sure what to make of "For example, we load in memory a set of parameters associated with the machine session that should remain constant during the application usage." Is this something that the client is providing or is it something server side is determining?

In the former case, can the client provide it on every call? The extra overhead could very-well be worth the elimination of server-side state. What prevents you from doing it when the first 'real' service is called?

Perhaps scaling and fault-tolerance are not of much importance here but making services stateless will greatly simplify the overall design.

  • "For example, we load in memory a set of parameters ..." This operation is made on server side : data associated with client work is constant during what we call a session (could be 1 to day long). In fact when loading those parameters we are also saving the state in database and returning a token to the client so it can refer on consecutive calls to his "session" data. We are fully able to scale on serveral server if necessary. It was the just the imposed workflow that seems weird to me. Anyway thank you for your help. – Dypso Oct 12 '17 at 0:14
  • If it's required to call one service and use the response from that to call another service, that's pretty normal. I would advise against very complex sequences of steps. If you can I would store as much in the token as possible. For example, if they retrieve a price list, you can encode their account, the time and the price list ID in the token and sign it. If I understand, you are doing something along these lines which seems totally fine. The concept behind this completely horrible acronym/initialism might be worth reading up on: HATEOAS – JimmyJames Oct 12 '17 at 13:32
  • I am not certain that this could be called a direct application of HATEOAS... If we were applying strict HATEOAS we would have enforce the workflow by sending back explicitly to the client on each call to a service the list of the various operations it could then access... So in my mind HATEOAS is when you have a dummy client and an explicit workflow given at runtime based on a peculiar state at this time (resource and client state, external condition) – Dypso Oct 13 '17 at 3:17
  • @Dypso I pointed to that simply as food for thought. I didn't mean to imply that this was what you were doing or that you should necessarily do it. I apologize if my mentioning it created confusion. – JimmyJames Oct 13 '17 at 15:09
  • No problem. I was aware about HATEOAS but it is always good to know about new things! – Dypso Oct 13 '17 at 16:24

You'll often see services do or return something necessary for a future call to the same service or to another. For instance, I need to get a list of users by calling UserService and after some filters, I then call a second service OrdersService with a list of users. In this there is absolutely nothing incorrect as each service is given exactly everything required to do its job with no state.

In your example however, it seems to me that the RegisterMachineSession is sort of opening a means to call other services, which is most certainly not stateless. Generally if such a thing were to be done, you simply call the service you require and if necessary, the service itself will open this session to be used later. This means making a service stateful in a sense, however, this is generally acceptable as it is handled internally and to the caller, the state is entirely transparent (caller should not care about whether or not a previous call has opened a session or otherwise).

So in my opinion, yes, it is an anti-pattern.

  • If there's no persisted state in-between your call to get users and placing an order, how can you be sure of the identity of the user placing the order? What prevents a malicious user from placing an order under somebody else's identity? – Ben Cottrell Oct 11 '17 at 8:02
  • 1
    @BenCottrell So create a third service which accepts credentials and returns a token to be passed to the other two services. It would still be weak security without some sort of firewall enforcement. The other two services remain stateless in this way. But I see your point. Not every service can be stateless, but that doesn't mean it should be encouraged. – Neil Oct 11 '17 at 8:06
  • @Neil : you got my point : the call to others service could not be made correctly if the first one to RegisterMachineSession is not done in first place. I was thinking effectively to open a session if necessary and transparently as you said. – Dypso Oct 11 '17 at 18:31

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.