Platform O.N.E. - Deutsche Telekom’s OSGi based Application Platform for Third Party Enabling -...

COPYRIGHT © 2008-2011 OSGi Alliance. All Rights Reserved

Platform O.N.E. Deutsche Telekom‘s OSGi based

Application Platform for Third Party Enabling

Elmar Brauch and Christian Baranowski

Deutsche Telekom AG, Products & Innovation and SEITENBAU GmbH

20.09.2011

OSGi Alliance Community Event 2011© 2008-2011. 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


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

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


Overview Platform O.N.E What is the Platform O.N.E?


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

http://www.developergarden.com/

http://medien-center.t-online.de/





Architecture Context

Core DLSi … … … …

DLSn

SMS …

Platform O.N.E.

TV

Service Layer SMS DLSn DLSi …

Devices

Edge P&I

Exp. Layer

Laptop/PC


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.


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.



OSGi Relevant Architecture Concepts


Design Goals

Design Goals

Goals from P3GW

Dependency management at

Runtime

Dependency injection instead

of inheritance

Testability

Operational goals

Monitoring

Configuration management

Packaging as RPM

Module developers

goals

Easy programming

model

Technical details should be

hidden

Blueprints for module design

Other goals

No dependency on OSGi in

Platform code

P3GW = Predecessor of Platform O.N.E


Architecture Overview


Technologies

Eclipse Equinox

OSGi HTTP

Service Jetty

Spring

Spring Dynamic Modules

JAX-RS – Jersey

SOAP - Axis

SLF4J and

Logback


Design of Platform O.N.E

OSGi related core services


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



Logger Client API



• 3rd party logging framework integration



• 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



• 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)


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


Web Extender

Register a REST Web Service


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


Web Extender

• Cons

• Implementation depends on the BundleContext API

• Implementation using whiteboard pattern preferable

• The BundleTracker API was not used in the implementation


Design Platform O.N.E. Modules

Design of exposure modules

• Main task of Platform O.N.E.

exposure modules:

build an exposure layer for

backend services.

• apps are kept independent of

backend changes.

• Exposure modules have no

business logic –

cheap and simple.

• Features are added to

modules by the platform.

Core

BSP

Com

men

Rest Soap

BSP

Com

men Core

BSP

Com

men

Rest

Core

BSP

Com

men

Soap Rest

Core

BSP

Com

mon


Design of exposure modules

• Each exposure module has

a standard bundle structure:

• BSP connection to backend

• CORE adds platform features

• COMMON functions required

in all bundles

• REST or SOAP connection to

clients

Core

BSP

Com

men

Rest Soap

BSP

Com

men Core

BSP

Com

men

Rest

Core

BSP

Com

men

Soap Rest

Core

BSP

Com

mon


Design of extension modules

• Extension modules can be

imported by Platform O.N.E.

modules.

• Extension modules have

business logic, they represent

the Platform O.N.E. features.

• Extension modules consist of

two bundle types:

• Interface describes feature’s API.

• Implementation implements the

feature.

Core

BSP

Com

men

Rest Soap Interface

Implementation


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


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



Platform O.N.E - Live Demo


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

• …


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, …)


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

• …


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

• …


Discussion and Q&A


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

http://team.ops4j.org/wiki/display/paxlogging/Pax+Logging

http://ekkescorner.wordpress.com/blog-series/osgi-apps/





https://github.com/njbartlett/jaxrs-osgi-extender





http://www.springsource.org/osgi

http://www.eclipse.org/gemini/blueprint/

http://jersey.java.net/nonav/documentation/latest/osgi.html


Appendix


Web Extender


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



• 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



• Cons • Only works in an application where you have one thread per request

Platform O.N.E. - Deutsche Telekom’s OSGi based Application Platform for Third Party Enabling -...

Technology

Transcript of Platform O.N.E. - Deutsche Telekom’s OSGi based Application Platform for Third Party Enabling -...