Adam Murdoch wrote:
On Tue, 3 Dec 2002 02:23 pm, Stephen McConnell wrote:Hi Adam:
This is the basic problem, it seems. These 2 dimensions just don't fit into Context.get() and ServiceManager.lookup(). How does a component writer ask for, say, a container-provided service, or peer-provided state? Or a particular service, whether container-provided or not?Third, how would you phrase the distinction between Context andThere are two views you can take here:
ServiceManager? What is the key issue, in your mind, that separates
items made available via Context and those made available via
ServiceManager? How would you elucidate this to someone new to the
Avalon Framework?
* the state/service separation
* the container/peer separation
It would be really useful to take a step back and decide which of these groupings actually add value for the component writer, and are worth keeping distinct. Maybe both are, maybe neither are.
Then, model the groupings explicitly in the framework interfaces. For example (and, please, they're nothing more than examples):
If neither state/service or container/peer separation is useful, drop one of Context or ServiceManager. Change the contract of the remaining interface so that it delivers all resources (apart from Logger, config and params) to the component.
If state/service separation is useful, change contracts so that, say, Context delivers state, and ServiceManager delivers services.
If container/peer separation is useful, change contracts so that, say, Context delivers container provided resources and ServiceManager delivers peer provided resources. Probably rename ServiceManager to something more appropriate.
If both are useful, well, there are a bucketload of ways to model that. Unfortunately, none (that I can think of) really appeal.
I'm convinced that theere is a religouse thing here - if I look at Merlin standard edition it does provide any container based services - nothing - all it does is run-up a bog standard Avalon component. On the otherhand there is the Phoenix model which promotes containement specialization at the level of context. I think there is middle ground - but it requires an open cross-container standard solution.
Yep.
My current thinking on this is that we need a separation notion -So this would be a possible solution to the 'both are useful' case above. Presumably a component would be able to ask 'give me the non-privileged such-and-such service', or 'give me the privileged such-and-such state', or even 'give me the such-and-such service, I don't care if it's privileged or not'.
*privalided" services and context dependencies. The notion of a
privileged service or context simply means "the container is responsible
for providing the service" and distinct from "the container is
responsible for mediating the service". If we were to provide two
FileService instances, one being privileged and other non-privileged -
the "non-privileged" notion corresponds to a peer, whereas the
privileged notion implies responsibilities on the container.
Do you really think this is going to be useful to the component writer? Do you have some examples?
One or more component authors (like those James guys) - let's imagine they want to lock a component into a suiside pact and as such - their component needs a shutdown service. When the component hits requestShutdown() their component is going die - ok, that's cool - perhaps the component is running under the mailet API and what it really needs is a reserection (but that's a thread for next year) - aside from that - problem is their component needs to be able to say "I need to make request to the thing that started me up in the first place". This is not the same semantics as a classic lookup() or get(). The issue - how can we convey that notion that the component is requesting a service from a provider that it intrisic to its own existance - that's what I'm trying to distinguish here - the notion of a privaliged request. Its priviliged if it's from sibling to parent. A shutdown request is one example, other examples include notification of state change, request for re-deployment etc.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
