Année 2008

Curriculum vitae

pour une demande d’inscription à

L’habilitation à diriger des recherchesspécialité informatique

par

Stéphane FRENOT

Travaux effectués au sein du Centre d’Innovation en Télécommunications et Intégration deServices (CITI) de l’INSA

de Lyon et de l’équipe Architecture Réseaux et Systèmes (Ares) de l’INRIA Rhône-Alpes

Chapter 1

CV

1.1 CivilitéCe CV décrit mes activités de recherche depuis ma thèse en novembre 1998.

Stéphane Frénot13 av. des SportsF-69500 BronNé le 27 septembre 1970 à Strasbourg (67)Marié 2 enfantshttp://perso.citi.insa-lyon.fr/sfrenotstephane.frenot@insa-lyon.fr

1.1.1 Expériences professionnellesDepuis septembre 1999

– Maître de conférences au département télécommunications, services etusages de l’INSA de Lyon.

– Membre du laboratoire CITI, responsable du thème Middleware– Membre du projet Ares / Amazone

1998-1999 ingénieur de recherche– Département informatique de l’INSA Lyon

1997-1998 ingénieur de développement– Société Al’X, responsable d’un projet de développement d’application de

gestion de dossiers patients en milieu hospitalier

1.1.2 DiplômesNovembre 1998 : Thèse en informatique Université Lyon I“Nouvelles technologies pour la gestion et la représentation de l’information

2

BIBLIOGRAPHIE 3

3 journaux internationaux + 1 en soumission13 publications en conférence internationales2 journaux nationaux15 publications nationales6 workshops3 présentations invité10 rapports de recherche et techniques INRIA

Tab. 1.1 – Synthèse des publications

médicale”Directeur de recherche : Pr. André FloryRapporteurs : Pr. Marie-France Bruandet, Pr. Guy GouardèreJury : Pr. Gérard Duru, Pr. Jean-Marc Geib, Pr. Maurice Laville,Dr. Alain Mercatello, Mr. Gérard Alix

Juillet 1993 : DEA informatique INSA Lyon“Une nouvelle interface pour la gestion des prescriptions médicales basées surdes techniques d’apprentissages”Laboratoire LISI, INSA Lyon, Encadré par Pr. André Flory

Juin 1993 : Diplôme d’ingénieur INSA LyonDépartement Informatique

1.2 Recherche

1.2.1 PublicationsLa table 1.1 présente une synthèse de mes publications. Les publications

récentes portent sur les approches à composants et leur gestion.

1.2.1.1 Journaux internationaux

[Brebner et al. 2005] Paul Brebner, Emmanuel Cecchet, Julie Margue-rite, Petr Truma, Octavian Ciuhandu, Bruno Dufour, LievenEeckhout, Stéphane Frénot, Arvind S Krishna, John Murphy etClark Verbrugge, « Middleware benchmarking : approaches, results, ex-periences », Concurrency Computat. : Pract. Exper, p. 1799–1805, vol. 17,2005. 1.2.2.3, 2, 2.6

[Frénot et Laforest 1999] Stéphane Frénot et Frédérique Laforest,« Medical Records Management Systems : Critics and New Perspectives »,Methods of Information in Medicine, p. 89–95, vol. 38, n 2, 1999. 1.2.2

[Royon et Frénot 2007] Yvan Royon et Stéphane Frénot, « MultiserviceHome Gateways : Business Model, Execution Environment, Management

BIBLIOGRAPHIE 4

Infrastructure », IEEE Communications Magazine, p. 122–128, vol. 45, Oc-tober 2007. 1.2.2.3, 2, 2.1

1.2.1.2 Publications en conférences internationales avec comités delecture

[Al Masri et Frénot 2001] Nada Al Masri et Stéphane Frénot, « SpeechRecognition Integration in Medical Information System »,MedInfo, London,England, October 2001.

[Flory et Frénot 1999] André Flory et Stéphane Frénot, « An IntelligentSystem for Drug Prescription Support », Intelligent Systems : ISCA 5thInternational Conference. International Society for Computers and TheirApplications - ISCA, Denver, CO, USA, 1999.

[Frénot et al. 1995] Stéphane Frénot, Frédérique Laforest et AndréFlory, « An intelligent system to help expert users : application to drugprescription », 7th int conf on Artificial Intelligence and Expert Systems Ap-plications (EXPERSYS’95), p. 61–66, San Francisco, CA, USA, November9-10 1995. 1.2.2

[Frénot et al. 2008] Stéphane Frénot, Yvan Royon, Pierre Parrend etDenis Beras, « Monitoring Scheduling for Home Gateways », IEEE/IFIPNetwork Operations and Management Symposium (NOMS 2008), SalvadorBahia, Brazil, April 2008. 1.2.2.3, 2

[Frénot et Royon 2005] Stéphane Frénot et Yvan Royon, « Componentdeployment using a peer-to-peer overlay », Working Conference on Com-ponent Deployment, Grenoble, France, 28-29 November 2005. 1.2.2.3, 2

[Ibrahim et al. 2007a] Noha Ibrahim, Fréderic Le Mouël et Sté-phane Frénot, « C-ANIS : A Contextual, Automatic and Dyna-mic Service-Oriented Integration Framework », Proceedings of the In-ternational Symposium on Ubiquitous Computing Systems (UCS’2007),LNCS, vol. 4836, p. 118–133, Springer Verlag, Tokyo, Japan,novembre 2007, http://www.le-mouel.net/Research/Publications/Conferences/2007/UCS2007/UCS2007.pdf.

[Ibrahim et al. 2007b] Noha Ibrahim, Frédéric Le Mouël et Sté-phane Frénot, « Automatic Service-Integration Framework forUbiquitous Environments », Proceedings of the International Confe-rence on Mobile Ubiquitous Computing, Systems, Services and Techno-logies (UBICOMM’2007), Papeete, French Polynesia (Tahiti), France,November 2007, http://www.le-mouel.net/Research/Publications/Conferences/2007/UBICOMM2007/UBICOMM2007.pdf.

[Laforest et al. 1996] Frédérique Laforest, Stéphane Frénot et AndréFlory, « A new approach for Hypermedia Medical Records Management »,13th Int Congress Medical Informatics Europe (MIE’96), p. 1042–1046, Co-penhagen, Danemark, 19-22 August 1996. 1.2.2

BIBLIOGRAPHIE 5

[Laforest et al. 1998] Frédérique Laforest, Stéphane Frénot et AndréFlory, « A Hypermedia-based Medical Records Management System »,MedInfo’98, Seoul, Korea, August 1998. 1.2.2

[Parrend et al. 2007] Pierre Parrend, Samuel Galice, Stéphane Fré-not et Stéphane Ubeda, « Identity-Based Cryptosystems for EnhancedDeployment of OSGi Bundles », SECUREWARE’2007, Valencia, Spain,14-20 october 2007. 1.2.2.3, 2, 2.3

[Parrend et Frénot 2006] Pierre Parrend et Stéphane Frénot, « A Secu-rity Analysis for Home Gateway Architectures », International Conferenceon Cryptography, Coding and Information Security, CCIS 2006, November24-26, Venice, Italy, 2006. 1.2.2.3

[Royon et al. 2006] Yvan Royon, Stéphane Frénot et Frederic LeMouel, « Virtualization of Service Gateways in Multi-provider Envi-ronments », CBSE, Vasteras, Stockholm, Sweden, 29/06-01/07 2006,http\mskip\medmuskip//perso.citi.insa-lyon.fr/yroyon/files/royonCBSE06virtualization.pdf. 1.2.2.3, 2, 2.4

[Royon et al. 2007] Yvan Royon, Pierre Parrend, Stéphane Frénot,Serafeim Papastefanos, Humberto Abdelnur et Dirk Van de Poel,« Multi-service, Multi-protocol Management for Residential Gateways »,BroadBand Europe, Antwerp, Belgium, december 2007. 1.2.2.3

1.2.1.3 Journaux nationaux

[Ben Hamida et al. 2008] Amira Ben Hamida, Frédéric Le Mouël, Sté-phane Frénot et Mohamed Ben Ahmed, « Une approche pour unchargement contextuel de services dans les environnements pervasifs », Re-vue Ingénierie des systèmes d’information, p. 59–84, vol. 3, 2008.

[Laforest et al. 2002] Frederique Laforest, Stéphane Frénot etNada Al Masri, « Dossier médical semi-structuré pour des interfaces desaisie multi-modales », Revue Documents numériques, vol. 6, n 1-2, 2002,Numéro spécial "Les Dossiers numériques".

1.2.1.4 Conférences nationales avec comités de lecture

[Al Masri et Frénot 2002] Nada Al Masri et Stéphane Frénot, « Instru-mentation dynamique d’applications à base d’EJB », Journées Composants,Grenoble, France, October 2002. 1.2.2.3

[Ben Hamida et al. 2008] Amira Ben Hamida, Frédéric Le Mouël, Mo-hamed Ben Ahmed et Stéphane Frénot, « Chargement Contextuel deservices par coloration de graphes de dépendances », Notere, Lyon, 23-27June 2008.

[Delestre et al. 2002] Nicolas Delestre, Stéphane Frénot, StéphaneMottelet et Michel Vayssade, « Distributed PolyTeXML : Une nou-velle plate-forme de partage d’items didactiques », TICE’2002, Lyon,France, 2002.

BIBLIOGRAPHIE 6

[Frénot et Avin-Sotres 2001] Stéphane Frénot et Miguel Avin-Sotres,« Migration et Déploiement automatique de services », Journées Compo-sants (JC’2001), Besançon, France, 2001. 1.2.2.3

[Frénot et Laforest 1998] Stéphane Frénot et Frédérique Laforest,« Un système de gestion d’architextes », Congrès INFORSID 1998, Mont-pellier, France, mai 1998. 1.2.2

[Frénot et Laforest 2001] S. Frénot et F. Laforest, « ToutoPhone : fournirdes services de haut niveau sur le téléphone », MS3G’2001 Colloque sur’Mobiles-services et réseaux mobiles de 3ème Génération, Lyon, France,2001.

[Frénot et Stefan 2004a] Stéphane Frénot et Dan Stefan, « Instrumen-tation de plates-formes de services ouvertes - Gestion JMX sur OSGi »,UbiMob, Nice, France, 1-3 juin 2004. 1.2.2.3

[Frénot et Stefan 2004b] Stéphane Frénot et Dan Stefan, « M-OSGi :Une plate-forme répartie de services », Notere, Saïdia, Maroc, 26-29juin 2004, http://perso.citi.insa-lyon.fr/sfrenot/publications/SFR-DST-Notere2004.pdf. 1.2.2.3

[Frénot 2004] Stéphane Frénot, « Gestion du déploiement de composantssur réseau P2P », DECOR, Grenoble, 28-29 october 2004. 1.2.2.3

[Gorce et al. 2001] Jean-Marie Gorce, Stéphane Frénot, VirginieCrespo et Stéphane Ubéda, « Modélisation de la propagation en en-vironnement INDOOR dans la bande de fréquence UHF », ICISP, Agadir,Maroc, 2001.

[Ibrahim et al. 2006] Noha Ibrahim, Frédéric Le Mouël et StéphaneFrénot, « Intégration négociée de services dans les systèmes distribués »,Journées Composants (JC’2006), Perpignan, France, October 2006.

[Le Mouël et al. 2005] Frédéric Le Mouël, Noha Ibrahim et StéphaneFrénot, « Interface Matching and Combining Techniques for ServicesIntegration », 3er Congresco Nacional de Ciencias de la Computacion, FCC-BUAP, Puebla, Mexico, 2005.

[Royon et al. 2005] Yvan Royon, Stéphane Frénot et Antoine Frabou-let, « Mynus : une pile réseau dynamique », Journées Composants, LeCroisic, France, 5-8 avril 2005. 1.2.2.3

[Royon et Frénot 2006a] Yvan Royon et Stéphane Frénot, « Architec-ture de gestion de passerelles domestiques de services », GRES, Bordeaux,France, 9-12 mai 2006. 1.2.2.3

[Royon et Frénot 2006b] Yvan Royon et Stéphane Frénot, « Un environ-nement multi-utilisateurs orienté service », CFSE’2006, Perpignan, France,October 2006. 1.2.2.3

1.2.1.5 Workshops

BIBLIOGRAPHIE 7

[Ben Hamida et al. 2007] Amira Ben Hamida, Frédéric Le Mouël, Sté-phane Frénot et Mohamed Ben Ahmed, « Approche pour unchargement contextuel de services sur des dispositifs contraints », 6èmeatelier sur les Objets, Composants et Modèles dans l’ingénierie desSystèmes d’Information (OCM-SI’2007) at INFORSID, Perros-Guirec,France, May 2007, http://www.le-mouel.net/Research/Publications/Workshops/2007/OCM-SI2007/OCM-SI2007.pdf.

[Frénot et Balan 2003] Stéphane Frénot et Tudor Balan, « A CPU Re-source Consumption Prediction Mechanism for EJB deployment on a fe-deration of servers », Workshop on Benchmarking at OOPSLA, Anaheim,CA, USA, 2003. 1.2.2.3

[Frénot 2003a] Stéphane Frénot, « JMX Management », Fractal Workshopat ObjectWeb Consortium meeting, Inria, Grenoble, France, 2003.

[Frénot 2003b] Stéphane Frénot, « System auto-configuration on top ofOSGi », Architecture Meeting at ObjectWeb Consortium, lip6, Paris, 1-2juillet 2003. 1.2.2.3

[Ibrahim et al. 2005] Noha Ibrahim, Frédéric Le Mouël et StéphaneFrénot, « Automatic Negotiated Integration of Services in Pervasive En-vironments », Middleware for Web Services Workshop (MWS 2005), En-schede, The Netherlands, 19 September 2005, http://citi.insa-lyon.fr/~sfrenot/publications/MWS2005_ibrahim_lemouel_frenot.pdf.

[Ibrahim et al. 2006] Noha Ibrahim, Frédéric Le Mouël et StéphaneFrénot, « Techniques d’intégration de services dans les environnementsdistribués », Actes du 7 ème atelier sur les Objets, Composants et Modèlesdans l’ingénierie des Systèmes d’Information (OCM-SI’2006) at INFOR-SID, Hammamet, Tunisie, May 2006.

[Le Mouël et al. 2006] Frédéric Le Mouël, Noha Ibrahim, Yvan Royonet Stéphane Frénot, « Semantic Deployment of Services in PervasiveEnvironments », RSPSI workhop at Pervasive 2006, LNCS 4063, p. 385–392, dublin, Ireland, 7-10 may 2006.

[Parrend et Frénot 2007] Pierre Parrend et Stéphane Frénot, « Suppor-ting the Secure Deployment of OSGi Bundles », First IEEE Workshop onAdaptive and DependAble Mission- and bUsiness-critical mobile Systems(ADAMUS) at WoWMoM, Helsinki, Iceland, 18 june 2007. 1.2.2.3

[Parrend et Frénot 2008] Pierre Parrend et Stéphane Frénot,« Component-based Access Control : Secure Software Compositionthrough Static Analysis », 7th Symposium on Software Composition(SC’2008) at ETAPS, 2008.

1.2.1.6 Rapports techniques

[Al Masri et Frénot 2002] Nada Al Masri et Stéphane Frénot, Dynamicinstrumentation for the management of EJB-based applications, TechnicalReport n 4481, INRIA Rhône-Alpes, 2002. 1.2.2.3

BIBLIOGRAPHIE 8

[Fleury et Frénot 2003] Eric Fleury et Stéphane Frénot, Building aJMX management interface inside OSGi, Technical Report n 5025, INRIARhône-Alpes, 2003. 1.2.2.1, 1.2.2.3

[Frénot et al. 2002] Stéphane Frénot, Miguel Avin-Sotres et Nada Al-Masri, EJB Components Migration Service and Automatic Deployment,Technical Report n 4480, INRIA Rhône-Alpes, 2002. 1.2.2.3

[Parrend et Frénot 2006] Pierre Parrend et Stéphane Frénot, SecureComponent Deployment in the OSGi Release 4 Platform, Technical Reportn 0323, INRIA Rhône-Alpes, 2006. 1.2.2.3

[Parrend et Frénot 2007] Pierre Parrend et Stéphane Frénot, Java Com-ponents Vulnerabilities - An Experimental Classification Targeted at theOSGi Platform, Technical Report n 6231, INRIA Rhône-Alpes, 2007. 1.2.2.3

[Royon et al. 2004] Yvan Royon, Stéphane Frénot et Antoine Frabou-let, Approche orientée composant d’une pile réseau, Technical Reportn 0298, INRIA Rhône-Alpes, 07 2004, https ://hal.inria.fr/inria-00069882.1.2.2.3

[Royon et Frénot 2007] Yvan Royon et Stéphane Frénot, A Survey of UnixInit Schemes, Technical Report n 0338, INRIA Rhône-Alpes, June 2007,https ://hal.inria.fr/inria-00155663.

1.2.1.7 Autres publications

[Al Masri et Frénot 2002] Nada Al Masri et Stéphane Frénot, « Unifiedand Automatic Enterprise JavaBeans Instrumentation », Poster at DOA,Irvine, CA, USA, Dec 2002. 1.2.2.3

[Festor et D’Haeseleer 2006] Olivier Festor et Sam D’Haeseleer, Speci-fication of Residential Gateway configuration, MUSE IST-6thFP-026442,public deliverable, DB4.3, november 2006.

[Frénot et al. 2003] Stéphane Frénot, Anis Krichen et Stéphane Ubéda,« Light Support for Dynamic and Pervasive Services on P2P Networks »,Ercim news No. 54, juille, 2003.

[Frénot et Laforest 1998] Stéphane Frénot et Frédérique Laforest,« Modélisation du dossier médical multimédia distribué », Carrefours dela fondation Rhône-Alpes futur, Lyon, France, septembre 1998, (2nd prixde la fondation). 1.2.2

[Frénot et Papastefanos 2008] Stéphane Frénot et Serafeim Papastefa-nos, Virtual Machines for Embedded Environments, MUSE IST-6thFP-026442, public deliverable, DB3.6, january 2008, http://www.ist-muse.org/Abstracts/abstract_DB3.6.htm.

[Frénot 2005] Stéphane Frénot, Open Management Using OSGi Tech-nology Enabled Services, OSGi world Congress, developper session,October 2005, http://ares.insa-lyon.fr/~sfrenot/publications/INRIA-ARES-OSGi.pdf.

BIBLIOGRAPHIE 9

[Le Mouël et Frénot 2006] Frédéric Le Mouël et Stéphane Frénot (éd.),1st IEEE International Workshop on Services Integration in PervasiveEnvironments at ICPS, Lyon, France, IEEE Press, June 2006, http://ares.insa-lyon.fr/sipe06/.

[Le Mouël et Frénot 2007] Frédéric Le Mouël et Stéphane Frénot (éd.),2nd IEEE International Workshop on Services Integration in Pervasive En-vironments (SIPE’2007) at ICPS, Istambul, Turkey, IEEE Press, July 2007,http://ares.insa-lyon.fr/sipe07/.

[Parrend et Frénot 2006] Pierre Parrend et Stéphane Frénot, « Depen-dability for Component Systems Deployment », Poster at EuroSys Confe-rence, Leuven, Belgium, 18-21 April 2006. 1.2.2.3

[Projet DARTS 2002] Projet DARTS, Déploiement et Administration deRessources, Traitements et Services, http://darts.insa-lyon.fr/index.html.en, 2002. 1.2.2

1.2.2 Activités de recherchePendant ma thèse, j’ai travaillé sur les systèmes d’information médicauxhospitaliers. Au début de mes travaux, les interfaces utilisateurs de systèmeslarge échelle1 étaient principalement des interfaces X11 ou windows. J’ai proposéau moment des balbutiements du Web d’avoir une approche orientée documen-taire pour la gestion de l’information médicale. Cette approche documentairerepose sur une architecture Web anticipant de deux années les architecturesactuelles. J’ai défini le principe d’architexte pour la gestion des informationsmédicales. Un architexte est une collection d’extraits documentaires qui repré-sentent l’intégralité du dossier médical s’ils sont regroupés. J’ai également dé-veloppé l’architecture de gestion des architexte pour l’entreprise Al’X durantma CIFRE. Cette activité s’est arrêtée lorsque Bull SA, qui commercialisait leproduit a revendu sa branche santé à une entreprise spécialisée dans le domainemédical Escare SA.

Ces travaux ont été présentés dans diverses publications : dans un journal in-ternational [Frénot et Laforest 1999], en conférences internationales [Laforest et al. 1996,Laforest et al. 1998, Frénot et al. 1995], en conférences nationales [Frénot et Laforest 1998]ainsi que dans des présentations locales comme [Frénot et Laforest 1998].

