Dynamic Deployment   Oredev 2009
Upcoming SlideShare
Loading in...5
×
 

Dynamic Deployment Oredev 2009

on

  • 1,243 views

At Oredev 2009, I presented 'dynamic deployment with OSGi': how can you leverage OSGi as a module system to make your development cycle more complete, including deployment and customer support?

At Oredev 2009, I presented 'dynamic deployment with OSGi': how can you leverage OSGi as a module system to make your development cycle more complete, including deployment and customer support?

Be sure to check the slide notes; this presentation is intended as a background for me talking, so the slides themselves might not give you all information.

Statistics

Views

Total Views
1,243
Views on SlideShare
1,240
Embed Views
3

Actions

Likes
2
Downloads
29
Comments
0

1 Embed 3

http://www.slideshare.net 3

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

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
  • - Who am I? Angelo, Luminis, Apache ACE committer <br /> - We will show a case that feels familiar to most of us, and use that as a showcase for using component technology and deployment. <br /> - Will go into OSGi a little, <br /> - I will show what dynamic deployment is all about <br /> - And wrap up with a demo
  • You start out with the idea of a great drawing application
  • You start out with a monolithic application <br /> <br /> http://www.flickr.com/photos/minegro/3097817447/
  • Growing software always has its peril. <br /> Customers will start demanding &#x2018;specials&#x2019; you don&#x2019;t want everyone to have, since you might want to charge for them. <br /> The specials start cluttering up your code, making it very hard to maintain
  • Growing software always has its peril. <br /> Customers will start demanding &#x2018;specials&#x2019; you don&#x2019;t want everyone to have, since you might want to charge for them. <br /> The specials start cluttering up your code, making it very hard to maintain
  • Build times start ramping up: engineers fire up a build shortly before lunch so they can see the results before going home that evening. <br /> http://xkcd.com/303/
  • It soon becomes hard to enforce your architecture, due to all of the specials that need to &#x2018;hook in&#x2019; somewhere <br /> <br /> http://www.flickr.com/photos/lance_mountain/142158155/sizes/o/ <br /> http://www.answersingenesis.org/assets/images/articles/utp/chap8/userkafs-pyramid.jpg
  • It soon becomes hard to enforce your architecture, due to all of the specials that need to &#x2018;hook in&#x2019; somewhere <br /> <br /> http://www.flickr.com/photos/lance_mountain/142158155/sizes/o/ <br /> http://www.answersingenesis.org/assets/images/articles/utp/chap8/userkafs-pyramid.jpg
  • You have a load of code, nicely communicating through interfaces. <br /> Note that in many applications some sort of layering shows up.
  • We overlay the Java packages here. These are quite fixed: how long would ik take you to restructure your packages? <br /> <br /> <br /> This really is the basis for subsequently designing both: <br /> - your package view / development view <br /> - your deployment view <br /> Reference the 4+1 view here: <br /> - to remain agile, you have to constantly manage your dependencies: <br /> -> test, how quickly could you completely redesign your packages??? (hours, days, weeks?)
  • So, we group these packages into components; this could be the basis of your package/deployment view. <br /> Note that while packages are rather fixed, carving up this package space isn&#x2019;t necessarily: we can rather easily change the packaging, or even have various forms together.
  • (from osgi.org) OSGi is based on the &#x201C;home gateway&#x201D; market, but later on profiled itself as &#x2018;universal middleware&#x2019;. Now, it just uses the term &#x2018;dynamic module system&#x2019;. OSGi is often seen as an application server, but it actually spans the range from embedded devices to enterprise servers.
  • The specification consists of two parts: a core specification and a service compendium. The core describes the framework itself and some core services. The compendium describes a lot of service interfaces, standardized so different implementations can be substituted easily. Of most of these services, multiple open source implementations exist already. <br /> Recently, version 4.2 of the specification has been has been released, focussing mostly on enterprise-related elements.
  • The framework itself is build out of a couple of layers, starting at the bottom with the execution environment, which describes the exact set of Java API&#x2019;s that are considered part of the environment. By having different environments, bundles can specify for example if they can run on Java 1.4, 5 or 6. You can even make your own environments. <br /> <br /> On top of that, the module, life cycle and service layers are built.
  • At the module layer, the software is grouped into bundles (also known as plugins in Eclipse), where each bundle contains zero or more Java packages and optionally some other resources or even native libraries. Some of these packages are exported, meaning they can be used by other bundles, others are private and only visible within a specific bundle. Packages that are exported by one bundle, can be imported by another. The exporter specifies a version number for a package. The importer can specify a range of versions it is compatible with. At run-time the framework will resolve such dependencies. All this allows you to keep implementations private, only exposing API&#x2019;s.
  • On top of that, the life-cycle layer determines the life-cycle of individual bundles. Basically, bundles can be installed, started, stopped and uninstalled. Furthermore, an installed bundle can be updated anytime. Finally, you can uninstall a bundle if you don&#x2019;t need it anymore. The &#x201C;starting&#x201D; and &#x201C;stopping&#x201D; states have hooks for you as the bundle developer to actually make your bundle do something. By implementing the BundleActivator interface, the framework will invoke your start() and stop() methods. You will also get a BundleContext which is basically a reference to the API to talk to the container.
  • Finally, the service layer contains a registry where services are published. Each bundle can register any number of services in the service registry. A service is registered using the fully qualified name of its interface. Furthermore, you can add any number of properties to this service. Both the name and properties can then be used again by others that query the registry. A fast and powerful LDAP based query language is used for that.
  • The compendium, as mentioned before, contains an extensive list of standard service descriptions. Services like HTTP, logging, preferences and pluggable XML parsers are things that a lot of applications share and by sticking to these services, you get excellent substitutability, where you can develop with light weight implementations and then at runtime switch to more heavy weight ones.
  • at the very least, your developers are happy now: they have components, and the complexity of the codebase is manageable. <br /> Your support personnel isn&#x2019;t <br /> <br /> http://www.flickr.com/photos/mpsfender182/2681841205/
  • at the very least, your developers are happy now: they have components, and the complexity of the codebase is manageable. <br /> Your support personnel isn&#x2019;t <br /> <br /> http://www.flickr.com/photos/mpsfender182/2681841205/
  • Goals of Dynamic Deployment
  • What exactly is deployment?
  • What exactly is deployment?
  • History is important
  • History is important
  • History is important
  • The topology. <br /> Disclosure: I am an Apache ACE committer, <br /> Apache ACE is an open source project that aims to build a system with the characteristics described before.
  • Leaving the topology for a while, let&#x2019;s look at the logical aspects.
  • First: DEPENDENCY MANAGEMENT <br /> Note that the repository has versions too...
  • FEEDBACK
  • management agent stores all life cycle related events in an audit log <br /> this log gets synchronized back to the server <br /> There is a part I did not yet talk about: the management agent.
  • DEPLOYMENT Leverages standard OSGi features; &#x2018;management agent&#x2019; is mentioned in the spec, but not as a component. <br /> - module / lifecycle layer <br /> - PackageAdmin <br /> - StartLevels <br /> - ConditionPermissionAdmin
  • Management agent is a set of activities, which can be deployed as a (number of) component(s), but also added into the framework.
  • We borrowed a little something from the OSGi specification, known as the Deployment admin <br /> <br /> Now, how does that all fit together?
  • Way too dangerous; I prepared some screencasts. <br /> <br /> http://dl.dropbox.com/u/2438787/www/2009-10/1-Community%20edition.mov <br /> http://dl.dropbox.com/u/2438787/www/2009-10/2-Pro%20edition.mov <br /> http://dl.dropbox.com/u/2438787/www/2009-10/3-Specials.mov <br /> http://dl.dropbox.com/u/2438787/www/2009-10/4-Customer%20support.mov

