REST back end and ios application to optimize time and recommend new events

Transcription

1 REST back end and ios application to optimize time and recommend new events Autor: Carlos Balduz Bernal Director: David Contreras Bárcena Madrid Junio 2013

2

3 AUTORIZACIÓN PARA LA DIGITALIZACIÓN, DEPÓSITO Y DIVULGACIÓN EN ACCESO ABIERTO (RESTRINGIDO) DE DOCUMENTACIÓN 1º. Declaración de la autoría y acreditación de la misma. El autor D. CARLOS BALDUZ BERNAL, como ALUMNO de la UNIVERSIDAD PONTIFICIA COMILLAS (COMILLAS), DECLARA que es el titular de los derechos de propiedad intelectual, objeto de la presente cesión, en relación con la obra Proyecto fin de Carrera: REST back end and ios application to optimize time and recommend new events, que ésta es una obra original, y que ostenta la condición de autor en el sentido que otorga la Ley de Propiedad Intelectual como titular único o cotitular de la obra. En caso de ser cotitular, el autor (firmante) declara asimismo que cuenta con el consentimiento de los restantes titulares para hacer la presente cesión. En caso de previa cesión a terceros de derechos de explotación de la obra, el autor declara que tiene la oportuna autorización de dichos titulares de derechos a los fines de esta cesión o bien que retiene la facultad de ceder estos derechos en la forma prevista en la presente cesión y así lo acredita. 2º. Objeto y fines de la cesión. Con el fin de dar la máxima difusión a la obra citada a través del Repositorio institucional de la Universidad y hacer posible su utilización de forma libre y gratuita ( con las limitaciones que más adelante se detallan) por todos los usuarios del repositorio y del portal e-ciencia, el autor CEDE a la Universidad Pontificia Comillas de forma gratuita y no exclusiva, por el máximo plazo legal y con ámbito universal, los derechos de digitalización, de archivo, de reproducción, de distribución, de comunicación pública, incluido el derecho de puesta a disposición electrónica, tal y como se describen en la Ley de Propiedad Intelectual. El derecho de transformación se cede a los únicos efectos de lo dispuesto en la letra (a) del apartado siguiente. 3º. Condiciones de la cesión. Sin perjuicio de la titularidad de la obra, que sigue correspondiendo a su autor, la cesión de derechos contemplada en esta licencia, el repositorio institucional podrá: (a) Transformarla para adaptarla a cualquier tecnología susceptible de incorporarla a internet; realizar adaptaciones para hacer posible la utilización de la obra en formatos electrónicos, así como incorporar metadatos para realizar el registro de la obra e incorporar marcas de agua o cualquier otro sistema de seguridad o de protección. (b) Reproducirla en un soporte digital para su incorporación a una base de datos electrónica, incluyendo el derecho de reproducir y almacenar la obra en servidores, a los efectos de

4 garantizar su seguridad, conservación y preservar el formato.. (c) Comunicarla y ponerla a disposición del público a través de un archivo abierto institucional, accesible de modo libre y gratuito a través de internet. 1 (d) Distribuir copias electrónicas de la obra a los usuarios en un soporte digital. 2 4º. Derechos del autor. El autor, en tanto que titular de una obra que cede con carácter no exclusivo a la Universidad por medio de su registro en el Repositorio Institucional tiene derecho a: a) A que la Universidad identifique claramente su nombre como el autor o propietario de los derechos del documento. b) Comunicar y dar publicidad a la obra en la versión que ceda y en otras posteriores a través de cualquier medio. c) Solicitar la retirada de la obra del repositorio por causa justificada. A tal fin deberá ponerse en contacto con el vicerrector/a de investigación ([email protected]). d) Autorizar expresamente a COMILLAS para, en su caso, realizar los trámites necesarios para la obtención del ISBN. d) Recibir notificación fehaciente de cualquier reclamación que puedan formular terceras personas en relación con la obra y, en particular, de reclamaciones relativas a los derechos de propiedad intelectual sobre ella. 5º. Deberes del autor. El autor se compromete a: a) Garantizar que el compromiso que adquiere mediante el presente escrito no infringe ningún derecho de terceros, ya sean de propiedad industrial, intelectual o cualquier otro. b) Garantizar que el contenido de las obras no atenta contra los derechos al honor, a la intimidad y a la imagen de terceros. c) Asumir toda reclamación o responsabilidad, incluyendo las indemnizaciones por daños, que pudieran ejercitarse contra la Universidad por terceros que vieran infringidos sus derechos e intereses a causa de la cesión. d) Asumir la responsabilidad en el caso de que las instituciones fueran condenadas por infracción de derechos derivada de las obras objeto de la cesión. 1 En el supuesto de que el autor opte por el acceso restringido, este apartado quedaría redactado en los (c) Comunicarla y ponerla a disposición del público a través de un archivo institucional, accesible de modo restringido, en los términos previstos en el Reglamento del Repositorio Institucional 2 En el supuesto de que el autor opte por el acceso restringido, este apartado quedaría eliminado.

5 6º. Fines y funcionamiento del Repositorio Institucional. La obra se pondrá a disposición de los usuarios para que hagan de ella un uso justo y respetuoso con los derechos del autor, según lo permitido por la legislación aplicable, y con fines de estudio, investigación, o cualquier otro fin lícito. Con dicha finalidad, la Universidad asume los siguientes deberes y se reserva las siguientes facultades: a) Deberes del repositorio Institucional: - La Universidad informará a los usuarios del archivo sobre los usos permitidos, y no garantiza ni asume responsabilidad alguna por otras formas en que los usuarios hagan un uso posterior de las obras no conforme con la legislación vigente. El uso posterior, más allá de la copia privada, requerirá que se cite la fuente y se reconozca la autoría, que no se obtenga beneficio comercial, y que no se realicen obras derivadas. - La Universidad no revisará el contenido de las obras, que en todo caso permanecerá bajo la responsabilidad exclusiva del autor y no estará obligada a ejercitar acciones legales en nombre del autor en el supuesto de infracciones a derechos de propiedad intelectual derivados del depósito y archivo de las obras. El autor renuncia a cualquier reclamación frente a la Universidad por las formas no ajustadas a la legislación vigente en que los usuarios hagan uso de las obras. - La Universidad adoptará las medidas necesarias para la preservación de la obra en un futuro. b) Derechos que se reserva el Repositorio institucional respecto de las obras en él registradas: - retirar la obra, previa notificación al autor, en supuestos suficientemente justificados, o en caso de reclamaciones de terceros. Madrid, a.. de... de. ACEPTA Fdo

6

7 Proyecto realizado por el alumno/a: Carlos Balduz Bernal Fdo:.. Fecha: /.. /.. Autorizada la entrega del proyecto cuya información no es confidencial: EL DIRECTOR DEL PROYECTO David Contreras Bárcena Fdo:.. Fecha: /.. /.. V B del Coordinador de Proyectos Israel Alonso Martínez Fdo:.. Fecha: /.. /..

8

9 Agradecimientos En primer lugar, me gustaría agradecer a mis padres todo su apoyo y el esfuerzo que ha supuesto para ellos que yo pueda estudiar la carrera que siempre he querido hacer en una de las mejores universidades que hay para dicha carrera. A mis compañeros de clase, por convertirse en una segunda familia durante el transcurso de la carrera y por estar siempre dispuestos a ayudar en cualquier momento, especialmente a Pedro y a David. También quisiera darle las gracias a Linda por estar ahí en lo bueno y en lo malo, animándome en todo momento a dar ese último empujón cuando parecía que el proyecto nunca iba a acabar. Por último, obviamente me gustaría agradecerle a mi director de proyecto, David Contreras, el haberme dirigido y haberme ayudado cuando he tenido algún problema. I

10 II

11 REST BACK END Y APLICACIÓN PARA ios PARA OPTIMIZAR TIEMPO Y RECOMENDAR NUEVOS EVENTOS Autor: Balduz Bernal, Carlos Director: Contreras Bárcena, David Entidad Colaboradora: ICAI Universidad Pontificia Comillas. RESUMEN DEL PROYECTO El objetivo de este proyecto de fin de carrera consiste en desarrollar una aplicación para dispositivos ios que ayude a sus usuarios a gestionar su tiempo de una manera más eficiente, y que además aprenda de ellos en base a sus interacciones con la aplicación para poder recomendar nuevos eventos que pudieran resultarles interesantes. Para ello, el proyecto contará con un back end donde se almacenará toda la lógica y se realizarán todas las consultas a la base de datos. Por otro lado, se desarrollará la aplicación para ios, que se comunicará con el servidor a través de la interfaz REST programada en el back end. PALABRAS CLAVE REST, ios, back end, sistema de recomendación, front end. INTRODUCCIÓN En la actualidad, cada vez más personas utilizan de forma activa un smartphone en su día a día. Como consecuencia de ello, cada vez más aplicaciones surgen para satisfacer las necesidades de los usuarios, y se pueden encontrar en la App Store de Apple o en el Market de Android aplicaciones para prácticamente cualquier finalidad. III

12 Sin embargo, todavía no existe ninguna aplicación que permita a sus usuarios gestionar de una forma eficiente su tiempo libre y que además dicha aplicación vaya tomando información del usuario para poder proponerle eventos o actividades que pudieran resultarle interesantes en base a lo aprendido. Una aplicación así podría mejorar la calidad de vida de los usuarios, y además les permitiría enterarse de novedades o eventos interesantes de los que no habrían sido conscientes si no fuese por la aplicación. Además, una aplicación así también podría incorporar funciones sociales para ser todavía más atractiva para los usuarios, ya que les permitiría comunicarse entre ellos y además crear eventos comunes. Por ello, este proyecto se centra en la creación de una aplicación que pueda servir como agenda electrónica a sus usuarios pero que además aporte el valor añadido de ayudarles a optimizar su tiempo, recomendarles eventos interesantes y poder interactuar con sus amigos. METODOLOGÍA Y DESARROLLO Este proyecto combina una amplia carga teórica con un desarrollo práctico que a su vez se divide en tres partes bien diferenciadas. Puesto que la aplicación para ios desarrollada en el proyecto se conectará a un back end donde se almacenarán todos los datos y donde se procesará la información, es necesario estudiar cuáles son las mejores tecnologías existentes para lograr una comunicación rápida y fiable. Por ello, la primera etapa del proyecto consiste en un estudio exhaustivo de los distintos modos de comunicar un front end y un back end, en especial los servicios web REST, que se están empezando a utilizar cada vez más. Además, durante esta etapa también se han estudiado los distintos frameworks más utilizados en grandes desarrollos de aplicaciones web en Java Enterprise Edition, como Spring Framework y algunos de sus módulos, o como Hibernate. Por último, también ha sido necesario estudiar el lenguaje de programación utilizado para el desarrollo de aplicaciones nativas para ios: Objective-C. IV

13 Tras adquirir el conocimiento necesario para el desarrollo del proyecto, la segunda etapa estuvo enfocada a la programación del back end y el diseño e implantación de la base de datos donde toda la información será almacenada. Durante esta etapa se utilizaron los frameworks estudiados, como Spring Framework, para disminuir el tiempo de desarrollo gracias a la inyección de dependencias y la programación orientada a aspectos. Además, fue durante esta etapa donde se estudió cómo asegurarse de que el back end se trata de un sistema seguro, puesto que los servicios web de tipo REST presentan mayores complicaciones a la hora de securizar una aplicación. En una tercera etapa del proyecto, se programó la aplicación para ios que los usuarios finales van a utilizar. La aplicación desarrollada se conecta con el back end para cada interacción del usuario con la aplicación, para que toda la información y la lógica de negocio esté centralizada en un mismo lugar. Pantalla principal de Slypter. V

