ViewVC logotype

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

Parent Directory Parent Directory | Revision Log Revision Log

Revision 946 - (show annotations) (download) (as text)
Tue Oct 20 12:26:31 2009 UTC (12 years, 3 months ago) by aramv
File MIME type: text/x-latex
File size: 13064 byte(s)
Latest additions
1 \chapter{The Execution Environment Service}
2 %The
3 % TODO ammend introduction
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 assertions it receives as input in the form of SAML2-XACML2 \cite{authzinterop} requests.
6 It provides functionality similar to the SCAS, but delegates the enforcement to the PEP.
8 % TODO quote "Description of the EES"
9 Here is a description of the EES taken from the document "Description of the EES" \cite{ees_design} for EGEE.
10 \begin{quote}
11 \textit{
12 From the ‘outside’ the EES appears as an ‘obligation transformer’.
13 It takes execution-agnostic assertions and obligations and makes sure that
14 \begin{itemize}
15 \item an execution environment compatible with these assertions and obligations is procured, e.g. by creating or leasing a Unix account;
16 \item new obligations are created that ensure that the policy enforcement points (PEP) can properly move the task into the procured execution environment;
17 \item removes any agnostic obligations that have been fully translated into a site-specific obligation, since the PEP has to be able to enforce all obligations present.
18 \end{itemize}
19 }
20 \end{quote}
22 \section{Requirements}
23 \subsection{Functional requirements}
24 The EES should \ldots
25 \begin{itemize}
26 \item be easily adaptable to new use cases, such as those pertaining to virtualization frameworks or interactions with batch systems
27 \item facilitate access from several external interfaces
28 \item provide a data store for generic and specialized data types
29 \item have a mechanism to work with SAML2-XACML2 concepts
30 \end{itemize}
32 \subsection{Technical requirements}
33 The EES should \ldots
34 \begin{itemize}
35 \item be largely backward-compatible with existing deployment schemes (provided the required plug-ins are updated accordingly)
36 \item be thread-safe
37 \item perform efficiently
38 \item be portable to many different platforms
39 \item be able to interact with the OS on a low level
40 \item provide a flexible plug-in API
41 \end{itemize}
42 % Moet de mogelijkheid hebben om low-level OS interacties te kunnen doen
45 \section{Design considerations}
46 % TODO verwerken van requirements in deze tekst
47 \subsection{Programming language}
48 %Since performance and portability are a requirement the best contenders are C and C++.
49 %For the pu
50 What follows is a comparison of some popular languages known to be able to meet most of the technical requirements.
51 %I have weighed the technical and functional requirements against the pro's and cons I associate with each language.
52 %Some parts of this project seem like they might benefit from an Object Oriented approach.
54 \subsubsection{Java}
55 Other services in the Argus framework have been implemented in Java, so it might be possible to share experiences and code.
56 %However, since SAML2XACML2 has been agreed upon as a standard in which to exchange information so this is not a necessity to use Java.
57 It is renowned for its portability.
58 Although its performance has greatly caught up with the other contenders over the past decade, it is likely to be less efficient at managing memory.
60 Pro's:
61 \begin{itemize}
62 \item Fully Object Oriented
63 \item Supposedly very portable
64 \end{itemize}
65 Cons:
66 \begin{itemize}
67 \item Not native, so hard to do low-level OS interaction
68 \item Likely to be a memory hog
69 %\item Hard to deploy stably
70 \end{itemize}
72 \subsubsection{C}
73 The previous middleware systems were created in C, which means there is code and experience at hand.
74 It is renowned for its performance.
75 While it does not natively provide any of the Object Oriented features the other languages do, a pseudo-OO style of programming can be adapted by using structures as simple Objects.
76 %Is a strong argument with regards to backward compatibility.
77 %This enables enforcing a strict separation and encapsulation of responsibilities.
78 %C is able to meet all of the technical requirements,
80 Pro's:
81 \begin{itemize}
82 \item Offers good low-level OS interaction
83 \item Can offer good overall performance on most architectures
84 \item Has proven to be very portable
85 \end{itemize}
86 Cons:
87 \begin{itemize}
88 \item Requires careful programming
89 \item Sometimes a bit too low-level
90 \end{itemize}
92 \subsubsection{C++}
93 C++ can provide more functionality than C at the cost of some overhead and being less portable.
94 It is renowned for its efficiency at dealing with large data structures.
95 %The modern language constructs in C++ can complicate a simple design, which leads to a variety of issues.
96 Some of the convenience provided by the use of the STL can lead to portability issues.
98 Pro's:
99 \begin{itemize}
100 \item Offers good low-level OS interaction
101 \item Can offer good overall performance on most architectures
102 \end{itemize}
103 Cons:
104 \begin{itemize}
105 \item Not as portable as C
106 \end{itemize}
108 \subsubsection{Choice}
109 The low-level OS interaction we seek is actually present in both C and C++.
110 I have chosen C because of the following reasons:
112 \begin{itemize}
113 \item Java seems to be the worst option since it abstracts the low-level OS interaction required, and does so at the cost of efficiency
114 \item While C++ allows programming in an Object Oriented style, it is much newer and thus not as portable
115 \item C can perform slightly better because the overhead of OO constructs can be omitted
116 \end{itemize}
118 \subsection{Implementation plan}
119 \subsubsection{Functionality}
120 To assure forward compatibility, the EES should be agnostic about low-level Grid business logic, instead relying on configurable plug-in chains to contain this.
121 This can be made more powerful by exposing an API which lets plug-ins exchange arbitrary information with each other through a data store.
123 By linking together small, maintainable plug-ins that can interact with the data store and perform a variety of tasks, the system can support many use cases.
124 The requirements allow the core of the EES to be almost completely oblivious to anything specifically Grid-related.
126 \subsubsection{Service programming}
127 Because multiple interfaces must be supported, it makes sense to encapsulate the core logic of the software apart from these interfaces.
128 Most of the implementation time will be spent on this core logic, allowing it to be incorporated into a service at a later time.
130 \subsubsection{Legacy code}
131 Some of the data structures and code from LCMAPS can be reused in the EES.
132 Reusing the configuration file parser can be a quick win.
134 \subsubsection{API's}
135 There are two kinds of API's that must be exposed from the core framework:
136 \begin{itemize}
137 \item An API for the interface components to interact with the core framework
138 \item An API for plug-ins to interact with the core framework and the outside world
139 \end{itemize}
141 The plug-in API is more important to get right, because more developers will be depending on it.
143 %This design requires a clear and concise API, most notably for plug-ins.
144 \subsubsection{Thread-safety}
145 To ensure thread-safety it should suffice to initialize a separate data store for each request, as this data is transient.
146 The rest of the configuration of the service is static.
147 %TODO tijd om te gaan slapen
148 %To ease the creation of services that access the core functionality, I was advised to create a library that exposes it.
149 %This has the added benefit of separating the core logic of the service from the interface components.
151 % Maken van kleine, aan elkaar geknoopte dingetjes in C is minder verneukeratief (functie scheiding)
153 %Particularly the parser
155 %The project can largely be based on LCMAPS, as it provides most of the functionality that will eventually be required in the EES.
156 %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.
160 \glossary{name={EES}, description={Execution Environment Service}}
161 \nomenclature{EES}{Execution Environment Service}
163 \section{Proposed architecture for the EES}
164 The core component of the \textit{Execution Environment Service} (EES) is a shared library that exposes the core logic, hereby dubbed the \textit{EES Execution Framework} (EEF).
165 \glossary{name={EEF}, description={EES Execution Framework}}
166 \nomenclature{EEF}{EES Execution Framework}
168 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).
170 These EIC's can be implemented as (for example):
171 \begin{itemize}
172 \item An HTTP(S) socket
173 \item A Unix domain socket
174 \item A named pipe
175 \end{itemize}
177 Multiple interaction mechanisms must be supported so that many kinds of internal and external services can interact with the EES.
178 Requests travel from these EIC's through the EEF framework to plug-ins, that do the actual work.
179 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.
180 %redenen voor deze EIC's.
181 % meerdere interaces zodat allerlei soorten services ermee kunnen functioneren (intern en extern)
183 % Vanaf de EIC's ga je door de EEF heen naar de plug-ins.
185 \glossary{name={EIC}, description={EES Interface Component}}
186 \nomenclature{EIC}{EES Interface Component}
188 Besides using these EIC's a direct API invocation of the EEF is also possible.
191 % EEF is agnostisch, dom ding. Daarom geschikt om pluggable te maken.
193 %\begin{figure}[hp]
194 %\centering
195 %\includegraphics[width=\textwidth]{ees_class_diagram}
196 %\caption[Pseudo-class diagram of the EES execution framework]%
197 %{Pseudo-class diagram of the EES Execution Framework, which shows the different files associated with different roles in the design.}
198 %\end{figure}
201 Please see appendix \ref{ees_class_diagram} for a diagram showing the architecture of the EES, which also describes the internal EEF components.
203 \section{Proposed components of the EEF}
205 \subsection{Evaluation Manager (EM)}
206 \glossary{name={EM}, description={Evaluation Manager}}
207 The \textit{Evaluation Manager} parses the configuration file and loads specified plug-ins.
208 Once the plug-in descriptions have been initialized, the plug-in chains expressed in the configuration file should be created.
209 These chains serve to describe different paths to successful execution of the plug-ins, which might fail at any point in the chain.
210 The configuration should be checked to avoid creating recursions in the policy chains.
211 After the configuration has been successfully parsed the Plug-in Manager can be used to loads the specified plug-ins.
213 \subsection{Plug-in Manager (PM)}
214 \glossary{name={PM}, description={Plug-in Manager}}
215 \nomenclature{PM}{Plug-in Manager}
216 The Plug-in Manager builds and maintains a list of plug-ins and is able to initialize, run and terminate them.
217 The list is built up of structures that contain function pointers linked to functions in the actual plug-in.
218 It is controlled by the Evaluation Manager.
219 % TODO hoe en waarom
221 \subsection{Attribute and Obligation Store (AOS)}
222 \glossary{name={AOS}, description={Attribute \& Obligation Store}}
223 \nomenclature{AOS}{Attribute \& Obligation Store}
224 The \textit{Attribute and Obligation Store} is used to store and exchange data between plug-ins.
225 %Data can be retrieved from the AOS by its label through getter functions which return type-casted results.
226 %This way, a crude mechanism for dynamic typing has been implemented.
227 Each data element should be uniquely identified through a label, and hold a copy of the supplied data in memory.
228 Plug-ins should not be able to overwrite or delete each other's data.
229 %Ownership of the stored data could be established through the memory address of the setting plug-in.
230 % TODO stating the rules is not a motivation for its design
232 %\subsection{Tools}
233 %At least some logging /debugging functionality should be implemented.
235 \pagebreak
236 \section{Life-cycle of an EEF run}
237 \begin{itemize}
238 % open logfile, AOS init, eef_run voor request
239 \item The EEF is invoked with a string containing a path to the LCMAPS-compatible policy description file.
240 \item To enable plug-ins to exchange information while being executed consecutively the AOS is initialized by the EEF
241 \item The EEF then invokes the Evaluation Manager to parse the supplied policy file, which creates a list of plug-in chains that can lead to successful execution.
242 \item The Evaluation Manager then loads and initializes the specified plug-ins by calling the Plug-in Manager
243 \item If all the plug-ins have been successfully loaded they are ready to be executed by a call to the EEF
244 \item Once a request comes in through an EIC, the SAML statements are parsed and loaded into the AOS
245 \item The policy chains loaded from the configuration file are run until one chain completes successfully
246 \item After completion, the result is returned to the EIC
247 \end{itemize}
249 %hier wordt het juist interessant
250 % Beschrijf:
251 % state-machine
252 % AOS interactie
253 % afhandeling van failure mbt AOS state
254 % cleanup & terminate van alle plug-ins
256 Please see appendix \ref{ees_sequence_diagram} for a sequence diagram of the EEF.

ViewVC Help
Powered by ViewVC 1.1.28