CSE 403 Spring UDub Mail. Gabriel Maganis Sachin Pradhan. April 04, 2006

Transcription

1 CSE 403 Spring 2006 UDub Mail Gabriel Maganis Sachin Pradhan April 04, 2006 Operational Concepts Scenario Paul Wall, a UW student got admitted into the CSE department and gets address. He ends up with another addition to his set of accounts {Hotmail, Gmail, UW, Yahoo!}. He is tired of keeping track of all these but can t afford to get rid of them as well. He thought of the forwarding service but he also wants to be able to send messages with his CS account. Paul uses the lab computers a lot and wants to be able to check his s in one interface. UW campus computers do not utilize user profiles such that students settings are loaded when they login to a machine. As a result, Paul Wall cannot take advantage of desktop clients such as Microsoft Outlook Express and Mozilla Thunderbird that offer such features. Problem Unified Distributed (UDub Mail) is a web based service that provides its users with the ability to manage their s from multiple existing accounts. The system is designed mainly for University of Washington (UW) students who use the computing services provided in the various labs on campus, but can be easily extended to support anyone who is subscribed to multiple service providers (ESPs). The main goal of UDub Mail is to simplify the task of checking and/or managing s from the multiple ESPs that its users are subscribed to. UDub Mail maintains an account for each user that contains the information about the ESPs they are subscribed to. UDub Mail users can log in to an intuitive user interface (UI) to view and manage s from each of the ESPs that they they have setup. Users can check or delete from their Inbox or other folders they have setup on the mail server, compose and send using the ESP account they choose and if time permits, other customizing tweaks such as automatically insert signatures to their . The UDub Mail system can be compared to UW s Webpine except it allows its users to manage multiple ESP accounts and has an arguably nicer UI. UDub Mail does not serve as an alternative to desktop clients for heavy users since it does require the overhead of the web server. As a result, it does not provide services such as SMTP and IMAP or POP3 and does not store its users s but just displays them. 1

2 System Requirements Client The client side of the system requires a web browser to access the website on the server side. UDub Mail users would need to know the following information about their ESP in order configure the system to include that account: Incoming mail server i.e. user.mail.cs.washington.edu. Outgoing mail server i.e. smtp.washington.edu. Incoming mail server protocol i.e. IMAP. UDub Mail also provides a UI for viewing s and a (simple) text editor for composing s. Server The server side of the system hides all the grunt work of management from the user. It supports ESPs that utilize the IMAP and POP protocols. The server should support secure authentication of clients. The server requires a database from which it stores and retrieves user information such as usernames, passwords and corresponding ESP settings. The server handles the following tasks: 1. Checking The server should fetch all the new s from each of the ESPs the user has configured. 2. Composing and sending The server should handle all sending tasks using the user specified ESP s outgoing mail server to send the Deleting The server should handle deletion task that would remove the specified from the mail server it is from. The system is expected to handle a high volume of users so it must be designed taking into account concepts such as modularity, expansibility and encapsulation in mind. System and Software Architecture The system will have the following main components: 1. A web interface on the client side. 2. A database that stores user information like username, password and the ESPs they have configured. 3. A server that handles the management tasks requested by the client. The server will need access to the database. 4. Mail servers provided by the ESPs that its users are subscribed to.

3 The webpage provides the UI for the users to view and delete s, to compose and send s, and to modify account configurations. The UI serves as the connection between the user and the server where users can specify management tasks they want to perform. An initial sketch of the proposed UI is shown in the figure below. It is the server s job to handle, interpret and execute these user specified tasks. The server needs to access the database and communicate with the mail servers in order to execute the tasks sent by the client. It should also give the client some form of confirmation that the task was executed. The database holds all the necessary information for each UDub Mail user. And finally, the mail servers are a third party component of the UDub Mail system. They just need to do what they are designed to do. Maintenance and reliability of these servers are not under UDub Mail s control. The UDub Mail system architecture is illustrated below.

4 The server should be designed using an object oriented language such as C++ or Java. The database can be implemented using SQLServer or MySQL and accessed by the server through queries. The web interface can be implemented using technologies such as Javascript or ASP and HTML. However, we are exploring the possibility of implementing the web interface to be a component of the server, thus eliminating the need for an interface between separate implementations of the UI and server. Life Cycle Plan The major stakeholders of this service are: 1. Users who want a single service to access all the ESPs they are subscribed to. 2. Developers who designs and implements the system, some of whom, may become the System Administrators who maintains and provides upgrades/additions to the system.

5 Why is the system being developed? UDub Mail is being developed to provide users of public computing systems such as the UW s with the functionality of desktop clients for managing their accounts. It should be useful for users who are subcribed to multiple ESPs and would like a single interface to maintain them all. What will be done by When? 1. Design the project architecture (LCA). 2. Design the UI and the database schema. (Prototype 1) 3. Design and implement the server. Operational Prototype. (Beta Release) 4. Unit Testing, Functional Testing and Documentation. 5. Final Release. Feasibility Rationale Assumptions The user has multiple accounts. The main purpose of building this system is to simplify the task of managing multiple accounts. It only follows that its main benefactors are those who are subscribed to multiple ESPs. A user with only one account can still use UDub Mail but would probably be better off without it. Our primary assumption is that a majority of users who use services and public computing systems maintain multiple accounts. The system is reasonably fast. Having to check multiple accounts is definitely time consuming. On the other hand, using our system should simplify this task by eliminating the need for multiple interfaces. However, even if our previous assumption holds, if our system is not fast enough (mainly because it is web based) then users may not be motivated to use it. The user trusts our system The user has to provide us with information such as addresses, account passwords and s they compose would need to go through our server before they reach their destination. The user needs to trust our system and be willing to give up personal information in order to benefit from UDub Mail.

6 Risks Is the team familiar enough with technology to write secure/stable code. Any technology that has to do with the transfer of users personal information such as passwords and s via a network has to be secure to some degree. The reliability of our system depends highly on the developers coding skills and familiarity with networking and technology. Does the team have enough UI experience Everyone likes things that look good. Apart from being a useful and stable system, the UI and client side of UDub Mail should not only be simple and intuitive but also visually appealing. Security Risks? All systems have security risks. Since our system handles personal information of its users, these risks are magnified. Stemming from the first risk mentioned above are security risks such as malicious attacks and stability of our system.