0
Platform O.N.E.Deutsche Telekom‘s OSGi basedApplication Platform for Third Party EnablingElmar Brauch and Christian Barano...
Welcome• Christian Baranowski• Software Quality Assurance @ Seitenbau GmbH  Konstanz (DE)  •    Custom Software Solutions ...
Agenda• Overview Platform O.N.E   •    Platform features   •    Architecture context• OSGi relevant architecture concepts ...
Welcome• Elmar Brauch• Technical Product Manager @  Deutsche Telekom, Products & Innovation  • Study of computer science a...
Overview Platform O.N.EWhat is the Platform O.N.E?   Page 5   OSGi Alliance Community Event 2011© 2008-2011. All Rights Re...
Overview• Platform O.N.E. is an OSGi based application platform.• Platform O.N.E. connects mobile apps or third party  cli...
Architecture ContextDevices                                                                                               ...
Idea• Platform O.N.E. offers features as services:   • Authentication, authorization,   • Security, billing(quota handling...
Motivation• Pros  • Faster module development,    because technical issues are solved in the platform.  • Cheaper modules,...
OSGi Relevant Architecture Concepts  Page 10   OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
Design Goals                                                          Design Goals                                        ...
Architecture Overview  Page 12   OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
OSGiTechnologies                                                              HTTP                                        ...
Design of Platform O.N.EOSGi related core services  Page 14   OSGi Alliance Community Event 2011© 2008-2011. All Rights Re...
Logging and Log Service• The platform logger provides an abstraction layer for  the actual logging implementation (Logback...
Logging and Log ServiceLogger Client API   Page 16   OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
Logging and Log Service• 3rd party logging framework integration  Page 17   OSGi Alliance Community Event 2011© 2008-2011....
Logging and Log Service  Page 18   OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
Logging and Log Service• Pros  • Logger API for the client classes  • Pluggable logging implementation (e.g. logger    imp...
Logging and Log Service• Cons  • Performance overhead delegation the logging call    through the abstraction layer to the ...
Web Extender• SOAP and REST web services must be registered as  servlets at the HTTP Service• The module implementation sh...
Web ExtenderRegister a REST Web Service  Page 22   OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
Web Extender• Pros  • The OSGi dependency on the HTTP Service and the BundleContext    API is contained locally in a singl...
Web Extender• Cons  • Implementation depends on the BundleContext API  • Implementation using whiteboard pattern preferabl...
Design Platform O.N.E. Modules  Page 25   OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
Design of exposure modules• Main task of Platform O.N.E.  exposure modules:  build an exposure layer for                  ...
Design of exposure modules• Each exposure module has  a standard bundle structure:                                        ...
Design of extension modules• Extension modules can be  imported by Platform O.N.E.                                        ...
Example:DLS exposure modules• Digital Life Storage -  Mediencenter• Two different systems• Target: Only one  system to sav...
Example:DLS exposure modules• Only new BSP bundle  must be developed• DLSi and DLSn have  same REST, CORE and  COMMON bund...
Platform O.N.E - Live Demo  Page 31   OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
Summary• OSGi benefits in the Platform O.N.E   • Dependency management at runtime   • OSGi provides a dynamic plugin frame...
Summary• OSGi disadvantages  • Build process and build tools (Maven, …)  • Integration of 3rd party frameworks and librari...
Summary• Lessons learned   • Modularization does not come for free   • XML libraries in Java are hell   • Use Bundle Track...
Summary• Technology radar   •    JAX-WS and Apache CXF Implementation   •    Spring Version 3.0.0   •    BNDTools as IDE  ...
Discussion and Q&A  Page 36   OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
References Ressources and Links• Richard S. Hall et al. - OSGi in Action• Pax Logging -  http://team.ops4j.org/wiki/displa...
Appendix  Page 38   OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
Logging and Log Service  Page 39   OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
Logging and Log Service
Web Extender  Page 41   OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
Web Extender  Page 42   OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
Request Context Service• Idea from the Spring Framework where Spring Beans  can be in the Request scope• There is one Requ...
Request Context Service  Page 44   OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
Request Context Service• Pros  • Simple generic way to pass parameters through the request    processing  • Makes implemen...
Request Context Service• Cons  • Only works in an application where you have one thread per request  Page 46   OSGi Allian...
Upcoming SlideShare
Loading in...5
×

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

3,322

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 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,322
On Slideshare
0
From Embeds
0
Number of Embeds
18
Actions
Shares
0
Downloads
181
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

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

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 10. OSGi Relevant Architecture Concepts Page 10 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  11. 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. 12. Architecture Overview Page 12 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  13. 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. 14. Design of Platform O.N.EOSGi related core services Page 14 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  15. 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. 16. Logging and Log ServiceLogger Client API Page 16 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  17. 17. Logging and Log Service• 3rd party logging framework integration Page 17 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  18. 18. Logging and Log Service Page 18 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  19. 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. 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. 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. 22. Web ExtenderRegister a REST Web Service Page 22 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  23. 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. 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. 25. Design Platform O.N.E. Modules Page 25 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  26. 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. 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. 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. 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. 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. 31. Platform O.N.E - Live Demo Page 31 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  32. 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. 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. 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. 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. 36. Discussion and Q&A Page 36 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  37. 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. 38. Appendix Page 38 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  39. 39. Logging and Log Service Page 39 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  40. 40. Logging and Log Service
  41. 41. Web Extender Page 41 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  42. 42. Web Extender Page 42 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  43. 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. 44. Request Context Service Page 44 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
  45. 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. 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×