Stateless Services?

When I had my first foray into Service Based Architecture (SOA) in 2008, I had to grapple with the idea that webservices should be stateless. They were meant to just accept your input, process them and give you a result. They shouldn't put anything in place to be able to tell who you are if ever you invoke any other service. They should have transient memory.

I took these things in literally – in every way.

This meant that some of the other little activities, which had to do with basically having little knowledge of the client, were moved away from the service layer. Little activities like authorizations which follow basic authentication. The question: “should I be able to perform this task” should be answered on a middle layer, before the service is called.

Even where I have access to the session state, I resist the urge to use it while implementing my SOA. Preferring instead to put documents out on how services should be used, which service should be invoked, when and how? In what order should they be stringed to accomplish required tasks? You get the drift?

But then, things could go wrong – errors could occur, documents could be misinterpreted… or leaked, people could become adventurous… or malicious. You know? They haven’t happened yet, but they could.

So I’m revising and adding basic authorization (err… session management?) to the Tiketmobile services which succeed basic authentication. Data is king and services are the doorway to the king, so they shouldn't be lax. The king could get compromised.

-------------------

Tiketmobile (www.tiketmobile.com) lets users find, buy and use bus tickets easily and conveniently from their mobile device. Check it out ;)