WebSave web application

1. Networked software systems lab Department of Electrical Engineering, Technion WebSave web application Amir Bishara and Dorin Danial Supervisors: Roiy Zysman Dr. Ilana David

2. Agenda • Goals • Background and Motivation • Development stages • Design • Layers classes • Backup modules • Console Application • Testing • We Learned • Accomplishments • Improvements

3. Background and motivation • Web2.0 services are widely used to store data. • The services may experience downtimes, accounts may be hacked or data is simply deleted. This creates a need for backup.

4. Development stages • Defining project goals. • Defining the system requirements. • Writing use cases. • Defining classes and class diagrams. • Drawing UML diagrams. • Implementing the system. • Testing.

5. Goals • To create a simple, automatic, multi-service backup web application. • Design the system with the ability to add more services in the future without changing it.

6. System requirements • Registering new users. • Email confirmation. • Password encryption. • Login user to the system. • Forgotten password: • Send email. • Secret question and answer. • Updating user’s information. • Password confirmation. • Support admin user • Deleting users. • User search. • Change users details. • Showing statistics. • Adding a new service. • Backing up different services: • RSS, username-password based. • Displaying the backed up and trashed data. • Automatic update. • Stop automatic update. • Allow manual update. • Automatic database maintenance • Trash can. • Deletion of unconfirmed users • Manage user’s allowed disk quota. • Adding support for additional service types as plug-in.

7. System design

8. System design • Separation to layers forms • Modularity • The ability to change an implementation of a layer without effecting the other layers • Easier maintainability • reuse • Better control of the system • Separate responsibilities • Interface is needed to implement the plug-in mechanism

9. Layers roles • Database • Tables with relationships that save all the data. • Data Access Layer • Is used to transfer data between the BL layer and the Database. • Business Logic Layer • Performs all the logic operations of the system. • Graphical User Interface • Is used for user – system communication.

10. Database tables

11. Database Tables • Users • Contains users and their personal details • ServiceTypes • Supported services and their types • URL • Backed up accounts and URLs • Related to • Users through user_id • ServiceTypes through service_id • DATA • The backed up data • Related to • Users through user_id • ServiceTypes through service_id • URL through url_id

12. DAL

13. Dal classes • Automatically generated by sqlmetal as partial classes • Use special syntax • Interface function to BLL were written in a different file • Table relations are mapped to class relations using the XML mapping file (also generated by sqlmetal) • Access to database using Database class only • Connection class used for easier connection and code reuse

14. BLL

15. BLL CLASSES • User • Represents a user in the system. • Implements all user-related functions. • Is the connection to the Users class in the DAL. • Admin • Implements admin-related functions. • Database_BL • Is the connection to the URL, DATA, ServiceTypes classes in the DAL. • Could also be implemented in three separate classes.

16. GUI • Aspx pages contain .NET components (buttons, textfields, etc.) which activate an event. • The events call methods from the code-behind files. • All code is run on the server, returning only HTML code to the user’s browser.

17. System design

18. Backup modules • Are separated from the BLL to enable adding support for additional services without changing the system. • Backup interface • Between the system and 3rd party developers • Backup classes • Each class does a backup for a specific service type. • Developed independently of the system. • BackUpManager • Handles the backups and updates • Calls the backup classes • Retrieves data from the database (using BLL) • Performs trash can actions

19. ServiceInfo Account details needed for the 3rd party developrs. Update Functions for the 3rd party developers to save the information and additional data needed for the system BackUpClass Implemented (inherited) by the 3rd party developers. UpdateInfo 3rd party developrers fill this informatin Backup Interface

20. Backup interface classes • UpdateInfo • The information that the backup class saves in the system • Update • Contains the additional necessary information to store the update in the Data table (user_id, service_id, url_id) • Service functions to the backup class • SaveUpdate – stores update in the database • GetLastUpdate – returns last update of the account • MakeLastFalse – changes lastupdate field in the table • ServiceInfo • Contains the information needed by the backup class (URL, Username, Password) • Also containes Update class • Is sent to the backup class in the constructor • Backup class • Abstract • Does the backup • Two methods • CheckDetails – check if account details are correct • GetDataFromService – backs up the data

21. Backup classes

22. Backup classes • Connect to the remote service for backup • Are placed and loaded from a pre-defined folder • RSS • Backs up RSS services • Relies of RSS format for backup • Gmail • Backs up Gmail email account • Connects using POP3 protocol and SSL

23. Backup manager • Loads and calls the backup classes • Only class that handles backup and backed up information • Retrieves and deletes updates from the database • Is used by the console application for the updates

24. Console application • Jobs: • Automatic update. • Trash can.

25. Console application • Is scheduled to run in a desired frequency. • In each iteration • Actions are preformed on a constant number of users. • Services updates are made. • Deletes users that haven’t been confirmed within a week. • Deletes services and data that have been in trash can for a week. • Log files are created. • It goes over the user list of the database in a cyclic way.

26. Developing and Adding new service types • 3rd party developers • Download BackUpInterface.dll • Implement class • Create .dll for the class • Download website page template • Change template according to need • Send dll and webpage files • webSave admin • Place backup dll file in dll folder • Place webpage file in webpage folder • Login to website and add new service type

27. testing • Can be done automatically using testing projects • Not suitable with void-returning functions • Was done manually

28. We learned • Designing and developing a large software system • Object Oriented Programming • Web application and the layers separation • Working with • the .NET framework and Visual Studio • C# • LINQ • Relational databases • XML

29. accomplishments • All project requirements were met • Two service types were developed • Project book and user manual were written

30. Improvements • Change database tables to support more users • Better, more service specific, back up classes using service API. • Better GUI.