OSGi 1.0. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON History First...

Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON

OSGi 1.0


History

First meeting Raleigh December 1998 as Connected Alliance SUN, IBM, ERICSSON, Sybase, Toshiba, Nortel,

Oracle Purpose

Attract third party developers by creating a standard API for a remotely managed residential gateways

Originally SUN's Java Embedded Server was supposed to be the starting point


History

Further API's Device Access Data Management Client Access Http server Logging Remote Administration Configuration


History

Initial work was progressing Decision was made to limit the changes to improve

time to market ;-) IBM picked 3, ERICSSON picked 3 Very nice cooperation However, ServiceSpace seemed to have problems

State of Connected Alliance was unsure Parties came and went


History

Connected Alliance became OSGi Took a long time to work out the details

SUN wanted to move the standardization into the Java Community Process (JCP) javax.osg interfaces. Wow!

Meetings were quite wasteful due to introductions of new members.

Specification work stalled in the mean time


History

Discussion in that time were about: Getting rid of the wizards and their added complexity Introducing factories Clarifying CLASSPATH issues Moving methods to BundleContext Versioning Manifest headers Protection between bundles: Gates


History

Gatespace was formed Used experience from e-box to enter this market Build their implementation of the specification

quickly Found a lot of problems

All key players left at SUN: Anselm, Ulrich and Bob Mines. Nobody left who know any reasons


History

OSGi rejected SUN's JCP process due to intellectual property rights (IPR)

OSGi introduced a light weight process Request For Proposal (RFP) Request For Comments (RFC)

SUN threatened to leave OSGi and withdraw the framework and device specification


History

IBM and ERICSSON prepare an alternative specification which is approved by Gatespace

SUN was soothed by allowing them to become Java Chair

Alternative spec turned out to have a lot of lessons Next week is a crucial meeting in San Francisco

Try to finalize the spec for Framework, Log, Device access and Http


History conclusion

We lost an incredible amount of time in business politics

The departure of the key SUN people made it very hard to agree on changes in the framework or device access


What is OSGi 1.0?

Framework Device Access HttpService Log

…. Quite minimal for 1 years work


OSGi guidelines

We want to attract "bundle" programmers Minimize complexity on the bundle site

Use interfaces to allow alternative implementations


Interfaces

Logclient

SimpleLog

IBMLog

MotorolaLog

implements

usesinterface

public interface Log { public void log(String s);}

public class SimpleLog { public void log(String s) { System.out.println( s ); }}


Framework

Responsibility: Provide a context for applications, called bundles, to

be installed and run in Provide a managed secure environment Allow bundles to discover and reuse each other

services in a controlled way Manage dependencies between bundles Manage the Java environment, specifically the

CLASSPATH issues


Framework (current)

BundleActivator

BundleManager

BundleListener

ServiceListener

BundleContext

Service

regi

ster

get

Framework

ServiceDescription

FrameworkListener

ServiceFactory

AboutInfo


Big differences from JES

Removed Wizards Made CLASSPATH management explicit

Export-Package tag in manifest Import-Package tag Versioning tag, more tags

Moved many methods to BundleContext Factory concept


Problems discovered recently

ServiceDescription is hard to use Requires strings for class names Unqualified services not well defined Can be

spoofed Service interface is a marker and totally useless No explicit reference object to a service No explicit registration object of a service Registration/lookup supports only one interface


Problems discovered recently No good service lookup facility About info is limited and fixed Framework/BundleContext not well defined

No clear object for Life cycle of bundle (is in Framework now)

No clear object for its environment (Is in Framework and BundleContext)

File issues should be separate loadable service instead of being in the Framework


Framework (proposed)

BundleActivator

BundleEnv.

ServiceReference

regi

ster

get

ServiceRegistration

Object

BundleServiceFactory

1 n 1 1

11

1 1

"public" start/stopin registry??

Private to bundle impl.


The "whiteboard" pattern

We found that we were creating lots of small private registries HttpServer, Device Access, Client Access Private registries do not automatically handle

dependencies Dependency handling is tricky and error prone


Current registration processClient

get("Server")

register("Server")

register(this)

callback()

start()

stop()

callback()

?????

Client Framework Server


Problems

Each server must implement a registry and handle dependencies

When more than one server is available the client must handle this WAP server together with HTTP server debug server

Client is dependent on server, if server dies, client must act


ProposalClient Framework Server

AddListener("Client")

register(this)

callback()

start()

stop()

Event:registered(client)

Event:unregistered(client)


Advantages

Servers do not have to manage dependencies, the framework does it for them

Client does not have to watch servers life cycle anymore

Clients automatically handle any number of servers

Also applicable to addXXXListener in framework


Service lookup proposal Current lookup/registration very limited:

void registerService( ServiceDescription, Service) Service getService( ServiceDescription ) Enumeration getServices() Enumeration getServices( ServiceFilter )

No attribute search No expressions Extremely limited Single interface


Proposed search mechanism

Why Find services by interface, manufacturer, location etc.

Proposed ServiceRegistration registerService( String, Object,

Dictionary ) ServiceReference [] getService( Class, String ) ServiceReference getService(Class)

