WE20: Declarative Services in OSGi R4 ApacheCon US 2005

1. WE20: Declarative Services in OSGi R4ApacheCon US 2005 BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO, OSGi Alliance

2. OSGi Alliance • Work began as an ad hoc group called the Connected Alliance in 1998 • The OSGi Alliance was founded in March, 1999 • As an independent, worldwide, non-profit organization with open membership • JSR-008 was withdrawn and technical work moved to the OSGi Alliance • OSGi Service Gateway Release 1.0 was published in May 2000…

3. OSGi Service Platform R4 Core • Framework Layering • Conditional Permission Admin • Declarative Services • Event Admin Mobile • DMT Admin • Deployment Admin • Foreign Applications • Mobile Management Tree Vehicle • Power Management • Metatype 2 • Diagnostic • Vehicle API R3 UPnP Initial Provisioning Name Space Jini Start Level IO Connector Wire Admin XML Parser Measurement & State Position Execution Environments URL Handler R2 Package Admin Configuration Admin Permission Admin User Admin Preferences MetaType Service Tracker R1 Framework Http Log Device Access 2000 2001 2003 2005

4. Bundle (Application) Framework OSGi Java Operating System Overall Architecture Driver Driver Driver Hardware = service

5. What does the OSGi Framework provide? • Horizontal Software Integration Platform • Component Oriented Architecture • Module (Bundles) • Package sharing and version management • Life-cycle management and notification (events) • Service Oriented Architecture • Publish/find/bind intra-VM service model • Life-cycle notification (events) • Open remote management architecture • No prescribed policy or protocol

6. Framework Features • Runs multiple applications and services • Single VM instance • Separate class loader per bundle • Class loader network • Independent namespaces • Class sharing at the Java package level • Lifecycle management of bundles • Intra VM publish/find/bind service model • Java Permissions to secure framework

7. L3 – Provides a publish/find/bind service model to decouple bundles SERVICE L2 - Manages the lifecycle of bundle in a bundle repository without requiring the VM be restarted LIFECYCLE L1 - Creates the concept of modules (aka. bundles) that use classes from each other in a controlled way according to system and bundle constraints MODULE Execution Environment L0 - • OSGi Minimum Execution Environment • CDC/Foundation • J2SE CDC CDC Framework Layering

8. Service Layer • Defines a publish/find/bind service model • Fully dynamic • Intra VM • Non-durable service registry • A service is a normal Java object published under one or more Java interfaces with additional metadata • Clear separation between interface and implementation • Find mechanism support searching on both interface name and metadata values • Service lifecycle is highly dynamic • Service may be published or unpublished at any time • Lifecycle event notifications

9. Service Orientation Service Registry publish find Service Description Service Provider Service Consumer interact

10. Service Registry • Service – An object registered with the service registry under one or more interfaces together with properties • Service Registration – The receipt provided when a service is registered • Allows the update of the service properties and the unregistration of the service • Service Reference – Token that provides access to the service’s properties but not the actual service object • Service Factory – A facility to let the registrant customize the service object provided to each using bundle • Service Event – An event holding information about the registration, modification, or unregistration of a service • Service Listener – A listener to Service Events

11. Service API (Procedural Model) • Publish service • ServiceRegistration registerService(String interfaceName, Object service, Dictionary properties) • Find service • ServiceReference[] getServiceReferences(String interfaceName, String filter) • Bind to service • Object getService(ServiceReference reference)

12. Issues with Basic API Usage • Services and the bundles which register them can come and go during the lifetime of the framework • Many programmers are not prepared to deal with such dynamism • Bundle programmer must not use unregistered services • Common problem in every bundle • So ServiceTracker was introduced…

13. Service Tracker • Class which can be instantiated to track specific services • Tracks list of registered services which match specified tracking criteria • Can customize behavior when service added and removed • Implemented to correctly handle dynamism of service model

14. Service Tracker Example // Create and configure the tracker ServiceTracker logTracker = new ServiceTracker(context, LogService.class.getName(), null); // Open the tracker to start tracking services logTracker.open(); // Get a service from the tracker LogService log = (LogService)logTracker.getService(); // Use the service log.log(LogService.LOG_INFO, “A message”); // Close the tracker and cease tracking services logTracker.close();

