Added: websites/staging/ace/trunk/content/docs/analysis/auditlog-analysis.html
==============================================================================
--- websites/staging/ace/trunk/content/docs/analysis/auditlog-analysis.html
(added)
+++ websites/staging/ace/trunk/content/docs/analysis/auditlog-analysis.html Mon
Nov 24 22:42:13 2014
@@ -0,0 +1,265 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html lang="en">
+ <head>
+ <title>Audit Log Analysis</title>
+ <meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
+ <meta property="og:image" content="//www.apache.org/images/asf_logo.gif" />
+ <link href="/css/bootstrap.min.css" rel="stylesheet" media="screen">
+ <link href="/css/prettify.css" rel="stylesheet" media="screen">
+ <link href="/css/code.css" rel="stylesheet" media="screen">
+ <script src="//code.jquery.com/jquery.js"></script>
+ <script src="/js/bootstrap.min.js"></script>
+ <script src="/js/prettify.js"></script>
+
+
+
+ <script>
+ $(function () { prettyPrint() })
+ $().dropdown()
+ </script>
+ </head>
+ <body style="padding-top: 50px;">
+ <div class="navbar navbar-fixed-top navbar-inverse">
+ <div class="navbar-inner">
+ <div class="container">
+ <a class="brand" href="/index.html">Apache ACE™</a>
+ <ul class="nav">
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">News <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a href="/news.html">News</a>
+ </li>
+ <li>
+ <a href="/on-the-web.html">On the web</a>
+ </li>
+ </ul>
+ </li>
+ <li>
+ <a href="/downloads.html">Downloads</a>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Users <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a href="/user-doc/introduction.html">Introduction</a>
+ </li>
+ <li>
+ <a href="/user-doc/getting-started.html">Getting Started</a>
+ </li>
+ <li>
+ <a href="/user-doc/user-guide.html">User Guide</a>
+ </li>
+ <li>
+ <a href="/user-doc/features.html">Features</a>
+ </li>
+ <li>
+ <a href="/user-doc/shellapi.html">Client Shell API</a>
+ </li>
+ <li>
+ <a href="/user-doc/restapi.html">Client REST API</a>
+ </li>
+ <li>
+ <a href="/user-doc/useradmin-ui.html">User Management Guide</a>
+ </li>
+ <li>
+ <a href="/user-doc/faq.html">FAQ</a>
+ </li>
+ <li>
+ <a href="/user-doc/support.html">Support</a>
+ </li>
+ </ul>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Developers <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a href="/dev-doc/getting-started.html">Getting Started</a>
+ </li>
+ <li>
+ <a href="/dev-doc/requirements/">Requirements</a>
+ </li>
+ <li>
+ <a href="/dev-doc/architecture.html">Architecture</a>
+ </li>
+ <li>
+ <a href="/dev-doc/analysis/">Analysis</a>
+ </li>
+ <li>
+ <a href="/dev-doc/design/">Design</a>
+ </li>
+ <li>
+ <a href="/dev-doc/coding-standards.html">Coding Standards</a>
+ </li>
+ <li>
+ <a href="/dev-doc/release-guide.html">Release Guide</a>
+ </li>
+ <li>
+ <a href="/dev-doc/writing-tests.html">Writing unit/integration
tests</a>
+ </li>
+ <li>
+ <a href="/dev-doc/adding-custom-artifact-types.html">Adding custom
artifact types</a>
+ </li>
+ <li>
+ <a href="/dev-doc/configuring-relay-servers.html">Configuring and
using relay servers</a>
+ </li>
+ </ul>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Get Involved <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a href="/get-involved/mailing-lists.html">Mailing Lists</a>
+ </li>
+ <li>
+ <a href="/get-involved/issue-tracking.html">Issue Tracking</a>
+ </li>
+ <li>
+ <a href="/get-involved/continuous-integration.html">Continuous
Integration</a>
+ </li>
+ <li>
+ <a href="/get-involved/source-code.html">Source Code</a>
+ </li>
+ <li>
+ <a href="/get-involved/project-team.html">Project Team</a>
+ </li>
+ </ul>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Wiki <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a
href="https://cwiki.apache.org/confluence/display/ACE/Board+Reports";>Board
Reports <i class="icon-share-alt"></i></a>
+ </li>
+ <li>
+ <a
href="https://cwiki.apache.org/confluence/display/ACE/Index";>Homepage <i
class="icon-share-alt"></i></a>
+ </li>
+ </ul>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Apache <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a href="http://www.apache.org/";>Apache Homepage <i
class="icon-share-alt"></i></a>
+ </li>
+ <li>
+ <a href="http://www.apache.org/licenses/";>Licenses <i
class="icon-share-alt"></i></a>
+ </li>
+ <li>
+ <a href="http://www.apache.org/security/";>Security <i
class="icon-share-alt"></i></a>
+ </li>
+ <li>
+ <a
href="http://www.apache.org/foundation/sponsorship.html";>Sponsorship <i
class="icon-share-alt"></i></a>
+ </li>
+ <li>
+ <a href="http://www.apache.org/foundation/thanks.html";>Thanks <i
class="icon-share-alt"></i></a>
+ </li>
+ </ul>
+ </li>
+</ul>
+
+ </div>
+ </div>
+ </div>
+ <div class="container">
+ <p><a href="/"><i class='icon-home'></i> Home</a> » <a
href="/docs/">Docs</a> » <a
href="/docs/analysis/">Analysis</a></p>
+ <h1>Audit Log Analysis</h1>
+ <div class="clear"></div>
+ <div id="content"><p>An audit log is a full historic account of all
events that are relevant for a certain object. In this case, we keep audit logs
of each target that is managed by the provisioning server.</p>
+<h1 id="problem">Problem</h1>
+<p>The first issue is where to maintain the audit log. On the one hand, one
can maintain it on the target, but since the management agent talks to the
server, it could keep the log too.</p>
+<p>Then there is the question of how to maintain the log. What events should
be in it, and what is an event?</p>
+<p>Finally, the audit log should be readable and query-able, so people can
review it.</p>
+<p>The following use cases can be defined:</p>
+<ul>
+<li>Store event. Stores a new event to the audit log.</li>
+<li>Get events. Queries (a subset of) events.</li>
+<li>Merge events. Merges a set of (new) events with the existing events.</li>
+</ul>
+<h1 id="context">Context</h1>
+<p>We basically have two contexts:</p>
+<ul>
+<li>Target, limited resources, so we should use something really "lean and
mean".</li>
+<li>Server, scalable solution, expect people to query for (large numbers of)
events.</li>
+</ul>
+<h1 id="possible-solutions">Possible solutions</h1>
+<p>As with all repositories, there should be one location where it is edited.
In this case, the logical place to do that is on the target itself, since that
is where the changes actually occur. In theory, the server also knows, but that
theory breaks down if things fail on the target or other parties start
manipulating the life cycle of bundles. The target itself can detect such
activities.</p>
+<p>The next question is what needs to be logged. And how do we get access to
these events?</p>
+<p>When storing events, each event can get a unique sequence number. Sequence
numbers start with 1 and can be used to determine if you have the complete
log.</p>
+<p>Assuming the target has limited storage, it might not be possible to keep
the full log available locally. There are a couple of reasons to replicate this
log to a central server:</p>
+<ul>
+<li>space, as said the full log might not fit;</li>
+<li>safety, when the target is somehow (partly) erased or compromised, we
don't want to loose the log;</li>
+<li>remote diagnostics, we want to get an overview of the audit log without
actually connecting to the target directly.</li>
+</ul>
+<p>When replicating, the following scenarios can occur:</p>
+<ol>
+<li>The target has lost its whole log and really wants to (re)start from
sequence number 1.</li>
+<li>The server has lost its whole log and receives a partial log.</li>
+</ol>
+<p>Starting with the second scenario, the server always simply collects
incoming audit logs, so its memory can be restored from any number of targets
or relay servers that report everything they know (again). Hopefully that will
lead to a complete log again. If not, there's not much we can do.</p>
+<p>The first scenario is potentially more problematic, since the target has no
way of knowing (for sure) at which sequence number it had arrived when
everything was lost. In theory it might ask (relay) servers, but even those
might not have been up to date, so that does not work. The only thing it can do
here is: Start a new log at sequence number 1. That means we can have more than
one log in these cases, and that again means we need to be able to identify
which log (of each target) we're talking about. Therefore, when a new log is
created, it should contain some unique identifier for that log (an identifier
that should not depend on stored information, so for example we could use the
current time in milliseconds, that should be fairly unique, or just some random
number).</p>
+<p>How to find the central server? Use the discovery service!? This is not
that big of a deal.</p>
+<p>Events should at least contain:</p>
+<ul>
+<li>a datestamp, indicating when the event occurred;</li>
+<li>a checksum and/or signature;</li>
+<li>a short, human readable message explaining the event;</li>
+<li>details:<ul>
+<li>in the form of a (possibly multi-line) document</li>
+<li>in the form of a set of properties</li>
+</ul>
+</li>
+</ul>
+<p>The server will add:</p>
+<ul>
+<li>the target ID of the target that logged the event.</li>
+</ul>
+<p>Storage will be resolve differently on the server and target. On the
target, using any kind of database would amount to having to include a
considerable library, which makes these solutions impractical there. We might
want to consider something like that for the server though. The options we
have, are:</p>
+<ul>
+<li>Relational database</li>
+<li>Object database</li>
+<li>XML</li>
+<li>DIY</li>
+</ul>
+<p>How do events get logged?</p>
+<ul>
+<li>explicitly, our management agent calls an AuditLog service method;</li>
+<li>implicitly, by logging (certain) events in the system;</li>
+</ul>
+<p>Implicit algorithms can be build on top of the AuditLog service. What we
need to monitor is the life cycle layer, which basically means adding a
BundleListener and an FrameworkListener. Those capture all state changes of the
framework. Technically we can either directly add those listeners, or use
EventAdmin if that is available.</p>
+<p>What would be the best way for the target to send audit log updates to the
server? I don't think we want the server to poll here, so the target should
send updates (periodically). So how does it know what to send?</p>
+<ul>
+<li>it could keep track of the last event it sent, sending newer ones after
that;</li>
+<li>it could ask for the list of events the server has;</li>
+<li>it could send its highest log event number, and get back a list of missing
events on the server, and then respond with the missing events.</li>
+<li>it could just send everything.</li>
+</ul>
+<h1 id="discussion">Discussion</h1>
+<p>Having two layers for the audit log makes sense:</p>
+<ul>
+<li>The first, lowest, layer is the AuditLog service that gives access to the
log. On the one hand it allows people to log messages, on the other it should
provide query access. Those should be split into two different interfaces.</li>
+<li>The second layer can build on top of that. It can either be removed
completely, which means the responsibility for logging becomes that of the
application (probably the management agent). It can be implemented using
listeners. Finally, it can be implemented using events.</li>
+</ul>
+<p>On the target we should implement a storage solution ourselves, to keep the
actual code small. The code should be able to log events quickly (as that will
happen far more often than retrieving them).</p>
+<p>Communication between the target and server should be initiated by the
target. The target can basically send two commands to the server:</p>
+<ol>
+<li>My audit log contains sequence number 4-8, tell me your numbers. The
server then responds (for example) with 1-6. This indicates we need to send
7-8.</li>
+<li>Here you have events 7-8, can you send me 1-3? The server stores its
missing events, and sends you the events it has (always check if what you get
is what you requested).</li>
+</ol>
+<p>This is setup in this way so the same commands can also be used by relay
servers to replicate logs between server and target.</p>
+<h1 id="conclusion">Conclusion</h1>
+<ul>
+<li>The audit log is maintained on the target.</li>
+<li>On the target, we implement the storage mechanism ourselves to ensure we
have a solution with a very small footprint.</li>
+<li>On the server, we use an XStream based solution to store the logs of all
the targets.</li>
+<li>Our communication protocol between target and (relay)server however,
should probably not rely on XML.</li>
+<li>Our communication protocol between server and (relay)server might rely on
XML (determine at design time what makes most sense).</li>
+</ul></div>
+ <hr>
+ <footer>
+ <p>Copyright © 2012-2014 <a href="http://www.apache.org/";>The
Apache Software Foundation</a>, Licensed under the <a
href="http://www.apache.org/licenses/LICENSE-2.0";>Apache License, Version
2.0</a>.<br/>Apache ACE, the Apache ACE logo, Apache and the Apache feather
logo are trademarks of The Apache Software Foundation. All other marks
mentioned may be trademarks or registered trademarks of their respective
owners.</p>
+ </footer>
+ </div>
+ </body>
+</html>
Added:
websites/staging/ace/trunk/content/docs/analysis/bundlerepository-analysis.html
==============================================================================
---
websites/staging/ace/trunk/content/docs/analysis/bundlerepository-analysis.html
(added)
+++
websites/staging/ace/trunk/content/docs/analysis/bundlerepository-analysis.html
Mon Nov 24 22:42:13 2014
@@ -0,0 +1,200 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html lang="en">
+ <head>
+ <title>Bundle Repository Analysis</title>
+ <meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
+ <meta property="og:image" content="//www.apache.org/images/asf_logo.gif" />
+ <link href="/css/bootstrap.min.css" rel="stylesheet" media="screen">
+ <link href="/css/prettify.css" rel="stylesheet" media="screen">
+ <link href="/css/code.css" rel="stylesheet" media="screen">
+ <script src="//code.jquery.com/jquery.js"></script>
+ <script src="/js/bootstrap.min.js"></script>
+ <script src="/js/prettify.js"></script>
+
+
+
+ <script>
+ $(function () { prettyPrint() })
+ $().dropdown()
+ </script>
+ </head>
+ <body style="padding-top: 50px;">
+ <div class="navbar navbar-fixed-top navbar-inverse">
+ <div class="navbar-inner">
+ <div class="container">
+ <a class="brand" href="/index.html">Apache ACE™</a>
+ <ul class="nav">
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">News <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a href="/news.html">News</a>
+ </li>
+ <li>
+ <a href="/on-the-web.html">On the web</a>
+ </li>
+ </ul>
+ </li>
+ <li>
+ <a href="/downloads.html">Downloads</a>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Users <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a href="/user-doc/introduction.html">Introduction</a>
+ </li>
+ <li>
+ <a href="/user-doc/getting-started.html">Getting Started</a>
+ </li>
+ <li>
+ <a href="/user-doc/user-guide.html">User Guide</a>
+ </li>
+ <li>
+ <a href="/user-doc/features.html">Features</a>
+ </li>
+ <li>
+ <a href="/user-doc/shellapi.html">Client Shell API</a>
+ </li>
+ <li>
+ <a href="/user-doc/restapi.html">Client REST API</a>
+ </li>
+ <li>
+ <a href="/user-doc/useradmin-ui.html">User Management Guide</a>
+ </li>
+ <li>
+ <a href="/user-doc/faq.html">FAQ</a>
+ </li>
+ <li>
+ <a href="/user-doc/support.html">Support</a>
+ </li>
+ </ul>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Developers <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a href="/dev-doc/getting-started.html">Getting Started</a>
+ </li>
+ <li>
+ <a href="/dev-doc/requirements/">Requirements</a>
+ </li>
+ <li>
+ <a href="/dev-doc/architecture.html">Architecture</a>
+ </li>
+ <li>
+ <a href="/dev-doc/analysis/">Analysis</a>
+ </li>
+ <li>
+ <a href="/dev-doc/design/">Design</a>
+ </li>
+ <li>
+ <a href="/dev-doc/coding-standards.html">Coding Standards</a>
+ </li>
+ <li>
+ <a href="/dev-doc/release-guide.html">Release Guide</a>
+ </li>
+ <li>
+ <a href="/dev-doc/writing-tests.html">Writing unit/integration
tests</a>
+ </li>
+ <li>
+ <a href="/dev-doc/adding-custom-artifact-types.html">Adding custom
artifact types</a>
+ </li>
+ <li>
+ <a href="/dev-doc/configuring-relay-servers.html">Configuring and
using relay servers</a>
+ </li>
+ </ul>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Get Involved <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a href="/get-involved/mailing-lists.html">Mailing Lists</a>
+ </li>
+ <li>
+ <a href="/get-involved/issue-tracking.html">Issue Tracking</a>
+ </li>
+ <li>
+ <a href="/get-involved/continuous-integration.html">Continuous
Integration</a>
+ </li>
+ <li>
+ <a href="/get-involved/source-code.html">Source Code</a>
+ </li>
+ <li>
+ <a href="/get-involved/project-team.html">Project Team</a>
+ </li>
+ </ul>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Wiki <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a
href="https://cwiki.apache.org/confluence/display/ACE/Board+Reports";>Board
Reports <i class="icon-share-alt"></i></a>
+ </li>
+ <li>
+ <a
href="https://cwiki.apache.org/confluence/display/ACE/Index";>Homepage <i
class="icon-share-alt"></i></a>
+ </li>
+ </ul>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Apache <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a href="http://www.apache.org/";>Apache Homepage <i
class="icon-share-alt"></i></a>
+ </li>
+ <li>
+ <a href="http://www.apache.org/licenses/";>Licenses <i
class="icon-share-alt"></i></a>
+ </li>
+ <li>
+ <a href="http://www.apache.org/security/";>Security <i
class="icon-share-alt"></i></a>
+ </li>
+ <li>
+ <a
href="http://www.apache.org/foundation/sponsorship.html";>Sponsorship <i
class="icon-share-alt"></i></a>
+ </li>
+ <li>
+ <a href="http://www.apache.org/foundation/thanks.html";>Thanks <i
class="icon-share-alt"></i></a>
+ </li>
+ </ul>
+ </li>
+</ul>
+
+ </div>
+ </div>
+ </div>
+ <div class="container">
+ <p><a href="/"><i class='icon-home'></i> Home</a> » <a
href="/docs/">Docs</a> » <a
href="/docs/analysis/">Analysis</a></p>
+ <h1>Bundle Repository Analysis</h1>
+ <div class="clear"></div>
+ <div id="content"><p>The bundle repository stores actual bundles and
other artifacts. It is kept external to be able to leverage existing
repositories and better protect the intellectual property of our users.</p>
+<h1 id="problem">Problem</h1>
+<p>The bundle repository is an external repository that stores the actual
bundle data and other artifacts. We keep this data external to our system to
better protect the intellectual property of our users. Having only the
meta-data in our system ensures the bundles and artifacts themselves can remain
on a separate, protected network, even when the provisioning server itself is
used in a hosted or cloud environment.</p>
+<p>Access to the bundle repository is URL based.</p>
+<p>The use cases are:</p>
+<ul>
+<li>Get bundle, which returns the full bundle. This use case is mandatory, as
this is the main goal for having a bundle repository.</li>
+<li>Get bundle meta-data, which returns only the meta-data. This one is nice
to have, as it would help us on slow connections when we only want
metadata.</li>
+<li>Get a list of (a subset of) all bundles in the repository. When
provisioning, we already know what we want. When managing the shop we might
have use for querying features and we should seriously look at OBR as an
implementation. Also, as part of the Equinox provisioning effort, they are
defining a similar model.</li>
+<li>Install/update bundle. Makes the repository editable from the outside.</li>
+<li>Delete bundle. Mentioned separately here because of the dangers of
deleting bundles that might still be in use (the repository has no way of
knowing what's in use).</li>
+</ul>
+<h1 id="context">Context</h1>
+<p>Whilst we will no doubt create our own bundle repository, it would be a big
bonus if we could work with other bundle repositories. OBR comes to mind, but
there might be others. Therefore it's important to create an implementation
that maps easily onto (for example) an HTTP based repository.</p>
+<p>Our requirement to have URL based access to bundles ensures we can do
that.</p>
+<h1 id="possible-solutions">Possible solutions</h1>
+<p>As mentioned before, we basically have two solutions:</p>
+<ol>
+<li>use an existing solution;</li>
+<li>creating our own.</li>
+</ol>
+<h1 id="discussion">Discussion</h1>
+<p>Most use cases can be done either way. If you look at the OSGi Alliance's
RFC-112 for OBR, the only thing it does not support is manipulating a
repository. You could argue that's because it is beyond the scope, and because
currently, OBR can be implemented using any webserver (it's basically just a
set of bundles and a single XML descriptor).</p>
+<h1 id="conclusion">Conclusion</h1>
+<p>I think we should create our own implementation of OBR, extending it with
editing capabilities, and perhaps subsetting it (at least initially, we might
not want a whole requirements, capability and dependency mechanism in there
right now, as that's something we deal with inside our provisioning system).</p>
+<p>At the same time, adding these editing capabilities should not mean we
cannot still generate static files that can be deployed on an external HTTP
server. We do want to add an API for editing, but we don't want to make the
whole repository depend on the capability to run code on that server, since we
might want to do all maintenance on some client that simply uploads files to a
server.</p></div>
+ <hr>
+ <footer>
+ <p>Copyright © 2012-2014 <a href="http://www.apache.org/";>The
Apache Software Foundation</a>, Licensed under the <a
href="http://www.apache.org/licenses/LICENSE-2.0";>Apache License, Version
2.0</a>.<br/>Apache ACE, the Apache ACE logo, Apache and the Apache feather
logo are trademarks of The Apache Software Foundation. All other marks
mentioned may be trademarks or registered trademarks of their respective
owners.</p>
+ </footer>
+ </div>
+ </body>
+</html>
Added: websites/staging/ace/trunk/content/docs/analysis/index.html
==============================================================================
--- websites/staging/ace/trunk/content/docs/analysis/index.html (added)
+++ websites/staging/ace/trunk/content/docs/analysis/index.html Mon Nov 24
22:42:13 2014
@@ -0,0 +1,180 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html lang="en">
+ <head>
+ <title>Analysis</title>
+ <meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
+ <meta property="og:image" content="//www.apache.org/images/asf_logo.gif" />
+ <link href="/css/bootstrap.min.css" rel="stylesheet" media="screen">
+ <link href="/css/prettify.css" rel="stylesheet" media="screen">
+ <link href="/css/code.css" rel="stylesheet" media="screen">
+ <script src="//code.jquery.com/jquery.js"></script>
+ <script src="/js/bootstrap.min.js"></script>
+ <script src="/js/prettify.js"></script>
+
+
+
+ <script>
+ $(function () { prettyPrint() })
+ $().dropdown()
+ </script>
+ </head>
+ <body style="padding-top: 50px;">
+ <div class="navbar navbar-fixed-top navbar-inverse">
+ <div class="navbar-inner">
+ <div class="container">
+ <a class="brand" href="/index.html">Apache ACE™</a>
+ <ul class="nav">
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">News <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a href="/news.html">News</a>
+ </li>
+ <li>
+ <a href="/on-the-web.html">On the web</a>
+ </li>
+ </ul>
+ </li>
+ <li>
+ <a href="/downloads.html">Downloads</a>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Users <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a href="/user-doc/introduction.html">Introduction</a>
+ </li>
+ <li>
+ <a href="/user-doc/getting-started.html">Getting Started</a>
+ </li>
+ <li>
+ <a href="/user-doc/user-guide.html">User Guide</a>
+ </li>
+ <li>
+ <a href="/user-doc/features.html">Features</a>
+ </li>
+ <li>
+ <a href="/user-doc/shellapi.html">Client Shell API</a>
+ </li>
+ <li>
+ <a href="/user-doc/restapi.html">Client REST API</a>
+ </li>
+ <li>
+ <a href="/user-doc/useradmin-ui.html">User Management Guide</a>
+ </li>
+ <li>
+ <a href="/user-doc/faq.html">FAQ</a>
+ </li>
+ <li>
+ <a href="/user-doc/support.html">Support</a>
+ </li>
+ </ul>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Developers <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a href="/dev-doc/getting-started.html">Getting Started</a>
+ </li>
+ <li>
+ <a href="/dev-doc/requirements/">Requirements</a>
+ </li>
+ <li>
+ <a href="/dev-doc/architecture.html">Architecture</a>
+ </li>
+ <li>
+ <a href="/dev-doc/analysis/">Analysis</a>
+ </li>
+ <li>
+ <a href="/dev-doc/design/">Design</a>
+ </li>
+ <li>
+ <a href="/dev-doc/coding-standards.html">Coding Standards</a>
+ </li>
+ <li>
+ <a href="/dev-doc/release-guide.html">Release Guide</a>
+ </li>
+ <li>
+ <a href="/dev-doc/writing-tests.html">Writing unit/integration
tests</a>
+ </li>
+ <li>
+ <a href="/dev-doc/adding-custom-artifact-types.html">Adding custom
artifact types</a>
+ </li>
+ <li>
+ <a href="/dev-doc/configuring-relay-servers.html">Configuring and
using relay servers</a>
+ </li>
+ </ul>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Get Involved <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a href="/get-involved/mailing-lists.html">Mailing Lists</a>
+ </li>
+ <li>
+ <a href="/get-involved/issue-tracking.html">Issue Tracking</a>
+ </li>
+ <li>
+ <a href="/get-involved/continuous-integration.html">Continuous
Integration</a>
+ </li>
+ <li>
+ <a href="/get-involved/source-code.html">Source Code</a>
+ </li>
+ <li>
+ <a href="/get-involved/project-team.html">Project Team</a>
+ </li>
+ </ul>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Wiki <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a
href="https://cwiki.apache.org/confluence/display/ACE/Board+Reports";>Board
Reports <i class="icon-share-alt"></i></a>
+ </li>
+ <li>
+ <a
href="https://cwiki.apache.org/confluence/display/ACE/Index";>Homepage <i
class="icon-share-alt"></i></a>
+ </li>
+ </ul>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Apache <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a href="http://www.apache.org/";>Apache Homepage <i
class="icon-share-alt"></i></a>
+ </li>
+ <li>
+ <a href="http://www.apache.org/licenses/";>Licenses <i
class="icon-share-alt"></i></a>
+ </li>
+ <li>
+ <a href="http://www.apache.org/security/";>Security <i
class="icon-share-alt"></i></a>
+ </li>
+ <li>
+ <a
href="http://www.apache.org/foundation/sponsorship.html";>Sponsorship <i
class="icon-share-alt"></i></a>
+ </li>
+ <li>
+ <a href="http://www.apache.org/foundation/thanks.html";>Thanks <i
class="icon-share-alt"></i></a>
+ </li>
+ </ul>
+ </li>
+</ul>
+
+ </div>
+ </div>
+ </div>
+ <div class="container">
+ <p><a href="/"><i class='icon-home'></i> Home</a> » <a
href="/docs/">Docs</a> » <a
href="/docs/analysis/">Analysis</a></p>
+ <h1>Analysis</h1>
+ <div class="clear"></div>
+ <div id="content"><ul>
+<li><a href="security-analysis.html">Security Analysis</a></li>
+<li><a href="template-mechanism.html">Template Mechanism</a></li>
+<li><a href="auditlog-analysis.html">Audit Log Analysis</a></li>
+<li><a href="bundlerepository-analysis.html">Bundle Repository
Analysis</a></li>
+</ul></div>
+ <hr>
+ <footer>
+ <p>Copyright © 2012-2014 <a href="http://www.apache.org/";>The
Apache Software Foundation</a>, Licensed under the <a
href="http://www.apache.org/licenses/LICENSE-2.0";>Apache License, Version
2.0</a>.<br/>Apache ACE, the Apache ACE logo, Apache and the Apache feather
logo are trademarks of The Apache Software Foundation. All other marks
mentioned may be trademarks or registered trademarks of their respective
owners.</p>
+ </footer>
+ </div>
+ </body>
+</html>
Added:
websites/staging/ace/trunk/content/docs/analysis/security-analysis-flow.svg
==============================================================================
Binary file - no diff available.
Propchange:
websites/staging/ace/trunk/content/docs/analysis/security-analysis-flow.svg
------------------------------------------------------------------------------
svn:mime-type = image/svg+xml
Added: websites/staging/ace/trunk/content/docs/analysis/security-analysis.html
==============================================================================
--- websites/staging/ace/trunk/content/docs/analysis/security-analysis.html
(added)
+++ websites/staging/ace/trunk/content/docs/analysis/security-analysis.html Mon
Nov 24 22:42:13 2014
@@ -0,0 +1,219 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html lang="en">
+ <head>
+ <title>Security Analysis</title>
+ <meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
+ <meta property="og:image" content="//www.apache.org/images/asf_logo.gif" />
+ <link href="/css/bootstrap.min.css" rel="stylesheet" media="screen">
+ <link href="/css/prettify.css" rel="stylesheet" media="screen">
+ <link href="/css/code.css" rel="stylesheet" media="screen">
+ <script src="//code.jquery.com/jquery.js"></script>
+ <script src="/js/bootstrap.min.js"></script>
+ <script src="/js/prettify.js"></script>
+
+
+
+ <script>
+ $(function () { prettyPrint() })
+ $().dropdown()
+ </script>
+ </head>
+ <body style="padding-top: 50px;">
+ <div class="navbar navbar-fixed-top navbar-inverse">
+ <div class="navbar-inner">
+ <div class="container">
+ <a class="brand" href="/index.html">Apache ACE™</a>
+ <ul class="nav">
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">News <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a href="/news.html">News</a>
+ </li>
+ <li>
+ <a href="/on-the-web.html">On the web</a>
+ </li>
+ </ul>
+ </li>
+ <li>
+ <a href="/downloads.html">Downloads</a>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Users <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a href="/user-doc/introduction.html">Introduction</a>
+ </li>
+ <li>
+ <a href="/user-doc/getting-started.html">Getting Started</a>
+ </li>
+ <li>
+ <a href="/user-doc/user-guide.html">User Guide</a>
+ </li>
+ <li>
+ <a href="/user-doc/features.html">Features</a>
+ </li>
+ <li>
+ <a href="/user-doc/shellapi.html">Client Shell API</a>
+ </li>
+ <li>
+ <a href="/user-doc/restapi.html">Client REST API</a>
+ </li>
+ <li>
+ <a href="/user-doc/useradmin-ui.html">User Management Guide</a>
+ </li>
+ <li>
+ <a href="/user-doc/faq.html">FAQ</a>
+ </li>
+ <li>
+ <a href="/user-doc/support.html">Support</a>
+ </li>
+ </ul>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Developers <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a href="/dev-doc/getting-started.html">Getting Started</a>
+ </li>
+ <li>
+ <a href="/dev-doc/requirements/">Requirements</a>
+ </li>
+ <li>
+ <a href="/dev-doc/architecture.html">Architecture</a>
+ </li>
+ <li>
+ <a href="/dev-doc/analysis/">Analysis</a>
+ </li>
+ <li>
+ <a href="/dev-doc/design/">Design</a>
+ </li>
+ <li>
+ <a href="/dev-doc/coding-standards.html">Coding Standards</a>
+ </li>
+ <li>
+ <a href="/dev-doc/release-guide.html">Release Guide</a>
+ </li>
+ <li>
+ <a href="/dev-doc/writing-tests.html">Writing unit/integration
tests</a>
+ </li>
+ <li>
+ <a href="/dev-doc/adding-custom-artifact-types.html">Adding custom
artifact types</a>
+ </li>
+ <li>
+ <a href="/dev-doc/configuring-relay-servers.html">Configuring and
using relay servers</a>
+ </li>
+ </ul>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Get Involved <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a href="/get-involved/mailing-lists.html">Mailing Lists</a>
+ </li>
+ <li>
+ <a href="/get-involved/issue-tracking.html">Issue Tracking</a>
+ </li>
+ <li>
+ <a href="/get-involved/continuous-integration.html">Continuous
Integration</a>
+ </li>
+ <li>
+ <a href="/get-involved/source-code.html">Source Code</a>
+ </li>
+ <li>
+ <a href="/get-involved/project-team.html">Project Team</a>
+ </li>
+ </ul>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Wiki <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a
href="https://cwiki.apache.org/confluence/display/ACE/Board+Reports";>Board
Reports <i class="icon-share-alt"></i></a>
+ </li>
+ <li>
+ <a
href="https://cwiki.apache.org/confluence/display/ACE/Index";>Homepage <i
class="icon-share-alt"></i></a>
+ </li>
+ </ul>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Apache <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a href="http://www.apache.org/";>Apache Homepage <i
class="icon-share-alt"></i></a>
+ </li>
+ <li>
+ <a href="http://www.apache.org/licenses/";>Licenses <i
class="icon-share-alt"></i></a>
+ </li>
+ <li>
+ <a href="http://www.apache.org/security/";>Security <i
class="icon-share-alt"></i></a>
+ </li>
+ <li>
+ <a
href="http://www.apache.org/foundation/sponsorship.html";>Sponsorship <i
class="icon-share-alt"></i></a>
+ </li>
+ <li>
+ <a href="http://www.apache.org/foundation/thanks.html";>Thanks <i
class="icon-share-alt"></i></a>
+ </li>
+ </ul>
+ </li>
+</ul>
+
+ </div>
+ </div>
+ </div>
+ <div class="container">
+ <p><a href="/"><i class='icon-home'></i> Home</a> » <a
href="/docs/">Docs</a> » <a
href="/docs/analysis/">Analysis</a></p>
+ <h1>Security Analysis</h1>
+ <div class="clear"></div>
+ <div id="content"><p>Security is an important concern for ACE. The
analysis needs to differentiate between the individual needs of each sub-system
and the overall flow inside the system. Furthermore, several scenarios need to
be taken into account and addressed. In general, safety issues are not part of
this analysis but will be addressed separately.</p>
+<p>Threat scenarios and possible countermeasures are given subdivided by and
investigated in regard to authentication, authorization, integrity, non
repudiation, and confidentiality. We need answers to the following questions,
what kind of different "attacks" from both external and internal interfaces can
we identify (threats); how can we authenticate the different actors (human and
machine) so we really know who we're talking to (authentication); who is
allowed to do what in the system (authorization); who did what at which point
of time (non repudiation); and how do we encrypt and ensure the integrity of
the communication/software/configuration data (confidentiality).</p>
+<p>Security on the target and relay server needs special attention because
they are most likely provided by a third party, might be accessible from the
outside, and not easily reachable for maintenance. It is for example possible
that a target is at a remote location, accessible via the internet, and
requires days to be accessed physically.</p>
+<h1 id="threat-scenarios">Threat Scenarios</h1>
+<p>This analysis focuses on the OSGi framework and management agent part of
the system and its interaction with a (relay) server as well as between the
client (for this analysis we assume the client is a separate node, for our web
based UI it just happens to be part of the server) and a server. The most
likely scenarios are forced breakdown of the system (denial of service attack),
malicious data that might change system behavior, attempts to take over
control, and espionage.</p>
+<ol>
+<li>(D)DOS - In general, it is not possible to prevent denial of service
attacks. Attackers normally can find a way to overload the system. Regarding
the management agent it would be for example possible to provide the agent with
a huge amount of data to install so that the target either is running out of
disk space or out of other processing resources. The same is possible for any
other entity in the system if an attacker finds a way to make it accept
data.</li>
+<li>Malicious Data - An attacker might use malicious data as part of a DOS
attack but it could be also used to gain control over the system or change some
aspects of its behavior to make it easier to take over control or cause other
harm.</li>
+<li>Hostile Takeover - Attackers might be interested in taking control over
(parts of) the system in order to either do espionage, change the behavior of
the system to do work for them, or plainly destroy/disable entities (e.g., to
harm competitors).</li>
+<li>Eavesdropping - An attacker might be able to listen in on the
communication between a target and its (relay-) server or the client and the
server. This might allow to learn about the configuration of a target and
getting hold of the installed software.</li>
+<li>Physical Access - Another type of attack would be to gain physical access
e.g., disassemble a target or a relay server in an attempt to steal its data
and/or impersonate it. Probably the only way to avoid that is hardware
encryption, which for ACE is out of scope (but can be used to further harden
the system).</li>
+</ol>
+<h1 id="countermeasures">Countermeasures</h1>
+<p>On the target there are two entities that are important namely, the (relay)
server which is providing the target with instructions and data/code, and the
management agent (i.e., the target itself). Regarding the communication between
a client and the server the secure checkout and commit of object repository
versions are important as well as the auditlog. The interaction between the
server and a relay server is a two way data exchange where the relay server is
comparable to a target in regard to the instructions and data/code it needs to
get from the server and to a server that sends the auditlog to a client. One
plus point from the security side is that the target is only polling the server
â hence, it is not accepting any connection requests from the outside. This
reduces the risk of a DOS attack but by no means makes it invulnerable against
it (especially since there is a high likelihood that the underlying platform is
vulnerable to DOS attacks as well). One way of workin
g around the polling restrictions are ARP and DNS injection attacks that might
make the target contact the wrong server. This allows for malicious data, DOS
attacks, and hostile takeovers.</p>
+<p>A good start to limit attack possibilities is to decouple the sub-net of
the target from the internet / external world by using relay servers but this
doesn't prevent the mentioned attacks and threats in all cases. Furthermore,
relay servers need to support both polling and being polled due to their
different roles (they are polled by the targets, need to poll deployment
packages or object repositories from the server, and push the auditlogs of
targets to the server). Finally, the server is only polled.</p>
+<h3 id="authentication">Authentication</h3>
+<p>As mentioned above, the most likely way of attacking a target or relay
server is to spoof its connection to the server (whether it is a relay server
or the real one). It is dangerous to rely on DNS and/or IP addresses because
both might be wrong. Given the issues at stake, authentication will need to be
based on certificates. An entity of the system should have a certificate (that
has the id as part of it's common name) as its identity.</p>
+<p>Furthermore, it needs to have a keystore of trusted root certificates (CA)
and a certificate revocation list (CRL). The (relay) server needs to have a
certificate as its identity that is part of a chain of trust to one of the
trusted root certificates of the target or client and vice versa. Basically,
this can be achieved via two ways, one is to use https with server and client
certificates; the other to use certificates to sign all messages/data using our
own protocol.</p>
+<h3 id="authorization">Authorization</h3>
+<p>We have to differentiate between several areas where authorization is
needed. The provisioning part needs to make sure it is installing deployment
packages from an authorized server.</p>
+<p>The target itself is running an OSGi framework and can subsequently, make
use of the built-in security. This is needed if deployed software components
can not be trusted and would be advisable to foster "least privilege" security
in general. However, the management agent will need to be able to cooperate
with the framework infrastructure to set-up needed rights. Special care needs
to be taken to avoid installing malicious software in a framework with security
disabled or with too powerful a set of rights. Due to the life-cycle
capabilities of OSGi, a malicious or faulty bundle could for example uninstall
the management agent itself if the bundle is started in the absence of security
or with admin permission (This aspect is not part of this analysis and will be
discussed as a separate user story).</p>
+<p>Assuming the additional requirements in regard to integrity and
authentication are satisfied it should be sufficient to ensure the server is
authorized to make changes to the target â hence, in a certificate based
approach separate chains of trust can be used to determine whether a server is
trusted and is authoritative for a given target. In other words, the
certificate of the server can be treated as a capability (revocation is then
possible via a certificate revocation list). The same applies for clients and
relay servers, respectively.</p>
+<h3 id="integrity">Integrity</h3>
+<p>Due to the fact that authorization to provision a given version (i.e., a
set of bundles) is mainly based on whether or not the current authenticated
server is authoritative for a target it is of great importance that the actual
deployment package has not been tampered with.</p>
+<p>The deployment admin specification already defines a way to ensure
integrity building upon the fact that deployment packages are Java JAR files
(which can be signed). Therefore, it makes sense to only allow deployment
packages that are signed by a certificate that the target has in a chain of
trust.</p>
+<p>Furthermore, taking into account relay servers the trusted certificates can
be limited further to for example only allow the actual server certificate.</p>
+<p>Deployment packages can be signed by any number of certificates so it is
possible to sign a deployment package multiple times in order to make it
available to different targets that follow non uniform certificate trust
strategies. The same is possible for the object repositories and the
auditlog.</p>
+<h3 id="non-repudiation">Non Repudiation</h3>
+<p>Several entities can be responsible for changes in the system. The
individual entities need to make sure they record in a non repudiation fashion
who was doing what for any action taken. Conversely, the server and possibly
the relay servers need a way to ensure that for example auditlog entries are
really from the target they are claimed to be.</p>
+<p>One way to tackle this is to use certificates to sign all data and to make
sure that for all data accepted from a different entity, the signature
(including the fingerprint of the signing certificate) is recorded. Taking the
auditlog as an example, a target would use its certificate to sign all entries
in the auditlog. Subsequently, a server or a client can be certain that a given
auditlog is originating from the target it is claimed to come from (assuming
the private key of the target certificate has not been exploited).</p>
+<p>Furthermore, it will be easy to invalidate data from compromised entities
by adding their certificates to the certificate revocation list.</p>
+<p>Another, more involved example, can be a target that receives a deployment
package and installs it. In this case, the manifest containing all the
signatures of the content of the signed deployment package as well as all the
fingerprints of the certificates that signed it need to be added to the targets
auditlog and this entry would be signed by the target certificate. After the
log is synchronized back to the server (possibly via several relay servers or
even manually) the server can determine who signed the deployment package and
where it has been installed. The same applies for clients.</p>
+<h3 id="confidentiality">Confidentiality</h3>
+<p>In most cases the software that needs to be provisioned as well as the
configuration of the targets needs to be kept confidential since it may contain
business secrets. This can only be ensured by means of encryption because we
have to take scenarios into account where communication happens via a none
secure channel like the internet.</p>
+<p>One secure set-up would be to use asynchronous encryption which would
furthermore not rely on a point-to-point protocol but rather enable all the way
confidentiality. Alas, the deployment packages might be big and asynchronous
encryption would be to slow in this case.</p>
+<p>The alternative is to use SSL (most likely by means of HTTPS). The downside
of SSL as for example in HTTPS is that it is often hard to set-up and
relatively inconvenient and static to use if the possibility of a man in the
middle attack needs to be ruled out.</p>
+<p>Possibly the biggest problem, in our scenario, is that we can not assume
that the common name of an entity reflects its IP/DNS name. Relay servers might
be operating in networks not under the customers or our control and the same
applies to targets and clients (which could have dynamic IP's and hostnames for
example). This problem can be overcome by ignoring the common name in regard to
authentication which might make it necessary to create some integration code
for certain platforms and containers (e.g., the JVM, by default, assumes that
it can resolve the common name as a host name). The downside is that such an
approach would open the possibility for man in the middle attacks. Only in
combination with client certificates this can be prevented (alas, this might
need some more adaption on the server side).</p>
+<p>Finally, the certificates on both, the server and the target side,
respectively, would need to be in a chain of trust. Assuming this precondition
holds, the only way to eavesdrop would then be to exploit one of the
certificate's private key (e.g., via disassembling the target by an attacker
that has physical access or by means of gaining access to the target via a
different vulnerability). Such a key could be blacklisted by adding it to the
certificate revocation list upon discovery of its exploitation.</p>
+<h3 id="encryption">Encryption</h3>
+<p>The physical access threat makes it possible that attackers might get hold
of data (like installed bundles). Https and certificates can prevent
eavesdropping while data is distributed but if an attacker can get hold of the
target or a relay server it is still possible to access the data. As mentioned
above, for the target the only way to prevent this would be hardware supported
encryption but for relay servers it is sufficient to encrypt the data itself.
We might need to support this eventually but it is not looked into further in
this analysis.</p>
+<h1 id="certificate-based-flow-analysis">Certificate based Flow Analysis</h1>
+<p>All entities (the server, the client, the relay server, and the target),
have a CRL and a keystore; the former contains revoked certificates and the
later the known and trusted certificate authorities. In general, for all
involved certificates, for a certificate to be valid it has to be the case that
it is in a chain-of-trust relation to at least one of the trusted certificate
authorities and is not revoked. Furthermore, there exists a special trusted
certificate known as the server authority and vice versa for the target and
client. The interaction between the entities is via HTTPS and needs a valid
server and client certificate. The common name of the certificate represents
the target, client, or server id, respectively. As a further restriction the
server certificate has to be in a chain of trust to the server certificate
authority, the client certificate has to be in a chain of trust to the client
certificate authority, and the target certificate has to be in a chain of trust
to the target certificate authority. The data exchanged between the entities
needs to be signed by the respective counterpart certificate authority. For
example, a deployment package send from the server to the target needs to be
signed by a valid certificate that is in a chain of trust to the server
certificate authority and auditlog entries send from the target to the server
must be signed by its target certificate. In other words, the signer needs to
be the one that created the specific data. CLR and keystore can be treated as
yet another object repository (because they need to be signed) â hence, they
can be synced from a server to clients, relay servers, and subsequently,
targets.</p>
+<p><object data="security-analysis-flow.svg" type="image/svg+xml"
class="span12" height="868"></object></p>
+<h1 id="conclusion">Conclusion</h1>
+<p>The set-up takes aforementioned countermeasure to the identified threat
into account. The https connection ensures the confidentiality via encryption.
Due to the server and client certificate connection authentication and
authorization are addressed. The requirement of separately signed content
provides integrity and non repudiation in the absence of compromised
certificate private keys. Certificates with known exploited keys can be revoked
by adding them to the CRLs. Authority derives from the chain of trust relation
to the server and target certificate authority.</p></div>
+ <hr>
+ <footer>
+ <p>Copyright © 2012-2014 <a href="http://www.apache.org/";>The
Apache Software Foundation</a>, Licensed under the <a
href="http://www.apache.org/licenses/LICENSE-2.0";>Apache License, Version
2.0</a>.<br/>Apache ACE, the Apache ACE logo, Apache and the Apache feather
logo are trademarks of The Apache Software Foundation. All other marks
mentioned may be trademarks or registered trademarks of their respective
owners.</p>
+ </footer>
+ </div>
+ </body>
+</html>
Added:
websites/staging/ace/trunk/content/docs/analysis/src/security-analysis-flow.graffle
==============================================================================
Binary file - no diff available.
Propchange:
websites/staging/ace/trunk/content/docs/analysis/src/security-analysis-flow.graffle
------------------------------------------------------------------------------
svn:mime-type = application/xml
Added: websites/staging/ace/trunk/content/docs/analysis/template-mechanism.html
==============================================================================
--- websites/staging/ace/trunk/content/docs/analysis/template-mechanism.html
(added)
+++ websites/staging/ace/trunk/content/docs/analysis/template-mechanism.html
Mon Nov 24 22:42:13 2014
@@ -0,0 +1,197 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html lang="en">
+ <head>
+ <title>Template Mechanism</title>
+ <meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
+ <meta property="og:image" content="//www.apache.org/images/asf_logo.gif" />
+ <link href="/css/bootstrap.min.css" rel="stylesheet" media="screen">
+ <link href="/css/prettify.css" rel="stylesheet" media="screen">
+ <link href="/css/code.css" rel="stylesheet" media="screen">
+ <script src="//code.jquery.com/jquery.js"></script>
+ <script src="/js/bootstrap.min.js"></script>
+ <script src="/js/prettify.js"></script>
+
+
+
+ <script>
+ $(function () { prettyPrint() })
+ $().dropdown()
+ </script>
+ </head>
+ <body style="padding-top: 50px;">
+ <div class="navbar navbar-fixed-top navbar-inverse">
+ <div class="navbar-inner">
+ <div class="container">
+ <a class="brand" href="/index.html">Apache ACE™</a>
+ <ul class="nav">
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">News <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a href="/news.html">News</a>
+ </li>
+ <li>
+ <a href="/on-the-web.html">On the web</a>
+ </li>
+ </ul>
+ </li>
+ <li>
+ <a href="/downloads.html">Downloads</a>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Users <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a href="/user-doc/introduction.html">Introduction</a>
+ </li>
+ <li>
+ <a href="/user-doc/getting-started.html">Getting Started</a>
+ </li>
+ <li>
+ <a href="/user-doc/user-guide.html">User Guide</a>
+ </li>
+ <li>
+ <a href="/user-doc/features.html">Features</a>
+ </li>
+ <li>
+ <a href="/user-doc/shellapi.html">Client Shell API</a>
+ </li>
+ <li>
+ <a href="/user-doc/restapi.html">Client REST API</a>
+ </li>
+ <li>
+ <a href="/user-doc/useradmin-ui.html">User Management Guide</a>
+ </li>
+ <li>
+ <a href="/user-doc/faq.html">FAQ</a>
+ </li>
+ <li>
+ <a href="/user-doc/support.html">Support</a>
+ </li>
+ </ul>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Developers <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a href="/dev-doc/getting-started.html">Getting Started</a>
+ </li>
+ <li>
+ <a href="/dev-doc/requirements/">Requirements</a>
+ </li>
+ <li>
+ <a href="/dev-doc/architecture.html">Architecture</a>
+ </li>
+ <li>
+ <a href="/dev-doc/analysis/">Analysis</a>
+ </li>
+ <li>
+ <a href="/dev-doc/design/">Design</a>
+ </li>
+ <li>
+ <a href="/dev-doc/coding-standards.html">Coding Standards</a>
+ </li>
+ <li>
+ <a href="/dev-doc/release-guide.html">Release Guide</a>
+ </li>
+ <li>
+ <a href="/dev-doc/writing-tests.html">Writing unit/integration
tests</a>
+ </li>
+ <li>
+ <a href="/dev-doc/adding-custom-artifact-types.html">Adding custom
artifact types</a>
+ </li>
+ <li>
+ <a href="/dev-doc/configuring-relay-servers.html">Configuring and
using relay servers</a>
+ </li>
+ </ul>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Get Involved <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a href="/get-involved/mailing-lists.html">Mailing Lists</a>
+ </li>
+ <li>
+ <a href="/get-involved/issue-tracking.html">Issue Tracking</a>
+ </li>
+ <li>
+ <a href="/get-involved/continuous-integration.html">Continuous
Integration</a>
+ </li>
+ <li>
+ <a href="/get-involved/source-code.html">Source Code</a>
+ </li>
+ <li>
+ <a href="/get-involved/project-team.html">Project Team</a>
+ </li>
+ </ul>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Wiki <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a
href="https://cwiki.apache.org/confluence/display/ACE/Board+Reports";>Board
Reports <i class="icon-share-alt"></i></a>
+ </li>
+ <li>
+ <a
href="https://cwiki.apache.org/confluence/display/ACE/Index";>Homepage <i
class="icon-share-alt"></i></a>
+ </li>
+ </ul>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Apache <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a href="http://www.apache.org/";>Apache Homepage <i
class="icon-share-alt"></i></a>
+ </li>
+ <li>
+ <a href="http://www.apache.org/licenses/";>Licenses <i
class="icon-share-alt"></i></a>
+ </li>
+ <li>
+ <a href="http://www.apache.org/security/";>Security <i
class="icon-share-alt"></i></a>
+ </li>
+ <li>
+ <a
href="http://www.apache.org/foundation/sponsorship.html";>Sponsorship <i
class="icon-share-alt"></i></a>
+ </li>
+ <li>
+ <a href="http://www.apache.org/foundation/thanks.html";>Thanks <i
class="icon-share-alt"></i></a>
+ </li>
+ </ul>
+ </li>
+</ul>
+
+ </div>
+ </div>
+ </div>
+ <div class="container">
+ <p><a href="/"><i class='icon-home'></i> Home</a> » <a
href="/docs/">Docs</a> » <a
href="/docs/analysis/">Analysis</a></p>
+ <h1>Template Mechanism</h1>
+ <div class="clear"></div>
+ <div id="content"><p>Some artifacts (see Object Graph in Client) can
need some customization before being provisioned, e.g. configuration files
might need some information that is managed by one of the distributions.</p>
+<p>The customization will be done when a new version is created, i.e., on call
of <code>approve()</code> on a StatefulTargetObject. A customized version of
the artifact (which is located somewhere in an OBR, reachable using a URL) is
uploaded to the same OBR, and the URL to the customized one is stored in the
DeploymentVersionObject.</p>
+<h1 id="proposed-design">Proposed design</h1>
+<p>In addition to the interfaces ArtifactHelper and ArtifactRecognizer, we
introduce a ArtifactPreprocessor, which has a single method
<code>preprocess(ArtifactObject object, Properties props)</code>, in which
Properties contains customization information (see below), and the method
returns the URL of the altered artifact (or, if nothing has changed, the
original artifact, or, if this changed artifact is identical to one that has
already been created before, that old URL). This ArtifactPreprocessor can be
published as a service (see the section on remoting below), but for local
purposes, the ArtifactHelper interface gets an extra method
<code>getPreprocessor()</code>, which returns an instance of the preprocessor
to be used for the type of artifact this helper helps.</p>
+<p>As an added service, we could create a basic preprocessor,
VelocityBasedPreprocessor which uses the Velocity template engine to process an
artifact and store it in a configured OBR; this preprocessor can be
instantiated and returned by each ArtifactHelper that needs a basic processor
(if no processing can be done for some type of artifact,
<code>getPreprocessor</code> should return null).</p>
+<h3 id="customization-information">Customization information</h3>
+<p>For each template that has 'holes' to fill in, it can 'reach' all
RepositoryObjects that are reachable from the TargetObject this template will
be provisioned to, leading to a tree of data. Inspired by Velocity's way of
finding contextual data, we propose to store the for each RepositoryObject in
its own Properties object, adding its attributes and tags to it as two
Properties objects using the keys "attributes" and "tags", and a
List<Properties> summing up all children (so, for a target, all its
distributions) using the key "children"; in the end, this becomes a tree of
Properties objects.</p>
+<p>This way, the Velocity template can use syntax like</p>
+<div class="codehilite"><pre><span class="c">#foreach( $license in
$gateway.children)</span>
+ <span class="c">#if
($license.attributes.vendor=="luminis")</span>
+ <span class="n">Default</span> <span class="nb">license</span> <span
class="n">by</span> <span class="n">luminis</span>
+ <span class="c">#else</span>
+ <span class="n">Custom</span> <span class="nb">license</span> <span
class="n">by</span> $<span class="nb">license</span><span
class="p">.</span><span class="n">attributes</span><span
class="p">.</span><span class="n">vendor</span>
+ <span class="c">#end</span>
+<span class="c">#end</span>
+</pre></div>
+
+
+<h3 id="support-for-remoting">Support for remoting</h3>
+<p>Some customers might want to keep all information hidden from us, only
allowing us the metadata on the server. In this case, we can deploy a
ArtifactPreprocessor on the customer's site, which is then responsible for
doing everything a local ArtifactPreprocessor can do, and returning a URL to
the altered artifact. Then, in stead of returning an instance of the
ArtifactPreprocessor, the ArtifactHelper will return some
RemoteArtifactPreprocessor which implements the ArtifactPreprocessor interface,
but talks to a servlet on the customer's server.</p>
+<h3 id="on-the-needsapprove-state-in-the-statefultargetobject">On the
'needsApprove' state in the StatefulTargetObject</h3>
+<p>With the mechanism above, <code>determineStoreState</code> in
StatefulTargetObject would need to create a full deployment version every time
we need to know whether approval is necessary. This is undesirable, because, in
a remoting scenario, it means we have to pass lots of data to a servlet,
oftentimes only to find out that we created a version identical to the one we
already had.
+So, in stead of this rigid semantics, the 'needsApprove' state will become
more of a 'tainted' state, which becomes true when something happens that could
have an impact on this StatefulTargetObject. We can quite easily determine what
targets are affected by a given change in the model by following the
associations from that object to the targets.</p></div>
+ <hr>
+ <footer>
+ <p>Copyright © 2012-2014 <a href="http://www.apache.org/";>The
Apache Software Foundation</a>, Licensed under the <a
href="http://www.apache.org/licenses/LICENSE-2.0";>Apache License, Version
2.0</a>.<br/>Apache ACE, the Apache ACE logo, Apache and the Apache feather
logo are trademarks of The Apache Software Foundation. All other marks
mentioned may be trademarks or registered trademarks of their respective
owners.</p>
+ </footer>
+ </div>
+ </body>
+</html>
Added: websites/staging/ace/trunk/content/docs/architecture.html
==============================================================================
--- websites/staging/ace/trunk/content/docs/architecture.html (added)
+++ websites/staging/ace/trunk/content/docs/architecture.html Mon Nov 24
22:42:13 2014
@@ -0,0 +1,280 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html lang="en">
+ <head>
+ <title>Architecture</title>
+ <meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
+ <meta property="og:image" content="//www.apache.org/images/asf_logo.gif" />
+ <link href="/css/bootstrap.min.css" rel="stylesheet" media="screen">
+ <link href="/css/prettify.css" rel="stylesheet" media="screen">
+ <link href="/css/code.css" rel="stylesheet" media="screen">
+ <script src="//code.jquery.com/jquery.js"></script>
+ <script src="/js/bootstrap.min.js"></script>
+ <script src="/js/prettify.js"></script>
+
+
+
+ <script>
+ $(function () { prettyPrint() })
+ $().dropdown()
+ </script>
+ </head>
+ <body style="padding-top: 50px;">
+ <div class="navbar navbar-fixed-top navbar-inverse">
+ <div class="navbar-inner">
+ <div class="container">
+ <a class="brand" href="/index.html">Apache ACE™</a>
+ <ul class="nav">
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">News <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a href="/news.html">News</a>
+ </li>
+ <li>
+ <a href="/on-the-web.html">On the web</a>
+ </li>
+ </ul>
+ </li>
+ <li>
+ <a href="/downloads.html">Downloads</a>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Users <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a href="/user-doc/introduction.html">Introduction</a>
+ </li>
+ <li>
+ <a href="/user-doc/getting-started.html">Getting Started</a>
+ </li>
+ <li>
+ <a href="/user-doc/user-guide.html">User Guide</a>
+ </li>
+ <li>
+ <a href="/user-doc/features.html">Features</a>
+ </li>
+ <li>
+ <a href="/user-doc/shellapi.html">Client Shell API</a>
+ </li>
+ <li>
+ <a href="/user-doc/restapi.html">Client REST API</a>
+ </li>
+ <li>
+ <a href="/user-doc/useradmin-ui.html">User Management Guide</a>
+ </li>
+ <li>
+ <a href="/user-doc/faq.html">FAQ</a>
+ </li>
+ <li>
+ <a href="/user-doc/support.html">Support</a>
+ </li>
+ </ul>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Developers <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a href="/dev-doc/getting-started.html">Getting Started</a>
+ </li>
+ <li>
+ <a href="/dev-doc/requirements/">Requirements</a>
+ </li>
+ <li>
+ <a href="/dev-doc/architecture.html">Architecture</a>
+ </li>
+ <li>
+ <a href="/dev-doc/analysis/">Analysis</a>
+ </li>
+ <li>
+ <a href="/dev-doc/design/">Design</a>
+ </li>
+ <li>
+ <a href="/dev-doc/coding-standards.html">Coding Standards</a>
+ </li>
+ <li>
+ <a href="/dev-doc/release-guide.html">Release Guide</a>
+ </li>
+ <li>
+ <a href="/dev-doc/writing-tests.html">Writing unit/integration
tests</a>
+ </li>
+ <li>
+ <a href="/dev-doc/adding-custom-artifact-types.html">Adding custom
artifact types</a>
+ </li>
+ <li>
+ <a href="/dev-doc/configuring-relay-servers.html">Configuring and
using relay servers</a>
+ </li>
+ </ul>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Get Involved <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a href="/get-involved/mailing-lists.html">Mailing Lists</a>
+ </li>
+ <li>
+ <a href="/get-involved/issue-tracking.html">Issue Tracking</a>
+ </li>
+ <li>
+ <a href="/get-involved/continuous-integration.html">Continuous
Integration</a>
+ </li>
+ <li>
+ <a href="/get-involved/source-code.html">Source Code</a>
+ </li>
+ <li>
+ <a href="/get-involved/project-team.html">Project Team</a>
+ </li>
+ </ul>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Wiki <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a
href="https://cwiki.apache.org/confluence/display/ACE/Board+Reports";>Board
Reports <i class="icon-share-alt"></i></a>
+ </li>
+ <li>
+ <a
href="https://cwiki.apache.org/confluence/display/ACE/Index";>Homepage <i
class="icon-share-alt"></i></a>
+ </li>
+ </ul>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Apache <b
class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li>
+ <a href="http://www.apache.org/";>Apache Homepage <i
class="icon-share-alt"></i></a>
+ </li>
+ <li>
+ <a href="http://www.apache.org/licenses/";>Licenses <i
class="icon-share-alt"></i></a>
+ </li>
+ <li>
+ <a href="http://www.apache.org/security/";>Security <i
class="icon-share-alt"></i></a>
+ </li>
+ <li>
+ <a
href="http://www.apache.org/foundation/sponsorship.html";>Sponsorship <i
class="icon-share-alt"></i></a>
+ </li>
+ <li>
+ <a href="http://www.apache.org/foundation/thanks.html";>Thanks <i
class="icon-share-alt"></i></a>
+ </li>
+ </ul>
+ </li>
+</ul>
+
+ </div>
+ </div>
+ </div>
+ <div class="container">
+ <p><a href="/"><i class='icon-home'></i> Home</a> » <a
href="/docs/">Docs</a></p>
+ <h1>Architecture</h1>
+ <div class="clear"></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-2014 <a href="http://www.apache.org/";>The
Apache Software Foundation</a>, Licensed under the <a
href="http://www.apache.org/licenses/LICENSE-2.0";>Apache License, Version
2.0</a>.<br/>Apache ACE, the Apache ACE logo, Apache and the Apache feather
logo are trademarks of The Apache Software Foundation. All other marks
mentioned may be trademarks or registered trademarks of their respective
owners.</p>
+ </footer>
+ </div>
+ </body>
+</html>
Added: websites/staging/ace/trunk/content/docs/auth_api.svg
==============================================================================
Binary file - no diff available.
Propchange: websites/staging/ace/trunk/content/docs/auth_api.svg
------------------------------------------------------------------------------
svn:mime-type = image/svg+xml
Added: websites/staging/ace/trunk/content/docs/auth_connectionfactory.svg
==============================================================================
Binary file - no diff available.
Propchange: websites/staging/ace/trunk/content/docs/auth_connectionfactory.svg
------------------------------------------------------------------------------
svn:mime-type = image/svg+xml
Added: websites/staging/ace/trunk/content/docs/auth_main_components.svg
==============================================================================
Binary file - no diff available.
Propchange: websites/staging/ace/trunk/content/docs/auth_main_components.svg
------------------------------------------------------------------------------
svn:mime-type = image/svg+xml
