Re: [hivemind] Design comparison

[Harish Krishnaswamy]

Ah, I see. Thanks.

Howard M. Lewis Ship wrote:

I'm not an aspect guru (not yet), but I believe a method introduction (at least in AspectJ) can take
into account who the caller is. 

So, the interceptor could make the method operate different dependeing on whether, for 
example, the
method was invoked be test code, by the container, or by the object itself 
(recursively).
With HiveMind, the interceptor is more simply a wrapper, and makes no decision about the caller.

--
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
 

-----Original Message-----
From: Harish Krishnaswamy [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, September 17, 2003 1:51 PM
To: Jakarta Commons Developers List
Subject: Re: [hivemind] Design comparison

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


     



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]