Pendant cette période, 1994-1997, j’ai développé en C++, Java et Perl ainsique dans de nombreuses architectures orientées Web. Notre approche à base deserveurs d’objets C++ étaient les précurseurs des architectures J2EE à base deJava qui allaient sortir un ou deux ans après. De notre point de vue l’architec-ture d’architexte correspond parfaitement à la tendance du Web2.0 qui est unereconstitution au niveau du client de consultation d’un ensemble de donnéesissues de plusieurs sources. Le client Web se comporte alors comme un point deconvergence local de l’information spécifique désirée par l’utilisateur.

1au sens grand hôpital ou centres hospitaliers comme les hospices civiles de Lyon

BIBLIOGRAPHIE 10

Après ma thèse, j’ai participé à la création du laboratoire CITI, au montagedu département Télécommunications Services et Usages2 ainsi qu’à deux équipesde recherche INRIA, ARES et AMAZONES.

J’ai changé d’activité à ce moment en laissant de côté l’activité médicale eten me recentrant sur le domaine fonctionnel des composants. Les approches àcomposants visées étant focalisés sur la conception d’intergiciels pour systèmesdynamique et mobiles.

Les applications courantes nécessitent de nouvelles infrastructures pour gérerla distribution, la dynamique, l’intégration autonome de nouveaux services etde nombreuses activités de haut niveau qui ne sont pas ou peu prises en chargepar les les couches “classiques” des systèmes d’exploitation. Mon défi est deconcevoir et d’implanter de nouveaux intergiciels, ou systèmes d’exploitationglobaux intégrant ces nouveaux besoins.

J’ai initialement travaillé dans le cadre de l’architecture J2EE afin de pro-poser une administration d’une fédération de serveurs d’applications. Les dif-férents noeuds partagent l’exécution des EJB et nous pouvons faire migrer desEJB entre noeuds durant l’exécution. Le système que nous avons conçu intègreune description des ressources liées aux EJB afin de planifier leur déploiementet leur exécution. Ce travail a été partiellement réalisé dans le cadre du projetDARTS, Déploiement et Administration de Ressources, Traitements et Services.Le projet DARTS [Projet DARTS 2002] est une ACI de 2 ans.

DARTS est focalisé sur les approches pour la grille de calcul, qui est unethématique un peu éloignée des activités du laboratoire CITI. Le problème ma-jeur est la taille croissante des architectures J2EE qui devenait de plus en pluscomplexe à intégrer dans de petits environnement sans-fils. Je me suis réorientésur des environnements plus embarqués, petits et ambiants. J’ai étudié les pro-positions industrielles et académiques et me suis recentré sur la spécificationOSGi dès les premières sorties. J’ai alors recentré le travail de l’équipe autourde cette activité.

Mon activité autour du framework OSGi porte sur 3 axes :– Implantation de certaines spécifications– Dissémination et enseignements autour de cette technologie– Conception d’extensions non-fonctionnelles à la plate-forme

1.2.2.1 Implantations intégrées à la communauté

La spécification OSGi est implantée par plusieurs solutions open-sources,Felix, Equinox et Knopflerish. Cependant aucune d’entre elle n’implantel’intégralité de la spécification. J’ai fourni à la communauté Felix une extensionpour la supervision de passerelles OSGi ainsi qu’une implantation de la partiedécouverte automatique de services [Fleury et Frénot 2003].

2à partir de la seconde promotion entrante

BIBLIOGRAPHIE 11

1.2.2.2 Dissémination et enseignements

Depuis que j’utilise cette technologie, je suis convaincu des avantages sub-stantiels qu’elle apporte dans le domaine du génie logiciel. J’ai monté en consé-quent des cours autour. J’ai présenté le framework au équipes de développementsde Motorola Toulouse en 2002, ainsi que dans diverses écoles et tutoriauxpour chercheurs (Ecotel’2002, Notere’2004, ING’2005, OSGi’2007, BBE’2007).J’interviens également dans des cours d’étudiants de cycle d’ingénieur et de Mas-ter recherche ; Département Télécommunication de l’INSA de Lyon dans uneoption de 4ème année, à l’ENSEIRB de Bordeaux ainsi qu’à CPE de Lyon.

1.2.2.3 Conception d’extensions non-fonctionnelles à OSGi

En dernier point, mon activité la plus important a été de proposer diversesextensions au framework OSGi. J’ai conçu et développé les extensions dans lesdomaines suivants :

– Administration : comment géré au mieux les passerelles (MOSGi et VOSGi)– Sécurité : comment garantir la sécurité des composants (SOSGi)– Embarquement : comment embarqué OSGi dans des environnements ré-

duits (ROCS)– Intégration du contexte : comment réagir aux modifications de l’environ-

nement (POSGi, ANIs)Le tableau 1.2 représente une synthèse des projets, des personnes qui y ontparticipé et de leur rôle. Il représente également les publications associées àchaque projet et les financements associés.

BIBLIOGRAPHIE 12

Pro

ject

,publica

tion

sT

hem

ePar

tici

pan

tFu

ndin

gs

DARTS

Dévelop

pementprincipa

lNad

aAlM

asri

(PhD

Stud

ent)

DARTS

ACI

(99-20

02)

[Brebn

eret

al.2

005],[Frénot

etStefan

2004

b],[AlM

asri

etFrénot

2002

]EJB

Migration

MiguelA

vinSo

tres

(MasterStud

ent)

[Fréno

tet

Stefan

2004

a],[Frénot

etBalan

2003

],[Fréno

tet

al.2

002]

RMIEvaluation

Tud

orBalan

(MasterStud

ent)

[AlM

asri

etFrénot

2002

],[A

lMasri

etFrénot

2002

],[Fleuryet

Frénot

2003

],[Fréno

tet

Avin-So

tres

2001

]Distributed

OSG

iDan

Stefan

(AssociatedEng

ineer)

POSG

iP2P

Bun

dledistribu

tion

Dan

Stefan

(Associate

Eng

ineer)

[Fréno

tet

Royon

2005

],[Fréno

t20

04],[Fréno

t20

03b]

Tarek

Tuu

rki(MasterStud

ent)

VOSG

iVirtual

OSG

iYvanRoyon

(PhD

Stud

ent)

MUSE

[Royon

etal.2

006],

[Royon

etFrénot

2006

b],

[Royon

etFrénot

2006

a],

[Royon

etal.2

005],[Royon

etal.2

004]

Denis

Beras

(Associate

Eng

ineer)

SOSG

iSecuredOSG

iPierreParrend

(PhD

Stud

ent)

MUSE

II[Parrend

etFrénot

2007

],[Parrend

etFrénot

2006],

[Parrend

etFrénot

2006

],[Parrend

etFrénot

2007

],[Parrend

etFrénot

2006

],[Parrend

etal.2

007]

Mathieu

Cha

ntrel(Associate

Eng

ineer)

MOSG

iMan

aged

OSG

iYvanRoyon

(PhD

Stud

ent)

MUSE

[Royon

etFrénot

2007

],[Fréno

tet

al.2

008],[Royon

etal.2

007]

Denis

Beras

(Associate

Eng

ineer)

Tab. 1.2 – Synthèse des projets de recherche

BIBLIOGRAPHIE 13

1.2.3 EncadrementsJe suis responsable de l’équipe Middleware du CITI. Elle est composée de

2 maîtres de conférences 5 étudiants en thèse, 2 ingénieurs et de quelques étu-diants de passage. J’organise une fois par mois des réunions de travail ou chaquepersonne présente son activité.

1.2.3.1 Co-Encadrement de thèse

Je co-encadre des thèses 1.3 depuis que j’ai été recruté et je suis co-auteursde l’ensemble des publications des étudiants.

Date de sou-tenance Etudiant Situation actuelle

Mar 01 Nada Al Masri Professeur Associée, University ofWaterloo (Canada)"Modèle d’Administra-

tion des Systèmes Dis-tribués à Base de Com-posants"

Déc 07 Yvan Royon Qualifié 27 et finissant un contratd’ATER"Environnements

d’exécution pour pas-serelles domestiques"

en cours Etudiant Date de soutenance prévue

Sept 05 Pierre Parrend Déc 2008"Sécurité des ap-proches à composants"

Tab. 1.3 – Encadrement de thèses

1.2.3.2 Encadrement de Master recherche

Les masters encadrés ont creusé certaines idées des projets. Yvan Royonet Nada Al Masri ont continué en thèse. Le tableau 1.4 indique la liste des 8masters en informatique que j’ai encadré.

BIBLIOGRAPHIE 14

Année Etudiant Mots clés2005 Tarek Tuurki P2P, OSGi2004 Radu Popa Grid, Globus, OSGi2004 Yvan Royon Componenent, TPC/IP2003 Tudor Balan RMI, Perfomance2003 Anis Krichen OSGi, Deployment

2001 ChristopheDeVaux-Bidon QoS, EJB

2000 Miguel Avin Sotres Naming, EJB1999 Nada Al Masri EJB, Monitoring

Tab. 1.4 – Masters recherche

1.2.3.3 Ingénieurs Associés

Sur les supports budgétaires de DARTS, MUSE et MUSE II j’ai embauchésur contrat 3 ingénieurs associés 1.5. Ils ont fournit un travail de documentationet de supervision de la qualité du code développé.

Year Engineer Project, Keywords2007-2008 Mathieu Chantrel INRIA funding, UPnP

2005-2008 Denis Beras MUSE, Management, Security

2003-2004 Dan Stefan DARTS, OSGi, Distribution

Tab. 1.5 – Ingénieurs associés

1.2.3.4 Autres encadrements

J’ai encadré de nombreux étudiants de stage et en projet de fin d’études. Letableau 1.6 en donne la liste.

BIBLIOGRAPHIE 15

Year Student Student origin Keyword

2008 Stéphane Chevali CPE Interposition de code detrace

2007 Martin Schlienger, Xiaotian Li INSA Telecom Java ClassLoader2006 Yoann Duclaux, Cyril Ganier INSA Telecom P2P ClassLoader

2006 Benoit Prat, Arnaud Dumont CPE Java Class DependenciesStudy

2005 Hayder Bassem INSAT Tunis Java Class DependenciesTool

2005 Nemeth Annamaria Feroiu Lyon University P2P for OSGi

2005 Baptiste Decroix CPE Embedded virtual Ma-chine

2005 Baptiste Decroix, Mathias Bert-schy CPE Avalon, Nano|Pico

Container2O05 Aurelien Laurendon INSA Telecom TCP/IP extension2004 Oscar Bigu University of Catalugnia UPnP, OSGi2004 Gilles Erwan INSA Telecom Embedding java2004 Khaled Yousfi, Riadh ben Hariz CPE JMX management2004 Djibril Kone IMAG Grenoble JMX management

Tab. 1.6 – Autres encadrements

1.2.4 Dissémination1.2.4.1 Edition de proceedings

Je suis co-éditeur de deux proceedings du workshop SIPE.– F. Le Mouël and S. Frénot, Proceedings of the 2nd IEEE International

Workshop on Services Integration in Pervasive Environments (SIPE’2007)– F. Le Mouël and S. Frénot, Proceedings of the 1st IEEE International

Workshop on Services Integration in Pervasive Environments (SIPE’2006)

1.2.4.2 Comité de programme

Je suis membre du comité de programme de 3 conférences internationales,d’une conférence nationale et de 3 workshops internationaux. Je suis égalementreviewer dans 2 journaux internationaux Oxford Journal et le journal koréenETRI.

– Journaux– Oxford Computer Journal– ETRI Journal

– Conférences Internationales– 11th IFIP/IEEE Network Operations and Management Symposium (NOMS2008)

– 10th IFIP/IEEE International Symposium on Integrated Network Ma-nagement (IM 2007)

BIBLIOGRAPHIE 16

– 6th International Conference on Software Engineering Research, Mana-gement and Applications (SERA 2008)

– Workshops Internationaux– 19th IFIP/IEEE International Workshop on Distributed Systems : Ope-rations and Management 2008 (DSOM 2008)

– 2nd International workshop on Adaptive and DependAble Mobile Ubi-quitous Systems (ADAMUS 2008 - WoWMoM 2008)

– 1st IEEE WoWMoM Workshop on Adaptive and DependAble Mission-and bUsiness-critical mobile Systems (ADAMUS 2007 - WoWMoM 2007)

– Conférence nationale– Nouvelles technologies de la répartition (Notere) - 2005, 2006, 2007,2008

1.2.5 FinancementsJ’ai participé à un projet européen MUSE I, qui a été reconduit en MUSE

II, sur une durée de 4 ans. Sur la phase II j’étais le représentant INRIA sur leprojet. J’ai piloté l’ACI DARTS, et je participe aux projets LISE et SVP. Letableau 1.7 résume ces informations. La suite de cette section explique ce qui aété fait dans chaque projet.

Years Acronym Role Funds provider

01-03 DARTS Leader for the project (2 labteams)

ACI French Ministry ofResearch

03-05 MUSE I Participant European project

05-07 MUSE II INRIA representative andparticipant European project

06-08 SVP Participant RNRT French Minis-try of Research

08-10 LISE Participant ANR French Ministryof Research

Tab. 1.7 – Contrats

2001-2003 DART ACI GRID3 Titre : Déploiement et Administration deRessources Traitements et ServicesResponsabilité : Responsable du projet impliquant deux équipes dans deuxlaboratoiresPartenaires : LISI (LIRIS)

3http://darts.insa-lyon.fr/index.html.fr

BIBLIOGRAPHIE 17

Description : DARTS a pour objectif de définir une architecture de déploie-ment et d’administration de services pour la grille. Les calculs sont distribuéssur un réseau hétérogène de périphériques. Chaque périphérique déclare ses dis-ponibilités et ses ressources. Un ordonnanceur déploie les calculs sur les noeudsdisponibles. Nous utilisons la technologie OSGi pour administrer les différentsnoeuds. Chaque calcul est emballé dans un bundle OSGi déclarant le servicecorrespondant. L’autre équipe de recherche s’est intéressée sur l’aspect de ladonnée dans ce contexte. Ils ont essayé de proposer une mise en oeuvre du tool-kit Globus v3 au dessus d’OSGi. Le projet a démontrer les bonnes potentialitésd’OSGi pour le contexte d’utilisation dans la grille.

2003-2007 MUSE I and II , projet européen du FP6 de type IP4

Titre : MUlti-AcceSs EverywhereResponsabilité : Participant au projet et Représentant de l’INRIA en phaseII. Dans le workpackage spécifique, nous avons collaboré avec Thomson, STMicroElectronics et NTUA 5 en Grèce.Partenaires : MUSE est un projet intégré qui regroupe une 60aine de parte-naires6.Description : Le projet a pour objectif la conception des réseaux de livraisonde services ADSL pour 2010. Le projet couvre toute la chaîne économique dufournisseur de service à la passerelle domestique. Dans notre workpackage, noussommes focalisé sur la spécification d’une passerelle de service au niveau maté-riel d’une part et au niveau système d’exploitation d’autre part. Notre expertised’OSGi nous a permis de faire des test d’Intégration dans des architectures in-dustrielles telles que proposé par Thomson. Nous avons proposé dans le projetles extensions présentées dans ce mémoire afin de participer à l’élaboration dumodèle économique multi-services, multi-fournisseurs préconisé.Fonds : MUSE nous a permis de financer une thèse de doctorat sur 3 ans et 1ingénieur de recherche sur les 2 phases du projet.

2006-2008 SVP, projet RNRT7 Titre : SurVeiller et PrévenirResponsabilités : Responsable de 2 livrablesPartenaires : CEA - Leti, INRIA - Projets ARES, ASAP, POPS,R2D2, LPBEM, EA 1274, LIP6, APHYCARE Technologies, THALES,ANACT, Institut Maupertuis8

Description : Le projet SVP propose l’étude, la réalisation et l’expérimenta-tion d’une architecture ambiante intégrée pour faciliter la conception, le déploie-ment et l’exploitation optimale de services de surveillance et de prévention surdifférents types de réseaux dynamiques.

4http://www.ist-muse.org/5National Technical University of Athens6http://www.ist-muse.org/partners.html7http://svp.irisa.fr/8http://svp.irisa.fr/partenaires.htm

BIBLIOGRAPHIE 18

2008-2010 LISE, projet ANR9 Titre : Liability Issues In Software Engi-neeringResponsabilités : ParticipantPartenaires : INRIA (Lyon, Grenoble), LIG (Grenoble), SUPELEC (Paris),DANTE (University of Versailles), PRINT (University of Caen)Description : Le projet cherche à garantir les traces générées par des passe-relles de service sécurisées. Quand survient un crash la cause doit pouvoir êtreidentifiée de manière univoque.

1.3 Responsabilités administrativesLors de mon recrutement en 1999 il a fallut participer au montage à la fois

du département télécommunications services et usage et du laboratoire de re-cherche CITI. Mes responsabilités administratives ont étés et sont toujours assezimportantes dans les trois domaines de notre métiers : recherche, enseignementet gestion administrative et technique.

Je suis membre élu de la commission de spécialiste INSA 27 depuis 4 ans.J’ai initialement défini et monté l’intégralité du système d’information du

département d’enseignement. A savoir les salles machines, la salle serveur, lesintranets et les extranet du département. J’ai mis en place ces tâches avant quele département n’ai suffisamment de personnel à mettre en place.

La liste suivante résume mes activités administratives.– Au niveau INSA

– Membre élu de la commission de spécialistes 27– Au laboratoire CITI

– Co-fondateur du laboratoire– Responsable de l’équipe middleware du projet INRIA Ares (2003-2007)– Responsable de l’équipe middleware du projet INRIA Amazones (2008-)

– Au département Télécommunications services et usages– Construction des cours à partir de la 2nd promotion entrante– Membre du conseil de département de 1998 à 2001– Responsable et concepteur des projets Innovant de la formation

– Environnement technique– Responsable pendant 3ans du système d’information du département– Administration et développement des applications de l’intranet du dé-partement : emploi du temps, gestion des contacts industriel, des outilsde réservation, des pages d’information internes

1.4 EnseignementsDurant ma thèse, ma convention CIFRE ne m’a pas permis d’avoir un gros

volume d’enseignement initial. Mais j’enseignais dès 1995 des technologies enavance de phase comme le Web, Java et les intergiciels.

9http://tinyurl.com/4l8j57

BIBLIOGRAPHIE 19

En tant que maître de conférences d’un nouveau département d’enseigne-ment j’ai dû monter un certain nombre de cours. TCP/IP, Middleware, Sécurité,Programmation Java, Génie logiciel. J’ai monté les cours magistraux, les tra-vaux dirigés et les séances de travaux pratiques. Je réalise également quelquesinterventions autour d’OSGi, des systèmes pairs-à-pairs, des approches à com-posants, de la programmation agile.

1.5 Geek attitudeJe suis programmeur depuis l’âge de 14 ans. J’ai essayé la programmation

dans de nombreux langages, Basic, Lisp, Fortran, Perl, Shell, C, C++,Java, Ruby, Caml, Python. J’essaye de m’auto-former sur un langage tousles ans. Je suis très intéressé par la théorie des langages et leur évolution mêmesi ce n’est pas nécessairement le coeur de ma recherche.

J’ai également géré et largement étudié la majorité des systèmes d’exploita-tion modernes principalement Unix (Aix, HP/ux, Solaris, SunOs, Linux,NT, XP, uclinux) sur les différents environnements de travail sur lesquelsj’ai travaillé. Je suis utilisateur de Linux depuis 1994 et j’ai utilisé un certainnombre de distributions depuis (Slackware, Redhat, Debian et maintenantGentoo). J’interviens dans un cours sur les systèmes d’exploitation pour parlerde l’historique des systèmes, ainsi qu’en formation du premier cycle INSA pourmotiver les étudiants aux réseaux et aux systèmes. J’ai une bibliothèque per-sonnelle de 250 livres d’informatique et assimilés. Je suis abonné à Dr. Dobbsmagazine depuis 15 ans, à wired depuis 7 ans. Mes compétences techniques etma flamme pour la transmission des compétences techniques sont parmi mespoints forts.

Chapitre 2

Selection

Voici une sélection d’un article par projet.– MUSE : [Royon et Frénot 2007]– MOSGi : [Frénot et al. 2008]– SOSGi : [Parrend et al. 2007]– VOSGi : [Royon et al. 2006]– POSGi : [Frénot et Royon 2005]– DARTS : [Brebner et al. 2005]

20

CHAPITRE 2. SELECTION 21

2.1 Projet MUSE [Royon et Frénot 2007]Yvan Royon and Stéphane Frénot

Multiservice Home Gateways : Business Model, Execution Environ-ment, Management InfrastructureIn IEEE Communications Magazine, pages 122–128, 2007.

Multi-Service Home Gateways: Business Model,Execution Environment, Management Infrastructure

Yvan Royon and Stephane Frenot, INRIA Ares / CITI, INSA-Lyon, F-69621, France

Abstract— The Home Gateway market is undergoing deepchanges. On one side, home networks are evolving, gettingdynamic and federating more and more devices. On the WANside, new actors appear, such as multimedia content providers.From both sides emerge new features and new managementneeds.

