Return-Path: X-Original-To: apmail-ace-commits-archive@www.apache.org Delivered-To: apmail-ace-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 2ACB79822 for ; Thu, 29 Mar 2012 16:40:00 +0000 (UTC) Received: (qmail 80492 invoked by uid 500); 29 Mar 2012 16:40:00 -0000 Delivered-To: apmail-ace-commits-archive@ace.apache.org Received: (qmail 80471 invoked by uid 500); 29 Mar 2012 16:40:00 -0000 Mailing-List: contact commits-help@ace.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ace.apache.org Delivered-To: mailing list commits@ace.apache.org Received: (qmail 80463 invoked by uid 99); 29 Mar 2012 16:40:00 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Mar 2012 16:40:00 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO eris.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Mar 2012 16:39:57 +0000 Received: from eris.apache.org (localhost [127.0.0.1]) by eris.apache.org (Postfix) with ESMTP id C786D23889BF for ; Thu, 29 Mar 2012 16:39:35 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r810561 - in /websites/staging/ace/trunk/content: ./ dev-doc/design/remote-interfaces.html Date: Thu, 29 Mar 2012 16:39:35 -0000 To: commits@ace.apache.org From: buildbot@apache.org X-Mailer: svnmailer-1.0.8-patched Message-Id: <20120329163935.C786D23889BF@eris.apache.org> 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 @@

The design is split into three components:

-
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.
+
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.
-
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.
+
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.
-
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.
+
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.

Process View

@@ -178,10 +178,10 @@

Use Case Design

There are two major use cases that are designed explicitly here:

Register Connector Services
Invoke Operation
UC-RI-1 Register Connector Services
UC-RI-2 Invoke Operation

Register Connector Services

UC-RI-1 Register Connector Services

Normal Flow

A component registers a service in the OSGi service registry.
The protocol adapter hands over the service to a protocol specific factory that creates an adapter.
The protocol adapter registers the created adapter with the protocol implementation.

Invoke Operation

UC-RI-2 Invoke Operation

Normal Flow

An actor invokes an operation on a service.