ibm software group © 2005 ibm corporation we20: declarative services in osgi r4 apachecon us 2005...

IBM Software Group

© 2005 IBM Corporation

WE20: Declarative Services in OSGi R4WE20: Declarative Services in OSGi R4ApacheCon US 2005ApacheCon US 2005

BJ HargraveBJ HargraveSenior Technical Staff Member, IBMSenior Technical Staff Member, IBMOSGi Fellow and CTO, OSGi AllianceOSGi Fellow and CTO, OSGi Alliance

IBM Software Group

© 2005 IBM Corporation2

OSGi Alliance

Work began as an ad hoc group called the Connected Alliance in 1998

The OSGi Alliance was founded in March, 1999

– As an independent, worldwide, non-profit organization with open membership

JSR-008 was withdrawn and technical work moved to the OSGi Alliance

OSGi Service Gateway Release 1.0 was published in May 2000…

IBM Software Group


OSGi Service Platform

2000 2001 2003 2005

R1

R2

R3

FrameworkHttpLogDevice Access

Package AdminConfiguration AdminPermission AdminUser AdminPreferencesMetaTypeService Tracker

R4

UPnPInitial ProvisioningName SpaceJiniStart LevelIO ConnectorWire AdminXML ParserMeasurement & StatePositionExecution EnvironmentsURL Handler

Core• Framework Layering• Conditional Permission Admin• Declarative Services• Event Admin

Mobile• DMT Admin• Deployment Admin• Foreign Applications• Mobile Management Tree

Vehicle• Power Management• Metatype 2• Diagnostic• Vehicle API

IBM Software Group


Overall Architecture

= serviceHardware

Driver Driver Driver

Operating System

Java

OSGi

Fram

ewor

k

Bundle (Application)

IBM Software Group


What does the OSGi Framework provide?

Horizontal Software Integration Platform

Component Oriented Architecture

– Module (Bundles)

– Package sharing and version management

– Life-cycle management and notification (events)

Service Oriented Architecture

– Publish/find/bind intra-VM service model

– Life-cycle notification (events)

Open remote management architecture

– No prescribed policy or protocol

IBM Software Group


Framework Features

Runs multiple applications and services

Single VM instance

Separate class loader per bundle

– Class loader network

– Independent namespaces

– Class sharing at the Java package level

Lifecycle management of bundles

Intra VM publish/find/bind service model

Java Permissions to secure framework

IBM Software Group


Framework Layering

CDCCDC

ExecutionEnvironment

L0 - •OSGi Minimum Execution Environment•CDC/Foundation•J2SE

MODULE

L1 - Creates the concept of modules (aka. bundles) that use classes from each other in a controlled way according to system and bundle constraints

LIFECYCLEL2 - Manages the lifecycle of bundle in a bundle repository without requiring the VM be restarted

SERVICEL3 – Provides a publish/find/bind service model to decouple bundles

IBM Software Group


Service Layer

Defines a publish/find/bind service model

– Fully dynamic

– Intra VM

– Non-durable service registry

A service is a normal Java object published under one or more Java interfaces with additional metadata

– Clear separation between interface and implementation

Find mechanism support searching on both interface name and metadata values

Service lifecycle is highly dynamic

– Service may be published or unpublished at any time

– Lifecycle event notifications

IBM Software Group


Service Orientation

Service ProviderService Provider

Service RegistryService Registry

Service ConsumerService Consumer

Service Description

publish find

interact

IBM Software Group


Service Registry

Service – An object registered with the service registry under one or more interfaces together with properties

Service Registration – The receipt provided when a service is registered

– Allows the update of the service properties and the unregistration of the service

Service Reference – Token that provides access to the service’s properties but not the actual service object

Service Factory – A facility to let the registrant customize the service object provided to each using bundle

Service Event – An event holding information about the registration, modification, or unregistration of a service

Service Listener – A listener to Service Events

IBM Software Group


Service API (Procedural Model)

Publish service– ServiceRegistration registerService(String interfaceName, Object service, Dictionary properties)

Find service– ServiceReference[] getServiceReferences(String

interfaceName, String filter)

