OSGi: Final summary and discussion

Outline Review: Origins of OSGi –Consortium –Goals Review: What is OSGi –Dynamic Modules for Java –Advanced Component Models over OSGi OSGi adoption in practice and success stories –Application servers –Eclipse Eclipse plug-ins OSGi criticism

Review: The OSGi Alliance OSGi is a set of specifications by the OSGi-Alliance The Open Service Gateway Initiative Initial goal: Facilitate the componentization of software and assure remote management and interoperability of applications and services over a broad variety of devices Application domains: Home automation, Mobile devices, Enterprise applications Current members of the OSGi alliance: –Strategic members: Adobe, Deutsche Telekom, Hitachi, IBM, Liferay, NTT, Oracle, Paremus, Ltd., ProSyst Software, Salesforce.com, Software AG, TIBCO AdobeDeutsche TelekomHitachiIBMLiferay NTTOracleParemus, Ltd.ProSyst SoftwareSalesforce.comSoftware AG TIBCO –Principal members: Cloudyle, Luminis, Makewave, Sumitomo Electric Industries, Ltd. CloudyleLuminisMakewaveSumitomo Electric Industries, Ltd. –Contributing associates: Eclipse Foundation, Inc., Intuit Inc., Mitsubishi Electric, NEC, Orange, Red Hat, Sagemcom SAS, Schneider Electric, Telecom Italia S.p.A, Unify GmbH & Co. KG

OSGi specifications developed in expert groups –Core platform (CPEG) –Vehicle (VEG) OSGi in vehicles –Mobile (MEG) OSGi in mobile devices –Enterprise (EEG) OSGi in enterprise solutions –Residential (REG) OSGi in home automation structured into 2 documents –Core Specification : framework –Service Compendium : standard services

OSGi specification releases OSGi Release 1 (R1): May 2000 OSGi Release 2 (R2): October 2001 OSGi Release 3 (R3): March 2003 OSGi Release 4 (R4): October 2005 / September 2006 –Core Specification (R4 Core): October 2005 –Mobile Specification (R4 Mobile / JSR-232): September 2006 OSGi Release 4.1 (R4.1): May 2007 (AKA JSR-291) OSGi Release 4.2 (R4.2): September 2009 –Enterprise Specification (R4.2): March 2010 OSGi Release 4.3 (R4.3): April 2011 –Core: April 2011 –Compendium and Residential: May 2012 OSGi Release 5 (R5): June 2012 –Core and Enterprise: June 2012 OSGi Release 6: July 2014

Review: What is OSGi now OSGi = Dynamic Modules for Java A set of specifications of the OSGi Alliance (currently Release 6) A set of different implementations of these specifications –Equinox, Felix, Knopplerfish Advanced component models over OSGi, developed independently by external parties (not included in OSGi specifications) –iPOJO, Spring DM

OSGi adoption The OSGi component system is used to build highly complex applications like: –IDE’s, application servers, application frameworks, telecom and service solutions, industrial automation, residential gateways, onboard telematics systems, etc

Java EE application servers vendors look for ways to make their application server products more modular and flexible –IBM's WebSphere –Red Hat’s JBoss –Oracle’s GlassFish Enterprise Server –ObjectWeb’s JOnAS, and –Apache’s Geronimo

Eclipse Eclipse: an open development platform comprised of extensible frameworks, tools and runtimes for building, deploying and managing software across the lifecycle

Eclipse architecture Figure from:

Different types of Eclipse plug-ins C++ IDE (CDE) Visual UI Editor (SWT/Swing Designer) UML modeling tools Colaborative tools (SVN) Aspect oriented language extension (AspectJ)

Eclipse plug-ins All written in Java Found at Eclipse launch - can not dynamically swap plug-ins Load-on-demand strategy - makes it possible to have many different plug-ins and still manage to obtain reasonable performance

Eclipse plug-in architecture Multi-layered extensibility: –Plugins, –Extension points, –Extensions Figure from: augsburg.de/~meixner/saj/skript/osgi/eclipseplugins.html

Create an Eclipse HelloWorld plugin Example: create an Eclipse plugin that adds a new Menu entry; when activated, it displays a window with a message Eclipse -> New ->Project Project wizard -> Plug-in-project -> select target = Eclipse Select Create plugin using one of the templates -> Plugin with a popup menu Generated files: –Source code: Activator.java, SampleAction.java –Metadata: MANIFEST.MF, plugin.xml You may already run the plugin (Run As -> Eclipse Application)

Manifest file for HelloWorld example Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: Myeclipseplugin Bundle-SymbolicName: org.foo.myeclipseplugin; singleton:=true Bundle-Version: qualifier Bundle-Activator: org.foo.myeclipseplugin.Activator Require-Bundle: org.eclipse.ui, org.eclipse.core.runtime, org.eclipse.core.resources Bundle-ActivationPolicy: lazy Bundle-RequiredExecutionEnvironment: JavaSE-1.7 An Eclipse plugin is an OSGi bundle !

OSGi for Eclipse Developers

org.foo.myeclipseplugin.Activator public class Activator extends AbstractUIPlugin { public static final String PLUGIN_ID = "org.foo.myeclipseplugin"; private static Activator plugin; public Activator() { } public void start(BundleContext context) throws Exception { super.start(context); plugin = this; } public void stop(BundleContext context) throws Exception { plugin = null; super.stop(context); } public static Activator getDefault() { return plugin; } public static ImageDescriptor getImageDescriptor(String path) { return imageDescriptorFromPlugin(PLUGIN_ID, path); }

Two manifest files MANIFEST.MFplugin.xml Classical OSGi manifest: Bundle identification Dependencies Activator Extension points Extensions

Plugin.xml for HelloWorld example <objectContribution objectClass="org.eclipse.core.resources.IFile" id="org.foo.myeclipseplugin.contribution1"> <menu label="New Submenu" path="additions" id="org.foo.myeclipseplugin.menu1"> <action label="New Action" class="org.foo.myeclipseplugin.popup.actions.NewAction" menubarPath="org.foo.myeclipseplugin.menu1/group1" enablesFor="1" id="org.foo.myeclipseplugin.newAction">

org.foo.myeclipseplugin. popup.actions.NewAction package org.foo.myeclipseplugin.popup.actions; public class NewAction implements IObjectActionDelegate { private Shell shell; public NewAction() { super();} public void setActivePart(IAction action, IWorkbenchPart targetPart) { shell = targetPart.getSite().getShell();} public void run(IAction action) { MessageDialog.openInformation(shell, "Myeclipseplugin", "New Action was executed.");} public void selectionChanged(IAction action, ISelection selection) {} }

OSGi Criticism Most of the success stories of OSGi adoption are with (dynamic) plug-in architectures OSGi is suited for applications where modularity and dynamic extensibility are particularly important OSGi may be too complex if the interest is on modularity only Using independent Java libraries (available as “normal” jars) from OSGi applications is difficult JRE will not adopt OSGi: if the JRE will be organized in a modular way, this will have to come from itself, not from an external container

Java modularity alternatives Goals: –Introducing the concept of module for programmers –Refactoring of the JDK/ JRE in a modular way (current JRE is monolithic) Project Jigsaw: has as a goal to design and implement a standard module system for the Java SE Platform, and to apply that system to the Platform itself and to the JDK. –It was postponed many times, it is now planned for java 9