ViewVC logotype

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

Parent Directory Parent Directory | Revision Log Revision Log

Revision 938 - (show annotations) (download) (as text)
Fri Oct 16 13:54:56 2009 UTC (12 years, 11 months ago) by aramv
File MIME type: text/x-latex
File size: 7961 byte(s)
Fixed a few more things pointed out by Oscar
1 \chapter{The Execution Environment Service}
2 %The
3 % TODO
4 % 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 \cite{authzinterop} requests.
7 \section{Requirements}
8 \subsection{Functional requirements}
9 The EES should \ldots
10 \begin{itemize}
11 \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}
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)
21 \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}
26 % Moet de mogelijkheid hebben om low-level OS interacties te kunnen doen
29 \section{Design considerations}
30 % TODO verwerken van requirements in deze tekst
31 Because backward-compatibility with existing deployment schemes must be maintained, the most logical choice is to build upon existing code.
32 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.
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.
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.
43 %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.
45 %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.
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)
52 \glossary{name={EES}, description={Execution Environment Service}}
53 \nomenclature{EES}{Execution Environment Service}
55 \section{Proposed architecture for the EES}
56 The core component of the \textit{Execution Environment Service} (EES) is a shared library that exposes the core logic, dubbed the \textit{EES Execution Framework} (EEF).
57 \glossary{name={EEF}, description={EES Execution Framework}}
58 \nomenclature{EEF}{EES Execution Framework}
60 The EES provides access to the EEF through various mechanisms, called \textit{EES Interfaces} (EI's), which are implemented as \textit{EES Interface Components} (EIC's).
62 These EIC's can be implemented as (for example):
63 \begin{itemize}
64 \item An HTTP(S) socket
65 \item A Unix domain socket
66 \item A named pipe
67 \end{itemize}
69 Multiple interaction mechanisms must be supported so that many kinds of internal and external services can interact with the EES.
70 Requests travel from these EIC's through the EEF framework to plug-ins, that do the actual work.
71 This design was chosen to clearly separate the roles of the EEF and the EIC's, thereby encapsulating the core logic away from disparate interfaces.
72 %redenen voor deze EIC's.
73 % meerdere interaces zodat allerlei soorten services ermee kunnen functioneren (intern en extern)
75 % Vanaf de EIC's ga je door de EEF heen naar de plug-ins.
77 \glossary{name={EIC}, description={EES Interface Component}}
78 \nomenclature{EIC}{EES Interface Component}
80 Besides using these EIC's a direct API invocation of the EEF is also possible.
83 % EEF is agnostisch, dom ding. Daarom geschikt om pluggable te maken.
85 %\begin{figure}[hp]
86 %\centering
87 %\includegraphics[width=\textwidth]{ees_class_diagram}
88 %\caption[Pseudo-class diagram of the EES execution framework]%
89 %{Pseudo-class diagram of the EES Execution Framework, which shows the different files associated with different roles in the design.}
90 %\end{figure}
93 Please see appendix \ref{ees_class_diagram} for a diagram showing the architecture of the EES, which also describes the EEF components.
95 \section{Proposed components of the EEF}
97 \subsection{Evaluation Manager (EM)}
98 \glossary{name={EM}, description={Evaluation Manager}}
99 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.
101 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.
103 After the configuration has been successfully parsed the Plug-in Manager can be used to load the specified plug-ins.
105 \subsection{Plug-in Manager (PM)}
106 \glossary{name={PM}, description={Plug-in Manager}}
107 \nomenclature{PM}{Plug-in Manager}
108 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.
111 % TODO hoe en waarom
113 \subsection{Attribute and Obligation Store (AOS)}
114 \glossary{name={AOS}, description={Attribute \& Obligation Store}}
115 \nomenclature{AOS}{Attribute \& Obligation Store}
116 The \textit{Attribute and Obligation Store} is used to store and exchange data between plug-ins.
117 %Data can be retrieved from the AOS by its label through getter functions which return type-casted results.
118 %This way, a crude mechanism for dynamic typing has been implemented.
119 Each data element should be uniquely identified through a label, and hold a copy of the supplied data in memory.
120 Plug-ins should not be able to overwrite or delete each other's data.
121 %Ownership of the stored data could be established through the memory address of the setting plug-in.
122 % TODO stating the rules is not a motivation for its design
124 %\subsection{Tools}
125 %At least some logging /debugging functionality should be implemented.
127 \pagebreak
128 \section{Life-cycle of an EEF run}
129 \begin{itemize}
130 % open logfile, AOS init, eef_run voor request
131 \item The EEF is invoked with a string containing a path to the LCMAPS-compatible policy description file.
132 \item To enable plug-ins to exchange information while being executed consecutively the AOS is initialized by the EEF
133 \item The EEF then invokes the Evaluation Manager to parse the supplied policy file, which performs some error-checking to assert the policy file has parseable syntax and will not create recursions
134 \item If all is well the Evaluation Manager then loads and initializes the specified plug-ins by making calls to the Plug-in Manager
135 \item If all the plug-ins have been successfully loaded they are ready to be executed by a call to the EEF
136 \end{itemize}
137 %TODO hier wordt het juist interessant
138 % Beschrijf:
139 % state-machine
140 % AOS interactie
141 % afhandeling van failure mbt AOS state
142 % cleanup & terminate van alle plug-ins
144 Please see appendix \ref{ees_sequence_diagram} for a sequence diagram of the EEF.

ViewVC Help
Powered by ViewVC 1.1.28