RE: [Embedlets-dev] Managing Dependencies in a Component Based Environment

[Christopher S. <cs...@oo...>]

I think that this highlights one of my pet themes:

1. Abstract the component interface to a general level that will support
most if not all expected demands.
2. Build service adapters that interact with that ONE interface to provide
the specific services.

Changing one adapter is much easier than having to modify or facade 100's of
components, post-facto as the coccon developers found.

Just a short rant.

>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> This just flew by on the Avalon list, posted by Berin.  Since it
> has a lot of
> applicability to the design of the Embedlet Container, I thought
> it would be
> useful to repost it to this list as well.
>
> The last paragraph is especially interesting, since the current
> stuff I have
> been working on (hope to post a whack of stuff by this weekend)
> follows that
> model with the interfaces/base classes in the embedlet.jar API
> jar file and
> the implementations found in outpost.jar.  Guess I'm on the right
> track! ;-)
>
> Back to coding/spec'ing....
>
> ....Andrzej
>
>
> ------- Forwarded message follows -------
> Date sent:      	Wed, 26 Feb 2003 10:38:45 -0500
> From:           	Berin Loritsch <blo...@ap...>
> To:             	de...@av..., coc...@xm...
> Subject:        	[RT] Managing Dependencies in a Component
> Based Environment (long)
>
> In this random thought, I want to address the issue of change in a
> component based environment.  The reason I am bringing it up is because
> of some of the issues that are present in Cocoon's CVS structure with
> dependencies on dependencies on dependencies, and the issues that the
> Avalon team faces daily as they try to make their projects better.
> Through this excersize, we will hopefully learn just what amount of
> change is really possible in a component based environment.
>
> BACKGROUND
>
> For the uninitiated, components are *supposed* to allow for greater
> degrees of change under the hood.  The do this by all components being
> loosely coupled.  Each component that requires another component uses
> that other component according to the contracts put in place in its
> interface.  While not all contracts can be effectively expressed in
> code, they can be expressed in the javadocs.
>
> Components live inside of a container.  THe container's responsibility
> is to create, manage, map, and destroy all the components it controls.
> As a result, there are a great many things that a container can
> incorporate into its management of components.  Things like pooling
> and caching can be done at the container level, as opposed to the
> component level.  That's the theory anyway.
>
> WHAT CAN GO WRONG
>
> For developers who are not used to component programming what inevitably
> happens is that component contracts are either incorrectly specified,
> or because the user changes an implementation they want to have a new
> interface as well.
>
> Components are really cool in that they will allow you to have vastly
> different implementations, all of which will work without breaking the
> system.  As long as the contracts surrounding the component interface
> are flexible enough to allow new implementations, yet strict enough
> to force them to be compatible, we won't have any problems.
>
> What happens if for some reason the interface changes?  For things as
> simple as a package change (the actual binary interface is in all other
> ways identical) the change can be handled by a dynamic proxy.  It's
> really simple and all existing code still works.  For other situations,
> the new component may still offer the same *role*, but with new
> semantics.  A common and flexible solution is to provide a manual proxy,
> or a facade component.  The facade component acts as a placeholder for
> all requests to the old component and translates them into requests for
> the new component.
>
> The facade pattern is a powerful tool if used wisely.  You can play with
> the interface until you find something that *works*, and then change
> all the underlying implementations to the new interface.  That takes
> care of the back end.
>
> EXISTING COMPONENTS
>
> A challenge to frameworks that have been around for a while like
> Cocoon is that other users outside of that framework's control use it.
> It is a good thing until you have to change something.  So how do we
> manage that change?
>
> The facade component can be a useful tool to keep around, that will
> nag the user at runtime until they change their code.  You don't have
> to be as heavy handed at that, but the facade component can work to
> maintain backwards compatibility as well as it can help the change
> toward a new system.
>
> Components can change more dramatically behind the scenes than
> you might think.  As long as a component supports the client/component
> contracts it is compatible.  Everything else behind the scenes can
> change and everything still works.
>
> META INFORMATION AND CONTAINERS WITH COMPONENTS
>
> Something in the pipeline for the future of Avalon is allowing the
> developer to express meta information about the components.  What this
> meta information allows is interaction with the container in a more
> automatic way.  Caching hints can be expressed as component attributes,
> and the container can interpret those attributes and provide the right
> level of caching.  The caching implementation can vastly change, but
> the component won't have to change its implementation.
>
> The example of "component caching" is a bad example mainly because
> it is *resources* that should be cached.  Components are simply meant
> to be used.  However, it is a reality that Cocoon deals with.  Each step
> in the pipeline can be cached.  That is a good thing, but the cache
> was applied to the component and not the resource that it produces.
> This choice was mainly because all the resources produced by the same
> component usually have the same caching attributes.  It is a "shortcut"
> so to speak.
>
> The problem is that Cocoon expressed in component interfaces what is
> really meta information.  In their defense, at the time Cocoon was
> being written, not even Phoenix had the notion of meta information.
> They did what they could do given the limitations of their container.
> This is a bigger problem than simply changing a client interface, or
> something along those lines.  It can still be handled by a facade
> component that makes the translation from the old caching artifacts
> to the new ones.
>
> HOW TO MANAGE FACADE COMPONENTS
>
> It is important to keep the core API of a framework as simple as
> possible.  That is why I advocate the use of an API JAR and an
> implementation JAR.  The API jar has all that is needed to properly
> express the client/component contracts in a framework.  The
> implementation JAR has all the blessed implementations of the
> components.  When you need to support legacy users, you can place
> all the facades and deprecated APIs in a separate compatibility JAR.
> Both the interfaces and the facade implementations are included in
> that JAR.  The users that don't want to keep up with change can
> simply include that JAR and everything would work as it has in the
> past.
>
> That would allow the Cocoon system to clean itself up, and separate
> alot of dependencies.  The chalange is of course to make the
> compatibility JAR completely separate from the original source.
>
> If I am missing something, let me know.
>
>
> ------- End of forwarded message -------
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Scholarships for Techies!
> Can't afford IT training? All 2003 ictp students receive scholarships.
> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
> www.ictp.com/training/sourceforge.asp
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>