Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Comparing JavaBeans and OSGi Towards an Integration of Two Complementary Component Models HUMBERTO CERVANTES JEAN-MARIE FAVRE 09/02."— Presentation transcript:

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

2 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

3 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?

4 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

5 JAVABEANS

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

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

8 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

9 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

10 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

11 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

12 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

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

14 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

15 OSGI

16 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: www.osgi.org

17 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

18 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

19 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

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

21 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

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

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

24 Comparison

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

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

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

28 Conclusion

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

30 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

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

32

33

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

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

36 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

37 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


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

Similar presentations


Ads by Google