Re: JMX Support

[Eric Yung]

Pablo Lalloni wrote: Ejem... Have I said something unapropriate? I'm not very good with english so here are my apologies if that's the case.... sorry. I am thinking about it this few days. El Jue 09 Dic 2004 11:50, Pablo Lalloni escribió: Shouldn't the ServiceModel itself be exposed/used for managing the corresponding pool? I think MBean interfaces should be keep clean an mapping 1:1 on the exposed service-point. If the core service implementation of a pooled service point defines its MBean interface, each instance should have its MBean registered in JMX. But the service point itself should be registered as one MBean as other kinds of service point. Like Achim's current implementation, the JMX addition to Hivemind should include the following MBeans. 1) MBean for configuration points - the current implementation looks ok. 2) MBean for service points - one MBean per service point should be used. The basic MBean interface of a service point should be the same as its service model. Primitive / Singleton service model provides little information (e.g. service interface classname, whether the service has been instantiated in the singleton service model, the MBean of the core service instance if found, etc.), while Pooled service model provides additional information for the pool's statistics (number of active / created instances, etc.) If a user would like to provide additional managed attributes / operations, he must specify the managed interface in the contribution. If the given interface is the same or a sub-class of the service interface, we can use the service proxy / instance as the MBean. Otherwise, we should define a way how to wire the operation from the managed interface to the service interface. 3) MBean for the core service instance - we need Hivemind's internal support to register the MBean of a core service instance after its instantiation (may be as an Observer / EventListener). 4) MBean for the interceptor - we should generalize the idea of PerformanceMonitor to allow the interceptor factory to access the JMX server or add a new JMX enable interceptor factory. Our previous thinking about this was like this: JMX publisher service should expose a service-point (as-is) as an MBean, keeping its interface as possible and the MBean should just delegate to the proxied service as any other client code. We didn't want to mix business interface with management interface of services and for this we planned to make a separate service-point for each. We have done previously for other uses a delegator service factory which receives on its parameters schema a mapping of interface methods to other services methods... this'll be clear with an example: <service-point id="Delegator1" interface="gov.afip.pampa.services.delegator.Delegator1"> <invoke-factory service-id="pampa.delegator.DelegatorFactory"> <construct base-class="gov.afip.pampa.services.AbstractBusinessService"> <delegate service-id="Delegate1"> <implement method="method" delegate-method="method"/> <implement method="methodString"/> </delegate> <delegate service-id="Delegate2"> <implement method="get*"/> </delegate> </construct> </invoke-factory> <interceptor service-id="hivemind.LoggingInterceptor"/> </service-point> We implemented this for security, constructing a MZ with delegators. But now we were looking at using the same (or a similar) approach for the management interface of manageable services. If there's interest in this code I can post it somewhere. Now with this separation of "business"/management interfaces in two different service/points, the bussiness service can be registered as a "listener" of the management service so the last will be able to collect references to every instance, also this management service just becomes a multiple-dispatch proxy a-la pico. (Yes, I see the current problem of never releasing references to threaded or pooled service instances that has been discarded by HiveMind, but this coould be worked out). I agree with you that the separation of "business / management" interface is a good point, but the implementation must be simple and can handle all service models. I think we should implement all this stuff as different constructing blocks / tools: delegator factory, dispatcher proxy factory, whatever... and a jmx publisher that only puts a service-point as MBean. Of course this JMX publisher could receive (as the delegator factory above) which methods to put in the MBean. This way we can keep everything simpler and we give the possibility to mix and match as needed.