1. 1/151/15 ENT Metamodel Implementation & Applications ENT metamodel, prototype implementation Component substitutability checking, ENT based component comparison Case Study: Component model OSGi Automated generating OSGi component versions Future work Lukáš Valenta & what are we working on…

2. 2/152/15 ENT Metamodel Element – interface element Name, type Additional non-functional information – Tag Classification:  Nature, Kind, Role, Granularity, Construct, … Trait – related elements Equal classifier and meta-type Set of traits defines the component model Categories – „similar“ traits Defined „angle of view“ f Exports : role = { provided } f Needs : role = { required }

3. 3/153/15 ENT Metamodel Implementation - Review of the Diploma Thesis 3 parts Definition of the concrete component model Classification system and categories ENT representation of the component Applicable for any component model (now implemented: EJB, OSGi ) New: ENT based component comparison

4. 4/154/15 Component Substitutability Checking “a substitute component should be usable whenever the current one was expected, without the client noticing it” [Wegner, Zdonik, 1988] “instances of type T' can be bound to variables declared to be of type T if T‘ <: T (subtype)” short <: long structured types: use rules recursively until primitive types are reached Issue with statically typed languages (Java, C++, …) Although int <: long, runtime error! 1none If a = b 2 insertion if a is not defined but b is specialization if b <: a 3 deletion if b is not defined but a is generalization if a <: b 4mutation if b contains both ins/spec and del/gen differences 5unknown If b cannot be compared to a Compare two types a and b: Diff(a,b): Type x Type -> differences It returns:

5. 5/155/15 ENT Based Component Comparison Comparing structured types (e.g. whole components) Input: ENT representations of two components (elements, tags) Appropriate parts are compared using subtyping rules = The rules for comparing various metatypes e.g. Enumeration:  Subtyping relation between values of the set must be specified  Authentication: supported <: required List, Map, … Output: comparison result

6. 6/156/15 Comparison Result Representation Hierarchical (tree) structure Complete information for all levels of comparison  “custom” depth XML representation Log Service Mutation Mutation Mutation Mutation Insertion Generalization None

7. 7/157/15 Case Study: Generating OSGi Component Versions Practical use of ENT component comparison for OSGi platform We are able to compare two components and get the complete information about the changes (at any „level of detail“)

8. 8/158/15 OSGi Service Platform Open Services Gateway initiative Common architecture to develop, deploy and manage services Target range: embedded/mobile devices  enterprise servers The core formed by the Framework (= container) Supports the deployment of applications called bundles Why? Simple component model … but contain versioned dependencies, industrial importance Practical applications: Eclipse Platform (Equinox) Enterprise Component Framework (ECP)

9. 9/159/15 OSGi Bundle Bundles can share Java packages (exporters  importers) and provide services Bundle = JAR archive Java classes + other resources needed to provide functionality Manifest file  Description of the contents  Provide information about the bundle  Specification of bundle dependencies  …  Primary source for generating the bundle ENT representation Bundle-Name: A Export-Package: cz.zcu.logging;version=1.3.0

10. 10/15 OSGi Bundle – Versioned Dependencies Every exported package has version identifier Well-known versioning schema: major.minor.micro  major – incompatible change  minor – compatible change in component interface  micro – change not affecting interface (e.g. bugfix) Importers can specify the version range of required packages (+ other constraints) Framework resolves all constraints and link importers to the right exporters Valid version identifiers  all possible problems identified already in the deployment phase Valid version identifiers = important ! Bundle-Name: A Export-Package: cz.zcu.logging;version=1.3.0 Bundle-Name: B Import-Package: cz.zcu.logging;version=“[1.2.6, 2)”

11. 11/15 Differences and Versioning Related In general: there is a connection between the change and the new version identifier The knowledge of difference between two subsequent versions of an interface part is sufficient to determine the new version identifier of that part d = Diff (R i-1, R i ) : difference between two consecutive revisions V old = maj old.min old.mic old : version of R i-1 The new version identifier V new = maj new.min new.mic new is defined: Diff (R i-1, R i )maj new min new mic new nonemaj old min old mic old +1 specialization, insertion maj old min old +10 deletion, generalization, mutation maj old +100 unknown

12. 12/15 Generating OSGi Component Versions

13. 13/15 Example Bundle-Name: A Bundle-Version: 2.2.6 Export-Package: cz.zcu.logging;version=1.2.5 Require-Bundle: B Bundle-Name: A Bundle-Version: ?.?.? Export-Package: cz.zcu.logging;version=?.?.? Require-Bundle: B, C Previous version:New version: Exported package is specialized  new version 1.3.0 The whole bundle has new required dependency (C)  its “needs” are specialized  bundle is generalized (backward strict incompatible)  new version 3.0.0

14. 14/15 Future Work – My Ideas Try to find a way to solve a problem with statically typed languages (Java) Automated creation of the connectors between the „incompatible“ interfaces

15. 15/15 Conclusion At the abstract level of the component representation we can do the substitutability checks Another component model can be added easily – implement the compare method for particular elements and tags The result can be used for another applications Thank you