Building modular software with OSGi - Ulf Fildebrandt
Upcoming SlideShare
Loading in...5
×
 

Building modular software with OSGi - Ulf Fildebrandt

on

  • 1,207 views

OSGi Community Event 2013 (http://www.osgi.org/CommunityEvent2013/Schedule)

OSGi Community Event 2013 (http://www.osgi.org/CommunityEvent2013/Schedule)

ABSTRACT

Statistics

Views

Total Views
1,207
Slideshare-icon Views on SlideShare
1,207
Embed Views
0

Actions

Likes
1
Downloads
41
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Building modular software with OSGi - Ulf Fildebrandt Building modular software with OSGi - Ulf Fildebrandt Presentation Transcript

    • Building Modular Software with OSGi Ulf Fildebrandt
    • Some words before This presentation should… • …give some insights in big software products • …and how the structure of these products is managed
    • About the presenter • • • • • Ulf Fildebrandt Studied computer science Works for SAP since 1998 Starting with C++ and COM Development in Java for Java EE server and Eclipse (even Eclipse 2.x) • Product architect of SAP Netweaver Composition Environment (Java stack) • Program architect of SAP Netweaver 7.30 • Program architect of Integration on Java on demand stack
    • Agenda Problem statement Goals Implementation of Modularity Measurement of Modularity
    • „In every phenomenon the beginning remains always the most notable moment.“ Thomas Carlyle Findbugs Analysis by Structure 101 SAP Netweaver Structure PROBLEM STATEMENT
    • Findbugs Analysis • Famous analysis done by Ian Sutton • Can be found at http://structure101.com/blog/2008/11/softw are-erosion-findbugs/ • Used Structure 101 (see also JAX 2012 innovation award for Restructure 101)
    • Findbugs 0.7.2
    • Findbugs 0.8.6
    • Findbugs 0.8.7
    • Findbugs 1.0.0
    • Findbugs 1.3.0
    • Findbugs 1.3.5
    • Server Analysis • SAP Java server’s own analysis tool • It shows the structure of the current Netweaver server • In contrast to Structure 101 it does not only show Java dependencies (packages) but also: – Usage Types – Software Components – Packages
    • Structure of Complex System – I Overview of product http://pwdfm295.wdf.sap.corp:9090/makeresults/ce.lc.reporting/NW730EXT_SP_COR/gen/dbg /java/packaged/full/_doc_pkg/content/index.html
    • Structure of a Complex System – II Basic Scenario
    • Structure of a Complex System – III Detailed dependencies
    • „...it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others.“ David Parnas Substitutability Extensibility GOALS
    • Software Development Goals Modules Manage complexity of software systems by „divide and conquer“ (see http://firstround.com/article/Th e-one-cost-engineers-andproduct-managers-dontconsider#) A module is a self-contained component of a system, often interchangeable, which has a well-defined interface to the other components. http://en.wiktionary.org/wiki/module
    • Software Development Goals Principles Extensibility Substitutability A module is a self-contained component of a system, often interchangeable, which has a well-defined interface to the other components. http://en.wiktionary.org/wiki/module
    • Software Development Goals One Product One system can evolve over time and modules can be replaced without impacting the other modules.
    • Software Development Goals Multiple Products Product 1 Product 2 Common modules Multiple systems can be assembled in different products and do not have to be implemented again and again.
    • Demo
    • „Programming without an overall architecture or design in mind is like exploring a cave with only a flashlight: You don't know where you've been, you don't know where you're going, and you don't know quite where you are.“ Danny Thorpe Process in development MODULARITY BY INTENTION
    • Process to define modular software Select modular runtime Definition of modules Measurement of metrics Decoupling •SOLID •Design Pattern Active definition of system
    • Definition of modules Decoupling •SOLID •Design Pattern Measurement of metrics Select modular runtime Active definition of system Packages Services Lifecycle BASIC MODULARITY WITH OSGI
    • Package Dependencies of a Bundle Bundle (internal packages) Imported Package Imported Package Exported Package Exported Package (internal packages) Bundle • Bundle exports only defined packages • Packages can be imported from other archives (bundles) • All other packages are only visible inside the bundle
    • Lifecycle of a Bundle install installed start starting resolve uninstall resolved uninstall uninstalled active stop stopping
    • How to achieve modularity... • OSGi is a framework on top of Java • Complements Java very good • ...but not suffient, because complex system require higher-level structure  OSGi subsystem specification
    • Subsystems • Subsystems bundle many OSGi bundles • Defined in OSGi R5 Enterprise Specification • Reference implementation in Apache Aries (http://apache.aries.org) http://coderthoughts.blogspot.de/2013/04/osgi-subsystems.html
    • Definition of modules Decoupling •SOLID •Design Pattern Measurement of metrics Select modular runtime Active definition of system Facade Factory PRINCIPLES AND PATTERNS - DESIGN PATTERN (GOF)
    • Factory – I A factory is an object for creating other objects. It is an abstraction of a constructor. http://en.wikipedia.org/wiki/Factory_(software_concept) • A factory externalizes the creation of objects • Creation and usage of objects is decoupled • Pattern definition works for coding Without factory: DataAggregator da = new DataAggregator(); With factory: IDataAggregator aggregator = DataAggregatorFactory.getInstance();
    • Factory – II Apply on component level • Externalization of creation of objects is a general pattern How can OSGi help: • Service registry provides an abstraction between provider and consumer of a service (object instance) • Creation of instances of a service can be handled by frameworks: – Declarative services – Blueprint
    • Facade – I A facade is an object that provides a simplified interface to a larger body of code, such as a class library. http://en.wikipedia.org/wiki/Facade_pattern Facade: public interface IDataAggregator { public List<IDataItem> get(); } Implementation of facade: final class IdentityDataAggregator extends DataAggregator { @Override public ArrayList<IDataItem> get() { List<IDataItem> itemList = new ArrayList<IDataItem>(); ... return itemList; } }
    • Facade – II Apply on component level • Access to a component as a general pattern How can OSGi help: 1. Services are Java interfaces 1. Service implementations are accessed via interface = facade 2. Exported packages are the only external visible entities of a bundle 1. 2. Not exported packages are not accessible Clear definition of a facade of the bundle
    • Definition of modules Decoupling •SOLID •Design Pattern Measurement of metrics Select modular runtime Active definition of system Dependency Injection (SOLID) Liskov (SOLID) PRINCIPLES AND PATTERNS - SOLID
    • Dependency Injection – I Dependency injection involves at least three elements: • a dependent consumer, • a declaration of a component's dependencies, defined as interface contracts, • an injector (sometimes referred to as a provider or container) that creates instances of classes that implement a given dependency interface on request. The dependent object describes what software component it depends on to do its work. The injector decides what concrete classes satisfy the requirements of the dependent object, and provides them to the dependent. http://en.wikipedia.org/wiki/Dependency_injection
    • property method method property method method method property method Class 1 method property method Dependency Injection – II Class 2
    • Dependency Injection – III Apply on component level • Reverse the dependency is a general pattern How can OSGi help: • Service registry provides an abstraction between provider and consumer of a service (object instance) • Injecting dependencies can be handled by additional frameworks – Declarative services – Blueprint
    • Liskov Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T. http://en.wikipedia.org/wiki/Liskov_substitution_principle Facade = T: public interface IDataAggregator { public List<IDataItem> get(); } Implementation of facade = S: final class IdentityDataAggregator extends DataAggregator { @Override public ArrayList<IDataItem> get() { List<IDataItem> itemList = new ArrayList<IDataItem>(); ... return itemList; } }
    • Definition of modules Decoupling •SOLID •Design Pattern Measurement of metrics Select modular runtime Active definition of system Architecture Layer SYSTEM ARCHITECTURE
    • Architecture Layer – I • • • … Package … Module Sub system System Layer System Platform • … … • • • A platform (in terms of runtime framework) hosts a system and is a versioned artifact A system consists of a set of sub-systems and is a versioned artifact running on a platform A system layer groups sub-systems providing structure and direction in terms of dependencies and is a layer which has no associated versioned artifact A system layer incarnation is the bill of materials or assembled sub-systems of a system layer relevant for a specific use case A sub-system consists of a set of modules and is a versioned artifact A module contains packages and is a versioned artifact A package contains components – – A component is a File A file is of type resource or source
    • Architecture Layer (as is) – II Package Module = Subsystem = Bundle Package analysis of web application Uses Structure 101 (see also JAX 2012 innovation award for Restructure 101) System Layer
    • Architecture Layer (to be) – III Data Display (Servlet) Data Aggregator 1 Aggregator Data Source 1 Data Aggregator 2 Data Source 2 Data Provider Data Aggregator Interface Data Aggregator Interface Data Source Interface UI Data Source Interface
    • Architecture Layer – IV ConQAT (to-be diagram) • ConQAT (https://www.conqat.org) • Compared to Structure 101: extensible because of open source – Used to implement modularity metrics • Easy integration in build process (Maven)  automatic check of to-be and as-is
    • Demo ConQAT – I
    • Demo ConQAT – II
    • Definition of modules Decoupling •SOLID •Design Pattern Measurement of metrics Select modular runtime Active definition of system ConQAT structure check Metrics MEASUREMENT OF MODULAR SOFTWARE
    • Demo ConQAT – III
    • Modularity Metrics – I Coupling: determines the coupling of this component to other components and is computed based on instability (Robert C. Martin). – I = Ce / (Ca+Ce) 1..0 (Ce (efferent) = outgoing, Ca (afferent) = ingoing) – Consequence: the more components THIS component depends upon, the more instable it is (0= stable, 1=instable) Ca = usages of exported packages Exported Package Exported Package (Internal Packages) Imported Package Bundle Imported Package Ce = imported classes in packages
    • Modularity Metrics – II Relational Cohesion: a component should consist of cohesive elements, otherwise, it should be splitted. Average number of internal relationships per type. – rc = Td / T (Td.. type relationships that are internal to this component; T.. number of types within the component) As classes inside an assembly should be strongly related, the cohesion should be high. On the other hand, too high values may indicate over-coupling. A good range for RelationalCohesion is 1.5 to 4.0. Assemblies where RelationalCohesion < 1.5 or RelationalCohesion > 4.0 might be problematic. Therefore rcI is the normalized RC, having value 1 for 1.5 to 4, decreasing to 0 outside this range based on gaussian bell curve.
    • Modularity Metrics – III Encapsulation: Components should encapsulate knowledge and offer a slim interface. – ep = pt / T (pt = private Types, T = all types) pt = types in internal packages, T = types in internal packages + types in exported packages Exported Package Exported Package (Internal Packages) Imported Package Bundle Imported Package The Overall Modularity Score is now defined as: – M = ((1-I) + rcI + ep) / 3.0
    • SUMMARY
    • Key take-aways • Big software systems have to be structured, but more highlevel than packages – Concrete implementation: OSGi sub systems • Use iterative process to structure software during the whole lifecycle of the product • Implementation best practices support modularity – Facade – Factory – Dependency Injection • Modularity can be measured by metrics