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 ;)
-------------------
Tiketmobile (www.tiketmobile.com) lets users find, buy and use bus tickets easily and conveniently from their mobile device. Check it out ;)
1 comment:
Does your ticketing app really need to be that complicated, bro?
Post a Comment