In this article, we highlight challenges and benefits of movingmore intelligence to the Home Gateway, making it more thana simple interconnection device. We argue that we need a full-fledged execution environment on gateways, to address the evolu-tion of business models. We present this evolution and summarizeexisting solutions for execution environments and managementfor Home Gateways. Then, we propose two improvements thatreflect the new requirements. The first improvement is a high-level virtualization of service gateways, and the second onerecommends an end-to-end dynamic multi-provider managementsystem.

I. I NTRODUCTION

During the last years, the Home Gateway market hasevolved at a very fast pace. For a time, it only consisted inbringing IP connectivity to the home. Available services werecommon application-level programs, such as Web or e-mailclients. Today, operators are moving to integrate value-addedservices. Multicast TV and Voice over IP services are largelyadvertised; their integration with data transport is referred to astriple play. These three network-enabled services are providedeither through the same connectivity box (the modem) orthrough a dedicated set-top box.

In the close future, operators plan to open the servicedelivery chain1. The roles currently assumed by theInternet Access Provider will be split between connectivityprovisioning and service provisioning. Instead of being tiedto a single service provider for television and phone over IP,the end-user will have a variety of choices and will gain fromcompetition, both in price and diversity. This business modelis referred to asmulti-play.

A model with multiple actors outlines new challenges. TheHome Gateway hosts a set of configurable services, whichcan be operated, controlled or monitored by different ServiceProviders. However, these important issues are not sufficientto get the full picture. Indeed, voice and video are not theonly services that can be of interest for home users: domotics,entertainment, home security and health care are also potentialmarkets. For a long time these other services have beenconsidered individually, with separate networks, devicesand

1See the MUSE European Project, IST-FP6-507295, which partially sup-ports these works. http://www.ist-muse.org

user control. By integrating them with the home network, newuse cases are possible.

As an example, a network-enabled white good (e.g., anoven or a dishwasher) can be monitored by its manufacturer.In case of failure, for instance if the temperature in a fridgerises above a certain threshold, an alarm would be raised tothe home user and to the nearest repairman. The contentsof a fridge or a wine cellar can also be monitored usingsensors. The home user would input preferences, or orderswould be sent to the nearest retailer. Many current projectsfocus on providing help for seniors or for the disabled athome; these issues are known asquality of life. For instance,the Home Gateway would monitor a pacemaker or similarmedical appliances, and alarms would be forwarded to familymembers and the nearest hospital.

All these examples show that the definition of “service”must be broadened. It should not be limited to networkmultimedia flows, but also include management facilitiesfor in-home devices (configuration, preferences, monitoring),human-machine interfaces, and any kind of application theHome Gateway may host. This paper refers to this extensionas multi-service. We keep this definition open so that futureideas and applications can be seamlessly integrated.

The Home Gateway must undergo changes so that themulti-service model can be implemented. Indeed, home usersshould be able to use in-home devices and set preferencesregardless of the status of the access provider’s network.This means that most home-related settings should be hostedinside the home. In the triple play model, the Home Gatewayalready hosts or uses information and configuration from bothhome users (e.g., WiFi access point settings) and the AccessProvider (e.g., last mile settings). Therefore, it seems a naturalchoice to enhance Home Gateways to be multi-service ready.

Our goal in this paper is to provide mechanisms for multi-service enhancements, which target both the OS layer and themanagement plane. Figure 1 shows a management perspectiveof the multi-service home environment. Three “realms” inter-act around home gateways. The Access realm is the usualAccess Provider, who provides layer 1-4 connectivity to thegateway. The User realm contains all interactions the end-userand local devices may have with the Home Gateway. Thirdly,the Service Provider realm represents the interactions betweena Service Provider and a service hosted on the gateway.

From an execution layer point of view, these multiplerealms and entities also coexist on the gateway. This meansthat some level of software isolation must be defined.

Fig. 1. Management Realms

The article is structured as follows. Each section focusesboth on the management layer and the execution environment.Section II presents existing solutions related to Home Gate-ways. Section III defines new requirements that result fromthe multi-service model, and the enhancements that must bemade compared to existing solutions. Section IV describes ourtestbed implementation of a multi-service gateway; results aredetailed in section V. Finally, section VI concludes the article.

II. OVERVIEW OF EXISTING HOME GATEWAY

ENVIRONMENTS

New business models bring new technical requirements.With the connectivity-only model, an Auto-ConfigurationServer (ACS) provides layer 1-4 parameters to the HomeGateway (e.g., DHCP). There is only one ACS, hosted by theAccess Provider. With the triple play model, the ACS muststore additional intelligence and parameters related to voiceand video subscriptions. Moreover, it manages not only theHome Gateway, but also other Customer Premises Equipments(CPE), such as set-top boxes for TV. With the multi-playmodel, there might be more than one ACS. Coherence andaggregation of management activities from different ServiceProviders to one particular Home Gateway become a problem.

With the multi-service model described above, it is clearthat more intelligence must be put inside the Home Gateway,making it a pivotal device in the home network. In this section,we first summarize existing management solutions that evolvearound the Home Gateway. Then, we present a panel ofexecution environments applicable to this particular device.

A. Management Solutions

With the triple play model, home users configure theirgateway and their services through the Access Provider’s Website. However, with the multi-service model, there can be morethan one service provider; the home user may also interact within-home devices, whether the Internet access is active or not.As a result, a single management server, located outside of thehome, is no longer desirable. The solutions that exist for thisproblem can be categorized in two groups: WAN managementprotocols and application / service management protocols.

WAN management protocols are network-centric solutionsthat follow a three-tier architecture: the manager (e.g., anACS), the agent (on the managed device), and the connector(for translation between the former two). Existing manage-ment technologies answer three questions: how the data isstructured, which data is available, and how the agent andthe connector interact. Common examples ares TR-069 fromthe DSL Forum, CIM/WBEM from the IETF, and SNMP.

Application management protocols focus on home devicemanagement, such as service discovery and autonomous ser-vice description. Examples are JMX in the Java world andUPnP.

An implementation of the multi-service model can makeuse of several of these WAN and application managementsolutions. The other side of the story is that the Home Gatewaymust support the management agent, but also other applica-tions, configuration facilities, etc. Such support is provided bythe execution environment.

B. Execution Environments for Home Gateway

With triple play and multi-play business models, HomeGateways are becoming more than just modems: they areresource-constrained computers. Their task is not only tocommute network packets, but also to filter them, to supportmulticast, to be upgradeable, to host application servicesand tosupport user interaction. Two kinds of execution environmentsare popular in academia and industry: GNU/Linux and OSGi.

1) Linux: The obvious trend at the moment is that construc-tors are abandoning proprietary operating systems that used topower their modems, in favour of Linux variants. There areseveral strong advantages.

• Linux exists in different flavours, such as uCLinux, whichmakes it adaptable to new architectures [1], includingresource-constrained environments;

• Source code is open and mainstream, and so is tested bylots of users;

• The programming model is standard C or C++. Findingable developers is very easy;

• It is then trivial to reuse existing applications for net-working (firewalls), multimedia (codecs), or management(agents for various protocols, such as SNMP).

Current operating systems still suffer drawbacks in multi-service environments. Integrating applications from differentproviders, making them work together and ensuring theircorrect behaviour is time consuming. One possible answer isto use type-safe languages and sandboxing techniques. Themobile phone industry went this way with Java. The HomeGateway industry is following the same path with OSGi.

2) OSGi Technology:In its early stages, OSGi was de-signed specifically for open service gateways2. The OSGiservice platform is a container built on top of a Java virtualmachine. It hosts deployment units calledbundles, whichcontain code, other resources (pictures, files), and a specificstart method. A descriptor file expresses dependencies on othersoftware pieces, among other meta-data.

2http://www.osgi.org

The OSGi platform automatically checks and resolves de-pendencies among bundles. It also dynamically controls bun-dles’ life cycle, and enables hot deployment and update. Thissimplifies the administrator’s work and improves stability.

The programming model is Service-Oriented Programming(SOP) [2], which derives from Object-Oriented Programming(OOP). The driving motivation is to minimize coupling amongpieces of software. A service is an interface, or a contract,that describes what a piece of software does. How it isimplemented is hidden internally.

The OSGi specifications keep the management layer open,in the sense that it does not impose a specific managementprotocol or technology. In real-life situations, several technolo-gies can be combined to provide an end-to-end managementsolution [3].

OSGi is getting popular in academia communities, but moreso in industry. For instance, some BMW cars use OSGi fornon-critical tools. Another example is the Eclipse developmentkit, which rebuilt its whole plug-in architecture around anOSGi framework, and most J2EE implementations, which areor plan to be redesigned as OSGi bundles. Actors interested inHome Gateways are also adopting OSGi, through the HomeGateway Initiative (HGI), a telco-driven consortium.

3) HGI: The Home Gateway performs various tasks, fromprotocol translation to QoS enforcement to remote access.Since most of these tasks are dynamic, configurable, manage-able, and can change over time, they should be implementedby updateable software. HGI [4] has defined Operating Systemrequirements for Home Gateways, which are largely based onthe OSGi specifications. They operate on three levels.

The first one is software management. It includes:

• Configuration of software pieces, called “modules”;• Management of their life cycle: install, update, uninstall;• Dynamicity and security enforcement. Modules are reg-

istered and verified; their dependencies are resolved, thenlinked;

• Resets for default configuration parameters, and forfirmware debug in case of low-level failures.

The second level is performance management and diagnos-tics, which include:

• Remote diagnostic tests for hardware and software ele-ments;

• Performance monitoring;• Support for events sent by the gateway.

The third and last level gathers definitions of users inpresence:

• A super-user (the Auto-Configuration Server), in controlof everything that is manageable;

• A local administrator, in control of local management(e.g., firewall, users);

• End-users, with permissions set by the local administra-tor.

Current works on Home Gateways are led by the HGI spec-ifications, the OSGi platform and management technologies.And yet, they lack the integration of the multi-service businessmodel. They still focus on models with a single Access andService Provider, hosting a single ACS. Our goal is to enable

the multi-service model, from both the management layer andthe execution environment points of view. The next sectionlists the requirements for these two issues.

III. R EQUIREMENTS FORMULTI -SERVICE HOME

GATEWAYS

A multi-service Home Gateway hosts various services,applications, etc. from several Service Providers. The fact thatthese Service Providers can be separate entities impacts boththe management layer and the execution environment.

A. Management Requirements

Figure 1 shows that the actors around the Home Gatewayuse the management layer for different purposes. In the multi-service model, management should not be classified accordingto network span (LAN, WAN) or OSI layer (IP, TCP), butaccording to the goals and features of each actor.

For example, a home user will set preferences and configuredevices using UPnP technologies, Flash interfaces, or propri-etary solutions. An Access Provider will configure layer 1-4parameters and manage QoS using TR-069. Service Providersmay prefer JMX or SNMP to monitor their services.

With these examples in mind, we can express managementrequirements as follows:

• Each actor around the gateway (home user, AccessProvider and each Service Provider) can use his owndedicated management agent;

• Technologies used for management agents are heteroge-neous.

These two points allow to isolate management activitiesfrom different actors, in terms of network flows. We must alsoaddress a separation local to the gateway, in terms of runtimeexecution.

B. OS Requirements

HGI requirements work well in a mono-provider scenario,with a single ACS. However, they fall short on several pointsin the case of an open, multi-tier environment. Indeed, dif-ferent Service Providers, potentially competitors, may deploymodules on the same Home Gateway. These modules maycontain code or data that are business-critical, or simply thatgive away information on the client base, configurations, orimplementation performance. They may also contain maliciousor buggy code, which could endanger all modules in presence.

Therefore, the need for isolation among actors present atsoftware level dictates the following additional requirements.

• Definition of users

– Service or Software Providers can be seen as users onthe Home Gateway, similarly to multi-user executionenvironments. These users need a secure authentica-tion phase and a secure session for all activities onthe gateway, such as module deployment;

– A Root user controls users allowed on the system.He also checks the overall resource consumption,and may take coercive measures against users thatthreaten to starve resources.

• Isolation and sharing of modules– Modules from different providers (users) must be

isolated by default, i.e., a user can only see andinteract with his own modules;

– A single instance of some modules may be sharedamong all users on the Home Gateway. This isuseful for libraries (such as codecs), or for commonmodules (such as a Web server).

• Remote access, for management features.• Preferences and configuration can be stored locally, in

the case that they represent private information or arenot related to an ACS.

In this section we described the changes that multi-servicegateways must undergo. The next section shows how weimplemented these changes using OSGi.

IV. A F RAMEWORK IMPLEMENTATION FOR

MULTI -SERVICE HOME GATEWAYS

OSGi offers important features for Home Gateways:service-oriented programming, dynamic life cycle manage-ment, dependency checking. Unfortunately, it lacks conceptsfor the multi-service business model. To enable this model,wepropose improvements on two levels. At the run-time level weimplement a virtualization of the OSGi framework (see [5]);atthe management level we provide an end-to-end, JMX-basedsolution.

A. OSGi Virtualization

Software elements that belong to different providers mustbe separated. In other words, we need some level of runtimeisolation. Various works already exist on this topic, such asBSD jails, Xen, VServer or VMware. They propose differentlevels of enforcement in terms of resource isolation andnamespace isolation, which are a trade-off with performance.

For instance, Xen [6] runs separate copies of a wholeoperating system for each isolated environment. VServer [7]does not duplicate the kernel, but still duplicates inodes onthe filesystem for each isolated environment. A BSD jail willduplicate only a portion of the filesystem, but will not providea strong resource isolation.

In our case, following the multi-service model, the chosenlevel of isolation must still allow to share services ondemand among different Service Providers. This meansthat isolation should be permissive. Moreover, we focusour implementation on Java/OSGi environments. As aconsequence, sharing applies to OSGi services (which areJava interfaces). For scalability reasons, duplicating a wholeJVM for each isolated environment seems overkill. Lastly,a Home Gateway has limited resources; typically 16 MB ofpermanent storage and 64 MB of RAM.

These reasons led us to opt for a weaker but lighter levelof isolation than Xen’s or VServer’s.

Our approach is to embed OSGi as an OSGi bundle. A“core” OSGi instance runs multiple OSGi instances, all sharingthe same JVM. Then, the scalability factor is only the priceof virtualizing (or embedding) OSGi.

The aim here is to give each Service Provider a separateexecution environment, as depicted in figure 2. A virtualgateway is operated by one Service Provider, who sees it as astandard OSGi service platform.

Fig. 2. Multi-Service, Multi-Provider Home Gateway

The core service gateway is responsible for launching virtualgateways. It is managed by a gateway operator, who can alsobe the owner of the gateway or the Access Provider. Operationsrelated to virtual gateway life cycle are subject to contractsbetween a Service Provider and a gateway operator.

We now have an execution environment where each ac-tor around the Home Gateway gets a little privacy. ServiceProviders are only aware of services running in their ownvirtual gateway. The gateway operator ensures that allowedvirtual gateways are up and running, but cannot access theircontents.

After ensuring isolation, we need to add a controlled wayto share code and services. Two cases are considered. Thefirst one is services common to all actors on the HomeGateway. This could be useful for an embedded Web serveror a generic fault logger. These common services are hostedby the core gateway, and explicitly exported to all virtualgateways. When a virtual gateway is launched, it adds thiscollection of shared services to its internal service registry.The second scenario is for sharing code, such as libraries.For example, a single instance of multimedia codecs canbe hosted by the core gateway, and shared with all virtualgateways. It is similar to the previous case, except for theimport/export mechanism in OSGi (Java package versusOSGi service).

So far, we have described an execution environment thatsupports the multi-service model. The following describesthemanagement framework that runs on top of it.

B. An End-to-End JMX-Based Management System

Multi-party access to a gateway can be handled usingdifferent approaches. One is to create a specific entity namingscheme for each provider. That means that each provider mayaccess only a subset of the whole management data. We choseto define a virtual execution environment for each ServiceProvider; thus, a Service Provider sees a gateway as if hewas the only one using it. Each virtual gateway hosts its ownmanagement agent, with the technology the Service Providerchooses.

Our default implementation uses JMX. For scalability rea-sons, each JMX agent needs to be lightweight in terms of

memory consumption. We use a modified version of MX4Jthat we stripped down and split using Service-Oriented Pro-gramming.

Management data in JMX is represented through MBeans,which are Java interfaces. They follow the JavaBeans model:get an attribute, set an attribute, execute a method. Querieson an MBean are redirected to a set of probes; we haveimplemented probes that give access to:

• The OSGi framework: version number, current runningprofile, etc;

• Bundles life-cycle: start, stop, update and list bundlesinside the current gateway;

• OBR, the Bundle Repository: allows to trigger the instal-lation of a bundle on a remote gateway;

• Memory usage inside the Java virtual machine;• The underlying OS metrics: global CPU, memory, swap

and disk usage.

Core gateways also have an MBean to start, stop and listrunning virtual gateways.

Any bundle can come with its own MBean, for instanceto represent management data for a specific device or OSGiapplication. In this case, the MBean registers itself to theOSGiframework as an OSGi service. The JMX agent, listening toservice-related activities, automatically registers theMBean;this effortless approach is called thewhite boardpattern [8].

Finally, a remote logger implements the OSGi Log service.It notifies a remote manager of each event that occurs on thegateway.

The JMX agent and all MBeans are located on the gateway.For remote interactions, queries on MBeans are sent throughconnectors. In our case, RMI and XML/HTTP are used.

Fig. 3. Monitoring Console

We have developed a monitoring console (figure 3) thatdynamically discovers the list of bundles on a gateway. Theirassociated MBeans are gathered following thevisitor designpattern [9], then displayed in graphical tabs. This allowsto specialize management depending on the user’s servicesubscriptions, and to reuse the console for each of the threerealms presented in figure 1.

V. RESULTS

A. Memory Performance

Figure 4 shows the amount of memory used on our testsystem3, cumulating OS, Java, OSGi and applications . Onthe x axis, we run sample services that each allocate 1MB of memory4. On the first curve, all services run in thesame gateway (single-user mode). The other curves run eachservice in a separate virtual gateway, with and without separatemanagement agents.

0

10

20

30

40

50

60

0 2 4 6 8 10 12 14

Mem

ory

usag

e (M

B)

Number of services (1 MB each)

single usermultiple users

multiple users with management

Fig. 4. Memory Performance on a 64 MB machine

Our current implementation, which is not yet optimized forsize, shows a 3 MB memory overhead per service providerusing OSGi virtualization and a JMX agent. There are nosignificant CPU and disk overheads.

The memory overhead is not negligible, so there is still roomfor improvement. However, the advantage of this proposalis to enable OSGi’s service-oriented programming betweenmultiple virtual gateways, without modifying the underlyingOS and JVM. Other options suffer from either scalability,programming model or availability. The first alternative isto launch one JVM per user; scalability is one order ofmagnitude worse than OSGi virtualization, and the OSGiframework would need heavy modifications to support SOPbetween JVMs. The second alternative is to use a multi-taskJVM. This is the best compromise between scalability andresource isolation; however, the only implementation thatweknow of [10] runs only on big SPARC/Solaris systems. A lastalternative is to use lower-level isolation such as Xen. Thisoffers the best resource isolation available; however, service-oriented programming between Xen instances is yet to beachieved. With current implementations, we would need to runone JVM per Xen instance, with the downsides cited above.

3An average Home Gateway has a processor around 266 MHz, 64 MB ofmemory and 16 MB of storage. We have run performance tests on an Epia (1GHz Nehemiah CPU, 64 MB of RAM) running a Sun JDK 1.5 with defaultparameters, with the Felix OSGi implementation.

41 MB is enough to host e.g., several small games, embedded applicationsand tiny web servers. Our own UPnP/Audio-Video control point uses 600 KBof memory.

B. Management Performance

The management layer is evaluated by measuring responsetimes. On figure 5, the thin black curve is the pseudo-theoretical load induced by a simple probe :getCPU(). Itsshape isy = α/x + β. α can be seen aty = 100% CPU; itis the response time forgetCPU() with zero network delay.β is the residual load when the gateway is not running anyparticular application; this is also called system noise. Thecurve is obtained by measuring two arbitrary points, e.g., at100 and 400 ms period.

The thick green curve is the experimental load. It calls thegetCPU() probe at various periods, ranging from every 1000ms to every 10 ms. The peaks on the curve correspond togarbage collections on the system under scrutiny.

Fig. 5. Load Induced by Management Probes on a 133 MHz machine

The figure shows that, if we allow the management systemto use no more than 5% CPU time, thegetCPU() probe canbe polled every 500 ms. With around 10 users on the gateway,each Service Provider can poll a simple probe every 5 secondswithout encumbering the CPU.

C. Summary

Looking back at the requirements expressed in section III,we have addressed some of them, and left others open. Hereis the status of what works and what needs improvement.

