Hi, That’s an interesting question. I would say that it slightly depend of your use case. However, in one level of abstraction, being consistent sounds reasonable.
To illustrate this, I’m going to describe two different types of projects choosing the different strategies: a universe of fine-grain components, and a universe of coarse-grain components (using regular object collaborators). In a project aiming to design and implement a residential gateway, the granularity of components is rather fine-grain. The most part of the functionalities are implemented inside components and are available through services, such as devices, technical services, and internal application services. For this latter case, using iPOJO composite was crucial to maintain the isolation of internal services that must not be accessible outside the application (by peer that are not a part of the application). This granularity was chosen because of the required flexibility for runtime evolution (application updates, modifications of the environment…). In this use case, “everything was dynamic”. In the Jonas JEE server, the chosen granularity was coarse-grain (Guillaume or/and Francois, correct me if I’m wrong). Each technical services provided by the JEE server is implemented by iPOJO components and provided as OSGi services. Two aspects motivated this choice. First, the Jonas team wanted to reuse the most part of their code (makes sense right?). Then, the unit of evolution (update) is the technical service (coarse-grain). So, in conclusion, it’s an open question ☺. There is no generic answer. iPOJO does not influence one or another way, because IMHO it depends of the use case. The goal of iPOJO was to provide functionalities to handle both cases. Regards, Clement -----Original Message----- From: Todor Boev [mailto:[EMAIL PROTECTED] Sent: lundi 27 octobre 2008 19:03 To: [email protected] Subject: IPojo - universe of components? Hello, I was wondering what is iPojo's mission in life: just to make it a bit easier to code in OSGi or the grand idea to lift the Java language to a higher abstraction. This philosophical question is important to me because iPojo like most other DI frameworks seems highly viral. For example suppose I start out with a single component class that creates all it's collaborators with POJN (Plain Old Java New :). At this point I will have to inject all service dependencies into this uber-component and have it pass them on to the constructors of it's collaborators. Soon I get sick of my bad style and decide to let iPojo manage the collaborators and pass around the dependencies for me. And as soon as the collaborators are under iPojo's wing all classes that need them will also have to be iPojo managed. And so in no time almost all my classes will be components. All that will be left are light-weight data objects and static utilities. The former could soon acquire behavior of their own and will inevitably become components because they will likely need to collaborate with other components. As for the static utilities: unless they are bundles of stand-alone purely functional methods they are a bad style to begin with and should be re-cast as singleton components. So if I go with the flow I should have a universe of components. Is this the way to work with iPojo? Or should restrict iPojo to only the core graph of long-lived objects that form the basis of my program and manage the construction, and lifecycle of the more volatile object generations by hand? Cheers, Todor --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
