• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Java Tech & Tools | OSGi Best Practices | Emily Jiang
 

Java Tech & Tools | OSGi Best Practices | Emily Jiang

on

  • 1,723 views

 

Statistics

Views

Total Views
1,723
Views on SlideShare
1,708
Embed Views
15

Actions

Likes
3
Downloads
37
Comments
0

1 Embed 15

http://lanyrd.com 15

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • WSAD512_IntroToPortal.ppt Page of 32
  • .
  • On the provider side, the BillingServiceImpl is another POJO implementing a Java interface for which a service is registered by the Blueprint container when the Billing bundle is started. By default beans are created with “singleton” scope which means only a single instance is created by the container. If the bean maintains any state then it can be declared with “prototype” scope so that the container creates a new instance each time it needs to inject the dependency into a client.
  • Here is a simple example of an eCommerce bundle which contains a “shop” bean which uses a BillingService provided by another bundle. The Blueprint container locates the Billing Service provider and injects it into the shop bean at runtime. OSGi services are dynamic so if the service provider can be changed then the blueprint container is able to dynamically rewire the reference to a new service without impacting the shop bean instance.
  • What best practices used? BP4 - Separate API from implementations BP5 - Share services not implementations BP6 – Make bundles loosely coupled & highly cohesive BP7 - Use Blueprint If you show the source code, the following three best practices can be included: BP1 - Use Import-Package instead of Require-Bundle BP2 - Avoid split packages BP3 - Version bundles and packages

