Date: 2004-04-17T21:22:32 Editor: 168.226.241.44 <> Wiki: Jakarta HiveMind Wiki Page: ModuleResourcesProposal URL: http://wiki.apache.org/jakarta-hivemind/ModuleResourcesProposal
no comment Change Log: ------------------------------------------------------------------------------ @@ -1,10 +1,32 @@ = Problem Statement = -I see a strong advantage for including another core module artifact at the same level as services. I know this may be considered as a fairly big adition but i dont' believe it is going away from the idea of keeping the micro-kernel minimal but rather extends the current framework so that it understands and works with resources as well. It is debatable if resources are as important as services or should be considered at the same level. I believe they are and that they provide something powerful that cannot be achieved through services and configurations. +(Apr 18 2004, not quite release 1.0-alpha-4) -The idea of this proposal is to further explore this with some concrete ideas and examples. +!HiveMind deals with two basic concepts; ''services'' and ''configurations''. ( There is no need to describe the !HiveMind concept of ''services'' or'' configurations'' again as that has already been done on the [http://jakarta.apache.org/hivemind/ HiveMind home page]. ). -= Definitions = +Applications use '''services''' throughout and !HiveMind provides a way to define, configure and manage these services using inversion of control meaning that the all the complex code is written just once in the framework (!HiveMind). This is great and I love the way !HiveMind does this but I believe that '''services''' are not the only thing applications need and that benefit from a micro-kernel/framework to define, configure and manage them. Applications also require '''resources'''. + +A '''resource''' provides an application with the type of data that is not known or does not need to be known until runtime. This data could have many possible values, varies based on how and where the application is deployed and often needs to change without having to recompile and redeploy the application. + +There are many examples of '''resources''': + * Localized key/value properties used for error messages. + * Localized key/value properties used for enumerations in user interface (e.g countries/marital status etc.). + * Key/value properties used for smtp server address port or other similar configurations. + * Datasource to be used to connect to database. + * XML document used to configure a particular part of the application. + * Resource obtained from a lookup on a JNDI tree. + * and many more ... + +The advantages of externalizing these resources via a framework or micro-kernel such as !HiveMind are: + * Contract with framework defines only the name of the resource and the Java type of the resource. + * We can easily change implementation of !ResourceFactory used to create the '''resource''' so as to use another source or backing store. + * Easier to change configuration and location of source/persistence of '''resource'''. + * We can monitor and manage all application '''resources'''.in one place. + * We can provide value added features such interceptors. + +The idea of this proposal is to further explore the above with some concrete ideas and examples. + +== Definitions == Both services and resources are looked up via the registry using their unique id ''moduleid.serviceid'' or ''moduleid.resourceid'' respectivly. @@ -30,4 +52,6 @@ = Proposals = -Coming soon .... +On it's way .... + += Commentary = --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
