You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@ace.apache.org by bu...@apache.org on 2014/11/24 23:42:14 UTC
svn commit: r930358 [3/10] - in /websites/staging/ace/trunk/content: ./
dev-doc/ docs/ docs/analysis/ docs/analysis/src/ docs/design/
docs/design/src/ docs/use-cases/ user-doc/
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