You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@hivemind.apache.org by Chris Conrad <cc...@vasoftware.com> on 2005/05/03 07:45:10 UTC
Designing with Hivemind best practices
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.
--Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
RE: Designing with Hivemind best practices
Posted by James Carman <ja...@carmanconsulting.com>.
I'm curious how you would propose "persisting" something if you don't use a
database or a file.
-----Original Message-----
From: Renat Zubairov [mailto:renat.zubairov@gmail.com]
Sent: Tuesday, May 03, 2005 11:36 AM
To: hivemind-user@jakarta.apache.org
Subject: Re: Designing with Hivemind best practices
I found installer proposal very interesting, I think my application will
need this feature in the future. But the question is how HiveMind can
contribute to the UI interface of the web-site? Should it be only web
specific request based or GUI specific or both.
I see two possible scenarious - one is that installer service worked allone
with installer application and provide the rest of the services with the
configuration information. After installer service/app done its job it is
not called.
Second approach is to draw an interface border between installer service and
possible installer UI interfaces users can created, the only thing is
important then is common persistent storage (as was mentioned in another
post on this topic made by James Carman). But it shouldn't be a database or
file, the storage information module should be modularized inside one module
(standart configuration service? symbol source?). Is any standart persistent
storages are planned for HiveMind like in Eclipse for example?
On 03/05/05, Chris Conrad <cc...@vasoftware.com> wrote:
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.
--Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
<ma...@jakarta.apache.org>
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
--
Best regards,
Renat Zubairov
Re: Designing with Hivemind best practices
Posted by Renat Zubairov <re...@gmail.com>.
I found installer proposal very interesting, I think my application will
need this feature in the future. But the question is how HiveMind can
contribute to the UI interface of the web-site? Should it be only web
specific request based or GUI specific or both.
I see two possible scenarious - one is that installer service worked allone
with installer application and provide the rest of the services with the
configuration information. After installer service/app done its job it is
not called.
Second approach is to draw an interface border between installer service and
possible installer UI interfaces users can created, the only thing is
important then is common persistent storage (as was mentioned in another
post on this topic made by James Carman). But it shouldn't be a database or
file, the storage information module should be modularized inside one module
(standart configuration service? symbol source?). Is any standart persistent
storages are planned for HiveMind like in Eclipse for example?
On 03/05/05, Chris Conrad <cc...@vasoftware.com> wrote:
>
> 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.
>
> --Chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
>
>
--
Best regards,
Renat Zubairov
RE: Designing with Hivemind best practices
Posted by James Carman <ja...@carmanconsulting.com>.
Chris,
That does make sense! I like the idea of putting the version in there so
that you know when you have to upgrade (new version of the software, but db
says only the old version is "installed"). I don't usually create a GUI
installer for my webapps, but then I have never had to package my apps as a
"shrink-wrap" solution for end users. Typically, I make an ant build script
where everything (db, email servers, etc.) is driven off of one
build.properties file. I use Velocity to generate files that are dependent
upon values in the build.properties file. Anyway, I like your ideas!
James
-----Original Message-----
From: Chris Conrad [mailto:cconrad@vasoftware.com]
Sent: Tuesday, May 03, 2005 9:26 PM
To: hivemind-user@jakarta.apache.org
Subject: Re: Designing with Hivemind best practices
Hi James,
Thank you for the insight on the article. I can definitely see the
advantage of having a UserFactory now.
Regarding the installer idea, it does need a way to check to see if it's
installed or not. The plan that I am using is (in my opinion) pretty
simple. I'm going to have a RegistryService which will work similarly to
the Java 1.4 Preferences API, but will back end on my database. The
InstallerService will use the RegistryService to look up the key
"/system/version". Since directly after installation that key won't exist,
you'll get redirected to the setup wizard. Once the setup wizard is
finished, "/system/version" will get set to the current version (which will
be retrieved through the application default property "system.version").
Using version numbers like that would allow a method for doing upgrades in a
similar manner down the road. Of course, it would be just as easy to just
check for a "/system/installationComplete" key if you don't want to handle
doing upgrades within the application itself.
Does that make sense?
--Chris
On May 3, 2005, at 5:10 AM, James Carman wrote:
Chris,
As for your comments on the article, yes the UserFactory service was a bit
too "thin." But, I wouldn't necessarily suggest removing it. I structured
the code for the article based upon principles from the book Domain Driven
Design: Tackling Complexity in the Heart of Software by Eric Evans. In the
book, Evans prescribes the use of entity "factories" to hide the
complexities of object creation. In my example, though, there wasn't much
complexity to hide. Factories are supposed to be used when creating a
single "aggregate" object involves creating many other objects. The logic
doesn't belong inside the constructor. Nor does it belong inside the client
code which needs the object to be constructed. But, it does belong inside
the "domain." So, factories are introduced. As I said, my example didn't
really require the use of a factory, but the User class would be an
"aggregate" in a real system and creating one would involve creating other
objects (Roles, Addresses, etc.). If you design that way from the
beginning, you don't have to refactor later when you need a factory (finding
everywhere you used the constructor directly). Using the factory, however,
did make my unit testing easier. I merely had to tell my mock factory which
object to return, avoiding the use of "argument matchers" and the like.
As for your other stuff, it sounds rather cool. The trick would be making
your installer service know that the application has already been installed,
across restarts. You could put something into the database, I would
imagine, to make that flag more permanent. I think it's an interesting
idea.
James
-----Original Message-----
From: Chris Conrad [mailto:cconrad@vasoftware.com]
Sent: Tuesday, May 03, 2005 1:45 AM
To: hivemind-user@jakarta.apache.org
Subject: Designing with Hivemind best practices
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.
--Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
Re: Designing with Hivemind best practices
Posted by Chris Conrad <cc...@vasoftware.com>.
Hi James,
Thank you for the insight on the article. I can definitely see the
advantage of having a UserFactory now.
Regarding the installer idea, it does need a way to check to see if
it's installed or not. The plan that I am using is (in my opinion)
pretty simple. I'm going to have a RegistryService which will work
similarly to the Java 1.4 Preferences API, but will back end on my
database. The InstallerService will use the RegistryService to look
up the key "/system/version". Since directly after installation that
key won't exist, you'll get redirected to the setup wizard. Once the
setup wizard is finished, "/system/version" will get set to the
current version (which will be retrieved through the application
default property "system.version"). Using version numbers like that
would allow a method for doing upgrades in a similar manner down the
road. Of course, it would be just as easy to just check for a "/
system/installationComplete" key if you don't want to handle doing
upgrades within the application itself.
Does that make sense?
--Chris
On May 3, 2005, at 5:10 AM, James Carman wrote:
> Chris,
>
> As for your comments on the article, yes the UserFactory service
> was a bit too "thin." But, I wouldn't necessarily suggest removing
> it. I structured the code for the article based upon principles
> from the book Domain Driven Design: Tackling Complexity in the
> Heart of Software by Eric Evans. In the book, Evans prescribes the
> use of entity "factories" to hide the complexities of object
> creation. In my example, though, there wasn't much complexity to
> hide. Factories are supposed to be used when creating a single
> "aggregate" object involves creating many other objects. The logic
> doesn't belong inside the constructor. Nor does it belong inside
> the client code which needs the object to be constructed. But, it
> does belong inside the "domain." So, factories are introduced. As
> I said, my example didn't really require the use of a factory, but
> the User class would be an "aggregate" in a real system and
> creating one would involve creating other objects (Roles,
> Addresses, etc.). If you design that way from the beginning, you
> don't have to refactor later when you need a factory (finding
> everywhere you used the constructor directly). Using the factory,
> however, did make my unit testing easier. I merely had to tell my
> mock factory which object to return, avoiding the use of "argument
> matchers" and the like.
>
> As for your other stuff, it sounds rather cool. The trick would be
> making your installer service know that the application has already
> been installed, across restarts. You could put something into the
> database, I would imagine, to make that flag more permanent. I
> think it's an interesting idea.
>
> James
>
>
> -----Original Message-----
> From: Chris Conrad [mailto:cconrad@vasoftware.com]
> Sent: Tuesday, May 03, 2005 1:45 AM
> To: hivemind-user@jakarta.apache.org
> Subject: Designing with Hivemind best practices
>
>
> 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.
>
> --Chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
>
RE: Designing with Hivemind best practices
Posted by James Carman <ja...@carmanconsulting.com>.
Chris,
As for your comments on the article, yes the UserFactory service was a bit
too "thin." But, I wouldn't necessarily suggest removing it. I structured
the code for the article based upon principles from the book Domain Driven
Design: Tackling Complexity in the Heart of Software by Eric Evans. In the
book, Evans prescribes the use of entity "factories" to hide the
complexities of object creation. In my example, though, there wasn't much
complexity to hide. Factories are supposed to be used when creating a
single "aggregate" object involves creating many other objects. The logic
doesn't belong inside the constructor. Nor does it belong inside the client
code which needs the object to be constructed. But, it does belong inside
the "domain." So, factories are introduced. As I said, my example didn't
really require the use of a factory, but the User class would be an
"aggregate" in a real system and creating one would involve creating other
objects (Roles, Addresses, etc.). If you design that way from the
beginning, you don't have to refactor later when you need a factory (finding
everywhere you used the constructor directly). Using the factory, however,
did make my unit testing easier. I merely had to tell my mock factory which
object to return, avoiding the use of "argument matchers" and the like.
As for your other stuff, it sounds rather cool. The trick would be making
your installer service know that the application has already been installed,
across restarts. You could put something into the database, I would
imagine, to make that flag more permanent. I think it's an interesting
idea.
James
-----Original Message-----
From: Chris Conrad [mailto:cconrad@vasoftware.com]
Sent: Tuesday, May 03, 2005 1:45 AM
To: hivemind-user@jakarta.apache.org
Subject: Designing with Hivemind best practices
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.
--Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org