Date: 2004-04-20T06:03:04 Editor: 63.69.231.245 <> Wiki: Jakarta HiveMind Wiki Page: ModuleResourcesProposal URL: http://wiki.apache.org/jakarta-hivemind/ModuleResourcesProposal
no comment Change Log: ------------------------------------------------------------------------------ @@ -31,22 +31,21 @@ Both services and resources are looked up via the registry using their unique id ''moduleid.serviceid'' or ''moduleid.resourceid'' respectivly. '''Service:''' -A POJO (Plain Old Java Object) used to perform a unit of work. A service has no state apart from injected references to other services or resources that are needed by the service. A service is disposable and is not persisted. A service is not locale sensitive (although +A POJO (Plain Old Java Object) used to perform a unit of work. A service implements an interface that defines its funtional interface. A service has no state apart from injected references to other services or resources that are needed by the service. A service is disposable and is not persisted. A service is not locale sensitive (although it can use a localized resource and therefore produce different execution results dependent on locale). Service instantiation is not dependent on the service implementation but only on the service model being used. 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. +A POJO that does not perform work put rather provides services and framework users with some resource/data. A resource does not nessecarily have to implement a interface. 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. 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'''. -= Proposals = += Suggested Solutions = == Make 'resources' a HiveMind concept at the same level as, and complimentary to, services == @@ -170,6 +169,11 @@ </module> }}} + + +Feel free to add suggested solutions here.. + + = 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. @@ -189,5 +193,5 @@ ChristianEssl: While this is off-topic IMO it is a general problem that any injected Object has to implement an interface and has to be defined as a service. Further some service-implementations may implement different interfaces and so represent more than one service. Maybe implementations could be defined without necesseraly implenting a certain service and have in such a case their own id. I somehow imagine services as the interface of a module while implentations are the private - implementation - part. -DanielFeist: Not particulary off topic as what you mention is the hurdle which seems to prevent resources being defined are services. You provide a more abstract way of looking at the problem i have been trying to tackle. My point of view was that its fair enough for a service to implement an interface and that this happens all the time whereas with resources this is not the case. This led me to the idea of defining resources as something complimentary to services that are biased to the needs of resources such as not having to implement an interface and managing the issue of backing store syncronization etc.. What you suggest it also another interesting and valid way too go which resolves a part of my proposal along with the other problem you mention of services that dont implement an interface ( does this happen much? should !HiveMind allow this? ). It would be good to see how this would work out in practice, maybe you could describe it in more detail with an example either as a part-solution to this proposal adding it along side the two proposals above or as a seperate change proposal? +DanielFeist: Not particulary off topic as what you mention is the hurdle which seems to prevent resources being defined are services. My idea was that its fair enough for a service to implement an interface (maybe its good to ensure this) whereas with resources this is not the case, resources often dont implement an interface. This led me to the idea of defining resources as something complimentary to services that are biased to the needs of resources such as not having to implement an interface and managing the issue of backing store syncronization etc.. What you suggest would go towards a solution to my proposal in that it would allow a resource to be defined as a service as Howard suggests. It would be good to see how this would work out in practice, although i personally am not sure if it's a good idea to have services that done implement an interface. What do people think? Make services more flexible and don't force then to implement an interface or try to solve my proposal without going down this route? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
