User DocumentationOne minute descriptionTwo minute tutorial Five minute introduction Advanced Topics FAQ Container Components Terminology Mock Objects Inversion of Control Types PatternsInversion of ControlDependency Injection Constructor Injection Setter Injection Interface-Impl Separation Lifecycle Antipatterns Developer DocumentationHow To ContributeRelative Volunteering Release Process Project InformationSloganMailing lists Source Repositories Open Issues Blog entries Statistics Team Sister Projects TShirts MiscellaneousDifferentiatorsNirvana Full Sitemap |
DifferentiatorsAuthors: Paul Hammant There are a number of specifications from the last few years that proport to be container/component designs…Sun specified nearly-IoC Containers & Component designsIt could be said that Sun have created a few container/component designs.......Enterprise Java BeansClearly Entity and Session beans run inside a container. The API is well defined, and to varying degrees of success one can deploy EJB appllications to WebLogic, WebSphere, Orion and JBoss etc. For assembly and configuration, there is high use of element-normal XML . There are some mandated parent objects and interfaces for various to extend and/or implement. Resolution is done by the components themselves via JNDI more often than not.PicoComponents are simpler in they they do not force an extensive XML markup, nor require the implementing of certaing interfaces or extening base classes. Quite importantly the relationship between factory (home), implementation (bean) and interface (remote) parts is much more real in PicoComponents. Lastly, EJB components are nearly impossible to unit-test without much effort.ServletsNot so obvious - Servlets are contained by a servlet container. They are generally bundled with (or replaced by) value added propositions like JSP, but it is still a container/component design. High use of XML for assembly and configuration. Servlets have no concept of parent container or the conatainer above that (sometimes EJB) and its provision of components, which is very unfortunate. Servlets have a number of interfaces to honor, none of which is too malignent. Servlets typically deal with external (or parent) components via RMI or JNDI. In more recent releases of EJB, local interfaces rather than RMI may be the mechanism for connection the parent components. WebLogic have always provided an optimizing mechanism for this interoperationAs with EJB, PicoComponents are far simpler. This is probably because they offer no web experience, apart from anything else. Servlets again are not that unit-testable.AppletsApplets, though presently not so often used, are a good example of Container/Component separations. There is very little XML in use by Applets. Configuration is typically delivered in applet tags in HTML. Applets are granted some access to the parent container, the brower, and its DOM model for pages and other applets. There very little standardisation for Browser as a container.As with EJB, PicoComponents are far simpler. Applets are unit-testable but with a little effort. Complex DOM interoperation is impossible under unit testing.Non IoC container-like things by variousMainable (Sun)public static void main(String[] args) {} Familiar? Hopefully not ![]() Singleton (pattern)See Singleton antipattern.Static Factory (pattern)Used in a similar way the Singleton pattern (and similarly detailed in "Design Patterns"), this allows disparate classes to create/get other components. Very dirty applications result from overuse of static factories.(TODO: move to antipatterns section?) JNDI ( Java API )A huge map of clunkily access components via a very non-IoC mechanism. It has to be strapped with much XML to prevent inappropriate access. This is not IoC because the component reaches out for external component dependancies whenever it feels like. This last fact clouds Serlvets and EJB use.AWT, Swing, SWT (Java graphic toolkits)Nice container/component designs. In the case of Swing, perhaps a little difficult for coders to easily assemble applications.Eclipse (Java grapical application platform)The Eclipse platform is very compelling. It supports the notion of a pluggable application concept. Each component statically accesses other components via a factory (which at least Paul does not like), though it is clear that some complex classloader magic is going on. The underpinning set of graphical components, SWT , are a simple and elegant design.Other IoC container / component designsAvalon-Framework and its containersApache hosts a project that has been running for years called Avalon. It has many components that fit that its design and many containers is writtern in Java, with a port underway to C#. Avalon components are characterised by implementation of many optional interfaces. Avalon components are distributed with meta-information in XML in the jar file. More XML is required to assemble components together for the same of a application. Avalon-Phoenix, Excalibur Component Manager (ECM), Avalon-Fortress and Avalon-Merlin are the pertinent containers .Apache-Avalon requires implementing components to implement a number of interfaces. This has proven historically to be a bit of a turn-off for component writers. Luckily there are no abstract classes that have to be extended by component writers. Those interfaces are :-
Avalon is a type-1 IoC design. Its flaw is that components written for it cannot be used without an Avalon-Framework compatible container. Many say that the XML that has to accompany each component is also a flaw. Unit-testing of Avalon components is very difficult because it is difficult to manage the components from JUnit. Carbontodo |