Difference between revisions of "ESciDoc Admin"

From MPDLMediaWiki
Jump to navigation Jump to search
(part of wording changed (in sync with agreed wording with FIZ))
Line 1: Line 1:
== Overview ==
== Overview ==


''eSciDoc admin'' is a a solution for the management of master data in an installation of the eSciDoc framework. Currently it is implemented as TurboGears web application talking to the framework's REST interface.
''eSciDoc admin'' is a a solution for the management of master data in an installation of the eSciDoc core services. Currently it is implemented as TurboGears web application talking to the core services REST interfaces.


It implements (parts of) the use cases specified in
It implements (parts of) the use cases specified in
Line 41: Line 41:
You need to supply some basic configuration settings for the application by adding the following lines to the ''global'' section of the configuration file.
You need to supply some basic configuration settings for the application by adding the following lines to the ''global'' section of the configuration file.


Configure the framework to which to talk
Configure the core services instance to which to talk


   framework.host="host[:port]"
   framework.host="host[:port]"
Line 74: Line 74:
=== Overview ===
=== Overview ===


''eSciDoc admin'' manages framework resources of the following kinds:
''eSciDoc admin'' manages resources of the following kinds:


*Organizational Units, abbreviated ''ou'',
*Organizational Units, abbreviated ''ou'',
Line 83: Line 83:
=== Architecture ===
=== Architecture ===


''eSciDoc admin'' - as a web interface to the framework's CRUD services for its resources - has a very simple architecture:
''eSciDoc admin'' - as a web interface to the resource handler services that support resource CRUD operations - has a very simple architecture:


