communication between mobile device and OSGi on server

[Uijtdewilligen, Freek]

Hello all,

 

I've been reading up on OSGi, checked out Neil Bartlett's excellent
tutorial, and checking out some of the examples available for Felix. The
reason for this is that for my master thesis, I'm developing a
context-aware application on Android and plan to include a
context-awareness framework that has been developed on Oscar. Although
it doesn't work straight out of the box on Felix, I suppose some minor
adjustments will fix this.

 

To shortly explain what it does: the framework contains a context
broker, allowing the registration of context sources, which can be
looked up by context consumers. These are all implemented as separate
bundles. It also has a reasoning engine (also made up out of a number of
bundles), allowing notifications to be triggered by certain context
properties. To do a notification, the reasoning engine calls a specified
method of a registered bundle. For more info, check out the Amigo
Project.

 

My idea is to get data from the phone, like its location or some
information entered by the user, into the framework, so that it can be
made available to the reasoning engine and to other registered services.
For instance, based on the location, a certain context consumer could
determine the weather at that location and send it back to the phone.
The location could also be used by the reasoning engine to trigger a
notification when the user is close to a store.

 

 

The question is, what is the best way to establish the communication
between the mobile device and the context-awareness server running on
Felix? Does the Android phone need to run an OSGi-platform, that
communicates somehow with the other OSGi-platform? Something like:

 

Phone -> context source bundle, running on OSGi on Android -> context
source bundle running on OSGi on server

 

Or should I use another way, like some RMI-based objects on the server,
that can be looked up in a registry and can be used to call methods of
the context source bundle? Like:

 

Phone -> RMI-object on server -> context source bundle on OSGi on server

 

Scalability is also an issue, how is it possible to have multiple
phones, thus multiple context sources providing their data to the
server?

 

 

Hopefully there is someone who could shed some light on this for me,
finding the best solution has been bugging me for some time now.. Of
course, if you want to know more about my assignment, I'd be happy to
explain it some more, but I thought it to be best to keep it as simple
as possible here.

 

Thank you very much!

 

Freek Uijtdewilligen

University of Twente, the Netherlands

Logica, the Netherlands

 



Please help Logica to respect the environment by not printing this email  / Pour contribuer comme Logica au respect de l'environnement, merci de ne pas imprimer ce mail /  Bitte drucken Sie diese Nachricht nicht aus und helfen Sie so Logica dabei die Umwelt zu schuetzen  /  Por favor ajude a Logica a respeitar o ambiente nao imprimindo este correio electronico.



This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

[Nima Kaviani]

Hi Freek,

is it CACI, the system you are trying to work on? I remember reading
the following paper written by people from your school

-- Dynamic Context Bindings in Pervasive Middleware:
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4144876

so it might be what you are trying to improve on. right?

I would recommend you have a look at the following works mostly by Jan
Rellermeyer. The papers are explanatory and should provide you with
the proper answer on things you are asking about. Not sure if Jan is
monitoring this mailing list, but he is a reliable source to get
feedback from.

