ace-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r807438 - in /websites/staging/ace/trunk/content: ./ dev-doc/architecture.html
Date Mon, 05 Mar 2012 14:46:26 GMT
Author: buildbot
Date: Mon Mar  5 14:46:26 2012
New Revision: 807438

Staging update by buildbot for ace

    websites/staging/ace/trunk/content/   (props changed)

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>&nbsp;&raquo&nbsp;<a
       <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>
+<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>
+<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>
+<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>
+<td>Software provisioning is the process of installing and updating software.</td>
+<td>A target, or OSGi gateway, is a computer or device that has an OSGi framework installed.</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>
+<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>
+<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>
+<td>An acronym for "do it yourself".</td>
+<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
+<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
+<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
+<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>
+<li>the module layer, that has package dependencies;</li>
+<li>the service layer, that has service dependencies.</li>
+<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>
+<p>The following state diagram shows these states and their transitions:</p>
+<p>The transitions are explained below:</p>
+<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
+<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
+<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>
+<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>
         <p>Copyright &#169; 2012 The Apache Software Foundation, Licensed under
the <a href="">Apache License, Version 2.0</a>.<br/>Apache
and the Apache feather logo are trademarks of The Apache Software Foundation.</p>

View raw message