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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Logging and Log Service

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

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

http://tux2323.blogspot.com	154
http://confluence	6
http://tux2323.blogspot.de	2
http://tux2323.blogspot.com.au	1
http://tux2323.blogspot.in	1
http://tux2323.blogspot.se	1

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

by mfrancis on Sep 21, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

6 Embeds 165

Statistics

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