ManagedServiceFactory and ServiceFactory are COMPLETELY unrelated ...
They are as far remote as one can gets.
1. Service Factory
A service factory is an OSGi framework entity. Its purpose is to
customize the service object given to a service getter. If you want to
register a service called MyService, you can register a Service
Factory instead of an instance of MyService. The framework will then
consult you when a bundle gets the service (once per bundle) and will
inform you when the getter ungets the service (or is stopped). This
allows you to create a unique service object for each bundle you
server.
2. Managed Service and Managed Service Factory
This is an entity that can be used in configuration management. If you
need configuration data, you register a Managed Service with a
persistent identity (PID), the
Configuration Admin will then call you with your configuration data
for the given PID.
This is guaranteed to happen initially (when CA is available) and will
happen again when the configuration data is changed. However, how do
you handle the situation when you need more than 1 or 0
configurations? For example, OBR needs to have links to many different
federated repositories. Each linked repo needs a URL, a name, responsible
person, etc. In that case you register a Managed Service Factory and
the Configuration Admin service will call you for each available
configuration instance. If an instance is deleted, it will call delete, a new
instance is created, it will call update().
The purpose of the Managed Service (and Factory) is to make life of
apps easy. They register the service and get called with their
configuration. They do not have to distinguish between the initial
situation and updates. Everything is an update.
The design was made for embedded situations. For this reason, we allow
Managed Service objects to be combined with other service interfaces.
This possible for ManagedServiceFactory as well, but not very useful I
think.
Hope this helps ... Kind regards,
Peter Kriens
MT> Niclas Hedhman wrote:
>>
>>
>> On 11/10/06, *Makas Tzavellas* <[EMAIL PROTECTED]
>> <mailto:[EMAIL PROTECTED]>> wrote:
>>
>> For the ManagedServiceFactory's case, how would it be possible for
>> it to
>> serve different instance of a service if it's not registered?
>>
>>
>> The ManagedServiceFactory is registered as the service. For instance;
>>
>> public class Abc implements ManagedServiceFactory { ... }
>>
>> public class Activator
>> {
>> :
>> public void start( BundleContext ctx )
>> throws Exception
>> {
>> Abc factory = new Abc();
>> reg = ctx.registerService( Def.class.getName(), factory, null );
>> :
>> }
>> :
>> }
>>
>> So when the client is requesting the Def service, Abc is asked to
>> create one for the client. If the same client bundle is requesting the
>> same service, the factory is not involved, and stuff handled by the
>> framework.
>>
MT> Uh, are you sure about the code above? ManagedServiceFactory only have
MT> these methods
MT> public String getName();
MT> public void updated(String pid, Dictionary properties)
MT> throws ConfigurationException;
MT> public void deleted(String pid);
MT> Which seems to me that it's only suppose to be registered as
MT> ManagedServiceFactory.class.getName() not Def.class.getName(). I dont
MT> think ManagedServiceFactory is treated the same way as ServiceFactory.
>>
>> A paragraph taken from the spec
>> "The Managed Service Factory should then create any artifacts
>> associated
>> with that factory. Using the PID given in the Configuration
>> object, the
>> bundle
>> may register new services (other than a Managed Service) with the
>> Framework, but this is not required. This may be necessary when
>> the PID is
>> useful in contexts other than the Configuration Admin service."
>>
>>
>> Not sure what this passage is referring to. Possibly there is a
>> context that I need to look at, and no time right now for that.
>>
>> What I'm thinking is that a JdoService instance with the same
>> configuration should not be re-instantiated and only created for new
>> configurations, and the configuration should be changable on
>> runtime by
>> a "management console (using ConfigurationAdmin)" should say the user
>> name/password has changed without the consumer of the service
>> needing to
>> worry about it.
>>
>>
>> ok. sounds like a non-factory case. All client bundles share the same
>> instance, hence no factory.
>>
MT> Client only *shares* the same instance if they have the share same
MT> configuration. Meaning, Client A and B wants to connect to database
MT> MESH, so they share the same instance, Client C wants to connect to
MT> database SMASH, which then will be using another instance of the service.
>>
>> Therefore the consumer of the service only need to track the required
>> service with the right filters (assuming someone else created the
>> configuration). E.g
>> String filter = "(database.type=mesh)"
>> ServiceTracker tracker = new ServiceTracker(
>> JdoService.class.getName(),
>> filter, this );
>>
>>
>> Ok. So, if the service instance is required to be killed and
>> re-instantiated on configuration updates, you need an internal
>> mechanism in the Jdo service subsystem, so that the instance is
>> "killed" on updated() and re-instantiated straight away. However, that
>> sounds like an anti-pattern and the service should be able to throw
>> away any Jdo resources that need to be re-initialized and bring that
>> up again, without killing the OSGi service instance.
>> updated() also has the "side effect" that the serviceModified() method
>> in the tracker is called, in case clients need to know.
MT> The configuration updates are not suppose (or not required) to
MT> kill/re-instantiate the service (unless I misunderstood the spec). Upon
MT> changes in the configuration, the ManagedServiceFactory will be called,
MT> which then ManagedServiceFactory implementation will find the service
MT> instance being configured and set the new properties. E.g the url for
MT> the database connection has changed for database MESH, the
MT> implementation of ManagedServiceFactory receives an update event to
MT> change it, it looks up the service using that configuration and sets the
MT> new url. Subsequent use of the same service will be connecting to the
MT> new url database (and after closing connection to the old database). The
MT> client is not involved and doesnt have to know that the service instance
MT> has changed.
>>
>> So question is, is ManagedServiceFactory suitable for it and is my way
>> of using it correct? I would like to use as much standard OSGi
>> interface
>> as I can without resorting to own factories if that can be avoided.
>>
>>
>> AFAICT, no factory at all is needed for the JDO provider service, but
>> I assume there are session objects that needs to be handed out.
>>
MT> Will continue more later...
>>
>> Niclas
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> general mailing list
>> [email protected]
>> http://lists.ops4j.org/mailman/listinfo/general
>>
MT> _______________________________________________
MT> general mailing list
MT> [email protected]
MT> http://lists.ops4j.org/mailman/listinfo/general
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
