Upload
dwayne-dabbs
View
215
Download
2
Tags:
Embed Size (px)
Citation preview
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
© 2005 IBM Corporation3
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
© 2005 IBM Corporation4
Overall Architecture
= serviceHardware
Driver Driver Driver
Operating System
Java
OSGi
Fram
ewor
k
Bundle (Application)
IBM Software Group
© 2005 IBM Corporation5
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
© 2005 IBM Corporation6
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
© 2005 IBM Corporation7
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
© 2005 IBM Corporation8
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
© 2005 IBM Corporation9
Service Orientation
Service ProviderService Provider
Service RegistryService Registry
Service ConsumerService Consumer
Service Description
publish find
interact
IBM Software Group
© 2005 IBM Corporation10
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
© 2005 IBM Corporation11
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
© 2005 IBM Corporation12
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
© 2005 IBM Corporation13
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
© 2005 IBM Corporation14
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
© 2005 IBM Corporation15
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
© 2005 IBM Corporation16
Still have issues with ServiceTracker and Service API (2)
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
© 2005 IBM Corporation17
Still have issues with ServiceTracker and Service API (3)
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
© 2005 IBM Corporation18
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
© 2005 IBM Corporation19
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
© 2005 IBM Corporation20
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
© 2005 IBM Corporation21
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
© 2005 IBM Corporation22
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
© 2005 IBM Corporation23
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>
Defines a component and its name
IBM Software Group
© 2005 IBM Corporation24
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>
Specifies the implementation class of the component
IBM Software Group
© 2005 IBM Corporation25
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>
Specifies that the component provides a service and the interfaces the service implements
The implementation class must implement these interfaces
IBM Software Group
© 2005 IBM Corporation26
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>
Specifies that the component references a service and the interface it expects the service to implement
IBM Software Group
© 2005 IBM Corporation27
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
© 2005 IBM Corporation28
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
© 2005 IBM Corporation29
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
© 2005 IBM Corporation30
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
© 2005 IBM Corporation31
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
<reference name="otherService"
interface="org.foo.OtherService“
bind=“bindOtherService”
unbind=“unbindOtherService”/>
protected void bindOtherService(OtherService other) {
…
}
IBM Software Group
© 2005 IBM Corporation32
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
<reference name="otherService"
interface="org.foo.OtherService“/>
protected void activate(ComponentContext context) {
OtherService other = (OtherService) context.locateService(“otherService”);
}
IBM Software Group
© 2005 IBM Corporation33
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
© 2005 IBM Corporation34
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
© 2005 IBM Corporation35
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
© 2005 IBM Corporation36
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
© 2005 IBM Corporation37
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