avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Albert Kwong <mandr...@yahoo.com>
Subject Re: Container supported interceptable service
Date Mon, 19 Apr 2004 14:57:54 GMT
Since I also lost hammett's post, let me reply it
here:

> I used aspects to provide interceptors capabilities.
However this works for
> all components, not for some in particular. What you
are proposing can be
> (or should be) possible using simple extensions.

In my applications, I am using a two component pattern
to provide the interceptor functionality I have
described (without container support).

public interface AbcService
{
    /* adds the interceptor to a list */
    public void register (int order, AbcInterceptor
interceptor);

    /* gets iterator from list and calls the first
plugin */
    public String doAbc (Object p);
}

/* both interceptor and the end point service
implements this interface.  Each implementation will
register itself with the AbcService.register() method.
*/
public interface AbcPlugin
{
    public String doAbc (Object p, Iterator plugins);
}

This pattern served me well.  However, there are some
downsides:

1. I need to create a register component for every
service that I want to be interceptable.
2. The end-point service also receives the interator,
which is a bit ugly :)
3. Interceptors shall not be allowed beyond the
end-point service.  However my current solution do not
prevent that becuase the registry service do not know
which plugin is the end point (unless I hard code it).

That's why I want it to be managed by the container. 
In that case, I can have interceptors whenever I need
it, wherever I want it.

> >
http://marc.theaimsgroup.com/?l=avalon-dev&m=107696768708344&w=2
> >
http://marc.theaimsgroup.com/?t=107678024500003&r=1&w=2
> >
> > Tell us what you think.

I want to comment on the use cases.

The interceptors are like aspects, except that aspects
are write once and apply to many places, while
interceptors are application specific.  I see
interceptors as extentions to components.

For example, I have an account management service
(service A), and I need to initialize some objects for
each account created (service B).

Without the interceptors, I may build a wrapper that
uses service A and B one by one.  The more complicated
the account creation business logic, the more messy
the wrapper, and hence high coupling and low SOC.

With interceptor, for each service that contributes to
the account creation process, an interceptor can be
designed.  Each interceptor need not know the
existence of the other.  Thus low coupling and high
SOC.

There are some other interesting points in the
previous discussions.  For instance the performance
issues with proxy.  I will need to take a closer look
at that.

Albert


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message