## 4 SERS Requirements
### Open Standards-Based Service-Oriented Architecture  
To facilitate the interaction between SERS and existing LMS a service-oriented architecture (SOA) is suitable. For instance, in the EU4 ALL project (IST-2006-034478) a SOA interoperates with a SERS to provide personalized and inclusive support in formal e-learning scenarios [22]. To clarify involved issues, in this section the EU4 ALL SOA components that are required to support the recommendation functionality to be provided by the SERS are described. Figure1 presents the operation flow among the components involved in the process of delivering the recommendations. It shows the web services (WSDL based) exchanged that relate to the recommendation process. In order to produce the required functionality, SERS can interact with other components such as the user model (UM), the device model (DM) and the LMS. The UM is in charge of collecting the information about the learner to support the personalization process, which can be described in terms of IMS-LIP, IMS-AfA (in particular the subpart that deals with the Accessibility for LIP-AccLIP) and ISO/IEC 24751 (in particular, the subpart that deals with the Personal Needs and Preferences-PNP). The DM stores the information about the device that the learner is using to select the recommendations. For this, the W3C CC/PP specification can be considered. Moreover, a tool is required to manage the recommendations, either those manually generated by the educator with the _TORMES_ methodology or automatically derived from the algorithms [33]. This tool requires information from the LMS to be aware of the available objects, which are candidates for a recommendation. This means, for instance, that in order to define a recommendation for a forum message object in a specific course, the systems should provide the list of existing messages in the forums of that specific course. Thus, following the SOA approach, the LMS has to offer the corresponding web services to inform about the structural composition of the virtual spaces created. In this way, the recommendation designed can point to the appropriate object identifier in the LMS (_i.e._, pointer or object _id). The process to deliver a recommendation starts when the SERS server receives a request from the LMS. After that, the SERS requests information from the UM, the DM and the LMS tracking component. With this collected information, the SERS identifies the available recommendations and selects the recommendations that match the current applicability conditions and restrictions. If the number of recommendations exceeds the maximum number of recommendations that can be shown in the device screen, then the top with higher relevance are selected and delivered to the LMS. As a result, the recommendations are offered to the learner through the LMS presentation layer as described in the next section (or e-mailed to the learner). Moreover, the LMS can provide feedback to the SERS about the interactions done by the learners on the recommendations offered, that is, if the recommendations have been followed or not by the learners. Moreover, learners have the possibility of providing some feedback on the perceived utility for each recommendation, by selecting one of the following three options: (i) the recommendation was useful; (ii) the recommendation may be useful, but not in the moment offered; and (iii) the recommendation is not useful at all. In case the learner provides this feedback through the LMS, it is sent to the SERS to be processed. Next, a high-level description of the information needs that is required to be offered by each of the aforementioned components is done, following the web services presented in Figure 1. The head of arrows point to the component that offers the required web service. Table 6 compiles the identifiedweb services. Regarding the LMS, two web services are required to provide access to both the structural and the interaction information. The UM should allow storing and retrieving the learner data.