1) Technical definition of users:Users (i.e., serviceproviders) are defined as managers of virtual gateways. Eachuser has his own management agent and management data, inhis own virtual gateway, accessible via his own port number.Thus, users are isolated from a management point of view.Moreover, each user chooses his own technology; we useJMX, but SNMP bundles are available on the OSGi BundleRepository5.

We have not yet addressed user authentication and securesession. We plan to use SSL-enhanced connectors for this.

The last requirement in this category was that the root user isable to take coercive measures against users that use too muchresources. This needs further works, since resource control forJava-based embedded systems is still a hot topic. We plan touse a feature similar to Linux’s OOM-killer (Out-Of-Memory):when too much memory (or CPU) is used system-wide, rootlocates the most consuming thread and kill its virtual gateway.

5http://www2.osgi.org/Repository/

If the thread belongs to root, the related bundle should bekilled.

2) Isolation and sharing of modules:We enforce names-pace isolation between software modules (OSGi bundles) thatbelong to different Service Providers. This is weaker thanresource isolation, but has the advantage of being OS- andJVM-independent, and it is production-ready.

Service sharing has been implemented statically. When theroot user creates a new virtual gateway, the core gatewaydeclares a list of services to export. In the future, we planto export this list dynamically.

3) Remote access for management:Our management bun-dles contain connectors for RMI and HTTP. Connectors forother remoting protocols are possible.

4) Local storage for preferences and configuration:Weuse a straightforward scheme to isolate local storage amongusers. The Felix OSGi implementation uses profiles to cachebundles and data related to bundles. Each virtual gateway hasits own profile, with its own cache directory. Bundles usuallyaccess files via thebundleContext.getDataFile()OSGi primitive, which only allows to reach this privatedirectory. We still need to stop malicious bundles that tryto openFileInputStreams on other users’ cache; Javapermissions allow to do this.

Our code is available under open source licenses.Management-related projects are integrated within the ApacheFelix project [11], distributed under the ASL license. The codefor OSGi virtualization is also written for Felix, and can beobtained on demand under the CeCILL license.

VI. CONCLUSIONS

Business models around Home Gateways are evolving, andwill inevitably open the door to new actors and new services.The immediate conclusion is that the execution environmenton the gateway must be split into isolated areas dedicatedto different Service Providers, and that each actor needsautonomy and choice in terms of management solutions.

We propose a lightweight, OSGi-level isolation of theexecution environment, where we launch “virtual” gateways(one per Service Provider) inside a “core” gateway (controlledby the operator). Each core and virtual gateway runs a separatemanagement agent. This enables namespace isolation; it isweaker than Xen’s or VServer’s isolation mechanism, but itscales reasonably on resource-constrained devices and allowsto share OSGi services between core and virtual gateways. Ontop of this, we provide an end-to-end management infrastruc-ture (probes, agent and monitoring console) that take virtualgateways and multi-service constraints into account.

We show that a simple implementation allows to host inthe order of ten Service Providers on a typical home gateway,with enough memory to run e.g. a UPnP/Audio-Video controlpoint. Each Service Provider can query simple probes in theorder of 10 times per minute without hindering the CPU.

REFERENCES

[1] Nicolas Fournel, Antoine Fraboulet and Paul Feautrier,“Booting andPorting Linux and uClinux on a new platform,” Research Report 206-08, LIP / ENS Lyon, February 2006.

[2] Guy Bieber and Jeff Carpenter, “Introduction to Ser-vice Oriented Programming,” 2001. [Online]. Available:http://openwings.org/download/specs/ServiceOrientedIntroduction.pdf

[3] Juan C. Duenas, Jose L. Ruiz and Manuel Santillan, “AnEnd-to-EndService Provisioning Scenario for the Residential Environment,” IEEECommunications Magazine, vol. 43, no. 9, pp. 94–100, September 2005.

[4] Home Gateway Initiative, ”Public Deliverable v1.0,” July 2006. [Online].Available: http://www.homegatewayinitiative.org/publis/HGI V1.0.pdf

[5] Yvan Royon, Stephane Frenot and Frederic Le Mouel,“Virtualizationof Service Gateways in Multi-provider Environments,” in Proceedingsof the 9th International SIGSOFT Symposium on Component-BasedSoftware Engineering (CBSE 2006), June 2006. LNCS 4063, pp.385–392.

[6] Paul Barham, Boris Dragovic, Keir Fraser, Steve Hand, Tim Harris, AlexHo, Rolf Neugebauer, Ian Pratt and Andrew Warfield, “Xen and the Artof Virtualization,” in Proceedings of the ACM Symposium on OperatingSystems Principles (SOSP 2003), October 2003.

[7] Stephen Soltesz, Herbert Potzl, Marc E. Fiuczynski, Andy Bavier andLarry Peterson, “Container-based Operating System Virtualization: AScalable, High-performance Alternative to Hypervisors,”in Proceedingsof the EuroSys Conference, March 2007.

[8] OSGi Alliance, “Listener Pattern Considered Harmful: TheWhiteboard Pattern,” 2nd revision, 2004. [Online]. Available:www.osgi.org/documents/osgitechnology/whiteboard.pdf

[9] E. Gamma, R. Helm, R. Johnson and J. Vlissides, “Design Patterns,Elements of Reusable Object-Oriented Software,” Addison Wesley,1995.

[10] Grzegorz Czajkowski, Laurent Daynes and Ben Titzer, “A Multi-UserVirtual Machine,” in Proceedings of the USENIX 2003 Annual TechnicalConference, pp. 85–98.

[11] Apache Software Foundation, “Felix OSGi R4 Service Platform imple-mentation.” [Online]. Available: http://felix.apache.org/

Fig. 6. Management Realms

Fig. 7. Multi-Service, Multi-Provider Home Gateway

Fig. 8. Monitoring Console

0

10

20

30

40

50

60

0 2 4 6 8 10 12 14

Mem

ory

usag

e (M

B)

Number of services (1 MB each)

single usermultiple users

multiple users with management

Fig. 9. Memory Performance on a 64 MB machine

Fig. 10. Load Induced by Management Probes on a 133 MHz machine

CHAPITRE 2. SELECTION 34

2.2 Project MOSGi[?]Stéphane Frénot, Yvan Royon, Pierre Parrend and Denis Beras

Monitoring Scheduling for Home GatewaysIn IEEE/IFIP Network Operations and Management Symposium(NOMS 2008), Salvador Bahia, Brazil, April 2008

Monitoring Scheduling for Home GatewaysStephane Frenot, Yvan Royon, Pierre Parrend and Denis Beras

INRIA ARES / CITI, INSA-Lyon, F-69621, Francetel. +334 72 43 64 22 - fax. +334 72 43 62 27

{firstname.lastname}@insa-lyon.fr

Abstract— In simple and monolithic systems such as ourcurrent home gateways, monitoring is often overlooked: the homeuser can only reboot the gateway when there is a problem. Innext-generation home gateways, more services will be available(pay-per-view TV, games. . . ) and different actors will providethem. When one service fails, it will be impossible to reboot thegateway without disturbing the other services.We propose a management framework that monitors remotegateways. The framework tests response times for variousmanagement activities on the gateway, and provides referencetime/performance ratios. The values can be used to establish amanagement schedule that balances the rate at which queries canbe performed with the resulting load that the query will inducelocally on the gateway. This allows the manager to tune the ratiobetween the reactivity of monitoring and its intrusiveness onperformance.

I. INTRODUCTION

During the last years, the Home Gateway market hasevolved at a very fast pace. The business model has evolvedfrom plain IP connectivity to triple play (voice, video anddata). These 3 services are provided by a single entity: theinternet access provider. In the close future, the business modelwill move to multi-play [1], and enable the management ofsmart homes [2]. The idea is that different sets of services,such as TV on demand, games, or home security, can bedeveloped and deployed by various business entities other thanthe access provider. To push this idea further, different serviceswill be delivered by various providers depending on the homeuser’s choices.

Such a business model has a strong impact on their under-lying technical infrastructures. Indeed, each service providershould be able to manage his own services. For instance, ifthe service is to monitor a pacemaker for an elder person, thehospital (or whoever is providing the service) should access thepacemaker’s data as directly as possible. It is not acceptablethat monitoring data is lost because the grandchildren arewatching TV.

From the network point of view, the solution is to granta certain Quality of Service to each provider, or even toeach service. However, we must also look at the system pointof view: home gateways have limited processing power, andmanagement activities do have an impact on CPU utilization.Simply put, the more often a manager sends requests, the moreaccurate management data he will get. However, the CPU loadwill increase, until a threshold where services will not be ableto run correctly.

We propose a management framework for home gatewaysthat determines this threshold. It is implemented on top of

Java/OSGi, using JMX. Section III gives a quick overview ofJMX and OSGi. In section IV, we show how we can evaluatethe cost of a getAttribute() request, namely a request toget the CPU usage on a gateway. Finally, section V describesa way to schedule management activities so that their cost inprocessing power are under control. Section VI concludes thiswork. 1

II. RELATEDWORKS

We now present the state of the art in management of Java-based systems. An overview of the existing solutions is pro-vided, and the JMX management opportunities, that emergesas one versatile solution for java applications. Until recently,the principal management technology has been the SNMP pro-tocol. It brings with it a complete management framework, inparticular data handling facilities with the MIB (ManagementInformation Base). SNMP can also be used in home systems[3], as JMX is. However, no real integration with applicationsis provided, which makes the latter approach more relevantwhen high-level software systems must be managed. However,application management must be performed carefully, so asnot to impair the system functions with management-relatedperformance overhead. This question has been studied in thecontext of Web Services [4], and for EJBs [5], or with afocus on Operarting System management [6]. The performancequestion for OSGi management will be discussed in detail inthis paper. JMX is the Java Management Extension [7]. Itis meant for managing and monitoring Java-based systems,through a so-called Agent that supervises probes. The probesare accessed through MBean interfaces. JMX is part of the SunJava project, and is the subject of two complementary speci-fications: the SUN JSR 3, ‘JavaTM Management Extensions(JMXTM) Specification’ 2, and the ‘SUN JSR 160: JavaTMManagement Extensions (JMX) Remote API’ 3. Several toolshave been developed to exploit the JMX functionalities. TheJConsole [8] is the sun monitoring and management tool.MX4J 4, which is an Open Source implementation of JMX,also provides a set of JMX-related tools. So as to provide afull control over the managed systems, which is often builtout of several elements, JMX must be integrated in a suitableframework. Jasmine5 is such a management framework for en-terprise applications, developed in the frame of the ObjectWebConsortium. It aims at managing the various parts of N-Tiers

1This work is partially supported by the IST-6thFP-507295 MUSE Euro-pean Project

systems ,such as Java EE, Message orientedMiddleware, andServices Oriented Architectures). The intensive use of JMXfor management brings scalability questions. This problemhas been studied by [9], and will be further discussed in thispaper. The specific instrumentation of OSGi platforms withJMX management facilities is more recent, and few powerfulsolutions exist. The Jasmine Project provides its own OSGiConsole, which is rather simple, since it only lists OSGiGateways and installed bundles. We developed a completeJMX Management Framework for the OSGi platform. Theprinciple of our approach is presented in OSGi [10], andthe core functionalities are shown is [11]. The current workintroduces additional functionalities, and discuses performanceoptimization of JMX-based Management.

III. A MANAGEMENT ARCHITECTURE FOR HOMEGATEWAYS

In previous works, we have designed a JMX-based frame-work for home gateways [12]. It comprises a remote console,and software that runs locally on each gateway. In JMX, suchsoftware is:• JMX agent: a singleton application that registers Java

management interfaces called MBeans;• MBeans: Java objects registered whithin the agent, and

accessible by a public Java interface. Standard MBeanscan provide 3 kinds of methods: get the value of attribute,set it to a new value, and invoke a method;

• Connectors: handled by the agent, they allow to accessMBeans remotely, in our case using HTTP or RMI;

• Probes: feed management data to MBeans when perform-ing get or set queries. Probes are implementation-specific,and are hidden by the MBean interface.

The role of the MBean is to provide information from themanaged system to the remote manager. The information canbe provided in two ways: through a solicitation from themanager (Response/Request), or through a notification fromthe MBean itself (Notification). The JMX specification enablesvarious kinds of MBean (standard, dynamic, models and open)and various kinds of MBean behaviors (thresholds, relations,measurements); this study focuses on standard MBeans withget / set / invoke methods.

We have implemented these software parts as OSGi plug-ins (called bundles). The OSGi [13], [14] specifications definea framework that manages the life cycle of applications.These applications can be downloaded from a remote location,started, stopped, updated, removed. Finally, applications canalso express dependencies towards other applications. Theframework automatically checks that dependencies are met,and refuses to launch an application otherwise. The OSGispecifications do not specify any management architecture tocontrol gateways. We have developed a JMX framework thatenables the remote monitoring of OSGi based home gateways.The framework uses a JMX agent located on the framework,and an RMI (or HTTP) connector that enables the connectionbetween an agent and a manager. We have also developedour own management console that connects to the agent. The

entire framework is available in Apache Felix [15], an opensource OSGi implementation. The management subproject iscalled MOSGi.

When managing a remote gateway, two interaction schemesare available: request/reply and notifications. With request/re-ply interactions, the manager periodically polls the gateway forvalues (memory, bandwidth. . . ). With notfications, the gatewaysends messages either on a timer basis or on a threshold basis.In both interaction schemes, management activities do havea cost in terms of processing power. This load correspondsto the various probes running on different threads and to theagent that maintains remote connections and a registry ofcurrent MBeans. Our concern is that the remote gateway haslimited resources. These resources are shared between bothuser services (TV, voice, games) and management activities.This paper tries to elaborate a way to determine the volume ofmanagement activities that can be imposed on a home gatewaywithout disrupting user services.

IV. MANAGEMENT COST EVALUATION

Managing home gateways has to cope with 2 oppositevisions. When something goes wrong the gateway operatorshould be warned as early as possible. But in order toachieve this, the gateway needs to handle an extra managementactivity that burdens the gateway. The question is simple:supposing that a figure under 5% of resource consumptionis not intrusive, how often can a manager query managementdata? The quantity is expressed as the number of requests persecond (or minutes) that can be sent. This measure reflects theresponse time an administrator can expect on a remote device.

A. CPU measurementAs a first approach we are working in request/response

mode. Figure 1 shows the CPU consumption that is inducedwhen querying the CPU utilization ratio.

Fig. 1. Cpu Monitoring

In this example the polling is made every 9 seconds andthe probe returns its value in 3 seconds. If the gateway doesnothing else than reacting to this query, it should present aload of 33%. It is easy to understand that the load average isdirectly related to the execution time (in CPU cycles) of thegetCpu method. In the Unix world, the /proc/stat fileholds data needed by the getCPU probe. The generic pseudo-algorithm of the probe is the following:

p u b l i c i n t getCPU ( ){open ( / p roc / s t a t ) ;i n t c u r r e n t I d l e V a l u e = r e a d I d l e V a l u e ( ) ;i n t cpu =( c u r r e n t I d l e V a l u e−o l d I d l e V a l u e ) / D u r a t i o n ;o l d I d l e V a l u e = c u r r e n t I d l e V a l u e ;c l o s e ( / p roc / s t a t ) ;re turn cpu ;

}

Listing 1. Pseudo-code for the getCPU probe

B. Determining the cost of the CPU probe

In order to manage a remote device, we need to know atwhich rate we can request data from it, and which quantityof data we can get in each request. The more requests byminutes, the fastest we can identify a fault, but the more loadwe put on the remote device. The theoretical curve obtainedis shown in figure 2 (smooth curve). This is a direct way ofobtaining the request rate the manager can apply. Accordingto these estimations, if the manager asks for the cpu every250ms he will generate a cpu load of 17%. If he asks every2s the rate drops down to 2%. Of course if the observation ismade every 2s, the system cannot identify the failure and theend-user can feel a service disruption.

The next section is a proposal to automatically obtain thiscurve. Knowing this curve, a manager can elaborate a manage-ment schedule among the various equipment available. Thismanagement planning should enable a fast decision makingwithout disrupting the user’s services.

V. A FRAMEWORK FOR MANAGEMENT SCHEDULING

A. Determining the cost of a management probe

As was presented in the previous section, we want to find away to establish the consumption curve. The curve establishesthe CPU rate involved by the management system. We havedeveloped two approaches: the first one is empirical, and triesvarious requests rates; the second one is theoretical and findssignificant points that allow to deduce the curve.

In the empirical approach, we define a series of rates atwhich the remote equipment is solicited. After setting theserates, the management console triggers a value request for eachof them. This test, run on a LinkSys NLSU2 equipment, givesthe second curve (not smooth) on figure 2. The values start at97% which means that whatever the manager does, he will notbe able to load the remote system more than 97%. We alsosee that there is an asymptote at about 0.5% which representsthe average load without any activity. This load is achievedfor a probing period of approximately 2s. So if we want notto disrupt the load of the managed system, we can make onerequest every 2s. A more important information is that we cansee that the curve has the α

x + β form. Below we try to findthe theoretical curve in a faster way, in order to determine theprobing period that match 5% of system load (which can beconsidered as negligible) efficiently.

αx +β is a trivial curve. The β parameter represents the load

without activity and the α parameter represents the peek loadthat the management system can put on the remote equipment.For instance, if the period is 1s for a 100% load, it is trivial that

for a 2s period the load should be 1/2 which correspond to 50%load (with the β parameter approximation). So the problemis to find a way to extract the α and β parameters of thiscurve. We have build an application that makes two measuresand extrapolates the curve. For the first point, the applicationsends requests as fast as possible and for the second point, theapplication tries a long period of requests.

Figure 2 compares the two curves previously presented.

Fig. 2. Estimated load curve and empirical results

The smooth curve is the one deduced from the significantpoints. The other one represents the empirical measurements.We see that testing all values or taking only two measures leadto similar results. The next step is to choose the 2 points thatallow to quickly calculate the estimated curve.

B. A management tool for evaluating the cost of a probe

We have integrated the tool to make these evaluation inour management architecture. It relies on a management agentresiding on the remote equipment which reacts to requestsfrom the management console. The management console hasthe following user interfaces:

Fig. 3. Management Console: Empirical tab

The left part of the user interface (figure 3) enables theselection of the remote equipment. The right top part of theinterface enables the input of parameters. In the sample theuser wants to test request periods from 1500ms to 10ms ofdelay with a step of 50ms. When he validates the value, a se-ries of testing periods is provided (the top Java TextArea). Theminimal probing period is an important value, it tantamounts

to the maximal rate of information retrieval by the manager.If periods are too short, tests are biased with the time theprobe needs to perform the calculation. One bias is linkedto the access to /proc/stat: the delay can interfere withmeasurements. The other bias is linked to management timers:Linux cannot provide precise data if the querying is too fast.In order to absorb these two bias we define the Minimal periodtime for a CPU calculation value, which force the request/replycycles at least to this value. The value corresponds to theminimum delay at which the system will be loaded for a periodof time. Finally if the user clicks on the ’Launch empiric’button it will generate a series of queries for each period, andprovide the corresponding curve.The second tab ”CPU attribute test“ of this user interfacedrives to the α

x + β curve production. Figure 4 shows thisinterface. The upper zone enables the user to choose the tested

Fig. 4. Management Console: αx

+ β tab

probe and the time duration of the test. When he presses thelaunch button, the system chooses automatically two periodsto test and determines the α and β parameters from a curveextrapolation.

We implement some heuristics in order to choose these twoperiods:• The second result should be at least 70% lower than the

first one. If the first value generates 97% of CPU load,the second point should be evaluated somewhere wherethe result is lower than 29%.

• The same number of requests must be executed for thepoints determination. This balances the garbage collectactivity.

• The system should control that the activity without man-agement is stable during the tests. This means that before,between and after the tests, the activity is stable.

As a conclusion, our approach enables a fast evaluation ofthe management cost of the CPU probe. The curve can bedetermined with two significant points. In the next section,we extend this to the evaluation of all available probes.

C. A generalisation of scheduling for any management probe

In the previous section we showed that we could evaluatethe cost of the CPU probe for a low end system. Since theremote equipment is managed in a multi-service environment

we think that not only the CPU cost should be evaluated. Inmany business scenario the CPU load is not relevant and manyother values can be more important. Significant values can beeither ”classical” ones, like available memory or bandwidth,but it can also be more specific ones such as ”how manyservices are deployed” (platform management data) or ”howmany beers are in the fridge” (application level data). Providedwe have the corresponding MBean , the framework is are ableto evaluate the cost for any probe. We automate the processof evaluating any remote probe. Figure 4 shows the associateduser interface. The service manager selects the probes he wants

Fig. 5. Attribute CostResult

to evaluate. For each probe the framework evaluates the delay(minimal time between each probe request) that correspondsto an increase of 100% of the remote equipment load.

