I came across a new concept in my travels this week, an invitation with compulsory acceptance.
Is an invitation that is compulsory to accept an invitation at all? Surely most people would see it as nothing more than a dressed up way of demanding attendance? Surely such “garnish” (Ben Elton fan’s will know exactly what I’m talking about) just engenders bad feeling in many recipients?
Meanwhile in the world of systems…….
We often do the equivalent of compulsory invitations in the way we build software - consider for example the whole dependency injection thing.
In many cases we build some object via a constructor that expects to be injected with a whole heap of other things. How do we guarantee all those things will attend and remain present for the lifetime of our object? After all without these things our object cannot perform it’s intended task. About the only way this works is by insisting that all these things exist within the same JVM as the object to be injected - then they all either exist or don’t exist.
Clearly, this doesn’t work so well in distributed systems where achieving the same availability assurance is considerably more difficult. A slightly more subtle issue is that if our systems are written in the above manner, upgrades are also more difficult because we must manage a dependency tree. e.g. We wish to upgrade System A and it has dependants, Systems B and C both of which will need to be taken off-line whilst we upgrade A.
What is required is a more dynamic form of injection, something that can be reinitialised or changed which at least invalidates injection via constructors (well, unless we throw the whole object out and rebuild it from scratch). In fact, we probably require some kind of event-based solution such that systems can get liveness information about the systems they rely upon and take appropriate action (which will likely include dealing with in flight operations).
Technorati Tags: architecture, design, distributed systems, philosophy
Entries (RSS)
March 22nd, 2007 at 6:51 am
“…probably require some kind of event-based solution such that systems can get liveness information about the systems they rely upon”.
Don’t we already have such a facility (albeit indirectly) Dan? Wouldn’t a lease expiry notification serve the purpose?
March 22nd, 2007 at 11:07 am
“Don’t we already have such a facility (albeit indirectly) Dan? Wouldn’t a lease expiry notification serve the purpose?”
Indeed we (Jini/Apache River) do but there’s a deeper design philosophy issue at work…..
A lease is a mechanism that forms part of a solution to the problem. ServiceDiscoveryManager (a Jini API helper class) is also a component mechanism. The reason these mechanisms exist is driven by the distributed systems design philosophy that drives the core behaviours embodied in the Jini APIs.
Many of the technologies and design approaches we use to build distributed systems aren’t born of the same philosophy. Instead they are often subtly oriented towards single machine use so that when we build our network systems on top of them brittleness is inherent.
If one looks a little further one will see similar tensions around methods for handling/performing configuration, deployment and so on.
March 23rd, 2007 at 4:12 pm
Isn’t an invitation with compulsory acceptance called a summons?
March 24th, 2007 at 9:47 am
“:) Indeed we (Jini/Apache River) do but there’s a deeper design philosophy issue at work…..”
My bad. I see you were trying to explain a larger design problem while I was pointing out a particular technological solution.
“…see similar tensions around methods for handling/performing configuration, deployment and so on” - you hit the nail on the head. Configuration, deployment and serviceability of a distributed system probably receive the least amount of thought/attention and end up being the most hairy of problems in production.
March 26th, 2007 at 10:52 pm
Just inject on interfaces and then use proxies. The proxy’s delegate can be updated without having to notify any of its users. The proxy could lazily instantiate services as required or even be a network proxy. This is how many mobile agent systems work. They have essentially been doing “dependency injection” since before the term was coined. This is required because when a mobile agent moves to a new node it needs a method of accessing its required services. Another advantage of proxies is that it prevents the mobile code from casting implementations to suspected implementations and then calling methods not belonging to the interface.
March 27th, 2007 at 10:09 am
“Just inject on interfaces and then use proxies. The proxy’s delegate can be updated without having to notify any of its users.”
The basic principle you outline is sound (and one that Jini provides out of the box). However, there are many cases (especially around failure and concurrent in-flight operations) where one can’t simply update the proxy and not have clients be aware - the clients must co-operate to make it work.
In the case where an agent has been suspended and moved or is started for the first time as you describe, there’s no issue.