removed some textbf

document/chapters/chapter_1/sections/4_how_to_convince_device_owners.tex

@@ -2,7 +2,7 @@ \section{How to convince device owners}
 Since this work assumes the voluntary contribution to the Grid by users, said people have to be convinced to participate in the project; alternatively, as much as the project allows to reach a great level of scalability, without any physical machines, no tasks can be performed, making it useless. This section discusses ways and prerequisites to incentivize users to participate in the dynamically allocated Grid.
 
 \subsection{Zero-effort configuration}
-In order to \textbf{reduce as much as possible the barrier of the active effort needed to participate in the Grid}, users should be presented with a configuration as easy as possible, especially considering that the vast majority of users do not want to be bothered with technical details. \textbf{The goal is possibly to just require an initial guided installation} (using easy to access methods such as applications stores and executables) \textbf{and then never require direct input from the contributor}.
+In order to \textbf{reduce as much as possible the barrier of the active effort} needed to participate in the Grid, users should be presented with a configuration as easy as possible, especially considering that the vast majority of users do not want to be bothered with technical details. The goal is possibly to just \textbf{require an initial guided installation} (using easy to access methods such as applications stores and executables) \textbf{and then never require direct input from the contributor}.
 
 While the \textbf{possibility of partially customizing the setup} must be offered, it should be \textbf{as minimal and easy as possible}, offering possibilities like enabling/disabling participation while using mobile data, while the device is alimented using only the battery and possibly a scheduling, depending on the time of the day. 
 
@@ -22,4 +22,4 @@ \subsection{Security and privacy}
 \subsection{Fair share business model}\label{fair_share_business_model}
 \textbf{Contributors} to the Grid must be \textbf{economically rewarded in order to be incentivized to offer their devices} to the project. Hence, a \textbf{fair share business model} will be useful to this purpose: \textbf{users receive a fraction of the earnings} obtained by the payments of the requestors of Grid services; \textbf{the reward is proportional to the contribution made by the device} that participated to offer the requested service.
 
-\textbf{This business model allows the owners of the Grid to make a profit} (while needing only to sustain the costs of the machines used to connect the machines of the requestors and the nodes of the Grid) \textbf{while also rewarding contributors of the Grid} for the usage of their computational resources (while not needing an active effort other than the initial setup).
+This business model allows the owners of the Grid to make a profit (while needing only to sustain the costs of the machines used to connect the machines of the requestors and the nodes of the Grid) while also rewarding contributors of the Grid for the usage of their computational resources (while not needing an active effort other than the initial setup).

document/chapters/chapter_2/sections/1_layered_grid_architecture.tex

@@ -28,7 +28,7 @@ \subsection{Fabric layer}
 \noindent This is the layer that \textbf{implements the local, resource-specific operations that occur on specific resources} (whether physical or logical) \textbf{as a result of sharing operations at higher levels}. The external access to such resources is mediated by protocols defined in the Grid, while \textbf{the internal workings of this layer depend on the specific implementation that runs on a machine}; this organization results in a relatively tight interdependence between the operations defined in this layer and the operations defined in higher layers.
 \vspace{30mm}
 
-\textbf{Operations in this layer should be as simple and minimal as possible in order to easily extend compatibility with as many devices as possible}; said operations must involve:
+\textbf{Operations in this layer should be as simple and minimal as possible in order to easily extend compatibility} with as many devices as possible; said operations must involve:
 \begin{itemize}
     \item \textbf{Enquiry functions}\\
     Allow to discover the Node inside the Grid, as well as describe its resources and status. Resources description provides info about software and hardware capabilities, while status handling offers mechanisms to enquire current load and queue state.

document/chapters/chapter_4/sections/1_grid_computing_evolution_approach_benefits.tex

