Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

- 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 &amp;#x2018;specials&amp;#x2019; you don&amp;#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 &amp;#x2018;specials&amp;#x2019; you don&amp;#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 &amp;#x2018;hook in&amp;#x2019; somewhere

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&amp;#x2019;t necessarily: we can rather easily change the packaging, or even have various forms together.

(from osgi.org) OSGi is based on the &amp;#x201C;home gateway&amp;#x201D; market, but later on profiled itself as &amp;#x2018;universal middleware&amp;#x2019;. Now, it just uses the term &amp;#x2018;dynamic module system&amp;#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&amp;#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&amp;#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&amp;#x2019;t need it anymore. The &amp;#x201C;starting&amp;#x201D; and &amp;#x201C;stopping&amp;#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&amp;#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&amp;#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&amp;#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.

10.
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.

12.
L3 - Provides a publish/ﬁnd/
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