commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Essl <>
Subject Re: [HiveMind] TSS
Date Thu, 18 Sep 2003 14:08:57 GMT
  > HiveMind's take on the DAO factory:  Define a DAO interface and supply
  several implementations (for
  > different databases or environments) in a configuration point. Have a
  service factory create a
  > service implementation that delegates to a particular implementation, 
  > client code --> wrapper service --> actual service
  > The wrapper service is created at runtime.  Client code only sees the
  wrapper service, never has to
  > even know that a dynamic selection takes place. Wrapper service is
  constructed at runtime using a
  > service impl factory ... look at how EJBFactory is implemented to
  understand this.

I think that's realy needed. However I have a (stupid) question. If you 
have a DAO interface and you have implementations of this interface why do 
you need an extra (dynamicly created wrapper-service)? Why can't you just 
use (or return in a ServiceFactory) the actual service which implements the 
interface any way?

  > Service that creates C#-style delegates for use in Swing apps.  You 
  in: object, name of public
  > method (of object), listener interface type ... it spits out delegate
  object that implements the
  > interface and invokes the public method (possibly, passing the event 
  Optional: if listener
  > interface defines multiple methods, you decide which to connect.

Do you mean a Service which returns something like java.beans.EventHandler?

What's about a central Event Service. I mean a Service where (all) Services 
can register themself with the event-type and the source service(id) they 
are interested in and the firing Service just imforms the central event 
Service when an event should be fired. The interface would look like this:

public interface CentralEventService {
	public void register(Object listener, Class listenerInterface,String 
      public void unregister(Object listener,Class listenerInterface,String 
      public void fireEvent(String source_serviceId,Class listener, 
EventAction action);

public interface EventAction{
	public void fire(Object listener);

The CentralEventService keeps all the listeners and when asked to fire 
provides the EventAction whith the listeners to fire the Event. This would 
certainly be a bit slower, but it would free the service of managing their 
own listeners and thus provide some further decoupling. If ie a Service is 
never actually used it is not just activated to register a listener. If a 
threaded service fires Events and a Singleton-Service has to listen 
currently it has to make sure to register with each instance. In case of a 
central EventService this would not be needed. You could also add some 
additions to such a Service. Ie you could make Event-groups or you are 
interested only in events on the current thread etc.


View raw message