You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2003/09/17 19:28:47 UTC
[hivemind] Design comparison
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.
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).
Differences:
-------------
1) The first parameter of each interface method must be a Context object
giving access to configuration and connections. Is this IoC?
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.
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.
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).
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).
So, similar ideas in places but different in others :-)
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [hivemind] Design comparison
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Howard M. Lewis Ship" <hl...@comcast.net>
>> 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
>> 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.
Yes hivemind does not seem to allow multiple implementations for the same
interface, and choose the one to use each time it is called. This late
binding is a key part of this framework.
---
>> 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).
Yes, services are represented by interfaces, with an implementation that may
be decorated with a fabricated proxy. To achieve this you need a lookup to
get the correct implementation class for the interface. (In hivemind this is
performed by a set method on the implementation, but that won't work for
late binding singletons.
---
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [hivemind] Design comparison
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Howard M. Lewis Ship" <hl...@comcast.net>
>> 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
>> 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.
Yes hivemind does not seem to allow multiple implementations for the same
interface, and choose the one to use each time it is called. This late
binding is a key part of this framework.
---
>> 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).
Yes, services are represented by interfaces, with an implementation that may
be decorated with a fabricated proxy. To achieve this you need a lookup to
get the correct implementation class for the interface. (In hivemind this is
performed by a set method on the implementation, but that won't work for
late binding singletons.
---
Stephen
Re: [hivemind] Design comparison
Posted by Harish Krishnaswamy <hk...@comcast.net>.
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:hkrishnaswamy@comcast.net]
>>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: commons-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
RE: [hivemind] Design comparison
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
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:hkrishnaswamy@comcast.net]
> 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: commons-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> >
> >
>
RE: [hivemind] Design comparison
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
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:hkrishnaswamy@comcast.net]
> 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: commons-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [hivemind] Design comparison
Posted by Harish Krishnaswamy <hk...@comcast.net>.
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
>
>
>
>
RE: [hivemind] Design comparison
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
>
> 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
RE: [hivemind] Design comparison
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
>
> 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