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.
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
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
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