• Save
Service oriented component model
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Service oriented component model

  • 2,310 views
Uploaded on

The OSGi Service oriented Component Model

The OSGi Service oriented Component Model

More in: Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,310
On Slideshare
2,310
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • SOA
  • Dynamic nature: they can be registered/unregistered to/from the service registry at any moment and the client must be prepared to cope with this situation, i.e. some notification. A service requester must be prepared to cope with situations where no required services are found or, on the other hand, multiple matching services are found. service requesters do not directly instantiate service instances, as is the case in object orientation, for example. As a result, service requesters do not know whether they are interacting with a common service instance or with different instances providing the same service.
  • Need a way to help architects to design service applications Need an easy programming model to develop applications using services
  • A typical view of components is that they implement one or more provided interfaces, where an interface is a contract of functional behavior. In this sense, interfaces provided by components are very similar to service interfaces. This makes components an ideal candidate for implementing services, where a service is equated with a provided interface.
  • Compositions are expressed in term of service specifications Applications are build by using available services
  • a service platform that includes a minimal component model, a small framework for managing the components, and a service registry. Services (i.e.,Java interfaces) are packaged along with their implementations and their associated resources into bundles . Services are deployed, as bundles. The OSGi framework creates a host environment for managing bundles and the services they provide; a bundle is the physical unit of deployment in OSGi and is also a logical concept used by the framework to internally represent the service implementation. The management mechanisms provided by the framework allow for the installation, activation, deactivation, update, and removal of bundles.
  • The activator implements activation and deactivation methods that are called to initialize and de-initialize it, respectively. In the activation/deactivation methods the activator receives a context object, which gives it access to the framework and the service registry. The context allows the activator component to register services, lookfor other services, and register itself as a listener to different types of events that the framework may fire.
  • The state of a bundle can change at any moment while the framework is running. When a bundle is stopped, its associated activator component must unregister its services and release the services that it is using. Clients of the activator component's services must take care to observe the departure of the services. The OSGi framework uses event notifications to signal service arrival and departure, but does not provide any additional support for service dependency management. Two classes of service dependencies exist in OSGi: component to-service and service-to-service. A component-to-service dependency occurs when a component depends on a service without itself providing any services. A service-to-service dependency occurs when a component provides services and also requires other services to provide its own. Writing the code tomanage component-to-service and service-to-service dependencies is complex and error-prone; managing service dependencies involves concurrency and synchronization issues as well as tedious code to monitor the arrival and departure of any used services. Monitoring involves the observation of changes in the service registry. This is done through the reception of notifications produced by the service registry that announce arrival, departure or changes in the servies. Reconfiguration involves acting in response to the changes in the services. Reconfiguration includes the release of a departing service but also the creation of a new binding towards a substituting or newly arriving service.
  • iPOJO is a service component runtime aiming to simplify OSGi application development. Based on the concept of POJO, application logic is developped easily. Non functional properties are injected in the component at runtime. iPOJO strength points are : components are developped as POJO the component model is extensible the standard component model manages service providing and service dependencies iPOJO manage the component lifecycle and the environment dynamics
  • A POJO is a very simple Java class containing only the business logic. A POJO has not dependencies on its execution environment. In iPOJO, a POJO is a Java class which serve of implementation to a component type. As a content of a component, non-functional requirements of this class will be injected by the container.
  • a component type is described by an implementation class and a container configuration. This container configuration describes non-functional requirements of the implementation / component type. For example, the container description can declare that fields are service dependencies, that it provides a service...
  • A handler is an object who can be plugged on an instance container. A handler manages one non-functional requirement of the instances. Handler can be created and deployed separately from the iPOJO runtime. So everybody can implement its own handler. It is possible to extend the component model by creating your own handler. Service dependency handler managing OSGi service discovery and invocation Service Providing handler managing the publication and the providing of OSGi services Lifecycle callback handler allowing the invocation of methods when the instance state changes Configuration Handler allowing the configuration and the dynamic reconfiguration of the instance Architecture Handler allowing to get information about the instance (state, handler ...) Lifecycle Invoke a method when the instance becomes valid or invalid Configuration Admin support Allow to dynamically (re-) configure an instance with the configuration admin Architecture view Allow to view instance and handlers information External handlers mechanism Allow to add non functional concerns in the component model Persistency Connectors : Event admin / Wire admin Configuration : JMX Task management : Cron, TaskScheduler Security … Easy to develop and to deploy
  • In fact, the container of the component contains a "Dependencies Manager" managing all the service dependency of the component. To do this, it registers an OSGi service event listener and listens for interesting events. When an interesting service arrives, it stores the service reference. When the service is used, it obtains the service object and returns the object to the component. If it is a multiple dependencies, it returns an array of service object. When a service goes away, the dependencies manager removes the reference from its list (and call the unget method): the manager does not keep any reference on the old service. This allows a complete unloading of the service. Two calls to a service can use two different service implementations if the used implementation has gone. iPOJO tries to return always the same service object, since the service goes away.
  • Field : name of the field reprensenting the dependency in the component class Interface : type of the field Optional : is the dependency an optional dependency ? Filter : filter selecting service provider Callback : allow to call a method on the component instances when a service provider (matching with the dependency) appears or disappears
  • POJO provides an ADL based of the notion of services. This kind of "composition" can be named Structural Service Composition. Generally, the application is described in terms of components or instances. iPOJO compositions are described in term of services. This composition allows more flexibility and allows service implementations to evolve without breaking the composition. As a composition can export/implement a service, a composition can be used inside another composition transparently. This brings a hierarchical composition model. Moreover, as the rest of iPOJO the composition is extensible via "composite handler", which are handler participating to a composition.
  • During execution, every component instance is managed independently by an instance manager that takes in charge service registration and service dependency management activities based on the information present in the component descriptor. The instance manager is a container that manages the instance's life-cycle through control methods and interfaces, which are only visible to the instance manager, following the Inversion of Control pattern (see figure 1).
  • A component instance is in one of two states: valid or invalid . When an instance is valid, its services are registered in the service registry and it is active (i.e., executing). When an instance is invalid, its services are not registered in the service registry and it is not active. When an instance is created, it is initially invalid. After creation, the instance manager enters a configuration phase (see figure 2). At this point, it creates bindings between the instance it manages and other instances that provide services required by the managed instance. Configuration can only succeed if bindings can be created for required service interfaces that are categorized as being mandatory. After configuration, the instance manager activates the component instance, and registers its services in the service registry. At that point the instance is valid. If configuration fails, the instance manager waits for the arrival of services that can be used to configure the instance. As soon as all mandatory services become present, the instance is validated. During execution, the instance manager receives notifications from the service registry. These notifications can trigger re-configuration activities, which depend on the dependency properties associated to the component that is being managed. The behavior of the instance manager with respect to the service dependency properties is summarized .
  • A static binding policy indicates that dependency bindings cannot change at run time, whereas a dynamic binding policy indicates that dependency bindings can change at run time. A static dependency is simpler to program than a dynamic one. 1..1, static Instance is bound to one service, any change invalidates the instance 1..1, dynamic Instance is bound to one service, changes do not invalidate the instance as long as it can be bound to another service 1..n, static Instance is bound to at least one service, any change invalidates the instance 1..n, dynamic Instance is bound to at least one service, changes do not invalidate the instance as long as the binding count is non-zero 0..1, static Instance is bound to at most one service (i.e., optional), if it is bound, departure of the bound service invalidates the instance 0..1, dynamic Instance is bound to at most one service (i.e., optional), the instance never becomes invalid 0..n, static Instance is bound to all available services at the time of binding, any departure of a bound service invalidates the instance 0..n, dynamic Instance is bound to all available services at the time of binding, as services arrive/depart they are bound/unbound to/from the instance, the instance never becomes invalid
  • bind-method: The name of the method to call on the component instance to bind a service to it. 􀀀 unbind-method: The name of the method that to call on the component instance to unbind a service from it.
  • When multiple required services are declared, it may be necessary for the component instance to be notified when the configuration phase is finished. Similarly, it may be necessary to be notified when the component instance is about to be invalidated (versus a re-configuration). This is the purpose of the methods defined in the Lifecycle interface. If the component implementation class implements this interface, the following methods are called at two different moments: activate(): During configuration, after all the bindings have been created, but before the provided services are registered. deactivate(): During execution, when the instance is about to be invalidated, after its services are unregistered and before its bindings are destroyed. ServiceBinderContext When writing an the component implementation class, it may be necessary to access the OSGi's bundle context that is provided to the activator of the bundle (altough this is usually not necessary). ServiceBinderContext is a class provided to solve this issue. If the instance class constructor receives a single ServiceBinderContext parameter, a context will be passed into it during instantiation. The methods that are provided in this context allow to: Access the bundle's BundleContext. Obtain the InstanceReference object corresponding to this instance. Obtain a list of all of the instance references that belong to the bun protected Object proxyProvidedServiceObject(Object obj, InstanceMetadata metadata) protected Object proxyRequiredServiceObject(Object obj, DependencyMetadata metadata) The first parameter of both methods contains the object to which a proxy will be added. The first method is called right after the component instance is created. The InstanceMetadata passed as a parameter provides the information about the component found on the descriptor file. The second method is called right before an invocation to a bind method takes place. The DependencyMetadata passed as a parameter contains information about the dependency such as the filter and the name of the service.

