OSGi Best Practices. Emily

Transcription

1 OSGi Best Practices Emily

2 Use OSGi in the correct way...

3 AGENDA > Why OSGi? > What is OSGi? > How to best use OSGi? 3

4 Modularization in Java > Jars have no modularization characteristics No jar scoped access modifiers. No means for a jar to declare its dependencies. No versioning. Package Jar Package Package emijiang@uk.ibm.com

5 5 Problems with Global Java Path Java VM log4j barcode4j axis batik commons derby fop ezmorph freemarker httpunit jakarta jcl json jdbm jdom jenks jpos18 jython looks lucene mail mx4j naming jetty poi resolver rome serializer servlets tomcat velocity ws-commons xalan wsdl4j xerces xmlgraphics xmlrpc xmlapis.. geronimo bsh bsf guiapp hhfacility manufact. marketing minerva accounting assetmaint base bi catalina common oagis order ebay content datafile ecommerce entity googlebase ofbiz widget minilang party pos. product workeffort workflow sunjce_prov. plugin jsse jce rt dnsns.. Not Found Exception Begin Begin Here Here

6 Problems with EARs/WARs Enterprise Applications have isolated classpaths but > No Sharing Common libraries/frameworks in apps and memory > Version conflicts weba.war weba.war WEB-INF/classes/servletA.class WEB-INF/classes/servletA.class WEB-INF/lib/spring.jar WEB-INF/lib/spring.jar WEB-INF/lib/commons-logging.jar WEB-INF/lib/commons-logging.jar WEB-INF/lib/junit.jar WEB-INF/lib/junit.jar webb.war webb.war WEB-INF/classes/servletB.class WEB-INF/classes/servletB.class WEB-INF/lib/spring.jar WEB-INF/lib/spring.jar WEB-INF/lib/commons-logging.jar WEB-INF/lib/commons-logging.jar WEB-INF/lib/junit.jar WEB-INF/lib/junit.jar webc.war webc.war WEB-INF/classes/servletC.class WEB-INF/classes/servletC.class WEB-INF/lib/spring.jar WEB-INF/lib/spring.jar WEB-INF/lib/commons-logging.jar WEB-INF/lib/commons-logging.jar WEB-INF/lib/junit.jar WEB-INF/lib/junit.jar plankton.v1 plankton.v2

7 AGENDA > Why OSGi? > What is OSGi? > How to best use OSGi? 7

8 What is OSGi? The dynamic module system for Java > Mature 10-year old technology > Governed by OSGi Alliance: > Used inside just about all Java-based middleware IBM WebSphere, Oracle WebLogic, Red Hat JBoss, Sun GlassFish, Paremus Service Fabric, Eclipse Platform, Apache Geronimo, (non-exhaustive list) Jar Package Package Explicit exports Jar Package Package Explicit dependencies 8

9 OSGi Bundles and Loading OSGi Bundle A jar containing: es and resources. OSGi Bundle manifest. What s in the manifest: Bundle-Version: Multiple versions of bundles can live concurrently. Import-Package: What packages from other bundles does this bundle depend upon? Export-Package: What packages from this bundle are visible and reusable outside of the bundle? Loading Bundle Each bundle has its own loader. No flat or monolithic classpath. sharing and visibility decided by declarative dependencies, not by class loader hierarchies. OSGi framework works out the dependencies including versions. Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: MyService bundle Bundle-SymbolicName: com.sample.myservice Bundle-Version: Bundle-Activator: com.sample.myservice.activator Import-Package: com.something.i.need;version="1.1.2" Export-Package: com.myservice.api;version="1.0.0" emijiang@uk.ibm.com 9

10 OSGi Bundle Bundles have a dynamic lifecycle Bundle Can come and go independently 10

11 OSGi Service Registry Service An object associated with a list of classes (usually interfaces) it provides Dynamic (can come and go), framed by bundle lifecycle Services are the primary means of collaboration between bundles. S

12 AGENDA > Why OSGi? > What is OSGi? > How to best use OSGi? 12