14 Por último, se ha desarrollado un sistema de recomendación que aprende de los usuarios en función del uso que le dan a la herramienta, pudiendo así en un futuro proponerles actividades que les pudiesen parecer interesantes. CONCLUSIONES Se ha conseguido el desarrollo de una aplicación que permite a sus usuarios organizar sus eventos de una manera más eficiente ayudados por una aplicación informática, y que además es capaz de proponerles nuevos eventos en función de sus gustos. Además, a nivel personal, el proyecto ha servido para adquirir conocimientos en algunos de los frameworks más demandados en el mundo empresarial a día de hoy, en especial Spring Framework. Asímismo, se ha ganado un mayor conocimiento de los servicios web y de las grandes ventajas que aporta REST frente a otras posibles opciones. Por otro lado, se han cumplido los objetivos que se propusieron al inicio de este proyecto, que son el desarrollo de un back end capaz de recibir cualquier petición de la aplicación para ios desarrollada y ofrecer todas las funcionalidades descritas anteriormente. REFERENCIAS [WALL11] Spring in Action. Walls, Craig. Manning. [MCCO04] Code Complete 2. McConnell, Steve. Microsoft Press. [APPL13] Apple s official ios documentation. VI

15 [HIBE13] JBoss Hibernate official website. VII

16 VIII

17 REST BACK END AND ios APPLICATION TO OPTIMIZE TIME AND RECOMMEND NEW EVENTS Author: Balduz Bernal, Carlos Supervisor: Contreras Bárcena, David Affiliation: ICAI Universidad Pontificia Comillas. ABSTRACT The objective of this final project consists in developing an application for ios devices that helps users manage their time in a more efficient way. Moreover, the application should learn from the users with each interaction, so that the application can recommend new events that the user may find interesting. To accomplish this, a back end has been developed where all the business logic of the system resides and where all the interactions with the database are carried out. As for the front end, an ios application will be programmed that will communicate with the server consuming its REST API. KEYWORDS REST, ios, back end, recommender system, front end. INTRODUCTION Nowadays, more and more people are starting to use smartphones in their daily life. As a result, more and more applications are being developed to satisfy user needs, and millions of applications can be found in Apple s App Store and the Android Market for almost any purpose. However, there are no applications that allow users to manage their free time in an efficient way and that it also stores information from the user to be able to learn IX

18 about him and recommend new events or activities that the user could find interesting. Such an application could improve the quality of life of its users. Moreover, the application described could also incorporate social features to be even more attractive to users, since it would allow them to communicate between them and to create common events. There, this project focuses on the creation of an application that could be used as an electronic agenda that also helps its users to optimize their time, recommend interesting events and enables them to interact with their friends. METHODOLOGY AND DEVELOPMENT This project is divided into four main stages, being the first one an exhaustive research of the technologies to be used throughout the project. Since the developed ios application will connect to a back end where all the data is stored and where all the information will be processed, it is necessary to study which of the existing technologies would be the best approach. Hence, the first stage of the project consists in the study of the different ways to provide communication between the front end and the back end, specially REST web services. Furthermore, during this first stage several frameworks that are used in the development of large Java Enterprise Edition applications, such as Spring Framework and its modules, or Hibernate. Finally, some research about Apple s official programming language, Objective-C, has also been carried out. After gaining the necessary knowledge to begin with the development process, the second stage of the project focused on the programming of the back end and the design and implantation of the MySQL database where all the data will be stored. During this stage, the frameworks studied in the first stage were used, like Spring Framework, tu reduce development time by taking full advantage of its dependency injection and aspect-oriented programming. As well as this, during this stage several security issues were taken into consideration, deciding how to make the back end secure, since REST web services present some problems with security. X

19 During the third stage of the project, the ios application that end users wull use was programmed. The developed application connects to the back end with each user interacion, so that all of the data and business logic is centralized in a single location. Slypter s main screen. Finally, a recommender system capable of extracting information from the user has been developed, so that the application can also propose new activities to the user. XI

20 CONCLUSIONS The development of an application that allows users to organize their events in a more efficient way has been achieved. Moreover, this application is capable of proposing new events to the users depending on what the recommender system has been able to learn from them. Moreover, this project has helped the author gain deeper knowledge about some of the most used frameworks nowadays, such as Spring Framework and Hibernate. Finally, all of the objectives that were originally proposed have been achieved, which were the development of a back end capable of handling any petition from the ios application developed and offer all of the functionalities described earlier. REFERENCES [WALL11] Spring in Action. Walls, Craig. Manning. [MCCO04] Code Complete 2. McConnell, Steve. Microsoft Press. [APPL13] Apple s official ios documentation. [HIBE13] JBoss Hibernate official website. XII

21 TABLE OF CONTENTS CHAPTER 1 INTRODUCTION PROJECT MOTIVATION... 1 CHAPTER 2 PROJECT SCOPE OBJECTIVES METHODOLOGY PLANIFICATION Documentation Back End Front End Recommender System PROJECT BUDGET CHAPTER 3 RESTFUL API WEB SERVICES REST REST methods for manipulating resources Response formats RESTful URLs SLYPTER S RESTFUL API CHAPTER 4 DEVELOPING THE BACK END SPRING FRAMEWORK Dependency Injection Aspect- Oriented Programming SPRING MVC Spring MVC and REST JAVA PERSISTENCE API XIII

22 4.3.1 Hibernate SENDING NOTIFICATIONS TO AN IOS DEVICE APNS Java libraries SLYPTER S BACK END IMPLEMENTATION Use cases Back end architecture Used frameworks Conclusions CHAPTER 5 SECURING THE APPLICATION RESTFUL AUTHENTICATION Authentication Token SPRING SECURITY SLYPTER S IMPLEMENTATION OF SPRING SECURITY SECURE SOCKETS LAYER Description How it works SSL in Slypter CHAPTER 6 SLYPTER S RECOMMENDER SYSTEM RECOMMENDER SYSTEMS CONTENT- BASED RECOMMENDER SYSTEMS COLLABORATIVE FILTERING How it works Gradient Descent Slypter s Recommendation System Mean Normalization CHAPTER 7 IOS FRONT END NATIVE OR WEB BASED APPLICATION? Web Based applications Native applications Comparison between both kinds of applications RESULTS XIV

23 7.2.1 User login Main screen Other screens CHAPTER 8 CONCLUSIONS AND FUTURE DEVELOPMENTS CONCLUSIONS Benefits of Spring REST FUTURE DEVELOPMENTS REFERENCES XV

24 XVI

25 List of Figures Figure 1. Overview of the project Figure 2. First stage of the project Figure 3. Second stage of the project Figure 4. Third stage of the project Figure 5. Fourth stage of the project Figure 5. WSDL 2.0 example Figure 6. Web service architecture [WIKI01] Figure 7. RESTless URL Figure 8. RESTful URL example Figure 9. Overview of the Spring Framework. [SPRI01] Figure 10. Spring MVC request life cycle. [SMVC11] Figure 11. Overview of the Hibernate framework. [HIBE13] Figure 12. ios notifications example Figure 13. Device token generation. [APPL13] Figure 14. Sharing the device token. [APPL13] Figure 15. Notification message format. [APPL13] Figure 16. Push notification from a provider to a client application. [APPL13].. 44 Figure 17. Some of Slypter use cases Figure 18. Slypter s back end workflow Figure 19. Authentication token: user login Figure 20. Authentication token: logged user Figure 21. Slypter s authentication token example XVII

26 Figure 22. Authenticating a user with a token sequence diagram Figure 23. Asymmetric encryption. [MDSN01] Figure 24. SSL session key negotiation. [SSLA12] Figure 25. Recommendation systems. [RECO12] Figure 26. Gradient descent example. [WIKI04] Figure 27. Comparison between web based and native applications. [SIXR12].. 81 Figure 28. Apple s official IDE: Xcode Figure 29. User login sequence diagram Figure 30. User login screen Figure 31. User login screen Figure 32. Slypter s main screen Figure 33. Slypter s main menu Figure 34. Adding a new event Figure 35. Selecting the time for an event XVIII

27 List of tables Table 1: time estimation for the first stage of the project Table 2: time estimation for the second stage of the project Table 3: time estimation for the third stage of the project Table 4: time estimation for the final stage of the project Table 4: detailed project budget Table 5: summarized project budget Table 6: content-based filtering example Table 7: content-based filtering set of features example Table 8: mean normalization example Table 9: comparison between web based and native ios applications XIX

28 XX

29 Chapter 1 INTRODUCTION 1.1 PROJECT MOTIVATION Over the last few years, smartphone usage has increased significantly worldwide. More and more people are beginning to use applications to help them in their daily routine. Hence, through application stores such as ios s App Store or Android s Android Market applications of all types can be found for almost any purpose. However, there are still no intelligent agendas that offer something innovative to smartphone users. Some applications focus on allowing its users to introduce their schedule, but none of the existing ones help the user optimize their time. Therefore, this project aims to provide a new application called Slypter for ios users that helps them to organize their time more effectively, allowing them to be more productive. After an initial configuration and using Artificial Intelligence techniques, like for example Artificial Neural Networks, Slypter will learn about the user s behaviour and aid him whenever he needs to make changes to his schedule, proposing the best option according to what the application has learned. As for the personal motivation, several factors were taken into consideration by the author before starting the project: The great challenge of building an ios application that connects to a JavaEE back end with a RESTful API. The possibility of gaining deeper knowledge of some of the most popular Java frameworks: Hibernate and Spring. 1

30 Learning about recommender systems and how to implement them. Creating an iphone application that can be published in the App Store. 2

31 Chapter 2 PROJECT SCOPE 2.1 OBJECTIVES The current project consists in the development of an ios application for all iphone and ipod Touch users that may need some help in organizing their daily routine. This application needs to provide the users with something more than just an electronic agenda, it should have something that makes a difference between Slypter and other similar applications. Therefore, the current project will also focus in developing a recommender system that learns from the user with every interaction with the application. This way, the application will use the information stored to propose events in the future that the user may find interesting. To do so, several Artificial Intelligence techniques will be studied to decide which of them are best suited for the application requirements. As well as this, Slypter will allow its users to do much more than just adding events and proposing new events based on their previous decisions. It will also incorporate social features so that users can interact with each other. Every user can add other users to its list of friends, and share events with any of them. Sending messages between users is another thing that Slypter will permit its users to do, as well as inviting friends to a certain event. Hence, this project also aims to create a new social network that is focused on events and helping users to optimize their free time. Moreover, Slypter is made up of two totally independent parts: a website and the ios application to be developed in this project. This project focuses on the latter, the ios application. However, Slypter s website technology uses Java EE servlets, which cannot be used by an ios application. As a result, a new back end 3

32 has to be developed so that the ios application interacts with it without the need of having to access the website. Furthermore, the API developed in the back end could also be used by the website, avoiding duplicated code and centralising all the business logic in the same place. In conclusion, this project is divided into three main parts, which are the develoment of a front end that targets all iphone and ipod Touch users, the development of a back end that will communicate with the front end, and the study and development of a recommender system that will reside in the developed back end. A list of the main objectives to be satisfied, from a more technical point of view, would be the following: To create a front end application to help users organize their time more effectively. This application will be programmed in Objective-C, which is the main programming language used by Apple for ios. To use Apple Push Notification Service to send notifications to users when there is new data do be presented to the user. To develop a very intuitive and user-friendly Graphical User Interface so that users are encouraged to use the application. To develop a RESTful API in Java Enterprise Edition using Spring Framework and Spring MVC where all the business logic resides. It will be this back end the one that interacts with the database and that decides which information it should return to the client. To add social features such as messaging between users or sending invitations. To secure the developed back end so that unauthorized users cannot use the application or view private information about other users. 4