Figure 5 shows results for some tested probes. For ex-ample the OSmemFree probe costs 44.221ms which meansthat requesting OSmemFree probe every 44ms will increasegateway CPU activity by 100%. So If we want a 5% load,the corresponding period is i.e. 884ms. The 0.0 values justindicates that probes are not tested yet.

These data can be used to elaborate a management plan.This plan indicates which and when each management probecan be requested. For instance if the manager asks the OSmem-Free value every 884ms and the Cpu probe value every 820mswe will have an increased CPU load of 10%. This managementplan is a fundamental concept where the manager needs to findthe right balance between the reaction time he wants and theload put on the remote equipment. The more reactive he wantsto be, the more load he puts on the remote site. Establishingthe plan a-priori can lead to a better anticipation of the systemevolution.

D. Results

We validate our framework on three classes of systems: 1)an Intel dual core running a desktop environment, 2) an EPIA1000Mhz simulating a high-end multimedia home gateway,and 3) a LinkSys NLSU2 representing a lightweight homegateway.

All these system runs Gentoo Linux with the JamVM virtualmachine and Felix/MOSGi as the management system2. Thefirst question to answer is : ”is the theoretical curve compliantwith empirical tests”. Figures 6, 7 and 8 represent these twocurves for the 3 test environments. The curve with squarepoints represent the ”empirical” approach the curve with roundpoints is the curve deduced from α and β parameter measures.

Fig. 6. Dual Core CPU cost

Fig. 7. Via Epia 1000 CPU cost

The empirical approach for the dual core figure stops at 12%load. This means that the manager cannot stress the remoteequipment to a big load. This is due to the fact that the dualcore is too powerful for the manager to be loaded. For the threefigures we see that the empirical and the α / β approachesproduce the same results. The latter is far faster since all thecurves are produced from two reference measures.

E. Monitoring

Once the service provider has determined which data hewants to monitor and at which rate he wants to get information,he sets these values on the monitoring management panel.Figure 9 shows an example of remote monitoring panel. In thisexample the panel is targeted to a human administrator but itcan be aimed at an automated system based on thresholds andalarms.

2All the code is available as opensource athttp://cwiki.apache.org/FELIX/index.html, and http://mosgi.gforge.inria.fr/

Fig. 8. LinkSys NLSU2 CPU cost

The monitoring console shows 2 periods (PI, PII). Theydisplay monitoring curves for 4 probes (c1, c2, c3, c4). Fromupper to lower curve :• The c1 curve is the OSmemFree probe,• The c2 curve is the OSmemBuffer probe,• The c3 curve is he Cpu probe,• The c4 curve is the OSmemCached probe.

Fig. 9. Slug monitoring platform

In PI all probes request periods are set to 1s. So ourframework predicts a CPU load for c1 to c4 respectively of4.4%, 4.2%, 4.6% and 4.1%. We can see that the Cpu probereturns an average value of about 17.5% which is about thesum of the c1 to c4 probes cost. In PII we want to specify arequest period for Cpu probe (c3) of 3s and for OSmemFree(c1) of 2s which, according to our framework, generates aCPU load of 3.6% total. So if we do not want to generatemore than 5% CPU load with our management plan, we setrequest periods for the 2 remaining probes in order to generatea maximum of 1.4% CPU load. In the figure we choose i.e0.7% for c2 and 0.7% for c4 the system calculates a resultingdelay of 6069ms for c2 and 6623ms for c4.

A last use case of our system is to make benchmarkingbetween systems. We use our system both on a Felix OSGiframework and on a Concierge OSGi framework. We observedthat the mean response time of most probes are slightly fasteron Concierge implementation than on Felix which confirms

that Concierge is optimized for small environments. Thesebenchmarking issues are rather easy to set up and the resultsare directly observable with the monitoring platform.

Another use case we examined is to evaluate the qualityof probe implementations. Our system can compare CPUconsumption of similar probes in order to compare theirperformance.

VI. CONCLUSION

We present in this article a monitoring framework that aimsat finding the balance between the frequency of remote queriesand the resulting CPU load on the managed equipment. Themonitoring process starts with an evaluation period wheremonitored system probes are queried in order to establish theircharacteristics. A probe characteristics is modeled with a curvethat represent the induced load in function of the query pace.The curve has an α

x + β shape.After having evaluated the curve a manager can elaborate

a query plan. This plan fixes for each probe the query pacethus anticipating the resulting load induced by the managementlayers on the managed system. The overload is then due toother running applications. Of course one goal of the systemis to guarantee that the management layers do not cost toomuch and that they stay below a certain limit.

This framework is aimed at home gateways; these runservices and applications that should be remotely managed.Since those devices have quite limited resources, the man-agement overload needs to be carefully tuned. The faster themanagement queries are made the faster the service providercan react to a perturbation, but the highest load he puts on thegateway.

REFERENCES

[1] MUSE Project, “IST-507295 FP6,” http://www.ist-muse.org/, 2004.[2] Baskar Sridharan and Aditya Mathur, “Infrastructure for the Manage-

ment of SmartHomes,” Software Engineering Research Center TechReport SERC-TR-177-P, January 2002.

[3] Radu State, Olivier Festor, and Isabelle Chrisment, “Context-DrivenAccess Control to SNMP MIB Objects in Multi-homed Environments,”in DSOM 2003, Self-Managing Distributed Systems, vol. LNCS 2867,2003.

[4] R. Levy, J. Nagarajarao, G. Pacifici, A. Spreitzer, A. Tantawi, andA. Youssef, “Performance management for cluster based web services,”in IFIP/IEEE Eighth International Symposium on Integrated NetworkManagement, 2003.

[5] Markus Debusmann, M. Schmid, and M. Kroger, “Generic PerformanceInstrumentation of EJB Applications for Service-Level Management,” inNOMS 2002, Florence, Italy, ser. Lecture Notes in Computer Science,M. Brunner and A. Keller, Eds. Springer, April 2002.

[6] Sujay Parekh, Kevin Rose, Joseph Hellerstein, Sam Lightstone,Matthew Huras, and Victor Chang, “Managing the PerfomanceImpact of Administrative Utilities,” in DSOM 2003, Self-Managing Distributed Systems, vol. LNCS 2867, 2003,http://www.research.ibm.com/PM/RC22864.pdf. [Online]. Available:http://www.research.ibm.com/PM/

[7] H. Kreger, “Java management extensions for application management,”IBM Systems Journal, vol. 40, no. 1, pp. 104–129, 2001.

[8] M. Chung, “Using jconsole to monitor applications,”Sun Whitepaper, December 2004. [Online]. Available:http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html

[9] Abdelkader Lahmadi, Laurent Andrey, and Olivier Festor, “Perfor-mances et resistance au facteur d’echelle d’un agent de supervision basesur JMX : Methodologie et premiers resultats,” in GRES, 2005.

[10] Eric Fleury and Stephane Frenot, “Building a JMX management inter-face inside OSGi,” Inria RR-5025, Tech. Rep., 2003.

[11] Yvan Royon, Stephane Frenot, and Frederic Le Mouel, “Virtualization ofService Gateways in Multi-provider Environments,” Component-BasedSoftware Engineering, 2006.

[12] Yvan Royon and Stephane Frenot, “Architecture de gestion depasserelles de services,” in GRES, 2006.

[13] OSGi Alliance, “http://www.osgi.org/.”[14] Dave Marples and Peter Kriens, “The Open Services Gateway Initiative:

an Introductory Overview,” IEEE Communications Magazine, December2001.

[15] Apache Software Foundation, “Felix OSGi R4 ServicePlatform implementation,” http://felix.apache.org/. [Online]. Available:http://svn.apache.org/repos/asf/incubator/felix/

CHAPITRE 2. SELECTION 41

2.3 Project SOSGi[Parrend et al. 2007]Pierre Parrend, Samuel Galice, Stephane Frenot and Stephane Ubeda

Identity-Based Cryptosystems for Enhanced Deployment of OSGiBundlesIn SECUREWARE’2007, Valencia, 14-20 october 2007

Identity-Based Cryptosystems for Enhanced Deployment of OSGi

Bundles

Pierre Parrend, Samuel Galice, Stephane Frenot, Stephane UbedaINRIA ARES/CITI, INSA-LyonF-69621 Villeurbanne, France

E-mail: {pierre.parrend},{samuel.galice},{stephane.frenot},{stephane.ubeda}@insa-lyon.fr

Abstract

The OSGi platform is designed to make Java soft-ware extensible at runtime. This undeniably presentsa great interest in several domains like embedded plat-forms or enterprise application servers. However, se-curing the deployment of the OSGi components, orbundles, proves to be a major challenge. The currentapproach consists in digitally signing the bundles andcertifying the signature through a Public Key Infras-tructure.

We propose to replace this technology with Identity-based cryptographic mechanisms, which provide bothbetter performances and simplified key management.We present an infrastructure for initialization and useof Identity-based key management, and define the dig-ital signature of bundles using such a cryptographicscheme. Based on our implementation, we providea comparison between PKI management and Identity-based Key Management. The proposed approach provesto support radical improvement in the key managementprocess, especially in strongly asymmetric system suchas OSGi-based Home Gateway, where a few providerspublish services for millions of potential users.

Introduction

Nowadays, the ever-growing connection to Internetof homes and enterprises - often through a connectionover ADSL Wide-band Access - brings new capabilitiesfor home entertainments or professional services. TheHome Gateway which classically provides the connec-tion to Internet becomes a central device that supportsexecution of high-level services. These services needto be dynamically loaded on the gateway at runtime,

0This work is partially funded by MUSE II IST FP6 Projectn026442.

which is supported by the OSGi Platform. The OSGienvironment is a lightweight overlay to a Java VirtualMachine. This runtime extension enables new code tobe executed on the Home Gateway, and must there-fore be strongly protected. This protection is currentlyperformed through the digital signature of the bun-dles with DSA algorithms, which imply a complex keymanagement. We propose to replace DSA signaturewith digital signatures that use Identity-based Cryp-tography. This recent cryptographic scheme enables inparticular to dramatically simplify the management ofpublic key, by replacing Public Key Certificates witha string identifier of the signer. A parameter whichis specific to the Certification Authority enables ev-ery client to deduce to public key from the identifier,and thus to check whether the Certification Authority,called Private Key Generator (PKG) has used a validprivate key for the bundle signer.

We present in this paper other works related to se-cure OSGi and dynamic systems in Section 1, and theprinciple of Identity-Based Cryptography, in Section 2.The infrastructure for secure deployment of OSGi bun-dles is presented in the section 3. We then provide avalidation of the proposed approach in Section 4, andconclude the paper.

1 Related Works

The security of the component deployment processis enforced is most cases through context-dependentsolutions. We provide here an overview of the principalexisting solutions.

The default Bundle Signature mechanisms of de-ployment of OSGi bundles is based on the Java Archivesignature [16]. It is strengthened by the OSGi CoreSpecification Release 4 [11] to provide a higher levelof security in the deployment process. In particular,OSGi bundles can not be extended with new resources,

when Java Archives can [13]. You can find further tech-nical information related to digital signature of OSGibundles in [12].

Several alternatives to the OSGi platform have beenproposed to support this secure deployment. The Cin-gal Model [3] manages the deployment of componentsthrough insertion of metadata in the components. Thebundles are wired together. Each bundle carries au-thentication metadata, which comprises the digital sig-nature and the identity of the signer. The implementa-tion is not compatible with the OSGi framework, butthe principles are very similar. Another alternative isPreatoria [5] which is a framework dedicated to thedeployment of Web Services. The security mechanismsare based on the Web-Service standards, which enablesto support both deployment and execution time se-curity. Praetoria is developed on the .Net platform.Since it uses Web Service technology, it is less flexiblethan the OSGi platform. In the context of enterprisesystems, the SmartFrog (Smart Framework for ObjectGroups) [9] has been developed. The security is per-formed through the encryption of all communicationsand data transfer. This approach is straightforwardin environments where all entities are known, but cannot be easily mapped toward large-scale or evolutivesystems.

Some solutions are specifically target at the OSGiframework. For instance, Kim et al. propose to rely onMessage Authentication Code (MAC) based authenti-cation. Consequently, the asymmetric cryptography-based signature with SHA-1 and DSA algorithms isreplaced by symmetric cryptography. The creation ofa shared secret at bootstrap time is required [7]. Thisprocess is more lightweight that the one specified bythe OSGi Alliance. However, the use of symmetriccryptography makes the key management more com-plex and less robust: since the secret key is shared,the non-repudiation of actions can not be guaranteed,keys can be divulgated to third parties, and key re-vocation is extremely difficult to support. Moreover,the actual benefit is not quantified, which would be ofa great interest when choosing to give up the currentstandard. This work is extended by Lim et al. to takeadvantage of XML technology signature, that supportsMAC based authentication [8]. Since XML is usuallynot considered as a lightweight technology, this exten-sion seems paradoxical with the use of limited resourcedevices. Again, the lack of quantification of the relativeperformances of the various solutions does not providesufficient data to choose between the various solutions.

Identity-based Cryptography has not yet been ap-plied to the deployment of OSGi bundles - or otherkind of components. However, several propositions

have been made to exploit their possibilities in thecontext of distributed and pervasive systems. In thecontext of Health-Care systems - which are a potentialapplications for Home Gateways - Mont propose to useIB Cryptography to support a secure messaging ser-vice [10]. The authors take advantage of the increasedflexibility brought by IB Cryptography to enforce role-based security mechanisms. The technology has alsobeen used in the context of the Grid to provide securecommunication channels [15].

2 Identity-Based Cryptosystems

Until recently, encryption techniques have relied onlong, randomly generated keys that must be mappedto identities using digitally-signed documents, calledcertificates. The management of these certificates, andthe need to fetch a certificate before encrypting to aperson or machine, has made encryption very difficult.

Identity-Based Encryption (IBE) takes a completelynew approach to the problem of encryption: IBE is akey authentication system in which the public key of auser is some unique information about the identity ofthe user . That allows any party to generate a pub-lic key from a known identity value such as an ASCIIstring (e.g. a user’s email address) enabling data to beprotected without the need for certificates. A trustedthird party, called the Private Key Generator (PKG),generates the corresponding private keys. Each newuser associated to the trusted domain must requestshis private key from this PKG. The master key is keptsecret by the PKG and there is no authority in chargeof the generation of this master key. The PKG controlsthe mapping of identities to decryption keys in orderto ensure the protection of the system.

Historically, the design of a functional Identity-Based Cryptosystem (IBC) was a long-standing openproblem in cryptography. The notion of IBC was firstintroduced by A. Shamir [14] in 1984. In 2001, D.Boneh and M. Franklin [1] were the first to propose afully adapted model with the help of elliptic curves andthe Weil and Tate bilinear pairings serving as buildingblocks for these Public Key Cryptosystems (PKC).

As a result, parties may encrypt messages (or ver-ify signatures) with no prior distribution of keys be-tween individual participants. This is extremely usefulin cases where pre-distribution of authenticated keysis inconvenient or infeasible due to technical restraints.However, to decrypt or sign messages, the authorizeduser must obtain the appropriate private key from thePKG. A caveat of this approach is that the PKG mustbe highly trusted, as it is capable of generating anyuser’s private key and may therefore decrypt (or sign)

messages without authorization. Because any user’sprivate key can be generated through the use of thethird party’s secret, this system has inherent key es-crow.

The power of IBE is in its simplicity. By usingwell-known identifiers, such as email addresses, as pub-lic keys, IBE enables security policies to be encodeddirectly into encryption and authentication methods,eliminating the need for cumbersome certificates andCertification Authorities. By eliminating the need forcertificates, IBE removes the hurdles of PKI: certificatelookup, life-cycle management, Certificate RevocationLists, and cross-certification issues. IBE’s simplicityalso enables it to be used in ways PKI could not: IBEcan be used to build security systems that are moredynamic, lightweight and scalable. The IBC based onelliptic curves have numerous advantages as the gain insize of the keys and the reduced computational time.Moreover, they provide as well signature/verificationprocesses as encryption/decryption operations withincorrect times and for a lower cost of CPU or memoryusage than in the case of classical cryptography (asDSA).

We propose thus to utilize IBC to deploy bundlein the OSGi context with a high level of security inparallel. We claim that the resulting protocol is morelightweight in both cost of management and networkcommunications than usual PKC based on traditionalcryptographic tools (RSA, DSA). To prevent the natu-ral key escrow problem presents in the native IBE sys-tem since the PKG knows each private key, we decide touse the Chang-Zeng-Kim signature scheme which pro-vides a solution to this issue. To support our proposi-tion, we intend to implement a fully functional versionof our protocol. The performance of our protocol iscomparable to the performance of ElGamal signaturescheme. The security of the system is based on a nat-ural analog Extract, Sign and Verify. Considering Alicea signer with her identity d, she signs a message in theSign phase by using the private key given by the PKG.In the Verify phase, Bob verifies the validity of her sig-nature in an IBS scheme just by using her identity IDA

and the params made publicly available by the PKG.The Chen-Zhang-Kim’s Identity-based Signature

(CZK-IBS) scheme (see [2] for more details about thisscheme) is used in the signing and verification phasesin order to eliminate the inherent Key Escrow prob-lem as cited in Introduction. This choice is highly mo-tivated by some non-repudiation considerations espe-cially in the context an multi-provider and open envi-ronment as the OSGi platform. Another motivation forthis scheme is to help the public bundle deployment.Rather than storing a big database of public keys the

Figure 1. Global view of the initialization ofthe cryptographic Objects

system can either derive these public keys from a localfile or from authorized providers.

3 The OSGi Security Architecture withCZK-IBS

The substitution of the classical Public Key In-frastructure (PKI) with an Identity-based key man-agement infrastructure for securing the deployment ofOSGi bundles has two main advantages. First, theprocess of key management is greatly simplified, whichmakes the actual use of secure deployment more realis-tic than with a PKI [4]. Secondly, the specifications ofthis new deployment scheme provides a support to ex-tend the original functionalities with the confidential-ity of the bundles. Three phases need to be specifiedfor the deployment of CZK-IBS signed bundles: theinitialization of the cryptographic objects, the processof bundle deployment, and the mechanisms of bundlesignature.

3.1 Initialization

Initialization of the cryptographic objects in our in-frastructure is shown in the figure 1. The process isthe following.

First, all entities that need to be identified must beinitialized. The parameters of the trusted PKG whichperforms the management of cryptographic objects inour infrastructure must be distributed through a securechannel to all participants, along with their own uniqueidentifier. This is typically done offline. In the contextof telecommunication services such as those developed

in the Muse Project, the PKG is located on the AccessControl Server. The identifier delivered to the partici-pants of the system contains the following information:a unique string identifier. The PKG stores a copy ofthe public identities to be able to identify valid par-ticipants. This offline initialization of cryptographicobjects is typically done through a USB key or a smartcard where the specified informations are stored. Thispre-identification step is mandatory in closed systems,such as Home Services, monitoring systems, or enter-prise informations systems. It can be by-passed in opensystems such as the deployment of open source softwareor in ambient systems, where all actors that want totake advantage of the infrastructure should be allowedto. While allowing unknown entities to be identified,such an approach guarantees the uniqueness of the bun-dle providers, and thus prevents both the tampering ofthe bundles and the impersonation of the providers.

Secondly, the bundles Issuers retrieve their privatekey from the PKG. Therefore, the PKG is implicitlygranted a strong trust, since it could forge any pri-vate key of all entities that rely on it. Nevertheless,the CZK-IBS provides a tracing scheme to detect thePKG’s impersonation. The retrieval of the private keymust be performed again when the issued private key isexpired. Typically the span-life of a private key wouldbe a short period of time, such as a day or a week. Thisshort validity of time of the private key makes the re-vocation of the issuers a lightweight process, since it issufficient not to issue a new private key for them.

Thirdly, the client platforms are initialized. A clientneeds two types of data so as to subsequently check thevalidity of the bundles it loads. The first type, the so-called ‘params’ of the PKG must be known. They allowto compute the public key of each bundle issuer fromtheir identity and above all, to verify the signature ofthe signed bundles. The second type of data is a listof trusted bundle issuers that are considered as validmust also be available. Otherwise, it would be possiblefor any malicious issuers to sign and publish bundlesthat would be considered as valid.

3.2 Bundle Deployment with CZK-IBS

The process of deployment with CZK-IBS scheme isshown in the Figure 2. It is very similar to the one inthe context of a classical PKI, with a notable gain interm of management complexity.

The signature phase is similar to the signature mech-anism in the PKI based model. The differences lay inthe cryptographic algorithms that are used (see section3.3) and the frequency of the update of the private keyof the signers. The validation phase is done in the same

Figure 2. Secure Deployment of OSGi Bun-dles with CZK-IBS scheme

way as in the case of the PKI. The validation processmust be adapted to the algorithms. The validation ofthe public key certificate is replaced by the control ofthe validity of the identity of the signer: its identity iscompared against the list of valid signers that has beenobtained during the initialization phase.