1. R-OSGi: Distributed Applications Through Software Modularization
(http://www.springerlink.com/content/u55h52l45q5144v1/)
2. AlfredO: An Architecture for Flexible Interaction with Electronic
Devices (http://www.springerlink.com/content/j022273606816lu6/)

and you can also have a look at this other paper:

3. Holger Schmidt, Jan-Patrick Elsholz, Vladimir Nikolov, Franz J.
Hauck, Rüdiger Kapitza: OSGi4C: Enabling OSGi for the Cloud. The
Fourth International Conference on Communication System Software and
Middleware - COMSWARE (Dublin, Ireland, June 16-19, 2009), ACM.
Accepted for publication.

The above papers should give you a failry good understanding of
splitting your implementation across distributed OSGi platforms

> Scalability is also an issue, how is it possible to have multiple
> phones, thus multiple context sources providing their data to the
> server?

Depends on how you implement your architecture. Have a look at message
oriented middleware (pub/sub designs in particular) and you may find
some interesting information. I have to run now, I will try to provide
you with a more detailed explanation on this last part later in the
week.

good luck,
-Nima

--
http://nima.magic.ubc.ca

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Uijtdewilligen, Freek]

Hey Nima,

Thanks for the advice! It might prove to be very useful, the R-OSGi system might be something I'll use!

I'm not working on CACI, but I know some of the writers, even had some courses from some of them. The system I'm using is part of the Amigo Project, which was a EC funded project into smart homes and such. As part of that, a context management service and announcement and notification service were developed as a number of modules on OSGi (Oscar).  You can read about it in


A Service-Oriented Middleware for Context-Aware Applications.
Bonino da Silva Santos, L.O. and Poortinga-van Wijnen, R. and Vink, P. (2007)
http://eprints.eemcs.utwente.nl/11446/



Does anyone know whether the older Oscar implementation of OSGi has some major disadvantages, as compared to Felix? Since the modules I'm using have been developed for use on Oscar, I should either take an effort to make these work on Felix, or develop my own bundles on Oscar..

Thanks!

Freek Uijtdewilligen

-----Original Message-----
From: Nima Kaviani [mailto:nima.kaviani@...]
Sent: donderdag 2 juli 2009 3:39
To: users@...
Subject: Re: communication between mobile device and OSGi on server

Hi Freek,

is it CACI, the system you are trying to work on? I remember reading
the following paper written by people from your school

-- Dynamic Context Bindings in Pervasive Middleware:
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4144876

so it might be what you are trying to improve on. right?

I would recommend you have a look at the following works mostly by Jan
Rellermeyer. The papers are explanatory and should provide you with
the proper answer on things you are asking about. Not sure if Jan is
monitoring this mailing list, but he is a reliable source to get
feedback from.

1. R-OSGi: Distributed Applications Through Software Modularization
(http://www.springerlink.com/content/u55h52l45q5144v1/)
2. AlfredO: An Architecture for Flexible Interaction with Electronic
Devices (http://www.springerlink.com/content/j022273606816lu6/)

and you can also have a look at this other paper:

3. Holger Schmidt, Jan-Patrick Elsholz, Vladimir Nikolov, Franz J.
Hauck, Rüdiger Kapitza: OSGi4C: Enabling OSGi for the Cloud. The
Fourth International Conference on Communication System Software and
Middleware - COMSWARE (Dublin, Ireland, June 16-19, 2009), ACM.
Accepted for publication.

The above papers should give you a failry good understanding of
splitting your implementation across distributed OSGi platforms

> Scalability is also an issue, how is it possible to have multiple
> phones, thus multiple context sources providing their data to the
> server?

Depends on how you implement your architecture. Have a look at message
oriented middleware (pub/sub designs in particular) and you may find
some interesting information. I have to run now, I will try to provide
you with a more detailed explanation on this last part later in the
week.

good luck,
-Nima

--
http://nima.magic.ubc.ca

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...



Please help Logica to respect the environment by not printing this email  / Pour contribuer comme Logica au respect de l'environnement, merci de ne pas imprimer ce mail /  Bitte drucken Sie diese Nachricht nicht aus und helfen Sie so Logica dabei die Umwelt zu schuetzen  /  Por favor ajude a Logica a respeitar o ambiente nao imprimindo este correio electronico.



This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Richard S. Hall]

On 7/7/09 3:16 AM, Uijtdewilligen, Freek wrote:

> Hey Nima,
>
> Thanks for the advice! It might prove to be very useful, the R-OSGi system might be something I'll use!
>
> I'm not working on CACI, but I know some of the writers, even had some courses from some of them. The system I'm using is part of the Amigo Project, which was a EC funded project into smart homes and such. As part of that, a context management service and announcement and notification service were developed as a number of modules on OSGi (Oscar).  You can read about it in
>
>
> A Service-Oriented Middleware for Context-Aware Applications.
> Bonino da Silva Santos, L.O. and Poortinga-van Wijnen, R. and Vink, P. (2007)
> http://eprints.eemcs.utwente.nl/11446/
>
>
>
> Does anyone know whether the older Oscar implementation of OSGi has some major disadvantages, as compared to Felix? Since the modules I'm using have been developed for use on Oscar, I should either take an effort to make these work on Felix, or develop my own bundles on Oscar..
>    

The major difference is that Oscar is R3 while Felix is R4, besides that
I do there are bugs in the last Oscar release that have been fixed in Felix.

You should be able to try to run your bundles on Felix with minimal
changes. The biggest issue you will likely run into is that the R3 spec
was not clear on what classes were visible to bundles from the class
path, so Oscar allow bundles to see everything on the application class
path by default. The R4 spec was much more clear on this topic and now
Felix disallows access to everything by default, which makes more sense
from a modularity perspective.

So, for example, a lot of bundles written for Oscar don't import
"org.osgi.framework" since they got it implicitly. With Felix this will
result in exceptions, so all bundles must import this package if they
have an activator, for example. With Felix, you have to import
everything except java.* packages. Period.

This means you might have to add some imports to your bundles to get
them to work correctly, but that should be about it.

-> richard

> Thanks!
>
> Freek Uijtdewilligen
>
> -----Original Message-----
> From: Nima Kaviani [mailto:nima.kaviani@...]
> Sent: donderdag 2 juli 2009 3:39
> To: users@...
> Subject: Re: communication between mobile device and OSGi on server
>
> Hi Freek,
>
> is it CACI, the system you are trying to work on? I remember reading
> the following paper written by people from your school
>
> -- Dynamic Context Bindings in Pervasive Middleware:
> http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4144876
>
> so it might be what you are trying to improve on. right?
>
> I would recommend you have a look at the following works mostly by Jan
> Rellermeyer. The papers are explanatory and should provide you with
> the proper answer on things you are asking about. Not sure if Jan is
> monitoring this mailing list, but he is a reliable source to get
> feedback from.
>
> 1. R-OSGi: Distributed Applications Through Software Modularization
> (http://www.springerlink.com/content/u55h52l45q5144v1/)
> 2. AlfredO: An Architecture for Flexible Interaction with Electronic
> Devices (http://www.springerlink.com/content/j022273606816lu6/)
>
> and you can also have a look at this other paper:
>
> 3. Holger Schmidt, Jan-Patrick Elsholz, Vladimir Nikolov, Franz J.
> Hauck, Rüdiger Kapitza: OSGi4C: Enabling OSGi for the Cloud. The
> Fourth International Conference on Communication System Software and
> Middleware - COMSWARE (Dublin, Ireland, June 16-19, 2009), ACM.
> Accepted for publication.
>
> The above papers should give you a failry good understanding of
> splitting your implementation across distributed OSGi platforms
>
>    
>> Scalability is also an issue, how is it possible to have multiple
>> phones, thus multiple context sources providing their data to the
>> server?
>>      
>
> Depends on how you implement your architecture. Have a look at message
> oriented middleware (pub/sub designs in particular) and you may find
> some interesting information. I have to run now, I will try to provide
> you with a more detailed explanation on this last part later in the
> week.
>
> good luck,
> -Nima
>
> --
> http://nima.magic.ubc.ca
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
>
> Please help Logica to respect the environment by not printing this email  / Pour contribuer comme Logica au respect de l'environnement, merci de ne pas imprimer ce mail /  Bitte drucken Sie diese Nachricht nicht aus und helfen Sie so Logica dabei die Umwelt zu schuetzen  /  Por favor ajude a Logica a respeitar o ambiente nao imprimindo este correio electronico.
>
>
>
> This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>