Pete, ><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. > I agree that 'Interface' is overloaded in English let alone computing.
Citing JDBC, Jxxx, then I agree with you that they are more APIs. Maybe we can meet in the middle by saying that ones duty as a Java developer is to split into interface, abstractions, and implementations. In AltRMI we hope that interface is exacltly that and includes final serialiazable classes (pattern book referes to these as ImmutableBeans, other as 'Value Objects'). The difference between the anstract and final classes is moot as far as AltRMI (and the bean container that uses it - Enterprise Object Broker) is concerned. Neither the abstract or final (impl) classes arrive on the client side. The client only deals with the interface and the ImmutableBeans. EJB is very similar. Client only deals with Home and Remote interfaces and knows little of how the bean developer put the app together or what patterns they used. >>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? > Three different logging comps? LogKit, Log4J & Commons-Logger? We only really use the former. >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. > Picker. Hmm sounds like our years old ComponentManager. >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. > No name? Another commerical effort? Using or competing with Avalon? Since we're name dropping, are your refugees from one other listed frameworks on JSR111 ? By the way, I am quite happy with 'Interface/Impl seperation' as the MEME formerly known as the 'Interface' pattern. I trust you are equally happy with 'InformingAPI' and that we won't meet in the middle for this. - Paul -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