Transcript

  • 1. Service-Oriented Component Model
  • 2. Content 10/19/10 2 Service-Oriented Component Model 1 A Glance at OSGi 2 iPOJO & Service Binder 3 DS & Spring OSGi 4 Comparison 5 Summary 6
  • 3. Service-Oriented Model 10/19/10 Publication Lookup Bind & Invoke
      • Service: Contract of defined behavior
    Service Registry Service Consumer Service Provider Service Specification
  • 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
    10/19/10
  • 5. Service-Oriented Model
    • A service way to implement the functionality
    • Focus on service dynamics and substitutabilty
    • Jini, Web Service
    10/19/10
      • 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
    10/19/10
  • 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 <=> service interfaces
      • Ideal candidate for implementing services
    10/19/10
  • 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
    10/19/10 Business code Dynamic management code
  • 9. SOC Model 10/19/10 Resolved at runtime Syntax, Description, Behavior, Semantic
      • Provides a functionality
    Applications are build by using available services 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…
    10/19/10
  • 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
    10/19/10
  • 12. OSGi Platform
    • Dynamic feature
      • Departure & arrival of services
      • Monitoring
        • Dependency management
        • Only notifications
      • Reconfiguration
    • Example
      • Service publication
      • Service discovery
      • Service invocation
      • Service dynamics
    10/19/10
  • 13. Example 10/19/10
    • ...
    • 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,
    • &quot;(&(objectClass=&quot; + DictionaryService.class.getName() + &quot;)&quot; +
    • &quot;(Language=*))&quot;);
    • ServiceReference[] refs = m_context.getServiceReferences(
    • DictionaryService.class.getName(), &quot;(Language=*)&quot;);
      • .....
    • }
    • public void stop(BundleContext context)
    • {
    • }
    • public void serviceChanged(ServiceEvent event)
    • {
    • String[] objectClass =
    • (String[]) event.getServiceReference().getProperty(&quot;objectClass&quot;);
    • .......
    • }
    • }
    import tutorial.example2.service.DictionaryService; public class Activator implements BundleActivator { public void start(BundleContext context) { Properties props = new Properties(); props.put(&quot;Language&quot;, &quot;English&quot;); context.registerService( DictionaryService.class.getName(), new DictionaryImpl(), props); } public void stop(BundleContext context) { } private static class DictionaryImpl implements DictionaryService { String[] m_dictionary = { &quot;welcome&quot;, &quot;to&quot;, &quot;the&quot;, &quot;osgi&quot;, &quot;tutorial&quot; }; 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;
  • 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
    10/19/10 19/10/10 Automate service registration & service dependency management
  • 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)
    10/19/10
  • 16. History 10/19/10 Service Binder (Humberto Cervantes) GenSD Monolithic Approach close to ServiceBinder iPOJO 0.6 : Extensible component model, Hosted on APACHE iPOJO 0.7 : Refactoring, Composite … Declarative Service (OSGi™ R4) Dependency Manager (Marcel Offermans) Spring-OSGi™ (Interfaces 21) 2004 2005 2006 october june november february june september
  • 17. 10/19/10 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
    10/19/10
  • 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
    10/19/10 OSGi™ iPOJO
  • 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
    10/19/10
  • 21. Concepts: Lifecycle
    • A component instance is either VALID or INVALID
    • A component instance is VALID  All handlers are valid
    10/19/10 Configured Created INVALID Stopped VALID Destroyed
  • 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
    10/19/10 Provided Service Lifecycle Configuration Architecture Dependency
  • 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
    10/19/10
  • 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
    10/19/10
  • 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
    10/19/10
  • 26. Dependency Handler 10/19/10
  • 27. Architecture Handler
    • An architectural / component view of your systems
    • Reflection on the iPOJO containers
    10/19/10 Component : fr.imag.adele.escoffier.hello.impl.HelloServiceImpl - VALID Dependency : org.osgi.service.log.LogService - RESOLVED - Optional : true - Multiple : false Provides : fr.imag.adele.escoffier.hello.HelloService - REGISTERED Service Property : floor_ = 2 Service Property : coucou = coucou Service Property : empty = true Service Property : language = fr Component : fr.imag.adele.escoffier.hello.impl.HelloServiceImpl2 - VALID Dependency : org.osgi.service.log.LogService - RESOLVED - Optional : true - Multiple : false Provides : fr.imag.adele.escoffier.hello.HelloService - REGISTERED
  • 28. iPOJO Core Model 10/19/10
  • 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
    10/19/10
  • 30. Example
    • A component requiring a service
      • The needed service is mandatory
      • The component require only one service provider
    • A component providing a service
    10/19/10
  • 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
    10/19/10
  • 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() { …}
    • }
    10/19/10
  • 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.
    10/19/10
  • 34. Step 2 : the Component Types
    • <component
    • classname=“…MyFirstPOJO”
    • factory = “myFirstType” >
    • <dependency field=”myService”/>
    • </component>
    • <component
    • classname=“…MySecondPOJO”
    • factory = “mySecondType” >
    • <provides/>
    • </component>
    10/19/10
  • 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.
    10/19/10
  • 36. Step 3 : Component Instances
    • <instance
    • component=“myFirstType”
    • name = “myFirstInstance”
    • />
    • <instance
    • component=“mySecondType”
    • name = “mySecondInstance”
    • />
    10/19/10
  • 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)
    10/19/10 <meta> {meta + manipulation} POJO POJO POJO POJO POJO iPOJO
  • 38. Step 5 : Runtime 10/19/10 myFirstType mySecondType 2.1 instance 1.1 instance FooService Factory Factory
  • 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
    10/19/10
  • 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
    10/19/10
  • 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 
    10/19/10
  • 42. 10/19/10 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
    10/19/10
  • 44. Execution Environment
    • Compatibility with standard' OSGi
    • Generic activator
      • Parse component descriptor
      • creates the instance managers
    • Architectural service
    10/19/10
  • 45. Concepts 10/19/10 an external view for the component and are part of the application logic IOC pattern and execution environment can manage instance's lifecycle 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
    10/19/10
  • 47. Instance Manager 10/19/10
  • 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
    10/19/10
  • 49. 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.
    10/19/10
  • 50. Example: Step1
    • 1.- Component descriptor (metadata.xml)
    • <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?>
    • <bundle>
    • <component class=&quot;org.simpleclient.impl.ClientImpl&quot;>
    • <provides service=&quot;org.simpleclient.interfaces.SimpleClientService&quot;/>
    • <property name=&quot;author&quot; value=&quot;Humberto&quot; type=&quot;string&quot;/>
    • <requires
    • service=&quot;org.simpleservice.interfaces.SimpleService&quot;
    • filter=&quot;(version=*)&quot;
    • cardinality=&quot;1..n&quot;
    • policy=&quot;dynamic&quot;
    • bind-method=&quot;setSimpleServiceReference&quot;
    • unbind-method=&quot;unsetSimpleServiceReference&quot;
    • />
    • </component>
    • </bundle>`
    10/19/10
  • 51. Step2~4
    • 2.- Manifest
    • Bundle-Activator: org.simpleclient.impl.Activator
    • Import-Package:
    • org.ungoverned.gravity.servicebinder; specification-version=&quot;1.1.0&quot;,
    • org.simpleservice.interfaces; specification-version=&quot;1.0.0&quot;
    • Bundle-Name: simpleclient.jar
    • Bundle-Description: A simple client.
    • Bundle-Vendor: Humberto Cervantes
    • Bundle-Version: 1.0.0
    • Metadata-Location: org/simpleclient/res/metadata.xml
    10/19/10 3.- Activator package 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 { ... }
  • 52. 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(&quot;-> SimpleClient: Hello SimpleService !&quot;);
    • m_simpleServiceRefs.add(ref);
    • ref.Test();
    • }
    • public void unsetSimpleServiceReference(SimpleService ref) {
    • System.out.println(&quot;-> SimpleClient: Goodbye SimpleService ...&quot;);
    • m_simpleServiceRefs.remove(ref);
    • }
    • }
    10/19/10
  • 53. Further Concepts
    • ServiceBinderContext
    • Lifecycle
    • Interceptors
      • GenericActivator
      • protected Object proxyProvidedServiceObject(Object obj, InstanceMetadata metadata)
      • protected Object proxyRequiredServiceObject(Object obj, DependencyMetadata metadata)
    10/19/10
  • 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 
    10/19/10
  • 55. 10/19/10 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
    10/19/10
  • 57. Declarative Service Overview 10/19/10
  • 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.
    10/19/10
  • 59. Declarative Service Overview
    • LifeCycle
      • Enabled
    10/19/10 Immediate Component Delayed Component Factory Component
  • 60. Declarative Service Overview
    • Service 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
    10/19/10
  • 61. Declarative Service Examples
    • Manifest.mf
      • No Activator Header.
      • Using Service-Component Header to indicate where the Componont Description are.
    10/19/10 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=&quot;1.3.0 ……
  • 62. Declarative Service Examples 10/19/10 <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?> <component name=&quot;example.immediate&quot;> <implementation class=&quot;com.acme.USBConnectionImpl&quot;/> <service> <provide interface=&quot;com.acme.USBConnection&quot;/> </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”
  • 63. Declarative Service Examples 10/19/10 <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?> <component name=&quot;example.listen&quot;> <implementation class=&quot;com.acme.HttpResourceImpl&quot;/> <reference name=&quot;HTTP&quot; interface=&quot;org.osgi.service.http.HttpService&quot; cardinality=&quot;0..n&quot; bind=&quot;setPage&quot; unbind=&quot;unsetPage&quot;/> </component> package com.acme; public class HttpResourceImpl { protected void setPage(HttpService http) { http.registerResources(&quot;/src&quot;, &quot;src&quot;, null ); } protected void unsetPage(HttpService http) { http.unregister(&quot;/src&quot;); } } /* reference policy */ policy=“dynamic” /* filter */ taget=“(version=1.0)”
  • 64.
    • Spring-OSGi
    10/19/10
  • 65. Spring-OSGi Overview
    • SourceForge
      • SubProject of Spring
      • Licence:APL
    • Current-Version:1.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.
    10/19/10
  • 66. Spring-OSGi Overview 10/19/10
    • 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-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=&quot;1.3.0 …… META-INF/spring
  • 67. Spring-OSGi Overview
    • Export Services
      • ApplicationContext----Contains some number of beans(Components/Services)
    10/19/10 <osgi:service interface =“com.xyz.MessageService&quot;> <bean class=“MessageServiceProvider”/> </osgi:service> <bean id =“MessageServiceProvider“ class=“com.xyz.MessageServiceImpl”/> </bean> lazy-init=“true”
  • 68. Spring-OSGi Overview
    • Using Services
      • Using BundleContextAware interface
      • Inject Services
    10/19/10 <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=&quot;0..n“ filter=“(version=1.0)”
  • 69. Spring-OSGi Overview
    • Using Services
      • Binding and Unbinding Services
    10/19/10 <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){ … } }
  • 70. Spring-OSGi Overview
    • Context 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.
    10/19/10 <osgi:reference id=“MessageService“ interface=“com.xyz.MessageService” context-classloader=“client”> <osgi:listener ref=“listenerBean” bind-method=“bind” unbind-method=“bind”/> </osgi:reference> 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.springframework.osgi.context.support. WebApplicationContext”
    • JMX Manament of OSGi applications
      • Spring provide an OSGi bundle that enables JMX-based management of OSGi.
    10/19/10
  • 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
    10/19/10
  • 73. Comparison 10/19/10 ContextClassLoader Service Mngt Life Cycle Component Factory Composite Ext. & Open Container Arch. Service Binder 1.2 N Y Y Y Y N Y Declarative Service N Y Y Y N N N Spring-OSGi Y Y y N N N N iPOJO 0.7 N
  • 74. References
    • H. Cervantes and R.S. Hall. &quot;Automating Service Dependency Management in a Service-Oriented Component Model,&quot; 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
    10/19/10
  • 75. Click to edit company slogan . We can always do better than good. Thank You !