Hi Richard and Clement,
First of all, thank you for the good and quick answers.
Richard, when I said services, I meant the Service Oriented
Architecture, SOA services. That's how I can see components without
services.
Clement, I've read the tutorial you mentioned. Actually, after reading
the example and explanations in the last e-mail, I got the misunderstood
from my part: when I used to read the word "service" I could only think
of *global OSGi services*. Even knowing that you relied on a two-layer
service registry solution to tackle component compositing, I could not
see *local composition services* as they really are.
Things are more clear for me now. Thank you again guys for tips and
explanations :-)
André Lage.
clement escoffier wrote:
Hello,
Richard is right, you can do that with composites. A composite is a ...
composition of components or services.
So, in your case, let's imagine 3 implementation classes like:
@Component
@Provides(specifications= {A.class})
public class A {
public String doSomething() {
return "A";
}
}
@Component
@Provides(specifications= {B.class})
public class B {
@Requires
private A myA;
public String doSomething() {
return "B -> " + myA.doSomething();
}
}
@Component
public class C {
@Requires
private B myB;
@Validate
public void start() {
System.out.println("Call C -> " + myB.doSomething());
}
}
Two things to note:
- A and B provide themselves as 'service'. Despite (like Richard) I do not
recommend such practice, iPOJO supports that.
- B and C deal with the bound component with simple service dependencies.
So, you can argue that you don't want global services there. That's where
composites comes into the games. Composites provide a service isolation
mechanism. So services exposed inside a composite are not exposed outside
(except if they are voluntary exported).
Let's create such composition:
<ipojo>
<composite name="MyApp">
<instance component="org.apache.felix.ipojo.sample.A"/>
<instance component="org.apache.felix.ipojo.sample.B"/>
<instance component="org.apache.felix.ipojo.sample.C"/>
</composite>
<instance component="MyApp"/>
</ipojo>
That's it. You just declare an instance of A, B and C. As bindings are
service-based, it's automatic. As said above, the services exposed inside
the composite are not exposed outside.
So, once deployed, something like 'Call C -> B-> A' appears.
If you want to specify bindings more finely, yo can write something like:
...
<instance component="org.apache.felix.ipojo.sample.A" instance.name
="myA"/>
<instance component="org.apache.felix.ipojo.sample.B">
<property name="requires.from">
<property name="org.apache.felix.ipojo.sample.A" value="myA"/>
</property>
</instance>
...
When you're application works, you can reduce binding coupling by replacing
the instance declarations by instantiated sub-services (iPOJO will looks for
a component type providing your specification).
I recommend you to read
http://felix.apache.org/site/ipojo-composition-tutorial.html to know more
about iPOJO compositions.
Regards,
Clement
2009/8/7 Richard S. Hall <[email protected]>
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]
--
André Lage Freitas
PhD Student - INSA Rennes
Paris Team / INRIA-IRISA
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
