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 - OSGi Design Patterns
Date Fri, 02 Jul 2010 18:50: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+-+OSGi+Design+Patterns">Apache
Felix Dependency Manager - OSGi Design Patterns</a></h2>
    <h4>Page <b>edited</b> by             <a href="https://cwiki.apache.org/confluence/display/~marrs">Marcel
Offermans</a>
    </h4>
        <br/>
                         <h4>Changes (1)</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" >h4. Motivation <br> <br></td></tr>
            <tr><td class="diff-changed-lines" >Resource adapters are similar
to normal adapters, but instead of requiring a service, they require a resource and provide
a service on top of it. Resources are an abstraction that is introduced by the dependency
<span class="diff-changed-words">manager<span class="diff-added-chars"style="background-color:
#dfd;">, represented as a URL</span>.</span> They can be implemented to serve
resources embedded in bundles, somewhere on a file system or in a content repository or database.
<br></td></tr>
            <tr><td class="diff-unchanged" > <br>h4. Structure <br></td></tr>
            <tr><td class="diff-snipped" >...<br></td></tr>
        </table>
</div>                            <h4>Full Content</h4>
                    <div class="notificationGreySide">
        <h2><a name="ApacheFelixDependencyManager-OSGiDesignPatterns-OSGiDesignPatterns"></a>OSGi
Design Patterns</h2>

<p>This section lists a couple of design patterns as they can be applied in an OSGi
context.</p>

<h3><a name="ApacheFelixDependencyManager-OSGiDesignPatterns-%28Singleton%29Service"></a>(Singleton)
Service</h3>

<p>Provides a service as long as its dependencies are resolved.</p>

<h4><a name="ApacheFelixDependencyManager-OSGiDesignPatterns-Motivation"></a>Motivation</h4>

<p>In a dynamic framework, services can come and go. Components that publish a service
are often themselves dependent on other services to perform their task. In such cases, they
have a dependency on those services and it makes sense to only publish their own services
when these dependencies are available. Being able to declare such dependencies in code ensures
consistent life cycle behavior.</p>

<h4><a name="ApacheFelixDependencyManager-OSGiDesignPatterns-Structure"></a>Structure</h4>


<table width="100%">
    <tr><td align="center"> 
        <table>     
            <caption align="bottom">
                         </caption>

            <tr><td>
                            <img style="border: none" usemap="#GLIFFY_MAP_9374247_singleton"
src="/confluence/plugins/servlet/gliffyapi/clientdiagramjpeg?cb=675291439&pk=pub&name=singleton&ceoid=9374247&key=FELIX&size=L&version=0"
alt="A&#32;Gliffy&#32;Diagram&#32;named&#58;&#32;singleton" />
                       </td></tr>
        </table> 
</td></tr>
</table>
<map name='GLIFFY_MAP_9374247_singleton'></map>

<h3><a name="ApacheFelixDependencyManager-OSGiDesignPatterns-AspectService"></a>Aspect
Service</h3>

<p>Provides an aspect on top of a specific type of service.</p>

<h4><a name="ApacheFelixDependencyManager-OSGiDesignPatterns-Motivation"></a>Motivation</h4>

<p>In aspect oriented programming, supporting functions are isolated from the main application's
business logic. This increases modularity at the source level by allowing the separation of
cross-cutting concerns. In OSGi we want to extend this modularity to the runtime, therefore
we implement aspects to work on certain services, where the aspect itself publishes that same
service but (usually) with a higher priority. This allows you to dynamically add and remove
aspects.</p>

<h4><a name="ApacheFelixDependencyManager-OSGiDesignPatterns-Structure"></a>Structure</h4>


<table width="100%">
    <tr><td align="center"> 
        <table>     
            <caption align="bottom">
                         </caption>

            <tr><td>
                            <img style="border: none" usemap="#GLIFFY_MAP_9374247_aspect"
src="/confluence/plugins/servlet/gliffyapi/clientdiagramjpeg?cb=220173278&pk=pub&name=aspect&ceoid=9374247&key=FELIX&size=L&version=0"
alt="A&#32;Gliffy&#32;Diagram&#32;named&#58;&#32;aspect" />
                       </td></tr>
        </table> 
</td></tr>
</table>
<map name='GLIFFY_MAP_9374247_aspect'></map>

<h3><a name="ApacheFelixDependencyManager-OSGiDesignPatterns-AdapterService"></a>Adapter
Service</h3>

<p>Provides an adapter for a specific type of service.</p>

<h4><a name="ApacheFelixDependencyManager-OSGiDesignPatterns-Motivation"></a>Motivation</h4>

<p>Like with aspects, sometimes you want to create adapters for certain services, which
add certain behavior that results in the publication of (in this case) a different service.
Adapters can dynamically be added and removed and allow you to keep your basic services implementations
clean and simple, adding extra features on top of them in a modular way. </p>

<h4><a name="ApacheFelixDependencyManager-OSGiDesignPatterns-Structure"></a>Structure</h4>


<table width="100%">
    <tr><td align="center"> 
        <table>     
            <caption align="bottom">
                         </caption>

            <tr><td>
                            <img style="border: none" usemap="#GLIFFY_MAP_9374247_adapter"
