Your SlideShare is downloading. ×
EnhancingOSGi with Explicit, Vendor Independent Extra-functional Properties
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

EnhancingOSGi with Explicit, Vendor Independent Extra-functional Properties

73
views

Published on

Current industry and research organisations invest considerable effort to adopt component based programming which is promising rapid development process. Several issues, however, hinder its wider …

Current industry and research organisations invest considerable effort to adopt component based programming which is promising rapid development process. Several issues, however, hinder its wider adoption. One of them is the practical use of extra-functional properties (EFPs) that research community aims at integrating to component composition but for which industrial applications are still rare. When extra-functional properties are not considered or misinterpreted, inconsistencies in application performance, security, reliability, etc. can result at run-time. As a possible solution we have proposed a general extra-functional properties system called EFFCC. In this paper we show how it can be applied to an industrial component model, namely the OSGi framework. This work analyses OSGi from the extra-functional properties viewpoint and shows how it can be enhanced by EFPs, expressed as OSGi capabilities. The proposed benefits of the presented approach are seamless integration of such properties into an existing framework and consistency of their interpretation among different vendors. This should support easier adoption of extra-functional properties in practice.

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
73
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Enhancing OSGi with Explicit, Vendor Independent Extra-functional Properties Kamil Ježek Premek Brada Lukáš Holý Department of Computer Science and Engineering University of West Bohemia Univerzitni 8, 30614 Pilsen, Czech Republic {kjezek|brada|lholy}@kiv.zcu.cz TOOLS 2012 1 / 17
  • 2. Introduction Agenda Component-based programming + Extra-functional properties Semantics weak extra-functional properties in OSGi Proposed semantic rich extra-functional properties Application to OSGi 2 / 17
  • 3. Component-based Programming Motivation Motivation Motivation Component deployment Different vendors From repository Binding compatibility checks Development Assembly Component independently developed and deployed Different groups of people involved Compatibility verification more important than before Extra-functional properties should be considered 3 / 17
  • 4. Component-based Programming Motivation Extra-functional Properties Overview What are Extra-functional Properties? No common understanding: Palladio simulates systems to asses performance and reliability ProCom defines parametrised values PECOS composes Petri-nets to model timing and synchronisation In this work: An extra-functional property holds measurable values, explicitly provided with a software system, to specify a characteristic of the system apart from its genuine functionality, to enrich client’s understanding of the usage of the system, supported by technical [computational] means. E.g.: System A: Require - network_speed = 10Mb/s 4 / 17
  • 5. OSGi Overview OSGi Overview OSGi is: Industrial standard to modularised systems Modules (components) Java jar files – called Bundles Explicit lifecycle of Bundles from Install and Start to Stop and Uninstall Strong isolation of each Bundle (on classpath level) Communication (among others) via explicitly registered services Only exported packages are accessible Better isolation control than Java coarse grained access modifiers Provided and required features explicitly stated in manifest file 5 / 17
  • 6. OSGi Parametrised Binding OSGi Parametrised Packages Parametrised packages Export-Package: cz.zcu.kiv.web.html; version=1.3,html_version=5.0 Import-Package: cz.zcu.kiv.web.html;version=1.3; resolution:=optional,html_version=5.0 version – build-in parameter html_version – user defined parameter Drawbacks: No explicit semantics and unification of user defined parameters (e.g. html_version vs. version_html) Different vendors do not have to even know existence of these parameters 6 / 17
  • 7. OSGi Parametrised Binding OSGi Capabilities Capabilities: Provide-Capability: cz.zcu.kiv.web.ui;ui_library=Qt Require-Capability: osgi.ee; filter:="(|(ui_library=GTK)(ui_library=Qt))" osgi.ee – build-in name-space cz.zcu.kiv.web.ui – user defined name-space Drawback: Name-spaces should have proposed semantics, however, no technical mean to exchange user defined ones among developers is provided 7 / 17
  • 8. OSGi Parametrised Binding OSGi Parametrised Services Parametrised services: HashTable ht = new HashTable(); ht.put("network_speed", 10); bundleContext.registerService(Net.class, this, ht); services = bundleContext.getServiceReferences( Net.class, "(network_speed >= 10)"); Drawback: Developers must study source-code or run bundles to determine services parameters Declarative Services: Services defined in XML files Solves need to study source-code Semantics of parameters still weak 8 / 17
  • 9. EFFCC Overview Proposed Solution EFFCC – Extra-Functional properties Featured Compatibility Checks Explicit definitions of properties in repository Same properties shared by different developers Properties grouped by application domain Semantics assigned for each domain Sub-domains supported Component deployment OSGi EF FCC Powered Different vendors EFPs from repository Binding compatibility checks Development Assembly 9 / 17
  • 10. EFFCC Example and Formalisation EFFCC Example and Formalisation e = (n, Ed , γ, V , M) GR = (id, name, {ei }) 462, Browser: { network_speed, {}, Integer, decreasing, {fast, slow}, "Mb/s", ... } LR = (id, GR, name, {LRi }, S, D) 463, Intel Dual Core 2.8GHz { network_speed: slow = [1..10), fast = [10..100), ... A = F ×E ×VA , VA = S×D×V ×computed RenderingEngine { Require-Capability : 462.network_speed = 463.slow, .. 10 / 17
  • 11. Application to OSGi Enriched OSGi Parameters Semantics Enriched OSGi Parameters Semantics All properties stored in unified remote repository (J2EE Server) Actually used properties mirrored in XML file, distributed with Bundles XML contains semantic rich properties Original OSGi parameters, attributes and filters linked with XML files GR: e1, e2, ... LR1: s1, s2, … , d1, d2, ... LR2: s1, s2, ... LR3: ... e : properties s, d : simple, derived values f : features Repository Mirror f1: (e1,(LR1,s1)) f2: (e1, (LR2,d2)) f3: (e1, „value“) f4: (e1, ...) MANIFEST.MF <ds>.XML 11 / 17
  • 12. Application to OSGi Attributes, Parameters and Filters Format Attributes, Parameters and Filters Format New proposed format to write down OSGi attributes and filter: <gr-id>.<efp>=<lr-id>.<value> <gr-id> – link to XML domain definitions part <lr-id> – link to XML sub-domain part <value> – value from XML, original OSGi value or formula E.g.: Original OSGi: network_speed = 10 Enriched OSGi: 462.network_speed = 463.slow 462.dhtml = 465.computed, true ⇔ jsver > 0&htmlver ≥ 4 12 / 17
  • 13. Application to OSGi Enriched OSGi Life-cycle Enriched OSGi Life-cycle ResolverHook Services Packages, Capabilities FindHook 13 / 17
  • 14. Application to OSGi Enriched OSGi Life-cycle Implementation Two hook methods: ResolverHook: void filterMatches(BundleRequirement requirement, Collection<BundleCapability> candidates) It represents set of candidates fulfilling requirement FindHook: void find(BundleContext context, String name, String filter, boolean allServices, Collection<ServiceReference<?>> references); It represents set of services fulfilling name and service filter In both cases, candidates can be removed according to additional compatibility checks 14 / 17
  • 15. Application to OSGi Enriched OSGi Life-cycle Implementation (II) 15 / 17
  • 16. Conclusion Conclusion OSGi allows ad-hoc extra-functional properties definitions Package export/import allows only comparison to equality (replaceable by capabilities) Limited number of data types (Number, String, Version) User-defined types may be added. Unfortunately, not implemented in Apache Felix and Equinox (solution: external “manifest”) Problem to evaluate e.g. “slow” vs. “fast” – OSGi compares as Strings Generic extra-functional properties mechanism proposed Mechanism applied to OSGi OSGi extended but not modifications Declarative services suggested 16 / 17
  • 17. Questions Thank you for your attention Contact us: {kjezek|brada|lholy}@kiv.zcu.cz Research group: http://www.kiv.zcu.cz/research/groups/dss/ EFFCC project: http://www.assembla.com/spaces/show/efps 17 / 17