Bind to service– Object getService(ServiceReference reference)

IBM Software Group


Issues with Basic API Usage

Services and the bundles which register them can come and go during the lifetime of the framework

– Many programmers are not prepared to deal with such dynamism

– Bundle programmer must not use unregistered services

– Common problem in every bundle

So ServiceTracker was introduced…

IBM Software Group


Service Tracker

Class which can be instantiated to track specific services

– Tracks list of registered services which match specified tracking criteria

– Can customize behavior when service added and removed

– Implemented to correctly handle dynamism of service model

IBM Software Group


Service Tracker Example

// Create and configure the tracker

ServiceTracker logTracker = new ServiceTracker(context, LogService.class.getName(), null);

// Open the tracker to start tracking services

logTracker.open();

// Get a service from the tracker

LogService log = (LogService)logTracker.getService();

// Use the service

log.log(LogService.LOG_INFO, “A message”);

// Close the tracker and cease tracking services

logTracker.close();

IBM Software Group


Still have issues with ServiceTracker and Service API (1)

Requires programmer to code to OSGi API

– Not an Inversion of Control model

– Services and bundles can come and go during the lifetime of the VM• Many programmers are not prepared to deal with such

dynamism.

– We want a simplification of the programming model for using services in OSGi so that new programmers can declare their service relationships and then have them managed by the runtime rather than having to write code to call OSGi API

IBM Software Group



Lack of metadata

– The framework or a management system does not know what services, if any, a bundle may provide or consume until the bundle executes and calls the framework

IBM Software Group



Performance

– The procedural model requires that bundles must execute in order to publish a service• This means the bundle must have a class loader, classes

must be loaded and objects instantiated and some code executed which will explicitly publish the service

– We would rather be able to declaratively specify that a bundle will publish a service and thus delay creating class loaders, loading classes and instantiating objects until some other bundle actually desires to consume the service

IBM Software Group


Research Effort: Service Binder

Service Binder 1.0 was released November 22, 2002

– Humberto Cervantes and Richard S. Hall

Focused on the dynamic aspects of OSGi services

– Services may arrive or depart at any time

Addressed metadata and simplified programming issues

– But not performance issue

Major influence on design of Declarative Services in OSGi R4

– Subsumes all of Service Binder's functionality

– Adopted similar, but extended metadata

IBM Software Group


OSGi R4 adds Declarative Services

New declarative programming model for services

– Defines service metadata

– Addresses performance concerns

– Simplifies programming model for using services• POJO• Can conceal all service dynamism from component

Fully integrates with existing procedural model

– So bundles written to Service API can work with bundles using Declarative Services

IBM Software Group


Service Components

Contained within a bundle

Their lifecycle is contained within their bundle’s lifecycle

Identified by an implementation class

Optionally provides a service which is registered as an OSGi service

Optionally references other OSGi services (which may be provided by other components)

Optionally configured

Can be lazily activated– This means the creation and activation of a component can be delayed until

the component is actually used.

Uses dependency injection to configure

Described by an XML document

Managed by a central runtime: Service Component Runtime (SCR)

IBM Software Group


Service Component Terms

Component Description – The declaration of a service component. It is contained within an XML document in a bundle.

Component Properties – A set of properties which can be specified by the component description, Configuration Admin service and from the component factory.

Component Configuration – A component configuration represents a component description parameterized by component properties. It is the entity that tracks the component dependencies and manages a component instance. An activated component configuration has a component context.

Component Instance – An instance of the component implementation class. A component instance is created when a component configuration is activated and discarded when the component configuration is deactivated. A component instance is associated with exactly one component configuration.

Reference – A specified dependency of a component on a set of target services.

Target Services – The set of services that is defined by the reference interface and target property filter.

Bound Services – The set of target services that are bound to a component configuration.

IBM Software Group


Component Description

<?xml version="1.0" encoding="UTF-8"?>

<component name="component.name“>

<implementation class=“org.foo.impl.ComponentImpl" />

<property name=“foo.property” value=“some.value”/>

<service>

<provide interface="org.foo.Service"/>