15. Still have issues with ServiceTracker and Service API (1) • Requires programmer to code to OSGi API • Not an Inversion of Control model • Services and bundles can come and go during the lifetime of the VM • Many programmers are not prepared to deal with such dynamism. • We want a simplification of the programming model for using services in OSGi so that new programmers can declare their service relationships and then have them managed by the runtime rather than having to write code to call OSGi API

16. Still have issues with ServiceTracker and Service API (2) • Lack of metadata • The framework or a management system does not know what services, if any, a bundle may provide or consume until the bundle executes and calls the framework

17. Still have issues with ServiceTracker and Service API (3) • Performance • The procedural model requires that bundles must execute in order to publish a service • This means the bundle must have a class loader, classes must be loaded and objects instantiated and some code executed which will explicitly publish the service • We would rather be able to declaratively specify that a bundle will publish a service and thus delay creating class loaders, loading classes and instantiating objects until some other bundle actually desires to consume the service

18. Research Effort: Service Binder • Service Binder 1.0 was released November 22, 2002 • Humberto Cervantes and Richard S. Hall • Focused on the dynamic aspects of OSGi services • Services may arrive or depart at any time • Addressed metadata and simplified programming issues • But not performance issue • Major influence on design of Declarative Services in OSGi R4 • Subsumes all of Service Binder's functionality • Adopted similar, but extended metadata

19. OSGi R4 adds Declarative Services • New declarative programming model for services • Defines service metadata • Addresses performance concerns • Simplifies programming model for using services • POJO • Can conceal all service dynamism from component • Fully integrates with existing procedural model • So bundles written to Service API can work with bundles using Declarative Services

20. Service Components • Contained within a bundle • Their lifecycle is contained within their bundle’s lifecycle • Identified by an implementation class • Optionally provides a service which is registered as an OSGi service • Optionally references other OSGi services (which may be provided by other components) • Optionally configured • Can be lazily activated • This means the creation and activation of a component can be delayed until the component is actually used. • Uses dependency injection to configure • Described by an XML document • Managed by a central runtime: Service Component Runtime (SCR)

21. Service Component Terms • Component Description – The declaration of a service component. It is contained within an XML document in a bundle. • Component Properties – A set of properties which can be specified by the component description, Configuration Admin service and from the component factory. • Component Configuration – A component configuration represents a component description parameterized by component properties. It is the entity that tracks the component dependencies and manages a component instance. An activated component configuration has a component context. • Component Instance – An instance of the component implementation class. A component instance is created when a component configuration is activated and discarded when the component configuration is deactivated. A component instance is associated with exactly one component configuration. • Reference – A specified dependency of a component on a set of target services. • Target Services – The set of services that is defined by the reference interface and target property filter. • Bound Services – The set of target services that are bound to a component configuration.

22. Component Description <?xml version="1.0" encoding="UTF-8"?> <component name="component.name“> <implementation class=“org.foo.impl.ComponentImpl" /> <property name=“foo.property” value=“some.value”/> <service> <provide interface="org.foo.Service"/> </service> <reference name="otherService" interface="org.foo.OtherService“ bind=“bindOtherService” unbind=“unbindOtherService”/> </component>

23. Defines a component and its name Component Description <?xml version="1.0" encoding="UTF-8"?> <component name="component.name“> <implementation class=“org.foo.impl.ComponentImpl" /> <property name=“foo.property” value=“some.value”/> <service> <provide interface="org.foo.Service"/> </service> <reference name="otherService" interface="org.foo.OtherService" bind=“bindOtherService” unbind=“unbindOtherService”/> </component>

24. Component Description <?xml version="1.0" encoding="UTF-8"?> <component name="component.name“> <implementation class=“org.foo.impl.ComponentImpl" /> <property name=“foo.property” value=“some.value”/> <service> <provide interface="org.foo.Service"/> </service> <reference name="otherService" interface="org.foo.OtherService" bind=“bindOtherService” unbind=“unbindOtherService”/> </component> Specifies the implementation class of the component

