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 2012/03/29 18:39:35 UTC

svn commit: r810561 - in /websites/staging/ace/trunk/content: ./ dev-doc/design/remote-interfaces.html

Author: buildbot
Date: Thu Mar 29 16:39:35 2012
New Revision: 810561

Log:
Staging update by buildbot for ace

Modified:
    websites/staging/ace/trunk/content/   (props changed)
    websites/staging/ace/trunk/content/dev-doc/design/remote-interfaces.html

Propchange: websites/staging/ace/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Thu Mar 29 16:39:35 2012
@@ -1 +1 @@
-1306973
+1306974

Modified: websites/staging/ace/trunk/content/dev-doc/design/remote-interfaces.html
==============================================================================
--- websites/staging/ace/trunk/content/dev-doc/design/remote-interfaces.html (original)
+++ websites/staging/ace/trunk/content/dev-doc/design/remote-interfaces.html Thu Mar 29 16:39:35 2012
@@ -163,13 +163,13 @@
 <p>The design is split into three components:</p>
 <ol>
 <li>
-<p>Protocol Adapters. For every protocol that we support, we have to create a protocol adapter, whose responsibility it is to expose connector interfaces. Connectors are discovered by leveraging the service registry using the whiteboard pattern. The protocol adapter talks to the session manager for managing sessions and making sure certain permissions have been given to the authenticated user. If the protocol itself also supports the notion of sessions, it's the adapters responsibility to ensure that the life cycle of the protocol specific session is aligned with our own sessions.</p>
+<p><em>Protocol Adapters.</em> For every protocol that we support, we have to create a protocol adapter, whose responsibility it is to expose connector interfaces. Connectors are discovered by leveraging the service registry using the whiteboard pattern. The protocol adapter talks to the session manager for managing sessions and making sure certain permissions have been given to the authenticated user. If the protocol itself also supports the notion of sessions, it's the adapters responsibility to ensure that the life cycle of the protocol specific session is aligned with our own sessions.</p>
 </li>
 <li>
-<p>Connectors. Each connector, which is implemented as a collection of one or more OSGi services, provides a specific API to talk to a system. An example is the client API. Which services make up a connector is specified in the design of a component.</p>
+<p><em>Connectors.</em> Each connector, which is implemented as a collection of one or more OSGi services, provides a specific API to talk to a system. An example is the client API. Which services make up a connector is specified in the design of a component.</p>
 </li>
 <li>
-<p>Session Manager. Responsible for managing sessions and the authentication and authorization of actors that use them. The session manager will be invoked by protocol adapters. It leverages the OSGi User Admin service to provide users with credentials, roles and permissions. The session manager is allowed to expire sessions if it needs to, so protocol adapters should always check if a session is still open.</p>
+<p><em>Session Manager</em>. Responsible for managing sessions and the authentication and authorization of actors that use them. The session manager will be invoked by protocol adapters. It leverages the OSGi User Admin service to provide users with credentials, roles and permissions. The session manager is allowed to expire sessions if it needs to, so protocol adapters should always check if a session is still open.</p>
 </li>
 </ol>
 <h3 id="process-view">Process View</h3>
@@ -178,10 +178,10 @@
 <h3 id="use-case-design">Use Case Design</h3>
 <p>There are two major use cases that are designed explicitly here:</p>
 <ol>
-<li>Register Connector Services</li>
-<li>Invoke Operation</li>
+<li>UC-RI-1 Register Connector Services</li>
+<li>UC-RI-2 Invoke Operation</li>
 </ol>
-<h4 id="register-connector-services">Register Connector Services</h4>
+<h4 id="uc-ri-1-register-connector-services">UC-RI-1 Register Connector Services</h4>
 <h5 id="normal-flow">Normal Flow</h5>
 <ol>
 <li>A component registers a service in the OSGi service registry.</li>
@@ -189,7 +189,7 @@
 <li>The protocol adapter hands over the service to a protocol specific factory that creates an adapter.</li>
 <li>The protocol adapter registers the created adapter with the protocol implementation.</li>
 </ol>
-<h4 id="invoke-operation">Invoke Operation</h4>
+<h4 id="uc-ri-2-invoke-operation">UC-RI-2 Invoke Operation</h4>
 <h5 id="normal-flow_1">Normal Flow</h5>
 <ol>
 <li>An actor invokes an operation on a service.</li>