</service>

<reference name="otherService"

interface="org.foo.OtherService“

bind=“bindOtherService”

unbind=“unbindOtherService”/>

</component>

IBM Software Group







<service>


</service>


interface="org.foo.OtherService"



</component>

Defines a component and its name

IBM Software Group







<service>


</service>





</component>

Specifies the implementation class of the component

IBM Software Group







<service>


</service>





</component>

Specifies that the component provides a service and the interfaces the service implements

The implementation class must implement these interfaces

IBM Software Group







<service>


</service>





</component>

Specifies that the component references a service and the interface it expects the service to implement

IBM Software Group


Component Description Lifecycle

The description for a component must first be enabled

– This is the initial state but can be altered

ENABLEDENABLED

DISABLEDDISABLED

ena

ble

disa

ble

IBM Software Group


Component Configuration Lifecycle

A component configuration must be satisfied before it can be activated– This means all the component’s references to other services

can be satisfied

The component instance is activated as required– An instance of the component implementation class is created

using the default constructor– The bind methods, if any, are called to inject the objects for the

bound services– The activate method, if present, is called to inject the

context for the component and mark the end of activation

Component instances are deactivated when any reference becomes unsatisfied– The deactivate method is called, if present, followed by the

unbind methods, if there are any bound services

SATISFIEDSATISFIED

UNSATISFIEDUNSATISFIED

ACTIVATEDACTIVATED

IBM Software Group


Component Activation

Uses Setter Injection to provide component instance with access to execution context

– If component implements

protected void activate(ComponentContext)

method, then it will be called to pass in component’s context

Context can be used to

– Access component properties

– Perform contextualized lookup of services

IBM Software Group


References to Services: Strategy

Objects for referenced service can be obtain in two ways

Event Strategy

– Useful to set fields during component activation

– Useful to be notified of changes in the state of services which are dynamically bound

Lookup Strategy

– Useful to avoid service object creation until service is needed

• In support of lazy activation

IBM Software Group


Event Strategy

Setter Injection

Bind and unbind methods are specified in the component description which are called by runtime when referenced services are bound and unbound from the component instance





protected void bindOtherService(OtherService other) {

…

}

IBM Software Group


Lookup Strategy

Contextualized Lookup/Dynamic Service Locator

The component can call the component context with the service name specified in the component description

Allows runtime to delay activation of referenced service


interface="org.foo.OtherService“/>

protected void activate(ComponentContext context) {

OtherService other = (OtherService) context.locateService(“otherService”);

}

IBM Software Group


References to Services: Policy

Policy controls visibility of dynamism to component

Static policy

– Component instance will only be active if the reference is satisfied

– If reference becomes unsatisfied, the component instance is deactivated

– Hides dynamism from component

Dynamic policy

– Component can see dynamism of referenced service

IBM Software Group


References to Services: Cardinality

Optionality

– Reference can be satisfied even if no target service exists

Multiplicity

– Reference can support 1 or more bound services

0..1 – Optional and unary1..1 – Mandatory and unary (Default)0..n – Optional and multiple1..n – Mandatory and multiple

IBM Software Group


Component Properties

Properties can be accessed via component context

Set by union of

1. Component description– property elements– properties files

2. Configuration Admin configuration under component name

3. Component Factory if created by component factory

Properties can be overridden by later setters

IBM Software Group


Service Component Types

Delayed Component – A component whose component configurations are activated when their service is requested.

Immediate Component – A component whose component configurations are activated immediately upon becoming satisfied.

Factory Component – A component whose component configurations are created and activated through the component’s component factory.

IBM Software Group


Declarative Services

New declarative programming model for services

– Simplifies programming model for using services

• Dependency Injection

• POJO

Supports service dynamism

– Details handled by the runtime

Programmer can focus on business logic and not infrastructure details

Fully integrates with existing OSGi procedural service model

ibm software group © 2005 ibm corporation we20: declarative services in osgi r4 apachecon us 2005...

Documents

ibm software group

osgi service platform

ibm osgi fellow

dynamic service

ibm corporation we20

service layer

service l3

osgi alliance slide