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