\section{Case Study} \label{Case}

We developed a case study in order to validate our approach. 
For that, we explore a DB system, that makes part of a SOA application, implemented into the scope of this work. This application represents a real process, currently used in practice by Brazilian government for the issuance and the management of electronic invoices. 
It was necessary to propose our own implementation due to the impossibility of accessing the real DB, from the federal agency, since the stored data are confidential. 

Even so, our application covers the usual SOA features, since its workflow is orchestrated by using BPEL language \cite{BPEL}, its services are deployed on remote servers and interfaced with external users, through the World Wide Web. 
These users order different types of distributed operations, generating a random system workload. 
The developed SOA process is depicted in Fig.~\ref{imgUML}. 
%###################################
\begin{figure}[h]
         \centering
         \includegraphics[height=4.4cm, width=15.5cm]{IMG/UML.png}
         \caption{Activity Diagram of Evaluated Process}
         \label{imgUML}
\end{figure}
%###################################
 
Basically, for each finalized sell, a commercial invoice is transmitted in parallel toward a regional and national web services. 
For now, our scope covers the regional operations, although it could involve additional web services (reason for the notation $i$, in the proposed model). 
The {\em Evaluation zone} contains the DB system that receives the regional transactions. 
After recording each remittance and replying a response message, the merchandises are released to transport or transfer.

Otherwise, if the request does not respond timely, according to the SLA definitions, a contingency operation is invoked. 
In this case, the overall system response time tends to be increased, disagreements with service commitment are susceptible to occur and the data security is affected, since the remittance must be retransmitted posteriorly. 
Besides this, any problem delaying the process directly affects customers and/or inspection agencies, that usually are waiting for the invoices validation.

For these reasons, it is essential that a contractual structure is preventing eventual service interruptions or even delays longer than the expected to answer, defining the penalties for possible interventions of the contingency solution. 
By providing juridical validity for web electronic transactions, it is reasonable to supply technological support for the lawyer's minds.

Our goal, in this paper, is focused on investigating how to establish and accomplish legal rules for SOA DB transactions. 
For the described process, we estimate the mean spent time for receiving a response from the invoices transmitters and its degradation insofar as the workload increases. 
It helps to acquire and provide electronic DB operations with QoS guarantees. 
Moreover, it avoids to develop a SOA system and, only then, to observe unexpected low performances, which certainly has already consumed money, time, employees, etc. 



\subsection{Database Structure and Primary Measurements}\label{parameters}

We are interested on to estimate the performance of DB requests, through using the proposed GSPN model. But this model receives a set of input parameters, obtained from the DB system. 
So, for the particular case, the DB structure was built over a {\em Java DB} technology \cite{DBJava}, such that the experiments posteriorly performed, require only partially its relations, involving the following tables:
\begin{itemize}
    \item {\em Products}: containing more than $700$ records;
    \item {\em Clients}: with more than $500$ records;
    \item {\em Invoices}: currently, it includes more than $10.000$ received records;
    \item {\em MovInvoices}: it also contains more than $10.000$ records. 
\end{itemize}

In the sequence, is presented an example of a problem, whose solution is achieved through bringing information from the DB recorded data.

\begin{problem}\label{SQL}
Given the previously described DB system, implement a query that returns all the clients and their respective negotiated invoices, admitting the following requirements:\\
(i)  the merchandises were already shipped;\\
(ii) the deadline for the payment is in, at most, one month.\\
Besides this, sort the results by the invoice deadline.
\end{problem}

Let us assume the following SQL query, in order to resolve problem \ref{SQL}:
\begin{verse}\label{Code}
{\em select *\\
from 
CLIENTS, 
INVOICES, 
MOV\_INVOICES, 
PRODUCTS\\
where INVOICES.Clients\_IdClient~~~~~~{\large~}~~~~~=~CLIENTS.idClients\\ 
and INVOICES.IdInvoices~~~~~~~~~~~~~~~{\footnotesize~}~~~~~~~=~MOV\_INVOICES.Invoices\_IdInvoices\\ 
and MOV\_INVOICES.Products\_IdProducts~=~PRODUCTS.IdProduct\\ 
and INVOICES.Shipment\_Date~~~~~~~~~~~~~~<= 'Informed current date'\\
and INVOICES.Deadline~~~~~~~~~~~~~~{\tiny~}~~~~~~~~<= 'Informed Limit date for payment'\\
%and INVOICES.Shipment\_Date 					<= '2011-01-01 00:00:00.0'\\
%and INVOICES.Deadline 							<= '2011-02-01 00:00:00.0'\\
order by INVOICES.Deadline
}
\end{verse}

