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...) 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. So, the ServiceReference in that case is no longer a "reference to a Service", but "reference to a Service Descriptor" which is resolved by the Service Importer. Cheers Niclas On Sun, Oct 31, 2010 at 5:55 PM, Rickard Öberg <[email protected]> wrote: > Hi, > > I'd like to discuss the proposed change of "active service" to "available > service". The basic reason is that as a client I don't really care if the > service is active or not at a particular time. I do care whether it's > available or not though, and so it would be good to be able to ask the API > about whether a particular service is available. > > In the API, isActive() in ServiceReference would be changed to isAvailable() > so that this could be queried for. > > The default would be that all native Qi4j services are available. For > imported services the current isActive method would be renamed to > isAvailable, and it can implement it any way it wants to. > > For services that want to support it, what I usually do is to have a > property "enabled" in the ConfigurationComposite of the service that I want > to enable/disable. Usually these services communicate with an external > service, and so if I know that it's not available (e.g. a mail server, web > service, or database), I will set it to "disabled" in the configuration. The > configuration of the connection might be there (e.g. database URL, > username/password, etc.), it's just that at the moment I don't want the > application to even try making a connection. > > With the introduction of a circuit breaker, that might be an additional way > to mark the service as unavailable. I.e. the service itself is available, > but it detected that the external service is currently not available, and so > want to make this clear to the rest of the application. > > This is the basic need that I have. The easiest way to support this would be > to have an additional Available interface (with an isAvailable method) that > a service can implement, and which would typically either delegate to the > "enabled" configuration or the circuit breaker (or both, in that order). > Then it would be very easily for my application to degrade gracefully, and > would also make it easy to make JMX tools to expose this using MBeans. > > WDYT? Does that sound like an ok way to do it? > > /Rickard > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev > -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
