service-oriented component model

Service-Oriented Component Model

[email protected]

[email protected]

April 18,2007

23/4/2123/4/21 22 Fly your dream with your handsFly your dream with your hands

2 Service-Oriented Component Model11

Content

A Glance at OSGi2

iPOJO & Service Binder3

DS & Spring OSGi4

Comparison5

Summary6


Service-Oriented Model

PublicationLookup

Bind & Invoke

Service Registry

Service Consumer

ServiceProvider

Service Specification

Service: Contract of defined behavior


Service-Oriented Model Good challenger to tackle dynamic environments

Loose-coupling – Design by Contract

Late-binding – At runtime, on demand

Hide heterogeneity Issues

Dynamic in nature– Service arrive/disappear dynamically– Clients cope with it i.e. Notification

Service dependencies are unreliable and ambiguous– No service found or multiple found

Service requesters do not directly instantiate service instances– Common service or different instances


Service-Oriented ModelA service way to implement the functionalityFocus on service dynamics and substitutabiltyJini, Web Service

Dynamics is very difficult to manage


Component-Oriented ModelFocus on application building block definition Creating reusable software building blocksSeparation of concerns

Avoid the mix between business code and non functional concerns.

Avoid monolithic application An assembler uses (existing) components and put

them together


Component-Oriented ModelA component type

consistent piece of code non-functional concerns configuration defined interfaces (required and provided)

A component instance Content: business code Container: manage non functional concerns

– Binding, Lifecycle, Persistence, Security, Transaction …

components interfaces <=> service interfaces Ideal candidate for implementing services


SOC ModelFocus on both

Component -implementation Service

Objectives Ease the development of application using services. Separation of concerns separate business code and

dynamism management code

Businesscode

Dynamic management

code


SOC Model

Component

Service

provides

*

Service Specification

1

Service Dependency

+queryrequires

*

Service Providing

+property[*]

Resolved at runtime

Syntax, Description, Behavior, Semantic

Provides a functionality

Applications are build by using available services

OSGi framework manage the component lifecycle


OSGi PlatformOSGi framework: excution environment

Service platform– Service-oriented interaction

Deployment infrastructure– Continuous deployment

A set of standard service definitions Bundle

– Physical unit– Logical concept for the service implements

Installation, activation, deactivation…


OSGi PlatformActivator

Component Register and use service Managed by framework Implement activation and deactivation methods Receive a context object

BundleContext Interact with the OSGi framework

– Service publication– Service discovery and invocation– Classes and resources loading


OSGi PlatformDynamic feature

Departure & arrival of services Monitoring

– Dependency management– Only notifications

Reconfiguration

Example Service publication Service discovery Service invocation Service dynamics


...

import tutorial.example2.service.DictionaryService;

public class Activator implements BundleActivator, ServiceListener{ private BundleContext m_context = null; private ServiceReference m_ref = null; private DictionaryService m_dictionary = null;

public void start(BundleContext context) throws Exception { m_context = context; m_context.addServiceListener(this, "(&(objectClass=" + DictionaryService.class.getName() + ")" + "(Language=*))");

ServiceReference[] refs = m_context.getServiceReferences( DictionaryService.class.getName(), "(Language=*)");

..... } public void stop(BundleContext context) { } public void serviceChanged(ServiceEvent event) { String[] objectClass = (String[]) event.getServiceReference().getProperty("objectClass");

....... }}

Example

import tutorial.example2.service.DictionaryService;

public class Activator implements BundleActivator{ public void start(BundleContext context) { Properties props = new Properties(); props.put("Language", "English"); context.registerService( DictionaryService.class.getName(), new DictionaryImpl(), props); }

public void stop(BundleContext context) { }

private static class DictionaryImpl implements DictionaryService { String[] m_dictionary = { "welcome", "to", "the", "osgi", "tutorial" };

public boolean checkWord(String word) { .... } }}

package tutorial.example2.service;

public interface DictionaryService{ public boolean checkWord(String word);}

import org.osgi.framework.BundleActivator;import org.osgi.framework.BundleContext;import org.osgi.framework.ServiceReference;import org.osgi.framework.ServiceListener;import org.osgi.framework.ServiceEvent;


Motivation OSGi does not provide a very simple development

model. But it provides all the basics to manage dynamic

Events management, service registry, dynamic rebinding …

Listener pattern Originally design to enable asynchronous communication in

object oriented language

Dependencies management Complex and error-prone Concurrency and synchronization

23/4/2114

Automate service registration & service dependency management