By the sake of convenience, we are evaluating a single query, although it does not make difference if considering more than one. 
Actually, by receiving a set of initial measurements and DBMS parameters, issues involving DB technology, type of performed operation, access policies, etc., are irrelevant for the estimates, since they are absorbed by each particular set of collected parameters. 
It enables us to generically apply our proposal over any size and type of DB and different operation as well, without compromising its accuracy. 

Then, using the proposed code, we obtain the parameters to feed the GSPN model, by collecting the DB statistics when answering the mentioned query. 
Through JMeter tool \cite{JMeter2011}\footnote{{\em JMeter}: an Apache software, designed mainly to workload generation and performance evaluation of several types of structures, as Web Applications and Database systems. JMeter supports working with protocols such HTTP, FTP and SOAP, JUnit tests and XML packages building;}, we build a test plan that performs it repeatedly. 

In JMeter, we gradually increase the workload of requests. 
However, notice that the model input parameters, should not include queue time. 
This is part of the dynamic system behavior and should be estimated through subsequent simulations. 
Instead, when measuring, we impose the highest possible workload level, before observing evidences of queue appearing in the system. 
It is detected by a perceptible increases of the response time, when the workload overcome the systems resources. 
Hence, we collected the parameters presented in Table \ref{tab:InputParameters}, complemented by those information from the DBMS. 
\begin{table}[h]
\centering
\caption{Model Input Parameters.}
\begin{tabular}{|c|c|c|c|c|c|c|c|} \hline
\multicolumn{ 8}{|c|}{{\bf Type of collected Parameter}} \\ \hline \hline
\multicolumn{ 2}{|c|}{{\bf DBMS Configuration}} & 
\multicolumn{ 3}{|c|}{{\bf Buffering}} &
\multicolumn{ 3}{|c|}{{\bf Processing}}\\ \hline
$NMP$ 		& $SMP$ 				& $\#R_i$ (bytes) 	& $Get\_R_i$ 		& $Put\_R_i$	& 
$\#K_i$ (req) 		& $Get\_K_i$ 		& $Put\_K_i$	 		\\ \hline
$1000$ 	& $4(KB) = 4096(B)$ & $4096000$ 			& $1022$ 			& $1022$  		&    
$2$ 					& $1$ 				& $1$  \\ \hline
\end{tabular}  
\label{tab:InputParameters}
\end{table}
 
First two columns bring the DBMS configuration parameters, where $NMP$ represents the number of memory pages available for database operations, whose size\footnote{The used DB automatically tunes the database page size, although it can be changed.} is defined by $SMP$. 

Columns labeled {\em Buffering}, show the input and output queue resources, responsible for storing the database requests before and after their execution, which is supplied by the parameters presented in {\em Processing} columns.
For clarifying the notations meaning, see the model description in Section \ref{Model}. 

The presented parameters are not the only ones necessary for allowing the GSPN simulations. 
A probability function must be also defined, as discussed in the following.



\subsection{Establishing and Feeding the PMF}\label{PMF}

Assuming the proposed GSPN topology for performance evaluation of DB systems (see Fig. \ref{imgDBModel}), notice that input and output memory spaces (places $QI_i$ and $QO_i$) mediate the access to the DB core $S_i$. 
These buffers express the DB extra-execution spent time.% and, in general, their parameters may be defined through measurements and according to the BD devices configuration.

Modeling the DB processing time, however, requires to chose a PMF that better fits with the real system behavior. 
This decision is made during the initial measurements, when the model input parameters are being collected. 
Once chosen, the same PMF can be used along all the simulation process, since it should stochastically follow the changes of the DB dynamic behavior. 