The confidentiality is achieved by encrypting thebundles before their publication. Because it is not pos-sible to publish a signed bundle for all clients, groupsmust be defined that gather the client platforms withsimilar functional and trust profiles. The clients re-trieve the private key of their group through a requestto the PKG. Consequently, this latter must maintain alist of the users’ identities for each group. The with-drawal of clients from the group is dealt with by a reg-ular key update. Former group members can not haveaccess to the new keys. The total number of groupsshould be reduced, so as to limit the number of copiesof a single bundle that are encrypted with differentpublic keys. Moreover, the user authentication mecha-nism is also based on its identity.

3.3 Bundle Signature with CZK-IBS

The process of signing bundles is pretty similar tothe classical one [12]. The algorithms used for obtain-ing the hash values are the same but those generat-ing the digital signature are different. Into the bar-gain, the absence of a public key certificate makes theCMS format [6] obsolete. The structure of a signedbundle using CZK-IBS scheme is depicted in the fig-ure 3. Each resource of the archive is identified in theMETA-INF/MANIFEST.MF file, along with itshash value. So as to allow several signers to sign thebundle, the hash value of this Manifest file is stored ina so-called Signature File, as well as the hash value ofthe various entries of the Manifest. The digital signa-ture itself is realized on the Signature File, and stored

Figure 3. Structure of a signed bundle, usingIdentity-based Cryptography

in the Signature Block.We propose to replace the CMS compliant Signa-

ture Block by an IB-CMS compliant block, that isto say a modified CMS file that contains the informa-tion related to the signer, such as its identifier, and theproperties of its key, such as the period of validity. Thesigner informations are the following: the signer iden-tifier (‘signerID’), the identifier of the PKG that issuesthe private key (‘keyissuerID’), the date of the emis-sion of the key (with the year, the month, the day),the validity period of the key (an integer value, anda time unit, which can be day, week, month or year),and the name of the algorithms that are bound to thiskey. The encryption algorithm is mandatory. In mostcase, the hash algorithm is bound to the encryption al-gorithm, and must be specified. The CZK-IBS schemeis also integrated in the IB-CMS file. Since it is basedon Elliptic curve cryptography, it is more performantand more compact that the classical DSA one. Twofields are removed from the original specified format,because they make no sense in the context of IBC: theX.509 public key certificate (or list of certificate, if del-egation of signature was provided), and the CertificateRevocation List (CRL). Consequently, the IB-CMS fileis more lightweight than the CMS one was, which canbe a useful property in environments with limited re-sources.

The substitution of classical PKI-based asymmetriccryptography by the Identity-based scheme makes itpossible to build an infrastructure for secure deploy-ment of bundles that is both easier to manage, andless greedy in term of resource consumption. We claimthat these two properties not only bring an improve-ment to the current specified solution, but also that itmerely makes it a realistic choice for systems that are

both complex and limited in their resources.

3.4 Security Analysis

We present in this section a short security analy-sis of our infrastructure against some classical attacks.The basic security properties a cryptosystem shouldprovide are Confidentiality, Integrity, Authentication,and Non-repudiation. Confidentiality is keeping infor-mation secret from all other than those who are au-thorized to see it. Integrity is ensuring that the infor-mation has not been altered by unauthorized or un-known entities. Authentication is the assurance thatthe communicating party is the one that it claims tobe. Non-repudiation is preventing the denial of pre-vious commitments or actions. The security of eachcryptographic primitive used in our proposition wasdiscussed in the referenced paper [2] and was clearlyestablished. Although the first IBC security notionswere proposed in [1], there is no work yet aiming atestablishing the strength of this notion in a full secu-rity analysis. So far, only the indistinguishability basedsecurity notions, as well as their variations have beenconsiderated in the literature.

Digital Signature is a fundamental cryptographicprimitive which provides authentication, integrity andnon-repudiation. The unforgeability of the hashed mes-sage guarantees the integrity of the CZK-IBS Signa-ture. This property is provided by the collision resis-tant property of the hash function used. Due to recentresults published in [17], at least SHA-1 must be usedto be sure that the hash function does not permit tocompromise the bundle signature integrity.

In our proposition, the PKG plays an important roleby defining entirely the security domain and thus maypotentially forge signature for any message. Neverthe-less, the CZK-IBS scheme provides a way to circum-scribe this problem. The dishonesty of the PKG canbe proved by the Service Issuer by providing a proof ofhis secret key (SIDA

, r) through a knowledge challenge.So there is Authentication in the system.

The PKG also plays an important role by ensur-ing that all the valid Service Issuers are trustworthy.Actually, the Service Provider in an OSGi based Ser-vice Environment exists outside the home network asdoes the Home Gateway manager for managing thehome gateway and authenticating the users. Our pro-tocol is designed under the assumption that Identity-based Infrastructure is used according to Home Gate-ways storage and computation capabilities, the paramsare shared between all entities. Another assumption isthat the service users trust the Service Manager. Fi-nally, Home Gateway knows that the PKG is legitimate

by using its public key initialized in a preinstallationphase.

4 Validation

The validation of our approach is performed in twosteps. First, we present the technology that we use todevelop our prototype. Then we perform an qualitativeand quantitative evaluation of the benefits of Identity-based cryptography in the process of secure deploymentfor OSGi Bundles.

4.1 Implementation

A prototype for IB Cryptography systems is cur-rently being built at the CITI Laboratory. It will beintegrated with the SFelix suite we previously devel-oped1, which is an implementation of current OSGiRelease 4 specifications of Bundle Signature.

The SFelix suite is written in Java, to be fully com-pliant with the OSGi environment. However, cur-rent implementations of identity-based cryptographylibraries, Miracl and Voltage, are only available in C.This does not prevent experimentation, since call tonative libraries are well supported in Java, but limitsthe portability of the solution.

We now discuss the existing IB cryptographic li-braries. The first implementation is based on Miraclwhich is a portable C/C++ library providing a fullimplementation of Multiprecision Arithmetic. In par-ticular it includes all the primitives necessary to im-plement Number Theoretic based methods for PublicKey Cryptography, such as Diffie-Hellman, RSA andDSS. Complete support is also provided for implemen-tation of Elliptic Curve Cryptosystems over the fieldsGF(2m) and GF(p). The MIRACL big number libraryalso contains an experimental implementation of IBE2.The second implementation is based on Voltage IBEToolkit which is a set of tools that enable developersto quickly and easily incorporate Identity-Based En-cryption into their applications. Using the Voltage IBEToolkit, applications can seamlessly integrate with theVoltage Security platform and take advantage of itscentralized administration, advanced policy manage-ment, and key distribution architecture3.

Our IB-based digital signature tools are in theirearly development stage. However, this does not pre-vent us to perform a precise evaluation of the proposedframework.

1http://sfelix.gforge.inria.fr/2http://www.shamus.ie/3http://developer.voltage.com

4.2 Benefits for Security Management

The prototype we develop allows us to evaluate theactual benefits of Identity-Based Cryptography in theprocess of deploying OSGi Bundles. This evaluationmakes it possible both to confirm that Identity-BasedCryptography hold its promises, and to draw actualpros and cons of classical PKI-based systems and IB-Crypto based systems.

A systematic comparison between Classical PKI andIdentity-Based Cryptography PKI is given in Table 1.The first main difference, which is the ground if thesimplicity of management of IB-PKI systems, is thatthe public key must be disseminated as is in the contextof classical PKI, and that it is directly deduced from astring identifier and from a Private Key Generator spe-cific parameter with IB-Cryptography. Consequently,keys are updated using huge periods in classical PKI,whereas they can be updated daily with IB-Crypto:if a time stamp is appended to the signer’s identifierto generate the public key, this latter can be updateddaily. The client only needs to re-generate locally thenew public key. The benefit of regular key update isthat public key revocation is performed transparently.When a signer is no longer part of the system, she cannot retrieve a new daily key pair from the PKG. So shecan no longer sign bundles. On the contrary, classicalPKI infrastructures imply that the client must be noti-fied when a signer is revoked, and thus complex PublicKey Revocation mechanisms must be available. More-over, Key size and time for signature verification aredecreased with IB-Cryptography.

PKI based on RSA or DSA algorithms still have ad-vantages over Identity-based Cryptography. In partic-ular, the speed of signature generation is greater usingDSA or RSA algorithms. But the main drawback ofIdentity-Based Cryptography is that the Private KeyGenerator must be fully trusted, since he knows theprivate key of all entities of the systems. Whereas clas-sical PKIs are based on the certification of public keys:they validate this latter without having access to theprivate key. Thus, the Certification Authority requiresa lower trust level than PKGs. We solve this prob-lem by using the IB-CKS cryptographic scheme, whichmakes key escrow traceable, and therefore forces thePKG to be honest.

A quantitative analysis shows that Digital Signatureof Bundles using IB Cryptography provides a great en-hancement in key management overhead when com-pared to PKI infrastructure. When a new key is usedby a signer, this latter makes a communication withthe PKG to retrieve the new private and public keys.Assume that N signers are authorized to publish bun-

dles in the systems, this is tantamount to N commu-nications - a reasonable assessment is than N is of theorder of magnitude of 10, or even less. When a clientloads a bundle, it can check locally that the key is validand has been issued by the trusted PKG. So no com-munication with the PKG is required. The total num-ber of communication with the Certificate Authorityis thus N. In the context of PKIs, the signers need tocertify their Public Key Certificates, which amounts toN communications. When they load a new bundle, theclients must check that this Public Key has not beenrevoked. This is done through a request to the Certifi-cation Authority, which provides a Certificate Revoca-tion List (CRL). The number of client is noted M, withM of the order of magnitude of a couple of million, ifwe assume as in the Muse European Project that theHome Gateway is provided with the ADSL modem (inFrance, the number of client varies between 1 and 5millions clients for each ADSL providers). On the firsthand, the PKG must stand a traffic of some tens ofconnections daily. On the other hand, the PKI mustbe available for several millions of users. If the PKI isreplicated on the DSLAMs, each replica serves no morethan 400 clients, but all DSLAMs must support CRLfunctionalities, which obviously causes an importantsystem update overhead. Identity-based Key Manage-ment systems therefore has a radical technical advan-tage over PKIs, which could soon be translated in rad-ical financial gains for telecommunications firms.

Since we have developed prototypes for both DSA-based digital signature and Identity-based systems, itwould be of interest to compare the relative computa-tion speed of both techniques. However, the BundleDigital signature we use is written using the Bouncy-castle Java library for DSA-signature, and the Identity-based Cryptographic C libraries are accessed from Javacode through native calls. Quantitative comparisonwould be a comparison of C and Java more than anevaluation of both techniques. We intend to performthese evaluation as soon as a Java implementations ofIdentity-based Cryptographic tools are available.

PKI and IB Cryptography have both pros and conswhat concerns cryptographic and system security prop-erties. But the simplification in the key manage-ment process with Identity-based systems, which allowsclient to check digital signatures without any need tocontact a certification authority proves to allows dra-matic key management gains, in particular in stronglyasymmetric systems such as telecommunication HomeGateways.

PKI IB-PKI Ratio+ - + -

KeyMan-age-ment

PublicKeyDissem-ination

PublicKey isIdenti-fier

KeyRevoca-tion

HeavyweightTransparent,throughregularkeyupdate

CryptographicOpera-tions

SignatureSpeed

KeySize,Signa-tureVerifi-cationSpeed

CATrustLevel

High KeyEs-crowRiskif un-trusted

Numberof Comswiththe CA

N+M N →1/M

Table 1. Pros and Cons of classical PKI andIB-PKI Approaches

5 Conclusion and Perspectives

We have proposed in this paper a protocol to securethe deployment of OSGi bundles by using recent cryp-tographic algorithms based on elliptic curves and bilin-ear pairings. Our proposition relied on the CZK-IBSscheme to support the Public Key Infrastructure (PKI)instead of the classical solutions as those specified bythe OSGi Alliance. The use of Identity-based cryptog-raphy has several advantages: first, the key manage-ment overhead is greatly reduced, which can provide aradical advantage in the case of strongly asymmetricsystems such as Home Gateway infrastructures, wherea couple of providers publish services for an importantnumber of clients. The public keys do not need to bepublished, since they can be deduced from the identi-fier of their owner. Moreover, the complex revocationscheme vanishes and is replaced by the frequent updateof the keys, typically every day or week. Another ad-vantage of our proposition which has probably a lessradical impact is the fact that the keys and signaturesused are based on Elliptic-curve cryptography. Theyare therefore more compact than those bounded withthe DSA algorithm which is currently used for signingarchives. We have also defined in this paper the pro-cess for securing the deployment of OSGi bundles usingIdentity-based cryptography, as well as the structure ofa signed OSGi bundle by the CZK-IBS scheme. Bothqualitative and quantitative benefits of the approachwere discussed. Yet, our approach has some limita-tions, in particular the centralization of the securityscheme around the PKG, which becomes a single pointof failure. Its compromission means a high impact onthe overall security of the system.

However, we believe that Identity-based Cryptog-raphy enables to greatly reduce the key managementoverhead, and thus may succeed in large scale systemswhere PKI have so far proven to be very difficult tomanage.

References

[1] D. Boneh and M. K. Franklin. Identity-based encryp-tion from the weil pairing. In Advances in Cryptology- Crypto’2001, volume 2139 of Lecture Notes in Com-puter Science, pages 213–229. Springer, 2001.

[2] X. Chen, F. Zhang, and K. Kim. A new ID-basedgroup signature scheme from bilinear pairings. InInformation Security Applications, 4th InternationalWorkshop - WISA’03, volume 2908 of Lecture Notesin Computer Science, pages 585–592. Springer-Verlag,2003.

[3] A. Dearle, G. Kirby, A. McCarthy, and J. D. y Car-ballo. A flexible and secure deployment framework

for distributed applications. In Lecture Notes in Com-puter Science 3083, pages 219–233. Springer, 2004.

[4] C. Ellison and B. Schneier. Ten risks of pki: Whatyou’re not being told about public key infrastructure.Computer Security Journal, 16(1), 2000.

[5] M. Gaedke, J. Meinecke, and M. Nussbaumer. Sup-porting secure deployment of portal components. InICWE 2004, number 3140 in LNCS, pages 516–520,2004.

[6] R. Housley. Cryptographic message syntax (cms).IETF RFC 3852, July 2004.

[7] Y.-G. Kim, C.-J. Moon, D.-H. Park, and D.-K. Baik.A mac-based service bundle authentication mechanismin the osgi service platform. In DASFAA, volume2973/2004 of LNCS, 2004.

[8] H.-Y. Lim, Y.-G. Kim, C.-J. Moon, and D.-K. Baik.Bundle authentication and authorization using xmlsecurity in the osgi service platform. In ICIS ’05:Proceedings of the Fourth Annual ACIS InternationalConference on Computer and Information Science(ICIS’05), pages 502–507, Washington, DC, USA,2005. IEEE Computer Society.

[9] C. Low and J. Guijarro. A smartfrog tutorial. Hewlett-Packard Development Company Whitepaper, July2006.

[10] M. Mont, P. Bramhall, and K. Harrison. A flexiblerole-based secure messaging service: Exploiting ibetechnology in a health care trial. In 14th InternationalWorkshop on Database and Expert Systems Applica-tions, DEXA 2003, pages 432–437, 2003.

[11] OSGI Alliance. Osgi service platform, core specifica-tion release 4. Draft, 07 2005.

[12] P. Parrend and S. Frenot. Secure component deploy-ment in the osgi(tm) release 4 platform. TechnicalReport RT-0323, INRIA, June 2006.

[13] P. Parrend and S. Frenot. Supporting the secure de-ployment of osgi bundles. In First IEEE WoWMoMWorkshop on Adaptive and DependAble Mission- andbUsiness-critical mobile Systems, Helsinki, Finland,June 2007.

[14] A. Shamir. Identity-based cryptosystems and signa-ture schemes. In Proceedings of CRYPTO 84 on Ad-vances in cryptology, pages 47–53, New York, NY,USA, 1985. Springer-Verlag New York, Inc.

[15] T. Stading. Secure communication in a distributedsystem using identity based encryption. In 3rdIEEE/ACM International Symposium on ClusterComputing and the Grid, CCGrid 2003, pages 414–420, 2003.

[16] Sun Microsystems, Inc. Jar file specification. Sun JavaSpecifications, 2003.

[17] X. Wang and H. Yu. How to break md5 and otherhash functions. In Advances in Cryptology - Euro-crypt’2001, volume 3494 of Lecture Notes in ComputerScience, pages 19–35. Springer, 2005.

CHAPITRE 2. SELECTION 50

2.4 Project VOSGi[Royon et al. 2006]Yvan Royon, Stephane Frenot and Frederic Le Mouel

Virtualization of Service Gateways in Multi-provider EnvironmentsIn CBSE 2006, 29/6-01/7, Västeras near Stockholm, Sweden

Virtualization of Service Gateways in

Multi-provider Environments

Yvan Royon, Stephane Frenot, and Frederic Le Mouel

INRIA Ares - CITI Lab - INSA LyonBat. Leonard de Vinci, 69621 Villeurbanne cedex, France

{yvan.royon, stephane.frenot, frederic.le-mouel}@insa-lyon.fr

Abstract. Today we see more and more services, such as entertainmentor home automation, being brought to connected homes. These servicesare published and operated by a variety of service providers. Currently,each provider sells his own box, providing both connectivity and a closedservice environment. The open service paradigm aims at mixing all ser-vices within the same box, thus opening the service delivery chain forhome users. However, open service gateways still lack important mech-anisms. Multiple service providers can access and use the same gatewayconcurrently. We must define what this use is, i.e. we must define a notionof user. Also, service providers should not interfere with each other onthe gateway, except if explicitly required. In other words, we must isolateservices from different providers, while still permitting on-demand collab-oration. By combining all these mechanisms, we are defining a multi-user,multi-service execution environment, which we call a virtualized servicegateway. We implement part of these features using OSGi technology.1

Keywords: Virtual gateway, multi-user, service-oriented programming.

1 Introduction

During the last years, high speed connectivity to the home has evolved at avery fast pace. Yesterday, home network access consisted in bringing IP connec-tivity to the home. The services made available were common application-levelprograms, such as web or e-mail clients. Today, the operators are moving tointegrating value-added services in their offer, mainly multicast TV and Voiceover IP. These network-enabled services are provided by the same connectivitybox, or by a dedicated set-top box. It is foreseen that in the next few years, boththe number and the quality of available services will increase drastically: homeappliances, entertainment, health care. . . However, these services would be de-veloped, maintained and supervised by other parties, for instance respectivelywhitegoods manufacturers, the gaming industry, and hospitals. Until today, theentire service chain and the delivery infrastructure, including the home gateway,are under the control of a single operator. Emerging standards push towardsopen solutions that enable both integration and segmentation of various mar-kets such as connectivity, entertainment, security, or home automation. This1 This work was partially supported by the IST-6thFP-507295 MUSE Project

2

approach implies that, on the single access point that connects the home net-work to the internet (i.e. the home gateway), many service vendors are each ableto deploy and manage several services.Current and ongoing service platform efforts enable multi-party service provi-sioning, but they still lack strong concepts and mechanisms to completely sup-port it. In particular, no isolation of services that belong to different parties hasbeen defined.

We propose an isolation of services, depending upon which party, or user,deploys, manages and owns them. Consequently, we also define the notion ofuser in this context. By isolation, we mean that a service provider should onlybe able to “see” her own services on the common service platform. We representthis as a virtual service gateway. Each service provider owns and manages hisown virtual gateway and the services it runs. All virtual gateways are run andmanaged by a unique core service gateway, typically hosted inside the homegateway (physical box), and operated by the home gateway provider.

The paper is structured as follows. Section 2 describes ongoing works onmulti-application Java environments. Section 3 defines the notion of virtual ser-vice gateway in this context. Section 4 explains how we implement these conceptson top of OSGi. Finally, section 5 discusses and concludes the article.

2 Multi-application Java Environments

This paper focuses on Java-based environments. Java applications are architecture-and OS-agnostic, which is an interesting feature when using very diverse hard-ware platforms (e.g. home gateways). Also, Java Virtual Machines are avail-able and already deployed on lots of architectures, which range from enterpriseservers through PCs to mobile phones. Reusing the existing software base isa key to technology acceptance. The main alternative to Java is Microsoft’s.NET. Our main concern with .NET is the lack of unloading facilities for assem-blies. This would cause the environment to grow huge if applications were oftenupdated. Therefore, in this section, we examine solutions to make the JVM amulti-application environment, which is essential for an open service gateway.

2.1 Current Java Environments

A standard Java Virtual Machine is a multi-thread but mono-application envi-ronment (figure 1). In order to run two applications, two JVMs are launched.In this case, the applications run independently, i.e. if they need to collaborate,they must access the operating system’s communication facilities (e.g. TCP/IPnetwork stack, file system. . . ). We can see that the problems with this solutionare both the overhead from running two JVMs, and the inefficiency of commu-nications, even though there are proposals to limit these [1].