@@ -38,14 +38,14 @@ \subsection{Low infrastructural costs: Volunteer computing philosophy}\label{low
     This category comprehends the actual machines (Computers, Smartphones and Tablets) that cooperate in order to execute the services provided by the Grid. Since the devices are owned and used by the Volunteers, the vast majority of the costs associated with said devices are demanded to them. Said costs are represented mainly by the device maintenance, the electricity needed to make them work, and the Internet traffic generated; but, as discussed in \textit{sections \ref{mobile_users_common_behavior} and \ref{economically_sustainable_internet_connections}}, these costs will be sustained by the Volunteer anyway (especially in the case of mobile devices), regardless contributing to the Grid or not. Furthermore, the Volunteer receives a compensation for its contribution (\textit{section \ref{fair_share_business_model}}), making it actually convenient for them to contribute.
 \end{itemize}
 
-On a final note, \textbf{this approach also has a positive effect on the environment}: the vastly diffused Cloud model results in a great consumption of electricity to run the dedicated machines composing the infrastructure; on the other hand, \textbf{demanding the execution of software into Volunteer machines} (that would be turned on anyway) \textbf{reduces the environmental impact derived by the electricity consumption}.
+On a final note, this approach also has a positive effect on the environment: the vastly diffused Cloud model results in a great consumption of electricity to run the dedicated machines composing the infrastructure; on the other hand, \textbf{demanding the execution of software into Volunteer machines} (that would be turned on anyway) \textbf{reduces the environmental impact derived by the electricity consumption}.
 
 \subsection{Removing the complexity: broader contributing user base}
 Although \textbf{Volunteer computing} has been a concept for many years, \textbf{the volunteering was typically done by people with relative confidence in using technology}, in particular (necessarily) computers.
 
-It is not uncommon that the typical computer user, for example, does not have the knowledge (or the confidence) to find and launch a Windows installer or, even worse, install a program from an integrated manager on any Linux distribution. But, \textbf{as technology increased in diffusion, in recent years a broader audience has become familiar with the concept of installing Apps through the use of a store} (mainly the App Store and the Play Store), \textbf{making it easier to reach new users}. Using such established means of distribution makes it \textbf{realistic to also reach potential Volunteers that mainly use mobile devices and may not have the technological skills to contribute using a computer}. Furthermore, the "store" approach on mobile devices has \textbf{recently generated similar stores on the desktop OSes thus} \textbf{creating a new simplified distribution medium} (even if still not vastly used today).
+It is not uncommon that the typical computer user, for example, does not have the knowledge (or the confidence) to find and launch a Windows installer or, even worse, install a program from an integrated manager on any Linux distribution. But, as technology increased in diffusion, \textbf{in recent years a broader audience has become familiar with the concept of installing Apps through the use of a store} (mainly the App Store and the Play Store), \textbf{making it easier to reach new users}. Using such established means of distribution makes it \textbf{realistic to also reach potential Volunteers that mainly use mobile devices} and may not have the technological skills to contribute using a computer. Furthermore, the "store" approach on mobile devices has recently generated similar stores on the desktop OSes thus creating a \textbf{new simplified distribution medium} (even if still not vastly used today).
 
-But, even if the first barrier on reaching users is removed, it is important to keep in mind the \textbf{simplicity principle} behind the idea, ensuring that the \textbf{Volunteer has to perform a setup as easy and guided as possible in order to configure its device once and then never have to do that again}.
+But, even if the first barrier on reaching users is removed, it is important to keep in mind the \textbf{simplicity principle} behind the idea, ensuring that the Volunteer has to perform a \textbf{setup as easy and guided as possible} in order to \textbf{configure its device once and then never have to do that again}.
 
 \subsection{Toward ubiquitous computing: Grid services for all devices}\label{grid_services_for_all_devices}
 The "\textbf{\textit{heterogeneous}}" \textbf{keyword} in the solution's name \textbf{refers not only to the possibility of using a multitude of different devices in order to contribute to the Grid, but it also includes the feature of accessing Grid's services from computers as well as smartphones and tablets}.
