Torsten Curdt wrote:
>
> > Just for reference, in our platform when an client is requesting a
> > pooled service it *always* narrows this to a particular type
> > (typically a factory object) and handles access and decommissioning
> > against a specific type based on its own lifecycle requirements
> > for the object in question. This may be for the duration of a single
> > invocation but more typically, the supplied factory will handle
> > caching of the supplied instance for a configured period of time - i.e.
> > overriding any request from the client to release the instance because
> > the factory knows more about the real world and the factory client only
> > just knows about doing its job.
>
> Maybe I'm too tired yet but...
> Sorry - I'm not quite getting what you are trying to say with that...
> ...could please explain a bit more?
Torsten:
Here is a more detailed explanation of the above - based on our own
experience of handling managers, factories, services etc.
First of all let me declare that I'm opposed to the introduction of
implied semantics on Object - and for this reason, our implementations
make the notion of release explicit on the object that is provided
by lookup. If an object must be released, this is a behaviour that
should be applied to the object being released. It is then up to that
object implementation to notify its manager (or container) of the
release.
In our environment an object supplied by a manager is typically one
of the following three:
1. a service implementation
- handles request from the client to do something
- typically exists for the life of the manager
- is typically created and disposed of by the manager
2. a factory implementation
- handles the creation of new instances of something
- factory is typically created by and disposed of by the
manager
- may have a caching policy which overrides the client
decision to release (for example, an object provided by
the factory may be "Releasable", the release
implementation notifies the factory of the release -
the factory is then free reallocate the object on the
pool or take any other action based on its own caching
policy)
- pooled objects in the above example are not constrained
to be single or multi-threaded (that's an implementation
decision that IMO should not be exposed in an interface)
3. a dynamic manager
- handles lookup requests for dynamically created services
- typically exists for the lifetime of the manager
- lookup requests are non-predictable because the services
it can provides are dynamically generated based on:
a) static configuration using DPML (digital product
modelling language service descriptions)
b) DPML meta-models published to the manager during
its lifetime
- will typically provide change listener and event support
Hope that helps.
Cheers, Steve.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
