ServiceOriented Component Model

1
Service-Oriented Component Model
zhangyf05_at_sei.pku.edu.cn youchao06_at_sei.pku.edu.cn
April 18,2007
2
Content
3
Service-Oriented Model

• Service Contract of defined behavior

Lookup
Publication
Bind Invoke
4
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

5
Service-Oriented Model

• A service way to implement the functionality
• Focus on service dynamics and substitutabilty
• Jini, Web Service

• Dynamics is very difficult to manage

6
Component-Oriented Model

• Focus on application building block definition
• Creating reusable software building blocks
• Separation of concerns
• Avoid the mix between business code and non
  functional concerns.
• Avoid monolithic application
• An assembler uses (existing) components and put
  them together

7
Component-Oriented Model

• A 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 ltgt service interfaces
• Ideal candidate for implementing services

8
SOC Model

• Focus on both
• Component -implementation
• Service
• Objectives
• Ease the development of application using
  services.
• Separation of concerns separate business code and
  dynamism management code

Business code
Dynamic management code
9
SOC Model
Syntax, Description, Behavior, Semantic
Applications are build by using available
services
Provides a functionality
Resolved at runtime
OSGi framework manage the component lifecycle
10
OSGi Platform

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

11
OSGi Platform

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

12
OSGi Platform

• Dynamic feature
• Departure arrival of services
• Monitoring
• Dependency management
• Only notifications
• Reconfiguration
• Example
• Service publication
• Service discovery
• Service invocation
• Service dynamics

13
Example
import org.osgi.framework.BundleActivatorimport
org.osgi.framework.BundleContextimport
org.osgi.framework.ServiceReference import
org.osgi.framework.ServiceListenerimport
org.osgi.framework.ServiceEvent
... import tutorial.example2.service.DictionarySe
rvice 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.getNam
e() ")" "(Language))")
ServiceReference refs m_context.getServiceRef
erences( DictionaryService.class.getNa
me(), "(Language)") ..... public
void stop(BundleContext context)
public void serviceChanged(ServiceEvent event)
String objectClass
(String) event.getServiceReference().getProperty
("objectClass") .......
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)
14
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

Automate service registration service
dependency management
14
2009-11-11
15
Existing Models

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

16
History
iPOJO 0.6 Extensible component model, Hosted on
APACHE
iPOJO 0.7 Refactoring, Composite
GenSD Monolithic Approach close to ServiceBinder
Service Binder (Humberto Cervantes)
february
september
november
2006
2005
2004
june
june
october
Dependency Manager (Marcel Offermans)
Spring-OSGi (Interfaces 21)
Declarative Service (OSGi R4)
17
a service component framework
18
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

19
iPOJO Overview

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

iPOJO
OSGi
20
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
21
Concepts Lifecycle

• A component instance is either VALID or INVALID
• A component instance is VALID ? All handlers are
  valid

INVALID
Configured
Created
Stopped
VALID
Destroyed
21
22
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

Dependency
Provided Service
Lifecycle
Configuration
Architecture
22
23
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

24
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

25
Dependency Handler

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

26
Dependency Handler
27
Architecture Handler

• An architectural / component view of your systems
  
• Reflection on the iPOJO containers

Component fr.imag.adele.escoffier.hello.impl.Hel
loServiceImpl - 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
28
iPOJO Core Model
29
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

30
Example

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

31
Step 1 the POJO classes

• POJO are Java classes
• Each 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

32
Step 1 the POJO classes

• public class MyFirstPOJO
• FooService myService
• public void doSomething()
• //Do something ....
• myService.foo()
• //Do another thing

• public class MySecondPOJO implements FooService
  
• public void foo()

33
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.

34
Step 2 the Component Types

• ltcomponent
• classnameMyFirstPOJO
• factory myFirstType gt
• ltdependency fieldmyService/gt
• lt/componentgt

• ltcomponent
• classnameMySecondPOJO
• factory mySecondType gt
• ltprovides/gt
• lt/componentgt

35
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.

36
Step 3 Component Instances

• ltinstance
• componentmyFirstType
• name myFirstInstance
• /gt

• ltinstance
• componentmySecondType
• name mySecondInstance
• /gt

37
Step 4 Packaging and Deployment

• iPOJO Bundles are not simple bundles
• Bytecode Manipulation
• Metadata exports
• How-to create an iPOJO Bundle
• With Maven
• With the Eclipse plugin (experimental)

