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 20:01: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 (6)</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" >* {{Provide-Bundle}} - a comma-delimited
set of symbolic names specifying the constituent bundles provided by the composite bundle
to the parent framework. <br> <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">The
provided bundles will be manifested in the parent framework as virtual bundles themselves.
<br> <br></td></tr>
            <tr><td class="diff-unchanged" >These declarative headers define the
entire capabilities of a composite bundle. To summarize, these capabilities are: containing
bundles, importing/exporting packages, requiring/providing bundles, and importing/exporting
services. <br> <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">NOTE:
It is not clear if {{Import-Package}} should essentially support an &quot;export as&quot;
directive where the composite creator explicitly specifies how the imported package gets converted
to an export internally or if this should be automatically converted by the eventually injected
wire. If the latter, then this relates to the rich wiring section in the open issues.  <br>
<br></td></tr>
            <tr><td class="diff-unchanged" >h2. Composite lifecycle management
<br> <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">Since
composite bundles are implemented as virtual bundles, access to their content and portions
of their lifecycle are controlled by an external manager. As a result, their lifecycle handling
is slightly different from normal bundles. This section describes various composite lifecycle
management issues. <br> <br></td></tr>
            <tr><td class="diff-unchanged" >h3. Composite manager <br> <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">The
composite manager results from the use of virtual bundles. The composite manager is largely
responsible for actually realizing the capabilities embodied in the composite declaration
headers. This means it is the composite manager&#39;s responsibility to: <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">*
Manage a composite bundle&#39;s constituent bundles. <br>* Provide constituent bundles
access to imported packages, required bundles, and imported services. <br>* Provide
the parent framework access to exported packages, provided bundles, and exported services.
<br>* Manage the overall lifecycle of composite bundles. <br> <br>The precise
approach the composite manager uses to accomplish these responsibilities is not specified.
<br> <br>h3. General lifecycle management <br> <br>In general, composite
lifecycle management follows that of any virtual bundle, which is not completely fleshed out
in all cases. For installation, if an &quot;install hook&quot; is introduced for virtual
bundle, then the composite manager can use it to seamlessly install composite bundles via
the {{BundleContext.installBundle()}} method, like any normal bundle. If install hooks are
not proposed, then it could provide a simple service for installing composites. <br>
<br>For resolving a composite, the wires for the required <br> <br>h3. Resolving
a composite <br> <br>h3. Refreshing a composite <br> <br></td></tr>
            <tr><td class="diff-unchanged" >h3. Provided bundles <br> <br></td></tr>
            <tr><td class="diff-snipped" >...<br></td></tr>
            <tr><td class="diff-unchanged" >h1. Open issues <br> <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">h2.
Rich wiring information <br> <br>Currently, the wiring information provided by
the virtual bundle proposal has been kept purposely simplistic. To fully implement aspects
of composites, like requiring/providing bundles, it is necessary to get richer information
from the wires, such as the type of capability. Further, the wiring information needs to be
at the module-level (i.e., bundle revision level), not at the bundle level. <br> <br></td></tr>
            <tr><td class="diff-unchanged" >h1. Considered alternatives <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>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., <tt>Bundle-ClassPath</tt>, <tt>Bundle-Activator</tt>,
<tt>Bundle-NativeCode</tt>, <tt>Bundle-ActivationPolicy</tt>). Other
than explicitly disallowed headers, all other headers maintain their normal meaning. For example,
code dependencies are handled by:</p>

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


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

<ul>
	<li><tt>Import-Service</tt> - 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><tt>Export-Service</tt> - 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><tt>Include-Bundle</tt> - A comma-separate list of bundle URLs.</li>
</ul>


<p>To simplify matching a composite's exported packages to its contained bundles, this
proposal introduces a new <tt>from</tt> directive for <tt>Export-Package</tt>,
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: Paint Program
Bundle-SymbolicName: org.foo.paint.composite
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>

<p>This proposal introduces one final header, which is:</p>

<ul>
	<li><tt>Provide-Bundle</tt> - a comma-delimited set of symbolic names specifying
the constituent bundles provided by the composite bundle to the parent framework.</li>
</ul>


<p>The provided bundles will be manifested in the parent framework as virtual bundles
themselves.</p>

<p>These declarative headers define the entire capabilities of a composite bundle. To
summarize, these capabilities are: containing bundles, importing/exporting packages, requiring/providing
bundles, and importing/exporting services.</p>

<p>NOTE: It is not clear if <tt>Import-Package</tt> should essentially support
an "export as" directive where the composite creator explicitly specifies how the imported
package gets converted to an export internally or if this should be automatically converted
by the eventually injected wire. If the latter, then this relates to the rich wiring section
in the open issues. </p>

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

<p>Since composite bundles are implemented as virtual bundles, access to their content
and portions of their lifecycle are controlled by an external manager. As a result, their
lifecycle handling is slightly different from normal bundles. This section describes various
composite lifecycle management issues.</p>

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

<p>The composite manager results from the use of virtual bundles. The composite manager
is largely responsible for actually realizing the capabilities embodied in the composite declaration
headers. This means it is the composite manager's responsibility to:</p>

<ul>
	<li>Manage a composite bundle's constituent bundles.</li>
	<li>Provide constituent bundles access to imported packages, required bundles, and
imported services.</li>
	<li>Provide the parent framework access to exported packages, provided bundles, and
exported services.</li>
	<li>Manage the overall lifecycle of composite bundles.</li>
</ul>


<p>The precise approach the composite manager uses to accomplish these responsibilities
is not specified.</p>

<h3><a name="CompositeBundles-Generallifecyclemanagement"></a>General lifecycle
management</h3>

<p>In general, composite lifecycle management follows that of any virtual bundle, which
is not completely fleshed out in all cases. For installation, if an "install hook" is introduced
for virtual bundle, then the composite manager can use it to seamlessly install composite
bundles via the <tt>BundleContext.installBundle()</tt> method, like any normal
bundle. If install hooks are not proposed, then it could provide a simple service for installing
composites.</p>

<p>For resolving a composite, the wires for the required</p>

<h3><a name="CompositeBundles-Resolvingacomposite"></a>Resolving a composite</h3>

<h3><a name="CompositeBundles-Refreshingacomposite"></a>Refreshing a composite</h3>

<h3><a name="CompositeBundles-Providedbundles"></a>Provided bundles</h3>


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

<h2><a name="CompositeBundles-Richwiringinformation"></a>Rich wiring information</h2>

<p>Currently, the wiring information provided by the virtual bundle proposal has been
kept purposely simplistic. To fully implement aspects of composites, like requiring/providing
bundles, it is necessary to get richer information from the wires, such as the type of capability.
Further, the wiring information needs to be at the module-level (i.e., bundle revision level),
not at the bundle level.</p>

<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=7&originalVersion=6">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