commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harish Krishnaswamy <hkrishnasw...@comcast.net>
Subject Re: [hivemind] Design comparison
Date Wed, 17 Sep 2003 17:51:22 GMT
Just for my knowledge, how are method introductions different from 
interceptors?

-Harish

Howard M. Lewis Ship wrote:

>>I have been monitoring hivemind as it is similar to a 
>>framework I helped design for work (not OSS). What interests 
>>me is the way that different groups in Java-land are moving 
>>towards the small POJO approach, and away from dreaded EJBs. 
>>I just want to sketch out some features of the framework I 
>>use in case it gives you some ideas.
>>    
>>
>
>I read a great article that, boiled down, said that "Enterprise JavaBeans" should be called
>"Transactional JavaBeans" because that's all you really get.
>
>Bloat, complexity and (due to dependencies on the app server runtime environment) limited
>testablility is the problem.  All these POJOs (Picocontainer, swing, HiveMind, Avalon)
are the
>reaction.
>
>Lots of HiveMind percolated and gestated in Tapestry.
>
>
>  
>
>>Similar to hivemind:
>>--------------------
>>Aims to enable a system to be written as a large number of 
>>small services. Each service can call other service in 
>>flexible ways. Each service is defined by an interface. The 
>>interface must have only _one_method. Each implementation 
>>must have no instance variables (singleton).
>>    
>>
>
>HiveMind services may have any number of methods.
>
>They don't have to be singletons, though singletons are generally sufficient; the threaded
service
>model allows one-instance-per-thread (but mandates that you tell HiveMind when the instances
may be
>discarded).  More service models on the way.
>
>
>  
>
>>Differences:
>>-------------
>>1) The first parameter of each interface method must be a 
>>Context object giving access to configuration and 
>>connections. Is this IoC?
>>    
>>
>
>I would say not; that's configuration information that should be provided by the container.
>
>
>  
>
>>2) The selection of which implementation to use is performed 
>>late. The selection is based on
>>- data in the method arguments
>>- the services in the stack calling this one
>>- the configuration
>><lookupGroup interface="blah.TheInterface">
>> <lookup>
>>  <caller caller="blah.SomeCallerImplementation" />
>>  <process process="blah.ImplIfCallerInStack" />
>> <lookup/>
>> <lookup dataSourceType="Database">
>>  <process process="blah.ImplIfParamsWantDB" />
>> <lookup/>
>> <lookup dataSourceType="File">
>>  <process process="blah.ImplIfParamsWantFile" />
>> <lookup/>
>><lookupGroup/>
>>I include this to give some idea of what is going on. The 
>>process elements are the implementations, and which is 
>>returned will depend on the current state of the system and 
>>the method parameters. It acts like a big if statement.
>>    
>>
>
>Those almost look like AOP method introductions; this doesn't have a parallel in HiveMind
per se.
>
>  
>
>>The lookup is hidden from callers by a class that simply has 
>>all the interfaces as methods, performs the lookup and then 
>>calls the implementation.
>>    
>>
>
>I'm not following this; in HiveMind services are represented by interfaces; the implementation
of
>the interface may be a fabricated proxy or interceptor, or a user-supplied core implementation
(or a
>fabricated core implementation).
>
>  
>
>>3) We have the concept of interceptors, again bytecode 
>>generated. We use them to open and close connections. Thus 
>>there is a doPre() method that opens the connection and 
>>attaches it to the Context, and a doFinally(), that is called 
>>as a finally block, that closes the connection. This 
>>obviously simplifies the service itself, and separates system 
>>logic from application logic. It is very powerful, and could 
>>be worth thinking about for hivemind. (our limitation is that 
>>each service can only talk to one datasource).
>>    
>>
>
>HiveMind allows multiple interceptors in a stack. There are examples of them performing
logging
>operations, and more interceptors are on the way.
>
>  
>
>>4) All our configuration is in XML resource bundles. This 
>>allows locale based config for the core server behaviour 
>>which we can control on a per session basis (although we 
>>haven't needed to yet). We chose to separate configuration 
>>from the services themselves, different to hivemind. The 
>>system we use allows single Strings, Lists, Maps and raw XML 
>>to be loaded from the resources by the program. There is no 
>>auto-bean conversion though which is nice in hivemind 
>>(although it only takes one line in our code).
>>    
>>
>
>Having unified module deployment descriptors enahnces the IoC aspects of HiveMind.  The
framework,
>as container, can 
>set properties of core implementations to configurations or other services.  Proxies get
in there to
>keep unecessary work from occuring
>until actually needed, and to defuse cyclic dependencies.
>
>Additionally, having interlationships between modules is very powerful; especially for
pluggability
>reasons.  For example, module A could define a DAO interface and service, and modules
B and C (only
>one available at runtime) would contribute an implementation of the service.
>
>HiveMind also feeds on itself ... services are used to construct other services.  BuilderFactory
is
>the "IoC" engine; it constructs core implementations and can set properties of the impl
to other
>services and configs.  EJBFactory creates a core impl that's a wrapper around looking
up and
>invoking stateless session EJBs.
>
>--
>Howard M. Lewis Ship
>Creator, Tapestry: Java Web Components
>http://jakarta.apache.org/tapestry
>http://jakarta.apache.org/commons/sandbox/hivemind/
>http://javatapestry.blogspot.com
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>  
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message