Author: marrs
Date: Thu Mar 29 16:39:22 2012
New Revision: 1306974
URL: http://svn.apache.org/viewvc?rev=1306974&view=rev
Log:
Small typographic changes. Numbered the use cases.
Modified:
ace/site/trunk/content/dev-doc/design/remote-interfaces.mdtext
Modified: ace/site/trunk/content/dev-doc/design/remote-interfaces.mdtext
URL:
http://svn.apache.org/viewvc/ace/site/trunk/content/dev-doc/design/remote-interfaces.mdtext?rev=1306974&r1=1306973&r2=1306974&view=diff
==============================================================================
--- ace/site/trunk/content/dev-doc/design/remote-interfaces.mdtext (original)
+++ ace/site/trunk/content/dev-doc/design/remote-interfaces.mdtext Thu Mar 29
16:39:22 2012
@@ -22,11 +22,11 @@ The design is based on the 4+1 View, whi
The design is split into three components:
-1. 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.
+1. *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.
-2. 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.
+2. *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.
-3. 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.
+3. *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
@@ -38,10 +38,10 @@ A session manager is allowed to spawn a
There are two major use cases that are designed explicitly here:
-1. Register Connector Services
-2. Invoke Operation
+1. UC-RI-1 Register Connector Services
+2. UC-RI-2 Invoke Operation
-#### Register Connector Services
+#### UC-RI-1 Register Connector Services
##### Normal Flow
@@ -50,7 +50,7 @@ There are two major use cases that are d
3. The protocol adapter hands over the service to a protocol specific factory
that creates an adapter.
4. The protocol adapter registers the created adapter with the protocol
implementation.
-#### Invoke Operation
+#### UC-RI-2 Invoke Operation
##### Normal Flow
