felix-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From conflue...@apache.org
Subject [CONF] Apache Felix > Apache Felix Dependency Manager - Background
Date Wed, 08 Sep 2010 20:44:00 GMT
<html>
<head>
    <base href="https://cwiki.apache.org/confluence">
            <link rel="stylesheet" href="/confluence/s/1810/9/1/_/styles/combined.css?spaceKey=FELIX&amp;forWysiwyg=true"
type="text/css">
    </head>
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
    <h2><a href="https://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+Dependency+Manager+-+Background">Apache
Felix Dependency Manager - Background</a></h2>
    <h4>Page <b>edited</b> by             <a href="https://cwiki.apache.org/confluence/display/~marrs">Marcel
Offermans</a>
    </h4>
        <br/>
                         <h4>Changes (3)</h4>
                                 
    
<div id="page-diffs">
            <table class="diff" cellpadding="0" cellspacing="0">
            <tr><td class="diff-snipped" >...<br></td></tr>
            <tr><td class="diff-unchanged" > <br>In an OSGi framework, services
are deployed using bundles and these bundles feature two types of dependencies:  <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">#
Package dependencies. A bundle can export a package which others import. These dependencies,
although dynamic, are relatively easy to handle. <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">#
Package dependencies. A bundle can export a package which others import. These dependencies,
although dynamic, are relatively easy to handle and the whole resolution process is handled
by the OSGi framework for you. <br></td></tr>
            <tr><td class="diff-unchanged" ># Service dependencies. Services,
implemented by components inside of bundles, can have their own life cycle within that of
their containing bundle and therefore can be registered and unregistered at any time. Other
components often depend on these services and need to deal with changes in their availability.
 <br> <br></td></tr>
            <tr><td class="diff-snipped" >...<br></td></tr>
            <tr><td class="diff-unchanged" > <br>The goals that drove the
design of the dependency manager are: <br></td></tr>
            <tr><td class="diff-changed-lines" >* Provide a clean separation between
a <span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">service</span>
<span class="diff-added-words"style="background-color: #dfd;">component</span>
implementation and the &quot;glue&quot; that binds it to the OSGi framework. The <span
class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">service</span>
<span class="diff-added-words"style="background-color: #dfd;">component</span>
implementation should not have to contain any OSGi specific code. In other words, it should
be a <span class="diff-changed-words">POJO<span class="diff-added-chars"style="background-color:
#dfd;"> (Plain Old Java Object)</span>.</span> <br></td></tr>
            <tr><td class="diff-unchanged" >* Minimize the amount of code that
needs to be written. The specification and management of dependencies should be automated
as much as possible, whilst still providing enough flexibility to customize the system. <br></td></tr>
            <tr><td class="diff-unchanged" >* Be extensible. Even though the core
bundle provides a lot of different dependencies already, you should be able to add your own
types of dependencies easily. <br>* Easy to monitor and debug. Being a dynamic system,
it&#39;s important to be able to see what the state of all components and dependencies
are at any point in time. <br></td></tr>
            <tr><td class="diff-snipped" >...<br></td></tr>
        </table>
</div>                            <h4>Full Content</h4>
                    <div class="notificationGreySide">
        <h2><a name="ApacheFelixDependencyManager-Background-Background"></a>Background</h2>

<p>In an OSGi framework, services are deployed using bundles and these bundles feature
two types of dependencies: </p>
<ol>
	<li>Package dependencies. A bundle can export a package which others import. These
dependencies, although dynamic, are relatively easy to handle and the whole resolution process
is handled by the OSGi framework for you.</li>
	<li>Service dependencies. Services, implemented by components inside of bundles, can
have their own life cycle within that of their containing bundle and therefore can be registered
and unregistered at any time. Other components often depend on these services and need to
deal with changes in their availability.</li>
</ol>


<p>When you look at dependency management, there are two aspects you need to take into
account: </p>

<p>The first is managing software configurations. This means you need to manage the
dependencies from a configuration standpoint. What you are managing are bundles, since those
are the units of deployment. What you need to manage are the package and service dependencies
between bundles. Package dependencies are always visible by examining the bundle manifest
and when a bundle is installed the framework will try to resolve such dependencies before
that bundle can even be started. Service dependencies are only optionally described in the
manifest by a list of services a bundle might export as well as a list it might use (import).
The words 'optionally' and 'might' already indicate that these aren't things we can depend
on. Even worse, these keywords have by now been deprecated. Besides that, the framework doesn't
have to perform any checks on these attributes.</p>

<p>The second is managing service dependencies at runtime. As mentioned before, a service
oriented architecture is dynamic by design, so your implementation should be able to deal
with this. Bundles can start in any order and any service can go away or be replaced by a
different implementation at any point in time. OSGi itself offers basic assistance for tracking
services. You can track them yourself by registering as a service listener. A slightly more
advanced way is to create a service tracker, which you can subsequently query, or have it
notify you on changes. All of these are too low-level to be good building blocks for developers.</p>

<p>In real implementations, you are probably going to track multiple services. Using
service trackers in such a scenario has the tendency to result in dependency logic that is
entangled in the implementation instead of being expressed in a declarative way. Using a declarative
way to specify dependencies has clear advantages when it comes to monitoring and managing
them, a task that becomes more and more important in modern, federated, service oriented environments.</p>

<p>The Dependency Manager provides you with the right building blocks to declaratively
specify dependencies using a straightforward Java API that is easy to maintain and refactor.</p>

<h3><a name="ApacheFelixDependencyManager-Background-DesignGoals"></a>Design
Goals</h3>

<p>The goals that drove the design of the dependency manager are:</p>
<ul>
	<li>Provide a clean separation between a component implementation and the "glue" that
binds it to the OSGi framework. The component implementation should not have to contain any
OSGi specific code. In other words, it should be a POJO (Plain Old Java Object).</li>
	<li>Minimize the amount of code that needs to be written. The specification and management
of dependencies should be automated as much as possible, whilst still providing enough flexibility
to customize the system.</li>
	<li>Be extensible. Even though the core bundle provides a lot of different dependencies
already, you should be able to add your own types of dependencies easily.</li>
	<li>Easy to monitor and debug. Being a dynamic system, it's important to be able to
see what the state of all components and dependencies are at any point in time.</li>
	<li>Supporting powerful high level design patterns. When building real-world applications,
more complex patterns need to be used, such as aspects and adapters. Support for these needs
to be built into the core.</li>
</ul>

    </div>
        <div id="commentsSection" class="wiki-content pageSection">
        <div style="float: right;">
            <a href="https://cwiki.apache.org/confluence/users/viewnotifications.action"
class="grey">Change Notification Preferences</a>
        </div>
        <a href="https://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+Dependency+Manager+-+Background">View
Online</a>
        |
        <a href="https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=9374241&revisedVersion=2&originalVersion=1">View
Changes</a>
                |
        <a href="https://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+Dependency+Manager+-+Background?showComments=true&amp;showCommentArea=true#addcomment">Add
Comment</a>
            </div>
</div>
</div>
</div>
</div>
</body>
</html>

Mime
View raw message