1. OSGi 1.0

2. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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

3. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON History Further API's Device Access Data Management Client Access Http server Logging Remote Administration Configuration

4. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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

5. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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

6. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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

7. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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

8. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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

9. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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

10. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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

11. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON What is OSGi 1.0? Framework Device Access HttpService Log …. Quite minimal for 1 years work

12. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON OSGi guidelines We want to attract "bundle" programmers Minimize complexity on the bundle site Use interfaces to allow alternative implementations

13. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON Interfaces Logclient Simple Log IBM Log Motorola Log implements uses interface public interface Log { public void log(String s); } public class SimpleLog { public void log(String s) { System.out.println( s ); } }

14. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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

15. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON Framework (current) Bundle Activator Bundle Manager Bundle Listener Service Listener Bundle Context Service register get Framework Service Description Framework Listener Service Factory About Info

16. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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

17. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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

18. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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

19. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON Framework (proposed) Bundle Activator Bundle Env. Service Reference register get Service Registration Object Bundle Service Factory 1 n1 1111 "public" start/stop in registry?? Private to bundle impl.

20. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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

21. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON Current registration process Client get("Server") register("Server") register(this) callback() start() stop() callback() ????? ClientFrameworkServer

22. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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

23. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON Proposal ClientFrameworkServer AddListener("Client") register(this) callback() start() stop() Event: registered(client) Event: unregistered(client)

24. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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

25. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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

26. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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

27. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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*)

28. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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))" );

29. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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

30. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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

31. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON Added states INSTALLED RESOLVED STARTINGSTOPPING RUNNING EXPORTING ZOMBIE

32. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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

33. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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

34. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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

35. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON Current device API NetworkDevice ManagerDriver register descriptor New device load bundle() attach device proprietary Framework start() get("DeviceManager") stop() proprietary start() install() get("DeviceManager")

36. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON Proposed device API NetworkDevice ManagerDriver register Device New device register Driver Framework start() add listener(Device,Driver) Event: registered(Device) start() install() Event: registered(Driver) match() get(Device) proprietary

37. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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

38. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON HTTP server Simple web server Support for javax.servlet API Access to bundle resources Access to file system Uses private registry HTML focussed

39. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON HTTP server current Client get("HttpServer") register("Server") register(servlet) callback() start() stop() callback() ????? ClientFrameworkHTTP serverservlet

40. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON HttpServer proposed Client register("Servlet") add listener("Servlet") Event: register(Servlet) callback() start() stop() ClientFrameworkHTTP serverservlet Event: unregister(Servlet)

41. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON HttpServer proposed Uses whiteboard pattern Allows for multiple independent HTTP or other servlet (WAP?) servers simultaneously

42. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON Next generation OSGi Client Access Messaging Data storage Configuration management Remote Administration

43. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON Client Access Purpose: A more generic way of publishing information than HTML used in starter pack in modified form Publisher Page 1 1..n FrameworkConsumer registerslistens User Manager

44. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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

45. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON Messaging Purpose Support sending Java objects between bundles over different transport mechanisms a Bundleb Bundle an Object

46. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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.

47. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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 role@123.ebox.se 14A231-2F12-0A12-89FA765A@ebox.se 14A231-2F12-0A12-89FA765A@123.ebox.se 14A231-2F12-0A12-89FA765A

48. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON Messaging Quality of Service Best effort, Acknowledged Priority Transport adaptor can use QOS information Secure messages Encryption, Authentication Combined with Socket connections

49. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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 ………...

50. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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

51. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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

52. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON Remote Administration No proposal yet

53. Copyright © 1999 All rights reserved presentation 14/12/1999 ERICSSON 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