Author: buildbot
Date: Mon Mar 5 14:46:26 2012
New Revision: 807438
Log:
Staging update by buildbot for ace
Modified:
websites/staging/ace/trunk/content/ (props changed)
websites/staging/ace/trunk/content/dev-doc/architecture.html
Propchange: websites/staging/ace/trunk/content/
------------------------------------------------------------------------------
cms:source-revision = 1297077
Modified: websites/staging/ace/trunk/content/dev-doc/architecture.html
==============================================================================
--- websites/staging/ace/trunk/content/dev-doc/architecture.html (original)
+++ websites/staging/ace/trunk/content/dev-doc/architecture.html Mon Mar 5
14:46:26 2012
@@ -154,7 +154,112 @@
<p><a href="/"><i class='icon-home'></i> Home</a> » <a
href="/dev-doc/">Dev-doc</a></p>
<h1>Architecture</h1>
<div class="clear"></div>
- <div id="content"></div>
+ <div id="content"><h1 id="introduction">Introduction</h1>
+<p>Apache ACE is a system that can be used to provision software to OSGi based
and other targets. It manages the life cycle of bundles and provides a
controlled, centralized way to install, update and uninstall software and
related artifacts such as configuration data, native code and device
firmware.</p>
+<h3 id="purpose-and-scope">Purpose and scope</h3>
+<p>The purpose of this document is to provide a comprehensive overview of the
software architecture of the system. It uses a number of different views to
depict the important aspects of the system and captures and conveys the
significant architectural decisions which have been made on the system.</p>
+<p>It serves three purposes:</p>
+<ol>
+<li><em>Abstraction of the system.</em> The architecture provides a relatively
small, intellectually graspable model of how the system is structured and how
components interact.</li>
+<li><em>Mutual communication.</em> The model described here forms the common
basis for all of the stakeholders to communicate with each other and form
consensus about the system.</li>
+<li><em>Major design decisions.</em> The description of the architecture
represents the earliest set of design decisions that have a significant impact
on the system as a whole. They are relevant to ensure the qualities and
features of the architecture.</li>
+</ol>
+<h3 id="readers-guide">Readers' guide</h3>
+<p>The document starts with an introduction, outlining the scope and purpose
of this document and defining some acronyms and abbreviations. It then goes on
by first sketching the architectural context, exploring the domain and the
constraints. That is followed by the architectural design, which uses the 4+1
view as a guide to describe the system.</p>
+<p>All stakeholders should read the architectural context, as it explains what
the system does and how it interacts with its surroundings.</p>
+<p>Software engineers in particular should read the architectural design,
which outlines the foundation and describes the high level design that forms
the basis for further analysis and design.</p>
+<h3 id="definitions-acronyms-and-abbreviations">Definitions, acronyms and
abbreviations</h3>
+<table>
+<thead>
+<tr>
+<th>Definition</th>
+<th>Explanation</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>OSGi</td>
+<td>The OSGi alliance is an independent non-profit organization that maintains
the OSGi standard. OSGi technology provides a service-oriented, component-based
environment for developers and offers standardized ways to manage the software
life cycle.</td>
+</tr>
+<tr>
+<td>Provisioning</td>
+<td>Software provisioning is the process of installing and updating
software.</td>
+</tr>
+<tr>
+<td>Target</td>
+<td>A target, or OSGi gateway, is a computer or device that has an OSGi
framework installed.</td>
+</tr>
+<tr>
+<td>REST</td>
+<td>Representational State Transfer (REST) is a style of software architecture
for distributed hypermedia systems. The term was introduced in the doctoral
dissertation in 2000 by Roy Fielding, one of the principal authors of the
Hypertext Transfer Protocol (HTTP) specification, and has come into widespread
use in the networking community.</td>
+</tr>
+<tr>
+<td>JMX</td>
+<td>Java Management Extensions provides the tools for building distributed,
web-based, modular and dynamic solutions for managing and monitoring devices,
applications and service-driven networks. Since Java 5, it is part of the Java
SE platform.</td>
+</tr>
+<tr>
+<td>SOAP</td>
+<td>SOAP is a protocol for exchanging XML-based messages over computer
networks, normally using HTTP/HTTPS. SOAP forms the foundation layer of the Web
services stack, providing a basic messaging framework that more abstract layers
can build on.</td>
+</tr>
+<tr>
+<td>DIY</td>
+<td>An acronym for "do it yourself".</td>
+</tr>
+</tbody>
+</table>
+<h2 id="architectural-context">Architectural Context</h2>
+<h3 id="domains">Domains</h3>
+<p>The system consists of the following domains, as shown in the picture
below.</p>
+<p>On the left hand side, the user interface and dependency repository are
shown. The dependency repository, sometimes referred to in an analogy as the
"shop", is mainly concerned with the dependency management domain, effectively
linking artifacts to targets through various mechanisms of grouping and
filtering based on requirements and capabilities of the individual
artifacts.</p>
+<p>On the right hand side, the deployment aspect deals with the actual
provisioning of versioned sets of artifacts to targets.</p>
+<p>Finally, on the target itself, the life cycle is monitored and managed by
the management agent.</p>
+<p>The OBR does not need to be a part of our system, but it is used both in
the dependency and deployment domain.</p>
+<p>The lower part of the image deals with feedback. Feedback is responsible
for providing historic data of all changes to the actual life cycle of the
target, which is collected in the audit log and synchronized back to the
server.</p>
+<h4 id="dependency-management">Dependency management</h4>
+<p>Whenever you are dealing with collections of artifacts, you want to start
grouping them to form logical subsystems. Doing this makes the artifacts more
manageable by users that are not intimately familiar with the architecture of
the software components that are being deployed.</p>
+<p>As an analogy, we often use the example of IKEA. They create modular
furniture, and sell their modules in configurations that make sense to their
users. You can order a cupboard that consists of planks, screws and doors, and
they give those configurations names. Apache ACE pretty much allows you to do
the same thing, which is why we like the "shop" analogy. In ACE we group our
artifacts into named distributions, and users can install one or more of these
onto a target.</p>
+<p>When installing artifacts together, we also need to make sure this
collection actually works together. Each bundle can have dependencies on other
bundles, services, packages or even specific hardware or operating systems.
These dependencies all need to be managed.</p>
+<p>Within an OSGi framework, there are two layers that feature
dependencies:</p>
+<ol>
+<li>the module layer, that has package dependencies;</li>
+<li>the service layer, that has service dependencies.</li>
+</ol>
+<p>Traditionally, in OSGi, a bundle contains enough meta-data to analyze
package dependencies and ensure that these can be resolved. Service
dependencies, however, are a lot harder to analyze because of the extremely
dynamic nature of a service and the fact that there is no meta-data available.
Also, modern dependency management frameworks can express dependencies on more
than just services, allowing users to have configuration dependencies or even
custom dependencies like a dependency on the time of day.</p>
+<p>For other dependencies, such as required screen sizes, or the presence of
specific hardware, no meta-data is available in the bundle, so that is one
thing we need to add externally.</p>
+<p>Summing it up, it is important to make sure that you first of all have a
clear overview of the artifacts and their different deployable distributions
and secondly that you end up deploying sets of artifacts that work together
well in the environments in which they're deployed.</p>
+<h4 id="deployment">Deployment</h4>
+<p>In short, deployment is responsible for getting software artifacts onto
target systems. The general strategy is to have a management agent on each OSGi
based target that receives and deploys these artifacts.</p>
+<p>An important aspect of deployment is the actual distribution of artifacts.
The provisioning server takes an OBR as its source and artifacts somehow need
to find a way to the targets. In real-life scenarios, there often won't be a
completely open, two way connection between server and target, so catering for
all kinds of scenarios here is important.</p>
+<h4 id="life-cycle-management">Life cycle management</h4>
+<p>Life cycle management deals with managing the life cycle of artifacts
within the OSGi based target. </p>
+<p>The management agent is responsible for managing these life cycles, when to
update and even to figure out what update strategy to implement. The management
agent is also responsible for monitoring any changes and reporting those back
via the audit log (see "Feedback" below).</p>
+<p>Different types of artifacts might have different life cycles. From a
provisioning point of view, each artifact is either present on a target or it
is not. Bundles have a more extensive life cycle, where the following states
can be identified:</p>
+<ul>
+<li>installed;</li>
+<li>resolved;</li>
+<li>starting;</li>
+<li>active;</li>
+<li>stopping;</li>
+<li>uninstalled.</li>
+</ul>
+<p>The following state diagram shows these states and their transitions:</p>
+<p>TODO</p>
+<p>The transitions are explained below:</p>
+<ul>
+<li><em>install</em> - Each bundle starts its life cycle when it is first
installed in the OSGi framework. When a bundle is installed it is stored
persistently in the framework.</li>
+<li><em>start</em> - As soon as the bundle is started, it will transition
through a couple of states. The first step is the resolving of package
dependencies. Here the bundle is "wired up" and if that succeeds, it ends up in
the resolved state. From there it will go to starting, where the bundle
activator gets instantiated and a bundle can become an active entity (it can
start threads, initialize, etc.). Finally it ends up in the active state.</li>
+<li><em>update</em> - As soon as a bundle is installed, it can be updated.
When a bundle is updated, if it was active, it will be stopped. Subsequently it
will have to be resolved again, and started.</li>
+<li><em>stop</em> - When a bundle is active, it can be stopped. It will first
go to the stopping state, where it will have to cleanup (basically undo
everything it did during starting). It will end up as resolved.</li>
+<li><em>uninstall</em> - When a bundle is no longer needed, it can be
uninstalled. That's a final state, from there it can never be started
again.</li>
+</ul>
+<h4 id="feedback">Feedback</h4>
+<p>Feedback is responsible for collecting log data and synchronizing it back
to the server. By default, all life cycle data is collected in the audit log.
This mechanism is extensible and can support domain specific extensions.</p>
+<p>An audit log is a full historic account of all events that are relevant for
a certain target. In this case, it provides historic data of all changes to the
actual life cycle of the target, both triggered by the management agent and by
other mechanisms on the target (for example, it also shows when the framework
itself was started and stopped).</p>
+<h2 id="architectural-design">Architectural Design</h2>
+<h3 id="architectural-foundation">Architectural foundation</h3>
+<h4 id="service-oriented-component-based-architecture">Service oriented,
component based architecture</h4>
+<h4 id="principles">Principles</h4>
+<h3 id="use-case-view">Use Case View</h3></div>
<hr>
<footer>
<p>Copyright © 2012 The Apache Software Foundation, Licensed
under the <a href="http://www.apache.org/licenses/LICENSE-2.0";>Apache License,
Version 2.0</a>.<br/>Apache and the Apache feather logo are trademarks of The
Apache Software Foundation.</p>
