Thanks to the WebKit project, Opera and other browser technology pioneers, embedded browser and JavaScript engines have caught up with their desktop counterparts and have become powerful application runtimes. Rich Internet Applications (RIA) on a mobile device, a feasible option? Despite the browsers having become a great choice for you embedded app's UI, they have two major deficits: * First, they lack access to to device features (location, messaging, address book, etc.) which typically add most part of your apps value. * Secondly, modeling complex business logic in JavaScript is not really what you want to do. Here is where OSGi comes into play! This presentation will introduce the concept of using OSGi as a "Server in your pocket". OSGi acts a runtime for your business logic while exposing device capabilities as well as your custom services to your RIAs running in the browser. By means of service remoting, the talk describes how OSGi middleware automatically translates OSGi Services into JASON web services available on your local server. The presentation will explain how this concept it realized on a set of carrier grade mobile handsets, will touch on lessons learned and will be complemented by life demos on Windows Mobile and Android devices.

1. OSGi as an embedded Rich Internet Application Engine

2. Introduction to Rich Internet Applications (RIA)

5. Rich Internet Applications RIAs on PCs: A Happy World… Source: ethanmorrow.com … same thing for Mobile? …

7. No integration with phone functions (i.e. location)

8. Data bandwidth, Offline Mode

9. Security, etc.… NO!!! Source: abcnews.go.com

10. Introduction to Rich Internet MobileNet Applications (RMA)