src="/confluence/plugins/servlet/gliffyapi/clientdiagramjpeg?cb=-2097855777&pk=pub&name=adapter&ceoid=9374247&key=FELIX&size=L&version=0"
alt="A&#32;Gliffy&#32;Diagram&#32;named&#58;&#32;adapter" />
                       </td></tr>
        </table> 
</td></tr>
</table>
<map name='GLIFFY_MAP_9374247_adapter'></map>

<h3><a name="ApacheFelixDependencyManager-OSGiDesignPatterns-ResourceAdapterService"></a>Resource
Adapter Service</h3>

<p>Provides an adapter for a specific type of resource.</p>

<h4><a name="ApacheFelixDependencyManager-OSGiDesignPatterns-Motivation"></a>Motivation</h4>

<p>Resource adapters are similar to normal adapters, but instead of requiring a service,
they require a resource and provide a service on top of it. Resources are an abstraction that
is introduced by the dependency manager, represented as a URL. They can be implemented to
serve resources embedded in bundles, somewhere on a file system or in a content repository
or database.</p>

<h4><a name="ApacheFelixDependencyManager-OSGiDesignPatterns-Structure"></a>Structure</h4>


<table width="100%">
    <tr><td align="center"> 
        <table>     
            <caption align="bottom">
                         </caption>

            <tr><td>
                            <img style="border: none" usemap="#GLIFFY_MAP_9374247_resource-adapter"
src="/confluence/plugins/servlet/gliffyapi/clientdiagramjpeg?cb=392411947&pk=pub&name=resource-adapter&ceoid=9374247&key=FELIX&size=L&version=0"
alt="A&#32;Gliffy&#32;Diagram&#32;named&#58;&#32;resource&#45;adapter"
/>
                       </td></tr>
        </table> 
</td></tr>
</table>
<map name='GLIFFY_MAP_9374247_resource-adapter'></map>

<h3><a name="ApacheFelixDependencyManager-OSGiDesignPatterns-TemporalDependency"></a>Temporal
Dependency</h3>

<p>Provides a proxy that hides the service dynamics of a dependency, even if it disappears
for a short time.</p>

<h4><a name="ApacheFelixDependencyManager-OSGiDesignPatterns-Motivation"></a>Motivation</h4>

<p>As a service consumer, you sometimes do not want to deal with the dynamics of services
and the fact that they tend to go away for short periods of time whilst their hosting bundle
gets updated. A temporal dependency provides you with a proxy that hides these dynamics and
blocks your calls if you try to invoke a method on a service that is currently "updating".
The maximum time to wait is configurable and you will get an exception if no new service becomes
available before that time.</p>

<h4><a name="ApacheFelixDependencyManager-OSGiDesignPatterns-Structure"></a>Structure</h4>

<h3><a name="ApacheFelixDependencyManager-OSGiDesignPatterns-NullObject"></a>Null
Object</h3>

<p>Provides an implementation of an object that does nothing and can be used in the
absence of the real object.</p>

<h4><a name="ApacheFelixDependencyManager-OSGiDesignPatterns-Motivation"></a>Motivation</h4>

<p>When a component depends on a service, but the dependency is optional, it means that
it will use this service when available, but it can still operate if it's not. Constantly
checking in your code if a service is actually available tends to lead to code with a lot
of "<tt>if (service != null) service.invoke();</tt>" constructions which do not
help with code readability. Instead, the dependency manager offers you a mechanism where it
will inject null objects for services that are currently not available so you can simply invoke
methods on them that "do nothing".</p>

<h4><a name="ApacheFelixDependencyManager-OSGiDesignPatterns-Structure"></a>Structure</h4>

<h3><a name="ApacheFelixDependencyManager-OSGiDesignPatterns-Whiteboard"></a>Whiteboard</h3>

<p>Handles listeners by leveraging the OSGi service registry to publish and look them
up.</p>

<h4><a name="ApacheFelixDependencyManager-OSGiDesignPatterns-Motivation"></a>Motivation</h4>

<p>The traditional model for dealing with listeners in Java needlessly complicates things
in an OSGi context. Instead of having listeners registering themselves with the component
that will invoke them on any change, a listener simply registers itself in the service registry
and the component will do a lookup of all relevant services. This is explained in more detail
on the OSGi.org wiki in the <a href="http://www.osgi.org/wiki/uploads/Links/whiteboard.pdf"
class="external-link" rel="nofollow">"Listeners considered harmful: the 'whiteboard' pattern"</a>
article.</p>

<h4><a name="ApacheFelixDependencyManager-OSGiDesignPatterns-Structure"></a>Structure</h4>

    </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+-+OSGi+Design+Patterns">View
Online</a>
        |
        <a href="https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=9374247&revisedVersion=13&originalVersion=12">View
Changes</a>
                |
        <a href="https://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+Dependency+Manager+-+OSGi+Design+Patterns?showComments=true&amp;showCommentArea=true#addcomment">Add
Comment</a>
            </div>
</div>
</div>
</div>
</div>
</body>
</html>

Mime
View raw message