There are two kinds of responses to these insufficiencies: bringing multi-application capabilities to the JVM, or using an overlay on top of the JVM,e.g. a J2EE or similar application server.

3

2.2 Multi-application Java Environments

• Sun’s Multi-tasking Virtual Machine [2] (figure 2), for instance, runs sev-eral Java applications, called isolates, in the same Java environment. Isolatesshare class representation, so that only static fields are duplicated. Applicationsare instrumented using a resource management interface, for heap memory man-agement in particular.• Rival proposals are Java operating systems [3] [4]. These mix the JVM with

the operating system layer, and often come with multi-process capabilities.• A last option is to add multi-application-like functionalities using an overlay

on top of the JVM (figure 3). The overlay is the single application that runs inthe JVM, but it allows several pseudo-applications to run concurrently on topof it.

Fig. 1. Mono-application Fig. 2. Multi-task Fig. 3. Multi-service

2.3 Isolation Terminology

The term “isolation” may imply several kinds of mechanisms. We attempt hereto basically classify them.• The first family of mechanisms is namespace isolation. A namespace is a

context for identifiers, and, in our case, for applications or services. Applicationsin different namespaces cannot “see” each other: this is an access right enforce-ment. With Java technology, this namespace isolation may be achieved throughthe use of classloaders, or more advanced loading facilities such as the ModuleLoader [5] or MJ [6].

• The second family of isolation mechanisms concerns low-level resources. Ina resource-isolated environment, applications are supposed to be protected fromone another. For instance, schedulers provided by operating systems allocateCPU slots for applications according to their priority. Recent Linux kernels alsoendorse out-of-memory kills, i.e. if a process endangers the whole system usingtoo much memory, it gets killed. Such memory protection can be qualified asa reactive mechanism, versus proactive mechanisms. An example of a proactivemechanism would be Xen’s hypervisor [7].

There are two ways to combine namespace isolation and resource isolation.The first one is to complete namespace isolation with reactive resource isolation,for instance by checking specific constraints such as CPU usage [8]. The secondone is to build a combination of proactive, strong resource isolation and names-pace isolation through the use of different virtualization techniques. Proposalssuch as Xen [7] or Denali [9] run multiple lightweight or full-featured operatingsystems on the same machine. Other attempts, such as Java isolates, provide anisolation API for Java applications.

4

2.4 Our Goals

The advantages of a modified runtime are performance (communications, mem-ory sharing) and resource isolation (see below). Inversely, the advantages ofoverlays are their usability on any standard JVM, and their ease of developmentthrough their level of abstraction. Table 1 summarizes this comparison.

Namespace Resource Performance Uses a Easiness ofisolation isolation optimizations standard JVM integration2

Modified JRE yes yes yes no intrusive

Overlay no no no yes effortlessTable 1. Summary of Multi-application Java Environments

Our goal in this paper is to define a multi-user, service-oriented Java environ-ment, without modifying the standard Java Runtime Environment. This impliesthat we use an overlay. Our contribution is divided in two steps: first we addnamespace isolation to the overlay solution, then, we add a definition of users.

3 Towards a Multi-user, Service-oriented Environment

In this section, we evoke the notion of service-orientation and its benefits. Wethen detail the terms multi-user, through the definition of core and virtual servicegateways. We explain on one hand how they should be isolated, and on the otherhand when and how they should be able to cooperate.

3.1 Service-oriented Programming

For clarification, the term “service” in this paper refers to Service-Oriented Pro-gramming (SOP). SOP is based on Object-Oriented Programming, which relieson ideas such as encapsulation, inheritance and polymorphism. SOP addition-ally states that elements (e.g. components) collaborate through behaviors. Thesebehaviors, also called services or interfaces, allow to separate what must be done(the contract) from how it is done (its implementation) [10].

Some service-oriented solutions, such as Web Services, deal with the interop-erability in communications, and are referred to as Service-Oriented Architec-tures. By contrast, SOP environments such as the OSGi Service Platform [11]and Openwings are centered on the execution environment, which is the focusof this paper.

3.2 Namespace Isolation

Core and Virtual Gateways. A core service gateway is a software element,managed by an operator. It makes resources available in order to run services.2 Easiness of integration means the easiness of developing the environment itself, using

it, and developing applications for it.

5

Such resources, physically supplied by the underlying hardware (i.e. the homegateway), include CPU cycles, memory, hard disk storage, network bandwidth,and optionally standard services (e.g. logging, HTTP connectivity). The gate-way operator grants service providers access to these resources. This access issymbolized by a virtual service gateway, and provides a namespace isolation.Figure 4 illustrates this architecture.

Fig. 4. Multi-service, namespace-isolated environment

Service cooperation. In an isolated, multi-application environment, applica-tions are cloistered by default. However, they still should be able to cooperate ondemand. In resource isolated environments, they cooperate through data com-munications. They either use standard OS facilities (e.g. sockets, IPCs, filesys-tem), or dedicated facilities (e.g. Links in the Java isolates API). By contrast,in open, non-isolated service environments, applications pass references on ser-vices (or interfaces). In an open, multi-service, multi-user, namespace-isolatedenvironment, this still must be possible if explicitly permitted. The frameworkis then responsible for passing these references.

3.3 Multi-user Java Environment

The gateway operator, through the core service gateway, acts much like a Unixroot user. He allows users (service providers) to launch their shell or execu-tion environment (their virtual service gateway). The core gateway also runsservices accessible to all users. However, contrary to Unix root users, the coregateway does not have access to service gateways’ data, files, etc, since thesewould belong to different, potentially competing companies. Figure 5 representsthe architecture with participating users.

The root user, i.e. the gateway operator, is responsible for the managementof the virtual gateways it runs. This management layer is structured around 4activities. Lifecycle management provides a mean to start and stop virtual gate-ways. Performance management provides information about the current statusof a gateway (a virtual gateway or the core gateway itself). Security managementpositions credentials and make security challenges with core and virtual gate-ways. Finally, Accounting and Logging brings information about service usagefor each gateway.

6

Fig. 5. Multi-service, multi-user residential gateway

Users, or service providers, access their virtual gateways through a remotemonitoring interface. According to the business model described in section 1,each service provider is responsible for the bundles she deploys. This means thatservice providers are encouraged to supervise their own services on their clients’service gateways. Also, some business services may inherently need remote mon-itoring: health care, home automation. . .

4 Implementation

4.1 OSGi and Virtualized OSGi

The service-oriented overlay we use for our prototype implementation is theOSGi Service Platform [11]. The OSGi specification defines a service-orientedAPI (figure 3), deployment units (components called bundles), and a container(the service platform) which guarantees dependencies resolution for hosted com-ponents.

In order to create virtual gateways, we launch several OSGi gateway instancesfrom within a core OSGi instance (figure 4). The core gateway also instrumentsand manages virtual gateways. This solution allows us to create a straightforwardmatching with the concepts of root user and users detailed above.

4.2 Service Isolation

The advantages of running several service gateway instances inside a single coregateway instance are quite immediate. Each service gateway can only accessOSGi bundles and services it directly hosts. The core gateway itself does not seethe hosted virtual gateways, but only a management agent that allows their lifecycle management. This is a straightforward way to enforce namespace isolation.

Each service provider sees his own virtual gateway as if it was a standardOSGi service platform. Therefore, at deployment time, standard OSGi deploy-ment schemes come in action. At runtime, namespace isolation is providedthrough a hierarchy of classloaders. Each deployed component (i.e. OSGi bundle)comes with its own classloader, which delegates to its service gateway’s class-loader [12]. This way, by default, services from different providers (i.e. runningin different virtual service gateways) are in different namespaces.

7

4.3 Service Cooperation

The core service gateway can provide services to its virtual service gateways.Currently, a static list of shared services and implementations is passed from thecore gateway to virtual gateways. Each virtual gateway then needs to internallypublish these shared services, so that its own services may access them. A moredynamic solution is planned, but not yet implemented.

4.4 Performance

We chose to run several OSGi Framework instances inside a core Frameworkinstance. The main drawback to this approach is that it induces a resourceconsumption overhead. We ran a first set of performance tests on a standardPentium IV PC, using a Gentoo Linux operating system, and Sun’s JDK 1.5with standard parameters (e.g. initial memory allocation pool). Our measurescompare a vanilla Oscar 1.0.5 gateway with a core gateway that runs six virtualgateways, each launching a standard set of bundles. After 24 hours, we observean overall 33% increase in memory use within the JVM’s pre-allocated mem-ory pool. This corresponds to a 2.9 MB consumption overhead. More thoroughbenchmarks are planned and under progress.

4.5 Available Code

We provide an OSGi bundle2 that allows to start and stop virtual OSGi in-stances. The project, called vosgi for Virtual OSGi, has been tested on patchedversions of both ObjectWeb’s Oscar3 and Apache’s Felix4 open source implemen-tations of the OSGi Service Platform specifications. The management activitiesexpressed in section 3 are enabled through a JMX architecture [13] called mosgi(for Managed OSGi).

5 Discussion and Conclusion

In this paper, we have proposed a first step toward a multi-user, service-orientedexecution environment. It can target the same markets as OSGi service plat-forms (mobile phones, vehicles, home gateways. . . ), while improving isolationand management.Since we use a standard Java virtual machine as the lower layer, our best optionfor service provider separation is to provide a namespace isolation. If we wantto go further into resource isolation, we need a JVM and an operating systemthat provides such a functionality. For instance, we could provide a multi-userenvironment on top of real-time virtual machines. But these are not available on2 Available at http://ares.inria.fr/~sfrenot/devel/ under the CeCILL open

source licence.3 http://oscar.objectweb.org/4 http://incubator.apache.org/felix/

8

a large scale yet, and they are not aimed at this ”in-the-middle” market (neitherembedded nor high-end PCs).

The proposed multi-user environment currently has two main alternatives.The first one is the multi-tasking virtual machine, and the second one is the useof ”standard” operating systems (e.g. Linux, Windows).From the MVM point of view, Sun’s team works on mapping OS-level usersrights within the JVM [14]. This project is aimed at big server systems thathost many users and applications (SPARC/Solaris). Inversely, our approach isfocused on embedded systems, using standard JREs. Also, we believe that coop-eration through service sharing, or interface sharing, is a better abstraction fordevelopers than data sharing (Link objects between isolates).Compared to standard operating systems, we assume that a service-oriented ap-proach is a real improvement over “classical” C programming. We argue thatboth layers (Java and service orientation) are beneficial to service developmentfor the targeted market. It enables many advantages (code structure, code hot-plugging. . . ) with only few drawbacks (mainly startup time).

References

1. Czajkowski, G., Daynes, L., Nystrom, N.: Code sharing among virtual machines.ECOOP (2002)

2. Czajkowski, G., Daynes, L.: Multitasking without comprimise: a virtual machineevolution. In: OOPSLA, New York, NY, USA, ACM Press (2001) 125–138

3. Golm, M., Felser, M., Wawersich, C., Kleinoeder, J.: The JX operating system.In: USENIX. (2002) 45–58

