> <snip> > 2) "Theoretical Aspects of Component Development" > > I'd like to add a new pattern that we already informally treat > reverently. It is "Interface/Impl seperation". People understand it but > do not really apply it, of it is mucked up. Catalina, for example, is > supposed to be interface/impl separated but is (or was last time I was > active in their mail list) not. The other thing that wven we are > historically a bit guilty of is the separation in terms of jars. We > desire this because we want to hide implementation. Following of from > Peter's K/CAPI/HC trinity of classloaders, where Hosted comps (HC) only > see the Client API (CAPI), the Kernel (K) may have chosen to hide the > impl of the CAPI in a different clas loader, not just by dyanmic proxy. > The K/CAPI/HC trinity will be repeated many times over in the most > complex cases (Phoenix hosting JAMES, FtpServer, Jesktop, EOB). It would > be good if we could really start promoting this. At least I am getting > sick of explaining it to the people I meet on the net when they have > something that is almost a good candidate for an example for EOB. One > case wherewe have it wrong is I think cornerstone.jar, it contains > interface and impl and will probably be left as is for historical reasons.
We are already trying to address this in our own little Avalon framework, and I would like to repeat it below to make sure that I understand properly, and to make sure that I am understanding what you are saying. Basically, we decided to call it, at least for the moment, the InformingAPI pattern. What that says is that XxxComponent may be BlahComponent or FooComponent, but that regardless of where it came from, what it is intended to do is implement the JXXX Api. The agreement then, is to use an InformingAPI to define the interface, and then BlahComponent, FooComponent and BarComponent may then implement this interface in their own black box kind of way. 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? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
