SlideShare uma empresa Scribd logo
1 de 54
Is OSGi Modularity
  Always Worth It?


            Glyn Normington
Agenda

   • Costs and benefits
   • Case studies
   • When is OSGi worth it?
OSGi Benefits
✓Encapsulated module internals
 ✓Easier to understand, maintain, and extend
✓Explicit, versioned dependencies
 ✓Simplified impact analysis
 ✓Faster class loading
✓Visible architecture
 ✓bundles, services, dependencies
 ✓execution environment
OSGi Benefits
✓Side-by-side versioning
✓Dynamism
✓Loose coupling via services
OSGi Costs
Learning: OSGi, new runtime, new tools
Reusing 3rd party JARs
Designing appropriate bundles and services
Defining and upgrading dependencies
Building bundles
Debugging resolution failures and class loading
Coping with dynamism
vert.x Case Study
vert.x

• Asynchronous, event-driven web apps
• HTTP, WebSockets, sockjs
• Apps in Java, Groovy, JavaScript, Ruby
• Apps need not be thread safe
• JSON event bus
client



                         HTTP, WebSockets, sockjs



                                                                      vert.x
               server




class loader                                           class loader



    module     verticle                       busmod
    module


                 JSON                               JSON




                              event bus
Converting vert.x to OSGi

  • Convert vert.x runtime to bundles
  • Convert verticles to bundles
  • (Convert busmods to bundles - similarly)
Convert Runtime to Bundles

  • JARs:
   • vert.x core
   • Netty - network IO
   • Jackson & Jackson Mapper - JSON
Approach

• Eye-ball existing OSGi manifests
• Generate manifests where necessary
 • Use bnd or Virgo bundlor
 • Create a manifest template
• Test resolution
Existing OSGi Manifests

✓Netty
 • Bundle version 3.4.2.Final
✓Jackson & Jackson Mapper
 • Bundle version 1.9.4
Bundle vert.x core


• Use bnd or Virgo bundlor
• Manifest template required ...
vert.x Core Template

 • vert.x name and version
Bundle-ManifestVersion: 2

Bundle-SymbolicName: org.vertx.core

Bundle-Name: vert.x Core

Bundle-Version: 1.0.0.final

Export-Template: *;version="1.0.0.final"
vert.x Core Template

• Package import template version ranges
 • Netty: [3.4.2.Final, 4.0)
 • Jackson: [1.9.4, 2.0)
 • Other optional imports: 0
   • 0 means [0, ∞)
vert.x Core Template

• Package import version ranges
 • Netty: [3.4.2.Final, 4.0) Where did these
 • Jackson: [1.9.4, 2.0)      come from?

 • Other optional imports: 0
   • 0 means [0, ∞)
Version Ranges
• Lower bound
 • What did you test?
 • What old versions do you support?
• Upper bound
 • Exporter’s versioning policy?
 • How easy is it to change your bundle?
   • Lifespan?
   • Distribution?
Netty Version Range




[3.4.2.Final, 4.0)   [3.4.2.Final, 3.5)
Generate Bundle

bundlor.sh -i vert.x-core.jar
           -m vertx.core.mf
           -o vert.x-core-1.0.0.final.jar
Test Metadata
      • Using Virgo, for simplicity
      • Place dependencies in repository/usr
      • Place vert.x core in pickup
      • Start Virgo:
...

<DE0005I> Started bundle 'org.vertx.core' version '1.0.0.final'.
Modular Verticles
public class MyVerticle extends Verticle {

    public void start() {

        vertx.createHttpServer().requestHandler(
          new Handler<HttpServerRequest>() {
            public void handle(HttpServerRequest req) {
              ...
            }
          }
        ).listen(8080);

    }

}
public class MyVerticle extends Verticle {

    public void start() {

        vertx.createHttpServer().requestHandler(
          new Handler<HttpServerRequest>() {
            public void handle(HttpServerRequest req) {
              ...
            }
          }
        ).listen(8080);

    }

}
public class MyVerticle extends Verticle {

