Difference between revisions of "Common Libraries Specification"
Manuele.simi (Talk | contribs) (→Architecture) |
Manuele.simi (Talk | contribs) (→Architecture) |
||
| Line 30: | Line 30: | ||
* '''common-ghn-client''': a client container that discovers and manages an open-ended set of facilities on client nodes (we call them client services) | * '''common-ghn-client''': a client container that discovers and manages an open-ended set of facilities on client nodes (we call them client services) | ||
* '''common-ghn-client-proxy''': key client service in the client container. installs an embedded HTTP proxy that intercepts client calls in full transparency from client code | * '''common-ghn-client-proxy''': key client service in the client container. installs an embedded HTTP proxy that intercepts client calls in full transparency from client code | ||
| − | * common-ghn-service: management facilities to manage HTTP services that run in a servlet container in full transparency from the services themselves | + | * '''common-ghn-service''': management facilities to manage HTTP services that run in a servlet container in full transparency from the services themselves |
* '''common-clients''': base framework for client library development, gCore-independent | * '''common-clients''': base framework for client library development, gCore-independent | ||
* '''common-gcore-clients''': gCore-bridge for common-clients | * '''common-gcore-clients''': gCore-bridge for common-clients | ||
| Line 37: | Line 37: | ||
* '''common-resource-publisher''': publishing of gCube resources according to the new Resource Model | * '''common-resource-publisher''': publishing of gCube resources according to the new Resource Model | ||
* '''common-resource-access''': discovery of gCube resources according to the new Resource Model | * '''common-resource-access''': discovery of gCube resources according to the new Resource Model | ||
| + | * '''common-utils-encryption''': encryption/decryption utilities to be exploited in the common-resources | ||
== Deployment == | == Deployment == | ||
Revision as of 14:19, 25 February 2012
Overview
A brief overview of the subsystem should be here. It should include the key features.
Key features
- Lightweight integration mechanisms with existing technologies
- ...
- Extensible Software Model
- ...
- Different level of engagements
- ...
- Encryption/decryption of resources
- ...
Design
Philosophy
This is the rationale behind the design. An example will be provided.
Architecture
- common-ghn-client: a client container that discovers and manages an open-ended set of facilities on client nodes (we call them client services)
- common-ghn-client-proxy: key client service in the client container. installs an embedded HTTP proxy that intercepts client calls in full transparency from client code
- common-ghn-service: management facilities to manage HTTP services that run in a servlet container in full transparency from the services themselves
- common-clients: base framework for client library development, gCore-independent
- common-gcore-clients: gCore-bridge for common-clients
- common-scope: scope and service map handling facilities
- common-resource: reference implementation of the new Resource Model
- common-resource-publisher: publishing of gCube resources according to the new Resource Model
- common-resource-access: discovery of gCube resources according to the new Resource Model
- common-utils-encryption: encryption/decryption utilities to be exploited in the common-resources
Deployment
Usually, a subsystem consists of a number of number of components. This section describes the setting governing components deployment, e.g. the hardware components where software components are expected to be deployed. In particular, two deployment scenarios should be discussed, i.e. Large deployment and Small deployment if appropriate. If it not appropriate, one deployment diagram has to be produced.
Large deployment
A deployment diagram suggesting the deployment schema that maximizes scalability should be described here.
Small deployment
A deployment diagram suggesting the "minimal" deployment schema should be described here.
Use Cases
The subsystem has been conceived to support a number of use cases moreover it will be used to serve a number of scenarios. This area will collect these "success stories".
Well suited Use Cases
Describe here scenarios where the subsystem proves to outperform other approaches.
Less well suited Use Cases
Describe here scenarios where the subsystem partially satisfied the expectations.
