ENT Metamodel Implementation & Applications

1. ENT MetamodelImplementation & Applications & what are we working on… • 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

2. ENT Metamodel • Element – interface element • Name, type • Additionalnon-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 } fNeeds: role = { required }

3. 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. Component Substitutability Checking Compare two types a and b: Diff(a,b): Type x Type -> differences It returns: • “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!

5. 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. Comparison Result Representation • Hierarchical (tree) structure • Complete information for all levels of comparison • “custom” depth • XML representation <component ctype="OSGi_R4" model="OSGi_R4"> <name>Log Service</name> <part name="" level="component"> <diff>Mutation</diff> <part name="Exports" level="category"> <diff>Mutation</diff> <part name="export_types" level="trait"> <diff>Mutation</diff> <part name="cz.zcu.Logger" level="class"> <diff>Mutation</diff> <part name="flush()" level="method"> <diff>Insertion</diff> </part> <part name="getItemCount()" level="method"> <diff>Generalization</diff> </part> </part> </part> <part name="Needs" level="category"> <diff>None</diff> </part> </part> </component>

7. Case Study: Generating OSGi Component Versions • Practical use of ENTcomponent 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. 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. 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. 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 inthe 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. 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(Ri-1,Ri): difference between two consecutive revisions • Vold = majold.minold.micold : version of Ri-1 • The new version identifier Vnew = majnew.minnew.micnew is defined:

12. Generating OSGi Component Versions

13. 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 Example Previous version: New version: 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

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