Filter is a string with LDAP search filter


Search filter Syntax LDAP string filter (RFC-2254)

equality, approximate, less or equal, greater or equal, sub strings

AND, OR, NOT, Sub expressions Multiple values per attribute Examples:

(cn=Babs Jensen) (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))

(o=univ*of*mich*)


Examples searching Properties p = new Properties();

p.put("manufacturer","ERICSSON");p.put("ff", new String[] {"flop","flip"});ServiceRegistration r = z.registerService(

"My flip flop service",flipflop, p );

ServiceReference [] ref = z.getServices(BundleListener.class,"(manufacturer=ERICSSON)" );

ServiceReference [] ref = z.getServices(FlipFlop.class,"(|(ff=flip)(ff=flop))" );


Advantages Simpler interface but more powerful than existing Can be used to find services registered in JINI and

UPnP Saves much code in cases where a specific service

needs to be located Gets rid of awkward anonymous/qualified

ServiceDescription A single registered object can be found under all the

interfaces it implements


State model Current bundle state is boolean

isActive Problems in implementation due to intermediate states

Killing another service in stop could cause deadlock starting/stopping are intermediate states


Added states

INSTALLED

RESOLVED

STARTING STOPPING

RUNNING

EXPORTING

ZOMBIE


Remove Framework

Framework instance shared by all bundles No current object describes the life cycle of the

bundle: start/stop/install/uninstall All implementations must separate calls for

different bundles: most calls are in shared Framework now


Remove Framework Introduce BundleEnvironment

Private object for bundle programmer to interact with environment

Registry, management interface Introduce Bundle

Public object to interact with Bundle life cycle start, stop, uninstall, kill, update dependencies

Close to expected implementation model


Device API

Dynamic detection of new devices Matching of device ID to loading a bundle that

acts as a driver stacked model

serial via USB USB via ethernet

DeviceManager acts as bundle locater and clearing house


Current device APINetwork Device Manager Driver

register descriptorNewdevice

load bundle()

attach device

proprietary

Framework

start()

get("DeviceManager")

stop()

proprietary

start()

install()

get("DeviceManager")


Proposed device APINetwork Device Manager Driver

register DeviceNewdevice

register Driver

Framework

start()

add listener(Device,Driver)

Event: registered(Device)

start()

install()

Event: registered(Driver)

match()

get(Device)

proprietary


Advantages new Device API

Looks slightly more complicated, but: Handles matches best driver (like BSD does) No unmanaged dependencies

Simpler to implement and more robust


HTTP server

Simple web server Support for

javax.servlet API Access to bundle resources Access to file system

Uses private registry HTML focussed


HTTP server currentClient

get("HttpServer")

register("Server")

register(servlet)

callback()

start()

stop()

callback()

?????

Client Framework HTTP serverservlet


HttpServer proposedClient

register("Servlet")

add listener("Servlet")

Event: register(Servlet)

callback()

start()

stop()

Client Framework HTTP serverservlet

Event: unregister(Servlet)


HttpServer proposed

Uses whiteboard pattern Allows for multiple independent HTTP or other

servlet (WAP?) servers simultaneously


Next generation OSGi

Client Access Messaging Data storage Configuration management Remote Administration


Client Access Purpose:

A more generic way of publishing information than HTML used in starter pack in modified form

Publisher

Page

1

1..n

Framework Consumerregisters listens

UserManager


Client Access

Content negociation between consumer and publisher

Authentication User administration Will not be standardized in first release unless

we can integrate it with HttpServer


Messaging

Purpose Support sending Java objects between bundles over

different transport mechanisms

a Bundle b Bundle

an Object


Messaging

Simple to use Unit of transport is an Object Mapping to MIME typed data for non-java

applications Flexibile transport media:

High performance for inside VM notifications Mapping to SMTP/HTTP etc.


Messaging

Addressing Each bundle will have a globally unique id (GUID) A bundle can listen to messages for a role VM broadcast and network broadcast

Examples [email protected] [email protected] [email protected] 14A231-2F12-0A12-89FA765A


Messaging

Quality of Service Best effort, Acknowledged Priority

Transport adaptor can use QOS information Secure messages

Encryption, Authentication Combined with Socket connections


Messaging wild idea

Source ID == GUID == public key Elliptic curves

Shorter keys than RSA (120 bits versus 1024) NeXT, Apple Fast

Automatic Public Key Infrastructure ………...


Data storage

JDBC referenced POS Data management driven by a person of

Oracle. Not clear if that person has full support POS

Object oriented database A bit tricky We have to be careful that it will not become a

standard by accident


Configuration management

Proposal from Liberate Register properties and listen to changes Cumbersome to use for bundle programmer due to

lots of string names We proposed to use a bean approach

Register a bean in the framework registry Configuration service will listen to UPDATE events

or send messages to bean


Remote Administration

No proposal yet


Conclusion

It took too long for too little Some very good people in the specification

group Time allowed us to learn what worked and what

not worked Know more after next week

OSGi 1.0. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON History First...

Documents

Transcript of OSGi 1.0. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON History First...