Date: 2004-04-18T20:40:14 Editor: 168.226.241.66 <> Wiki: Jakarta HiveMind Wiki Page: ModuleResourcesProposal URL: http://wiki.apache.org/jakarta-hivemind/ModuleResourcesProposal
no comment Change Log: ------------------------------------------------------------------------------ @@ -37,21 +37,143 @@ Services are already a !HiveMind concept. - '''Resource:''' A POJO that does not perform work put rather provides services and framework users with some resource/data. A resource does have state and it is its state that is either the resource data itself (e.g Properties) or is used to gain access to the resource data (e.g. Datasource). Resource data is anything used in implementation, but external to it (Values from Properties/!ResourceBundles, data from a DB, data or XML from a file/URL, link to a JNDI/LDAP tree etc.). A resource is locale sensitive. The instantiation of a resource changes depending on the type of resource and the resources backing store. A resource could in theory be writable. A resource has a state that tells us if it is in sync with its backing store if uses one as is the case with Properties/Messages etc. Resources are not a !HiveMind concept yet. I believe they could/should be and would be used widely. -My concept of a resource as i have attempted to describe above is similar in many ways to the way in which resources can be defined and used in Tomcat. Tomcat is a web container and provides resources defined/configured in the server.xml via JNDI. Hivemind is a micro-kernel and would provide resources defined/configured in hivemodule.xml's via the Registry. +My concept of a resource as i have attempted to describe above is similar in many ways to the way in which resources can be defined and used in Tomcat. Tomcat is a web container and provides resources defined/configured in the server.xml via JNDI. Hivemind is a micro-kernel and would provide resources defined/configured in hivemodule.xml's via the Registry. Take a look at [http://jakarta.apache.org/tomcat/tomcat-5.0-doc/jndi-resources-howto.html]. Don't let the mention of JNDI/J2EE or web applications make you think its something specific to that type of application. '''Resources''' are widely in nearly all applications to the same extent as '''services'''. -Take a look at [http://jakarta.apache.org/tomcat/tomcat-5.0-doc/jndi-resources-howto.html] taking into account how as sorts of resources are used widely in application without letting the mention of JNDI/J2EE or web applications make you think its something specific to that enviroment. += Proposals = +== Make 'resources' a HiveMind concept at the same level as, and complimentary to, services == -= Proposals = +This is the prefered solution to integrate the described functionality into !HiveMind. It may seem slightly drastic but i believe it is definitly worth looking into. + +An '''application''' has ''modules'' + +A '''module''' has ''services'', ''configurations'' and ''resources''. -On it's way .... +A '''service''' has dependent ''services'', ''configurations'' and ''resources''. + +A '''configuration''' has ''contributions'' + +A '''resource''' has attributes/contributions that are used to instantiate the ''resource'' using a ''!ResourceFactory''. A ''resource'' may also depend on other ''resources'' with optional resource references as a special type of attribute. (e.g. a resource that obtains properties from a database may depend on a !DataSource resource) + + +Use: +{{{ +// Mailer service obtained has been injected with its dependent services and resources by HiveMind. In this case the +// datasource from which the mailer service obtains the list of email addresses. +Mailer myMailer = (Mailer) registry.getService("com.myco.mypackage.Mailer", Mailer.class); + +boolean mailerResult=myMailer.mail(); + +//Properties 'userMessages' obtained is created by HiveMind. The factory used to create this resource along with the +//source location of the data i.e file, database or web-services. This resource can also be managed and monitored by +//Hivemind in the same way services and have interceptors. +Properties userMessages=(Properties) registry.getResource("com.myco.mypackage.userMessages", Properties.class); + +if (result){ + log.info(userMessages.get("mailerSuccess"); +} +}}} + +Module definition (hivemodule.xml): +{{{ +<?xml version="1.0"?> +<module id="com.myco.mypackage" version="1.0.0"> + + <service-point id="Mailer" interface="com.myco.mypackage.Mailer"/> + + <resource id="myDatasource" type="java.sql.DataSource" > + <attribute name="username">sql</attribute> + <attribute name="password">sql</attribute> + </resource> + + <!-- This resource needs a factory because it is not JavaBean complient --> + <resource id="userMessages" type="java.util.Properties" factory="com.myco.mypackage.DBPropetiesFactory" > + <attribute name="table">USER_MESSAGES</attribute> + <attribute name="pk">MESSAGE_KEY</attribute> + <resource-ref id="myDatasource"> + </resource> + + <implementation service-id="com.myco.mypackage.Adder"> + <invoke-factory service-id="hivemind.BuilderFactory"> + <construct class="com.myco.mypackage.impl.DefaultMailerImpl"> + <!-- Here we inject the service's resource dependency. A resource is not just a file but any pre-defined + resource in the HiveMind registry from any module. --> + <set-resource property="mailerDS" resource-id="myDatasource"/> + </construct> + </invoke-factory> + </implementation> + +</module> +}}} + +== Provide functionality via a 'service' included in HiveMind framework or library == + +This solution is an alternative which avoids modification of the core concepts of !HiveMind. Initially it seems to have disadvantages but this needs to be looked into further. + +Use: +{{{ + +//First we need to obtain the service that is used to obtain resources +ResourceService rs=(ResourceService) registry.getResource("org.apache.hivemind.ResourceService", ResourceService.class); + +//We then obtain the resource from the resource service. +Properties userMessages=(Properties) rs.getResource("com.myco.mypackage.userMessages", Properties.class); + +}}} + +Obtaining resources this way is not hard its just has an extra step, obtaining the !ResourceService. The thing is how do define our resources in the hivemind.xml module definitions? + +The only way that occurs to me is to along with the definition of the !ResourceService define a configuration point whose contributions are in fact the resource definitions. This is workable and would provide the same result as the first proposal. + +Module definition (hivemodule.xml): +Module definition (hivemodule.xml): +{{{ +<?xml version="1.0"?> +<module id="com.myco.mypackage" version="1.0.0"> + + <service-point id="Mailer" interface="com.myco.mypackage.Mailer"/> + <service-point id="ResourceService" interface="org.apache.hivemind.ResourceService"/> + + <configuration-point id="resources"> + <schema>...</schema> + </configuration-point> + + <contribution configuration-id="resources"> + <resource id="myDatasource" type="java.sql.DataSource" > + <attribute name="username">sql</attribute> + <attribute name="password">sql</attribute> + </resource> + <resource id="userMessages" type="java.util.Properties" factory="com.myco.mypackage.DBPropetiesFactory" > + <attribute name="table">USER_MESSAGES</attribute> + <attribute name="pk">MESSAGE_KEY</attribute> + <resource-ref id="myDatasource"> + </resource> + </contribution configuration-id="resources"> + + <implementation service-id="com.myco.mypackage.Adder"> + <invoke-factory service-id="hivemind.BuilderFactory"> + <construct class="com.myco.mypackage.impl.DefaultMailerImpl"> + <!-- To be able to inject resources here the BuilderFactory would have be dependent on the ResourceService and + would obtain the resource via the ResourceService --> + <set-resource property="mailerDS" resource-id="myDatasource"/> + </construct> + </invoke-factory> + </implementation> + +</module> +}}} + += Discussion = + +The disadvantage of the second proposal is that with this this proposal ''resources'' are not considered as core module artifacts along with ''services'' meaning that the concept of injection of dependent services and/or resources is not so simple and direct and would mean implementation that attempted to use it (such as the BuilderFactory for resource injection) would be dependent on the resource service. Also if ''resources'' are not considered at the same level as ''services'' within !HiveMind it will be far harder to provide a integrated and uniform management interface (via JMX or not) for both '''services''' and '''resources'''; the two key and complimentary module artifacts needed by applications that should be provided by !HiveMind. = Commentary = + +Please add your comments, ideas and suggestions here ... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