Existing ModelsiPOJO 0.7(Clement Escoffier)Service Binder 1.1 et 1.2 (Cervantes)Declarative Service (OSGi R4)Spring – OSGi (Adrian Colyer and all)Dependency Manager (Offermans)Service Component Architecture (IBM)


History

Service Binder (Humberto Cervantes)

Service Binder (Humberto Cervantes)

GenSD Monolithic

Approach close to ServiceBinder

GenSD Monolithic

Approach close to ServiceBinder

iPOJO 0.6 : Extensible

component model, Hosted on APACHE

iPOJO 0.6 : Extensible

component model, Hosted on APACHE

iPOJO 0.7 : Refactoring,

Composite …

iPOJO 0.7 : Refactoring,

Composite …

Declarative Service (OSGi™

R4)

Declarative Service (OSGi™

R4)

Dependency Manager (Marcel Offermans)

Dependency Manager (Marcel Offermans) Spring-OSGi™

(Interfaces 21)Spring-OSGi™ (Interfaces 21)

2004 2005 2006

octoberjune

november february

june

september


a service component framework


iPOJO Overview injected POJO

Base on byte code manipulate iPOJO is a service component model

Based on POJO For dynamic environment Extensible and Flexible

Aims to ease the application development on the OSGi™ framework Hide non functional concerns inside the implementation Hide service interactions Manage dynamics Component Factory management

iPOJO 0.7 is hosted as a subproject of the APACHE Felix project


iPOJO OverviewPOJO

Plain Old Java Object Simple Java class containing the business logic No dependencies on its execution environment

Container around component instance Non-func requirement be injected

OSGi™OSGi™

iPOJO


Concepts: Component

Component Type (Component) Description of a component type

– Name, Factory – Define the container configuration

Component Instance (Instance) Component Factories create instances Instance characterization

– Name, Component Type, Configuration

20


Concepts: Lifecycle

A component instance is either VALID or INVALID A component instance is VALID All handlers are

valid

21

ConfiguredConfiguredCreatedCreated

INVALID

INVALID

StoppedVALIDVALID

DestroyedDestroyed


Concepts: Container

Plugins The container is composed by a IM and Handlers An handler manage one non functional concern Possibility to implement others handlers without modifying

iPOJO core (External Handlers) The runtime plugs the needed handlers

22

Provided Service

Lifecycle

Configuration

Architecture

Dependency


Concepts: Handlers Manage non-func requirement Plugged on the instance manager

Each instance has its own handler set (defined in its type)

Extends the component model Two kinds of handlers

Core handlers– Contained inside iPOJO Runtime

– Lifecycle, Dependency, Provided Service, Configuration, Architecture

External handlers– Developed and Deployed singly from iPOJO Core

– Developed by using the OSGi™ programming model

– Deployed inside bundle exporting the package of the handler


Concepts: Handlers

Handlers, plugged on an instance manager Participate to instance lifecycle vote

– Ask for a vote, Invalid the instance

Interact with POJO fields– Inject values, be notified when the value change

Invoke methods on the POJO Create POJO objects Get the instance Bundle Context …

Manage the relations between “external world” and the POJO


Dependency HandlerManage dependency elements

Service lookup and the service invocation Affects directly the component state Manage correctly the dynamics of OSGi

Dependency Manager Manager all the dependency Register an OSGi service event listener

– When service arrive, store the reference– When used, obtain the service object and return component– When goes away, remove the reference and call unset– Simple vs Multiple

Callback


Dependency Handler


Architecture Handler An architectural / component view of your syste

ms Reflection on the iPOJO containers

Component : fr.imag.adele.escoffier.hello.impl.HelloServiceImpl - VALIDDependency : org.osgi.service.log.LogService - RESOLVED - Optional : true - Multiple : falseProvides : fr.imag.adele.escoffier.hello.HelloService - REGISTEREDService Property : floor_ = 2Service Property : coucou = coucouService Property : empty = trueService Property : language = frComponent : fr.imag.adele.escoffier.hello.impl.HelloServiceImpl2 - VALIDDependency : org.osgi.service.log.LogService - RESOLVED - Optional : true - Multiple : falseProvides : fr.imag.adele.escoffier.hello.HelloService - REGISTERED


As Service Component Using special (service-aware) handlers

Provided service handler– Publish and manage an OSGi™ service

Dependency Handler– Discover and Track an OSGi™ service

These handlers manage OSGi™ service dynamics These handlers allow dynamic service composition

Composition described in term of service specifications not in term of component type


Example

A component requiring a service The needed service is mandatory The component require only one service provider

A component providing a service


