avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pete Carapetyan <p...@datafundamentals.com>
Subject Re: Website docs
Date Sat, 30 Mar 2002 17:30:54 GMT
<snip discussing the difference between the InformingAPI and the component that
implements it>

> >What this does for us is make sure that the first guy to implement a component
> >works to a common API, such as JAAS, JCA, or JBLAH, instead of just doing his
> >own thing. That way the next guy works to the JBLAH interface when he writes his
> >plubbable component, not to the interface set by the JBlahComponent, which has
> >every right to be funky, without the InformingAPI pattern. Keeps the idea of
> >pluggability possible in practice, rather than just as an abstract idea that
> >falls apart when the second implementation doesn't work to the same interfaces
> >that the first guy uses.
> >
> >Does that make sense? ...or did I go off into different waters?
> >
> More or less the same thing.  The first person to code the the thing
> deliberately creates interfaces thus making an API.  Wiley's Patterns
> for Java book refers to it as 'Interface' and cites Grand98 as the
> origin.  It is a dodgy thing to include in a pattern book as Java has it
> as a core concept.  Having said that people think iyt is mostly for
> things they use and not things they make.  It is worth pushing..

Interface is one of those polymorphic terms in the english language that means so
many things. Here, it is used in the more literal contract sense, but not perfectly
literal, because JAAS, JCA,  JDBC, and JXXX are not written as interfaces they are
API's. Semantics then can be more than a little bit confusing, because from a
component standpoint, you want to look at them as an interface which the component
would implement as a black box.

> You have not talked about an equally important test of your seperation.
>  Zip the interface into one jar, the impl into another and a test into a
> third. Mount the three in different classloaders with only the
> interfaces visible to both the other two.  I.e. it is no good separating
> if you distribute both in one Jar.

Indeed. Have not looked how you handle it with the three different logging
components, any one of which can be used, but it is the same problem? Assume, the
same solution?

It seems unlikely though, that any of this would really be possible without a
configurator tool that would let you build your components together as a group
designed to work with each other. Not just like Maven, but in a addition, with pick
boxes like pick this logging component, this persistence component, this view
component, etc.

There are many more problems than this though, because not all InformingAPI's are so
clean. Lots of API's are an amalgamation of all kinds of functionality. No way you
can bring them in as a single purpose component, but instead as a collection of
components. Struts is a perfect example. It brings together many different
functionalities. You would have one InformingAPI, but many different component
interfaces, including Validation, action mapping, and on and on. But a different
InformingAPI that accomplishes many of the same goals is JavaServerFaces (JSR127)
which takes these forms, and more. So if you wanted plugability to use one or the
other, JSF provides 7 distinct areas, Struts 5 distinct areas, and the mapping
between them is not so clean. Hurts my head to think about this.

> Lastly, when you say "our own little Avalon framework" what do you mean ?

There is a bunch of us who are refugees from another very successful framework, but
one which we considered to be eventually doomed because of it's tightly coupled, and
commercially sponsored roots. We have, apparently, broken off to start afresh. We
will be attempting to use Avalon as our starting point. Quite a terrific framework,
this Avalon! No telling how fast this will move, though, as the old framework is
working well enough for us that we don't have to slam together a bad product together
just for the sake of getting something out the door. It is starting very slowly, so
far, which is fine.

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

View raw message