Stephen,
See the notes below.
Stephen McConnell wrote:
>
<skip/>
>>>>
>>>This principal is that selection (brought about by the introduction
>>>of a policy argument) is something that can be isolated under a
>>>separate ServiceSelector implementation. This means that the common
>>>ServiceManager does not need to be polluted with selection semantics.
>>>From an implementation perspective this is a really good thing because
>>>we achieve isolation the behaviour (no empty methods).
The semantics of such lookups (role+policy) are well defined and would
not lead to empty methods. The behavior would be exactly the same as in
ServiceSelector. How much effort would it actually take to implement
something like this?
void addService( String role, ServiceSelector selector );
>>>... The principal
>>>is the you "lookup" the directory then apply "select" against the
>>>directory that is returned.
But why do we need the additional step? Including selection in
ServiceManager would not change the principle.
<skip/>
> interface ServiceReclaimer
> {
> void release( Object object );
> void releaseAll( Object token );
> }
>
> interface ServiceResolver extends ServiceManager, ServiceReclaimer
> {
> Object lookup( String role, Object token );
> }
>
> interface PooledSelector extends ServiceSelector, ServiceReclaimer
> {
> Object select( Object token, Object policy );
> }
Let's look at the complete interfaces (show below).
interface ServiceManager
{
Object lookup( String role );
boolean hasService( String role );
}
interface ServiceResolver extends ServiceManager, ServiceReclaimer
{
boolean hasService( String role );
Object lookup( String role );
Object lookup( String role, Object token );
void release( Object object );
void releaseAll( Object token );
}
ServiceManager looks more like a ServiceResolver and vice versa. One of
them just finds a service and the other one actually does some managing.
Don't you think switching the names would better describe the components?
I would not mix with-token and without-token operations. This would be
less consistent and more difficult to implement.
interface Serviceable
{
public void service( ServiceManager manager )
throws ServiceException;
}
interface Resolvable
{
public void resolve( ServiceResolver resolver )
throws ServiceException;
}
Let's say Project A uses ServiceResolver and Project B is determined to
use ServiceManager. Project C would like to use components produced by
both, and implement components that can be used by all projects. So,
Project C's components would look something like the following:
class ComponentC implements Serviceable, Resolvable
{
private ServiceManager manager;
public void service( ServiceManager manager )
{
if (this.manager == null) {
this.manager = manager;
}
}
public void resolve( ServiceResolver resolver )
{
if (this.manager == null) {
this.manager = resolver;
}
}
}
Possible? Of course. The practice we'd like to promote? Not so sure.
Also, LifecycleHelper and other similar classes would have to be aware
of both Serviceable and Resolvable.
Now, do you find the implications described above less severe than those
of including all necessary functionality in ServiceManager? If so,
please describe the practical issues caused by this.
(: A ;)
--
Antti Koivunen (Mr.) <[EMAIL PROTECTED]>
---------------------------------------------
The song of life might not be a simple one,
but there's plenty of room for improvisation.
---------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