13 BP1 - Use Import-Package not Require-Bundle Require-Bundle Tightly coupled with a particular bundle with the specified symbolic name and version MANIFEST.MF High coupling between bundles MANIFEST.MF Import all packages Bundle version management Require-Bundle: com.ibm.ws.service;bundle-version=2.0.0 Require-Bundle: com.ibm.ws.service;bundle-version=2.0.0 Import-Package Can wire to any bundles exporting the specified package Loose coupling between bundles Only import the package you need Package version management MANIFEST.MF MANIFEST.MF Import-Package: com.ibm.ws.service.api;version=2.0.0 Import-Package: com.ibm.ws.service.api;version= emijiang@uk.ibm.com 13

14 BP2 - Avoid split packages Split package A package is exported by two bundles at the same version and the set of classes provided by each bundle differs. Why? Leads to the use of Require-Bundle, compromising the extent to which systems using the bundles can be extended and maintained. How? Keep all of the classes from any one package in a single bundle emijiang@uk.ibm.com 14

15 BP2 - Split Package examples API A org.hal.api Implementation C org.hal.a API B org.hal.api Bundle C has to use 'Require-Bundle' to ensure that it has classes from both parts of the API Figure 1. Consumers of split packages need to use the Require-Bundle header emijiang@uk.ibm.com 15

16 BP2 - Split Package examples API A org.hal.api Implementation C org.hal.a Figure 2. A complete package exported from a single bundle maintains high bundle cohesion emijiang@uk.ibm.com 16

17 BP3 - Version bundles and packages What is semantic versioning? Uses a major.minor.micro.qualifier numbering scheme Major - Packages with versions that have different major parts are not compatible both for providers as well as consumers. Minor API enhancement, e.g. adding methods to an API Micro bug fixing Qualifier identifier such as timestamp Example: am, 1.0.0, 2.0 Changes in major: a binary incompatible, minor: enhanced API, micro: no API changes Why? Clients can protect themselves against API changes that might break them emijiang@uk.ibm.com 17

18 BP3 - Version bundles and packages examples API A Implementation A Imports: org.hal.a [1.0, 1.1) org.hal.a API B org.hal.a Client A Imports: org.hal.a [1.0, 2.0) Figure 3: A client and an implementation can use either of two equivalently versioned packages Implementation A Imports: org.hal.a [1.0, 1.1) API A org.hal.a Client A Imports: org.hal.a [1.0, 2.0) Implementation B Imports: org.hal.a [1.1, 1.2) API B org.hal.a Client B Imports: org.hal.a [1.1, 2.0) Figure 4: How a client and implementation are affected differently by a minor API version change emijiang@uk.ibm.com 18

19 BP3 - Version bundles and packages examples Implementation A Imports: org.hal.a [1.0, 1.1) org.hal.a API A Client A Imports: org.hal.a [1.0, 2.0) Implementation B Imports: org.hal.a [2.0, 2.1) API B org.hal.a Client B Imports: org.hal.a [2.0, 3.0) Figure 5. How clients and implementations are similarly affected by a major API version change emijiang@uk.ibm.com 19

20 BP4 - Separate API from Implementations Why? Great flexibility Many implementation bundles enable more services provided Reduce package dependencies reduce circular dependencies How? Put API classes in one bundle Put implementation classes in a separate bundle emijiang@uk.ibm.com 20

21 BP4 - Separate API and implementation examples API + Implementation org.hal.myapi org.hal.a.impl Client org.hal.b.client Both API and implementation packages imported by client Figure 6. Badly designed provider bundle where the API and implementation classes are in the same bundle emijiang@uk.ibm.com 21

22 BP5 - Share services not implementations Use the OSGi service registry to construct instances Why? Able to obtain an instance of an implementation without knowing which one Achieve a loosely coupling of client, API and implementation How? Register an instance of the API interface in the OSGi service registry Register an implementation of the OSGi ServiceFactory interface in the OSGi service registry emijiang@uk.ibm.com 22

23 BP4 & 5 - examples API Client org.hal.myapi org.hal.b.client Implementation org.hal.a.impl API and implementation packages in different bundles but still imported by client Figure 7. Badly designed provider bundles where the API and implementation classes have been separated emijiang@uk.ibm.com 23

24 BP4 & 5 - examples API Client org.hal.myapi org.hal.b.client Implementation org.hal.a.impl Client and implementation in separate bundles, both import API. Client uses implementation through a service defined by the API. Figure 8: Well designed provider bundles where the API and implementation classes have been separated emijiang@uk.ibm.com 24