*All communication with the framework is implemented in a [https://subversion1.escidoc.mpg.de/admin/trunk/escidocadmin/escidocadmin/lib/framework/ framework client library]
*All communication with the core services resource handlers is implemented in a [https://subversion1.escidoc.mpg.de/admin/trunk/escidocadmin/escidocadmin/lib/framework/ core services client library]
*As a !TurboGears aplication, ''escidocadmin'' subscribes to the MVC pattern, or better the VC pattern, because the persistence layer is implemented by the framework.
*As a !TurboGears aplication, ''escidocadmin'' subscribes to the MVC pattern, or better the VC pattern, because the persistence layer is implemented by the framework.
*The management logic for each resource is implemented in one [https://subversion1.escidoc.mpg.de/admin/trunk/escidocadmin/escidocadmin/controllers/ controller class].
*The management logic for each resource is implemented in one [https://subversion1.escidoc.mpg.de/admin/trunk/escidocadmin/escidocadmin/controllers/ controller class].
Line 91: Line 91:




==== Framework Client Library ====
==== Core services Client Library ====


The [https://subversion1.escidoc.mpg.de/admin/trunk/escidocadmin/escidocadmin/lib/framework/ framework client library] provides a [https://subversion1.escidoc.mpg.de/admin/trunk/escidocadmin/escidocadmin/lib/framework/client.py client class] which mediates access to a framework installation much like a database connection mediates access to a database.
The [https://subversion1.escidoc.mpg.de/admin/trunk/escidocadmin/escidocadmin/lib/framework/ core services client library] provides a [https://subversion1.escidoc.mpg.de/admin/trunk/escidocadmin/escidocadmin/lib/framework/client.py client class] which mediates access to a core services installation much like a database connection mediates access to a database.


Since resources are transferred between framework and client as xml representations, the client library  treats [https://subversion1.escidoc.mpg.de/admin/trunk/escidocadmin/escidocadmin/lib/framework/resource.py resources] basically as (wrapped) xml dom objects (more precisely as [http://docs.python.org/lib/module-xml.etree.ElementTree.html etree.Element] instances). A ''Resource'' instance is initialized with an appropriate ''Element'' of a parsed framework response, and can be serialized for passing it back to the framework.
Since resources are transferred between core service resource handlers and clients as xml representations, the client library  treats [https://subversion1.escidoc.mpg.de/admin/trunk/escidocadmin/escidocadmin/lib/framework/resource.py resources] basically as (wrapped) xml dom objects (more precisely as [http://docs.python.org/lib/module-xml.etree.ElementTree.html etree.Element] instances). A ''Resource'' instance is initialized with an appropriate ''Element'' of a parsed core service resource handler response, and can be serialized for passing it back to the core service resource handler.


==== User Management ====
==== User Management ====


''eSciDoc admin'' uses framework user accounts to access the framework. After successful authentication with the external identity provider the admin application receives a token which is subsequently used to authenticate requests to the framework (see [https://subversion1.escidoc.mpg.de/admin/trunk/escidocadmin/escidocadmin/controllers/root.py ''login_finish'']).
''eSciDoc admin'' uses eSciDoc user accounts to access the core services resource handlers. After successful authentication with the external identity provider the admin application receives a token which is subsequently used to authenticate requests to the core service resource handlers (see [https://subversion1.escidoc.mpg.de/admin/trunk/escidocadmin/escidocadmin/controllers/root.py ''login_finish'']).


[[Category:ESciDoc]]
[[Category:ESciDoc]]
[[Category:ESciDoc-Team]]
[[Category:ESciDoc-Team]]

Revision as of 21:40, 8 June 2008

Overview[edit]

eSciDoc admin is a a solution for the management of master data in an installation of the eSciDoc core services. Currently it is implemented as TurboGears web application talking to the core services REST interfaces.

It implements (parts of) the use cases specified in

Repository URL: https://subversion1.escidoc.mpg.de/admin/


Installation/Deployment[edit]

Requirements[edit]

Download[edit]

You may download the application as egg appropriate for your architecture:

TODO


Or run eSciDoc admin from a repository checkout: run

 svn co https://subversion1.escidoc.mpg.de/admin/trunk/escidocadmin

in a suitable directory.


Deployment[edit]

Configuration[edit]

You need to supply some basic configuration settings for the application by adding the following lines to the global section of the configuration file.

Configure the core services instance to which to talk

 framework.host="host[:port]"

and a default user account to use

 framework.user="username"
 framework.password="password"

When deploying the web application behind a proxy (e.g. apache), make sure to set

 server.webpath="http://your.domain/escidoc/admin/path/"


Controlling the Application[edit]

You may use the start-escidocadmin.py script to start the application from the commandline.


Running eSciDoc admin behind Apache HTTPD[edit]

To run eSciDoc admin behind Apache HTTPD add the following to your apache configuration:

 RewriteRule ^/escidoc/admin/path/(.*) http://127.0.0.1:8080/$1 [proxy,L]
 <Location /escidoc/admin/path>
   Order allow,deny
   Allow from all
 </Location>

Technical Documentation[edit]

Overview[edit]

eSciDoc admin manages resources of the following kinds:

  • Organizational Units, abbreviated ou,
  • Contexts, abbreviated ctx,
  • User Accounts (and Grants), subsumed under aa (for authentication and authorization).


Architecture[edit]

eSciDoc admin - as a web interface to the resource handler services that support resource CRUD operations - has a very simple architecture:

  • All communication with the core services resource handlers is implemented in a core services client library
  • As a !TurboGears aplication, escidocadmin subscribes to the MVC pattern, or better the VC pattern, because the persistence layer is implemented by the framework.
  • The management logic for each resource is implemented in one controller class.
  • The views for each resource are implemented in one (or several) templates.


Core services Client Library[edit]

The core services client library provides a client class which mediates access to a core services installation much like a database connection mediates access to a database.

Since resources are transferred between core service resource handlers and clients as xml representations, the client library treats resources basically as (wrapped) xml dom objects (more precisely as etree.Element instances). A Resource instance is initialized with an appropriate Element of a parsed core service resource handler response, and can be serialized for passing it back to the core service resource handler.

User Management[edit]

eSciDoc admin uses eSciDoc user accounts to access the core services resource handlers. After successful authentication with the external identity provider the admin application receives a token which is subsequently used to authenticate requests to the core service resource handlers (see login_finish).