You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by André Lage <An...@irisa.fr> on 2009/08/07 17:35:57 UTC
Composing iPOJO components with no service requiring
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.
Thank you in advance,
André Lage.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Composing iPOJO components with no service requiring
Posted by André Lage <An...@irisa.fr>.
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 <he...@ungoverned.org>
>
>> 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: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
--
André Lage Freitas
PhD Student - INSA Rennes
Paris Team / INRIA-IRISA
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Composing iPOJO components with no service requiring
Posted by clement escoffier <cl...@gmail.com>.
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 <he...@ungoverned.org>
> 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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Composing iPOJO components with no service requiring
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org