POJO
POJO
POJO
POJO
ltmetagt
meta manipulation
POJO
iPOJO
38
Step 5 Runtime
myFirstType
mySecondType
Factory
Factory
2.1 instance
1.1 instance
FooService
39
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

40
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

41
Conclusion of iPOJO

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

42
Service Binder Simplifying application
development on the OSGi services platform
43
Service Binder

• Automate the management of components and their
  service dependency
• Extract 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

44
Execution Environment

• Compatibility with standard' OSGi
• Generic activator
• Parse component descriptor
• creates the instance managers
• Architectural service

45
Concepts
IOC pattern and execution environment can manage
instance's lifecycle
an external view for the component and are part
of the application logic
deployment dependencies or resources
46
Instance Manager

• Every component instance is managed independently
  by an instance manager
• Bind/unbind required services to/from the
  component instance when it is created/destroyed
• Register/unregister any services provided by the
  component instance after its required services
  are bound/unbound
• Dynamically monitor the component instance's
  service dependencies,
• Create/destroy the component instance when its
  service dependencies 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

47
Instance Manager
48
Instance Property

• Cardinality
• 0-1,0-n,1-1,1-n
• Policy
• How runtime service changes are handled
• How component instance lifecycle is managed
• Static
• Dynamic
• Filter
• Bind/unbind
• Factory
• Register a special FactoryService to create
  instance

49
Instance Property gtInstance 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.

50
Example Step1

• 1.- Component descriptor (metadata.xml)
• lt?xml version"1.0" encoding"UTF-8"?gt
• ltbundlegt
• ltcomponent class"org.simpleclient.impl.ClientIm
  pl"gt
• ltprovides service"org.simpleclient.interfaces
  .SimpleClientService"/gt
• ltproperty name"author" value"Humberto"
  type"string"/gt
• ltrequires
• service"org.simpleservice.interfaces.Simp
  leService"
• filter"(version)"
• cardinality"1..n"
• policy"dynamic"
• bind-method"setSimpleServiceReference"
• unbind-method"unsetSimpleServiceReference
  "
• /gt
• lt/componentgt
• lt/bundlegt

51
Step24

• 2.- Manifest
• Bundle-Activator org.simpleclient.impl.Activator
• Import-Package
• org.ungoverned.gravity.servicebinder
  specification-version"1.1.0",
• org.simpleservice.interfaces specification-versi
  on"1.0.0"
• Bundle-Name simpleclient.jar
• Bundle-Description A simple client.
• Bundle-Vendor Humberto Cervantes
• Bundle-Version 1.0.0
• Metadata-Location org/simpleclient/res/metadata.x
  ml

3.- Activator package org.beanome.simpleclient.imp
l import org.ungoverned.gravity.servicebinder.Gen
ericActivator public class Activator extends
GenericActivator 4.- Service
interfaces package org.simpleclient.interfaces p
ublic interface SimpleClientService ...
52
Step5 Implement Class

• package org.simpleclient.impl
• import org.simpleclient.interfaces.SimpleClientSer
  vice
• import org.simpleservice.interfaces.SimpleService
  
• import java.util.ArrayList
• public class ClientImpl implements
  SimpleClientService
• ArrayList m_simpleServiceRefs new
  ArrayList()
• public ServiceImpl()
• public void setSimpleServiceReference(SimpleSe
  rvice ref)