The calculation of an appropriate PMF, requires the average - $\mu$ and standard deviation - $\sigma$ of the DB requests response time. 
Usually, these metrics are only defined after collecting a set of DB transactions, containing an enough number of samples that allows observing a tendency to a stationary behavior. 

For the particular case, for example, when JMeter was requesting around the hundredth sample, it was already possible to observe a stationary condition. 
Then, the values assigned for $\mu$ and $\sigma$ are those from (a) and (b) as below. 
Equation (c) defines how establishing the coefficient of variation - $\Pi$, with result in (d):
$$
(a)~~ \mu = 36;~~~~~~~~ (b)~~ \sigma = 17;~~~~~~~~ (c)~~\Pi = \frac{\sigma}{\mu}; ~~~~~~~~ (d)~~\Pi = 0,47.
$$

Depending on the value assumed by $\Pi$, one can identify the appropriated PMF that would better represent each type of stochastic process. 
For the particular example, $\Pi = 0,47$. 
Then, as discussed in Section \ref{Distrib}, whenever $\Pi < 1$ it is suggested adopting a Hypo-exponential distribution, whose structure is depicted in Fig.~\ref{imgHipo}. Therefore, this GSPN block takes the place of the gray box in the initial model, presented in Section \ref{Model}, Fig.~\ref{imgDBModel}. 
%###################################
\begin{figure}[h]
         \centering
         \includegraphics[height=3.2cm, width=12cm]{IMG/Model/DBHipo.png}
         \caption{Adopted Hypo-exponential distribution}
         \label{imgHipo}
\end{figure}
%################################### 

A Hypo-exponential probability function matches Exponential and Erlang distributions. 
In fact, $T\lambda_1$ represents an exponential approximation, while $T\lambda_2$ maps an Erlang distribution, since the $\gamma$ parameter is used as a sequencer of Exponential triggers, both with delay $d_\lambda 2$. 

Supported by the formulation discussed in Section \ref{Distrib} and variables $\mu$ and $\sigma$ previously presented, we establish the Hypo-exponential parameters, as follows:
$$
d_\lambda 1 = 12; ~~~~~~~~~~~~~~~~~~
d_\lambda 2 = 23; ~~~~~~~~~~~~~~~~~~
\gamma = 3.
$$

At this moment we have the necessary informations to proceed with the GSPN simulations, providing organizational informations and planning SLA for DB transactions, as discussed in the following. 


\subsection{Defining SLA clauses for DB systems}\label{questions}

Let us start supposing usual situations, faced when defining SLA clauses for SOA-based systems. 
Assuming, for example, that it is necessary to answer the following question. 

{\em Question $1$:}
{\em For the particular DB system discussed in this section, let $W$ be a predefined workload level of requests arriving at DB server (requests per second). 
Which SLA, for the DB mean response time, could be guaranteed in practice$?$}

In this case, a typical range of workload levels (variating $W$) is known, but the response times for the DB requests under these workloads, are quite variables and difficult to predict.

In a similar way, let us suppose that a performance engineer is challenged to answer the following question, to the company's legal department, in order to elaborate contractual partnership clauses.

{\em Question $2$:}
{\em For the same discussed DB system, let $RT$ be an established SLA for the response time (in milliseconds) of a particular DB operation. 
Which SLA, for the higher supported workload, could be guaranteed in practice, such that the mentioned $RT$ is not exceeded$?$}

In this case, the service supplier is committed to deliver each request with response time no less than the clause $RT$. But, certainly, the $RT$ degrades when the workload increases and, in SOA, it is unexpected. So, it is essential to know which number of requests per second could be received by the application, such that $RT$ is kept on track in the SLA. 

The capability for answering questions $1$ and $2$ is one of the keys for elaborating realistic and safer service contracts. 
In practice, it is difficult to find ways to do so. 
Usually, the performance engineer waits for the system implementation and, then, for historical execution traces in order to supply those information and, finally, the lawyers could plan appropriated SLA. 
It really could take years. 
In the following we present an alternative to quickly and efficiently answer these questions. 