33 To study which machine learning techniques would be better to create a recommender system that learns information from the user with every interaction and proposes new events that the user could find interesting. 2.2 METHODOLOGY Due to the nature of this project, a very standard methodology has been used. New software development methods based on iterative and incremental development, such as SCRUM, are not suitable for this project since there are very differentiated stages of the project that need to be concluded before the next one begins. For example, the author of the project knows nothing about Spring Framework, so a first stage of documentation is necessary before starting the development of the back end. For these reasons, this project has been developed following a waterfall model, in which every stage of the project is not initialized until the previous one has been successfully finished. At first glance, the project could be divided into four main stages, each of them focusing in very differentiated parts of the whole system. These four stages are the following: Documentation about Spring Framework and its modules, Hibernate, web services, REST, machine learning and recommender systems. Development of the back end using Java Enterprise Edition, Spring Framework, Spring MVC, Hibernate and Spring Security, creating a RESTful API to be used by the front end. 5

34 Development of the front end that will consume the REST web services created in the previous stage using Objective-C as the programming language. Creation and development of the recommender system, that will be added as a new module of the back end. These four main stages can be seen in the following figure: Figure 1. Overview of the project. Although the majority of the project will follow a waterfall model, since, for example, the front end cannot be programmed until the RESTful API of the back end is finished, the last three stages will follow a different approach. When developing the back end, the front end and the recommender system, an iterative and incremental development will be used. In every iteration, a new functionality will be planned, implemented and tested. By using this methodology, the development time of each of those three stages may be reduced. Moreover, if an error arises, since each iteration is tested, it will be discovered and solved in the moment, which makes testing easier once the whole project is finished. 6

35 2.3 PLANIFICATION As stated in the previous section, this project is divided into four main stages, and each of them is as well divided into different tasks. In this section, the required tasks and duration of each of them will be indicated DOCUMENTATION Before getting started with the development of both the back end and the front end, some research must be performed to study which approach would be the best for this project. Therefore, in this first stage of the project, several frameworks and ways of communicating two endpoints over the network will be studied. Moreover, the author will also study the two programming languages needed to develop both the back end and the ios application to gain deeper knowledge of them. Since the back end will be programmed in Java Enterprise Edition, the first task will consists in studying this programming language and how to develop large applications. The next step would be to learn about ORM frameworks such as JPA and Hibernate. To determine how to allow communications between the client and the server, web services should be studied, to determine which ones would be the best option. 7

36 Then, the Spring Framework will be studied, focusing on its core benefits, such as dependency injection and aspect-oriented programming, and also Spring MVC and Spring Security. Finally, the last step is to learn about Objective-C, since it is the programming language used to build native ios applications. In the following figure, the main steps of this stage can be seen: Figure 2. First stage of the project. As for the time estimation of each of these tasks, it can be seen in the following table: 8

37 Task Start date End date Java Enterprise Edition 08/10/ /11/2012 JPA and Hibernate 19/11/ /12/2012 Web services 03/12/ /12/2012 Spring Framework 25/12/ /01/2013 Spring MVC 11/01/ /01/2013 Spring Security 16/01/ /01/2013 Objective-C 23/01/ /01/2013 Table 1: time estimation for the first stage of the project BACK END After the research has been performed and the best available options have been chosen to develop Slypter s server, it is time to develop the back end using some of the technologies studied in the previous section. This is probably the most important stage of the project, since all of Slypter s logic and interactions with the database will be performed here. Therefore, it is the most complex and longest stage of the project. There are several tasks to be done to ensure that the back end works correctly and to ensure that it does everything it needs to do without any errors. Moreover, the back end must be secure against possible attacks. 9

38 One of the most important assets of almost any software application is its data, so the first step is the design and implementation of the database. After the database has been implemented, all of the Hibernate configuration files needed for it to work must be created. Moreover, the Java beans with the necessary annotations so that they can be mapped to the database are to be programmed. In every Spring application, there are several things to be configured to get things working. In this part of the project, all of the Spring configuration files will be configured, including Spring MVC configuration files. Once the project is set up, the DAO classes will be programmed and tested to check that everything is working correctly. With the Java beans and the DAO classes, the next step is to program the classes that will contain all the logic of Slypter. These classes will be called services, and are the ones the controllers will call for every request they receive, and are the ones in charge of performing all the necessary operations to fulfill the user s objective. In these services, the interactions with Apple Push Notification Service will also be programmed using aspect-oriented programming. Then, the controllers, which are the classes that will receive the user requests, would be programmed. These controllers work as RESTful web services with Spring MVC. The back end is almost finished, but there is still one issue that has not been addressed: its security. In this step, Spring Security will be configured so that any user that is not logged in will not be able to access the application. 10

39 In the following figure, the steps to be taken during this stage of the project can be seen: Figure 3. Second stage of the project. The time estimation for each of the tasks shown in the previous figure can be seen in the following table: 11

40 Task Start date End date Database design and implementation 30/01/ /02/2013 Hibernate configuration 05/02/ /02/2013 Java beans 08/02/ /02/2013 Spring configuration 12/02/ /02/2013 DAO programming 14/02/ /02/2013 Services programming 19/02/ /03/2013 Controllers programming 20/03/ /03/2013 Spring Security Configuration 27/03/ /03/2013 Security interceptor 28/03/ /03/2013 Table 2: time estimation for the second stage of the project FRONT END The final user that will use Slypter as an application that will help him optimize his or her free time will do so with an iphone or an ipod Touch, so after developing the back end, an ios application is needed so that users can start taking full advantage of it. This application will be programmed in Objective-C, since it will be a native application instead of a web-based application. Something characteristic about the application to be developed is that it will contain almost no business logic, since everything it needs to display will be retrieved from the server, and whenever the user makes changes or creates new events, the application will make a call to the server so it can update what the user has modified. 12

41 This means that the greatest challenge of the front end application will be to develop a user-friendly Graphical User Interface and minimizing the response time of the back end. Since the application needs to be constantly communicating with the server, one of the main concerns of this application is to use the full potential of the Grand Central Dispatch provided by Apple so that the application can make use of several threads, and the main thread is not blocked while the application tries to retrieve information from the server. Otherwise, the appliaction would be constantly freezing and no user would use such an application. Moreover, even if the application has a very intuitive GUI that the user finds attractive, if the communication with the server is slow, then the user will have to wait a long time everytime he interacts with the application. Therefore, the communication between both endpoints must be as fast as possible. The first step in this stage would be programming the login screen and manage how the application will store the necessary data so that the user may perform requests after logging in without having to present its credentials again, since the back end is a RESTful API and therefore each request needs to present some authentication information. After storing the necessary authentication information, a custom library will be programmed so that all of the other classes of the project do not need to worry about building the request with the necessary attributes so that the back end will accept the petition. This way, only one call to this library is needed by the class that needs to communicate with the server. The next step would be programming the main screen of the application, where all the events are presented to the user. In this screen, the user can view its events, displaying a list, or a view of the whole week or the whole month. 13

42 Another thing the user must be able to do is to add new events, indicating its details such as the location and the description of the event. Moreover, users can invite their friends to the event if they want to. This feature would be programmed during this step. Furthermore, users may send messages to their friends, and have conversations with each of them, which will be programmed in this step. Every user may change the settings of the application, like for example enabling notifications or changing their profile picture. This step would focus on achieving this. Finally, some other minor features would be programmed, such as allowing users to add or remove friends, remove events, etc. The following figure shows all of the necessary steps to be done during this third stage of the project: Figure 4. Third stage of the project. 14

43 The time estimation for each of the tasks to be developed during this stage of the project can be seen in the following table: Task Start date End date Log in 01/04/ /04/2013 Back end Fetcher Library 11/04/ /05/2013 Main screen 02/05/ /05/2013 Adding new events 12/05/ /05/2013 Messaging system 24/05/ /05/2013 Settings 01/06/ /06/2013 Other features 12/06/ /06/2013 Table 3: time estimation for the third stage of the project RECOMMENDER SYSTEM As for the last stage of the project, it will consist of the study and development of a recommedation system that will allow Slypter to obtain information from the users with every interaction, enabling the application to propose new events to the user that Slypter thinks the user will find interesting based on the information learned. This is one of the most complicated and delicate stages of the project, since recommendation systems are one of the most complicated applications of Artificial Intelligence, and there are several approaches when building these kind of systems, so some previous research will need to be carried out in order to discover which one suits best an application such as Slypter. 15

44 The recommendation system sought in this project, is one that is able to filter information obtained from the user and learn about all the users, so that it can then predict whether a certain user will like or dislike a public event, like for example a concert. Whenever the user is proposed a new event, depending on whether this user accepts or declines the event, the system must use this interaction to make better predictions in the future. Moreover, the recommendation system must also be able to display similar events to the one the user is currently viewing. Hence, the steps to be taken during this step of the project would be the following: Firstly, studying recommendation systems and how to implement them is necessary in order to start with the development. Learning about different types of recommender systems and finding out which one is better to satisfy this project s requirements. Design and implementation of a set of new tables that will need to be added to the current database. Since recommendation systems require of large amounts of information in order to work, a new design of the database will need to be studied to store all the necessary data. The next step would be programming a new module of the Java EE back end, which contains all of the recommendation system s logic. One of the main challenges of programming this module, is the heavy math required by recommendation systems, since all of the estimated parameters need to be recalculated with each interaction from the user. Adding new screens to the front end application. Once the recommender system is finished, the ios application needs to be able to show the user the public events that the recommendation system developed deals with. In these new screens, the user will be 16

45 able to view public events, Slypter s suggestions, similar events to the one they are currently viewing, and so on. All the steps described above can be seen in the following figure: Figure 5. Fourth stage of the project. As for the time estimation of each of the steps to be performed during this stage, they can be seen in the following table: 17

46 Task Start date End date Content-based systems 29/06/ /07/2013 Collaborative filtering 01/07/ /07/2013 Database redesign 04/07/ /07/2013 Recommendation system development Development of new front end features 06/07/ /07/ /07/ /07/2013 Table 4: time estimation for the final stage of the project. 2.4 PROJECT BUDGET The estimated budget for this project can be seen in table 4. To calculate this costs, the following factors have been taken into account: For each of the days indicated in the project planification, the average of hours per day is around 2.5 hours. A junior software developer earns 25 per hour. Other expenses (such as Internet connection, electricity, office materials, the computer and iphone 5 used to test the software ) turn the initial 25 per hour into per hour. 18

47 Task Cost Stage 1 Java Enterprise Edition 450 JPA and Hibernate 600 Web services 900 Spring Framework 950 Spring MVC 250 Spring Security 300 Objective-C 300 Stage 1 total 3750 Stage 2 Database design and implementation 400 Hibernate configuration 200 Java beans 265 Spring configuration 120 DAO programming 290 Services programming 1750 Controllers programming 525 Spring Security Configuration 90 Security interceptor 225 Stage 2 total

48 Stage 3 Log in 450 Back end Fetcher Library 1125 Main screen 410 Adding new events 430 Messaging system 315 Settings 490 Other features 215 Stage 3 total 3435 Stage 4 Content-based systems 120 Collaborative filtering 200 Database redesign 180 Recommendation system development 720 Development of new front end features 615 Stage 4 total 1835 Table 5: detailed project budget. by stage: As for the summarized budget, it can be seen in the following table divided 20