Dynamic Deployment   Oredev 2009 Dynamic Deployment Oredev 2009 Presentation Transcript

  • dynamic deployment with OSGi Angelo van der Sijpt angelo.vandersijpt@luminis.nl
  • how about modules?
  • Partitioning software • modular, componentized, ... • minimize dependencies • consider rate of change • minimize complexity • maximize architected flexibility • testability • reuse
  • Reuse: copy/paste • no clearly defined interface • maintenance nightmare
  • Reuse: Object Oriented • objects tend to work badly when taken out of context
  • Reuse: Components • components are black boxes • clear “interfaces” with their
  • >)=9)%)% A(..0=9 28"=4? C- (,)= 203) =)8 #0=302 @07(;' &<0,) -.,(%')% *+,(%')% 4%0,< 2:;0%) #"%#6) '%"0=46) 234 /0#)1(($ !"#$% A(=54;%0B(= @(4 &'(%) *3)=' #(=54 6(44)% 56)272'). 8)1903 )3)='
  • >)=9)%)% A(..0=9 %)=9)%)% #(..0=9 28"=4? C- (,)= 203) =)8 #0=302 28"=4D#0=302 28"=4D;" 28"=4D#.9D(,)= 28"=4D#.9D203) 28"=4D#.9D=)8 28"=4D#(='%(62 @07(;' &<0,) -.,(%')% *+,(%')% 607(;' 2<0,) ".,(%')% )+,(%')% 4%0,< 2:;0%) #"%#6) '%"0=46) 234 /0#)1(($ !"#$% 607(;'D4%0,< 2<0,)D2:;0%) 2<0,)D#"%#6) 2<0,)D'%"0=46) ".,D234 )+,DE(($ ".,D!"#$% A(=54;%0B(= @(4 &'(%) *3)=' (24"D#0 (24"D6(4 2'(%) (24"D)3)=' #(=54 6(44)% 56)272'). 8)1903 )3)=' /)6"+D#0 /)6"+D6(4 2'(%)D/2 2'(%)D8)1903 /)6"+D)3)='
  • %)=9)%)% #(..0=9 >)=9)%)% A(..0=9 %)=9)%)% #(..0=9 ;" #(..0=92 28"=4? C- (,)= 203) =)8 #0=302 28"=4D#0=302 28"=4D;" 28"=4D#.9D(,)= 28"=4D#.9D203) 28"=4D#.9D=)8 28"=4D#(='%(62 9%08"=4 &<0,) 0,"D"( @07(;' -.,(%')% *+,(%')% 607(;' 2<0,) ".,(%')% )+,(%')% 4%0,< 2<0,)2 234 )+,(%')%2 4%0,< 2:;0%) #"%#6) '%"0=46) 234 /0#)1(($ !"#$% 607(;'D4%0,< 2<0,)D2:;0%) 2<0,)D#"%#6) 2<0,)D'%"0=46) ".,D234 )+,DE(($ ".,D!"#$% 0,"D(24" A(=54;%0B(= @(4 &'(%) *3)=' (24"D#0 (24"D6(4 2'(%) (24"D)3)=' #(=5409."= 6(4 56)2'(%) 8)1903 )3)=' #(=54 6(44)% 56)272'). 8)1903 )3)=' /)6"+D#0 /)6"+D6(4 2'(%)D/2 2'(%)D8)1903 /)6"+D)3)='
  • OSGi technology is the dynamic module system for Java™ OSGi technology is Universal Middleware. OSGi technology provides a service-oriented, component- based environment for developers and offers standardized ways to manage the software lifecycle. These capabilities greatly increase the value of a wide range of computers and devices that use the Java™ platform.
  • !"#$%"&'($)&%*+,-./'0 !"#$%"&'($)&%*+,-./'0 1/'&%"2&)$.$),-$/3 "&'($)&%1/02&34$50 45&%!"#$%6++$,3)& 67&%!"#$%8++$,3)& 7&+&,8&%9:%;&'8$/3%9<= 9&+&,:&%;<%=&':$/3%;>? 62'$+%>??@ 82'$+%@AAB Digitally signed by Digitally OSGi OSGi Alliance DN: cn=OSGi Alliance, c=US Date: signed by 2007.02.22 OSGi OSGi Alliance DN: cn=OSGi Alliance, c=US Signatu Alliance 14:44:10 + 01'00' re Not Alliance Date: Verified 2007.02.22 Signatur 14:45:47 + e Not 01'00' Verified
  • L3 - Provides a publish/find/ SERVICE MODEL bind service model to decouple bundles L2 - Manages the life cycle of a bundle in a framework LIFECYCLE without requiring the vm to be restarted L1 - Creates the concept of a module (aka. bundle) that use MODULE classes from each other in a controlled way according to system and bundle constraints L0 - Execution OSGi Minimum Execution Environment Environment CDC/Foundation JavaSE
  • Module Layer Module Bundle Bundle Bundle Bundle imports exports imports exports exports exports • unit of deployment org.apache.utils 1.0 org.apache.db 1.4 is the bundle i.e., a JAR org.apache.log 2.3 org.apache.utils 1.1 • share only your “interface” packages • automatic wiring based on version ranges Module
  • Life-cycle Layer Life-cycle install installed start start starting resolved active • Managed life cycle end uninstall uninstalled stopping stop • States for each bundle; • Allows updates of existing bundles. • Dynamically install, start, update, and uninstall Life-cycle Module
  • Service Layer • OSGi framework Service promotes service Log Database Prefs publish publish use oriented interaction publish use use Bundle Bundle Bundle Bundle pattern among bundles Service Registry publish find Service Life-cycle Service Service Provider Requeste Module interact
  • OSGi compendium User Admin Initial Provisioning Wire Admin XML Log Device Access Measurement and Parser State UPnP™ Preferences Device Configuration Admin Position Metatype Event Service Tracker Admin HTTP IO Connector Execution Environment Spec Declarative Services
  • Now we have components, hurrah! Right?
  • “What version do you have?” “Can you look in the ‘about’ box?” Now we install 037B.17.zip “Did you have components, we sent you?” hurrah! Right? What is the version of the product, anyway?
  • how about configuration
  • Dynamic Deployment • who uses what? • what’s the history of a system? • what’s the impact of this bug? • integrate into build/test/QA cycle • extensions, like (re)install and license management
  • !"#$"%&%'() !"#$%&'( !"#$"%&%'(* !"#$%&') !"#$"%&%'(! !"#$%&'*
  • !"#$"%&%'() !"#$%&'( !"#$"%&%'(* !"#$%&'"() !"#$%&') !"#$"%&%'(! !"#$%&'*
  • now !"#$"%&%'() !"#$%&'( !"#$"%&%'(* !"#$%&') !"#$"%&%'(! !"#$%&'*
  • last year !"#$"%&%'() +,-.&'() last month !"#$"%&%'() !"#$"%&%'(* +,-.&'() last week !"#$"%&%'() !"#$"%&%'(* !"#$%&'( +,-.&'(! +,-.&'(* now !"#$"%&%'() !"#$%&'( !"#$"%&%'(* !"#$%&') +,-.&'(! !"#$"%&%'(* !"#$"%&%'(! !"#$%&') !"#$%&'* !"#$"%&%'(! !"#$%&'*
  • !"#$%! 0"&"$%0%&!. "$%&! !"#$%! /2,%&! *#(+,-,(&,&$. 0"&"$%0%&!. &%!'(#) -%#+%# "$%&! !"#$%! 0"&"$%0%&!. "$%&! /(0*(&%&!. #%*(-,!(#1
  • !"#"$!"$%&' !"#,-&("$+ ()$)*"("$+ .""!/)%0
  • ',*-&'( )&*(+"%( !"#$"%&%'( 2 1"#$"%&%'/0 !"#$"%&%'() 3 1"#$"%&%'/0 !"#$"%&%'() !"#$"%&%'(! .,*-&'/0 4 1"#$"%&%'/0 !"#$"%&%'(! !"#$"%&%'(* 5 1"#$"%&%'/1 !"#$"%&%'(* 2 1"#$"%&%'/6 !"#$"%&%'(* .,*-&'/6 3 1"#$"%&%'/0 !"#$"%&%'() !"#$"%&%'(*
  • !"#$%! 0"&"$%0%&!. "$%&! !"#$%! /2,%&! *#(+,-,(&,&$. 0"&"$%0%&!. &%!'(#) -%#+%# "$%&! !"#$%! 0"&"$%0%&!. "$%&! /(0*(&%&!. #%*(-,!(#1 • server only stores metadata, so no IP in these repositories • allows integration with different repositories • OBR, Maven (anything with a URL)
  • !"#$%! *#(+,-,(&,&$. /"&"$%/%&!. &%!'(#) -%#+%# "$%&! 012,!. 012,!. 3($ 3($ !=#".%@A*?B*-%45(%23-'+*,C%151*%4521- $"#$E%;21-<*%$"%,+533*- !:#". !D#".!"#$"%&'()*+%,+'(+*- $"#$9 !"#$"%&'()*+%,+'(+*- $E#".!"#$.%/+'(01)%23-'+*%4(56%7*(,851%9%+5%: $"#.9 !"#$.%/+'(01)%23-'+*%4(56%7*(,851%9%+5%: $!#".!"#$.%;21-<*%"=%23-'+*- E$#$$ !"#$.%;21-<*%"=%23-'+*- !"#$9%>3-'+*%+5%7*(,851%:%,2??**-*- E9#$$ !"#$9%>3-'+*%+5%7*(,851%:%,2??**-*- !.#$9%&'()*+%,+533*- !.#$9%&'()*+%,+533*-
  • Management Agent • manages life cycle of bundles • controls package sharing policies • controls starting/stopping !"#$%"&'($)&%*+,-./'0 1/'&%"2&)$.$),-$/3 45&%!"#$%6++$,3)& order 7&+&,8&%9:%;&'8$/3%9<= >?3&%=@@A • implements a security
  • !"#"$%!%#&'"$%#& *'.#"/0#, '('.# "#10)-2#$34 (/"!340)6 3(*5 !"#$%&'(%)$ "!*')+#,-
  • Management Agent !"#"$%!%#&'"$%#& *'.#"/0#, '('.# "#10)-2#$34 (/"!340)6 3(*5 !"#$%&'(%)$ "!*')+#,- • identification, uniquely identifies a target • discovery, provides mechanism to find server • scheduler, periodically triggers updates
  • Deployment Admin • versioned set of artifacts • transactional install/update • fix packages provide deltas • signing makes them secure • extensible through resource processors !"#$%! 0"&"$%0%&!. "$%&! !"#$%! /2,%&! *#(+,-,(&,&$. 0"&"$%0%&!. &%!'(#) -%#+%# "$%&! !"#$%! 0"&"$%0%&!. "$%&! /(0*(&%&!. #%*(-,!(#1
  • demo
  • Angelo van der Sijpt software engineer at Luminis / Apache ACE committer angelo.vandersijpt@luminis.nl @_angelos
  • Further reading • www.luminis-technologies.com • cwiki.apache.org/ACE/ • cwiki.apache.org/FELIX/ • Or ask me: angelo.vandersijpt@luminis.nl