Java Tech & Tools | OSGi Best Practices | Emily Jiang Java Tech & Tools | OSGi Best Practices | Emily Jiang Presentation Transcript

  • OSGi Best Practices Emily Jiang, IBM OSGi Developer, Apache Aries Committer [email_address]
      • AGENDA
        • Why OSGi?
        • What is OSGi?
        • How to best use OSGi?
        • Jars have no modularization characteristics
          • No “jar scoped” access modifiers.
          • No means for a jar to declare its dependencies.
          • No versioning.
        Modularization in Java
          Jar
          Package
          Class
          Class
          Class
          Package
          Class
          Class
          Class
          Package
          Class
          Class
          Class
        • Problems with Global Java ClassPath
          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
          ..
          Class Not Found Exception
          Begin Here
        • Problems with EARs/WARs
          Enterprise Applications have isolated classpaths but…
          • No Sharing
            • Common libraries/frameworks in apps and memory
          • Version conflicts
          webA.war WEB-INF/classes/servletA.class
          WEB-INF/lib/spring.jar WEB-INF/lib/commons-logging.jar WEB-INF/lib/junit.jar …
          webB.war WEB-INF/classes/servletB.class
          WEB-INF/lib/spring.jar WEB-INF/lib/commons-logging.jar WEB-INF/lib/junit.jar …
          webC.war WEB-INF/classes/servletC.class
          WEB-INF/lib/spring.jar WEB-INF/lib/commons-logging.jar WEB-INF/lib/junit.jar …
          plankton.v1
          plankton.v2
          • AGENDA
            • Why OSGi?
            • What is OSGi?
            • How to best use OSGi?
          • What is OSGi?
            “ The dynamic module system for Java”
            • Mature 10-year old technology
            • Governed by OSGi Alliance: http://www.osgi.org
            • 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) http://www.osgi.org/wiki/uploads/News/2008_09_16_worldwide_market.pdf
            Jar
            Jar
              Explicit exports
              Explicit dependencies
            • Package
              Class
              Class
              Class
              Class
              Class
              Class
            • Package
              Class
              Class
              Class
              Class
              Class
              Class
            • OSGi Bundles and Class Loading
              OSGi Bundle – A jar containing:
              • Classes 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?
              Class Loading
              • Each bundle has its own loader.
              • No flat or monolithic classpath.
              • Class 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 : 1.0.0 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"
              Bundle
            • OSGi Bundle
            Bundles have a dynamic lifecycle
            • Can come and go independently
              Bundle
            • 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
              • AGENDA
                • Why OSGi?
                • What is OSGi?
                • How to best use OSGi?
              • BP1 - Use Import-Package not Require-Bundle
              • Require-Bundle
                • Tightly coupled with a particular bundle with the specified symbolic name and version
                • High coupling between bundles
                • Import all packages
                • Bundle version management
              • 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 ... Require-Bundle: com.ibm.ws.service;bundle-version=2.0.0
                MANIFEST.MF ... Import-Package: com.ibm.ws.service.api;version=2.0.0
              • 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
              • BP2 - Split Package examples
                API B
                Implementation C
                org.hal.a 1.0.0
                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
                API A
                org.hal .api 1.0.0
                org.hal.a pi 1.0.0
              • BP2 - Split Package examples
                API A
                Implementation C
                org.hal.a 1.0.0
                Figure 2. A complete package exported from a single bundle maintains high bundle cohesion
                org.hal.api 1.0.0
              • 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: 1.1.2.20101122am, 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.
              • BP3 - Version bundles and packages examples
                Figure 3: A client and an implementation can use either of two equivalently versioned packages
                Figure 4: How a client and implementation are affected differently by a minor API version change
                Implementation A
                Imports: org.hal.a [1.0, 1.1)
                API A
                org.hal.a 1.0.0
                API B
                org.hal.a 1.0.0
                Client A
                Imports: org.hal.a [1.0, 2.0)
                API B
                org.hal.a 1.1.0
                API A
                org.hal.a 1.0.0
                Client A
                Imports: org.hal.a [1.0, 2.0)
                Client B
                Imports: org.hal.a [1.1, 2.0)
                Implementation B
                Imports: org.hal.a [1.1, 1.2)
                Implementation A
                Imports: org.hal.a [1.0, 1.1)
              • BP3 - Version bundles and packages examples
                Figure 5. How clients and implementations are similarly affected by a major API version change
                API A
                org.hal.a 1.0.0
                org.hal.a 2.0.0
                API B
                Client A
                Imports: org.hal.a [1.0, 2.0)
                Client B
                Imports: org.hal.a [2.0, 3.0)
                Implementation B
                Imports: org.hal.a [2.0, 2.1)
                Implementation A
                Imports: org.hal.a [1.0, 1.1)
              • 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
              • BP4 - Separate API and implementation examples
                Figure 6. Badly designed provider bundle where the API and implementation classes are in the same bundle
                API + Implementation
                org.hal.myapi
                org.hal.a.impl
                Both API and implementation packages imported by client
                Client
                org.hal.b.client
              • 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.
              • BP4 & 5 - examples
                org.hal.myapi
                API and implementation packages in different bundles but still imported by client
                Implementation
                org.hal.a.impl
                Figure 7. Badly designed provider bundles where the API and implementation classes have been separated
                API
                Client
                org.hal.b.client
              • BP4 & 5 - examples
                Figure 8: Well designed provider bundles where the API and implementation classes have been separated
                API
                org.hal.myapi
                Client
                org.hal.b.client
                Client and implementation in separate bundles, both import API. Client uses implementation through a service defined by the API.
                Implementation
                org.hal.a.impl
              • Using services can be hard!
                @Override
                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);
                } } }
                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 , &quot;(objectClass=org.osgi.service.log.LogService)&quot; ); ServiceReference ref = ctx.getServiceReference(LogService. class .getName());
                if (ref != null ) {
                ls .set((LogService) ctx.getService(ref)); lr .set(ref);
                } }
              • BP6 - Use Blueprint
              • 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.)
                dependencies injected
                publishes service
                consumes service
                A static assembly and configuration of components (POJOs) ‏
                Blueprint bundle
                OSGI-INF/blueprint/ blueprint.xml
              • BP6 - Blueprint service-bundle examples
                public interface BillingService { void bill(Order o);
                }
                Billing
                < blueprint >
                < service ref = ”service” interface = ”org.example.bill.BillingService” /> < bean id = ”service” scope = ”prototype” class = ”org.example.bill.impl.BillingServiceImpl” />
                </ blueprint >
                Billing service bundle
              • “ prototype” scope indicates a new instance is created by the container for each use.
              • “ singleton” scope is the default.
              • BP6- Blueprint client-bundle examples
                public class ShopImpl {
                private BillingService billingService ; void setBillingService(BillingService srv) {
                billingService = srv;
                }
                void process(Order o) {
                billingService .bill(o);
                } }
                e-Commerce
                < 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 bundle
              • injected service reference
              • service can change over time
              • can be temporarily absent without the bundle caring
              • managed by Blueprint container
              • BP7 – Make Bundles Loosely Coupled & Highly Cohesive
                'Hairball' effect – one bundle has many package dependencies
                org.hal.log.impl
                Implementation
                org.hal.log.impl
                SomeotherAPI
                DBAPI
                TransactionsAPI
                FileSystemAPI
                JPAAPI
                org.hal.fslog.impl
                Figure 9. Poorly purposed system where a single bundle provides multiple implementations of the same API
                API
                org.hal.log.api
              • BP7 – Make Bundles Loosely Coupled & Highly Cohesive
                Implementation
                org.hal.DBlog.impl
                DBAPI
                API
                org.hal.log.api
                Implementation
                org.hal.fslog.impl
                FileSystemAPI
                Implementation
                org.hal.DBlog.impl
                DBAPI
                Implementation
                org.hal.DBlog.impl
                DBAPI
                Figure 10. A well purposed system where each implementation of an API is provided by a separate bundle
              • BP8 – Use bundle repositories
              • 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
                • BP8 - Use Bundle Repositories
              • Quiz – What best practices are used?
                Blogging Service
                Blog Persistence Service
                blog-servlet
                Web application bundle
                META-INF/ persistence.xml
                WEB-INF/ web.xml
                OSGI-INF/blueprint/ blueprint.xml
                OSGI-INF/blueprint/ blueprint.xml
                JNDI
                EM
                blog
                blog-persistence
                blog-api
              • Questions?
              • Additional References
                OSGi Best Practices www.ibm.com/developerworks/websphere/techjournal/1007_charters/1007_charters.html Enterprise OSGi YouTube Channel: www.youtube.com/user/EnterpriseOSGi
              • Copyright and Trademarks
                © IBM Corporation 2011. 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 www.ibm.com/legal/copytrade.shtml.