49 Stage Cost Documentation 3750 Back end 3865 Front end 3435 Recommender system 1835 Total Table 6: summarized project budget. 21

50 22

51 Chapter 3 RESTFUL API 3.1 WEB SERVICES When two applications need to communicate over the internet, they generally achieve so by using Web services. A Web service is a software system designed to allow machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically, Web Service Definition Language, or WDSL). Other systems interact with the Web service sending messages to the interface provided. The vast majority of Web services used to use the SOAP (Simple Object Access Protocol) protocol, which relies on XML files to describe the methods that can be accessed. The file used for describing the functionality offered by the Web service is called the Web Services Description Language. It provides a description of how the service can be called, the parameters it expects, and what data structure it returns. An example of a WSDL file could be the following: Figure 6. WSDL 2.0 example. 23

52 However, SOAP Web services have several disadvantages. For instance, creating this type of services is too complex and special tools are needed to create a client. But its main drawback is the heavy XML wrapper required in each request or response, which makes this kind of Web services need much more bandwith. Figure 7. Web service architecture [WIKI01]. For these reasons, Representational State Transer has emerged as a popular alternative to SOAP-based web services. 3.2 REST Representational State Transfer (REST) is a simpler alternative to SOAP web services. REST web services are invoked through plain HTTP URLs, without SOAP s XML namespaces. The term REST was introduced in 2000 by Roy Fielding, and it has gained widespread acceptance as a simpler alternative to other web services. REST is resource-oriented, and relies on a simple URL to deliver the resource requested, although in some situations additional information must be provided. One of the main characteristics of REST is its statelessness, which 24

53 means that the server is not allowed to keep a session. When working with REST, each request must contain all of the information necessary to understand the request, since session state is kept entirely on the client. There are four different methods to make a REST call to a server, which will be explained in the following section REST METHODS FOR MANIPULATING RESOURCES When making a REST request to the server, the most common operations are to retrieve a resource from the server, to create a new one, to update it or to delete it. For this reason, REST can use four different HTTP 1.1 verbs to perform tasks: GET: this method is used to retrieve a resource identified by the request s URL. POST: creates a new resource in the server with the data provided by the request. The server must create a new identifier for the resource created. PUT: updates the resource identified by the URL. DELETE: deletesthe resource on the server identified by the request s URL. Another thing to bear in mind about REST is that, unlike SOAP web services, it does not have to use XML to provide the response, and other formats may be used. 25

54 3.2.2 RESPONSE FORMATS XML Extensible Markup Language (XML) is a simple, very flexible text format derived from SGML. A server response in REST can use XML, although it is not bound to it like in SOAP services. An example of an XML response would be the following: <people> <user> <username>user 1</username> < >[email protected]</ > </user> <user> <username>user 2</username> < >[email protected]</ > </user> </people> One of the main disadvantages of using XML as response type, is that it is that it results in more data for the same amount of information than other types, such as JSON. JSON JavaScript Object Notation (JSON) is a lightweight, text-based, languageindependent data interchange format. It is a text format for the serialization of structured data, and it offers two main advantages over XML: JSON is smaller than corresponding XML. JSON s syntax is simpler than XML, thus it is easier and faster to parse. The same example used in the previous section, but serialized using JSON would give produce the following: 26

55 { } "people": { "user": [ { "username": "User 1", " ": "[email protected]" }, { "username": "User 2", " ": "[email protected]" } ] } Other response formats Although the most common response formats are the two described in the previous sections, REST web services can deliver resources in almost any form. Another possible formats include HTML and CSV (comma-separated values) RESTFUL URLS Generally, web applications have URLs that contain verbs or that indicate somehow what actions the server is expected to perform. However, since REST is resource-oriented, URLs are used to specify objects, not actions. For this reason, when creating a RESTful API, all of its URLs should avoid the use of verbs, and instead identify a resource. For example, a URL for a web application that follows the MVC model without REST could be the following: 27

56 Figure 8. RESTless URL. In the previous example, the URL demands that the server show a user, it is verb-oriented, indicating actions instead of resources. A RESTful URL should identify a unique resource, without the need of specifying which action needs to be done, since that will depend on the HTTP method of the request. A good example of a RESTful URL is: Figure 9. RESTful URL example. The previous URL locates a resource and uniquely identifies it, without asking the server to perform any action. Generally, RESTful URLs take its input from its path, which is parameterized, whereas RESTless URLs input comes from query parameters. 3.3 SLYPTER S RESTFUL API Slypter, as well as an ios application, will have a website so that people who do not own an iphone or ipad can also use it. Therefore, all of the data the application requires will need to be stored in a back end where both the website and the application can retrieve or update data. Moreover, all of the data processing will also be done in the back end, to avoid code duplication. 28

57 For this reason, the front end application will communicate with the server through web services. This communication must be as fast as possible, since internet connection is slower on a mobile phone, and response times must be kept to a minimum. In order to achieve this, the web services will be REST, since they are faster than SOAP-based web services. The back end will have several controllers mapped to different RESTful URLs that will take care of retrieving a resource, creating a new one, updating an existing one or delete it, depending on the HTTP method of the request. As for the response format of Slypter s web services, it will be JSON for two reasons: it is easier to parse, and it is much faster than other formats such as XML. 29

58 30

59 Chapter 4 DEVELOPING THE BACK END Before programming Slypter s back end, several things must be taken into account. First of all, one of the main objectives of the present project is to develop a successful ios application, so the code should be as readable and easy to maintain as possible, since it is highly likely that many changes will have to be done to the code in the future. Additionally, to develop the RESTful API, a good Java EE framework that helps with the creation of web services should be used. Due to the nature of the project, an MVC framework such as Struts or Spring MVC would suffice. Finally, the database the back end will be accessing is MySQL, a relational database. Since there will be a large number of beans, an object-relational mapping framework would help reducing the amount of code necessary to perform any operation with the database. 4.1 SPRING FRAMEWORK In the early years of Java, as applications became more and more complex, the need for powerful frameworks arose due to the power of Java. In 1996, Sun Microsystems published the JavaBeans specification, which enabled Java objects to be reusable, but it was not enough for Java Enterprise Edition developers. Two years later, the first version of Enterprise JavaBeans emerged. This new specification provided many new features, simplifying aspects of development such as transactions, but it complicated development in many other ways. For this reason, EJB was not the best choice. 31

60 Nowadays, new techniques have appeared to give JavaBeans the power that EJB offered. These techniques include dependency injection (DI) and aspectoriented programming (AOP), making plain-old Java objects (POJOs) more powerful without the complexity of Enterprise JavaBeans. The most widely used framework for lightweight POJO-based development is Spring Framework. According to [WALL11], Spring is an open source framewor, originally created by Rod Johnson and described in his book Expert One-on-One: J2EE Design and Development. Spring was created to address the complexity of Enterprise application development, and makes it possible to use plain-vanilla JavaBeans to achieve things that were previously only possible with EJBs. The main objective of Spring Framework is to simplify Java development, and it achieves so in two different ways, which will be covered in more detail later: dependency injection and aspect-oriented programming. However, over the years, more and more modules have been added to Spring, making it one of the most complete frameworks available. The main modules of the Spring Framework can be seen in figure 9: Figure 10. Overview of the Spring Framework. [SPRI01] 32

61 Core Spring Container This is the main module of the framework, which includes the dependency injection and inversión of control features. All of the modules are built on top of the core container. AOP Aspect-oriented programming support is provided within this module. It allows the definition of method-interceptors and pointcuts to decouple code. Data Access and Integration This module helps keeping database code clean and simple, providing a JDBC-abstraction layer. Moreover, it also includes an ORM module for frameworks such as ibatis and Hibernate. Web In this module, Spring s Model-View-Controller implementation for web applications is included. It also provides remoting options, like Remote Method Invocation (RMI). Test This module is dedicated to testing Spring applications, and it supports testing with JUnit or TestNG. As mentioned above, since Spring Framework was first released, many modules have been developed and added to the framework. The ones that described above are the core of Spring, but there are more modules, such as Spring Security, which provides a declarative security mechanism and will be discussed in chapter 4. 33

62 4.1.1 DEPENDENCY INJECTION The main purpose of Spring is to help developers produce a code that is cleaner, simpler, and easier to understand and to maintain. One of the ways it achieves this is with Dependency Injection. Generally, in programming, each object must obtain its own references (dependencies) to the objects it will need. This results in highly coupled code, and one change in an object may force many changes in other objects. Coupling is necessary in every program, but it must be kept to a minimum to minimize its impact. The whole point of DI is to produce decoupled code, by giving each object its dependencies at creation time by some third party that coordinates each object in the system [WALL11]. The following code shows an example of a class tightly coupled to another one: public class User implements Person { private LeisureEvent event; public User() { this.event = new LeisureEvent(); } } public void startevent() { this.event.start(); } In the previous code, User is tightly coupled to LeisureEvent. As a result, this code is difficult to test and difficult to reuse. After applying Dependency Injection to the code, it would look like this: public class User implements Person { private Event event; 34

63 public User(Event event) { this.event = event; } } public void startevent() { this.event.start(); } Now, User is given an event at construction time as an argument. It is not coupled to any specific implementation of Event, and it does not need to worry about getting its own references, since they will be injected at construction time. This results in code that is more reusable, easier to maintain and easier to test. Spring Framework allows injecting beans through constructors or directly into properties, and this can be done in the XML configuration files or with annotations ASPECT-ORIENTED PROGRAMMING Aspect-oriented programming is a programming paradigm that promotes separation of concerns within a software system. Developers tend to group and encapsulate concerns into separate entities, but often these elements carry additional responsibility beyond their core functionality. Cross-cutting concerns are these elements that affect other concerns, leading to code duplication. Transaction management, data validation and security are examples of cross-cutting concerns, having to code specific functions to implement these services into elements whose core functionality is something else. AOP aims to separate cross-cutting concerns, increasing modularity and reducing code duplication. An aspect is defined by the combination of an advice and a pointcut. Advices specify what the aspect does, and when it must do it. In Spring, advices can take place before a method is called, after it has been called, after the advised method successfully completes, after the method throws an exception, or before 35

64 and after the advised method is invoked. As for pointcuts, they are the points of execution in the application where the advice should be invoked. 4.2 SPRING MVC Spring MVC is Spring s solution to developing web applications that follow the Model-View-Controller pattern. When building JavaEE web applications, one servlet is defined for each request, but in Spring MVC applications every request is intercepted by the same servlet, called DispatcherServlet. For every request, the DispatcherServlet consults a handler mapping to figure out which controller must attend the request, and then sends it to that controller. After the controller has finished processing the information, it will return the information that the user needs (the model) along with the name of the view that should be presented to the user. Now, the DispatcherServlet will consult a view resolver to find out which view implementation must be rendered, and finally the output is returned to the user. The whole process can be seen in the following figure: 36