25 Using services can be hard! private BundleContext ctx; private AtomicReference<LogService> ls = new AtomicReference<LogService>(); private AtomicReference<ServiceReference> lr = new AtomicReference<ServiceReference>(); public void start(bundlecontext ctx) throws InvalidSyntaxException { this.ctx = ctx; ctx.addservicelistener(this, "(object=org.osgi.service.log.logservice)"); ServiceReference ref = ctx.getservicereference(logservice.class.getname()); if (ref!= null) { ls.set((logservice) ctx.getservice(ref)); lr.set(ref); } public void servicechanged(serviceevent event) { ServiceReference ref = event.getservicereference(); if (ls.get() == null && event.gettype() == ServiceEvent.REGISTERED) { ls.set((logservice) ctx.getservice(ref)); } else if (ls.get()!= null && event.gettype() == ServiceEvent.UNREGISTERING && ref == lr.get()) { ref = ctx.getservicereference(logservice.class.getname()); if (ref!= null) { ls.set((logservice) ctx.getservice(ref)); lr.set(ref); } } } emijiang@uk.ibm.com 25

26 publishes service BP6 - Use Blueprint dependencies injected consumes service A static assembly and configuration of components (POJOs) OSGI-INF/blueprint/ blueprint.xml Blueprint bundle Specifies a Dependency Injection container, standardizing established Spring conventions Configuration and dependencies declared in XML module blueprint, which is a standardization of Spring application context XML. Extended for OSGi: publishes and consumes components as OSGi services Simplifies unit test outside either Java EE or OSGi r/t. The Blueprint DI container can be a part of the server runtime (compared to the Spring container which is part of the application.) emijiang@uk.ibm.com 26

27 BP6 - Blueprint service-bundle examples Billing service bundle <blueprint> <service ref= service interface = org.example.bill.billingservice /> <bean id= service scope= prototype class= org.example.bill.impl.billingserviceimpl /> </blueprint> Billing public interface BillingService { void bill(order o); } - prototype scope indicates a new instance is created by the container for each use. - singleton scope is the default emijiang@uk.ibm.com 27

28 e-commerce bundle BP6- Blueprint client-bundle examples <blueprint> <bean id= shop class= org.example.ecomm.shopimpl > <property name= billingservice ref= billingservice /> </bean> <reference id= billingservice interface= org.example.bill.billingservice /> </blueprint> e-commerce public class ShopImpl { private BillingService billingservice; void setbillingservice(billingservice srv) { billingservice = srv; } -injected service reference -service can change over time -can be temporarily absent without the bundle caring -managed by Blueprint container void process(order o) { billingservice.bill(o); } } emijiang@uk.ibm.com 28

29 BP7 Make Bundles Loosely Coupled & Highly Cohesive API org.hal.log.api FileSystemAPI Implementation org.hal.log.impl org.hal.log.impl org.hal.fslog.impl SomeotherAPI TransactionsAPI DBAPI JPAAPI 'Hairball' effect one bundle has many package dependencies Figure 9. Poorly purposed system where a single bundle provides multiple implementations of the same API emijiang@uk.ibm.com 29

30 BP7 Make Bundles Loosely Coupled & Highly Cohesive FileSystemAPI API org.hal.log.api Implementation org.hal.fslog.impl DBAPI DBAPI DBAPI Implementation Implementation Implementation org.hal.dblog.impl org.hal.dblog.impl org.hal.dblog.impl Figure 10. A well purposed system where each implementation of an API is provided by a separate bundle emijiang@uk.ibm.com 30

31 Summary OSGi Best Practices > BP1 - Use Import-Package instead of Require-Bundle > BP2 - Avoid split packages > BP3 - Version bundles and packages > BP4 - Separate API from implementations > BP5 - Share services not implementations > BP6 - Use Blueprint > BP7 - Make bundles loosely coupled & highly cohesive emijiang@uk.ibm.com 31

32 Quiz What best practices are used? blog-api Web application bundle WEB-INF/ web.xml blog-servlet JNDI Blogging Service OSGI-INF/blueprint/ blueprint.xml blog Blog Persistence Service EM META-INF/ persistence.xml OSGI-INF/blueprint/ blueprint.xml blog-persistence 32

33 Questions?

34 Additional References OSGi Best Practices Enterprise OSGi YouTube Channel: Contact: 34

35 Copyright and Trademarks IBM Corporation All Rights Reserved. IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at Copyright and trademark information at 35