11. Rich MobileNet Applications Rich Internet Application: ”Fully featured software package that runs in a browser.”- from Loosely Coupled (http://www.loselycoupled.com/glossary/RIA) Movements to achieve “fully featured”: Google Gears OMTP BONDI W3C Geolocation API Incomplete/Work in progress Specification work in BONDI ongoing Implementations are browser and platform specific

12. Rich MobileNet Applications Traditional Approach to mobile Portals: Web Server Web Server Web Server Location PIM Bluetooth … Browser This persentation is NOT about this

13. The new approach: RMA Rich MobileNet Applications XYZ Server Web Service App Service Web Server Web Server Location PIM Bluetooth … Browser Mobile OSGi My Local Portal

14. Server in the pocket concept The role of mobile phones changes Content is created on the go Photos taken by camera phones Blog entries written on smart phones Data collected via sensors Location information Services are provided at the edge of the network For example phone as a content (media) server Ad hoc connectivity Local networks, peer to peer etc. Different realizations of the concept – or parts: Mobile web server: Nokia MyMobilesite.Net Personal web server: Opera Unite (http://unite.opera.com)

15. OSGi – The Server In Your Pocket HTTP Service: your personal web server UPnP: for ad hoc connectivity and automatic configuration Portability: runs on many different platforms (S60, WM, BREW, Android etc.) Platform integration: existing Java APIs to access device functionality Local web applications (widgets) Remote Service Access: automatic export of services

16. OSGi enabling BONDI BONDI is an emerging standard for browser JavaScript extensions (mostly for access to phone features) OSGi is a component and service runtime OSGi can inject BONDI into browsers OSGi Browser Java JSR JSR JSR JSR JSR API API API API API Phone OS Phone OS

17. Services in your pocket Horizontal services Device integration or operator services Shared by applications Can be deployed post shipment Application specific services: Complex business logic implemented in Java Can use the full power of Java JEE-like 3-tier architecture in the device Can leverage existing 3rd-party components

18. Technology

19. Remote Service Access - Architecture UI Runtime (e.g. Browser) OSGi Remote Events Event Admin Application (e.g widget) RSR Convenience Library (e.g. JavaScript) Service Registry 3. find 2. export RSA 4. bind Service Service Object 5. use 1. register

20. Widgets Locally installed web applications Support for W3C Widget specification Widget use HTML and CSS as the markup Metadata provided in config.xml Packaged as a ZIP Widgets are fully manageable via OSGi Secure widget execution: security context spans from OSGi to the Browser

21. Remote Service Access Based on Distributed OSGi concept Bindings specified for JSON RPC – lightweight and fits JavaScript naturally Services can be marked for export Access point and skeleton automatically created IDL: Java – simple mapping to JavaScript (with some restrictions) Remote Service Registry (RSR) Available at a well-know URL Accessible via a well-known (JSON) web service interface

22. Service Model Asymmetric: service provider OSGi, service consumer UI Runtime Synchronous method calls Parameters passed by value No callbacks, no listeners… Event support: to prevent polling in the applications Applications can subscribe to Event Admin topics

23. Convenience Library Remote Service Access is specified in terms of protocols and access points Ensures interoperability with any UI Runtime A JavaScript convenience library is provided for better developer experience Simple API to access RSR – find and bind services Automatically generates stubs for using bound services Subscribe to remote events (listeners)

24. How to make a remote service So, how to create a remote service? By flagging it “remotable”: org.osgi.remote.publish=true

25. Best design practices for remote services Use simple types as parameters Primitive types and their wrappers Strings JavaBeans Classes with default constructor and public members Maps Arrays (homogeneous) Synchronous methods should return quickly If operation takes longer, use notifications Session-oriented services

26. Session oriented services startSession: returns session ID Session ID used to identify an Event Admin topic. Notifications are delivered through that topic Session ID is used in each service request to identify the session asynchServiceMethod: returns request ID Events related to this request carry the request ID

28. Request ID

29. Type: “MessageResult”

30. Session ID

31. Request ID

32. Type: “MessageError”

33. Status: sent, pending, delivered or failed

34. Recipients

35. Name

37. Demo – Meet Me Here! Meet Me Here! is a simple web application Select a contact from the device contact list and send him a message The default message contains a Google Map URL with the current location of the user Implemented as a widget and a service bundle to access device features Three remote services: contacts, location, messaging Installed from a single deployment package

38. Service Lookup and Binding <script src="http://localhost/rsr/rsr_1.0.js"> </script> <script type="text/javascript"> functionbindService(service) { varsreg = RSR.find(service,null); if( sreg ) { returnRSR.bind(sreg[0]); } else { alert("Can't find " + service + " service!"); } } const LOCATION= "com.prosyst.demo.rma.LocationService"; varlocationService = bindService(LOCATION); packagecom.prosyst.demo.rma; publicinterfaceLocationService { public Location getLocation(); } public class Activator implementsBundleActivator { public void start(BundleContext context) throws Exception { Hashtable props = newHashtable(); props.put( "org.osgi.remote.publish", Boolean.TRUE); this.locationService = newLocationServiceImpl(context); context.registerService( LocationService.class.getName(), this.locationService, props); …

39. Service Usage varmsg = "Location service not available"; if( !locationService ) { locationService = bindService(LOCATION_SERVICE); } var location = false; if( locationService ) { location = locationService.getLocation(); } if( location ) { msg = "Meet Me Here: " + "http://maps.google.com/maps?q=" + location.latitude + ", " + location.longitude; } varsmsMessage = document.getElementById("smsMessage"); smsMessage.value = msg; packagecom.prosyst.demo.rma; publicinterfaceLocationService { public Location getLocation(); } public class Location { public double latitude; public double longitude; public double altitude; public long timestamp; }

40. JSON RPC – Lightweight web service protocol Specification: http://json-rpc.org/wd/JSON-RPC-1-1-WD-20060807.html Request: {"version":"1.1","method":"getLocation","params":[]} Response: {"version":"1.1","result":{"altitude":0,"timestamp":1242744765930,"latitude":47.434006,"longitude":19.148868}}

41. Demo

42. Summary “Mobile Web Applications will beat native applications”Daniel K. Appelquist (http://www.torgo.com/blog/2008/10/mobile-web-native-apps.html) Using OSGi – you can take the best of both worlds: Web developers & designers build the front-end Java developers build the app logic … and OSGi ensures the transparent interworking. Having a server on the edge of the network changes the way things work.

43. Where To Start? Devices: First MASS Deployment in US in 2009. – Project Name: Sprint Titan Shipping 5 device models during 2009 On 3 different platforms: Windows Mobile, BREW, 3rd platform OSGi for Android Download: http://dz.prosyst.com/oss#mBS_Android 2009 Sprint Open Developer Conference http://developer.sprint.com/devcon2009 My blog: http://picisblog.blogspot.com/

44. Question?

45. Contact Gábor Pécsy g.pecsy@prosyst.com Mobile: +36 70 385 5821 http://picisblog.blogspot.com ProSyst Software GmbH Dürener Straße 405 D-50858 Cologne, Germany Tel. +49 221 6604-0 Fax +49 221 6604-660 info@prosyst.com www.prosyst.com Member of: