Your SlideShare is downloading. ×
Platform O.N.E. - Deutsche Telekom’s OSGi based Application Platform for Third Party Enabling - Elmar Brauch & Christian Baranowski
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Platform O.N.E. - Deutsche Telekom’s OSGi based Application Platform for Third Party Enabling - Elmar Brauch & Christian Baranowski

3,236
views

Published on

Platform O.N.E. is an OSGi based application platform of Deutsche Telekom. The talk gives an overview of the key architectural concepts, design patterns and ideas behind the Platform O.N.E. The talk …

Platform O.N.E. is an OSGi based application platform of Deutsche Telekom. The talk gives an overview of the key architectural concepts, design patterns and ideas behind the Platform O.N.E. The talk is practically orientated and will be accompanied by slides and a live coding demo with a running example. The core idea behind the Platform O.N.E. is to provide easy access for third party users (e.g. mobile-apps, web-applications, or other kind of clients) to internal services of Deutsche Telekom. The internal services are exported by platform modules as REST or SOAP services. A platform module provides an easy way to enhance a service with features like: authentication, authorization, security, billing, logging, profiling, monitoring etc. For module implementation the platform provides: an OSGi based run-time, a standard module design, a maven based build process and a set of Platform O.N.E. specific OSGi services. The talk consists of three parts. The fist part gives an overview of the platform architecture and the OSGi technologies used. The second part discusses the design of a platform module and shows the advantages arising from modular design and the use of an OSGi based platform. The second part will be presented on a running example module as a live coding demonstration. The final part of the talk summarizes the key learnings and discusses which OSGi technologies might play a role in the future development of Platform O.N.E.

Published in: Technology, Business

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,236
On Slideshare
0
From Embeds
0
Number of Embeds
18
Actions
Shares
0
Downloads
180
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Platform O.N.E.Deutsche Telekom‘s OSGi basedApplication Platform for Third Party EnablingElmar Brauch and Christian BaranowskiDeutsche Telekom AG, Products & Innovation and SEITENBAU GmbH20.09.2011 Page 1COPYRIGHT © 2008-2011 OSGi Alliance. All Rights Reserved
  • 2. Welcome• Christian Baranowski• Software Quality Assurance @ Seitenbau GmbH Konstanz (DE) • Custom Software Solutions • E-Government Solutions • Identity Management and SSO Solutions • www.seitenbau.com Page 2 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 3. Agenda• Overview Platform O.N.E • Platform features • Architecture context• OSGi relevant architecture concepts • Design goals • Overview of platform architecture • Design of OSGi related core services (REST exporter, logging, ...)• Design of Platform modules • Bundle structure for a module (bundle structure blueprint) • Advantages of the module structure• Live demo• Summary Page 3 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 4. Welcome• Elmar Brauch• Technical Product Manager @ Deutsche Telekom, Products & Innovation • Study of computer science at university of Koblenz-Landau. • Worked as Software Engineer at Capgemini and United Internet Page 4 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 5. Overview Platform O.N.EWhat is the Platform O.N.E? Page 5 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 6. Overview• Platform O.N.E. is an OSGi based application platform.• Platform O.N.E. connects mobile apps or third party clients with internal services of Deutsche Telekom.• Internal services are exported as REST or SOAP services. • Developer Garden uses SMS module. • http://www.developergarden.com • Mediencenter uses DLS module. • http://medien-center.t-online.de Page 6 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 7. Architecture ContextDevices TV Laptop/PCEdge P&I DLSExp. Layer DLSi SMS … … … … … n Core Platform O.N.E.Service Layer SMS DLSn DLSi … Page 7 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 8. Idea• Platform O.N.E. offers features as services: • Authentication, authorization, • Security, billing(quota handling), logging• Features are implemented as components which provides the features as OSGi services.• Platform modules exporting backend services can easily use these features. Page 8 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 9. Motivation• Pros • Faster module development, because technical issues are solved in the platform. • Cheaper modules, because all features and services are reusable in other modules. • Save hardware, because different modules can use the same servers. Page 9 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 10. OSGi Relevant Architecture Concepts Page 10 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 11. Design Goals Design Goals Module Goals from Operational developers Other goals P3GW goals goals Dependency Easy No dependency management at Monitoring programming on OSGi in Runtime model Platform code Dependency Technical details Configuration injection instead should be management of inheritance hidden Packaging as Blueprints for Testability RPM module design P3GW = Predecessor of Platform O.N.E Page 11 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 12. Architecture Overview Page 12 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 13. OSGiTechnologies HTTP Service Jetty SLF4J and Logback Eclipse Equinox Spring SOAP - Spring Axis Dynamic Modules JAX-RS – Jersey Page 13 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 14. Design of Platform O.N.EOSGi related core services Page 14 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 15. Logging and Log Service• The platform logger provides an abstraction layer for the actual logging implementation (Logback)• The logger will be accessed in a static way, not as OSGi service• Backend implementation (Logback) is pluggable• Logger works in other environments, e.g. Java SE for debugging unit tests• One platform exposure module is associated with one Logback instance• Design is inspired by the Pax logging project Page 15 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 16. Logging and Log ServiceLogger Client API Page 16 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 17. Logging and Log Service• 3rd party logging framework integration Page 17 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 18. Logging and Log Service Page 18 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 19. Logging and Log Service• Pros • Logger API for the client classes • Pluggable logging implementation (e.g. logger implementation can be changed at runtime) • Common log frameworks are integrated over SLF4 bridges • The OSGi log service is integrated • There is always a log, even when the log service is not active, e.g. at startup • One Logback (log) instance per exposure module • A log message is associated with request Page 19 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 20. Logging and Log Service• Cons • Performance overhead delegation the logging call through the abstraction layer to the log backend service implementation • Not OSGi Standard (but you could use the OSGi log service as backend log service) Page 20 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 21. Web Extender• SOAP and REST web services must be registered as servlets at the HTTP Service• The module implementation should not depend on the Servlet API or on the OSGi HTTP Service API• To this end the platform provides a platform specific extender which registers the servlets for the SOAP and REST modules• Design is motivated by Neil Bartlett - jaxrs-osgi- extender project Page 21 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 22. Web ExtenderRegister a REST Web Service Page 22 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 23. Web Extender• Pros • The OSGi dependency on the HTTP Service and the BundleContext API is contained locally in a single class in the web extender • There are no OSGi dependencies in the modules • The web extender implements a proxy servlet for generic platform logic which should be invoked for each request, e.g. Token Handling • Modules do not depend on the JAX-RS Implementation, but only on the JAX-RS API Page 23 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 24. Web Extender• Cons • Implementation depends on the BundleContext API • Implementation using whiteboard pattern preferable • The BundleTracker API was not used in the implementation Page 24 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 25. Design Platform O.N.E. Modules Page 25 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 26. Design of exposure modules• Main task of Platform O.N.E. exposure modules: build an exposure layer for Commen Commen Commen Common Commen backend services. Rest Soap • apps are kept independent of backend changes. Core• Exposure modules have no business logic – BSP cheap and simple.• Features are added to modules by the platform. Page 26 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 27. Design of exposure modules• Each exposure module has a standard bundle structure: Commen Commen Commen Common Commen • BSP connection to backend Rest Soap • CORE adds platform features • COMMON functions required Core in all bundles • REST or SOAP connection to BSP clients Page 27 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 28. Design of extension modules• Extension modules can be imported by Platform O.N.E. Commen modules. Rest Soap Interface• Extension modules have business logic, they represent Core the Platform O.N.E. features. Implementation• Extension modules consist of BSP two bundle types: • Interface describes feature’s API. • Implementation implements the feature. Page 28 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 29. Example:DLS exposure modules• Digital Life Storage - Mediencenter• Two different systems• Target: Only one system to save costs• First step get rid of German App• Migration needs only new DLSn exposure module Page 29 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 30. Example:DLS exposure modules• Only new BSP bundle must be developed• DLSi and DLSn have same REST, CORE and COMMON bundles.• Minimal development costs - no App or Backend changes• App developement is focused Page 30 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 31. Platform O.N.E - Live Demo Page 31 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 32. Summary• OSGi benefits in the Platform O.N.E • Dependency management at runtime • OSGi provides a dynamic plugin framework out of the box • A platform exposure module can be used with different BSP bundles (Composition) • Dynamic component system, e.g. start and stop REST or SOAP endpoint at runtime • SOA at very low level • Sharing classes and logic between modules in form of OSGi services • … Page 32 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 33. Summary• OSGi disadvantages • Build process and build tools (Maven, …) • Integration of 3rd party frameworks and libraries can be difficult • Maven dependency management and OSGi do not always fit together • OSGi is simple in concept but not as easy to learn, classloader problems etc. • IDE and tooling (PDE, STS, BndTools …) • Dynamic approach brings more complexity to the system • Testing – In-container testing (Pax Exam, BND, …) Page 33 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 34. Summary• Lessons learned • Modularization does not come for free • XML libraries in Java are hell • Use Bundle Tracker OSGi util class to implement an extender pattern • In some cases a whiteboard pattern is a better solution than an extender pattern • … Page 34 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 35. Summary• Technology radar • JAX-WS and Apache CXF Implementation • Spring Version 3.0.0 • BNDTools as IDE • Web Bundles (WAR) - RFC66 • Apache Felix • Jersey Version 1.8 • Jetty 7 • Apache Karaf • Eclipse Virgo • … Page 35 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 36. Discussion and Q&A Page 36 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 37. References Ressources and Links• Richard S. Hall et al. - OSGi in Action• Pax Logging - http://team.ops4j.org/wiki/display/paxlogging/Pax+Logging• Ekke - Logging in OSGi Applications - http://ekkescorner.wordpress.com/blog-series/osgi-apps/• Neil Bartlett - jaxrs-osgi-extender - https://github.com/njbartlett/jaxrs-osgi-extender• Spring Dynamic Modules - http://www.springsource.org/osgi• Gemini Blueprint - http://www.eclipse.org/gemini/blueprint/• Jersey and OSGi - http://jersey.java.net/nonav/documentation/latest/osgi.html Page 37 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 38. Appendix Page 38 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 39. Logging and Log Service Page 39 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 40. Logging and Log Service
  • 41. Web Extender Page 41 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 42. Web Extender Page 42 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 43. Request Context Service• Idea from the Spring Framework where Spring Beans can be in the Request scope• There is one RequestContext which contains data that are associated with the actual request• The RequestContext instance is bound to the local thread• The Client obtains the RequestContext via the RequestContextService Page 43 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 44. Request Context Service Page 44 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 45. Request Context Service• Pros • Simple generic way to pass parameters through the request processing • Makes implemention of e.g. the Token Service simple: the Client does not have to know anything about the token and where it comes from Page 45 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  • 46. Request Context Service• Cons • Only works in an application where you have one thread per request Page 46 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved