OSGi and JavaScript - Simon Kaegi

719 views

Published on

OSGi DevCon 2013

One of the real surprises in my career has been the emergence of JavaScript as an increasingly reasonable choice as a systems language. In this talk I'll make the case that it's time for the OSGi community to gather and start looking at creating specifications for JavaScript based implementations. The Orion team started with an OSGi-insired MicroService architecture and in the past year has grown to also include a plugin architecture that is closely aligned with both OSGi bundle metadata and lifecycle concepts. We will use Orion as an example to discuss areas that we think are suitable for standardization.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
719
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
4
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

OSGi and JavaScript - Simon Kaegi

  1. 1. JavaScript and OSGi Simon Kaegi, Orion Project Co-lead IBM Canada @skaegi
  2. 2. 2 What’s up with JavaScript … and why OSGi now?
  3. 3. 3 2005 – Open Source AJAX Libraries Firefox and Webkit 2008 – Google Chrome and … V8! WHATWG and HTML5 EcmaScript 5 (nee 3.1) 2009 – Node.js
  4. 4. 4 JavaScript 2013… Aging AJAX Frameworks Limited framework inter-op Cottage industry of micro libraries NPM Package Hell (Tools are still horrible) …victim of its own success
  5. 5. 5 JavaScript is going through growing pains similar to what Java experienced ten years ago. OSGi concepts and experiences are universal and relevant to JavaScript.
  6. 6. 6 “OSGI seems like overengineered Java stuff. I'm generally pretty skeptical of big frameworks that do everything for everyone. Usually they're a big pain.” -Isaac Schlueter (emphasis is mine)
  7. 7. 7 OSGi for JavaScript OSGi Focused, Lightweight, Open
  8. 8. Core JavaScript Problem Areas • Modularity • CommonJS “require” • AMD (Browser) – require(stringID, callback) – async • Node (Server) – require(stringID) – sync • ES6 Module Loader • http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders • Closer to class-loading than bundle loading
  9. 9. Core JavaScript Problem Areas • Packages • NPM Packages • Closest thing to a bundle but more just project metadata • OSGi bundles can be NPM Packages and vice-versa • Useful work to be done right now!
  10. 10. Core JavaScript Problem Areas • Asynchronous API • Registered Callback Pattern (Node) • doService(params, callback) • Promises “A+” • doService(params).then(onSuccess, onFailure) • http://promises-aplus.github.com/promises-spec/ • W3C DomFutures • ES6 Generators / Co-routines • http://wiki.ecmascript.org/doku.php?id=harmony:generators
  11. 11. Core JavaScript Problem Areas • Extensibility and Services • OpenAjax / OpenSocial • Web Intents (W3C Webapps WG) • No strong standards plays at the moment • Go OSGi!
  12. 12. Orion and OSGi • Micro Services • Complete implementation of OSGi Services API • Uses Promises for return types to decouple from async service implementation details • Data only / No transferable functions • PluginRegistry • OSGi Lifecycle and Bundle State semantics used for Plugins • OSGi Framework startup • Preferences/Settings • Implementation of Configuration Admin and Metatype for Plugin Settings and Schema
  13. 13. Orion Core Retrospective • Orion core “strongly” OSGi influenced • Very small, fast, stable and predictable • Nearly all OSGi service specifications in the compendium are applicable in JavaScript. • Direct Service API use has poor usability characteristics • We need to find a simpler usage pattern to make OSGi Services more approachable to the JavaScript community.
  14. 14. Closing Thoughts • JavaScript is an increasingly reasonable choice as a systems language • Tons of innovation and tons of growing pains • OSGi can really be of help here however • We need to correct some invalid perceptions • We need to make our APIs easier to use and adopt

×