25. Component Description <?xml version="1.0" encoding="UTF-8"?> <component name="component.name“> <implementation class=“org.foo.impl.ComponentImpl" /> <property name=“foo.property” value=“some.value”/> <service> <provide interface="org.foo.Service"/> </service> <reference name="otherService" interface="org.foo.OtherService" bind=“bindOtherService” unbind=“unbindOtherService”/> </component> • Specifies that the component provides a service and the interfaces the service implements • The implementation class must implement these interfaces

26. Component Description <?xml version="1.0" encoding="UTF-8"?> <component name="component.name“> <implementation class=“org.foo.impl.ComponentImpl" /> <property name=“foo.property” value=“some.value”/> <service> <provide interface="org.foo.Service"/> </service> <reference name="otherService" interface="org.foo.OtherService“ bind=“bindOtherService” unbind=“unbindOtherService”/> </component> Specifies that the component references a service and the interface it expects the service to implement

27. The description for a component must first be enabled This is the initial state but can be altered Component Description Lifecycle DISABLED enable disable ENABLED

28. Component Configuration Lifecycle • A component configuration must be satisfied before it can be activated • This means all the component’s references to other services can be satisfied • The component instance is activated as required • An instance of the component implementation class is created using the default constructor • The bind methods, if any, are called to inject the objects for the bound services • The activate method, if present, is called to inject the context for the component and mark the end of activation • Component instances are deactivated when any reference becomes unsatisfied • The deactivate method is called, if present, followed by the unbind methods, if there are any bound services UNSATISFIED SATISFIED ACTIVATED

29. Component Activation • Uses Setter Injection to provide component instance with access to execution context • If component implements protected void activate(ComponentContext) method, then it will be called to pass in component’s context • Context can be used to • Access component properties • Perform contextualized lookup of services

30. References to Services: Strategy • Objects for referenced service can be obtain in two ways • Event Strategy • Useful to set fields during component activation • Useful to be notified of changes in the state of services which are dynamically bound • Lookup Strategy • Useful to avoid service object creation until service is needed • In support of lazy activation

31. Event Strategy • Setter Injection • Bind and unbind methods are specified in the component description which are called by runtime when referenced services are bound and unbound from the component instance <reference name="otherService" interface="org.foo.OtherService“ bind=“bindOtherService” unbind=“unbindOtherService”/> protected void bindOtherService(OtherService other) { … }

32. Lookup Strategy • Contextualized Lookup/Dynamic Service Locator • The component can call the component context with the service name specified in the component description • Allows runtime to delay activation of referenced service <reference name="otherService" interface="org.foo.OtherService“/> protected void activate(ComponentContext context) { OtherService other = (OtherService) context.locateService(“otherService”); }

33. References to Services: Policy • Policy controls visibility of dynamism to component • Static policy • Component instance will only be active if the reference is satisfied • If reference becomes unsatisfied, the component instance is deactivated • Hides dynamism from component • Dynamic policy • Component can see dynamism of referenced service

34. References to Services: Cardinality • Optionality • Reference can be satisfied even if no target service exists • Multiplicity • Reference can support 1 or more bound services 0..1 – Optional and unary1..1 – Mandatory and unary (Default)0..n – Optional and multiple1..n – Mandatory and multiple

35. Component Properties • Properties can be accessed via component context • Set by union of • Component description • property elements • properties files • Configuration Admin configuration under component name • Component Factory if created by component factory • Properties can be overridden by later setters

36. Service Component Types • Delayed Component – A component whose component configurations are activated when their service is requested. • Immediate Component – A component whose component configurations are activated immediately upon becoming satisfied. • Factory Component – A component whose component configurations are created and activated through the component’s component factory.

37. Declarative Services • New declarative programming model for services • Simplifies programming model for using services • Dependency Injection • POJO • Supports service dynamism • Details handled by the runtime • Programmer can focus on business logic and not infrastructure details • Fully integrates with existing OSGi procedural service model

38. Questions?