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.
17. 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.
18. !"#$%"&'($)&%*+,-./'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
19. 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
20. 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
21. 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
22. 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
23. 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
25. “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?
27. 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
35. !"#$%!
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)
- Who am I? Angelo, Luminis, Apache ACE committer
- We will show a case that feels familiar to most of us, and use that as a showcase for using component technology and deployment.
- Will go into OSGi a little,
- I will show what dynamic deployment is all about
- And wrap up with a demo
You start out with the idea of a great drawing application
You start out with a monolithic application
http://www.flickr.com/photos/minegro/3097817447/
Growing software always has its peril.
Customers will start demanding &#x2018;specials&#x2019; you don&#x2019;t want everyone to have, since you might want to charge for them.
The specials start cluttering up your code, making it very hard to maintain
Growing software always has its peril.
Customers will start demanding &#x2018;specials&#x2019; you don&#x2019;t want everyone to have, since you might want to charge for them.
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.
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
http://www.flickr.com/photos/lance_mountain/142158155/sizes/o/
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
http://www.flickr.com/photos/lance_mountain/142158155/sizes/o/
http://www.answersingenesis.org/assets/images/articles/utp/chap8/userkafs-pyramid.jpg
You have a load of code, nicely communicating through interfaces.
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?
This really is the basis for subsequently designing both:
- your package view / development view
- your deployment view
Reference the 4+1 view here:
- to remain agile, you have to constantly manage your dependencies:
-> 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.
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.
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.
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.
Your support personnel isn&#x2019;t
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.
Your support personnel isn&#x2019;t
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.
Disclosure: I am an Apache ACE committer,
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
Note that the repository has versions too...
FEEDBACK
management agent stores all life cycle related events in an audit log
this log gets synchronized back to the server
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.
- module / lifecycle layer
- PackageAdmin
- StartLevels
- 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
Now, how does that all fit together?
Way too dangerous; I prepared some screencasts.
http://dl.dropbox.com/u/2438787/www/2009-10/1-Community%20edition.mov
http://dl.dropbox.com/u/2438787/www/2009-10/2-Pro%20edition.mov
http://dl.dropbox.com/u/2438787/www/2009-10/3-Specials.mov
http://dl.dropbox.com/u/2438787/www/2009-10/4-Customer%20support.mov