Date: 2004-04-16T11:07:21 Editor: 63.69.231.245 <> Wiki: Jakarta HiveMind Wiki Page: ModuleResourcesProposal URL: http://wiki.apache.org/jakarta-hivemind/ModuleResourcesProposal
no comment New Page: = Problem Statement = I see a strong advantage for including another core module artifact at the same level as services. I know this is a fairly big change 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. The idea of this proposal is to further explore this with some concrete ideas and examples. = Definitions = Both services and resources are looked up via the registry using their unique id ''moduleid.serviceid''. '''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 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. This is already implemented in HiveMind. '''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 or is used to gain access to the resource data. Resource data is anything used in implementation, but external to it(Strings from Properties/!ResourceBundles, data in a DB, data or XML from a file/URL, link to a JNDI/LDAP tree etc.). A resource is localizable. The instantiation of a resource changes depending on the type of resource and the backing store of the resource. A resource does not have a lifecycle. A resource could be writable, A resource has a state that tells us if it is in sync with its backing store. This not implemented in HiveMind and i believe it could/should be and would be used widely. = Proposals = Coming soon .... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
