/[pdpsoft]/trunk/grid-mw-security/ees/thesis/ees.tex
ViewVC logotype

Diff of /trunk/grid-mw-security/ees/thesis/ees.tex

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 937 by aramv, Fri Oct 16 10:52:45 2009 UTC revision 938 by aramv, Fri Oct 16 13:54:56 2009 UTC
# Line 2  Line 2 
2  %The  %The
3  % TODO  % TODO
4  % introduction to EES  % introduction to EES
5  The role of the \textit{Execution Environment Service} is to ensure that an appropriate site-specific execution environment is procured based on the site-agnostic obligations and attributes it receives as input in the form of SAML2-XACML2 requests.  The role of the \textit{Execution Environment Service} is to ensure that an appropriate site-specific execution environment is procured based on the site-agnostic obligations and attributes it receives as input in the form of SAML2-XACML2 \cite{authzinterop} requests.
6    
7  \section{Requirements}  \section{Requirements}
8    \subsection{Functional requirements}
9  The EES should \ldots  The EES should \ldots
10  \begin{itemize}  \begin{itemize}
 \item have a rudimentary understanding of SAML2XACML2 concepts  
 \item provide a data store for generic and specialized data types  
 \item provide several external interfaces  
 \item provide a flexible plug-in API  
11  \item be easily adaptable to new use cases, such as those pertaining to virtualization frameworks or interactions with batch systems  \item be easily adaptable to new use cases, such as those pertaining to virtualization frameworks or interactions with batch systems
12    \item facilitate access from several external interfaces
13    \item provide a data store for generic and specialized data types
14    \item have a mechanism to work with SAML2-XACML2 concepts
15    \end{itemize}
16    
17    \subsection{Technical requirements}
18    The EES should \ldots
19    \begin{itemize}
20  \item be largely backward-compatible with existing deployment schemes (provided the required plug-ins are updated accordingly)  \item be largely backward-compatible with existing deployment schemes (provided the required plug-ins are updated accordingly)
 \item be portable to many different platforms  
21  \item be thread-safe  \item be thread-safe
22    \item be portable to many different platforms
23    \item should be able to interact with the OS on a low level
24    \item provide a flexible plug-in API
25  \end{itemize}  \end{itemize}
26  % Moet de mogelijkheid hebben om low-level OS interacties te kunnen doen  % Moet de mogelijkheid hebben om low-level OS interacties te kunnen doen
27    
# Line 25  Because backward-compatibility with exis Line 32  Because backward-compatibility with exis
32  The project can largely be based on LCMAPS, as it provides most of the functionality that will eventually be required in the EES.  The project can largely be based on LCMAPS, as it provides most of the functionality that will eventually be required in the EES.
33  However, due to the age and relative complexity of the LCMAPS codebase I have chosen to start this project from scratch, borrowing code where applicable.  However, due to the age and relative complexity of the LCMAPS codebase I have chosen to start this project from scratch, borrowing code where applicable.
34    
35    The previous middleware systems were created in the C programming language.
36    It makes sense to use C for the EES as well, as it is able to help satisfy most of the technical requirements.
37    
38    The first two functional requirements merit a structured approach to the design of the software.
39    In C, a pseudo-Object Oriented style of programming can be adapted by using structures as simple Objects.
40    This enables enforcing a strict separation and encapsulation of responsibilities.
41    
42    
43  %The EES should be a high-level shared object that enables LCMAPS-like functionality.  %The EES should be a high-level shared object that enables LCMAPS-like functionality.
44  Ideally, the EES should be agnostic about low-level Grid business logic; instead relying on configurable plug-in chains to perform this.  Ideally, the EES should be agnostic about low-level Grid business logic; instead relying on configurable plug-in chains to perform this.
45  %This design requires a clear and concise API, most notably for plug-ins.  %This design requires a clear and concise API, most notably for plug-ins.
46    To ensure thread-safety, it should be possible to initialize a separate data store for each request.
47  To ease the creation of services that access the core functionality, I was advised to create a library that exposes it.  To ease the creation of services that access the core functionality, I was advised to create a library that exposes it.
48    This has the added benefit of separating the core logic of the service from the interface components.
49  % Maken van kleine, aan elkaar geknoopte dingetjes in C is minder verneukeratief (functie scheiding)  % Maken van kleine, aan elkaar geknoopte dingetjes in C is minder verneukeratief (functie scheiding)
50    
51    
# Line 79  Please see appendix \ref{ees_class_diagr Line 96  Please see appendix \ref{ees_class_diagr
96    
97  \subsection{Evaluation Manager (EM)}  \subsection{Evaluation Manager (EM)}
98  \glossary{name={EM}, description={Evaluation Manager}}  \glossary{name={EM}, description={Evaluation Manager}}
99  The \textit{Evaluation Manager} parses the configuration file and load specified plug-ins.  The \textit{Evaluation Manager} parses the configuration file and loads specified plug-ins.
100  Once the plug-in descriptions have been initialized, the plug-in chains expressed in the configuration file should be created.  Once the plug-in descriptions have been initialized, the plug-in chains expressed in the configuration file should be created.
101  These chains serve to describe different paths to successful execution of the plug-ins, which might fail at any point in the chain.  These chains serve to describe different paths to successful execution of the plug-ins, which might fail at any point in the chain.
102  The configuration should be checked to avoid creating recursions in the policy chains.  The configuration should be checked to avoid creating recursions in the policy chains.
# Line 88  After the configuration has been success Line 105  After the configuration has been success
105  \subsection{Plug-in Manager (PM)}  \subsection{Plug-in Manager (PM)}
106  \glossary{name={PM}, description={Plug-in Manager}}  \glossary{name={PM}, description={Plug-in Manager}}
107  \nomenclature{PM}{Plug-in Manager}  \nomenclature{PM}{Plug-in Manager}
108  The Plug-in Manager maintains the list of plug-ins and is able to initialize, run and terminate them.  The Plug-in Manager builds and maintains a list of plug-ins and is able to initialize, run and terminate them.
109    The list is built up of structures that contain function pointers linked to functions in the actual plug-in.
110  It is controlled by the Evaluation Manager.  It is controlled by the Evaluation Manager.
111  % TODO hoe en waarom  % TODO hoe en waarom
112    

Legend:
Removed from v.937  
changed lines
  Added in v.938

grid.support@nikhef.nl
ViewVC Help
Powered by ViewVC 1.1.28