geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pasi Salminen <pasi.salmi...@profitsoftware.com>
Subject Re: [services] getting service developers started - the initial component model
Date Thu, 14 Aug 2003 05:49:31 GMT
We have a framework built on top of J2EE services where we are coding application
level services like this:

public interface PropertyService
{
    public String getProperty( String propertyName,String defaultValue );
}

public class PropertyServiceImpl
    extends AbstractService
    implements PropertyService
{
    public String getProperty( ... ) { }
}

and the lookup is then like this:

PropertyService ps = ( PropertyService ) Services.getService(
PropertyService.class.getName( ) );

which means that the interface is used to lookup the implementation. Here's the XML
configuration (which is used to configure Services class)

 <services>
  <service id="com.profitsoftware.appfw.propertyservice.PropertyService">

<class-name>com.profitsoftware.appfw.propertyservice.PropertyServiceImpl</class-name>

  </service>
    ...
 </services>

So, if somebody wants to replace service implementation (which is used through the
framework by other components), they just change the implementation class in the
XML configuration file. Works nicely. Here nobody is managing other components but
they are using each other by looking up the service and using it through a well
defined interface.

Regards,

Paci

Berin Loritsch wrote:

> Jeremy Boynes wrote:
>
> >>The danger with using too much JMX is that when components start
> >>talking to each other using JMX, then it's very difficult to undo at a
> >>later stage.
> >>
> >
> >
> > Difference between components managing each other (for which JMX may be
> > good), and invoking each other (for which an alternative may be better).
> >
> > We need to keep this difference in mind.
> >
> > We also need to be careful about coupling of implementations and making sure
> > we keep invocations detached (to allow for redeployment). JMX enforces this,
> > any other framework needs to support it as well.
>
> Coding to interfaces does a good job of managing these things.  As long as
> your code *never* does a cast to the interface like this:
>
> ((MyImpl)service).doSomethingNotInInterface();
>
> That is REALLY BAD.  You will never be able to have loose coupling, or insert
> interceptors properly with that approach.  When the interface covers the entire
> contract, components can use each other and even be completely replaced with
> something new and still function.
>
> The MAJOR RED FLAG I saw is the notion of components _managing_ each other.
> It is the Container's job to manage components.  Period.  No component should
> manage another component unless it in turn is a container for the managed
> component.  For example:
>
> BAD
> ---
>
>       +--------------+
>     ..|  Container   |..
>     . +------+-------+ .
>     .        |         .
>     v +------+-------+ v
> +----+---+      +--------+
> | Comp 1 |.....>| Comp 2 |
> +--------+      +--------+
>
> (the dotted line is management)
>
> GOOD/ACCEPTIBLE
> ---------------
>
>       +--------------+
>       |  Container   |
>       +------+-------+
>       .      |
>       . +----+---+
>       .>| Comp 1 |..
>         +----+---+ .
>              |     .
>         +----+---+ .
>         | Comp 2 |<.
>         +--------+
>
> In other words, a heirarchy of components is much easier to work with, develop,
> and debug than any component usurping the container's job and cause
> unpredictable results.  Not to mention it complicates the security mechanisms
> much more than necessary.
>
> --
>
> "They that give up essential liberty to obtain a little temporary safety
>   deserve neither liberty nor safety."
>                  - Benjamin Franklin

__________________________________________________________________________

This message and its attachments have been found clean from known viruses 
with three different antivirus programs.
__________________________________________________________________________

Mime
View raw message