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:[email protected]]
Sent: donderdag 2 juli 2009 3:39
To: [email protected]
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: [email protected]
For additional commands, e-mail: [email protected]
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: [email protected]
For additional commands, e-mail: [email protected]