65 Figure 11. Spring MVC request life cycle. [SMVC11] SPRING MVC AND REST Spring 3 provides full REST support, allowing developers to build RESTful web applications using Spring MVC. Each controller can handle request for the four HTTP methods used in REST web services: GET, POST, PUT and DELETE. Moreover, controllers are able to handle parameterized URLs, so they can take input from the path of the URL. With Springs MVC s view resolvers, resources can be represented in serveral formats, including XML and JSON. For example, a controller that handles REST requests for the URL described in figure 8 could be public class ExampleController { private UsersService public ExampleController(UsersService usersservice) { 37

66 } this.usersservice = method=requestmethod.get) User getuser(@pathvariable("id") long id) { return this.usersservice.getuserbyid(id); method=requestmethod.put) public void updateuserinfo(@pathvariable("id") long id, User user) { this.usersservice.saveuser(user); method=requestmethod.delete) public void deleteuser(@pathvariable("id") long id) { return this.usersservice.deleteuser (id); } method= RequestMethod.POST) public void registeruser(user user) { this.usersservice.registeruser(user); } In the previous code example, in very few lines of code the controller can handle four different requests for each of the REST methods. When the controller is created, the class UsersService is injected as a constructor argument, and it will be this class the one that contains all the logic. Whenever a new request to the URL is caught by the DispatcherServlet, it is sent to ExampleController. Depending on the request method, it will retrieve the resource with id 98 and return it to the caller, update it or delete it. However, if the caller is trying to create a new resource with a POST petition, the resource to be created does not yet have an id, so instead, the URL will be: Spring MVC makes the creation of REST web applications very straightforward, and testing these applications with Spring is very easy. For these reasons, the framework used to build Sypter s RESTful API will be Spring MVC, along with Spring Framework to decouple code with its dependency injection and separate cross-cutting concerns with aspect-oriented-programming. 38

67 4.3 JAVA PERSISTENCE API The Java Persistence API (JPA) is a Java framework that provides a POJO persistence model for ojbect-relational mapping. With JPA, the developer no longer has to write code to map an object s model data representation to a relational data model. JPA works with entities, which, according to [WIKI02], are lightweight Java classes whose state is typically persisted to a table in a relational database. Instances of an entity correspond to individual rows in the table. Entities generally have relationships with other entities, and these relationships are expressed through object/relational metadata. When working with Java Database Connectivity (JDBC), the programmer needs to write the code to map every object, and it is his responsibility to handle the result set and convert it to objects through code manually. All this code can be avoided when working with JPA, since it will automatically make the conversions once the mapping of an entity has been specified using XML configuration files or annotations. There are many implementations of the Java Persistence API, like EclipseLink and OpenJPA. The one that Slypter will use is Hibernate HIBERNATE Hibernate is an object-relational mapping solution for Java environments. It takes care of the mapping from Java classes to database tables, and from Java data types to SQL data types. In addition, it provides data query and retrieval facilities. It can significantly reduce development time otherwise spent with manual data handling in SQL and JDBC [HIBE13]. 39

68 Figure 12. Overview of the Hibernate framework. [HIBE13] To work with Hibernate, entities must be declared in an XML configuration file or using annotations, indicating the framework to which table it corresponds and how it should be mapped. An example of a very simple entity using annotations would be = "USERS") public class User { private long userid; private @Column(name = "user_id", unique = true, nullable = false) public long getuserid() { return userid; } public void setuserid(long userid) { this.userid = userid; = "user_name") public String getusername () { return username; } 40

69 } public void setusername(string username) { this.username = username; } Once the entities are mapped, an XML configuration file must be created, where the details of the database (such as its location, username, password ) must be especified, as well as the classes that contain entities. Finally, to access the database using Hibernate, a SessionFactory is required, since it is the one in charge of opening a session with the database. 4.4 SENDING NOTIFICATIONS TO AN IOS DEVICE One of the main problems of ios is that it does not allow applications to be running in the background. Thus, applications that require to be connected constantly are not able to receive updates. To solve this, Apple created the Apple Push Notification Service with the release of ios 3.0. Notifications allow applications that are not running in the foreground to alert the user that it has new information for them. In Slypter, for instance, the user needs to be notified when an event is about to start, when a friend sends a message or when someone posts a new comment in an existing event. The APNS is a service that allows an ios device to be constantly connected to Apple s push notification server. When a notification needs to be sent to the user, the server side of the application (the provider) must contact the APNS so that it can deliver a push message on the intended device. 41

70 Figure 13. ios notifications example. Notifications consist of two pieces of data: the device token and the payload. The device token is a unique token generated by APNS within an iphone application so that each notification may be addressed to a specific device. Each device token is 32 bytes long, and an example of a device token could be the following: 5672fb75 55d a3a0fd db2cc2ac e71930c4 294ce52b 641bc69c eb95dbae To receive a device token, the application must register connecting to the APNS, where a new token will be generated using information contained in the unique device certificate. Then, the application should send the received token to the provider, in this case Slypter s back end, where it should be stored. 42

71 Figure 14. Device token generation. [APPL13] Figure 15. Sharing the device token. [APPL13] According to [APPL13], the payload is a JSON-defined property list that specifies how the user of an application on a device is to be alerted. The maximum size allowed for a notification payload is 256 bytes, any notification exceeding this limit will be discarded. An example of a notification payload could be the following: { "aps" : { "alert" : "Message received from Bob" }, "acme2" : [ "bang", "whiz" ] } 43

72 The format of a notification message can be seen in figure 15: Figure 16. Notification message format. [APPL13] To send a push notification, the provider must first create a unique SSL ceritificate for the application through Apple Developer s ios Provisioning Portal. Then, the provider must connect to the APNS using the SSL certificate, construct the payload for the message, send it to the APNS, and then disconnect from it. After that, the APNS will send the notification message to the device indicated in the payload. Figure 17. Push notification from a provider to a client application. [APPL13] APNS JAVA LIBRARIES Since Slypter s back end is written in Java Enterprise Edition, all the payloads will be constructed using Java, so a library is needed to do so. There are two main libraries to send APNS push notifications in Java: java-apns 44

73 javapns The main problem of both libraries is that both projects contain bugs reported long time ago which have not been solved. However, Slypter s notifications are very simple and after testing both of them, java-apns has worked perfectly, delivering all the intended notifications without major problem. Hence, the library Slypter will use to send push notifications to users is java-apns. 4.5 SLYPTER S BACK END IMPLEMENTATION The main purpose of Slypter s back end is to release the front end from having to perform any business logic or having to interact with any database. The reason to do so, is that Slypter also has a website where the users can check their events and perform the same operations they can do in the ios application. Therefore, there is a need for a server where the information is processed, avoiding code duplication. Moreover, using a common back end for both environments means using the same database, so that there are no inconsistencies between both platforms USE CASES The back end must be able to process any request that the client sends to the server, so each and every possible use case must be contemplated by the back end. Whether the user wants to simply check his daily tasks, create a new event, or send a message to one of his contacts. This petitions must be handled by the back end, using the frameworks studied in the previous sections. 45

74 Some of the possible use cases that the back end must be prepared to process could be the following: Figure 18. Some of Slypter use cases BACK END ARCHITECTURE Using the frameworks that have been studied above, the back end is able to handle any request that can be made by the client. The back end s architecture is divided into three basic layers: Controllers: these classes are the ones that will receive the user s request. Depending on the request s URL and on the HTTP method 46

75 of the request, the controller will decide which class of the next layer will process the request. Services: once the controller has decided which service will handle the request, it will pass it to one of the services. These classes contain all the business logic, so they will take care of performing whatever the user wants to do. They are the ones in charge of interacting with the database (through DAO classes), handling exceptions, etc. Data Access Objects (DAOs): these classes are the only ones that can interact with the database directly. They provide an abstract interface so that services can use them without exposing details of the database. How the three layers interact with each other when a new request arrives to the back end can be seen in the following figure: Figure 19. Slypter s back end workflow. 47

76 4.5.3 USED FRAMEWORKS The three layers explained above take full advantage of Spring Framework and Hibernate. For example, all of the DAO classes use Hibernate to access the database, and with the power of JPA the amount of code needed to perform a SELECT operation or an UPDATE is drastically reduced. Moreover, the three layers use Spring Framework to reduce code complexity. Each class has its own interface that is declared as a bean in the Spring configuration file. If one of the controllers needs a specific service, it does not need to create a new one, since Spring will automatically give it to the controller using dependency injection. DAO classes benefit from Spring s dependency injection too, since to communicate with the database Hibernate needs to create a session that is provided by the SessionFactory, a class which is also injected by Spring. Another thing that Slypter s back end uses is Spring s aspect-oriented programming. With AOP, DAO classes no longer need to worry about transaction management, since using annotation in the method from the service class that will call the DAO tells Spring exactly what it should do. This leads to less complex code and helps separating cross-cutting concerns from the rest of the program. However, there is still one last issue where Spring s aspect-oriented programming has proved to be very useful when developing Slypter s back end. Whenever a user sends a message to another user, the service class needs to call the corresponding DAO to add that message to the database, but there is still one more thing to be done. If a user receives a message, a notification from Apple Push Notification Service should arrive to that user s ios device. To do so, the service class could directly call the class in charge of sending notifications to the APNS, but this 48

77 would lead to duplicating code whenever a notification should be sent to the user. Therefore, using aspects, services that need to send a notification to a user do not need to code the call to the class in charge of sending notifications to the APNS, since it will be Spring the one that, with the aspects declared, will know when exactly to call that class so that the user receives a notification CONCLUSIONS The developed back end offers a powerful REST API that is able to handle any request that could arrive from Slypter s front end. With the frameworks used along with the architecture divided into three layers, very readable and maintainable code has been produced. Thus, if any problem arises or any modification or improvement needs to be made to the back end, it would require little development time. Moreover, the technologies used to program the back end make it a very robust and scalable system. 49

78 50

79 Chapter 5 SECURING THE APPLICATION Security is one of the major concerns in every software application, especially in web applications. Measures must be taken to ensure that the information residing in the server is protected, since information is one of the most valuable assets in software applications. Every user that wants to use Slypter must identify himself with a username and a password, and only after a successful login will he be able to see all his information, his events, his friends, etc. But not only should the application be protected against unknown users, it should also prevent users from accessing to the private information of other users. However, securing an application which needs to connect to the back end for each and every single piece of information is no simple task. Every petition must travel through the internet to the back end, when it is most vulnerable, so several considerations must be taken into account when securing the back end. 5.1 RESTFUL AUTHENTICATION Probably the most common issue when securing a RESTful application, is that one of the main characteristics of REST is that is stateless, so the server is not allowed to keep any session. As a result, the client must always provide some mechanism of authentication to the server, even after successfully logging in to the application. Using cookies is not an option, since it violates one of the principles of REST. So if the client is the one that needs to keep all the session information, 51

80 and no cookies can be used, then other options need to be explored to decide which one suits best Slypter s requirements. A possible solution would be to send the username and password along with every request. This way, even if the server cannot keep track of each session, it would not mean any problem, as the server could authenticate the user for every petition. Nevertheless, this is the least secure solution, because this way sensitive information would be travelling over the network too frequently. Therefore, there are two possible solutions to tackle the problema. The first one is to use HTTP based authentication. Once the user has presented its credentials, the client software will compute the Base64 encoding of the credentials and include it in every HTTP request to the server using the Authorization HTTP header. This is a good option, but somehow the users credentials are still sent with every request, and this should be avoided. The second alternative is a token-based authentication. The user is prompted for the credentials once, and then the server creates a unique token that is then returned to the client. The client must provide the server with this unique token in every request, passing it as a URL argument or in the Authorization HTTP header, as in the previous alternative. This seems a better choice, since the user s password will only need to be sent over the network once, and the server is in control of the token in every moment. If the user has not used the application in over a month, the token can be deactivated automatically for security reasons, and the user would need to introduce his credentials again. In figure 19, the client presents its credentials to the server, sending its username and password. Then, the server computes a unique token and sends it back to the client. From now on, the client must send the authentication token to the server in every request in the Authorization header. Failing to do so will result in an error message that will send the user back to the login page. 52