\subsection{Model Simulations}

We use the statistical data from Table \ref{tab:InputParameters} and the PMF parameters previously discussed, to feed the input structures of the GSPN depicted in Fig.~\ref{imgDBModel}.
As output, we intend to estimate the DB variable behavior, including queue occupation, processing performance degradation and so on, when increasing the workload level of requests. 
For that, we conduct GSPN simulations using {\em TimeNet} tool\footnote{{\em TimeNet - Timed Net Evaluation Tool} is a software for the modeling and analysis of stochastic Petri nets with non-exponentially distributed firing times.} \cite{Timenet2011}, considering a confidence level in 95\% and relative error of 10\%. 

For the sake of convenience, we establish the workload levels (in requests per second - {\em req/sec}), to be used during the experiments. 
We start by applying $1$ req/sec and gradually increase until achieving $10$ req/sec. 
After that, we turn to increase it from $10$ to $10$, until $50$. 
Finally, in order to verify the accuracy of the proposed approach under a more extreme variability condition, we simulate the model by applying $100$ req/sec.

We also measure the implemented DB system, with the purpose of comparing the collected real samples, against the estimates provided by our model. This comparative analysis represents a way to validate our approach. 
The workloads levels used for simulations and measurements were the same and the obtained results are presented in Table \ref{Comparison}.

\begin{table}[h]
\centering
\caption{Comparison between Simulated and Measured Response Times}
\begin{tabular}{|r|r|r|r|r|r|r|r|r|r|r|r|r|r|r|} \hline
%\multicolumn{ 15}{|c|}{{\bf {\em Delay $d\lambda_i$, assigned to the timed Transition $T\lambda_i$ %(Fig.~\ref{imgDBModel})}}} \\ \hline
%$1000$ & $500$ & $333$ & $250$ & $200$ & $167$ & $143$ & $125$ & $111$ & $100$ & $50$ & $33$ & $25$ & %$20$ & $10$ 
%\\ \hline

\multicolumn{ 15}{|c|}{{\bf {\em Applied Workload Level (req/sec)}}} \\ \hline
$1$ & $2$ & $3$ & $4$ & $5$ & $6$ & $7$ & $8$ & $9$ & $10$ & $20$ & $30$ & $40$ & $50$ & $100$ \\ 
\hline \hline
%\multicolumn{ 15}{|c|}{{\bf {\em Estimated Response Times -  ms}}} \\ \hline
%$58$ & $119$ & $177$ & $291$ & $340$ & $414$ & $510$ & $653$ & $778$ & $943$ & $1178$ & $1589$ & $2167$ & %$3842$ & $8156$ \\ \hline
%\multicolumn{ 15}{|c|}{{\bf {\em Measured Response Times -  ms}}} \\ \hline
%$36$ & $80$ & $200$ & $251$ & $377$ & $463$ & $564$ & $675$ & $835$ & $923$ & $1616$ & $2219$ & $3514$ & %$4436$ & $9083$ \\ \hline
%   \multicolumn{ 15}{|c|}{{\bf {\em Closeness Percentage between Estimations and Measurements}}} \\ %\hline
%$62\%$ & $67\%$ & $89\%$ & $86\%$ & $90\%$ & $89\%$ & $90\%$ & $97\%$ & $93\%$ & $98\%$ & $73\%$ & $72\%$ %& $62\%$ & $85\%$ & $90\%$ \\ \hline

\multicolumn{ 15}{|c|}{{\bf {\em Estimated Response Time (s)}}} \\ \hline
$0,06$ & $0,12$ & $0,18$ & $0,29$ & $0,34$ & $0,41$ & $0,51$ & $0,65$ & $0,78$ & $0,94$ & $1,18$ & $1,59$ & $2,17$ & $3,84$ & $8,16$ \\ \hline
\multicolumn{ 15}{|c|}{{\bf {\em Measured Response Time (s)}}} \\ \hline
$0,04$ & $0,08$ & $0,20$ & $0,25$ & $0,38$ & $0,46$ & $0,56$ & $0,68$ & $0,84$ & $0,92$ & $1,62$ & $2,22$ & $3,51$ & $4,50$ & $9,08$ \\ 
\hline \hline
   \multicolumn{ 15}{|c|}{{\bf {\em Closeness Percentage between Estimations and Measurements}}} \\ \hline