    public void start() {   redundant boilerplate
        vertx.createHttpServer().requestHandler(
          new Handler<HttpServerRequest>() {
            public void handle(HttpServerRequest req) {
              ...
            }
          }
        ).listen(8080);

    }

}
public class MyVerticle extends Verticle {

    public void start() {   redundant boilerplate
        vertx.createHttpServer().requestHandler(
          new Handler<HttpServerRequest>() {
            public void handle(HttpServerRequest req) {
              ...
            }           not easily unit tested
          }
        ).listen(8080);

    }

}
public class MyVerticle extends Verticle {

    public void start() {   redundant boilerplate
        vertx.createHttpServer().requestHandler(
          new Handler<HttpServerRequest>() {
            public void handle(HttpServerRequest req) {
              ...
            }           not easily unit tested
          }
        ).listen(8080);

    }   baked-in configuration
}
Modular Verticle
• Move boilerplate code to a support bundle
• Convert configuration to declarative
  metadata
• Use services for loose coupling
 • whiteboard pattern
public class MyHandler implements
  Handler<HttpServerRequest> {

    public void handle(HttpServerRequest req) {
      ...
    }

}
<?xml version="1.0" encoding="UTF-8"?>
<blueprint
  xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">

  <bean class="org.vertx.osgi.sample.MyHandler"
        id="handler"/>

  <service interface="org.vertx.java.core.Handler"
           ref="handler">
    <service-properties>
      <entry key="type"
             value="HttpServerRequestHandler">
      <entry key="port" value="8080">
    </service-properties>
  </service>

</blueprint>
7. request from network     org.vertx.core
                               bundle
                                                                    4. create server
                                                                    5 register handler
                                                                    6. set server listening
    9. HttpServerRequest operations           8. Handler.handle()




                                 modular
                                                                         org.vertx.osgi
                                 verticle
                                                                            bundle
                                 bundle

                          1. listen for/find bundle


                                                                                 3. listen for/find handler

         blueprint
                                2. publish handler
          service


                                                     OSGi Service Registry
Was it worth it?
Benefits
✓vertx implementation can be hidden
✓Boilerplate factored out
✓Unit testing simplified
✓Configuration externalised
Costs
Deciding dependency version ranges
Reworking vert.x to improve encapsulation
Programming model changed
Shared dependencies must be thread safe
Costs
 Deciding dependency version ranges
 Reworking vert.x to improve encapsulation
 Programming model changed
 Shared dependencies must be thread safe


Conclusion: probably not worth it
vSphere Web Client
    Case Study
vSphere Web Client

• OSGi based web server
 • Virgo Server for Apache Tomcat
• Plugins allow users to extend the Web Client
 • Custom data
 • Custom relationships (for new/existing data)
browser

                          Flex UI
                        component




                               BlazeDS


          Virgo
          (vSphere
          Web Client)
                            Data
                           Service



 ESX
 ESX
  ESX
Server
Server
 Server
          vCenter Server

 VM
  VM                     VMware
   VM
                        Inventory
                         Service
browser

                          Flex UI                         Custom Flex UI
                        component                          component




                               BlazeDS                            BlazeDS


          Virgo
          (vSphere
          Web Client)
                            Data                           Custom Data
                           Service                           Service



 ESX
 ESX
  ESX
Server
Server
 Server
          vCenter Server                 plugin zip
                                           plugin zip
                                             plugin zip
 VM
  VM                     VMware                           Remote Data
   VM
                        Inventory                           Source
                         Service
Was it worth it?
Benefits

✓Modular
✓Extensible by users
✓Internals not accessible to users
✓Dynamically updateable
Costs
Steep initial learning curve
Investment required in Virgo tooling
OSGi exposed to users
Costs
Steep initial learning curve
Investment required in Virgo tooling
OSGi exposed to users



 Conclusion: worth it