• System.out.println("-gt SimpleClient
  Hello SimpleService !")
• m_simpleServiceRefs.add(ref)
• ref.Test()
• public void unsetSimpleServiceReference(Simple
  Service ref)
• System.out.println("-gt SimpleClient
  Goodbye SimpleService ...")
• m_simpleServiceRefs.remove(ref)

53
Further Concepts

• ServiceBinderContext
• Lifecycle
• Interceptors
• GenericActivator
• protected Object proxyProvidedServiceObject(Object
  obj, InstanceMetadata metadata)
• protected Object proxyRequiredServiceObject(Object
  obj, DependencyMetadata metadata)

54
Conclusion of Service Binder

• Simple development model ?
• Binding methods
• Service management ?
• Component lifecycle management ?
• Component factory ?
• Component type / Instance ?
• Composition?
• Extensibility of container ?
• Architecture service ?
• Performance ?
• Distribution ?

55
Declarative Service
56
Declarative Service Overview

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

57
Declarative Service Overview
58
Declarative Service Overview

• Immediate 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.

59
Declarative Service Overview

• LifeCycle
• Enabled

60
Declarative Service Overview

• Service Binding and Unbinding
• 2 strategyEvent 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

61
Declarative Service Examples

• Manifest.mf
• No Activator Header.
• Using Service-Component Header to indicate where
  the Componont Description are.

Manifest-Version 1.0 Bundle-ManifestVersion
2 Bundle-Name ConfigFileValidatorBundle Bundle-Sy
mbolicName ConfigFileValidatorBundle Bundle-Versi
on 1.0.0 Bundle-ClassPath bin/,lib/junit.jar Ser
vice-Component OSGI-INF/component.xml Import-Pack
age org.osgi.frameworkversion"1.3.0
62
Declarative Service Examples
lt?xml version"1.0" encoding"UTF-8"?gt ltcomponent
name"example.immediate"gt ltimplementation
class"com.acme.USBConnectionImpl"/gt ltservicegt lt
provide interface"com.acme.USBConnection"/gt lt/se
rvicegt lt/componentgt
package com.acme public class USBConnectionImpl
implements USBConnection protected void
activate(ComponentContext ctxt) ... protected
void activate(ComponentContext ctxt) ... ...
/ Factory Component / factoryusbfactory /
Delay Component / immediatefalse
63
Declarative Service Examples
lt?xml version"1.0" encoding"UTF-8"?gt ltcomponent
name"example.listen"gt ltimplementation
class"com.acme.HttpResourceImpl"/gt ltreference
name"HTTP" interface"org.osgi.service.http.Http
Service" cardinality"0..n" bind"setPage" unbi
nd"unsetPage"/gt lt/componentgt
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 / policydynamic / filter
/ taget(version1.0)
64

• Spring-OSGi

65
Spring-OSGi Overview

• SourceForge
• SubProject of Spring
• LicenceAPL
• Current-Version1.0 M1
• 2006,September
• Goals
• Make it as easy as possible to write Spring
  applications 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.

66
Spring-OSGi Overview

• Manifest.mf
• No Activator Header.
• Using Spring-Context Header to indicate where the
  Componont Description are.

Manifest-Version 1.0 Bundle-ManifestVersion
2 Bundle-Name ConfigFileValidatorBundle Bundle-Sy
mbolicName ConfigFileValidatorBundle Bundle-Versi
on 1.0.0 Bundle-ClassPath bin/,lib/junit.jar Spr
ing-Context wait-for-dependenciesfalse Import-
Package org.osgi.frameworkversion"1.3.0
META-INF/spring
67
Spring-OSGi Overview

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

lazy-inittrue
ltosgiservice interface com.xyz.MessageService"gt
ltbean classMessageServiceProvider/gt lt/osgise
rvicegt
ltbean id MessageServiceProvider
classcom.xyz.MessageServiceImpl/gt lt/beangt
68
Spring-OSGi Overview

• Using Services
• Using BundleContextAware interface
• Inject Services

ltosgireference idMessageService
interfacecom.xyz.MessageService/gt ltbean
idMyBean classSomeClassgt ltproperty
namemessageService refMessageService/gt lt/be
angt
public class SomeClass public void
setMessageService(MessageService s)
cardinality"0..n filter(version1.0)
69
Spring-OSGi Overview

• Using Services
• Binding and Unbinding Services

ltosgireference idMessageService
interfacecom.xyz.MessageServicegt ltosgilistene
r reflistenerBean bind-methodbind unbind-m
ethodbind/gt lt/osgireferencegt ltbean
idlistenerBean classSomeClass/gt
public class SomeClass public void
bind(MessageService s) public void
unbind(MessageService s)
70
Spring-OSGi Overview

• Context ClassLoader Management
• OSGi doesnt 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.

ltosgireference idMessageService
interfacecom.xyz.MessageService context-classl
oaderclientgt ltosgilistener
reflistenerBean bind-methodbind unbind-met
hodbind/gt lt/osgireferencegt
Service-provider Unmanaged(default)
71
Spring-OSGi Overview

• Web application Support
• Set the contextClass parameter of the listener
  declaration in web.xml file to org.springframewor
  k.osgi.context.support.WebApplicationContext
• JMX Manament of OSGi applications
• Spring provide an OSGi bundle that enables
  JMX-based management of OSGi.

72
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

73
Comparison
74
References

• H. Cervantes and R.S. Hall. "Automating Service
  Dependency Management in a Service-Oriented
  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/conflu
  ence/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

75
We can always do better than good.
Thank You !

• Click to edit company slogan .