felix-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From conflue...@apache.org
Subject [CONF] Apache Felix > Composite Bundles
Date Tue, 29 Jun 2010 18:25: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/Composite+Bundles">Composite
Bundles</a></h2>
    <h4>Page <b>edited</b> by             <a href="https://cwiki.apache.org/confluence/display/~heavy@ungoverned.org">Richard
S. Hall</a>
    </h4>
        <br/>
                         <h4>Changes (9)</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" >* Groups of bundles needing lifecycle
management as a whole can be modeled as a composite bundle. <br> <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">This
list is not intended to be exhaustive. <br> <br></td></tr>
            <tr><td class="diff-unchanged" >h1. Terminology <br> <br>The
following terms are used in this document: <br> <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">*
Composite bundle - a bundle whose contents is actually a set of bundles that appear to be
running inside of another framework instance. <br>* Composite parent framework - the
framework in which a composite bundle is installed. <br>* Composite framework - the
framework running inside the composite bundle (this term may not be necessary). <br></td></tr>
            <tr><td class="diff-unchanged" > <br>h1. Technical approach
<br> <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">The
overall technical approach is to build a layer on top of the virtual bundle concept (proposed
separately) to manage composite as a layer above the framework. The specific approach is to
forgo an API-based approach to support a simple, declarative approach. Therefore, the technical
approach is actually divided into two halves: composite declaration and composite lifecycle
management. <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">h2.
Proposed API <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">NOTE:
The goal is not to completely rule out any API, but to keep things simple until some real-world
experience is gained at which point API could potentially be introduced. <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">h2.
Composite declaration <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">h2.
Composite Lifecycle <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">A
composite bundle is declared using a set of manifest-like headers, which is familiar to bundle
developers and fits well with the virtual bundle proposal, where virtual bundles are installed
with a given set of headers. Many existing headers are reused to declare a composite bundle,
but not all are applicable (e.g., Bundle-ClassPath, Bundle-Activator, Bundle-NativeCode, Bundle-ActivationPolicy).
Other than explicitly disallowed headers, all other headers maintain their normal meaning.
For example, code dependencies are handled by: <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">*
Import-Package - the packages imported by the composite bundle. <br>* Export-Package
- the packages exported by the composite bundle. <br>* Require-Bundle - the bundles
required by the composite bundle. <br> <br>For service dependencies, this proposal
resurrects the following headers: <br> <br>* Import-Service - the services imported
by the composite bundle (exact syntax is yet to be defined, but a list of filters is a reasonable
starting point). <br>* Export-Service - the services exported by the composite bundle
(exact syntax is yet to be defined, but a list of filters is a reasonable starting point).
<br> <br>A new header is introduced to declare the composite&#39;s constituent
bundles: <br> <br>* Include-Bundle - A comma-separate list of bundle URLs. <br>
<br>To simplify matching a composite&#39;s exported packages to contained bundles,
this proposal introduces a new {{from}} directive for Export-Package, which is used to specify
the symbolic name of the providing bundle. Consider the following composite declaration: <br>
<br>{noformat} <br>Bundle-ManifestVersion: 2 <br>Bundle-Name: Full Paint
Program <br>Bundle-SymbolicName: composite.example.full <br>Include-Bundle: \
<br> file:/Users/rickhall/Projects/book-trunk/code/chapter04/paint-example/bundles/shape-4.0.jar,
\ <br> file:/Users/rickhall/Projects/book-trunk/code/chapter04/paint-example/bundles/paint-4.0.jar,
\ <br> file:/Users/rickhall/Projects/book-trunk/code/chapter04/paint-example/bundles/circle-4.0.jar,
\ <br> file:/Users/rickhall/Projects/book-trunk/code/chapter04/paint-example/bundles/square-4.0.jar,
\ <br> file:/Users/rickhall/Projects/book-trunk/code/chapter04/paint-example/bundles/triangle-4.0.jar
<br>Export-Package: org.foo.shape; from:=org.foo.shape; version=&quot;4.0&quot;
<br>Import-Package: org.osgi.service.log; version=1.0.0 <br>Import-Service: org.foo.shape.SimpleShape
<br>{noformat} <br> <br>This composite contains five bundles and exports
{{org.foo.shape}} from the bundle with the symbolic name {{org.foo.shape}}. Further, it also
imports the log service package and any services implementing the {{org.foo.shape.SimpleShape}}
interface from the package it exports. <br> <br>h2. Composite lifecycle management
<br> <br>h3. Composite manager <br> <br></td></tr>
            <tr><td class="diff-unchanged" >h1. Open issues <br> <br></td></tr>
            <tr><td class="diff-snipped" >...<br></td></tr>
        </table>
</div>                            <h4>Full Content</h4>
                    <div class="notificationGreySide">
        <h1><a name="CompositeBundles-Overview"></a>Overview</h1>

<p>The OSGi framework supports deploying bundles into a flat and basically globally
bundle space. The idea behind this approach can be summarized as, "the deployed set of bundles
is your application configuration." This approach has performed well over the years; however,
as OSGi technology is used in more and more complicated scenarios, this approach is not always
sufficient. For example, when trying to run multiple applications in a single framework instance
or when applications become so large that sets of bundles start mapping onto logical subsystems.
In these types of situations, it is possible for the configurations of different applications
or subsystems to interfere with each other.</p>