Croatian Telecom
  Case Study
Overview
• Virgo 3.0.3, EclipseLink, Atomikos,
  ActiveMQ, Tomcat clustering, Hazelcast
• In production for more than a year
 • last 7 months as a cluster
• Nearly 1 million user accounts
• 100s of web requests per second, peak
• Only one major outage, due to a Linux bug
Cited Benefits

✓Better understand components you use
✓Cleaner, higher quality code
✓Better system architecture
✓Reusable modules
Cited Costs
Time to learn the intricacies of OSGi
Time to integrate non-OSGi ready
components
Cited Costs
Time to learn the intricacies of OSGi
Time to integrate non-OSGi ready
components


   Conclusion: worth it
Wrap-up
OSGi Costs
Learning: OSGi, new runtime, new tools
Reusing 3rd party JARs
Designing appropriate bundles and services
Defining and upgrading dependencies
Building bundles
Debugging resolution failures and class loading
Coping with dynamism
Reduced isolation in some cases
Further investment in tooling required
OSGi Benefits
✓Encapsulated module internals
✓Explicit, versioned dependencies
✓Side-by-side versioning
✓Dynamism
✓Visible architecture
✓Loose coupling via services
✓used understanding of components
 Better


✓Reusable modules
When is OSGi worth it?
✓Lower layers benefit most
 ✓Control dependencies
 ✓Hide internals
    Lower layers push higher layers to OSGi

? Exposing OSGi to users
✓Long-lived or critical applications
PRO TANTO QUID RETRIBUAMUS




For so much, what shall we give in return?


           (wording from the edge of the Belfast £1 coin)
Further Information
• “Java Application Architecture” by Kirk
  Knoernschild
• http://www.osgi.org
• http://underlap.blogspot.co.uk/2012/06/osgi-
  case-study-modular-vertx.html
• http://vertx.io/
• http://underlap.blogspot.co.uk/2012/10/
  virgo-in-vsphere.html
• http://www.osgi.org/wiki/uploads/Links/
  SemanticVersioning.pdf
• “Coins” by Rob Redwood
Credits   • “Benefits of using OSGi”
               http://www.osgi.org/Technology/WhyOSGi


          • “One Pound” by Leo Reynolds

Mais conteúdo relacionado

Mais procurados

Nuxeo WebEngine and GlassFish v3
Nuxeo WebEngine and GlassFish v3Nuxeo WebEngine and GlassFish v3
Nuxeo WebEngine and GlassFish v3
Nuxeo
 

Mais procurados (20)

Grokking #9: Building a real-time and offline editing service with Couchbase
Grokking #9: Building a real-time and offline editing service with CouchbaseGrokking #9: Building a real-time and offline editing service with Couchbase
Grokking #9: Building a real-time and offline editing service with Couchbase
 
ASP.NET Core 1.0 Overview
ASP.NET Core 1.0 OverviewASP.NET Core 1.0 Overview
ASP.NET Core 1.0 Overview
 
Angular Owin Katana TypeScript
Angular Owin Katana TypeScriptAngular Owin Katana TypeScript
Angular Owin Katana TypeScript
 
ASP.NET: Present and future
ASP.NET: Present and futureASP.NET: Present and future
ASP.NET: Present and future
 
Let's play with adf 3.0
Let's play with adf 3.0Let's play with adf 3.0
Let's play with adf 3.0
 
你不可不知的 ASP.NET Core 3 全新功能探索 (.NET Conf 2019)
你不可不知的 ASP.NET Core 3 全新功能探索 (.NET Conf 2019)你不可不知的 ASP.NET Core 3 全新功能探索 (.NET Conf 2019)
你不可不知的 ASP.NET Core 3 全新功能探索 (.NET Conf 2019)
 
Micro Frontends
Micro FrontendsMicro Frontends
Micro Frontends
 
