Rich Turner has posted a clarification to my initial quest to understand the Autonomy tenet of SOA.
I read the post, but i still have some problems understanding it. No biggie, i guess i have a few years to catch it. :-)
Let's go piece by piece,to help me understand it.
" Taking this into consideration, and with a little further discussion, it became a little clearer that that Autonomous systems do not stand alone without interaction with other parties. An Autonomous system is self-governed and whose resources are not directly controlled by an external entity. "
No questions here. This seems like a tipical fiefdom pattern.
" The value of a Service which is entirely stand-alone would somewhat questionable and in the real world, of course, never happens. Our applications are (usually) comprised of complex interrelationships between component parts, but this IS the problem! "
This was my point. :-) If we see it as a fractal, when it comes to being autonomous a service seems to fit this description, only at a larger level but seems exactly the same. Since we are at a larger level, the level of interrelationships are a lot smaller easing it our pains,but still there nonetheless. Part of my reasoning problem, is not only at the conceptual level but also at the operational one. If we depend on another service(s) if one of those services fails, we will also fail (assuming we aren't asynchrounous). How can we be autonomous if we fail when others fail? only because we are now loosely coupled the dependency is still there.
"Most of our applications today are a rat’s nests of inextricable parts which (method call) have hard-interrelationships resulting in fragile systems that do not encourage the efficiencies of re-use that most of us seek. "
Indeed. Life is a bitch.
" If instead, our systems were architected and implemented against different principles, whereby our systems are deliberately designed to be independent and autonomous, we’re far more likely to implement flexible, resilient solutions than before. "
No question here, life would be great. And SOA will certainly help us here a little, but that still doesn't help me understand how services are autonomous. Please continue. :-)
" But what about Service A that requires information inside Service B? Won’t these two Services therefore be inextricably bound? Well, not if they’ve been carefully designed according to our SO tenets! "
Yes. Only because service A depends on B, doesn't B is less of a fiefdom, nor it affects is autonomicity but what about service A is it really autonomous? I begin to think, that is somehow related to being loosely coupled.
" Why are these services Autonomous?
· Either Service’s location can change at (almost) any time due to the fact that they’re dynamically addressable
· The services communicate through dynamically negotiated communications channels that support the necessary formats and capabilities (security, reliability, etc)
· Neither Service requires knowledge of each others’ internal workings in order to exchange data – they only need the published schemas & contracts
· Neither party make demands on each other as to how the work is carried out
"
Ah. Know i think i get it. As long as the contract remains, as long i can find it's endpoint (in case it changes) as long as it is loosely coupled, then it's autonomous. I think i now get it.
I think i now understand it at a conceptual level.....
Rich, not to impose me or anything, can i ask you another question?
If service B starts misbehaving (performing poorly) at a point that service A stability is compromised, is A still autonomous? (assuming i didn't code for failure and for example haven't triggered my code to timeout if A doesn't respond in a timely manner?).
Anyway, thanks for the reply it helped me a lot. I'm not fully convinced but i think i now understand it.