Comparing JavaBeans and OSGi Towards an Integration of Two Complementary Component Models HUMBERTO CERVANTES JEAN-MARIE FAVRE 09/02

Who I Am Humberto Cervantes 3d year PhD at Adèle team, LSR, Grenoble www-adele.imag.fr Collaborators: Jean-Marie Favre : PhD supervisor Jacky Estublier : Team director Richard S. Hall : Visitor Work area: Applying Component-Based Technologies to build Software Environments

Comparing OSGi and JavaBeans Two component technologies: JavaBeans: visual assembly of applications Open Services Gateway Initiative (OSGi): service deployment in home gateways. Richard S. Hall, implementor of OSCAR How do these two technologies support a set features that characterize component models? Since some aspects are complementary, how can they be integrated?

Points of Comparison Components : Have a clear and explicit boundary Well specified interface and explicit dependencies Can be customized Can be assembled Are reusable Are units of substitution Are units of delivery and deployment Have certified properties* Component Framework Runtime services to support the model

JAVABEANS

JavaBeans Sun’s technology oriented towards visual assembly of applications Introduced in 1996 Client-side Relatively simple compared to EJB

JavaBeans in a Builder Tool Bean Palette Assembly canvas Selected instance Selected instance properties Running application

What is a JavaBean ? JavaBean: Standard Java class that follows certain naming conventions Express properties, receptacles, events. JAR: Package file for JavaBeans Along with an optional class that provides information, the BeanInfo class Difference between design-time and run- time

Life-cycle Serialized beans become prototypes Instantiation occurs either inside builder tools or in ‘real’ applications. Compilation Packaging InstantiationCustomization SerializationStorage of assembly.class.ser.jar.xml.java Manifest.mf

Boundary and Dependencies Interface is well defined Dependencies With respect to the runtime and imported packages: not explicit Towards other beans, classes or resources: can be described if they occur in the same JAR file. EventSource addEvtListener EventSink implements EvtListener Properties getName/setName Interfaces Receptacle getName/setName

Customization Properties are persistent attributes Changing value of properties Build-time activity Calls to setter methods Can be done at the component or instance level

Assembly Assembly: graph of inter-connected instances. References are transient An assembly cannot directly become itself a Bean. Storage and retrieval of graphs is available. XML Encoder / Decoder

Reusability and Substitution JavaBeans promote reuse However, all the dependencies of the Bean must be known. A JavaBean can be substituted by another if it provides the exact same interfaces.

Delivery and Deployment JAR file is the unit of delivery and deployment for JavaBeans. A manifest file inside the JAR provides simple information about the JavaBeans it contains There is no component registry, Beans are loaded from the classpath Only one version can be available

OSGI

OSGi Open Services Gateway Initiative Founded in 1999 (more than 70 companies) Goal is to define a set of Java APIs that specify a services gateway architecture. OSGi specification: 1st rel: May 2000, 2d rel: October 2001 A service platform that includes: A minimal component-like model A lightweight framework to manage the components. Source:

Global View Source: java.sun.com Services Gateway Bundles Framework JVM Registry Services Services Gateway OSGi Framework : Service registry and request facilities Bundle management facilities

Services and Bundles Service: A Java interface Registered in the framework along with an object that implements it and a set of properties of type name,value Bundle: Delivery and deployment units (JAR file) Contains services: interfaces, implementations and resources Manifest file contains meta-data

Boundary and Dependencies Services have a clearly defined interface No dependencies at service level Bundle Bundle-to-package depencies Code inside the bundle imports packages exported by other bundles Managed by the framework Bundle-to-Service dependencies Code inside the bundle uses services Unmanaged but can be described Runtime dependencies Unmanaged but can be described

Customization Services that implement a particular interface can be customized. Through getter/setter methods Services are shared, a change in the state affects all of the clients.

Assembly No concept of assembly Applications are dynamically created by bundles that connect to services A service request includes the name of the service plus a filter (&(manufacturer=sun)(version>=1.0)) Might return several responses

Units of delivery and deployment The Bundle is the unit of delivery and deployment. JAR file State

Reusability and Substitution Bundles can be reused in different frameworks In a framework at any moment, however, only one bundle from a particular location can exist. Substitution can occur during runtime.

Comparison

JavaBean component vs. OSGi service JavaBean : can be instantiated OSGi service : shared by multiple clients Assemblies JavaBeans: graphs and hierarchies are supported OSGi: No concept of assembly.

Comparison Framework OSGi: Explicit framework to manage delivery units ServiceRegistry JavaBeans: Several classes provide runtime services ClassPath

Comparison Support for customization OSGi: Services are shared. Delivery units OSGi: well managed package dependencies JavaBeans: poor dependency management

Conclusion

Two complementary models Different concept of ‘component’ JavaBeansOSGi Beans +Services JAR fileBundle + Assembly unit Delivery unit

Integration of JavaBeans and OSGi OSGi used as an infrastructure for managing delivery units. A special factory service is registered to create instances of JavaBeans Factory pattern OSGi registry becomes a component registry Factories are located with LDAP filters

Current Work Beanome=JavaBeans+OSGi A prototype: www-adele.imag.fr/BEANOME

Services Gateway & Framework Gateway: embedded server that stands between ‘external’ internet and local network. Framework : Java infrastructure contained inside the gateway that provides: Service registry and request facilities. Bundle management facilites.

Bundle lifecycle INSTALLED RESOLVED STOPPINGSTARTING ACTIVE UNINSTALLED install uninstall update start stop Explicit Transition Automatic transition

JavaBeans Framework java.beans.Beans Instantiation Resource loading java.beans.Introspector Use beaninfo or standard reflection java.beans.beancontext.BeanContext Hierarchy of JavaBean instances Composite pattern Context can provide services Java.beans.Encoder/Decoder Storage/retrieval of a graph of JavaBeans

OSGi Framework A bundle can contain an optional Activator class Called when the bundle starts and stops Receives a BundleContext : Bundle Management Service registration Service request Reception of framework events