## 4 SARA: Main Characteristics and Architecture Components
### The Collaboration Services  
Collaboration Services comprise several services that allow to alter different characteristics of collaboration between users. The first service is the _Collaboration Model Manager (CMM)_. It stores information about the collaboration model associated with a certain _Session_. Each collaboration model has a set of associated rules. When the _Communication Service_ receives _any_ event, it is validated using the _CMM_. This validation is done by comparing the event against all the rules associated with the collaboration model. If the event goes through all of them, it is valid, so the content of the event may be applied. Otherwise, by default it is discarded but other policies could be implemented too. The _Conflict Manager Service_ has two main components, the _Conflict'Detector_ and the _Conflict Solver_. The first is in charge of detecting conflicts (such as two users applying updates concurrently or conflicts generated when applying the _CMM_). Once detected, the _Conflict Solver_ reacts to these conflicts and manages responses. For example, in the concurrent updates scenario, it can merge both events into a single one and send it to the _Communication Manager_ as solved. As the last component, the _Users Service_ offers functionality related with the user's data. It also has access to its own database and stores information such as hierarchies of users, which can be queried by the _CMM_. Additionally, this service offers functionality such as registers and removal of users, as well as logins and logouts. Thus, SARA wraps the minimum functionality required to enable the development and deployment of collaborative AR applications. Figure 6 illustrates the difference between the development of collaborative AR applications without using SARA and using it. As Figure 6 shows, when implementing collaborative AR applications without using SARA, the development of each new application is done independently of the others. Thus, the application logic should first be implemented for each of the platforms on top of which the application needs to run. For example, in case the objective is to create an application that initially provides support for HoloLens and iOS devices (i.e., Platform 1 and Platform 2), it is required to implement the logic in a dedicated application for each of them. If later it is needed to give support for Android systems, that same logic should be implemented for Android. Once the logic has been implemented, a communication server that allows the exchange of information between clients has to be implemented and configured. Some previous server structure could be reused here, but it should always be adapted. Once done, the message exchange protocol between the clients and the server needs to be defined and implemented, and this had to be done for all the platforms involved. Next, the graphical interfaces and interaction methods of each platform have to be created and tailored. Finally, the collaboration model needs to be be implemented from scratch, possibly within the application's own logic, which means that it cannot be easily reused. By using SARA, there are three blocks in which development is accelerated. First, SARA provides a _Communication Service_, which does not require any implementation and can be directly launched (with some minor configurations such as port information). Thus, it will accept client connections and handle the events broadcasting. Second, when developing the platform clients, SARA already provides an application skeleton that once imported, establishes the connection with the _Communication Service_ and receives/sends the session status. At this point it would only be  
Figure 6: Sequence diagram that illustrates the communication between users and the _Communication Service_. necessary to create the interfaces adapted to the application.