12 Factor Apps and Cloud Foundry - Twin Cities Code Camp
12 Factor Apps and Cloud Foundry - Twin Cities Code Camp12 Factor Apps and Cloud Foundry - Twin Cities Code Camp
12 Factor Apps and Cloud Foundry - Twin Cities Code Camp
 
Angular 2.0
Angular  2.0Angular  2.0
Angular 2.0
 
Refactor your Java EE application using Microservices and Containers - Arun G...
Refactor your Java EE application using Microservices and Containers - Arun G...Refactor your Java EE application using Microservices and Containers - Arun G...
Refactor your Java EE application using Microservices and Containers - Arun G...
 
Nuxeo WebEngine and GlassFish v3
Nuxeo WebEngine and GlassFish v3Nuxeo WebEngine and GlassFish v3
Nuxeo WebEngine and GlassFish v3
 
Grails 3.0 Preview
Grails 3.0 PreviewGrails 3.0 Preview
Grails 3.0 Preview
 
Dev objective2015 lets git together
Dev objective2015 lets git togetherDev objective2015 lets git together
Dev objective2015 lets git together
 
Magic of web components
Magic of web componentsMagic of web components
Magic of web components
 
Swagger code motion talk
Swagger code motion talkSwagger code motion talk
Swagger code motion talk
 
Java Microservices with Spring Boot and Spring Cloud - Denver JUG 2019
Java Microservices with Spring Boot and Spring Cloud - Denver JUG 2019Java Microservices with Spring Boot and Spring Cloud - Denver JUG 2019
Java Microservices with Spring Boot and Spring Cloud - Denver JUG 2019
 
Owin and Katana
Owin and KatanaOwin and Katana
Owin and Katana
 
Asp.net mvc 5 course module 1 overview
Asp.net mvc 5 course   module 1 overviewAsp.net mvc 5 course   module 1 overview
Asp.net mvc 5 course module 1 overview
 
Cocoon OSGi CocoonGT2007
Cocoon OSGi CocoonGT2007Cocoon OSGi CocoonGT2007
Cocoon OSGi CocoonGT2007
 
Developing modular Java applications
Developing modular Java applicationsDeveloping modular Java applications
Developing modular Java applications
 

Semelhante a Is OSGi modularity always worth it?

Successfully Deliver and Operate OpenStack in Production with VMware VIO
Successfully Deliver and Operate OpenStack in Production with VMware VIOSuccessfully Deliver and Operate OpenStack in Production with VMware VIO
Successfully Deliver and Operate OpenStack in Production with VMware VIO
Arraya Solutions
 
Big Gains With Little Virtual Machines Sumeet Mehra
Big Gains With Little Virtual Machines Sumeet MehraBig Gains With Little Virtual Machines Sumeet Mehra
Big Gains With Little Virtual Machines Sumeet Mehra
Jay Leone
 
Supporting Hyper-V 3.0 on Apache CloudStack
Supporting Hyper-V 3.0 on Apache CloudStackSupporting Hyper-V 3.0 on Apache CloudStack
Supporting Hyper-V 3.0 on Apache CloudStack
Donal Lafferty
 
Automating Software Development Life Cycle - A DevOps Approach
Automating Software Development Life Cycle - A DevOps ApproachAutomating Software Development Life Cycle - A DevOps Approach
Automating Software Development Life Cycle - A DevOps Approach
Akshaya Mahapatra
 
Building a Global-Scale Multi-Tenant Cloud Platform on AWS and Docker: Lesson...
Building a Global-Scale Multi-Tenant Cloud Platform on AWS and Docker: Lesson...Building a Global-Scale Multi-Tenant Cloud Platform on AWS and Docker: Lesson...
Building a Global-Scale Multi-Tenant Cloud Platform on AWS and Docker: Lesson...
Felix Gessert
 

Semelhante a Is OSGi modularity always worth it? (20)