<p>To address some of these issues, this proposal introduces a composite bundle concept
built on top of virtual bundles. The main goal of this proposal is to provide an isolation
mechanism for groups of bundles, while still allowing collaboration among those groups and
to manage everything as a layer above the framework.</p>

<h1><a name="CompositeBundles-Usecases"></a>Use cases</h1>

<p>Some potential use cases for composite bundles:</p>

<ul>
	<li>Large application subsystems can be modeled as a composite bundle.</li>
	<li>Different applications running in the same framework instance can be isolated from
each other inside of composite bundles.</li>
	<li>Web servers could model EARs and composite bundles.</li>
	<li>Groups of bundles needing lifecycle management as a whole can be modeled as a composite
bundle.</li>
</ul>


<p>This list is not intended to be exhaustive.</p>

<h1><a name="CompositeBundles-Terminology"></a>Terminology</h1>

<p>The following terms are used in this document:</p>

<ul>
	<li>Composite bundle - a bundle whose contents is actually a set of bundles that appear
to be running inside of another framework instance.</li>
	<li>Composite parent framework - the framework in which a composite bundle is installed.</li>
	<li>Composite framework - the framework running inside the composite bundle (this term
may not be necessary).</li>
</ul>


<h1><a name="CompositeBundles-Technicalapproach"></a>Technical approach</h1>

<p>The overall technical approach is to build a layer on top of the virtual bundle concept
(proposed separately) to manage composite as a layer above the framework. The specific approach
is to forgo an API-based approach to support a simple, declarative approach. Therefore, the
technical approach is actually divided into two halves: composite declaration and composite
lifecycle management.</p>

<p>NOTE: The goal is not to completely rule out any API, but to keep things simple until
some real-world experience is gained at which point API could potentially be introduced.</p>

<h2><a name="CompositeBundles-Compositedeclaration"></a>Composite declaration</h2>

<p>A composite bundle is declared using a set of manifest-like headers, which is familiar
to bundle developers and fits well with the virtual bundle proposal, where virtual bundles
are installed with a given set of headers. Many existing headers are reused to declare a composite
bundle, but not all are applicable (e.g., Bundle-ClassPath, Bundle-Activator, Bundle-NativeCode,
Bundle-ActivationPolicy). Other than explicitly disallowed headers, all other headers maintain
their normal meaning. For example, code dependencies are handled by:</p>

<ul>
	<li>Import-Package - the packages imported by the composite bundle.</li>
	<li>Export-Package - the packages exported by the composite bundle.</li>
	<li>Require-Bundle - the bundles required by the composite bundle.</li>
</ul>


<p>For service dependencies, this proposal resurrects the following headers:</p>

<ul>
	<li>Import-Service - the services imported by the composite bundle (exact syntax is
yet to be defined, but a list of filters is a reasonable starting point).</li>
	<li>Export-Service - the services exported by the composite bundle (exact syntax is
yet to be defined, but a list of filters is a reasonable starting point).</li>
</ul>


<p>A new header is introduced to declare the composite's constituent bundles:</p>

<ul>
	<li>Include-Bundle - A comma-separate list of bundle URLs.</li>
</ul>


<p>To simplify matching a composite's exported packages to contained bundles, this proposal
introduces a new <tt>from</tt> directive for Export-Package, which is used to
specify the symbolic name of the providing bundle. Consider the following composite declaration:</p>

<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent
panelContent">
<pre>Bundle-ManifestVersion: 2
Bundle-Name: Full Paint Program
Bundle-SymbolicName: composite.example.full
Include-Bundle: \
 file:/Users/rickhall/Projects/book-trunk/code/chapter04/paint-example/bundles/shape-4.0.jar,
\
 file:/Users/rickhall/Projects/book-trunk/code/chapter04/paint-example/bundles/paint-4.0.jar,
\
 file:/Users/rickhall/Projects/book-trunk/code/chapter04/paint-example/bundles/circle-4.0.jar,
\
 file:/Users/rickhall/Projects/book-trunk/code/chapter04/paint-example/bundles/square-4.0.jar,
\
 file:/Users/rickhall/Projects/book-trunk/code/chapter04/paint-example/bundles/triangle-4.0.jar
Export-Package: org.foo.shape; from:=org.foo.shape; version="4.0"
Import-Package: org.osgi.service.log; version=1.0.0
Import-Service: org.foo.shape.SimpleShape
</pre>
</div></div>

<p>This composite contains five bundles and exports <tt>org.foo.shape</tt>
from the bundle with the symbolic name <tt>org.foo.shape</tt>. Further, it also
imports the log service package and any services implementing the <tt>org.foo.shape.SimpleShape</tt>
interface from the package it exports.</p>

<h2><a name="CompositeBundles-Compositelifecyclemanagement"></a>Composite
lifecycle management</h2>

<h3><a name="CompositeBundles-Compositemanager"></a>Composite manager</h3>

<h1><a name="CompositeBundles-Openissues"></a>Open issues</h1>

<h1><a name="CompositeBundles-Consideredalternatives"></a>Considered alternatives</h1>

<p>TBD</p>
    </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/Composite+Bundles">View
Online</a>
        |
        <a href="https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=23331295&revisedVersion=3&originalVersion=2">View
Changes</a>
                |
        <a href="https://cwiki.apache.org/confluence/display/FELIX/Composite+Bundles?showComments=true&amp;showCommentArea=true#addcomment">Add
Comment</a>
            </div>
</div>
</div>
</div>
</div>
</body>
</html>

Mime
View raw message