On 2010-11-01 08.36, Niclas Hedhman wrote:
Since I worked with JINI many years ago, I like the whole concept of
Availability and what you describe is close to my experience as well.
OSGi is another area, where Availability is a central theme,
originally as an in-JVM concept to allow services to be
unloaded/reloaded in runtime, but with the introduction of Distributed
OSGi, the concept has been extended, and we should learn from this.
In both instances there are additional features (other than a simple
isAvailable()) which is in place;
1. Ability to subscribe to events about Availability. Both Jini and
OSGi use a similar model; added, modified, removed. The subscription
is not to a particular service instance, but a criteria (type,
template, properties, expression...)
That would make sense. You would subcribe for events from a Module
perspective, right? So you would only get events for services that you
can "see"?
2. A hook for the subscription above, so that the service provider
can activate a service on-demand instead of 'always'. With the
ServiceReference.get() and a corresponding ServiceReference.release(),
the client code can cooperate much stronger with external systems.
This sounds similar to the lease thing in Jini. The problem with
acquire/use/release strategies seem to always be that it gets screwed
up. Witness JDBC. Client code pretty much always gets the cleanup wrong.
It's very easy to get UnitOfWork's in Qi4j wrong as well, because it's
so easy to forget the complete() and or handle exceptions properly.
In a sense we already have "on-demand" though, with the Activatable
system, since it's only on usage of a service that it needs to be
activated. So that part I'm not too worried about.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