$62\%$ & $67\%$ & $89\%$ & $86\%$ & $90\%$ & $89\%$ & $90\%$ & $97\%$ & $93\%$ & $98\%$ & $73\%$ & $72\%$ & $62\%$ & $85\%$ & $90\%$ \\ \hline

\end{tabular}  
\label{Comparison}
\end{table}

First line presents the workload level (number of requests per second) applied on the experiments, which is achieved by properly variating the delay $d\lambda_i$ of the timed transition $T\lambda_i$ in the GSPN model. 
{\em Estimated} and {\em Measured} response times, bring the results achieved by simulating the proposed model and by measuring the real DB system, respectively.

\subsubsection{Discussing the achieved results} 
As can be seen, according to the workload increases, the system becomes less deterministic due to presence of queues. Nevertheless, the response times calculated through the proposed approach, maintain their accuracy in relation to the measures taken from the real DB application, whose percentage may be checked in the last line ({\em Closeness Percentage}). 
Fig.~\ref{graph1} helps to graphically analyze the results from Table \ref{Comparison}. 
%###################################
\begin{figure}[h]
         \centering
         \includegraphics[height=4.3cm, width=12cm]{IMG/GraphPerformance_I.png}
         \caption{Analysis of the Measured and Estimated Database Behaviors}
         \label{graph1}
\end{figure}
%###################################  

Firstly, let us discuss the statistics from the first ten levels of workload, which were increased individually. 
A comparison between estimated and measured results, as presented in Fig.~\ref{graph1}, leads us to recognize that our approach remains close to the measured samples, whatever the existent variability. 
For these results, the accuracy is on the order of $86\%$. 
We also graphically analyze the Table \ref{Comparison} as a whole, as shows Fig.~\ref{graph2}.
%###################################
\begin{figure}[h]
         \centering
         \includegraphics[height=4.5cm, width=12cm]{IMG/GraphPerformance_New.png}
         \caption{General Closeness between Measured and Estimated Response Times}
         \label{graph2}
\end{figure}
%###################################  

One can observe that, even increasing the workload, our estimates follow the behavior of the real measurements, which indicates that a more extreme variability does not affect our predictions. 
In a general case, the closeness observed between measured and estimated results is on the order of $83\%$, which certainly is reasonable from a stochastic point of view. 
It is also essential to notice that, for several times, the curves tend to intercept to each other. This fact indicates that nowhere our model lost the tracing of the real evaluated behavior.

\subsection{Composing the SLA}

Given the SLA requirements, defined in the subsection \ref{questions}, it is opportune to analyze the range of information available for answering the questions $1$ and $2$, after obtained the results from Table \ref{Comparison}. 

For question $1$, let us suppose that we know the mean workload usually imposed to the system. Let us assume $W=50$, for example. 
It is easy to note that for this workload level, the DB system would take $4436~ms$ to reply each request, while we have estimated a response time of $3842~ms$. 
Although we have not provided an exact estimative, which was not our proposal, certainly it contributes for the SLA planning since, in practice, this difference should be absorbed by an usual adopted margin of error. Moreover, our estimative is on the order of $85\%$ closed with the measured sample, which surely is stochastically acceptable.

In a inverse way, suppose that we know the minimum response time for each DB requests, which is defined in SLA, as introduced by question $2$. 
So, let us assume $RT = 900~ms$, for instance. 
It is expected to establish a SLA for the maximum supported workload, such that the $RT$ is not exceeded. 
According to the Table \ref{Comparison}, it is easy to show that $9$ req/sec is the higher supported workload that satisfies the assumed assumptions. 
The estimated mean response time, in this case, is $778~ms$ while the measured one is $835~ms$, with accuracy between them on the order of $93\%$.

%We have shown only two examples of how using the proposed model could help to compose accurate SLA clauses. 
 