Is OSGi Modularity Always Worth It? - Glyn Normington
Is OSGi Modularity Always Worth It? - Glyn NormingtonIs OSGi Modularity Always Worth It? - Glyn Normington
Is OSGi Modularity Always Worth It? - Glyn Normington
 
Groovy & Grails eXchange 2012 vert.x presentation
Groovy & Grails eXchange 2012 vert.x presentationGroovy & Grails eXchange 2012 vert.x presentation
Groovy & Grails eXchange 2012 vert.x presentation
 
Vert.x devoxx london 2013
Vert.x devoxx london 2013Vert.x devoxx london 2013
Vert.x devoxx london 2013
 
Deploying windows containers with kubernetes
Deploying windows containers with kubernetesDeploying windows containers with kubernetes
Deploying windows containers with kubernetes
 
Virtualizing Apache Spark and Machine Learning with Justin Murray
Virtualizing Apache Spark and Machine Learning with Justin MurrayVirtualizing Apache Spark and Machine Learning with Justin Murray
Virtualizing Apache Spark and Machine Learning with Justin Murray
 
Successfully Deliver and Operate OpenStack in Production with VMware VIO
Successfully Deliver and Operate OpenStack in Production with VMware VIOSuccessfully Deliver and Operate OpenStack in Production with VMware VIO
Successfully Deliver and Operate OpenStack in Production with VMware VIO
 
Best Practices for Running Kafka on Docker Containers
Best Practices for Running Kafka on Docker ContainersBest Practices for Running Kafka on Docker Containers
Best Practices for Running Kafka on Docker Containers
 
App fabric introduction
App fabric introductionApp fabric introduction
App fabric introduction
 
Big Gains With Little Virtual Machines Sumeet Mehra
Big Gains With Little Virtual Machines Sumeet MehraBig Gains With Little Virtual Machines Sumeet Mehra
Big Gains With Little Virtual Machines Sumeet Mehra
 
Supporting Hyper-V 3.0 on Apache CloudStack
Supporting Hyper-V 3.0 on Apache CloudStackSupporting Hyper-V 3.0 on Apache CloudStack
Supporting Hyper-V 3.0 on Apache CloudStack
 
OSGi Cloud Ecosystems (OSGi Users Forum Germany)
OSGi Cloud Ecosystems (OSGi Users Forum Germany)OSGi Cloud Ecosystems (OSGi Users Forum Germany)
OSGi Cloud Ecosystems (OSGi Users Forum Germany)
 
Java servlet technology
Java servlet technologyJava servlet technology
Java servlet technology
 
Vsphere 4-partner-training180
Vsphere 4-partner-training180Vsphere 4-partner-training180
Vsphere 4-partner-training180
 
Automating Software Development Life Cycle - A DevOps Approach
Automating Software Development Life Cycle - A DevOps ApproachAutomating Software Development Life Cycle - A DevOps Approach
Automating Software Development Life Cycle - A DevOps Approach
 
Learn OpenStack from trystack.cn ——Folsom in practice
Learn OpenStack from trystack.cn  ——Folsom in practiceLearn OpenStack from trystack.cn  ——Folsom in practice
Learn OpenStack from trystack.cn ——Folsom in practice
 
Open stack in sina
Open stack in sinaOpen stack in sina
Open stack in sina
 
Automating CloudStack with Puppet - David Nalley
Automating CloudStack with Puppet - David NalleyAutomating CloudStack with Puppet - David Nalley
Automating CloudStack with Puppet - David Nalley
 
