On 8/7/09 11:35, André Lage wrote:
Hi all!
I'm interested in knowing how I could compose iPOJO components, but
only in terms of components. Let me better explain.
Imagine that I am a service developer (a single service developer). In
this case, from the OSGi point of view, I should implement a Java
interface that describes/represents this service and then publish my
service (suppose that there is only this service inside of a bundle).
But before implementing this interface, I need to well design and
develop my component-based application.
In other words, I need to take advantage of the iPOJO component model
when composing *without taking into account services*, I just want to
plug/unplug components. In some tutorials, I could only see
relationships among iPOJO components through OSGi services.
Let's take an example: suppose that the following illustration is my
application design (a single OSGi service inside of a bundle):
D-->-C-->-B-->-A
where letters are components;
arrows are the connections among them; and
A is the component that finally implements the service
interface.
Here is my question: How can I compose D, C and B with no services?
I know it may sound strange the fact of avoiding service interactions.
Actually, I'm interested in both components and services, but I must
also know how much iPOJO component model can help me when developing
"pure" component applications. I've read in another thread about other
OSGi-based component models (Blueprint, DS, Spring-DM, Peaberry),
however I don't know them. Please, feel free to report something even
it is about other OGSi component models rather than iPOJO.
I am sure Clement can answer about iPOJO details better than I, so I
will leave it to him, but I believe what you want to do is possible
using composites.
More generally, it is not clear to me why you see "pure components" as
being without services...that sounds like object orientation to me.
Typically, components provide and require interfaces through which they
interact with other components. In OSGi we treat these interfaces as
OSGi services (which themselves are just interfaces).
So, even if you are not using OSGi, I would still recommend an approach
where your components provide and require interfaces, which is the main
mechanism for keeping component implementations decoupled from each other.
-> richard
Thank you in advance,
André Lage.
---------------------------------------------------------------------
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]