81 Figure 20. Authentication token: user login. With the authentication token, the client can ask for any resource to the server. The server will use the token to identify the user that is making the request. This way, it is the client that keeps all the session information, not the server. Figure 21. Authentication token: logged user. 53

82 5.1.1 AUTHENTICATION TOKEN To create a secure authentication token, it must meet two requisites: it has to be unique, and it should be as random as possible to protect the back end from unwanted attacks. If the token is not unique, then the server would not know which user is the one making the request. As for the randomness, if the token of user A can be guessed by user B, then user B could pretend to be user A and gain access to his information. Ensuring that the token is unique is not a complex task: adding the username to the token and a second value that must be unique. This second value, since Slypter will only work in ios devices, should be an identifier of the device the user is using. Every ios device (iphones, ipads and ipods) has a unique device identifier (UDID) which is a 40-character string, so this value will also be added to the token. To make the token as random as possible, a universally unique identifier will also be included. A UUID is a 128-bit number used to uniquely identify an object on the internet. Java contains a function to create a random UUID using java.security.securerandom, which is cryptographically strong, using 122 bits to ensure randomness. Finally, when the token is being created, a timestamp is appended at the end. One of Slypter s authentication tokens could be the following: Figure 22. Slypter s authentication token example. 54

83 The next step to make Slypter s back end completely secure against unwanted attacks is to protect every controller from every request that does not include the token in its HTTP headers. This can be achieved by checking in every controller whether the request contains or not the authentication token, but that would mean code duplication. Security is a cross-cutting concern, so using Spring s aspect-oriented programming would be the best option. There is a Spring module especially designed for security, called Spring Security. 5.2 SPRING SECURITY Spring Security is a security framework that provides authentication, authorization and other security features for web applications. Since it is based on the Spring Framework, it takes full advantaje of dependency injection and aspectoriented programming. Security is handled by this framework in two different ways: using servlet filters to secure web requests and restrict accesses, and using AOP to secure method invocations. Spring Security allows the developer to restrict access to users depending on their privileges, by indicating a way to authenticate a user and the role the user has. There are several ways to authenticate users: Declaring users, passwords and authorities directly in the Spring configuration. Authenticating users against a relational database using JDBC. LDAP-based user repositories. OpenID decentralized user identity systems. 55

84 Central Authentication System (CAS). X.509 certificates. JAAS-based providers. Servlet filters will intercept every request, and it will restrict access to URLs specified in the configuration file to users who have the role that has been indicated in the file. With aspect-oriented programming, Spring Security provides also methodlevel security. Securing methods implies that these methods can only be invoked by a user who has the required role, raising an exception otherwise. Combined with servlet filters, Spring Security allows developers to control every aspect of a web application s security. 5.3 SLYPTER S IMPLEMENTATION OF SPRING SECURITY As has been stated before, the main issue when developing Slypter s back end is the statelessness of REST. If the server is not allowed to keep any session of the client, then the client will always need to provide a way of identifying himself. The solution is to use an authentication token, and only allow users with such token to access the back end. By using Spring Security, every request can be intercepted and, with the authentication token, decide whether the petition is valid or not. To do so, some security rules must be established in the security configuration file. Every request to Slypter s back end falls into two categories: unlogged users trying to log in to the application, and logged users trying to access their information. There are no premium users, administrators or anything that requires any special privileges. Therefore, there are only two different roles when accessing the back end: unlogged user and logged user. 56

85 As for the URLs, only one should be available to both roles: the one to make log in. All other URLs can only be accessed by users that already have logged in. Hence, there are two different security rules in the configuration file. One of them allows every user to access the log in controller, so that they can successfully log in and receive the authentication token. The second rule is more complex, since it needs to check whether the user has a valid token or not. To solve this problem, a custom filter has been programmed that gets called whenever the user makes a request to a URL different to the one used to make log in. The custom filter intercepts every petition, processes it, and depending on its outcome, it will raise an error or let the request reach the controller. To decide whether the petition is valid or not, the filter grabs the request headers and checks if the Authorization header exists. If so, then it validates the token by checking in the database if the token exists and all its fields are correct. After the token has been validated, the user has been correctly authenticated and therefore is added to Spring Security s SecurityContextHolder, which is the class that associates a security context with the current thread. Therefore, the request will then be able to access the controller it needs to perform its task. If the request does not contain an Authorization header, or the token is invalid, the application would answer with the following error: Unauthorized: Authentication token was either missing or invalid.. The process of user authentication through the authentication token can be seen in figure 22. Once the user s request reachs the back end, it is intercepted by AuthTokenProcessingFilter. The filter checks if a token exists in the HTTP request, and if so, it delegates to TokenUtils to check whether the token is valido r not. This class extracts the username from the token, and gets the token corresponding to that username from the database, returning a boolean to TokenUtils. Finally, if the token is valid, the filter will add the authenticated user to the current security context by calling SecurityContextHolder. 57

86 Figure 23. Authenticating a user with a token sequence diagram. After completing the process, the petition will go through to the destination controller and perform the desired action. If anything goes wrong during the process, an exception will be raised and the client will need to log in again, in order to receive a new authentication token. 5.4 SECURE SOCKETS LAYER After solving the statelessness problem of the REST back end, and completely securing the application against attacks, there is still one last issue that could make Slypter vulnerable. The whole security of the application relies on an authentication token that the user must present to the back end with every petition to gain access to it. This 58

87 token ensures that the user is correctly identified and allowed to do what it needs to do. However, if someone can steal one of these tokens and start making requests with that token, he would be able to obtain information about the user he is usurping. Therefore, there is one last issue that needs to be addressed when securing Slypter, which is ensuring that the token cannot be stealed. Whenever a new request is made to the server, the authentication token will travel in plain text and can be easily read by anyone who is sniffing the network. One last mechanism must be implemented to encrypt the token when it is being transmitted over the internet, such as Secure Sockets Layer DESCRIPTION Secure Sockets Layer (SSL) is a protocol to allow secure communications across the networks between two participants, protecting against eavesdropping and tampering. SSL uses asymmetric cryptography for authentication of key exchange, symmetric encryption for confidentiality and message authentication codes for message integrity. The Hypertext Transfer Protocol can be layered on top of the SSL protocol to provide secure HTTP connections, known as HTTPS (the s stands for secure). The HTTPS protocol works exactly the same as the HTTP protocol, but adding SSL security features, encrypting the connection between client and server HOW IT WORKS To begin a communication using SSL, both parties need to negotiate a session key that will be used to encrypt every message. The session key is negotiated using asymmetric cryptography. 59

88 Asymmetric cryptography is a system that requires two different keys, one of them secret and the other one public, both of them mathematically related. One of the keys is used to encrypt the message, while the other one is used to decrypt it. The public key can be published without compromising security, although the private one must never be revealed. Figure 24. Asymmetric encryption. [MDSN01] Both the sender and the recipient have their own private key, both of them different. However, they are mathematically related to a public one which is known by both of them. The public key allows each of them to encrypt the message so that it can only be decrypted using a private key. Security Sockets Layer uses the above system to negotiate a session key that will be used by both parties to encrypt and decrypt messages. This key will be used both to decrypt and to encrypt messages. To negotiate the key, a handshake procedure is used. It consists in the following: The client sends a ClientHello message to the server. 60

89 The server responds with ServerHello message indicating SSL options. The server sends its certificate to the client. The server sends a ServerHelloDone message concluding its part of the negotiation. The client sends session key information (encrypted with server s public key) in ClientKeyExchange message. The client sends ChangeCipherSpec message to activate the negotiated options for all future messages it will send. The client sends Finished message to let the server check the newly activated options. The server sends ChangeCipherSpec message to actívate the negotiated options for all future messages it will send. The server sends Finished message to let the client check the newly activated options. 61

90 Figure 25. SSL session key negotiation. [SSLA12] Once the handshaking protocol has successfully ended, both the client and the server possess a key to both encrypt and decryypt messages (symmetric encryption). The reason why the server sends its certificate to the client in the third handshaking message is to verify its identity. The client can match the server s Certification Authority against its list of trusted CAs. If the issuing CA is trusted, the client will verify that the certificate is authentic and has not been tampered with. Once the handshaking protocol has successfully ended, both the client and the server possess a key to both encrypt and decryypt messages (symmetric encryption). The reason why the server sends its certificate to the client in the third handshaking message is to verify its identity. The client can match the server s Certification Authority against its list of trusted CAs. If the issuing CA is trusted, the client will verify that the certificate is authentic and has not been tampered with. 62

91 5.4.3 SSL IN SLYPTER To prevent attackers from stealing other users authorization tokens, every petition to the back end will be done using HTTPS, to ensure that the information travels through the network encrypted. By forcing SSL connections, Slypter is protected (at least partially) against every type of attack. The server is configured to redirect HTTP traffic to HTTPS with Spring Security s configuration file. Moreover, the web server where Slypter s back end is run, Apache Tomcat, has been configured to support SSL by modifying the server.xml file. Finally, as discussed in the previous section, the server needs a certificate so that the client can verify its identity. A self-signed certificate has been created to start using SSL for now. Nevertheless, in a not so distant future, an SSL certificate will be purchased from one of the leading authorities such as Verisign or Symantec, since using a self-signed certificate may lead to several warnings and exceptions when using SSL, as the client cannot really verify who the server is. 63

92 64

93 Chapter 6 SLYPTER S RECOMMENDER SYSTEM As has been stated above, Slypter is an application that learns information from the user and from this information is able to propose new events that the user could find interesting. Since Slypter will also be a social application, there will be public events in which any user can participate. Depending on whether the user accepts these public events or declines them, the application will learn in order to propose better events to the user in the future. To achieve this, Slypter s back end will have another module which is a recommender system. This recommender system will be updated each time a user accepts or declines an event that has been proposed to the user. By doing so, the application will learn from all of the users of the application, so that its proposals will be better suited for each user. 6.1 RECOMMENDER SYSTEMS One of the main applications of machine learning nowadays are recommender systems or recommendation systems. These systems goal is to predict what rating a user would give to an element they have not yet considered, using a model built from the characteristics of an ítem (content-based approaches) or the user s social environment (collaborative filtering approaches) [WIKI03]. Over the last few years, these recommendation systems have become extremely common. For example, Amazon recommends new books to the user looking at what books the user has purchased in the past. These systems have a 65

94 huge potential, being these systems responsible for a huge part of Amazon s revenue. But not only Amazon uses this systems, there are other examples such as Netflix, Apple s Genius, and so on. Recommender systems are information filtering systems, which suggest interesting resources to users based on their preferences, and what resources they have liked or disliked in the past. Using this information, the system will be able to propose new resources to users thare are likely to be of interest to the users. Figure 26. Recommendation systems. [RECO12] When developing recommender systems, there are two different approaches: Content-based filtering: these methods use characteristics of the items to be recommended, recommending resources that are similar to the ones that the user has liked in the past. 66

95 Collaborative filtering: this approach is the most used one. It collects large amounts of data to analyze users behaviours and it uses this information to predict what users will like based on their similarity to other users. 6.2 CONTENT-BASED RECOMMENDER SYSTEMS As mentioned earlier, this recommendation systems are based on information and characteristics about the items that are going to be recommended. Therefore, to use this approach, a set of features must be defined and each item must be given a value for each of these features in order to be analyzed by the recommendation system. Given the set of features, the system will predict which resources the user will find interesting according to the items that the user liked or disliked in the past. To illustrate this, lets consider the following example: Movie User 1 User 2 User 3 User 4 Ghost Titanic 5?? 0 Love Story? 4 0? Star Wars Blade Runner 0 0 5? Table 7: content-based filtering example. 67

