## 7 Repository Implementation  
Our proposals for implementation of the hybrid SIEM data repository are, firstly, the recommendations on the choice of DBMS. In order to choose DBMS for the repository, we investigated a set of relational databases, XML-based databases, and triplet stores. A _triple store_ is a purpose-built database for the storage and retrieval of RDF metadata [27]. A _triple_ is a short formal statement in the form of \"subject-predicate-object\". Of course, traditional and popular relational DBMS (such as MySQL and PostgreSQL) together with XML-based DBMS can be used, but for the realization of an ontology-based SIEM, which includes advanced possibilities for logical reasoning, the triplet stores are preferable. The storage of triplets can be divided into two basic groups [28]:  
* implemented as standalone solutions (AllegroGraph, BigOWLIM and PelletDb) and
* parts of complex enterprise semantic system stores (Virtuoso, OpenAnzo and Semantics.Server). Our analysis shows that the most preferable solution is the Virtuoso by the OpenLink Software Company [29]. It is a very powerful Enterprise-product, which has a free version and combines the support of all three types of storages that implements all necessary languages and protocols for data access and also supports a variety of necessary drivers. Also it supports such frameworks as Jena, Sesame, _etc._ Jena is a java framework for building semantic web applications. Sesame is an open source framework for processing RDF data [30]. For these reasons as the best practical solution for the ontological data storage we proposed to combine the storage of triplets and the relational databases. This provides a balance in the flexibility of data manipulation, the effective use of metadata and the acceptable processing speed. For relational databases we choose Derby and Virtuoso. Derby is used for storing events and alarms, and Virtuoso--for other security information. The implementation of the Web services was made in Java. All Web services are implemented as stateless, _i.e._, services do not share among themselves any variables and objects. This allows running the request from the client in a single thread on the application server. Thus, a single service can handle multiple threads of the same instances of classes. As we decided to use a hybrid repository, a part of web services was developed for relational data representation, and the other part--for ontological one. The primary protocol we used for interaction is SOAP. The implemented structure of the data repository is presented in Figure 8. It consists of several program modules. The _Authorization_ module is responsible for authorization of the client queries that manipulate data. The _WS.Repository_ component implements the application business logic and provides interaction between other modules. The _Data Model_ module is generated on the basis of the data types defined in the corresponding _XSD-document_. It presents data base entities as Java classes. The _Data Access Object (DAO)_ module translates client queries into queries in database specific language (SQL or SPARQL). The _Web Services Description Language (WSDL) document_ contains the description of the web-services implemented in the data repository. Figure 9 illustrates the UML sequence diagram of the repository. It shows interactions occurring when the user requests data stored in the repository. The user initiates interaction by sending request _SelectData()_. This request is processed by the _Autorization_ module, which sends the _AuthorizationRequest()_ backward to the user. If the client has permissions to get access to the requested data, his/her query _SelectData()_ is transferred to the _WS.Repository_ module. The _WS.Repository_ processes the query according to the predefined logic and gives it further to the _DAO_ module. The _DAO_ module translates the query into _SQL_ or _SPARQL_ queries. The choice of the language is determined by the type of the repository the query is addressed.