4. Prangsma, E.: JNode. (http://jnode.sourceforge.net)5. Hall, R.S.: A Policy-Driven Class Loader to Support Deployment in Extensible

Frameworks. In: Component Deployment, Edinburgh, UK. (2004) LNCS 3083, pp.81 - 96.

6. J. Corwin, D.F. Bacon, D.G., Murthy, C.: MJ: a Rational Module System for Javaand its Applications. In: (OOPLSA. (2003) pp. 241-254.

7. Barham, P., Dragovic, B., Fraser, K., Hand, S., Harris, T., Ho, A., Neugebauer,R., Pratt, I., Warfield, A.: Xen and the art of virtualization. In: SOSP. (2003)

8. Yamasaki, I.: Increasing robustness by code instrumenting: Monitoring and man-aging computer resource usage on OSGi frameworks. OSGi World Congress (2005)

9. Whitaker, A., Shaw, M., Gribble, S.: Denali: Lightweight virtual machines fordistributed and networked applications (2002)

10. Bieber, G., Carpenter, J.: Introduction to service oriented programming.http://www.openwings.org (2001)

11. The OSGi Alliance: OSGi Service Platform. 4th edn. IOS Press (2005)12. Liang, S., Bracha, G.: Dynamic class loading in the Java virtual machine. In:

OOPSLA. (1998) pp. 36–4413. Fleury, E., Frenot, S.: Building a JMX management interface inside OSGi. Tech-

nical report, Inria RR-5025 (2003)14. Czajkowski, G., Daynes, L., Titzer, B.: A Multi-User Virtual Machine. In: Usenix.

(2003) pp. 85–98

CHAPITRE 2. SELECTION 59

2.5 Project POSGi[?]Stéphane Frénot and Yvan Royon

Component deployment using a peer-to-peer overlayIn Working Conference on Component Deployment, 28th-29th no-vember 2005, Grenoble France

Component deployment using a peer-to-peer

overlay

Stephane Frenot and Yvan Royon

INRIA Ares - CITI Lab - INSA LyonBat. Leonard de Vinci, 69621 Villeurbanne cedex, France{stephane.frenot, yvan.royon}@insa-lyon.fr

Abstract. The deployment of component-based software applicationsusually relies on a centralized repository where the components arestored. This paper describes a peer-to-peer approach for componentsdistribution. The software components are distributed among a set ofnodes participating in the execution of services. When a node wants toinstall a component which is not present locally, this component is bothsearched and installed using a peer-to-peer network. The proposed ar-chitecture is an underlayer for OSGi application (bundles) deploymentand execution management. 1

1 Introduction

The installation of software component-based systems requires an infrastructurefor the search and distribution of these components. Typically, an HTTP or FTPserver hosts these components, and provides an indexation mechanism.

We describe a peer-to-peer (p2p) infrastructure implementation for themanagement of “installable” software components. This decentralized anddistributed infrastructure dispatches the installable components, their indexmechanism and their versioning system over a set of peer network nodes. Theexpected benefits are the distribution of storage and bandwidth load, as well asrobustness due to peer-to-peer inherent characteristics.

We propose an application of this approach to the OSGi world, which cur-rently has no standardized component deployment mechanism.

The OSGi technology is a proposition to standardize the way local servicesand peripherals are remotely operated. The OSGi specifications [1] define Java-like APIs for the execution of applications in a service-oriented programmingway. An OSGi component (the deployment unit) is called a bundle. It is aJava jar archive, described by a Java manifest file. The OSGi Service Platformmanages the bundles’ life cycles, i.e. their state: stopped, installed, resolved,started.

1 This work is partially supported by the IST-6thFP-507295 MUSE Integrated Project.

2

Deployment within the OSGi context is summarized in section 2, while sec-tion 3 proposes an approach for deployment management, based on self-organizedpeer nodes.

2 Deployment in the context of OSGi Technology

The OSGi specifications do not currently address the deployment issue. Bundlesare retrieved using a provided URI, but no deployment mechanisms are proposed.

We use OSGi platforms with a specific actors model in mind: users owna single OSGi service platform within their homes. Depending on subscriptionsthe users contract, several service providers may want to install bundles on theseunique service gateways.

The only deployment architecture currently available is OBR (Oscar BundleRepository), from the Oscar [2] open source implementation of the OSGi speci-fications. With OBR, an XML descriptor file lists and details all bundles hostedon a remote repository. The client service gateway retrieves this file and parses itto mount a memory representation of the bundle it can install. The installationis performed using HTTP requests with the URIs provided by the descriptorfile.

OBR is a centralized repository. It is therefore weak to denial of service at-tacks, as well as peaks in CPU or bandwidth loads. Also, if the central repositorycrashes, a potentially huge number of service gateways have no way to updatetheir bundle index.

All these problems are addressed by peer-to-peer networks. A peer networkcomprised of all these service gateways would be a good way to distribute bothbundles and their index. We cast our choice upon a Pastry [3] network, since itoffers an effective way to locate resources (bundles in our case) among a set ofpeer nodes. It also has interesting resource replication features, which make thewhole deployment infrastructure less error-prone.

A second problem we address is the versioning system. With the OSGi spec-ifications and OBR, bundle version numbers are internal, i.e. they only appearinside the bundle’s manifest file. This makes it impossible for a lower-layer de-ployment system to include version management. We propose to include theversion number in the bundle name, and to integrate this information withinthe peer-to-peer search mechanism. This enables service gateways for automatedand integrated bundle updates.

3 Implementing a peer-to-peer deployment network

3.1 OSGi components deployment

General Network Architecture. Our p2p deployment infrastructure forOSGi platforms uses a Pastry network. It is composed of 3 layers. The IP layeridentifies the participating OSGi service platforms. The Pastry layer allocates

3

each of these platforms a node identifier. The component layer locates OSGicomponents on the Pastry peer network.

Diffusion of a component. Any peer node can share a software componenton the network. To do so, the source node sends a deposit request for theresource. A root node identifier is computed from the resource hash key, usinga function known to all peer nodes: hash(<bundleName>) ⇒ root node ID.The route between the current node diffusing the resource and the root node isautomatically calculated by the network: the component is routed hop by hopuntil the node which identifier is the closest to the root node ID is found. Thislast node then hosts the component.

This procedure is extended to include version management. In this case,resource publication requires 2 steps (see listing 1.1). Firstly, the node withnodeID the closest to hash(<bundleName>) hosts the current version numberfor the bundle. This is obtained with the 1st call. Secondly, The actual bundle isnamed <bundleName>-<version>.jar instead of <bundleName>.jar. Its rootnode is the one with nodeID closest to hash(<bundleName>-<version>). The2nd call which achieves this.

1 . pub l i sh ( hash(<bundleName>) , < vers ion >);2 . pub l i sh ( hash(<bundleName> <vers ion >) , bytecode ) ;

Listing 1.1. Calls for publishing with version management

Installation of a component. An OSGi bundle is a Java jar archive.Its name is its identifier. To install a component, the user types the start<bundleURI> command. For coherence reasons, the URI we use follow thispattern: p2p://<bundleName>. Hence, typing start p2p://log.jar retrievesthe latest version of the log.jar bundle from the network and installs it locally.

More precisely, the client node requesting the bundle computes a hash keyfrom the bundle’s name (3rd call, listing 1.2). This call returns the currentversion for this bundle. The second step is call number 4, which returns theactual bundle in its latest version.

3 . r e t r i e v e ( hash(<bundleName > ) ) ;4 . r e t r i e v e ( hash(<bundleName> <vers ion > ) ) ;

Listing 1.2. Calls for retrieving a versioned bundle

Node insertion. A node needs to know one node of the peer network in orderto join the community. Once again, during a node insertion, Pastry’s featuresare used: resources are redistributed among the nodes for balance reasons.

4

3.2 Implementation with FreePastry/Oscar

Our implementation uses the open source Oscar [2] implementation of OSGispecification, and FreePastry [4] for peer-to-peer distribution. We provide 3 OSGibundles.2

The first one (pastryWrapper) is used by the OSGi service platform to declareitself to the peer network. The bundle manager also uses it to publish or retrievebundles.

The second bunlde (p2pHandler) extends bundleRepository from the Oscardistribution. The usual bundleRepository (OBR, Oscar Bundle Repository) isthe centralized index presented in section 2. We extend this system to integratea protocol handler for p2p:// URIs. Thus, if the bundle location follows thep2p://<bundleName> pattern, nodes using OBR directly search the peer-to-peernetwork.

Finally, the third bundle (posgiCommand) provides commands for Oscar’sshell.

4 Comments and conclusions

We have developed an infrastructure for deploying and downloading OSGi com-ponents, called bundles, over a peer-to-peer network. These bundles are down-loaded from a p2p:// URI, which we implement inside the OSGi service plat-form.

Future works include testing our implementation wide-scale. We still need tocheck Pastry’s behavior within the OSGi context. We plan to run tests within theMUSE [5] project, which aims to define home connectivity and service deliveryfor European citizens.

We would also like to investigate the simultaneous use of several publish/dis-covery protocols, depending on the context. It would then be possible to use abroadcast search on the local area network. If no node replies, then the searchis extended to routing mode. This is what Sun’s JXTA framework does. In ourcase, this is interesting when deploying applications in computer rooms: remotedownloading is done only once, and the remaining downloads are done locally.

References

1. Open Service Gateway initiative: Osgi specifications. http://www.osgi.org (2002)2. Hall, R.S.: Oscar: Object service container architecture. http://oscar.objectweb.org

(2004)3. Rowstron, A., Druschel, P.: Pastry: Scalable, distributed object location and routing

for large-scale peer-to-peer systems. In: Proceedings of IFIP/ACM Middleware.(2001) 33–34

4. FreePastry: http://freepastry.rice.edu. Rice University, Houston, Texas (2004)5. MUSE Project: Ist-507295 fp6. http://www.ist-muse.org/ (2004)

2 Available at http://ares.insa-lyon.fr/˜sfrenot/devel/

CHAPITRE 2. SELECTION 64

2.6 Project DARTS[Brebner et al. 2005]Paul Brebner, Emmanuel Cecchet, Julie Marguerite, Petr Truma, Octavian

Ciuh, Bruno Dufour, Lieven Eeckhout, Stéphane Frénot, Arvind S Krishna,John Murphy, Clark Verbrugge

A CPU Resource Consumption Prediction Mechanism for EJB de-ployment on a federation of serversIn Concurrency Computat. : Pract. Exper, 2005, vol 17, pp 1799–1805

CONCURRENCY AND COMPUTATION: PRACTICE AND EXPERIENCEConcurrency Computat.: Pract. Exper. 2005; 17:1799–1805Published online 28 June 2005 in Wiley InterScience (www.interscience.wiley.com). DOI: 10.1002/cpe.918

Middleware benchmarking:approaches, results, experiences‡

Paul Brebner1,∗,†, Emmanuel Cecchet2, Julie Marguerite2,Petr Tuma3, Octavian Ciuhandu4, Bruno Dufour5,Lieven Eeckhout6, Stephane Frenot7, Arvind S. Krishna8,John Murphy4 and Clark Verbrugge5

1CSIRO ICT Centre, G.P.O. Box 664, Canberra, ACT 2601, Australia2INRIA Rhone-Alpes/ObjectWeb, 655 avenue de l’Europe, 38330 Montbonnot, St. Martin, France3Department of Software Engineering, Charles University, Malostranske namestı 25, Praha 1,Czech Republic4Performance Engineering Laboratory, Dublin City University, Dublin 9, Ireland5School of Computer Science, McGill University, Montreal, Quebec, Canada H3A 2A76Department of Electronics and Information Systems (ELIS), Ghent University, St. Pietersnieuwstraat 41,B9000 Gent, Belgium7INRIA Ares, INSA-CITI Bat. Leonard de Vinci, 69661 Villeurbanne Cedex, France8Electrical Engineering and Computer Science, Vanderbilt University, Nashville, TN 37235, U.S.A.

SUMMARY

The report summarizes the results of the Workshop on Middleware Benchmarking held during OOPSLA2003. The goal of the workshop was to help advance the current practice of gathering performancecharacteristics of middleware implementations through benchmarking. The participants of the workshophave focused on identifying requirements of and obstacles to middleware benchmarking and forminga position on the related issues. Selected requirements and obstacles are presented, together withguidelines to adhere to when benchmarking, open issues of current practice, and perspectives on furtherresearch. Copyright c© 2005 John Wiley & Sons, Ltd.

KEY WORDS: middleware benchmarking; middleware performance; middleware scalability; middleware eval-uation; middleware benchmark design; benchmarking guidelines; benchmarking measurement;benchmarking metrics; OOPSLA 2003 workshop

∗Correspondence to: Paul Brebner, CSIRO ICT Centre, G.P.O. Box 664, Canberra, ACT 2601, Australia.†E-mail: paul.brebner@csiro.au‡This report was produced from the OOPSLA 2003 Middleware Benchmarking Workshop, homepagehttp://nenya.ms.mff.cuni.cz/projects/corba/oopsla-workshop-03/.

Copyright c© 2005 John Wiley & Sons, Ltd.Received 30 March 2004

Revised 18 May 2004Accepted 10 June 2004

1800 P. BREBNER ET AL.

1. INTRODUCTION

For over a decade, middleware has been a well-established part of numerous applications. The spectrumof middleware implementations is diverse, ranging from communication-oriented middleware such asCORBA or SOAP libraries to component-oriented application servers such as the Enterprise JavaBeans(EJB) or CORBA Component Model (CCM) containers. Naturally, an important characteristic of theseimplementations is their performance under various conditions. Such a characteristic is used both bythe middleware developers to improve and advertise their middleware and by the middleware users todecide on their middleware of choice.

The natural way to obtain the performance characteristics of a system is through benchmarking.However, although middleware benchmarking is a relatively frequent endeavor [1–11], the practiceis rather fragmented. Middleware developers use proprietary testing suites with results that are rarelycomparable across the spectrum of middleware implementations. Middleware users rely on simplistictesting suites whose results are often prone to misinterpretation when related to specific usagescenarios. Most standardization efforts in the area so far have also failed to bear fruit [12].

To remedy this situation, the participants of the Middleware Benchmarking Workshop heldduring OOPSLA 2003 shared their experience with designing, running and evaluating the existingbenchmarks. As the next step, the participants identified some of the most significant obstaclesencountered in the current practice and proposed approaches to tackle these obstacles. This reportpresents the results of the workshop in four sections, dedicated to the reasons for benchmarking,guidelines for benchmarking, open issues in benchmarking and perspectives on further research.

2. WHY BENCHMARKING?

An important statement emphasized repeatedly during the workshop debates was that the nature of abenchmark depends strongly on the intended use of the results. A benchmark that provides continuousdata to an automated load-balancing system will be different from a benchmark that provides staticdata to a system developer. The somewhat obvious character of this statement is outweighed by the lessobvious nature of its implications, which touch all aspects of benchmarking from the benchmark designthrough the measurement mechanisms to the processing of results. The following sections focus on theuse of benchmarking for the design and the evaluation of middleware, and outline the implications ofthe considered use on the nature of the benchmark.

2.1. Benchmarking to design middleware

The first use of a benchmark that was considered important by the participants of the workshopwas benchmarking to aid in the design of middleware. Essential to this use is benchmarking realapplications to see how they stress the supporting system, collecting data to create models ofsupporting system usage typical for the selected application domains. Examples of such models are theworkloads defined by the ECperf, RUBiS, SPEC jAppServer, SPEC JBB, Stock-Online and TPC-Wbenchmarks, all focusing on the online business domains. Additional models are needed for otherdomains.

Model-based techniques can be applied to visually represent techniques for defining entities andtheir interactions in the application domain using domain-specific building blocks. An example of

Copyright c© 2005 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2005; 17:1799–1805

MIDDLEWARE BENCHMARKING: APPROACHES, RESULTS, EXPERIENCES 1801

a model-based benchmarking tool is the CCMPerf benchmarking tool [10], which is a model-basedbenchmarking suite that allows developers and end-users of the CCM [13] middleware to evaluate theoverhead that CCM implementations impose above and beyond the CORBA implementation, as well asto model interaction scenarios between CCM components using varied configuration options to capturesoftware variability in higher-level models rather than in lower-level source code. The model-basedtechniques used in CCMPerf help domain experts visualize and analyze the results of performanceexperiments more effectively, since they focus on higher-level modeling abstractions, rather thanwrestling with low-level source code.

During middleware design, benchmarking should be used to determine the optimal architecture forgiven constraints, such as memory capacity, processing power, or network throughput and latency.Important in this aspect is the task of validating models created during the design and, thus, predictingthe real behavior of the architecture. Contemporary middleware is too complex to be understood purelythrough the analysis of its architecture, without benchmarking its real behavior.

Another important feature of the use of benchmarking to design middleware is the ability to captureand document consequences of using a specific architecture. An example of this approach is the workon design patterns for the server-side threading and dispatching models of TAO [14].

2.2. Benchmarking to evaluate middleware

The second use of a benchmark that was considered important by the participants of the workshop wasbenchmarking to evaluate middleware. This use of benchmarking includes comparing the performanceof various middleware architectures, as well as comparing the performance of specific middlewareconfigurations. In addition to the obvious use of the comparisons for selecting architectures andconfigurations, perspective uses include gathering data for system sizing and for determining systemstate and devising autonomic computing policies.

A benchmark needs to be able to evaluate the scalability of middleware. This implies benchmarkingthe behavior of the middleware and the supporting system when stretched to the limits of theirscalability, as well as when used within the limits of their scalability.

3. BENCHMARKING GUIDELINES

The participants of the workshop also noted that many benchmarking projects tend to repeat commonmistakes that devalue the results. Prominent among the common mistakes was an incorrect choiceof metrics. Timestamps alone are not necessarily sufficient for understanding the results; annotatingtimestamps with system utilization and resource consumption data for the supporting system is useful.

A pitfall that can lead to useless results is using benchmarks that rely on an artificial workload such asthe microbenchmarks of an isolated feature of the middleware. It is difficult to conclude anything aboutthe behavior of real applications from the results of such benchmarks, and their use should thereforebe limited and well justified.

The measurement technique in benchmarking is equally important. Particular performance measuresor metrics may have a variety of intertwined effects, and a change or improvement in one measurementwill usually affect many other quantities as well. A reduction in the number of method callsexecuted due to a method-inlining optimization, for instance, will increase code size, which may

Copyright c© 2005 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2005; 17:1799–1805

1802 P. BREBNER ET AL.

alter cache performance. In order to make valid overall performance judgments, evaluations basedon quantification must not only focus on providing a comprehensive representation of the benchmarkthat reveals important qualities, but also on understanding the inevitable dependencies betweenmeasurements.

Building a comprehensive view through measurement is itself challenging. A small, fixed suite ofmeasurements is desirable since it makes comparisons simple and human comprehension feasible.Any reduced set of measures, however, may not give a true indication of benchmark activity and iscertainly unlikely to capture all possible quantities of interest. A more reasonable approach is to permita rough assessment through a few general measurements, but also calculate more specific measures inorder to allow exploration of an apparent behavior through other perspectives and finer-grained detail.Evaluating a benchmark numerically is then a process of drilling down until one is satisfied that a clearunderstanding of the behavior has been determined [15].

Another pitfall is related to the interpretation of the results. The results must reflect the working ofthe measured feature and not interference from other features. That is especially true for warming upthe system under test to a steady state to filter out interference such as cache priming, which is knownto take minutes for simple benchmarks and can stretch to hours when complex mechanisms such asgarbage collection or database access are involved. A similar concern applies to the interference fromthe workload injection limits with the system under test.

It may not be easy or straightforward to assess performance. Execution activity at various levels fromthe lowest to the highest will alter performance, and so must be understood in order to give an accurateevaluation. This is particularly true of low-level concerns; while the impact of higher-level algorithmdesign (and even of code generation choices) may be well understood by an application developer,low-level issues such as cache sizes, branch-predictor strategy and so on can have a significant impacton the actual performance cost of various benchmark actions. For instance, an interpretation that abenchmark is making a lot of method calls may not be indicative of excessive execution overhead ifeach call is correctly predicted by the processor. Therefore, a benchmark evaluation based on numericaldata must be careful to account for all possible system features.

Particular care must be taken to understand, explore and document the impact of virtual machines formiddleware that critically depends on them. This is an often poorly understood aspect of benchmarkingJava middleware, which makes heavy demands on the Java Virtual Machine (JVM). The brand ofJVM, number running per machine, settings, type of engine and type of garbage collector can haveconsiderable (and not easily predicted) impacts on middleware performance and scalability, and hencebenchmark results (see, for example, [16]).

As a general guideline, the participants of the workshop agreed that it is important to releaseexhaustive configuration information together with any results. In addition to the obvious need forreproducibility of the results, the information can be used for assessing the impact of configurationchanges on the results.

Note that interpretation of numerical data will only be valid when the measurement is preciselydefined. Many analyses fail to include enough information about how the measurement is actuallycalculated, making it not only difficult to reproduce and verify results, but also difficult to makecomparative assessments. For example, lines of code, a traditional measurement of static applicationsize, is easily perturbed by programming style and a variety of potential measurement possibilities(should it count blank lines, comment lines, etc.). Choices by different experimenters will often differ,and so exact metric definitions have an obvious necessity.

Copyright c© 2005 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2005; 17:1799–1805

MIDDLEWARE BENCHMARKING: APPROACHES, RESULTS, EXPERIENCES 1803

4. OPEN ISSUES

Paramount among the open issues was the question of the resources needed to conduct benchmarking,in terms of machinery, time to run the benchmarks and expertise needed to understand the completesetup of the benchmarks. The participants of the workshop agreed that the resource requirements areoften prohibitive to conducting benchmarking, especially in a research environment with stringentrequirements on results. An additional complication is that the lifetime of the expertise and the resultsis short, which increases the cost of benchmarking.

A benchmark should be indicative of the performance of a real application. This implies the needfor real workloads, but such workloads tend to be unsuitable for benchmarking because of their size.Determining what substitute workloads are representative of real workloads is an important open issue.

During microprocessor design, computer architects face similar problems due to extremely longsimulation times—it is not exceptional that simulating one second of a real system takes 24 hours.Several techniques have been proposed to address this issue in the context of uniprocessor performancemodeling. Sampling [17–19] refers to selecting samples from a complete program run. Since thenumber of sampled instructions is smaller than the total number of instructions in a complete programrun, significant simulation speedups can be obtained. Important issues that need to be dealt withare which samples to select and how to guarantee a correct hardware state at the beginning ofeach sample. A second technique is to use reduced input sets [20,21]. These reduced input setsare derived from longer reference inputs by a number of techniques: modifying inputs, truncatinginputs, etc. The benefit of these reduced inputs is that the dynamic instruction count when simulatingthese inputs can be significantly smaller than for the reference inputs. A third approach is to applystatistical simulation [22–24]. The idea of statistical simulation is to define and collect a numberof important program characteristics, to generate a synthetic workload from it that is several ordersof magnitude smaller than a real application and, finally, to simulate this synthetic workload. If thesynthetic workload captures the right characteristics, the behavior of the synthetic workload and thereal application will be similar.

A key issue that needs to be dealt with for all of these techniques is to determine whether thesubstitute workload is representative of the real workloads. Previous work has shown that statisticaldata analysis techniques could be useful for this purpose [25]. We believe that adapting these methodsto the context of middleware benchmarking could be extremely useful in speeding up measurementtime while preserving the representativeness of the substitute workload. How to do this, however,remains an open issue.

With the middleware being just one part of a layered architecture, typically supported by theoperating system or even another middleware, the results of middleware benchmarking depend notonly on the middleware itself, but also on the supporting architecture. An open issue is how to abstractfrom the supporting architecture and characterize only the middleware layer, perhaps together with theinteractions between layers.

A representative example of a layered architecture is the CCM [13], where the CCM applicationssit on top of a CORBA ORB, which comprises three layers. The host infrastructure layer isthe middleware layer that provides a uniform abstraction over the underlying operating system.The distribution middleware layer is the middleware layer such as CORBA that abstracts the datamarshaling and connection management facilities. The common middleware services layer is themiddleware layer that provides services. Benchmarks for CCM implementations are thus heavily

Copyright c© 2005 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2005; 17:1799–1805

1804 P. BREBNER ET AL.

influenced by the underlying layers and it is necessary to characterize the influence of these layersin isolation.

An open issue of an entirely different nature is that of dealing with the publication of resultsfor commercial products. Such results can often damage any of the concerned sides through real orperceived bias, or through simple misinterpretation.

5. PERSPECTIVES

With the numerous technical issues, it might be beneficial to keep a knowledge base of benchmarkingexpertise that would list such issues and thus help to keep research free of engineering mistakes.The question that remains unanswered is how to keep such a knowledge base up to date.Similar reasoning supports an open database of benchmarking results similar to the CORBABenchmarking Project [9]. Such a database could help extract different information from the sameresults depending on the nature of the research that uses the results. The database would requiresolutions to the issues of anonymity, reliability and credibility of the results. The related technicalissue of common data format would also need to be solved to facilitate sharing the results and the toolsto process them.

Another beneficial step to the benchmarking efforts would be to get the middleware designersinterested in supplying the recommended settings for specific applications and workloads.With representative workloads for selected application domains, this would help to avoid publishingresults that are incorrect because of misconfiguration, especially for commercial products that oftenhave complex or undocumented settings that influence benchmark results.

REFERENCES

1. Boszormenyi L, Wickener A, Wolf H. Performance evaluation of object oriented middleware—development of abenchmarking toolkit. Proceedings of the 5th International Euro-Par Conference (EuroPar-99) (Lecture Notes in ComputerScience, vol. 1685). Springer Berlin, 1999.

2. Callison HR, Butler DG. Real-time CORBA Trade Study. Boeing, 2000.3. Cecchet E, Chanda A, Elnikety S, Marguerite J, Zwaenepoel W. Performance comparison of middleware architectures for

generating dynamic Web content. Proceedings of the 4th ACM/IFIP/USENIX International Middleware Conference, 2003.ACM Press: New York, 2003.

4. Cecchet E, Marguerite J, Zwaenepoel W. Performance and scalability of EJB applications. Proceedings of the 2002 Object-Oriented Programming, Systems, Languages and Applications (OOPSLA-02). ACM SIGPLAN Notices 2002; 37(11).

5. Gokhale S, Schmidt DC. Measuring and optimizing CORBA latency and scalability over high-speed networks. IEEETransactions on Computers 1998; 47(4).

6. Juric MB, Rozman I. RMI, RMI-IIOP and IDL performance comparison. Java Report 2001; 6(4).7. Juric MB, Rozman I, Stevens AP, Hericko M, Nash S. Java 2 distributed object models performance analysis, comparison

and optimization. Proceedings of the 2000 International Conference on Parallel and Distributed Systems (ICPDAS-00).IEEE Computer Society Press: Los Alamitos, CA, 2000.

8. Tuma P, Buble A. Open CORBA benchmarking. Proceedings of the 2001 International Symposium on PerformanceEvaluation of Computer and Telecommunication Systems (SPECTS-01). SCS, 2001.

9. Distributed Systems Research Group. CORBA Benchmarking Project, Charles University. http://nenya.ms.mff.cuni.cz.10. Institute of Software Integrated Systems. CCMPerf: Model integrated test and benchmarking suite, Vanderbilt University.

http://www.dre.vanderbilt.edu/∼arvindk/MIC/ccmperf.htm.11. Gorton I, Liu A, Brebner P. Rigorous evaluation of COTS middleware technology. IEEE Computer 2003; (March):50–55.12. Object Management Group. White paper on benchmarking. OMG Document bench/99-12-01, Object Management Group,

1999.

Copyright c© 2005 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2005; 17:1799–1805

MIDDLEWARE BENCHMARKING: APPROACHES, RESULTS, EXPERIENCES 1805

13. Wang N, Schmidt DC, O’Ryan C. An overview of the CORBA component model. Component-Based SoftwareEngineering, Heineman G, Councill B (eds.). Addison-Wesley: Reading, MA, 2000.

14. Schmidt DC, O’Ryan C. Patterns and performance of distributed real-time and embedded publisher/subscriberarchitectures. Journal of Systems and Software (Special Issue on Software Architecture Engineering Quality Attributes)2003; 66(3):213–223.

15. Dufour B, Hendren L, Verbrugge C. Problems in objectively quantifying benchmarks using dynamic metrics. SableTechnical Report 2003-6, McGill University, 2003.

16. Brebner P. Is your AppServer being crippled by the JVM? Proceedings of the 5th Annual Borland Conference Asia Pacific,Sydney, 2002.

17. Conte TM, Hirsch MA, Menezes KN. Reducing state loss for effective trace sampling of superscalar processors.Proceedings of the 1996 International Conference on Computer Design (ICCD-96). IEEE Computer Society Press:Los Alamitos, CA, 1996.

18. Sherwood T, Perelman E, Hamerly G, Calder B. Automatically characterizing large scale program behavior. Proceedingsof the 10th International Conference on Architectural Support for Programming Languages and Operating Systems(ASPLOS-X). ACM Press: New York, 2002.

19. Wunderlich RE, Wenisch TF, Falsafi B, Hoe JC. SMARTS: Accelerating microarchitecture simulation via rigorousstatistical sampling. Proceedings of the 30th Annual International Symposium on Computer Architecture (ISCA-30). ACMPress: New York, 2003.

20. Eeckhout L, Vandierendonck H, De Bosschere K. Designing computer architecture workloads. IEEE Computer 2003;36(2).

21. KleinOsowski J, Lilja DJ. MinneSPEC: A new SPEC benchmark workload for simulation-based computer architectureresearch. Computer Architecture Letters 2002; 1.

22. Eeckhout L, Nussbaum S, Smith JE, De Bosschere K. Statistical simulation: Adding efficiency to the computer designer’stoolbox. IEEE Micro 2003; 23(5).

23. Nussbaum S, Smith JE. Modeling superscalar processors via statistical simulation. Proceedings of the 2001 InternationalConference on Parallel Architectures and Compilation Techniques (PACT-2001). IEEE Computer Society Press:Los Alamitos, CA, 2001.

24. Oskin M, Chong FT, Farrens M. HLS: Combining statistical and symbolic simulation to guide microprocessor design.Proceedings of the 27th Annual International Symposium on Computer Architecture (ISCA-27). ACM Press: New York,2000.

25. Eeckhout L, Vandierendonck H, De Bosschere K. Quantifying the impact of input data sets on program behavior and itsapplications. Journal of Instruction-Level Parallelism 2003; 5.

26. Center for Distributed Object Computing. The ACE ORB (TAO), Washington University.http://www.cs.wustl.edu/∼schmidt/TAO.html.

Copyright c© 2005 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2005; 17:1799–1805