Leo:
I've been thinking a lot about this following the emails from yourself
and Berin. My conclusion is that there are a lot of different and
conflicting requirements - that are all valid because they are dealing
with different applications needs for a Container at quite different
scales and application domains.
My current thinking is that we should seperate "service-management" from
"component-management". I've restructured the Merlin Container interface
such that it is only dealing with "component-management" and provides a
"isolation" model. Given this change, the subject of
"service-management" can be dealt with somewhat more freely and under
different interfaces addressing the different requirements.
Some of the possible "service-management" requirements:
service aggreggation
Where all service are published to a aggregator
E.g. take this container specification and give me
back the set of candidate services that it declares.
This is required in cases where you are using a
container as an internal part of the component
management system - e.g. the parent container
delegates a part of component management to a
sub-container, get the aggreggated set of services,
and applies its own service management policies.
service location
Where services are disclosed based on a request for
the service - similar to a http protocol - if I know
the page I get the page and if I don't I get a 404,
or the ECM model based on a structured lookup matching
and interface name or service key.
This is required in situations where you have the need
to provide access to services that *may* be available
but the keys are not know at assembly time. For example
a container monitoring a set of jar files representing
plug-in extensions. The disclosure is based on the
addition of a jar file to a directory, combined with
service attribiutes on compoonent descriptors that
possibly constrain service visibility.
service publication
Where a container publishes services into a service
publication system (e.g. JNDI). The container publishes
services into to the extenal publication system based on
container specific directives and component descriptors.
Cheers, Steve.
Leo Sutic wrote:
> Just one final note:
>
> the JNDI binding/lookup must be pluggable in the container. For example,
> if you use JBoss, then JNDI *requires* all objects bound to it to be
> Serializable / Referenceable / etc. So if the container just takes a
> component
> and tries to bind it (or creates a proxy for it) then the bind()
> operation
> will most likely fail.
>
> The solution (JBoss specific) is to use a NonSerializableFactory class.
>
> The point is that other JNDI implementations may work differently. I'd
> say that
> while the lookup () operation on JNDI is well-defined across all
> containers (that
> I've seen), the bind() operation is not neccesarily so.
>
> One possibility is to define an interface:
>
> interface JNDIPublisher /* implements Component */ {
> void bind (String name, Object obj);
> Object lookup (String name);
> void unbind (String name);
> }
>
> and plug the JNDI publisher in as any other component (taking care
> not to make it visible to the other components in the container).
>
> /LS
>
>
>>From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>>
>>
>>>From: Leo Sutic [mailto:[EMAIL PROTECTED]]
>>>
>>>
>>>
>>>>If you want to access a globally accessible service, you get an
>>>>InitialContext()
>>>
>>>Nitpick: The container gets an InitialContext. The whole point is
>>>to be able to access globally accessible services published
>>
>>via JNDI
>>
>>>via the ServiceManager interface. The Serviceable component
>>>should not need to care whether the service comes in via JNDI
>>>or whether it is a peer in the container.
>>
>>
>>Fair enough.
>
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
--
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]>
