Upload
toralf-richter
View
197
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Explorations into OSGi on the server side
Citation preview
10 Questions & Answers on OSGi (on the server side)
Toralf Richter, May 11, 2009
1. What is OSGi?
Answer 1 An acronym : Open Services Gateway initiative
Answer 2 The name of a consortium : the „OSGi Alliance“ Founded 1999 more than 100 companies as members world-wide
(IBM, Oracle+Sun, Nokia, and many telcos, automotive equipment manufacturers)
1. What is OSGi?
Answer 3 a specification : the OSGi Service Platform defines basic concepts of OSGi components and services terminology: bundle, life cycle, services, dependencies defines a programming interface (API) to interact with
the service platform, other services in the same platform, etc.
defines how bundles (components) are built and how their needed meta information is added
current specification version is R4.1 (since May 2007)
1. What is OSGi?
Answer 4 a set of paradigms : in some sense OSGi is yet another incarnation
of the component architecture - complex software systems (should) consist of simpler building blocks (components) OSGi bundles
service orientation within the application - components exists besides each other and express dependency but true interaction is by services using a producer-consumer pattern
It is fine-grained (versus monolithic) - the building blocks are loosely coupled and ought to never rely on another building block‘s presence
it is dynamic – services can appear and disappear (white board pattern)
It aims at continuous operation (uninterrupted by updates and maintenance)
2. Origins of OSGi
Mainly from the embedded software development in automotive (think of BMW iDrive), mobile (think of Java on mobile phones), home entertainment (many recent DVD players run on
OSGi bundled Java applications
3. So what is the server-side story with OSGi? Drive to „enterprise OSGi“ recognisable Foundation of OSGi Enterprise Expert Group in January
2007 transport Java EE APIs and functionalities to OSGiSpecification R4.2 due June 2009 will contain “enterprise
features” which will make OSGi much more practicable (than now) for large scale server side applications
Initial attempt at “distributed OSGi” We made some studies into OSGi for server
applications starting from 2007/2008 this but it only starts to get really interesting now
4. How mature can we consider it on the server side? Some examples of server / server-infrastructure
applications built on OSGi already JBoss, Glassfish v3, BEA Weblogic
Mule ESB, Apache ServiceMix ESB
For the typical JEE application there are still shortcomings of the specification and available and possible implementations.
It seems this is going to improve with R 4.2
OSGi on the server side can currently be considered a heavily emerging technology
5. What are the basic principles? Software is made of components Each component has a clearly marked functionality
(„core competency“) The „same“ component can be present in several
versions In OSGi components are called bundles
5. What are the basic principles? OSGi compliant componentised software runs in a
suitable runtime environment called an “OSGI framework” or “OSGI container”
The container takes care of interpreting the meta information attached to the components, i.e. provide the export and requests the imports (quite similar to well know web or JEE containers)
It takes care choosing a suitable isolation level between bundles based in meta information, in effect determining “visibility” between bundles
5. What are the basic principles? Complex applications are composed of bundles and the dependencies
expressed between them Dependencies can be direct export / import relationship Fragment relationship Service producer /
service consumer relationship
The container resolves dependencies from the “visible” offerings deployed in the container
6. How to manage visibility? Bundles specify explicitly what (Java) packages they provide to other bundles, the OSGi
term for this is export what packages or entire other bundles are needed, or in OSGi
terms are imported and what packages are kept strictly private, etc.
In addition to Java code level visibility (public, protected, …) visibility between bundles is determined by package exports and their version information
The OSGi container takes care of dependency resolution (I.e. does export meet import)
An importer of a package does usually not care which exporter actually provides package, alternatives / substitutes of the same functionalities / exports are easily interchangeable
7. How to express version constraints? Version number pattern „major.minor.bugfix.qualifier“ Exports specify the version they provide Imports specify the precise version or version
range they require Specifying range in the manifest is done in
“mathematical notation” : [ means >=, ] means <=, ( means >, ) means <
Example range: from including 1.5.0 to not including 2.0 - manifest notation: version=“[1.5.0, 2.0)”
When more than one bundle or package match an importers version constraint there are decisions rules (set by OSGi specification) which one goes first
8. How does an OSGi manifest look?
Key elements of an OSGi JAR MANIFEST below. MANIFEST is to be found in jar:<xyz>!/META-INF/MANIFEST.MF
Bundle-SymbolicName: ttwBase
Bundle-Version: 1.0.0
Bundle-Activator: com.tomtomwork.base.Activator
Require-Bundle: ttwOther;bundle-version=“[1.3.1, 1.4.0)“
Export-Package: com.tomtomwork.base.*;version=“1.0.0“
Import-Package: org.osgi.framework;version="1.3.1“,com.tomtomwork.webfleet;version=“[2.0.0, 2.1.99)“
Private-Package: com.tomtomwork.internal.*
9. How bundles interact using services? bundles can register objects they instantiate and hold as
services they become service providers or service producers when registering service the provider specifies a service interface
and arbitrary additional (meta) information and announces the service(s) on a public white board (service registry)
also bundles can lookup services fulfilling certain criteria and when available consume the service
provider and consumer do not and should not know each other. They interact through the white board (service registry)
loose coupling + dynamism: (non-)availability of services can be queried “per-access”, notifications can be set up using service listeners, and since specification R 4.x the service tracker can be used for constant and transparent service state tracking
10. What are advantages and costs of OSGi development? Developer must learn new API plain OSGi partially invasive on code (can be avoided
using declarative services) developer MUST honour OSGi paradigms third party libraries are sometimes not yet OSGi
complaint tooling not yet “up to speed” when you compare it to
standard Java IDE products JEE capabilities still emergent (e.g. complex /
multiple web applications or JDBC still somewhat complicated)
10. What are advantages and costs of OSGi development? robust
clearly defined and managed dependencies
code quality / maintainability bundles can and should be developed separately and interact on
defined interfaces … this helps to avoid growing huge tangled monoliths
flexibility / adaptability Composed arbitrarily complex applications from small bundles
focusing on their “core competency”
(high) availability / continuous operation update / swap bundles without rebooting the entire application
container (“hot deploy” is rather default mode of operation instead an option)
extensibility add bundles and capabilities at runtime
Thanks for your patience.
Toralf Richter
http://de.linkedin.com/in/toralfrichter/
@ToralfRichter