Step 1 : the POJO classes

POJO are Java classesEach provided service interfaces need to be

implemented by the POJO To be sure that all method are implemented

A POJO needs to declare a field for each required service Dependencies injection


Step 1 : the POJO classespublic class MyFirstPOJO {

FooService myService;

public void doSomething() {

//Do something ....

myService.foo();

//Do another thing… }

}

public class MySecondPOJO implements FooService {

public void foo() { …}

}


Step 2 : the Component Types

A component type is describe by a name, an implementation class and the handlers configuration.

iPOJO manages component factories to create component instance. One by component type Can be public (service) or private.


Step 2 : the Component Types

<component

classname=“…MyFirstPOJO”

factory = “myFirstType” >

<dependency field=”myService”/>

</component>

<component

classname=“…MySecondPOJO”

factory = “mySecondType” >

<provides/>

</component>


Step 3 : Component Instances

An instance has a name and can receive a configuration.

We can declare instances in the descriptor. These instances will be created when the bundle will be started.

Can create instances from an external factory. Inside another metadata file. By using Factory and ManagedServiceFactory services.


Step 3 : Component Instances

<instance

component=“myFirstType”

name = “myFirstInstance”

/>

<instance

component=“mySecondType”

name = “mySecondInstance”

/>


Step 5 : Runtime

myFirstType

mySecondType

2.1instance

2.1instance

1.1instance

1.1instance

FooService

FactoryFactory


iPOJO Composition Level Component Composition

Horizontal Composition : Instances can be bound by linking consistent provided interfaces and required interfaces

Vertical Composition : Instances can contain other instances

Service Flexibility Runtime / Late Binding Service dynamics Implementation evolution

As Composition are mapped on iPOJO instance, the composition is extensible Possibility to implement “Composite Handlers” extending the

composition model Follow the same rules than “normal” handlers

– Sub-set of Handler methods


Structural Service Composition

A Composition can import and export services A Composition can contain internal services (sub-

services) are instantiated for the composition– Published only inside the composition– Hierarchical Composition

Sub-services dependencies are resolved in the composition scope

Service Application are compositions


Conclusion of iPOJOSimple development model Service management Component lifecycle management Component factory Component type / Instance Composition, ADL, Hierarchic Model Extensibility of container Architecture service Performance Distribution


Service Binder

Simplifying application development on the OSGi services platform


Service BinderAutomate the management of components and t

heir service dependencyExtract service dependency management logic

Configured by information contained in an XML component descriptor file

Inserted seamlessly into a bundle by creating an empty subclass from a generic activator class

Applications are assembled dynamically and are capable of adapting themselves autonomously

Say goodbye to OSGi API and isolate from OSGi

A standard OSGi bundle


Execution EnvironmentCompatibility with

standard' OSGi Generic activator

Parse component descriptor

creates the instance managers

Architectural service


Concepts

an external view for the component and are part of the application logic

IOC pattern and execution

environment can manage instance's

lifecycle

deployment dependencie

s or resources


Instance Manager Every component instance is managed independently by

an instance manager Bind/unbind required services to/from the component instance w

hen it is created/destroyed Register/unregister any services provided by the component inst

ance after its required services are bound/unbound Dynamically monitor the component instance's service depende

ncies, Create/destroy the component instance when its service depend

encies are satisfied/unsatisfied, Manages the instance's life-cycle

Control methods and interfaces Inversion of Control

Constantly maintain the validity of the instance it manages


Instance Manager


Instance PropertyCardinality

0-1,0-n,1-1,1-nPolicy

How runtime service changes are handled How component instance lifecycle is managed

– Static – Dynamic

FilterBind/unbindFactory

Register a special FactoryService to create instance


Instance Property =>Instance Manager

1..1, static Configuration: The required service interface corresponds to a

single binding that must be created for the instance to be validated.

Execution: The destruction of the binding invalidates the instance

0..n, dynamic Configuration: The required service interface corresponds to a

set of bindings that do not need to be created for the instance to be validated. The instance manager creates bindings with all the available service providers at the moment of configuration.

Execution: New bindings can be created and bindings can be destroyed. Instance invalidation only occurs when the instance is destroyed.


Example: Step11.- Component descriptor (metadata.xml)

<?xml version="1.0" encoding="UTF-8"?><bundle> <component class="org.simpleclient.impl.ClientImpl"> <provides service="org.simpleclient.interfaces.SimpleClientService"/> <property name="author" value="Humberto" type="string"/> <requires service="org.simpleservice.interfaces.SimpleService" filter="(version=*)" cardinality="1..n" policy="dynamic" bind-method="setSimpleServiceReference" unbind-method="unsetSimpleServiceReference" /> </component></bundle>`


Step2~42.- Manifest

Bundle-Activator: org.simpleclient.impl.Activator

Import-Package: org.ungoverned.gravity.servicebinder;

specification-version="1.1.0", org.simpleservice.interfaces; specificat

ion-version="1.0.0"Bundle-Name: simpleclient.jarBundle-Description: A simple client.Bundle-Vendor: Humberto CervantesBundle-Version: 1.0.0Metadata-Location: org/simpleclient/res

/metadata.xml

3.- Activatorpackage org.beanome.simpleclient.impl;import org.ungoverned.gravity.servicebinder.GenericActivator;

public class Activator extends GenericActivator{}

4.- Service interfaces

package org.simpleclient.interfaces;public interface SimpleClientService{ ...}


Step5: Implement Class

package org.simpleclient.impl;import org.simpleclient.interfaces.SimpleClientService;import org.simpleservice.interfaces.SimpleService;import java.util.ArrayList;public class ClientImpl implements SimpleClientService{ ArrayList m_simpleServiceRefs = new ArrayList(); public ServiceImpl() { } public void setSimpleServiceReference(SimpleService ref) { System.out.println("-> SimpleClient: Hello SimpleService !"); m_simpleServiceRefs.add(ref); ref.Test(); } public void unsetSimpleServiceReference(SimpleService ref) { System.out.println("-> SimpleClient: Goodbye SimpleService ..."); m_simpleServiceRefs.remove(ref); }}


Further ConceptsServiceBinderContext LifecycleInterceptors

GenericActivator protected Object proxyProvidedServiceObject(Object

obj, InstanceMetadata metadata) protected Object proxyRequiredServiceObject(Object

obj, DependencyMetadata metadata)


Conclusion of Service BinderSimple development model

Binding methodsService management Component lifecycle management Component factory Component type / Instance CompositionExtensibility of container Architecture service Performance Distribution


Declarative Service


Declarative Service OverviewService Compedium(RC4)

Chapter 112 Version 1.0

Declarative Service is a Service Component Model.It uses a declarative model for publishing, finding and binding to OSGi services.

Goals Simplicity High-Performance


Declarative Service Overview


Declarative Service OverviewImmediate Component

An immediate component is activated as soon as its dependencies are satisfied.

Delayed Component A delayed component specifies a service, the

activation of the component configuration is delayed until the registered service is requested.

Factory Component A Factory Component supports multiple instances.


Declarative Service OverviewLifeCycle

Enabled

Immediate ComponentDelayed ComponentFactory Component


Declarative Service OverviewService Binding and Unbinding

2 strategy:Event & Lookup Action in Component LifeCycle

– Binding:– while activating

– the references are processed in the order in which they are specified in the component description.

– Unbinding:– while deactivating

– the references are processed in the reverse order in which they are specified in the component description.

Reference policy– Static & Dynamic


Declarative Service ExamplesManifest.mf

No Activator Header. Using Service-Component Header to indicate where t

he Componont Description are.

Manifest-Version: 1.0

Bundle-ManifestVersion: 2

Bundle-Name: ConfigFileValidatorBundle

Bundle-SymbolicName: ConfigFileValidatorBundle

Bundle-Version: 1.0.0

Bundle-ClassPath: bin/,lib/junit.jar

Service-Component: OSGI-INF/component.xml

Import-Package: org.osgi.framework;version="1.3.0

……


Declarative Service Examples<?xml version="1.0"

encoding="UTF-8"?>

<component name="example.immediate">

<implementation class="com.acme.USBConnectionImpl"/>

<service>

<provide interface="com.acme.USBConnection"/>

</service>

</component>

package com.acme;

public class USBConnectionImpl implements USBConnection {

protected void activate(ComponentContext ctxt) {...}

protected void activate(ComponentContext ctxt) {...}

...

}

/* Factory Component */factory=“usbfactory”/* Delay Component */immediate=“false”


Declarative Service Examples<?xml version="1.0"

encoding="UTF-8"?>

<component name="example.listen">

<implementation class="com.acme.HttpResourceImpl"/>

<reference name="HTTP"

interface="org.osgi.service.http.HttpService"

cardinality="0..n"

bind="setPage"

unbind="unsetPage"/>

</component>

package com.acme;

public class HttpResourceImpl {

protected void setPage(HttpService http) {

http.registerResources("/src", "src", null );

}

protected void unsetPage(HttpService http) {

http.unregister("/src");

}

}

/* reference policy */policy=“dynamic”/* filter */taget=“(version=1.0)”


Spring-OSGi


Spring-OSGi OverviewSourceForge

SubProject of Spring Licence:APL

Current-Version:1.0 M1 2006,September

Goals Make it as easy as possible to write Spring application

s that can be deployed in an OSGi execution environment.

Also make development of OSGi applications simpler and more productive by building on the ease-of-use and power of the Spring framework.


Spring-OSGi OverviewManifest.mf

No Activator Header. Using Spring-Context Header to indicate where the C

omponont Description are.

Manifest-Version: 1.0

Bundle-ManifestVersion: 2

Bundle-Name: ConfigFileValidatorBundle

Bundle-SymbolicName: ConfigFileValidatorBundle

Bundle-Version: 1.0.0

Bundle-ClassPath: bin/,lib/junit.jar

Spring-Context: *;wait-for-dependencies=false

Import-Package: org.osgi.framework;version="1.3.0

……

META-INF/spring


Spring-OSGi OverviewExport Services

ApplicationContext----Contains some number of beans(Components/Services)

<osgi:service interface =“com.xyz.MessageService">

<bean class=“MessageServiceProvider”/>

</osgi:service>

<bean id =“MessageServiceProvider“ class=“com.xyz.MessageServiceImpl”/>

</bean>

lazy-init=“true”


Spring-OSGi OverviewUsing Services

Using BundleContextAware interface Inject Services

<osgi:reference id=“MessageService“ interface=“com.xyz.MessageService”/>

<bean id=“MyBean” class=“SomeClass”>

<property name=“messageService”

ref=“MessageService”/>

</bean>

public class SomeClass {

public void setMessageService(MessageService s) {

…

}

}

cardinality="0..n“filter=“(version=1.0)”


Spring-OSGi OverviewUsing Services

Binding and Unbinding Services

<osgi:reference id=“MessageService“ interface=“com.xyz.MessageService”>

<osgi:listener ref=“listenerBean”

bind-method=“bind”

unbind-method=“bind”/>

</osgi:reference>

<bean id=“listenerBean” class=“SomeClass”/>

public class SomeClass {

public void bind(MessageService s) {

…

}

public void unbind(MessageService s){

…

}

}


Spring-OSGi OverviewContext ClassLoader Management

OSGi doesn’t define what the context ClassLoader will be at any point in time.This means some useful 3rd-party libraries may not be able to find the types and resources they need.

<osgi:reference id=“MessageService“ interface=“com.xyz.MessageService”

context-classloader=“client”>

<osgi:listener ref=“listenerBean”

bind-method=“bind”

unbind-method=“bind”/>

</osgi:reference>

Service-providerUnmanaged(default)


Spring-OSGi OverviewWeb application Support

Set the contextClass parameter of the listener declaration in web.xml file to “org.springframework.osgi.context.support.WebApplicationContext”

JMX Manament of OSGi applications Spring provide an OSGi bundle that enables JMX-bas

ed management of OSGi.


Comparison A development model simple and non intrusive Dynamics management and component lifecycle

management Differentiation between component type / Instance Composition, ADL, Hierarchic Model Other non functional concerns management, extensibility,

flexibility Runtime representation Performance Distribution


Comparison

ContextClassLoader

ServiceMngt

Life

Cycle

Component Factory

Composite Ext. & Open Container

Arch.

ServiceBinder 1.2

N Y Y Y Y N Y

DeclarativeService

N Y Y Y N N N

Spring-OSGi Y Y y N N N N

iPOJO 0.7 N


References H. Cervantes and R.S. Hall. "Automating Service Dependency Management in a Service-Oriente

d Component Model," Proceedings of the Sixth Component-Based Software Engineering Workshop, May 2003, pp. 91-96.

Clement Escoffier.“iPOJO Yet Another Service-Oriented Component Model”.ppt Clement escoffier . http://cwiki.apache.org/confluence/display/FELIX/IPojo Humberto Cervantes, Richard S. Hall . http://gravity.sourceforge.net/servicebinder/ Martin Fowler.Inversion of Control Containers and the Dependency Injection pattern Neil.A Comparison of Eclipse Extensions and OSGi Services BlueDavy.Service-Oriented Component Model(SOCM) http://osgi.org http://www.springframework.org/osgi

Click to edit company slogan .

We can always do better than good.

service-oriented component model

Documents

serviceoriented component

ambiguousno service

service implementsinstallation

standard service definitions

component lifecycle

business codecontainer

null private servicereference

private bundlecontext