You are here:
(05 Nov 2008, PietVanOostrum)
---+++ Project contents The aim of the project is to write a distributed application with one of the techniques that is taught in the course (Java RMI/Corba/COM/XML-RPC/SOAP). The participants choose themselves which technique they want to use. They also choose which programming language to use. The project must be done with 2 or 3 persons. A group of 3 persons must do a slightly bigger version of the project than a group of 2 persons (see below). There are two projects. Each group can choose which one they want to do. The first one ([[Project1]]) is a Groupware system; the second one ([[Project2]]) is a multi-user game. ---+++ Security Your system should give some attention to security. Users that want to use the system should be authenticated, and no user should be allowed to work with data for which he/she is not authorized. In the design document you have to describe how this will be done. <p>In the final documentation of the project you must also explain what are the dangers of hackers/crackers trying to enter your system illegally (e.g. by connecting directly to sockets), and how this should be protected. It does not have to be implemented, however.</p> ---++++ Interoperability To make the concept `interoperability' more concrete for your design, you must make an additional (small) client for your server that is different in at least one of the following aspects: * Written in a different programming language. * Using a different distributed system technique. If you use *.NET* for the implementation the choice of just another programming language is not enough as you let *.NET* do the work. So you must then either choose a different protocol (other than SOAP) or use SOAP in a different way in one of the programs, e.g. by using a SOAP library. In general you should have to do some work for the interoperability, not let the system do it for you. This special client doesn't have to have the same functionality as the normal client; it just suffices to implement some simple function. E.g. one of the functions of your normal client or some statistics overview or management function. It also doesn't need a GUI, it is allowed to print something on the console. The important thing is the `proof of concept' of interoperability. The client should, however, be able to run on a different machine than the other clients or the server. How you implement this is up to you, e.g. the use of a special `conversion object' is allowed. ---+++ Design For the design the team has to make: * UML class diagrams, use cases, sequence diagrams * IDL for the distributed objects * Description of the design (so that another group can understand it) * You should indicate which objects are going to be used as remote objects and which ones will just be used locally. * There must also be an explanation of the security in your design as explained above. * Design presentations and discussions in week 39 ---+++ Implementation * User interface is the least important aspect, so don't spend too much time on it * Project presentations and demos (week 44) * Oral explanation by project group (week 45) ---+++ Documentation The final documentation should include the design, as it eventually was used (so including any changes that you made during the implementation), a description of how things were implemented, problems that you had to solve, the interoperability. Documentation about how to use the system can be kept brief. In the final documentation you must also explain what are the dangers of hackers/crackers trying to enter your system illegally (e.g. by connecting directly to sockets), and how this should be protected. It does not have to be implemented, however. ---+++ Planning In the first two weeks the group should make a design, consisting of a UML scheme and IDL definition. The IDL should be made even if you are going to use a system that doesn't use IDL, e.g. Java RMI. In those cases the IDL is just documentation. You can choose which kind of IDL to use (DCE, Corba, COM, or WSDL). Additionally you should indicate which objects are going to be used as remote objects and which ones will just be used locally. The interoperability part doesn't have to be included in the design document. <p>There must also be an explication of the security in your design as explained in the previous paragraph.</p> Furthermore see the [[CourseSchedule][planning schedule]]. ---+++ Submission You have to submit your project before Nov ??, 24.00. You should submit a zip file containing your source code and documentation.<p> <!-- Use the <a href="http://www.cs.uu.nl/docs/submit/" >submit page</a> to submit your project.</p> Fill in the loginname and studentnumber of one of the project members. Under 'Opgave' select 'Distributed Object Systems - project'. 'Aantal studenten' should contain the number of students in the project group. --> ---+++ Grading of the project A well working project will in general have a grade of 7-8, depending on the quality. More or less if it has additional qualities or shortcomings. See more details at the <a href="beoordeling.html" >grading page</a>. -- Main.PietVanOostrum - 03 Sep 2008
ore topic actions
Topic revision: r2 - 05 Nov 2008, PietVanOostrum
Distributed Object Systems
http://www.cs.uu.nl/education/vak.php?vak=gob Education page
Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding UUCS?