96 The recommendation system s goal would be to predict the rating that the users would give to the movies they have not yet rated. Depending on the value predicted, then the system would decide whether or not to recommend the movie to the user. Since this example is about the content-based approach, then a set of features is needed to predict the user ratings. In the previous example, there would be two features: romance and science fiction. Each movie has a vector with values for each of the features: Movie x1 Romance x2 Science Fiction Ghost Titanic Love Story Star Wars Blade Runner Table 8: content-based filtering set of features example. With these set of features, the objective of the content-based recommendation system is to learn a parameter θ ( j) R 3 for each user j. Once this parameter has been obtained, then it would be a simple problem of linear regression, where the rating for movie i of user j would be: (θ ( j) ) T x (i) where x (!) would be the vector with the values of the features for each movie i. Since the problem has now been reduced to a linear regression problem, the objective is to minimize the difference between the user ratings and the 68

97 predicted ratings for each of the movies they have rated. Therefore, to learn θ!, the following equation must be used: where y (!,!) would be the rating user j gave to movie i, and r(i,j) would be whether the user has rated or not the movie. The overall expression to calculate the θ parameters for all users would be the following: Finally, after calculating all the parameters, the last step would be to predict the ratings each user would give to the movies they have not yet rated. Then, if the predicted value is above 3 for example, then the system would recommend the movie to the user, since it would probably be of interest to that user. Nevertheless, using content-based recommendation systems has several drawbacks, specially in Slypter. In order to use these recommender systems, there needs to be a set of features, and each item needs a value for each of the features. However, it is not always possible to extract a set of features for all of the possible items, or sometimes when a new item is added some of the values for each of the features may be unknown. This problem is aggravated when the number of possible features is too large, which is the case of Slypter. Events can be of any kind, from a concert to a visit to a museum, so a better approach would be one that automatically extracts 69

98 the features that it may find relevant. Moreover, if a user creates a public event, having to specify values for each of the features would make the application unusable. 6.3 COLLABORATIVE FILTERING HOW IT WORKS With collaborative filtering, the algorithm does not know which value each feature has for any of the items. Thus, the objective is to learn automatically the values for the set of features. In this approach, the goal would be to learn all of the x (!) values we already had in the content-based recommendation system. To do so, in the collaborative filtering approach, each user gives the application its θ vector. This means that each user tells the application exactly how much he likes each of the different types of items to be recommended. With the θ parameters, the algorithm would need to find wich x (!) values, after applying the same equation as before: (θ ( j) ) T x (i) give the same results as the ratings given by the users to each item. To learn the feature vectors, the objective is to minimize the following equation for each x (!) : 70

99 Whereas the overall function to find all of the feature values given the θ parameters would be: Therefore, in the previous approach the feature vectors are used to learn the θ parameters, whereas this approach is exactly the opposite: given the θ parameters, learn the x (!) values. Thus, the problem is which one comes first: learning x (!) from the θ parameters or learning θ from x (!) values. To solve that dilemma, what can be done is to guess an initial random θ, and from this random θ parameters learn x (!). After this, a new set of θ is calculated using the x (!) learned, and so on. This will converge to a reasonable set of features and a reasonable set of parameters that can be used to recommend new resources to the users. The only problem of this new approach is that going back and forth between x (!) and θ is not very computationally efficient. Thus, there is an algorithm that can be used to solve for both parameters simultaneously: where J( ) is the cost function, and the objective of the learning algorithm is to minimize it. 71

100 6.3.2 GRADIENT DESCENT In order to minimize the cost function, the method used is the gradient descent, which is an optimization algorithm to find a local minimum of a function. The way this algorithm works, is by taking steps proportional to the negative of the gradient of the function at the current point: x!!! x! α f(x! ) where α is the learning rate. After a certain number of steps, the gradient descent will converge to a local minimum of the function. An example of how gradient descent works can be seen in the following figure: Figure 27. Gradient descent example. [WIKI04] 72

101 6.3.3 SLYPTER S RECOMMENDATION SYSTEM When recommending new events in Slypter, the algorithm used is the collaborative filtering approach. It consists of the following steps: Initialize x (!) and θ (!) to small random values. Minimize the cost function using gradient descent. Predicting whether a user would find interesting or not a certain event. A difference between Slypter s implementation and the movies example used above, is that in Slypter s public events there are no ratings. Therefore, instead of using values from 1 to 5 (for example) when using the algorithm, only the values 0 and 1 are considered. Whenever a user declines an event, this will be computed as a 0, and when the user accepts an event, this will count as 1. Hence, when the recommendation system predicts a value of over 0.75, this means that it is highly likely that the user will find the event interesting and accept the event, so the system will recommend this event to the user. Another thing that the recommender system used in Slypter does, is suggesting to the user up to 5 similar events to the one they are currently looking at or that they have previously liked but have not accepted or declined yet. To do so, it simply computes the distance between the feature vector of the current event and the x (!) vectors of all the events, and present to the user the 5 events with less distance, meaning that they are more similar: x! x! Finally, there is one last issue that has not been addressed yet. The algorithm used to recommend events in Slypter requires some interaction from the user in order to work. This means that until a user accepts or declines a public event, the algorithm will not be able to propose events to the user. If Slypter does 73

102 not suggest events to a user, then the user will not accept or decline them and therefore the algorithm will never learn from that user and it will never work for new users. To solve the problem of users that the system does not have any information about them, there is one last thing that can be added to the algorithm to improve it and allow it to work for these users: mean normalization MEAN NORMALIZATION When a new user starts using the application, the recommender system does not have any information about events that this new user has previously accepted or declined. This means that, when minimizing the function the algorithm is using, the output of the θ parameter for that user will always be 0. With the θ parameter being a vector of 0s, then the equation used to predict whether the user will find the event interesting will be 0, and therefore no events will ever be recommended to that new user: (θ ( j) ) T x (i) The goal of mean normalization is to solve this problem by offering new users events depending on the amount of people that have accepted those events in the past, by computing its mean. If there are 4 users that have previously rated 4 events, and a new user starts using Slypter, then the following situation would occur: 74

103 Event User 1 User 2 User 3 User 4 User 5 Music festival ? Museum visit ? Comic convention ? Anime convention ? Table 9: mean normalization example. The data from the previous table can be seen in the following matrix: Y =! # # # # " ???? $ & & & & % Now, a mean vector is computed by ignoring the last row, the one where there are no values:! # µ = # # # " $ & & & & % Finally, a new Y matrix would be computed by substracting each row its mean. Therefore, the new Y matrix would be the following: Y = " $ $ $ $ # , ???? % ' ' ' ' & 75

104 As can be seen, now each row of the new Y matrix sums up to 0. Now, the predicted rating for each event would be computed in a slightly different way. The equation is the same, but now the mean for each event needs to be added: (θ ( j) ) T x (i) + µ i By using mean normalization, predictions for all users that have already accepted or declined events will remain the same. However, new users will receive recommendations based on the mean of the events. Therefore, the predicted values for the new user from the previous example would be:! # # # # " $ & & & & % This means that Slypter s recommendation system would recommend the first event to the new user, since it is the only one that reaches RESULTS To see how the algorithm previously described works, a large amount of real data is needed. Since that data will not be available until Slypter is released and real users start to use the application, some tests using random data have been carried out. For example, one of the tests consisted of randomly creating a 100x10 matrix, where 100 is the number of users and 10 the number of public events that could be recommended to each user. This matrix had around a 20% of -1 values, which means that the user of row i has not yet rated event j. The other 80% where values 1 and 0 randomly generated using a normal distribution. As explained 76

105 earlier, a value of 1 indicates that the user accepted the event, whereas a 0 value indicates that the user rejected it. After running the collaborative filtering algorithm, the θ parameters for user 1, for example, where the following:! $ # & # & # & # & # & # & θ (1) = # & # & # & # & # & # & # & "# % & The user from the example had rated 7 out of the 10 public events used for the test. After estimating the rating the user would give to each of the events he had not been recommended, the ouput was: Event 3: Therefore, this event would not be recommended to the user since the threshold is Event 5: Again, this event does not reach the required 0.75 in order to be proposed to the user. Event 9: This event would appear in the recommendations screen to user 1, since the algorithm estimates that this user would accept the event with a probability of more thatn The number of features used for this example was 10, and the learning rate of the gradient descent was 0.3. This example, as well as the other tests that have been carried out, is only used to test whether the algorithm works or not. However, to check its efficiency when recommending events to users, real data is 77

106 needed. Therefore, until the application is officially launched and real users start giving some feedback to Slypter s collaborative filtering algorithm, there is no real proof that the recommended events are really interesting to the user. Another thing to bear in mind is that, in order to get the algorithm running, the first public events will need to be recommended to every user, since there is still no data available to make estimations. After some significative data has been collected, the algorithm will be able to start predicting whether a user will find an event interesting or not, and Slypter will stop recommending every single event to all of the users. 78

107 Chapter 7 IOS FRONT END One of the main objectives of this project is to develop an ios application that will connect to the back end discussed in previous chapters. The front end application will allow users to keep track of all the events they need to do in their daily routine, as well as letting them communicate with other users to create events with their friends. However, the ios application will not contain any of the business logic of Slypter, since it will be delegated to the Java EE back end. Therefore, whenever the user presses a button in the app or navigates to another screen, the application will need to communicate with the server to fetch all the necessary data and display it to the user. The main reason to avoid coding business logic in the front end, is that Slypter will also have a website with the same functionality as the ios application, so it would make no sense to write lines of code to achieve the same goals in both places, resulting in millions of lines of duplicated code. Therefore, the application to be developed will need to make a request to the server to obtain all the data the user needs. The communication between the server and the front end will be via REST, as mentioned before, due to all the benefits it offers over SOAP-based web services. 79

108 7.1 NATIVE OR WEB BASED APPLICATION? Before building Slypter s ios front end, several factors need to be taken into account. There are two kinds of applications that are very used nowadays, which are native applications and web based applications, and each of them have their own advantages and disadvantages WEB BASED APPLICATIONS Web based applications are applications that run inside the browser of the device, Safari in the case of ios. They are written in HTML and Javascript and generally cannot access iphone resources, such as contacts, calendar, photos Moreover, these type of applications cannot access hardware features either, so they cannot take full advantage of the accelerometer or camera. Storing information in the device is another thing that cannot be done with these applications. However, these applications have several advantages. Users do not need to go to a store or marketplace to download and install the app. Moreover, the same code can be used across all platforms. Another great advantage is that all users use the same version, without the need of having to update the application every time a new version is released. A comparison between web based and native applications can be seen in the following figure: 80

109 Figure 28. Comparison between web based and native applications. [SIXR12] NATIVE APPLICATIONS Native applications run on the operating system of the device, ios. They are written in Objective-C, and can use every feature of the device. Developing native applications have several advantages, but these applications are not portable to other platforms, and require a longer development time than web based applications. Furthermore, native applications can be designed to present a better user interface and consistent with what the users expect and are accostumed to on that particular device. As discussed in chapter 3, ios has a Push Notification System, which allows the user to be notified when the application has new information waiting for him. Sending notifications to the user can only be achieved with native applications, not with web based applications. 81

