Ejem... Have I said something unapropriate?
I'm not very good with english so here are my apologies if that's the case....
sorry.
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.
>
> 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 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.
--
Pablo I. Lalloni <[EMAIL PROTECTED]>
Tel�fono +54 (11) 4347-3177
Proyecto Pampa
Direcci�n Inform�tica Tributaria
AFIP
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Nothing I do is my fault.
-- Calvin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
