hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Conrad <>
Subject Designing with Hivemind best practices
Date Tue, 03 May 2005 05:45:10 GMT
I'm hoping that maybe we can strike up a discussion on some design  
best practices when working with Hivemind.  Unfortunately, I'm not  
the one to do much talking, but I'd like to pose some questions that  
might get the ball rolling.

After reading through The Server Side article and the documentation  
it's my understanding that Hivemind services should small and fine  
grained.  Assuming that I've got that aspect correct, my question  
would be, what is too small?  For example, in the article there is a  
RegistrationService, UserFactory and UserRepository.  If I was to  
start a design from scratch the most logical design for me would be  
to combine the RegistrationService and UserFactory into a single  
UserService and then keep the UserRepository as is.  How do you guys  
decide when a service is fine grained enough, or in the alternative,  
what is too fine grained?

My second thought topic involves application installation.  I'm going  
to use a standard J2EE web application for examples sake.  From my  
experience, you'd first set up your container as necessary (database  
connections, javamail sessions, etc.) and then deploy your war or  
ear.  At that point, however, most applications still have a good  
amount of application specific that still needs to be done.  For  
example, setting up default preferences, creating the first admin  
user, etc.  In the past I've simply had all of that in the database  
sql initialization scripts.  It seems to me, however, that Hivemind  
presents some interesting opportunities to make this more user  
friendly.  For example, an InstallerService could have a contribution  
point which takes Installer services.  These can provide (if we were  
using Tapestry) a Tapestry component and label.  The InstallerService  
can use a Wizard component which pages through the different  
Installer component contributions.  The individual Installer  
components could use ApplicationDefaults for the default values.   
Then the Tapestry front end can check with the InstallerService to  
see if installation is complete.  If it isn't, it can redirect to the  
wizard which allows the user to do the initial configuration.

Hopefully this isn't too off topic for the list, but I'm really  
interested in what people think about these things.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message