Running eZ Platform on Kubernetes (presented by Björn Dieding at eZ Conferenc...
Running eZ Platform on Kubernetes (presented by Björn Dieding at eZ Conferenc...Running eZ Platform on Kubernetes (presented by Björn Dieding at eZ Conferenc...
Running eZ Platform on Kubernetes (presented by Björn Dieding at eZ Conferenc...
 
Building a Global-Scale Multi-Tenant Cloud Platform on AWS and Docker: Lesson...
Building a Global-Scale Multi-Tenant Cloud Platform on AWS and Docker: Lesson...Building a Global-Scale Multi-Tenant Cloud Platform on AWS and Docker: Lesson...
Building a Global-Scale Multi-Tenant Cloud Platform on AWS and Docker: Lesson...
 
Liferay (DXP) 7 Tech Meetup for Developers
Liferay (DXP) 7 Tech Meetup for DevelopersLiferay (DXP) 7 Tech Meetup for Developers
Liferay (DXP) 7 Tech Meetup for Developers
 

Mais de glynnormington

Multi-bundle Scoping in OSGi
Multi-bundle Scoping in OSGiMulti-bundle Scoping in OSGi
Multi-bundle Scoping in OSGi
glynnormington
 

Mais de glynnormington (6)

Practical OSGi Subsystems
Practical OSGi SubsystemsPractical OSGi Subsystems
Practical OSGi Subsystems
 
Multi-bundle Scoping in OSGi
Multi-bundle Scoping in OSGiMulti-bundle Scoping in OSGi
Multi-bundle Scoping in OSGi
 
Multibundle Scoping in OSGi
Multibundle Scoping in OSGiMultibundle Scoping in OSGi
Multibundle Scoping in OSGi
 
Donating a mature project to Eclipse
Donating a mature project to EclipseDonating a mature project to Eclipse
Donating a mature project to Eclipse
 
Virgo Project Creation Review
Virgo Project Creation ReviewVirgo Project Creation Review
Virgo Project Creation Review
 
Eclipse Virgo
Eclipse VirgoEclipse Virgo
Eclipse Virgo
 

Is OSGi modularity always worth it?

  • 1. Is OSGi Modularity Always Worth It? Glyn Normington
  • 2. Agenda • Costs and benefits • Case studies • When is OSGi worth it?
  • 3. OSGi Benefits ✓Encapsulated module internals ✓Easier to understand, maintain, and extend ✓Explicit, versioned dependencies ✓Simplified impact analysis ✓Faster class loading ✓Visible architecture ✓bundles, services, dependencies ✓execution environment
  • 5. OSGi Costs Learning: OSGi, new runtime, new tools Reusing 3rd party JARs Designing appropriate bundles and services Defining and upgrading dependencies Building bundles Debugging resolution failures and class loading Coping with dynamism
  • 7. vert.x • Asynchronous, event-driven web apps • HTTP, WebSockets, sockjs • Apps in Java, Groovy, JavaScript, Ruby • Apps need not be thread safe • JSON event bus
  • 8. client HTTP, WebSockets, sockjs vert.x server class loader class loader module verticle busmod module JSON JSON event bus
  • 9. Converting vert.x to OSGi • Convert vert.x runtime to bundles • Convert verticles to bundles • (Convert busmods to bundles - similarly)
  • 10. Convert Runtime to Bundles • JARs: • vert.x core • Netty - network IO • Jackson & Jackson Mapper - JSON
  • 11. Approach • Eye-ball existing OSGi manifests • Generate manifests where necessary • Use bnd or Virgo bundlor • Create a manifest template • Test resolution
  • 12. Existing OSGi Manifests ✓Netty • Bundle version 3.4.2.Final ✓Jackson & Jackson Mapper • Bundle version 1.9.4
  • 13. Bundle vert.x core • Use bnd or Virgo bundlor • Manifest template required ...
  • 14. vert.x Core Template • vert.x name and version Bundle-ManifestVersion: 2 Bundle-SymbolicName: org.vertx.core Bundle-Name: vert.x Core Bundle-Version: 1.0.0.final Export-Template: *;version="1.0.0.final"
  • 15. vert.x Core Template • Package import template version ranges • Netty: [3.4.2.Final, 4.0) • Jackson: [1.9.4, 2.0) • Other optional imports: 0 • 0 means [0, ∞)
  • 16. vert.x Core Template • Package import version ranges • Netty: [3.4.2.Final, 4.0) Where did these • Jackson: [1.9.4, 2.0) come from? • Other optional imports: 0 • 0 means [0, ∞)
  • 17. Version Ranges • Lower bound • What did you test? • What old versions do you support? • Upper bound • Exporter’s versioning policy? • How easy is it to change your bundle? • Lifespan? • Distribution?
  • 18. Netty Version Range [3.4.2.Final, 4.0) [3.4.2.Final, 3.5)
  • 19. Generate Bundle bundlor.sh -i vert.x-core.jar -m vertx.core.mf -o vert.x-core-1.0.0.final.jar
  • 20. Test Metadata • Using Virgo, for simplicity • Place dependencies in repository/usr • Place vert.x core in pickup • Start Virgo: ... <DE0005I> Started bundle 'org.vertx.core' version '1.0.0.final'.
  • 22. public class MyVerticle extends Verticle { public void start() { vertx.createHttpServer().requestHandler( new Handler<HttpServerRequest>() { public void handle(HttpServerRequest req) { ... } } ).listen(8080); } }
  • 23. public class MyVerticle extends Verticle { public void start() { vertx.createHttpServer().requestHandler( new Handler<HttpServerRequest>() { public void handle(HttpServerRequest req) { ... } } ).listen(8080); } }
  • 24. public class MyVerticle extends Verticle { public void start() { redundant boilerplate vertx.createHttpServer().requestHandler( new Handler<HttpServerRequest>() { public void handle(HttpServerRequest req) { ... } } ).listen(8080); } }
  • 25. public class MyVerticle extends Verticle { public void start() { redundant boilerplate vertx.createHttpServer().requestHandler( new Handler<HttpServerRequest>() { public void handle(HttpServerRequest req) { ... } not easily unit tested } ).listen(8080); } }
  • 26. public class MyVerticle extends Verticle { public void start() { redundant boilerplate vertx.createHttpServer().requestHandler( new Handler<HttpServerRequest>() { public void handle(HttpServerRequest req) { ... } not easily unit tested } ).listen(8080); } baked-in configuration }
  • 27. Modular Verticle • Move boilerplate code to a support bundle • Convert configuration to declarative metadata • Use services for loose coupling • whiteboard pattern
  • 28. public class MyHandler implements Handler<HttpServerRequest> { public void handle(HttpServerRequest req) { ... } }
  • 29. <?xml version="1.0" encoding="UTF-8"?> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"> <bean class="org.vertx.osgi.sample.MyHandler" id="handler"/> <service interface="org.vertx.java.core.Handler" ref="handler"> <service-properties> <entry key="type" value="HttpServerRequestHandler"> <entry key="port" value="8080"> </service-properties> </service> </blueprint>
  • 30. 7. request from network org.vertx.core bundle 4. create server 5 register handler 6. set server listening 9. HttpServerRequest operations 8. Handler.handle() modular org.vertx.osgi verticle bundle bundle 1. listen for/find bundle 3. listen for/find handler blueprint 2. publish handler service OSGi Service Registry
  • 32. Benefits ✓vertx implementation can be hidden ✓Boilerplate factored out ✓Unit testing simplified ✓Configuration externalised
  • 33. Costs Deciding dependency version ranges Reworking vert.x to improve encapsulation Programming model changed Shared dependencies must be thread safe
  • 34. Costs Deciding dependency version ranges Reworking vert.x to improve encapsulation Programming model changed Shared dependencies must be thread safe Conclusion: probably not worth it
  • 35. vSphere Web Client Case Study
  • 36. vSphere Web Client • OSGi based web server • Virgo Server for Apache Tomcat • Plugins allow users to extend the Web Client • Custom data • Custom relationships (for new/existing data)
  • 37. browser Flex UI component BlazeDS Virgo (vSphere Web Client) Data Service ESX ESX ESX Server Server Server vCenter Server VM VM VMware VM Inventory Service
  • 38. browser Flex UI Custom Flex UI component component BlazeDS BlazeDS Virgo (vSphere Web Client) Data Custom Data Service Service ESX ESX ESX Server Server Server vCenter Server plugin zip plugin zip plugin zip VM VM VMware Remote Data VM Inventory Source Service
  • 40. Benefits ✓Modular ✓Extensible by users ✓Internals not accessible to users ✓Dynamically updateable
  • 41. Costs Steep initial learning curve Investment required in Virgo tooling OSGi exposed to users
  • 42. Costs Steep initial learning curve Investment required in Virgo tooling OSGi exposed to users Conclusion: worth it
  • 43. Croatian Telecom Case Study
  • 44. Overview • Virgo 3.0.3, EclipseLink, Atomikos, ActiveMQ, Tomcat clustering, Hazelcast • In production for more than a year • last 7 months as a cluster • Nearly 1 million user accounts • 100s of web requests per second, peak • Only one major outage, due to a Linux bug
  • 45. Cited Benefits ✓Better understand components you use ✓Cleaner, higher quality code ✓Better system architecture ✓Reusable modules
  • 46. Cited Costs Time to learn the intricacies of OSGi Time to integrate non-OSGi ready components
  • 47. Cited Costs Time to learn the intricacies of OSGi Time to integrate non-OSGi ready components Conclusion: worth it
  • 49. OSGi Costs Learning: OSGi, new runtime, new tools Reusing 3rd party JARs Designing appropriate bundles and services Defining and upgrading dependencies Building bundles Debugging resolution failures and class loading Coping with dynamism Reduced isolation in some cases Further investment in tooling required
  • 50. OSGi Benefits ✓Encapsulated module internals ✓Explicit, versioned dependencies ✓Side-by-side versioning ✓Dynamism ✓Visible architecture ✓Loose coupling via services ✓used understanding of components Better ✓Reusable modules
  • 51. When is OSGi worth it? ✓Lower layers benefit most ✓Control dependencies ✓Hide internals Lower layers push higher layers to OSGi ? Exposing OSGi to users ✓Long-lived or critical applications
  • 52. PRO TANTO QUID RETRIBUAMUS For so much, what shall we give in return? (wording from the edge of the Belfast £1 coin)
  • 53. Further Information • “Java Application Architecture” by Kirk Knoernschild • http://www.osgi.org • http://underlap.blogspot.co.uk/2012/06/osgi- case-study-modular-vertx.html • http://vertx.io/ • http://underlap.blogspot.co.uk/2012/10/ virgo-in-vsphere.html • http://www.osgi.org/wiki/uploads/Links/ SemanticVersioning.pdf
  • 54. • “Coins” by Rob Redwood Credits • “Benefits of using OSGi” http://www.osgi.org/Technology/WhyOSGi • “One Pound” by Leo Reynolds

Notas do Editor

  1. \n
  2. \n
  3. \n
  4. \n
  5. \n
  6. \n
  7. \n
  8. \n
  9. \n
  10. \n
  11. \n
  12. \n
  13. \n
  14. \n
  15. \n
  16. \n
  17. Exporter&amp;#x2019;s versioning policy is implicit in the manifest.\n
  18. \n
  19. \n
  20. \n
  21. \n
  22. \n
  23. \n
  24. \n
  25. \n
  26. \n
  27. \n
  28. \n
  29. \n
  30. \n
  31. \n
  32. \n
  33. \n
  34. \n
  35. \n
  36. \n
  37. \n
  38. \n
  39. \n
  40. \n
  41. \n
  42. \n
  43. \n
  44. \n
  45. \n
  46. \n
  47. \n
  48. \n
  49. \n
  50. \n
  51. \n
  52. \n
  53. \n
  54. \n