1 / 74

Service-Oriented Component Model

Service-Oriented Component Model. zhangyf05@sei.pku.edu.cn youchao06@sei.pku.edu.cn April 18,2007. 1. 2. Service-Oriented Component Model. 2. 3. 4. 5. 6. A Glance at OSGi. iPOJO & Service Binder. DS & Spring OSGi. Comparison. Summary. Content. Service Registry.

Télécharger la présentation

Service-Oriented Component Model

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Service-Oriented Component Model zhangyf05@sei.pku.edu.cn youchao06@sei.pku.edu.cn April 18,2007

  2. 1 2 Service-Oriented Component Model 2 3 4 5 6 A Glance at OSGi iPOJO & Service Binder DS & Spring OSGi Comparison Summary Content 2

  3. Service Registry Service Specification Service Consumer ServiceProvider Service-Oriented Model • Service: Contract of defined behavior Lookup Publication Bind & Invoke 3

  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 4

  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 5

  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 6

  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 7

  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 8

  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 9

  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

  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 11

  12. OSGi Platform • Dynamic feature • Departure & arrival of services • Monitoring • Dependency management • Only notifications • Reconfiguration • Example • Service publication • Service discovery • Service invocation • Service dynamics 12

  13. Example 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; • ... • 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"); • ....... • } • } 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); } 13

  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 2014/11/19 14

  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) 15

  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) 16

  17. a service component framework 17

  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 18

  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™ 19

  20. Concepts: Component 20 • 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 INVALID Created Configured Stopped VALID Destroyed 21 A component instance is either VALID or INVALID A component instance is VALID  All handlers are valid 21

  22. Concepts: Container Dependency Provided Service Lifecycle Configuration Architecture 22 • 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

  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 23

  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 24

  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 25

  26. Dependency Handler 26

  27. Architecture Handler • An architectural / component view of your systems • 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 27

  28. 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 29

  29. Example • A component requiring a service • The needed service is mandatory • The component require only one service provider • A component providing a service 30

  30. 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 31

  31. 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() { …} } 32

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

  33. Step 2 : the Component Types <component classname=“…MyFirstPOJO” factory = “myFirstType” > <dependency field=”myService”/> </component> <component classname=“…MySecondPOJO” factory = “mySecondType” > <provides/> </component> 34

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

  35. Step 3 : Component Instances <instance component=“myFirstType” name = “myFirstInstance” /> <instance component=“mySecondType” name = “mySecondInstance” /> 36

  36. Step 4 : Packaging and Deployment POJO POJO POJO POJO <meta> {meta + manipulation} POJO iPOJO • iPOJO Bundles are not simple bundles • Bytecode Manipulation • Metadata exports • How-to create an iPOJO Bundle • With Maven • With the Eclipse plugin (experimental) 37

  37. Step 5 : Runtime myFirstType mySecondType Factory Factory 1.1 instance 2.1 instance FooService 38

  38. 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 39

  39. 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 40

  40. 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 41

  41. Service Binder Simplifying application development on the OSGi services platform 42

  42. 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 43

  43. Execution Environment • Compatibility with standard' OSGi • Generic activator • Parse component descriptor • creates the instance managers • Architectural service 44

  44. 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 45

  45. 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 46

  46. Instance Manager 47

  47. 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 48

  48. 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. 49

  49. Example: Step1 1.- 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>` 50

  50. Step2~4 2.- Manifest Bundle-Activator: org.simpleclient.impl.Activator Import-Package: org.ungoverned.gravity.servicebinder; specification-version="1.1.0", org.simpleservice.interfaces; specification-version="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.xml 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 { ... } 51

More Related