110 Nevertheless, building native applications have also some important drawbacks. Users need to go to the Apple Store or to the marketplace (Android), look for the app, download it and finally install it. Whenever a new software version of the application is released, the user needs to download it and install the application once again. Another thing to bear in mind when developing native applications, is that they need to be programmed in a specific programming language, that varies from one operating system to another. For example, to develop ios applications, the language that needs to be used is Objective-C, whereas Android applications are developed in Java. However, web based applications can be written in HTML and Javascript and be used indistinctly in every operating system, since it is accessed in a web browser. Developing an application in a specific programming language may lead to a longer development time, but it also has its own advantages. Native applications are generally faster than web based applications, since they are optimized for the specific device where the app will run COMPARISON BETWEEN BOTH KINDS OF APPLICATIONS As exposed above, both kinds of applications have its own advantages and disadvantages. The issue is which one should be used, since both of them are appropriate in different scenarios. The business requirements and the required functionality of the app determine which one should be developed. 82

111 ios Native App Web Based Application Portable? No Yes Access hardware Yes No features Access iphone Yes No resources Store data on the iphone? Yes No Speed Faster Slower Programming language Objective-C HTML/Javascript Need to install updates Yes No Table 10: comparison between web based and native ios applications. When the application is very complex or it needs to access hardware features or store information on the iphone, then a native app is required. However, when portability is of paramount importance or speed is not critical, then it is better to develop a web based application. To decide whether or not to develop a native application for Slypter s front end, several factors need to be considered: The application must store data on the device, since each time a request is made to the server, the authentication token must travel in the HTTP headers. Slypter users may want to take a picture to upload it to an event or to use it as a profile picture, so the app will need to access the camera. 83

112 For the time being, there will be no Slypter applications on Android, so portability is not an issue. Generally, ios users prefer native applications due to the more user-friendly GUI native applications provide. For these reasons, an ios native application has been developed as Slypter s front end. The programming language therefore has been Objective-C, and the IDE is Xcode. Figure 29. Apple s official IDE: Xcode. 84

113 7.2 RESULTS Since all of Slypter s logic and data will be stored on the server, the front end will need to access the back end each time the application needs to display new information to the user. Therefore, the front end will always work the same way: The user logs in, and the application calls the back end to check whether the credentials are valid. The server returns the authentication token in case the user data was correct. The application presents to the user the main screen, and makes a new petition to the server to retrieve the data to be displayed in this screen. From now on, everytime the user navigates to a different screen or modifies some data, the front end will need to communicate with the back end to retrieve the requested data or tu post or update the modified data USER LOGIN The first thing the user needs to do in order to start using Slypter in his ios device, is to present its login information to the application. After tapping the login button, the application will send the user s credentials to the back end. Then, 85

114 the back end will check if the received data are correct, and create a new authentication token that will be returned to the user. Since the authentication token needs to be sent in every request, it needs to be stored on the iphone so that the user will not have to present its credentials again unless he logs out or the back end decides to invalidate that token for any reason. Slypter will only need to store a few data on the iphone, so there is no point in creating a SQLite database for that purpose, but there is still a need for some mechanism to store few amounts of data that can only be accessed by the Slypter application. There is a class in Objective-C called NSUserDefaults, that allows objects to be saved in ios defaults system. Any data saved to ios defaults system will persist through application sessions and is available through all the code of the app. Hence, the authentication token will be saved using this class, to ensure that it is always available when the application needs to make a new request to the back end. After the authentication token has been successfully saved to the ios defaults system, the user can access the main screen and start using Slypter normally. The whole process of logging in can be seen in the following sequence diagram: 86

115 Figure 30. User login sequence diagram. This process only needs to be done once, since after receiving the authentication token the user will be able to navigate through the application without any problems. However, if a new version of Slypter is released, the authentication token would be deleted from NSUserDefaults and the user would need to log in once again, as well as if the user decides to log out. The login form can be seen in the following figures: 87

116 Figure 31. User login screen 1. Figure 32. User login screen 2. 88

117 7.2.2 MAIN SCREEN After successfully logging in to the application, the user will see the main screen, where a list of all the events will be displayed. These events will all be retrieved from the back end, and the user can select whether to display them on a list, to view the events on each day, or to view the whole month. In this screen, the user has many options. Tapping on an event will send the user to another screen where the details of the event (such as its description, duration ) will be displayed. Moreover, the user can add a new event by clicking the plus button at the top right corner of the screen. Finally, there is a menu that can be accessed through the whole application (except for the login form) that will appear whenever the user clicks on the button at the top left corner of the screen and whenever the user swipes the screen from left to right. This menu can be used to look for friends, go to the settings screen 89

118 Figure 33. Slypter s main screen. The main menu can be seen in the following figure: 90

119 Figure 34. Slypter s main menu OTHER SCREENS More examples of the user interface of Slypter s ios application are, for instance, the UI to add new events. To achieve this, the user can click on the plus button located at the top right corner of the screen. This will present a modal view controller where the user can fill in the necessary data to create the event. After doing this, Slypter will post the data to the back end. 91

120 Figure 35. Adding a new event. In the screen from the previous figure, the user needs to fill in the name, the description, and the date and time of the event. Moreover, the user can also invite his friends to the event by clicking on People Invited, and the location can also be added. However, these two steps are completely optional, so the user may as well skip it. As for the date and time of the event, the user can select it from the following screen: 92

121 Figure 36. Selecting the time for an event. The user can see a list of his friends to check their profiles from the Friends option in the main menu. The list displayed would be: 93

122 Figure 37. Friends screen. 94

123 Chapter 8 CONCLUSIONS AND FUTURE DEVELOPMENTS 8.1 CONCLUSIONS This final project consists in the development of an ios application that may help people in their daily routine. By allowing users to keep their agenda on a software tool that optimizes their free time, they can focus on other things that may be more important than having to worry about keeping up to their tight schedules. With the Artificial Intelligence techniques used to make Slypter an intelligent agenda that not only allows the user to add events, but also proposing new events that the user could find attractive, it makes Slypter a very useful application that can be used by everybody no matter their age. Moreover, by developing a RESTful back end, the communications between the front end and the server are much faster than with any other kind of web services. REST web services along with JSON provide fast communications so that the user finds a pleasant experience while navigating through the application. Another thing to bear in mind is that with the usage of advanced frameworks such as Spring and Hibernate, the development time has been drastically reduced. Since Hibernate helps the programmer simplify every interaction with the database, less code is required to deal with the mapping between Java objects and relational entities from the MySQL database used in this project. 95

124 8.1.1 BENEFITS OF SPRING As for Spring Framework, there are two key factors that make it one of the most useful frameworks nowadays. First of all, its Dependency Injection results in loosely coupled code so that each component of the system does not need to know almost anything about other components. Therefore, if a class needs to be changed, this change will not affect the rest of the program, one of the main reasons why loosely coupled code is very important in object oriented environments. Secondly, aspect-oriented programming also offers several benefits to the developers. By allowing programmers to isolate cross-cutting concerns such as transaction management into separate modules, it significantly reduces code complexity. Furthermore, separating cross-cutting concerns from the rest of the program also leads to less duplicated code, and improves code readability and makes the whole program easier to maintain. However, apart from dependency injection and aspect-oriented programming, Spring Framework offers much more benefits to Java developers. Apart from Spring Core, Spring offers many modules for specific purposes. To develop Slypter s RESTful API, Spring MVC has proved to be a very useful framework when programming REST web services. Finally, there is one last Spring module that has been used when developing Slypter s back end that has also helped in the development process of the back end. Spring Security is one of the best frameworks available to secure a Java Enterprise Edition application, due to the authentication, authorization and other security features it provides. Slypter s back end has proved to be very secure to unauthorized access thanks to this framework, since it allows the developer to program security interceptors that will check that every single request to the server is valid, rejecting the request otherwise. 96

125 8.1.2 REST As stated above, working with RESTful web services is a great option when dealing with communications between two endpoints. Nevertheless, after developing a back end with a RESTful API, some considerations are to be taken. These web services provide fast communications between the front end and the back end, without having to send any additional information such as the WSDL used in SOAP-based web services. Moreover, REST web services allow the back end to deliver the data in almost any format available, such as JSON, XML, CSV Another important feature about REST is that it is resource-oriented, and it makes it much easier for clientes to consume these web services. This results in greater scalability, since if new requirements arise, such as developing a new front end for other devices, there would be no need to modify the back end. It helps developers organize the application, no matter how complex it may be, into simple resources. Summarizing, the main advantage of REST web services is its simplicity. Despite this, there is one important feature that REST does not cover and that is the reason why there are still many developers that still prefer SOAP-based web services over REST: security and reliability. RESTful web services have no built-in standards for security or reliability, so applications where security is of paramount importance, these type of web services is still not the most suitable option. One of the main reasons why making a RESTful application secure is so complicated, is its statelessness. Since the server is not allowed to store any session data of the user, there needs to be some mechanism so that the user can identify for every request. However, after developing Slypter s back end, several ways to address this issue have been studied. Using an authentication token or sending the user s 97

126 credentials encrypted in every request are possible solutions that would make RESTful web services secure. Furthermore, using Secure Sockets Layer to encrypt all the communications between the client and the server adds even more security to a REST application. To sum up, communication between two endpoints over the network is something complex that needs to be studied carefully to choose the option that best suits the application. RESTful web services have proved over the last few years to be one of the best options available, and more and more applications are starting to benefit from them. Important network services such as Twitter are a clear example of this. Although REST still has some disadvantages, it is nowadays the best way of communicating a client to a back end. 8.2 FUTURE DEVELOPMENTS After completing the objectives for this project, there are still several things that could be done to improve Slypter. At this moment, the application developed troughout the project is aimed to all iphone and ipod Touch users, but in a not so distant future, the goal is to reach every user that possesses a smartphone. Moreover, Artificial Intelligence is something that is constantly evolving, and therefore there are still many things that can be done to improve Slypter s recommender system, so that users find this option still more useful. If users are willing to introduce in a software application all the events they do in their day to day, they will want the application to be as secure as possible, since if another user could see those private events, this invasion of privacy would make people turn away from using Slypter. Therefore, although the actual security system implemented in Slypter s back end is secure, further research must be performed to ensure that it is completely safe and secure. 98

127 In conclusion, the future developments in which Slypter be focused at the time being would be the following: First of all, a new front end could be developed to target not only iphone and ipod users, but also ipad users, so that all ios users can use Slypter. Before building the ipad application, it would be studied whether to build a brand new application for ipads, or if it would be better to modify the existing application so that it could be a universal application for all ios devices. If Slypter is successful among ios users, using the RESTful API developed in this project, new applications could be developed so that users of other operating systems can also use it. For example, Android has significantly increased its market share over the last few years, so developing an application for these devices would help Slypter more users. Moreover, there are other operating systems to be considered, such as BlackBerry, which would also be studied to see if it would compensate developing an application for them. The SSL certificate used to authenticate the server is self-signed, which may lead to certain problems, since the server s identity should be verified by a third party. Therefore, a new SSL certificate will be purchased from a Certification Authority such as VeriSign. As well as using a verified SSL certificate, there should be more things that can be done to improve security. Hence, new security features will be analyzed and tested to ensure that Slypter s back end is secure. 99

128 Once Slypter has been officially released, several tests will be carried out using real data to improve Slypter s Artificial Intelligence. 100

129 REFERENCES [WALL11] Spring in Action. Walls, Craig. Manning. [MCCO04] Code Complete 2. McConnell, Steve. Microsoft Press. [HARR12] Pro Spring 3. Harrop, Rob. Apress. [WIKI01] Last access on April [WIKI02] Last access on March [WIKI03] Last access on July [WIKI04] Last access on July [SPRI01] Last access on May [APPL13] Last access on June

130 [HIBE13] Last access on March [SMVC11] Last access on April [MSDN01] Last access on April [SSLA12] Mutual-SSL-Authentication. Last access on May [SIXR12] Last access on June [RECO12] Last access on June