Comments on: Compulsory Attendance http://www.dancres.org/blitzblog/2007/03/22/compulsory-attendance/ Sat, 05 Jul 2008 08:33:50 +0000 http://wordpress.org/?v=2.3.3 By: Dan Creswell http://www.dancres.org/blitzblog/2007/03/22/compulsory-attendance/#comment-461 Dan Creswell Tue, 27 Mar 2007 08:09:47 +0000 http://www.dancres.org/blitzblog/2007/03/22/compulsory-attendance/#comment-461 "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. “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.

]]> By: Kevin Greer http://www.dancres.org/blitzblog/2007/03/22/compulsory-attendance/#comment-459 Kevin Greer Mon, 26 Mar 2007 20:52:34 +0000 http://www.dancres.org/blitzblog/2007/03/22/compulsory-attendance/#comment-459 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. 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.

]]> By: Bharath R http://www.dancres.org/blitzblog/2007/03/22/compulsory-attendance/#comment-448 Bharath R Sat, 24 Mar 2007 07:47:57 +0000 http://www.dancres.org/blitzblog/2007/03/22/compulsory-attendance/#comment-448 ":) 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. “:) 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.

]]> By: Kerr http://www.dancres.org/blitzblog/2007/03/22/compulsory-attendance/#comment-438 Kerr Fri, 23 Mar 2007 14:12:42 +0000 http://www.dancres.org/blitzblog/2007/03/22/compulsory-attendance/#comment-438 Isn't an invitation with compulsory acceptance called a summons? ;) Isn’t an invitation with compulsory acceptance called a summons? ;)

]]> By: Dan Creswell http://www.dancres.org/blitzblog/2007/03/22/compulsory-attendance/#comment-431 Dan Creswell Thu, 22 Mar 2007 09:07:15 +0000 http://www.dancres.org/blitzblog/2007/03/22/compulsory-attendance/#comment-431 "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. “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.

]]> By: Bharath R http://www.dancres.org/blitzblog/2007/03/22/compulsory-attendance/#comment-419 Bharath R Thu, 22 Mar 2007 04:51:51 +0000 http://www.dancres.org/blitzblog/2007/03/22/compulsory-attendance/#comment-419 "...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? “…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?

]]>