1
OSGi as an embedded Rich Internet Application Engine
2
Introduction to
Rich Internet Applications(RIA)
3
Rich Internet Applications
What are Rich Internet Apps (RIAs)?
Common base technologies:HTML, JavaScript, CSS, AJAX, Flash …
Frameworks:Adobe Air & Flex, Google WT, Gears, Yahoo Widgets…
4
Rich Internet Applications
Why do we care?Job demand for „RIA“
Job demand for „Adobe Flex“
5
Rich Internet Applications
RIAs on PCs: A Happy World…
… same thing for Mobile? …
Source: ethanmorrow.com
6
Rich Internet Applications
Immature Technologies and Deployments No integration with phone functions (i.e. location)
Data bandwidth, Offline Mode Security, etc.
Source: abcnews.go.com
… NO!!!
7
Introduction to
Rich Internet MobileNet Applications(RMA)
8
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
9
Rich MobileNet Applications
Traditional Approach to mobile Portals:
WebServer
Browser
WebServer
WebServer
Location PIM Bluetooth …
This persentation is NOT about this
10
Rich MobileNet Applications
The new approach: RMA
WebServer
XYZServer
Browser
WebService
Location PIM Bluetooth …
Mobile OSGi
App
Service
My Local PortalWebServer
11
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)
12
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
13
Phone OSPhone OS
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
Java
JS R JS R JS R JS R JS R
OSGi Browser
AP
I
AP
I
AP
I
AP
I
AP
I
14
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
15
Technology
16
Remote Service Access - Architecture
UI Runtime (e.g. Browser)
OSGi
RSR
RSA
Service
Application(e.g widget)
ConvenienceLibrary
(e.g. JavaScript)
Se
rvic
e R
egis
try
ServiceObject
RemoteEvents
EventAdmin
3. find
4. bind
5. use
1. register
2. export
17
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
18
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
19
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
20
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)
21
How to make a remote service
So, how to create a remote service?
By flagging it “remotable”:
org.osgi.remote.publish=true
22
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
23
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
24
Session oriented service example - Messaging
public interface MessagingService { public String startSession(); public void stopSession(String sessionId);
/** * Result will be delivered to: * /com/prosyst/service/MessagingService/<sessionId> topic. */ public int sendSms(String sessionId, SMSMessage message, Map options);}
public class SMSMessage { public String[] recipients; public String body; public Map options;}
• Session ID• Request ID• Type: “MessageResult”
• Status: sent, pending, delivered or failed
• Recipients
• Session ID• Request ID• Type: “MessageError”
• Name• ErrorMessage
Success Event attributes Failure Event attributes
25
Demo Application – Meet Me Here!
26
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
27
Service Lookup and Binding
<script src= "http://localhost/rsr/rsr_1.0.js">
</script><script type="text/javascript">
function bindService(service) { var sreg = RSR.find(service,null); if( sreg ) { return RSR.bind(sreg[0]); } else { alert("Can't find " + service + " service!"); }}const LOCATION= "com.prosyst.demo.rma.LocationService";
var locationService = bindService(LOCATION);
package com.prosyst.demo.rma;public interface LocationService { public Location getLocation();}
public class Activator implements BundleActivator {
public void start(BundleContext context) throws Exception {
Hashtable props = new Hashtable();
props.put( "org.osgi.remote.publish", Boolean.TRUE);
this.locationService = new LocationServiceImpl(context);
context.registerService( LocationService.class.getName(), this.locationService, props);
…
28
Service Usage
var msg = "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;
}
var smsMessage = document.getElementById("smsMessage");smsMessage.value = msg;
package com.prosyst.demo.rma;public interface LocationService { public Location getLocation();}
public class Location {public double latitude;public double longitude;public double altitude;public long timestamp;
}
29
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}}
30
Demo
31
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.
32
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/
33
Question?
34
Contact
Member of:
Gábor Pécsy
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
www.prosyst.com
Top Related