@@ -57,12 +57,12 @@ \subsection{Toward ubiquitous computing: Grid services for all devices}\label{gr
 \subsection{Cheaper access to Cloud services: Grid services for everyone}\label{cheaper_access_to_cloud_services}
 \textbf{As a result of having broad compatibility for devices' contribution} (\textit{section \ref{transparent_heterogeneous_devices_more_contribution}}) \textbf{and low infrastructural costs} (\textit{section \ref{low_infrastructural_costs_volunteer_computing_philosophy}}), \textbf{the cost of accessing to the Grid services} (that can be seen as Cloud computing services from the customer point of view) \textbf{becomes cheaper} than utilizing other platforms that run their infrastructures hosting their private machines.
 
-\textbf{Realistically, performances of services ran on Grid computing systems will be slightly worse compared to services that host their dedicated machines}; this is mainly because of the potential faults arising from the less stable connection of the devices. \textbf{Nonetheless, this is a highly viable and much cheaper alternative in domains where performances are not a highly strict requirement and a little delay can be accepted, opening the possibility of using such services also to entities that do not have a lot of financial resources}.
+\textbf{Realistically, performances of services ran on Grid computing systems will be slightly worse compared to services that host their dedicated machines}; this is mainly because of the potential faults arising from the less stable connection of the devices. \textbf{Nonetheless, this is a highly viable and much cheaper alternative in domains where performances are not a highly strict requirement} and a little delay can be accepted, opening the possibility of using such services also to entities that do not have a lot of financial resources.
 
 \vspace{10mm}
 Expanding the considerations seen up until now, \textbf{the Grid owners get value and a revenue from the Customers that}, at the same time, \textbf{save money accessing cheaper services}. \textbf{On the Volunteer side, there is a compensation} for doing absolutely nothing more than easily configuring a device once \textbf{and the environment is less impacted} while still performing advanced computations. In conclusion, \textbf{everyone wins}. 
 
 \subsection{Anticipating market trends: current devices' panorama}
 As discussed in \textit{section \ref{from_pdas_to_smartphones}}, \textbf{the current market trend shows how computer sales are decreasing} and, as experts say \cite{smartphones_sales}, this trends is not expected to reverse. In light of these considerations, \textbf{as the number of computers decreases while other devices increase} (mainly mobile), \textbf{it becomes increasingly important to think computational solutions around devices that will actually be used}.
 
-\textbf{The solution proposed}, although already relevant, \textbf{progressively increases its significance with time with the gradual but inevitable global shift of device types composition}.
+The solution proposed, although already relevant, progressively increases its significance with time with the gradual but inevitable global shift of device types composition.

document/chapters/chapter_4/sections/2_solution_analysis.tex

@@ -122,9 +122,9 @@ \subsection{Requirements: MoSCoW Prioritization}
     \item \textbf{Could have}
     \item \textbf{Won't have}
 \end{itemize}
-Other than priority, \textbf{this methodology focuses also on the concept of release}, aiming to use an \textbf{evolutionary approach}; this means that \textbf{for a first production release it is not necessary to satisfy all requirements but just the one with higher priority} (Must have), leaving the \textbf{satisfaction of the remaining requirements to subsequent versions} (always trying to first satisfy remaining requirements with the highest priority).
+Other than priority, this methodology focuses also on the concept of release, aiming to use an \textbf{evolutionary approach}; this means that \textbf{for a first production release it is not necessary to satisfy all requirements but just the one with higher priority} (Must have), leaving the satisfaction of the remaining requirements to subsequent versions (always trying to first satisfy remaining requirements with the highest priority).
 
-Requirements in this list are \textbf{also divided in three areas}: \textbf{Contributor, Customer and Grid Owner}; \textbf{the last area} in particular (which was not included in the use cases) \textbf{is introduced to assign tasks that are more technical in nature but are necessary to the success of the project}, both in the short term (first working release) and in the long term (easily introduce new features) \textbf{given the particular technical nature of this Domain}.
+Requirements in this list are also divided in \textbf{three areas}: \textbf{Contributor, Customer and Grid Owner}; \textbf{the last area} in particular (which was not included in the use cases) \textbf{is introduced to assign tasks that are more technical in nature but are necessary to the success of the project}, both in the short term (first working release) and in the long term (easily introduce new features) given the particular technical nature of this Domain.
 
 \subsubsection{Must have}
 All the requirements that are necessary for the successful completion of a first working production release.
@@ -136,6 +136,7 @@ \subsubsection{Must have}
         \item The Contributor must be able to register to the Grid system in order to uniquely identify Contributions performed by its Contributing Endpoints.
         \item Once authenticated to a Contributing Endpoint, the Contributor must not be requested to authenticate again unless it is absolutely necessary.
     \end{itemize}
+    \vspace{5mm}
     \item \textbf{Contribution}
     \begin{itemize}
         \item It must be possible to Contribute to the Grid using a Contributing Endpoint running on any device among Computers, Smartphones and Tablets running the most popular respective Operative Systems.

document/chapters/chapter_5/sections/1_architecture.tex

@@ -159,11 +159,11 @@ \subsection{Customer area}\label{customer_area}
 \end{figure}
 
 \subsubsection{Invoking Endpoint}
-The Invoking Endpoint is \textbf{the main software entity used by the Customer to perform Grid Services Invocations}. It is a \textbf{library}, developed by the Grid Owner, that can be \textbf{integrated as a dependency and utilized into any software solution through the use of the exposed SDK}; in particular, an application utilizing an Invoking Endpoint is identified as Customer Custom Application.
+The Invoking Endpoint is the \textbf{main software entity used by the Customer to perform Grid Services Invocations}. It is a \textbf{library}, developed by the Grid Owner, that can be \textbf{integrated as a dependency and utilized into any software solution through the use of the exposed SDK}; in particular, an application utilizing an Invoking Endpoint is identified as Customer Custom Application.
 
 \textbf{Many Invoking Endpoint implementations can exist}, depending on the target execution environment and which Grid Services that specific Invoking Endpoint wants to grant access to (a Customer may want to use only a certain type of Grid Service); \textbf{the requirement for any Invoking Endpoint is}, in order to connect to a Node in a Grid Service Invocation, \textbf{to conform to the communication interfaces belonging to the Grid Services which is interested to use}.
 
-\textbf{An Invoking Endpoint} (after being authenticated through the Authentication Service) \textbf{contacts the Grid Services Gateway Service in order to request a Service Invocation and}, as a consequence of that, \textbf{creates a connection to the provided Node}(s). In order to grant the possibility of Grid Services invocation from low-spec devices, \textbf{the Invoking Endpoint needs just to perform a lightweight coordination of the Resources obtained while the computationally demanding work is executed by the Nodes connected}; \textbf{if the coordination is too complex and demanding to realistically be executed from any device, the Invoking Endpoint just connects to a Node which actually performs the coordination}: an example of such occurrence is the MapReduce Service where the MapReduce Master is the one performing the coordination of Map Workers and Reduce Workers while the Invoking Endpoint is only connected to the MapReduce Master.
+An Invoking Endpoint (after being authenticated through the Authentication Service) contacts the Grid Services Gateway Service in order to request a Service Invocation and, as a consequence of that, creates a connection to the provided Node(s). In order to grant the possibility of Grid Services invocation from low-spec devices, \textbf{the Invoking Endpoint needs just to perform a lightweight coordination of the Resources obtained while the computationally demanding work is executed by the Nodes connected}; if the coordination is too complex and demanding to realistically be executed from any device, the Invoking Endpoint just connects to a Node which actually performs the coordination: an example of such occurrence is the MapReduce Service where the MapReduce Master is the one performing the coordination of Map Workers and Reduce Workers while the Invoking Endpoint is only connected to the MapReduce Master.
 
 \subsubsection{Customer Custom Application}
 \textbf{An application utilizing the Invoking Endpoint}. It is \textbf{developed by the Customer} and \textbf{utilizes Grid Services} (offered by the Invoking Endpoint) in order to build complex behaviors that are dependent on the application's domain.