Master Arbeit

PROTOTYPING REAL-TIME
COLLABORATIVE APPLICATIONS
Submitted by :
Jibran Javed
Thesis submitted in partial fulfillment of the degree
Master in Media Informatics Lehr-und Forschungsgebiet Informatik 9 Computeruntersttztes Lernen RWTH Aachen University, University of Bonn
ABSTRACT
There is a growing recognition that the collaborative and cooperative work can play an important role in learning process. The idea to work in teams or pairs in school classrooms, the concept of computer clubhouses, online communities, shared workspaces, social-networking sites, and other after-school activities are some of the examples realizing this idea. The concept of Collaboration and Cooperation came from the fact; that doing things together in teams or pairs have a better effect, provide more productive learning experience, and bring the interest factor even in the least interesting areas, e.g., Science, Technology, Engineering, and Mathematics (STEM). Collaboration can work as a tool to provide fun and boost interest in STEM learning. To breathe life into this concept, the first step in these efforts is to make sure the vast and easy availability of learning applications and tools, provided with the real-time collaborative features, where the maximum benefit of collaborative learning and specifically with real-time collaboration can be achieved. Considering the widely recognized role of kids authoring tools and microworlds, and the effectiveness of real-time collaboration; the primary aim of this research is to introduce the concept and build the foundations of real-time collaborative kids learning tools to bring the benefits and effectiveness of real-time collaboration in kids learning process.
ii
ATTESTATION
I certify that this Thesis reports original work performed by me during Thesis, except for the resources and aids, which are indicated. All places, which are literally or in a general manner from published or unpublished writing, are cited in footnotes and reference section.
Jibran Javed
Aachen, 27.9.2011
iii
ACKNOWLEDGEMENTS
I would like to start expressing my sincere acknowledgement to my advisors: Prof. Dr. Ulrik Schroeder and Prof. Dr. Christian Bauckhage because they gave me the opportunity to research under their supervision. Mr. Philipp Brauner for his support, encouragement, and motivation during this thesis. I also want to thank the inspiration and courage; I received from my sister Dr. Shahnila Javed. I am keenly grateful and owe special thanks to Mr. Ali Tahir for his guidance and transmitted knowledge for the completion of my overall studies. The Nuance communication, Aachen for their HIWI room used for the network testing involved in this thesis. I would like to thank all people from software development communities specially www.stackoverflow.com. I would also like to thank the open-source developers, who have produced the libraries that the project relies on; namely Java3D, Kryo and MINA, Kryonet; and finally, Ahsan Muneer Gill for his outstanding proofreading. During my studies in RWTH, Aachen and University of Bonn, several colleagues, friends, and institutions collaborated directly and indirectly in my studies, I cant write the names of all, but I do thankful to all of them from the bottom of my heart for their warmth and love .
iv
TABLE OF CONTENTS
ABSTRACT ................................................................................................................................................... ii ATTESTATION ....................................................................................................................................... iii ACKNOWLEDGEMENTS .............................................................................................................................. iv TABLE OF CONTENTS ...................................................................................................................................v
LIST OF ABBREVIATIONS
......................................................................................................................... viii
LIST OF FIGURES ......................................................................................................................................... x 1. About ..................................................................................................................................................... 1 1.1. Background ........................................................................................................................................ 1 1.2. Introduction ....................................................................................................................................... 2 1.3. Motivation ......................................................................................................................................... 3 1.4. Collaborative ..................................................................................................................................... 4 1.5. Real-time............................................................................................................................................ 5 1.6. Goals ................................................................................................................................................... 5 1.7. Overview of Thesis............................................................................................................................ 6 1.8. Summary ............................................................................................................................................ 7 2. Literature Review ................................................................................................................................. 8 2.1. State-of-the-art ................................................................................................................................. 8
2.1.1. Real-time Collaborative Solutions and Opportunities.................................................................. 8 2.1.2. Pedagogical Repositories ..................................................................................................................... 9 2.1.3. Microworlds............................................................................................................................................. 9 2.1.4. Authoring Tools ................................................................................................................................... 11 2.1.5. Game Development............................................................................................................................ 14
2.2. Our Methodology ........................................................................................................................... 14

2.2.1. Language................................................................................................................................................ 15
2.3. Summary .......................................................................................................................................... 16
3. Design and Analysis............................................................................................................................ 17 3.1. Graphical User Interface ............................................................................................................... 19

3.1.1. Morphic .................................................................................................................................................. 19 3.1.2. Model-View-Controller (MVC) ......................................................................................................... 20 3.1.3. Analysis................................................................................................................................................... 21
3.2. GUI Packages .................................................................................................................................. 23

3.2.1. Swing....................................................................................................................................................... 23 3.2.2. Qt Jambi................................................................................................................................................. 24 3.2.3. Analysis................................................................................................................................................... 26
3.3. Design ............................................................................................................................................... 27 3.4. Networking ...................................................................................................................................... 29

3.4.1. Architectures ........................................................................................................................................ 29 3.4.2. Protocols................................................................................................................................................ 30 3.4.3. Distributed Computing ...................................................................................................................... 31 3.4.4. Custom Networking Solutions ......................................................................................................... 34 3.4.5. Analysis................................................................................................................................................... 38
3.5. Summary .......................................................................................................................................... 41 4. Implementation .................................................................................................................................. 43 4.1. A Compact Network Framework .................................................................................................. 45
4.1.1. Server-Factory...................................................................................................................................... 45 4.1.2. Client-Factory....................................................................................................................................... 47
4.2. Real-time Collaborative Physics Simulation ............................................................................... 48

4.2.1. Network Layer with RMI.................................................................................................................... 48 4.2.2. Application Layer with Swing and Java3D ..................................................................................... 54
4.3. Critical Review ................................................................................................................................ 61 4.4. Summary .......................................................................................................................................... 62 5. Testing ................................................................................................................................................. 64 5.1. Profiling ............................................................................................................................................ 64
5.1.1. Server-site Profiling............................................................................................................................. 65 5.1.2. Client-site Profiling.............................................................................................................................. 65
5.2. Network Testing.............................................................................................................................. 66

5.2.1. Wireshark.............................................................................................................................................. 66 5.2.2. Test-bed ................................................................................................................................................. 66
5.3. Throughput Evaluation .................................................................................................................. 67

5.3.1. RMI .......................................................................................................................................................... 68
vi
5.3.2. Customized Serialization and Java NIO......................................................................................... 70
5.4. IO Statistics...................................................................................................................................... 72 5.5. Round-trip Time Evaluation .......................................................................................................... 73 5.6. Summary .......................................................................................................................................... 75 6. Conclusion........................................................................................................................................... 76 6.1. Summary .......................................................................................................................................... 76 6.2. Future Milestones............................................................................................................................ 77 6.3. Personal Thoughts .......................................................................................................................... 78 6.4. Secondary Achievements ............................................................................................................... 78 References ............................................................................................................................................... 79
vii
LIST OF ABBREVIATIONS
ACA - America Competes Act API - Application Programming Interface AWT - Abstract Window Toolkit CAD - Computer Aided Design COM - Common Object Model CORBA - Common Object Request Broker Architecture CPU - Central Processing Unit CSCW - Computer-Supported Cooperative Work DCOM - Distributed Common Object Model EJB - Enterprise Java Beans EJS - Easy Java Simulation FPS - First Person Shooter GC - Garbage Collection GUI - Graphical User Interface GWT - Google Web Toolkit IDE - Integrated Development Environment IDL - Interface Definition Language IO - Input-Output JMS - Java Messaging System LAN - Local Area Network MINA - Multipurpose Infrastructure for Network Applications MVC - Model-View-Controller NIO - New Input-Output OOP - Object-oriented Programming ORB - Object Request Broker OS - Operating System OSP - Open Source Physics
viii
RAD - Rapid Application Development RMI - Remote Method Invocation RPC - Remote Procedure Call RTC - Real-time Communication RTT - Round-trip Time SIP - Session Initiation Protocol SOAP - Simple Object Access Protocol STEM - Science Technology Engineering Mathematics TCP - Transmission Control Protocol UDP - User Datagram Protocol VM - Virtual Machine WAN - Wide Area Network WYSIWIS - What You See Is What I See WYSIWYG - What You See Is What You Get XML - Extensible markup language XMPP - Extensible Messaging and Presence Protocol XUL - XML User Interface Language
ix
LIST OF FIGURES
Figure 1: A Scratch GUI demonstrating the creation of Physics Simulation, with its all possible Palettes...........................................10 Figure 2: Four different views of the EJS GUI. ..............................................................................................................................12 Figure 3: Agentsheets GUI with Worksheet as Simulation world and Gallery to Drag&Drop ..........................................................13 Figure 4: A comparison of Waterfall development and Agile development pertaining single iteration time.......................................15 Figure 5: A possible multiuser view of Scratch, demonstrating the real-time collaborative city building via multiuser interface...........18 Figure 6: A simulation designed from simulation authoring tool EJS in multiuser scenario with WYISWIS GUI. ................................19 Figure 7: A Block diagram summing up the MVC architecture and the role of each component. ....................................................20 Figure 8: Simulations designed with Java Swing Library.................................................................................................................22 Figure 9: A typical application layer of single user application based on MVC architecture. ............................................................23 Figure 10: An adaptation of Separable Model Architecture by a single Swing component...............................................................24 Figure 11: A detailed view of WYISWYG, Drag&Drop Qt Designer. .............................................................................................25 Figure 12: A typical real-time collaborative GUI (strict WYSIWIS) depicting the same state of GUI components and simulated objects among multiple clients..................................................................................................................................................................26 Figure 13: A typical Swing GUI component based on its quasi-MVC variant. .................................................................................27 Figure 14: A possible architecture depicting the decoupling and communication of Model and Controller in case of real-time collaborative application. ..............................................................................................................................................................28 Figure 15: A typical architecture of single user application after plugging network layer. ................................................................29 Figure 16: Benchmark illustrating serialization time leveraging state-of-the-art solutions. ...............................................................39 Figure 17: Bar charts presenting the Kryo benchmark in-contrast with some of its contemporaries. ...............................................40 Figure 18: A Layered structure representing the core elements of MINA design. ...........................................................................41 Figure 19: Class diagram depicting the design of Server-factory, using Factory-method pattern. .....................................................45 Figure 20: Class diagram representing the design of Client-factory, using Factory-method pattern. .................................................47 Figure 21: Class diagram depicting the remote publisher-subscriber design. ..................................................................................52 Figure 22: Class diagram representing the map of remote Publisher-Subscriber as the remote Model-Controller.............................53 Figure 23: The design of simple real-time collaborative simulation with RMI..................................................................................54 Figure 24: The Java3D Scenegraph representing the simulation world [5]. ...................................................................................57 Figure 25: Sequence diagram representing the sequence of basic operations involving main components. ......................................59 Figure 26: Component diagram demonstrating the deployment of Applications core components..................................................60 Figure 27: A real-time collaborative 3D Simulation demonstrating Ball Physics. .............................................................................61 Figure 28: VisualVM GUI presenting the profiling results using different perspectives.....................................................................65 Figure 29: Wireshark GUI displaying the transmission of packets from client to server and server to client using RMI.....................68 Figure 30: Graph showing throughput from client to server in-case of RMI (41 bytes). ..................................................................69 Figure 31: Graph showing Throughput from server to client (1196 bytes). ....................................................................................69 Figure 32: Wireshark GUI displaying the transmission of packets from client to server and server to client using Kryonet. ..............70 Figure 33: Throughput observed from client to server in-case of Kryonet......................................................................................71 Figure 34: Graph representing throughput from server to client (556 bytes). ................................................................................71 Figure 35: The average response time IO graph with customized serialization. .............................................................................72 Figure 36: The average response time IO graph with default serialization in RMI.........................................................................72 Figure 37: The average response time IO graph with default serialization in RMI..........................................................................73 Figure 38: Graph representing the RTT during transmission with RMI...........................................................................................74 Figure 39: RTT observed during transmission with custom serialization (Kryonet). .........................................................................74
Chapter 1
1. About
1.1. Background
Globalization of the world, technological advancement, rapid information growth, and the changing consumer lifestyle demand dynamic changes in Science, Technology, Engineering, and Mathematics (STEM) Education. Peoples expectations are getting higher and higher from the science and technology; and experts highlighted the need and significance of continuously evolving educational process, due to economic pressures and a greater number of students with diverse needs attending colleges and universities [34]. Taking an example of America, on behalf of their federal government, the initiatives to improve STEM are considered as a strategy to improve innovation and competitiveness. Research and development in science and related disciplines were made a priority with the passage of the America Competes Act (ACA) in Fiscal year 2007 [53]. The ACA committed $5.9 billion in FY 2007, and more than 136 billion over the following 10 years, to increase investments in R&D, strengthen education and encourage entrepreneurship and innovation [52]. It was also reported by the Commission on Mathematics and Science Education research from the Carnegie Corporation of New York for Advanced study: urges improvements in the teaching of math and science in the U.S. as central to preserving democracy and social mobility for our nations young people [53]. They also stressed on revising the teaching and learning systems, methods, and curriculum especially for mathematics and science to deliver excellent equitable math and science learning. [51]. A new report by McKinsey & the Company, also highlights the significant negative correlation between educational achievement gaps and national GDP [54]. The other researches also emphasized and pointed out the criticality of this problem to the governments, including recent policy reports [76]; and asked for new solutions other than conventional to overcome this problem and other evolving complications due to this.
Chapter 1
About
1.2. Introduction
STEM is the key to every nations ability to stand-by its young blood with the skills and knowledge needed to find better places in the global market. There isnt any doubt about the complexity of STEM concepts and their learning, but the conventional teaching methods, limited use of technology (as compared to the need of subject and topic) are some of the other prominent factors contributing to this problem. The kids are getting far and far from the science and technology, and the fear of STEM acquisition is being increased because of increasing gap between the technology and its adaptation [26]. To address these concerns, there is a significant need to work at grass-root level on the teaching and learning methodologies; in which the incorporation of new technologies, technological revisal of legacy applications, the introduction of the new ideas, and the development of new solutions are some of the evident ones [12]. In the 21st century, pursuing the non-traditional ways to approach such challenging problems: the invention of unconventional solutions and bringing-to-front the fresh ideas, the identification of isolated areas, and a closer look into formerly overlooked factors, such as fun, interaction and realtime collaboration in STEM education; are some of the ways to address such global problems and to achieve faster and effective results. To satisfy the immense need of new approaches to make the STEM education as interesting and playful as possible, among the various ways: the one way to bring the lost STEM interest in young generation is the incorporation of real-time collaboration. Nowadays, the role of real-time collaboration among diverse domains and professionals can easily recognize; and its potential to enhance future opportunities for every nation can be easily proof. Among the other factors, the collaboration is also one of the factors includes in the set of competencies, commonly referred as 21st Century Skills [61], which prepares the youth with critical thinking and problemsolving skills that are essential to apply STEM knowledge to real-world challenges. The concept of real-time collaboration came from the fact that doing things together in teams or in pairs boost interest factor even in the least interesting areas and have a better impact on various factors, e.g., learning and productivity [10, 37]. One of the examples of those least interesting areas is the acquisition of STEM education; which is considered in an alarming situation, as far as the human resource in STEM fields is concerned. One of the reasons of this alarming situation and scarce human resource is the steep interest level in STEM education. STEM education is considered one of the boring and dry areas, and losing its interest in the newer generation day by day. There is a huge deviation in the supply and demand of the human resource in STEM fields, what are the reasons? We have to start from scratch and need to find the root, to address this problem. There could be various reasons: from social, cultural, and economic perspectives for this, but as the computer scientists, we have to concentrate on what we could contribute to this and how. In academia, there are various visual programming tools, environments, and microworlds available. Still quite a visible lag in adaptation of fast evolving technologies and the rich concepts, e.g., real-time collaboration can be seen, which can be highly effective in this context. The real-time collaboration in learning can work as a stimulator, and an accelerator to increase interest factor in STEM learning. In order to execute this idea, the primary need demands the vast and easy availability of kids authoring applications and environment, provided with real-time collaborative features, where to work in the teams and cooperative learning can easily make possible. To fulfill this requirement, the research community seeks the role of software-development industry to develop the authoring tools especially for kids, which facilitates the development of real-time collaborative learning applications; and kids can gain the effectiveness of real-time collaborative learning.
Master Thesis Prototyping Real-time Collaborative Applications
Page | 2
Chapter 1
About
1.3. Motivation
The terms: multiuser, cooperative work, and collaborative learning, and their significance in real-life and computing world is quite evident [36, 82]. The core of this work is also governed by the significance of these concepts. Nevertheless, in this research, we step towards the employment of these concepts to more complex real-world scenarios and explore the fusion of them with other state-of-the-art solutions from other domains to address the fast evolving global problem, e.g., kids learning process. An immense amount of efforts has been done and going on, to make the learning process as much compelling as possible and promote the interest of STEM education in young pupils [38]. The microworlds and other kids authoring tools are also some of the prominent steps in those efforts. Although the microworlds [30] and other solutions are playing the cutting-edge role in kids learning process, but the fast evolving global changes demand more cultivation of ideas and inventions from the technology to strengthen the kids learning process. Among the several, the one way to derive new ideas is to derive the ideas from existing solutions, and an intelligent leverage of different realms. To have an example of acquiring more interest and more user involvement: a common realm of game development can be considered; in which the concept of multiuser is just exhaled to gain more interest, interaction, and involvement of participants in the game-play. To explore the effectiveness of such concepts in other areas, we employ the same concept of multiuserness (real-time collaboration) other than the realm of entertainment, e.g., games [39], to some constructive activity, i.e., the kids learning process [12]. Despite the diverse nature of products and applications with distinct features to make the learning process more interesting and intuitive for the kids; the capabilities to learn via real-time collaborative authoring or multiuser learning environment, where children can build the pedagogic material, i.e., educational games and simulation together; and the support to create multiuser applications seems still missing, and needs to be addressed for the effectiveness of real-time collaboration in learning process. The other crucial aspect of this research embarks on the significance of promoting re-usability and facilitation of resources in this context, i.e., frameworks [42]. Pursuing the role of existing game engines and frameworks, the efforts to bring even some single-user simulation or game authoring tool in the educational context are still not able to get any greater benefit from the existing resources because of the primary rationale and intent behind them. An isolation of frameworks is observed, to precisely support the kids learning applications, e.g., kids authoring tools, microworlds, in which a similar and a relatively recognized liability of game authoring tools can be taken as a reference. The game authoring tools and particularly the tools for serious or educational games; which are also considered the STEM promoting mediums because of their diversifying goal than the conventional games [18]; in-spite of belonging to a vast and recognized field of software development, i.e., game development; the comprehensive tools or authoring environments, to support the creation of serious games and explicitly in the real-time collaborative manner seem also in scarce; and demand more precise efforts for learning or similar perspectives [18, 26]. To bring the prolific outcomes, and address the discussed concerns for the upcoming global challenges, there is always space in research and development community. In the context of our research, we choose the integration of the rich concept: real-time collaboration [15, 40] in the conventional solutions, such as kids learning tools. Other than that, other secondary goals are also expected to be achieved as an outcome of this research and can also be effective for building the scalable and robust foundations for similar goals, which includes: the incarnation of new models and architectures for E-learning applications like microworlds, e.g., Scratch and Simulation authoring tools, e.g., Easy Java Simulation (EJS); to address precisely the requirements of kids learning applications. Master Thesis Prototyping Real-time Collaborative Applications Page | 3
Chapter 1
About
1.4. Collaborative
The Collaborative is derived from collaboration; so, we are emphasizing on the concept of collaboration. The Collaboration is a collective term. It can be defined as the cooperation of multiple individuals to fulfill a single goal. Going more in details, this cooperation being via computer and internet technology, divides into categories of real-time and non-real-time, which further open the door, for other concepts to stand under the hood of collaboration, i.e., synchronous and asynchronous communication [15, 49]. A typical scenario of asynchronous (non-real-time collaboration) embarks on the collaboration or cooperation of two individuals on the same task on different computers at the time t, but one individual is unable to see the changes of the other, until they combine or share the task with each other. On the contrary, in real-time collaboration, the two individuals, who can be in any part of the world, can see the work of each other at any point of time t, and they find the same state of the task without explicitly sharing, combining, or any other mechanism. As the real-time collaboration is also a collective term, it is characterized by the following ways of communication: Text Chat Multiuser Whiteboard Application sharing Desktop sharing Co-browsing Voice over IP Video and audio conferencing tools Design tools, such as Computer Aided design (CAD) data [22, 41] There is not any doubt, that the above ways of communication can facilitate the real-time collaboration and can be a part of some sophisticated real-time collaborative application [40]. Considering these features enough for real-time collaboration; and examining, whether they can play the integral role in learning applications, a simple example can be considered. In a normal classroom, where the communication is easily possible between individuals, considering the text chat as the primary way, crucial to communicate and enough for real-time collaboration does not make enough sense. Therefore, to decide the medium and the level of real-time collaboration is the matter of application domain, intention, and ones definition of collaboration [41, 42]. Going back into the theory of CSCW, the concept of shared context simplifies and aids the requirements catering based on theoretical proofs. The study revealed that the notion of shared context coincides with our approach; and our approach is also a variant of the shared context, in which the distributed processing of information includes; a shared view and collective operations on objects. The theory further elaborates: the significance of shared context for real-time collaboration and states: The design of shared context is very important for real-time collaboration. In CSCW applications, synchronous means that the users cooperate simultaneously, and are aware of this. Activities on shared data are immediately propagated to all participating users to achieve real-time behavior [36]. The first approach in the direction of a shared context is the so-called principle WYSIWIS. WYSIWIS is the acronym for What You See Is What I See and often used in the context of synchronous
Page | 4
Chapter 1
About
groupwares, that aims at a consistent presentation of shared information to all participants. It is considered, one of the important factors to resolve the confusion of situations perception among multiple users; and hence considered one of the crucial and important notions in synchronous cooperative work [41]. As an Example of WYSIWIS, the scenario of simple simulation can be considered, if the users observe the same state of objects, i.e., simulation world or objects, controls to manipulate simulation, and overall Graphical User Interface (GUI); irrespective of the time, when they join or start the application on their screens; and they explicitly know, that they are reading, and manipulating the same objects and controls, and any changes will propagate to all the connected users; then this will be considered as typical usage scenario of WYSIWIS Interfaces and play the role of backbone to achieve real-time collaboration, concerning the need of our and similar scenarios. The concept of WYSIWIS interfaces is quite analogous to our work and one of its intuitive realizations can also be seen in other realms of IT, such as computer games as multiuser games. Additionally, we also found WYSIWIS interfaces; the crucial part of groupware application; therefore, our work has also significance in the field of groupware applications and other associated fields.
1.5. Real-time
The term real-time is used in various contexts differently [28, 37, 40]. In our case, we are referring the real-time communication (RTC) as the communication, in which all users can exchange information instantly or with negligible latency. To make it clearer and precise, in the real-time system, if the event occurs on any of the clients at the time t, other clients should also be able to see the event at the time t [28, 49].
1.6. Goals
Considering the role of kids authoring tools and microworlds towards the efforts of making learning process more intuitive for children and the effectiveness of real-time collaboration in other areas [36, 38]; the primary aim of this research is to introduce and step towards the concept of real-time collaborative learning applications, e.g., Multiuser Microworlds, to get benefited by the effectiveness of real-time collaboration in learning process. Considering the basic engineering principles refactoring, re-usability, and re-engineering; the initial findings seem to be refuted the viability of realizing the Multiuserness into existing solutions; by the integration of the real-time collaborative feature, due to the complexity of engineering process, architecture; and other factors involved in the development process. Taking into account these facts, on the behalf of this research, the grounding and infrastructure for such applications (Multiuser Microworlds) in terms of approach, architecture, solutions, and the challenges; will be emphasized and discussed. To make the processes more effective and achieve the substantial results; a case study of the most likely scenario will be presented, to have a deeper insight into the development process; and to foresee the complexities involved in the realization process, which will implicitly contribute as a framework, to build the realtime collaborative applications in general. Other secondary aims, which will be achieved by this project, are: A first building-block, to introduce the concept of real-time collaborative authoring in learning application, tools, and microworlds, for collaborative learning. A motivation, demonstrating one of the possible application scenarios, for real-time collaborative realms.
Page | 5
Chapter 1
About
A test-bed for different network protocols, and distributed computing environment with least efforts. To highlight the contribution of state-of-the-art distributed computing, and Network libraries in developing real-time collaborative application. A case study presenting the likely scenario for agile development process in software engineering fraternity. Motivation to design new network protocols for specialized real-time collaborative working. Patronize the development of a multiuser application, by deriving new design patterns especially designed for network architectures, considering the needs of decoupling, and other network constraints. To provide a one-stop source to facilitate the distributed application developers in requirement gathering, scenario generation, technology selection and overall decision making considering the development of real-time collaborative applications.
1.7. Overview of Thesis

The thesis is structured in a way that the whole software-development process can be explained. It covers the whole software development process to sustain the readers level of interest and a continuous flow in reading. We started with a discussion on state-of-the-art technologies contribute in the similar context like microworlds and e-learning environments. Then, we discuss; how we approached to fulfill the underlying requirements, and explained the survey process to consider the existing software technologies to implement our solution. To achieve more concretization, in the following chapters, we explain; how the realization took place, both as a design and concrete implementation. At the end, the testing process; and a conclusion evaluating the work, suggested improvements, and other future directions; which could be undertaken are presented. Chapter 2, State-of-the-Art, examines some of the existing resources, concepts, ideas, that are also working towards the similar goals; and indirectly highlight the significance and motivation behind this work. Chapter 3, Design and analysis, demonstrates the requirement analysis phase and highlight possible factors involve in design, explores the role of existing frameworks and architectures, discusses the possible patterns, technologies and further highlight the reasons and implications for such design decisions. Chapter 4, Implementation, discusses how different network layers based on different technologies can be exploited, and a typical application based on the proposed architecture can be implemented. Chapter 5, Testing, briefly presents the testing process and the results, which can be achieved by implementing the corresponding the network layers and application layer. Additionally, it also presents the comparison and impact of different network solution on network performance.
Page | 6
Chapter 1
About
Chapter 6, Conclusion, concludes the thesis by sharing the experience gained, lessons learnt, and how well it managed to meet the initial requirements. Additionally, it discusses the future directions for such or related realms with the same goal and rationale; and identifies the areas, where this work could be further enhanced and productive.
1.8. Summary
This chapter presents the preamble of this work, by introducing the core factors, i.e., problem and motivation, which leads to any research. It elaborates, the two most important concepts: real-time and collaboration and their nature in this project. The chapter concludes by highlighting the primary and secondary goals to be achieved by this thesis, and a brief structural overview of the thesis in terms of chapters and their content. To have a look into what has already done to achieve the similar goals; the next will present the literature review.
Page | 7
Chapter 2
Literature Review
Chapter 2
2. Literature Review
2.1. State-of-the-art
As we emphasize the idea of real-time collaboration in learning applications, we will discuss the stateof-the-art, concerning the development of real-time collaborative applications and learning tools, e.g., microworlds, pedagogic authoring tool, where the idea of real-time collaboration or multiuser is most likely to bring the significant improvements and prolific results.
2.1.1. Real-time Collaborative Solutions and Opportunities

As discussed in section 1.3, the collaboration exists in various forms these days. Different application and domain exploit different form of collaboration according to their need. Most of them relies on the conventional ways of collaboration, i.e., text chat, video and audio conferencing and desktop sharing. Keeping in mind the same trend, software industry also contributed and offered various frameworks and online environments. The GoogleWave1 and Adobe LiveCycle Collaboration Service2, are some of the examples of such solutions, but they also focused on the same form of collaboration and also offered the application server for such collaboration features. In addition to that, the stand-alone real-time collaboration solutions are also introduced; which exploits the voiceover-IP or video-over-IP systems to attain the real-time audio or video communication, and instant communication systems to real-time text-based communication. Concerning relatively advanced and specialized efforts, the real-time collaborative editors are introduced via web-based services, such as GoogleDocs3 and as the applications: Adobe Buzzword4, Etherpad5[21, 27, 48] considering their generic purpose. However, industry seems to be neglected our desired means of real-time
1 2
http://code.google.com/apis/wave/ http://www.adobe.com/products/livecycle/collaborationservice/ 3 docs.google.com/ 4 http://www.adobe.com/uk/acom/buzzword/ 5 http://ietherpad.com/
Page | 8
Chapter 2
Literature Review
collaboration and particularly the significance of rich concepts, e.g., WYSIWIS for e-learning or similar context.
2.1.2. Pedagogical Repositories

The most conventional way for teaching STEM involving computers is the use of educational components. The teachers were used to develop or search those components according to their topic and distribute those as an applet or applications in class, but later to facilitate this process the software community contributed in this realm and introduced the concept of repositories to provide the pedagogic material as Java components at one shared place. They endorse the concept of facilitating STEM education by promoting the authoring, teaching, and publishing. The one of the projects endorsing the same idea, is known as, Open Source Physics6 (OSP). It facilitates the incorporation of users and developers, who are interested in physics learning and teaching; and employs the idea of providing ready-to-use Java components and applications. The OSP collection comprises of a huge variety of simulations covering the huge variety of physical phenomena. Endorsing the same concept of collaboration, AgentSheets7 also introduced the concept of Ristretto, which is built into AgentSheets; and lets you communicate your ideas through the web to the rest of the world. Some of the other efforts, which also belong to the same form of collaboration include: AgentSheets Behavior Exchange, which allows users to collaborate on simulations by gathering, annotating, and exchanging agents through a web-based repository of agents; Educational Software Components of Tomorrow8 (ESCOT) Collaborative Framework, to integrate and create new educational material; and the educational object economy (EOE)9, a collection of educational Java applets [3, 17]. Other than highlighting the role of computer-aided education and its role in the pasts classrooms, these projects signify the importance of collaboration between diverse stakeholders from different realm of science and technology from earlier days of IT. Considering these or similar efforts, the educational system seems stagnant in the adaptation of new technologies, such as real-time collaboration to incorporate the new ideas like real-time collaborative (multiuser) learning applications, i.e., serious games or simulations, real-time collaborative (multiuser) microworlds; and being the foremost cause of kids deprivation from STEM education.
2.1.3. Microworlds
Among the various research and scientific community efforts, the most prominent form of effort, we found is the idea of Microworlds. Among the various definitions of microworld, the simplest and comprehensive definition of microworld can be; a specialized learning environment to simulate, explore, and experience, the specific domain of knowledge with minimal instruction [30]. Since the introduction of this concept, various microworlds are introduced to explore the knowledge of different domains, in which one of them is Scratch, which emphasized the computer programming. Considering the computer programming slight non-traditional and more artificial subject for young pupils, most of the research and tools were developed in this realm, which caused the other STEM areas in isolation. Although the efforts are also made for other subjects, but those tools seem to be overlooked the concept of microworlds, which is most probably because of their target audience and the primary differences between an IDE or authoring tool and a microworld. The tool EJS is one of the examples
6 7
http://www.compadre.org/osp/ http://www.agentsheets.com/ 8 http://www.escot.org/ 9 http://www.eoe.org
Page | 9
Chapter 2
Literature Review
of such tools, which we will discuss in detail in section 2.1.4; as our inclination is about the fusion of both; rather than only on microworlds and learning the particular skill, i.e., computer programming. Considering the microworlds first, and specifically Scratch; Scratch is a programming environment for kids and uses the concept of Building-block, which also stem from the research on LogoBlocks. Being inspired by the LogoBlocks, the GUI of Scratch resembles with the Logo Microworlds GUI, in which the kids, so-called write code by snapping together blocks like the Lego bricks or puzzle pieces. Scratch facilitates the manipulation of rich media right from the environment rather than using thirdparty software, i.e., Photoshop, Premier, Acid Pro, etc.; and provide the interface to program the real-world physical objects, e.g., Motors, MIDI synthesizer, lights as the normal on screen virtual objects in computer programs and enable the input via sensors. To emphasize the sharing of thoughts, Scratch supports multiple languages and provides the site to upload and share the projects like other environments, e.g., AgentSheets [76]. On the Scratch website since it started, more than 200,000 people with the majoritys age between 8 and 17 years (peak at 13) have registered. Considering the site statics, the site has been quite active, receiving more than 1,500 projects a day and allowing kids from around the world to share their own interactive media. In less than two years, more than 50,000 people have uploaded around 350, 00 Scratch projects, ranging from dance projects to science simulations. For a brief idea, how does Scratch support the creation of such interactive applications, Figure 1 is presented to demonstrate the creation of simple physics simulation using Scratch.
Figure 1: A Scratch GUI demonstrating the creation of Physics Simulation, with its all possible Palettes.
Page | 10
Chapter 2
Literature Review
The principle that the cartoons and games can make programming easier to learn directly by programs and animated objects in the virtual world, beyond writing code or even without visual programming, and drag/drop; the tool called ToonTalk10 complies with this concept. It aims to replace computational abstractions by concrete familiar objects. Unlike many other learning environments, it supports long-distance synchronous communication and collaboration via birds that can fly to nests on other computers, and support the distributed design, exploration, and solution of a particular idea [23]. Greenfoot11 is another worth experiencing environment, which addresses the beginner level programmers rather than kids and put emphasis on learning object-oriented programming via Java. It provides metaphors to denote and ease the grasp of programming concepts, and the drag and drop GUI components to facilitate the authoring of playable stuff, i.e., games, simulations, to provide the opportunity to learn programming in a playful manner. The concept of gallery is introduced to provide the capability of cooperative and collaborative work via sharing and accessing the created projects. Among several others, one of the environments, which incorporate simulations for creative learning, is StagecastCreator12. It enables users to create lively interactive simulations for Math, Arts, Science, etc. StagecastCreator can be effective for any subject, any grade level, and students with the diverse learning capabilities. It provides the kids the capability to learn by building games and simulations of small microworlds in a language-less, direct-manipulation manner. The discussed projects belong to the same species and the primary goal, but the major concentration of differences occurs at their level of complexity, different trade-offs, and target audience.
2.1.4. Authoring Tools

The other category, which also gets prominent to promote the teaching and learning science curriculum, is simulation authoring tools. These tools are provided with a GUI to design simulations and physical phenomena independent of users programming skills. One of the realizations of this idea is the project called EJS. EJS is a free, open-source modeling tool, to generate Java code automatically. EJS is a full-fledged simulation authoring tool, especially designed to create simulations by the users with least programming knowledge. The tool is provided with a set of components, considered essential for any physics simulation and drag and drop capability is provided to design the simulation with least efforts.
10 11
http://toontalk.com/ http://www.greenfoot.org/ 12 http://www.stagecast.com/
Page | 11
Chapter 2
Literature Review
Considering the ease-of-use, the separate GUIs (views) are provided (see Figure 2) to deal with the logic, look, and customization separately, and can be seen from Figure 2. Emphasizing on the reusability, the simulations created by EJS can be saved as an Extensible Markup Language (XML) file for later use, which makes possible the enhancement or extension by the other people and the distribution as an application or an applet for further use [24, 47].
Figure 2: Four different views of the EJS GUI13.
On the importance of incorporating collaborative interaction within applications GUI, VisAD14, is another project. The project promotes the developer to employ the simulations, to investigate and demonstrate interactively different physical phenomena, via collaboration. It provides ready-made Java components, which are designed specifically for visualization and interaction with scientific data. In addition to that, VisAD provides the mechanism to plug-in the collaboration using Java distributed computing in those Java components, so that collaborative visualization and interaction can be achieved. The generic graphics layer is capable to render the objects in various dimensions. Being
13 14
http://fem.um.es/Ejs/ http://www.ssec.wisc.edu/~billh/visad.html
Page | 12
Chapter 2
Literature Review
developed especially for simulating data; the library also supports data sources and provides the support to visualize data in various formats. Having all of these features, the project is undoubtedly a valuable asset, but for the beginner level programmers, primary physics lectures, and simple experiments; the usage of this library is found relatively difficult [44, 46]. Other worth discussing interactive simulation authoring tool, AgentSheets; enables you to create simulations and publish them on the Web. AgentSheets is a simulation authoring tool, as shown in Figure 3, addresses the huge target audience, to create interactive simulations and games. AgentSheets is a legendary environment, came into being after ten years of research; and introduces the concept of agents (object/sprites), spreadsheets (grids), Java authoring technologies, and the programming paradigms, i.e., Tactile and conversational programming, under one hood. AgentSheets with its built-in simulator provides a thought laboratory, which lets you give life to your ideas, and simulate real-world scenarios without the need of any prior programming and modeling knowledge. Its unique features encompass all the functional and non-functional requirements of some authoring tool for educating kids, which include compatibility, portability, interoperability, interactivity, and multimedia support, etc. [2].
Figure 3: AgentSheets GUI with Worksheet as Simulation world and Gallery to Drag&Drop the simulated objects.
Page | 13
Chapter 2
Literature Review
2.1.5. Game Development

Among the state-of-the-art open-source and proprietary game authoring tool and engines. First, we hardly found the open-source game authoring tool and especially multiuser game authoring tool. Second, when we surveyed the gaming engines for the architectural details and design, as an exemplary solutions; we felt: the selection of gaming engine specially in Java, satisfying ones needs is a quite daunting task for the novice developers because of the bulk of gaming engines with a bulk of redundant features, which makes them hard to use and complex rather than reusable [9,17]. As our aim is not to develop some sophisticated game, we did not research deep into those, but we tried to adapt the features from them, which can help us in making our framework simple and easy-to-use authoring tool for STEM applications (especially serious games).
2.2. Our Methodology

Considering the agile development becoming a traditional way of software development and mainly based on iterative development processes, we will follow the agile development strategy. Agile development according to Wikipedia, defines as the a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams [48]. Although the agile development strategy complies specifically with the needs of commercial software development [19], but we considered the iterative and incremental approach also well suited, for the researchbased projects; especially like ours: with vague and diverse nature of requirements, limited time constraints, requires an active participation of stakeholders from various domains, and with no or the least monetary resources [85].
Page | 14
Chapter 2
Literature Review
To have an idea of agile effects, one of the important factors and especially concerning the masters thesis, a comparison of agile development strategy with the traditional development models, i.e., Waterfall especially in terms of the length of development cycles can be seen by the Figure 4 [74].
Waterfall development
Agile development
Figure 4: A comparison of Waterfall development and Agile development pertaining single iteration time15.
To get the most of the agile strategy, the maximum number of iterations will be conducted, which will be possible in the time constraints of the thesis. To have a closer look into areas and the implications of different approaches, a single scenario as a case study will be discussed in each iteration; which will give us the opportunity to experience in-depth the related issues, complexities, and overhauling of other sub-domains involve. Considering the application of computer simulations, to facilitate the grasp of complex STEM concepts, in microworlds and authoring tools. For the case study, realizing the significance of simulations and considering the development of physics simulations (independent of complexity and scale) capable to cover the most use-cases involved in the development of our desired form of applications; we choose the development of physics simulation as a case study to cover all typical scenarios involve in development process.
2.2.1. Language
Considering the non-functional requirements, we will pursue Java for the implementation, and believe that Java is capable enough to cope with most non-functional requirements because of its versatile features. The other reasons to use Java are based on the fact, that there are only a few resources available due to reason that Java is considered slow for real-time scenarios, i.e., games and
15
http://www.ibm.com/developerworks/architecture/library/ar-archman1/index.html
Page | 15
Chapter 2
Literature Review
simulations. Considering the nature of this project: open source, research-based; and emphasizing on a research-based prototype rather than, development of commercial game product, we overlooked the slowness factor. Other than that, we also considered the benefits of Java as easily writable and understandable, because of the higher level; and the compatibility and portability on various platforms, to get benefited in the future [5, 72].
2.3. Summary
In this chapter, we present the state-of-the-art, to have an idea about intuitive and compelling tools for learning; and to foresee the challenges and complexities in case of integrating or creating such tools with real-time collaborative feature. The AgentSheets, Scratch, and Alice are good examples to predict the resources and different constraints involved in overall development cycle, even in the case of developing single user applications for the underlying purpose. The literature revealed that the AgentSheets is the zenith of 10 years research and development, and the efforts to make it a pervasive tool are still continued. We also came to know that most of the features, which we are going to consider from beginning, such as 3D environment, are integrated after more than decades planning [3]. The Alice documentation states that 3 to 4 years are invested on the conceptualization of Alice and then the development cycle is started to bring something substantial from the concept [33]. Reviewing about the development of Scratch, which document about the development process in this way The Scratch project is a multiple year effort.Implementation of the first prototype began in January of 2003, based on the design decisions of previous year. [74] Later, the role of game development is also portrayed, which closely relates to our work, concerning development methodologies. Finally, the chapter is concluded, by highlighting the methodology to be followed in this thesis; and presenting a brief overview of the language selected, to narrow down and approach closer to the engineering process, in the next chapters.
Page | 16
Chapter 3
Design and Analysis
Chapter 3
3. Design and Analysis
Based on the reviewed state-of-the-art microworlds and other authoring tools; in this chapter, we will portray one of microworld, as a multiuser microworld, which supports the creation of games or simulations by multiple users simultaneously. We choose the Scratch for that; and discuss a simple scenario to present an idea and clear our intent. We took an example of physics simulation from Scratch sample projects, to be specific to the pedagogical context.
Page | 17
Chapter 3
Design and Analysis
Figure 5: A possible multiuser view of Scratch, demonstrating the real-time collaborative city building via multiuser interface16.
The aim of the Figure 5, is to convey the idea that the GUI of a single user application, such as microworld consist of a single or multiple conventional GUI components, e.g., frame or panel can also work as the usual game-world of a multiuser game; where two or more players can participate and manipulate the game entities in the real-time collaborative manner. Endorsing the same concept of multiuser game with a difference of entities and their layouts, a microworld can also be used as a multiuser environment to promote constructivism in children rather than only fun and gaming. An example can be realized, by the above (see Figure 5) city building in the real-time collaborative way, which mainly involves: building the houses, hospitals, schools and real-world objects, etc.; but conveys various physics concepts, e.g., gravity, mass, collision, velocity, acceleration, etc., in a more realistic, interactive and educative way. Until here, we discussed only the real-time collaborative authoring process involving learning applications specially microworlds. Discussing this, unfold other forms of real-time collaboration and one of the closely related embarks on the multiuserness in the created application itself, which came as a result of real-time collaborative authoring process.
16
http://scratch.mit.edu/
Page | 18
Chapter 3
Design and Analysis
Although this further adds, an immense amount of complexity in the engineering process; and endorse the idea of first developing and then leveraging the effect of real-time the collaboration by using the ready application, but its worth researching for the comprehensiveness of this thesis. An example can be seen by Figure 6, which portraits a multiuser physics simulation created supposedly by the multiuser EJS.
User A
User B
Figure 6: A simulation designed from simulation authoring tool EJS in multiuser scenario with WYISWIS GUI17. As now we have highlighted, the two primary goals of this thesis, which embrace the real-time collaborative learning environment (a multiuser microworld or a multiuser authoring environment), and the creation of multiuser applications leveraging these tools. Although we emphasize the realtime collaborative GUIs (multiuser GUIs); nevertheless, the importance of single-user GUIs cannot be neglected. Therefore, it would be worth examining, some best practices, and patterns from existing GUI development methodologies for the development of real-time collaborative GUI. Additionally, this process will also be helpful to identify, which existing GUI packages can be effective to derive the GUI framework for real-time collaborative GUI; and can be transformed in real-time collaborative GUI package.
3.1. Graphical User Interface

3.1.1. Morphic
The major development to aid the educational processes via GUIs, started with Smalltalk-80. Smalltalk-80 is considered, one of the pioneer languages featuring object orientation, introduced by
17
http://www.um.es/fem/EjsWiki/Main/ExamplesThrowingABall
Page | 19
Chapter 3
Design and Analysis
Xerox PARC. Due to its ease-of-use, it is considered widely for facilitating the learning process. Later, pursuing the same rationale, an implementation of it came with the name of Squeak, which made its name in the rich GUI development, especially for the educational purpose because of its flexibility and versatility. The most of the credit of Squeak popularity goes to its architecture. Squeak builds upon the architecture, designed specifically to address the requirement of rich GUIs in Smalltalk, by the Palo Alto research center in 1979. The architecture name was Model-ViewController (MVC), which took from the three main classes in the design. Interestingly, to realize this versatility; the environment with the name Squeak was also introduced, which provides the concrete implementation of MVC; and later, the other environments were also introduced for better understanding of architecture, and its concrete implementation [21, 67]. As the Squeak achieved a reputable place in the realm of GUI development, various other architectures were also introduced as the packages for Squeak and presented as products and tools. The efforts to improve the predecessors and to provide a better architecture is kept going, among which one of them with the name Morphic became popular. The name of Morphic evolves from the name of one of the core class Morph. The objects in Morphic need to be inherited from this class, to simulate the real-world behavior with the built-in looping mechanism, known as stepping mechanism. Later, as the successors of Morphic, other variants and implementations were also introduced, to provide more flexibility and rich user experience, in which one renowned is a Tweak [21].
3.1.2. Model-View-Controller (MVC)

As discussed, the philosophy of the MVC is ancient and coined from Smalltalk developers [67]. Although in-spite of an old philosophy, the developers of other languages adapt the philosophy of MVC, for which the example can be easily realized, in the form of advanced GUI packages, i.e., Java Swing and Microsoft Foundation Classes. The MVC embarks on decoupling and separation-of-concern by dividing them into three fundamental elements, which can be seen by the following diagram (Figure 7):
Figure 7: A Block diagram summing up the MVC architecture and the role of each component18.
18
http://www.oracle.com/technetwork/articles/javase/mvc-136693.html
Page | 20
Chapter 3
Design and Analysis
The Model The Model is considered to provide the functionality; the objects behave in real life. The programmer depicts the behavior of objects in the real world and in their minds, by writing the logic in applications Models. The Model can be a computational approximation or an abstraction of the realworld process or a system. The Model contains the state of the process or system; and how the process will work with different parameters and in different conditions. Taking again the example of physics simulation, the effect of gravity to keep the things on the ground, and decreasing the gravity making the things free in the air, will be set by the Model. The Model can also vary in its tasks, i.e., there could be also the Model possible only for managing the overall GUI (multiple Views, multiple Controllers), which is common in all commercial and full-fledged application of a single user application; and there is also the Model possible, which is responsible only for running the simulation on one view [77]. The View The part of the application, which presents the GUI for user interaction and displays the real-world objects and information, is called the View. The View is considered to display the information get from the Model, and presents the GUI components (controls), to control the object on the screen. The Controller updates the View, as the change occurs in the Model and present to the user, there can be one main View, which is comprised of several other sub-views. There could be several Views possible of the same Model; the View normally performs the same purpose and persist the same location in the distributed applications, as in the single user applications [77]. The Controller The Controller provides the functionality how the application will perform in-case of a certain event triggered from the View , the ability to accept the inputs via the View is provided by the Controller , the Controller send further the input to the Model, and after processing got the result from the model and transfers back to the view to display. Although the user interact with the View, to change the settings or interact with the application, but this is handled, by the Controller. Taking the concrete example, which needs to change the gravity in the simulation scenario, the job of the View is just to present the slider, but when the slider will be moved by the user, the Controller will be responded and the input will be sent to the Model for further processing [77].
3.1.3. Analysis
Considering the separation-of-concern and the granularity of problem achieved by the MVC, the MVC seems the promising option and can help more than any other framework to implement the solution pursuing Java for implementation.
Page | 21
Chapter 3
Design and Analysis
To explore the MVC further in the context of our requirements, we examine its application in single user applications and found the transition from single user application to multiuser application a possible way to proceed.
Figure 8: Simulations designed with Java Swing Library1920. Examining the simple simulations, as shown in Figure 8; we realized, the View: as an overall GUI, i.e., display area and components, i.e., buttons, sliders, textboxes, etc.; the Model: to run the applicationlogic (ball-physics); and last but not least: the Controller: as a listener to user actions via view and to process further. Therefore, considering the role of all these elements, MVC can also be realized in our scenario, and play a crucial role to implement the application layer for real-time collaborative applications. In the general development strategies, the designing of any application persuade the use of tiers to define the responsibilities of different components, as shown in Figure 9. Normally, three tiers are pursued to create a typical application. The first layer is considered the Presentation layer, and renders the GUI; while the second layer, residing in the middle work as a mediator between the first layer; and the third layer, which is considered to provide the application logic.
19 20
http://stackoverflow.com/questions/345838/ball-to-ball-collision-detection-and-handling http://www3.ntu.edu.sg/home/ehchua/programming/java/J8a_GameIntro-BouncingBalls.html
Page | 22
Chapter 3
Design and Analysis
Due to application of tier-based approach in various types of applications, e.g., database-driven, web, etc., choose the right variant of MVC, i.e., Two Tier, Three Tier of this pattern; according to application domain and roles of elements is also an analysis phase decision and realized by the following Figure (Figure 9).
Figure 9: A typical application layer of single user application based on MVC architecture. Considering all these benefits, we step towards the search of GUI package, which best comply the MVC architecture to facilitate the creation of real-time collaborative components for multiuser GUIs.
3.2. GUI Packages

To get benefited by MVC in the context of our further requirements at GUI level and particularly for real-time collaborative GUI, we needed to find a GUI framework, grounded in MVC, and can be enhanced to implement the real-time collaborative GUI components. To identify such framework, like several available for Tweak and Squeak; we reviewed, some state-of-the-art Java GUI packages to examine, which of them comply best with MVC. To have a brief introduction, we review two renowned of them, i.e., Java Swing and Qt Jambi; and examine, if they realize MVC and can be expanded for our requirements.
3.2.1. Swing
Among the other GUI packages, i.e., GWT, AWT, etc.; one of the GUI packages, which Java offers is Swing. Swing is relatively an old technology, available as GUI package with every Java installation. Considering the package to endorse the language capabilities for GUI development, Swing is not highlevel solution, and promotes the GUI designers to write code. Being low-level, the developers have more opportunities to innovate new components, but this affect the Swing popularity
Page | 23
Chapter 3
Design and Analysis
among the nave GUI developers. Swing is the package, which complies the most with the Model, View, and Controller philosophy; among the other GUI packages. It complies with the MVC architecture in a slightly different way; but finally, it persuade the separation-of-concern between the logic (Model) and other components (Controller, View), by its Separable Model Architecture. Moreover, the Swing facilitates the developers by providing the models for most of its components, to be customized in case of specialized needs. There exist two types of Models for a single component depending on its core responsibilities, i.e., GUI-state model and application data model. Due to this openness, Swing is mostly considered, when the custom widgets are needed or when there is a need to customize the existing one. Swing Model driven programming can be observed in Figure 10, in which the View tightly coupled with Controller delegating the component UI, contrary to the traditional MVC architecture, but Model persist its role [58, 72].
Figure 10: An adaptation of Separable Model Architecture by a single Swing component21.
3.2.2. Qt Jambi
The other considerable name in GUI development, which also made its position for GUI development in Java, is Qt Jambi22. Qt Jambi is a cross-platform GUI authoring framework, written in C++ and came with richer features to create GUIs with least coding efforts. It endorsed the ancient philosophy of GUI development, which as discussed in section 3.1.1 first experienced in Squeak GUI specifications. It realized the framework, as a tool rather than a framework with core classes, to proof the flexibility and a concrete example of language versatility.
21 22
http://www.javaswing.org/introduction-to-java-swing.aspx http://qt-jambi.org/
Page | 24
Chapter 3
Design and Analysis
Qt Jambi is available with variety of modules from network to multimedia and 3D, LGPL open-source License and Drag and Drop What You Is What You Get (WYSIWYG) integrated development environment (IDE), as shown in Figure 11. Being high-level, written in C++ and a wrapper of Qt for Java development, we sifted out the Qt Jambi as the considerable framework for our need. Considering the Qt Jambi as a tool rather than an open architecture GUI framework, which can be adapted and reviewed for other applications architectural consideration, or low-level alteration is unlikely and demands higher level of expertise, but highly recommended for creating usual GUI based solution with Java [72].
Figure 11: A detailed view of WYISWYG, Drag&Drop Qt Designer23.
23
http://doc.qt.nokia.com/latest/designer-manual.html
Page | 25
Chapter 3
Design and Analysis
3.2.3. Analysis
To address the other concerns, which involves the multiuserness of overall GUI including, the thirdparty GUI components, i.e., textbox, button, slider, etc. as shown in Figure 12. The application logic of real-time collaborative application will comprises of two classes of Models.
Figure 12: A typical real-time collaborative GUI (strict WYSIWIS) depicting the same state of GUI components and simulated objects among multiple clients24. The first class of Models: the application Models, will be used to provide the conventional application logic (simulation logic or game logic); where as the desired logic for GUI components to provide real-time effect of user interaction, embarks on the need of another class of Models. Considering GUI components as the part of application logic for real-time interaction, the deeper accessibility to their logic is desired for further implementation. The real-time collaborative components demand a loose coupled and transparent GUI library, where the accessibility to the components application logic (Model) is easily achievable. To create the new GUI library, corresponding to the discussed requirement, and based on flexible architecture is the topic of creating a new GUI package in Java, which we found unrealistic due to time constraint of the thesis.
24
http://stackoverflow.com/questions/345838/ball-to-ball-collision-detection-and-handling
Page | 26
Chapter 3
Design and Analysis
Therefore, to proceed further, we explore the Swing package, knowing its groundings in MVC pattern. We found the typical example of our use-case in Swings way of implementing components and found, the Swing Separable Model approach (see Figure 13) the viable option for this task with least implementation efforts. Swing provides the concrete Models for each component it provides. These Models work as the traditional Models, but being the Models represent the GUI components; their services are characterized by the nature and purpose of particular component.
Figure 13: A typical Swing GUI component based on its quasi-MVC variant25. It provides the Models even for the basic components, like buttons and checkboxes; and divides the Models into two categories: State Models and Data Models. The State Models perform the task of bookkeeping and store the state of component; for example, clicked, checked, pressed, etc. The data Models deal with the data of component, they are attached with; for example, a Grid component keeps the record of all the data, it is displaying. Additionally, Swing provides a separate Model interface for each component, which has a logical data or value abstraction, and makes possible the customization of component logic according to application need [50]. As now we have reviewed, the possible technologies for application layer. For the network applications, one of the primary requirements is to decouple and distribute the resources across multiple machines. For the decoupling, we already reviewed the role of MVC to provide separationof-concern between different application components. Considering the real-time collaboration (network layer), MVC can also play an important role in better and structured design, if the proper allocation of resources (Model, View, Controller) is made.
3.3. Design
Considering the real-time scenario, when multiple users wanted to share the same view of objects and their state, the software development embarks to access/share the application logic (Model) at a particular time t. To realize this mechanism, the Model is supposed to reside on a separate machine and considered responsible only to process the application logic. Doing this make possible, multiple machines accessing the particular machine get the same resources and services at time t, or the Model can just send its state to all machines at time t; and consequently the multiuser effect is achieved, as shown in Figure 12. As in the single user application, the Model and other components
25
http://www.javaworld.com/javaworld/jw-04-1998/jw-04-howto.html?page=2
Page | 27
Chapter 3
Design and Analysis
lie on the same machine and the communication between them is not the issue. In the multiuser applications, this communication of the Model, with the View and the Controller, considered the door for complexities to enter in the realm of developing network application. Nevertheless, in the light of above analysis and discussion, which embrace exploiting the Swings quasi-MVC and relocating the MVC components, we came up with the following architecture for the real-time collaborative applications.
Figure 14: A possible architecture depicting the decoupling and communication of Model and Controller in case of real-time collaborative application. As the architecture (see Figure 14) depicts, the role of the Model, View, and Controller will be the same, but the distribution of components for the sake of communication between multiple machines, and an additional class of MVC is introduced to provide the logic for real-time collaborative GUI components. Considering the other changes, the responsibilities of the Controller are varied, due to its need to communicate with Models residing on different machine; and simultaneously, working as traditional Controller. Considering the role of Model as discussed due to real-time need, the individual Models need to reside on the different machine and a super Model will represent the both Models, to propagate the updates to the Controller on each level, i.e., GUI component level and simulation level.
Page | 28
Chapter 3
Design and Analysis
Until here we saw, how existing solutions and especially the Swing quasi-MVC (Figure 13) can play an important role to develop the real-time collaborative GUI (application layer). The only challenge left is to combine this application layer with network layer to get it work in a distributed environment as shown in the Figure 15.
Figure 15: A typical architecture of single user application after plugging network layer.
To implement the network layer for realizing the above architecture (Figure 14), we will examine different network technologies in networking section 3.4.
3.4. Networking
3.4.1. Architectures
The obvious choices for selecting the architecture, in which two computers can communicate, are the client-server and peer-to-peer. Both have their advantages and disadvantages and we will select one, which is most suitable to real-time communication. Peer-to-Peer In peer-to-peer architecture, every client is connected to other clients. Each client in peer-to-peer is responsible to update other clients. There is no designated server exists in peer-to-peer architecture and any client, who needs to update can serve as a server. All application-specific functionalities, e.g., the game-state reside on each client and the processing done by each client itself. The possible deployment of peer-to-peer architecture includes; the networks, where high latency can directly affect the application functionality and low latency is a functional requirement, and the clients are capable enough to process the complex application logic. Among the various, the one advantage of
Page | 29
Chapter 3
Design and Analysis
peer-to-peer architecture is the elimination of one resource dependency. In-contrast to client-server architecture, where all the clients rely on one server and server down, or any other problem can affect all clients or may completely halt the application [6, 8, 31]; the peer-to-peer architecture keeps the application running by simply transfer the control to other computers. Nevertheless, the peer-topeer architecture is considered un-scalable and data security can be one of the issues in peer-to-peer architecture. Client-Server Concerning the other option, which is client-server, in client-server architecture, all the clients are connected to the designated server, and the server is responsible to propagate updates to each client. Among various other concerns, one important concern in deploying client-server architecture is to define proper load on your server; and the services, which needs to be provided by the server. In client-server architecture, the role of servers is worth deciding right in the analysis phase. Formerly, the job of the server is observed, limited to propagate updates to the clients; but with the emergence of complex online applications, where the processing of application logic, i.e., game logic or simulation overload the single server; the concept of different types of server arises. The concept of thin and thick also embarks about this consideration [6, 8, 31]. There are two types of server, which are commonly used in client-server environments, in which first type: the networking server, just propagate the message to each client. The other kind of server for which the terminology of application server, is used to process complex application as in our case the game or simulation logic and to serve related services. Considering the flexibility and features of client-server architecture, we found it more viable to use for the applications, where application logic, e.g., game or simulation logic is more sensitive to processing. In such scenarios, the idea of logic and networking server seems also more logical, which can deal separately with the lengthy processing of application logic or persistently stores the shared objects and mediates communication among the clients for real-time updates. This is also possible that implementing these architectures would involve minimal changes or combination of both while solving the domain-specific problems.
3.4.2. Protocols
Transmission Control Protocol (TCP) TCP is the most commonly used protocol for the network communication. It is a connection based protocol and provides reliability by guaranteed and ordered delivery of data. TCP is considered easyto-use as the reading and writing the data via TCP is as simple file reading and wiring. It is considered a high-level protocol and works as black box by providing all the necessary operations to send data on wire by default. To send the data, it automatically breaks up data into packets and provides the flow control to prevent the data transfer too fast or too slow for the network connection. To avoid collision and packet loss, TCP automatically determines, when data needs to be re-sent; and stops the flow of data until previous packets are successfully transferred. It also supports the error correction by default and make sure the clients re-requests for packet from the server until it receives the complete and identical to its original packet.
Page | 30
Chapter 3
Design and Analysis
User Datagram Protocol (UDP) UDP is another commonly used protocol for the distributed communication. It is considered a lowlevel protocol, while the handling of all low-level details and implementations are purely depends on the user preference. UDP is a connection less protocol and provides no guaranty of the data transfer and the order. Contrary to TCP, the flow control, error-correction and other operations need to transfer the data on wire is the concern of individual choice and requirement. UDP is an unreliable protocol and considered an unviable medium to send important data, such as web-pages, database information, etc; contrary to this, UDP is considered for the solutions, where the speed has the highest priority. Being no implicit care of flow control and error-correction; UDP is faster than TCP and commonly used for the scenarios, where the speed has the higher preference then reliability; such as audio, video streaming and racing games [1,6].
State-of-the-art As the other technologies progress, new protocols are also developed to address the specialized needs, support different types of data and stream the data in various formats. One of the revolutions in message passing protocols is of the instant messaging protocols. Instant messaging protocols are widely considered these days, to provide off-the-shelf real-time communication features. We found the significance of discussion on this class of protocols, due to real-time factor and comprehensiveness of our study. The Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) are some of the names, which seem popular in the field of instant messaging these days. Considering these protocol to achieve our form of real-time collaboration, we found the viability of these protocols, only for limited real-time scenarios and a less amount of data. Taking the example of XMPP, XMPP can be productive to develop the real-time applications, e.g., multiuser turn base game; but considering this protocol a generic solution, which can be fitted in every scenario, i.e., real-time first-person shooter (FPS) or multiuser physics simulation does not seem viable. These protocols can play a productive role to provide off-the-shelf features; like in case of real-time communication, XMPP can be handy to implements the features, like friend-lists, presence, avatars, private chats, and group chats; which can play a promising role in rapid development of online social-networking applications, but hardly considerable for LAN based car racing game [80]. In the end, the game and multiuser applications are still seemed to be relying on the conventional protocols; in which TCP is considered reliable and make sure the delivery of data to arrive at their destination, while UDP is considered faster, but provides no guarantee of data to be received by the receiver. Due to faster delivery of data, UDP is typically used, when frequent delivery of data is needed and loss of data is not critical to the application.
3.4.3. Distributed Computing

The distributed computing paradigm can be further split into two branches, the Messaging passing and the Remote procedure call (RPC) based. They are the most commonly used approaches to communicate in distributed applications. All newly developed approaches are variants of these approaches even the RPC is considered built on top of message passing. Message passing provides an unreliable, asynchronous communication; while, the RPC provides a reliable and synchronous
Page | 31
Chapter 3
Design and Analysis
communication. RPC is considered a viable approach in client-server architecture, while the message passing generally considered suitable in a peer-to-peer or adhoc communication model. These technologies can easily distinguish based on several considerations and requirements of application; like concurrency, synchronization, resource/service discovery, reliability, ease-of-implementation (abstraction) [73]. One can choose either of these, based on communication scenario, i.e., synchronous or asynchronous communication requires by the application. If the application needs the synchronous communication, data loss can be affected on the application performance and functionality; and reliable communication is a functional requirement, RPC is generally considered best for such situations. Nevertheless, the factors like the slowness, which trade-off ease-of-implementation in RPC should not be ignored. To overcome these performance overheads, which basically evolve from the use of generic algorithms, for different operation; like serialization, marshalling; the space to improve and optimize is still left, and can easily be found by using optimized algorithms for each operation. RPC is considered, a widely used approach in distributed applications. It is realized by the particular realm of technology, which is commonly known as the distributed computing paradigm. There are various implementations of RPC are available these days, which trade-off the complexity of implementation by overall performance. Therefore, to select the suitable and best inter-process communication paradigm is the other challenging decision, which came across in developing any distributed application. Common Object Request Broker Architecture (CORBA) CORBA is the first name came into mind, when the discussion on the technologies based on neutral reusable components take place. CORBA achieves platform independence, by introducing a new language called interface definition language (IDL). IDL is platform independent language, used to define the meta-information and details about the particular object; it has its own type system. CORBA mediates the communication using the pattern called object request broker (ORB). The ORB provides the basic services of locating and activating the remote object; and the inter-communication between the client and remote object via request and reply communication scheme [85]. CORBA provides the open architecture, it is considered a competitor of the technologies, which are vendor and platform dependent, like Distributed common object model (DCOM). DCOM The other technology, which is based on the concept of components spread over the network, is DCOM. DCOM is based on the proprietary model, Common Object Model (COM), and widely considered to support Windows based environments. Its component inherently supports all the features of COM, e.g., like the COM component, DCOM components can also have multiple interfaces. DCOM is grounded in the concept of Proxy and Stub, the stub represents the component reside on server, while the proxies represent the client object. The stub and proxies are supposed to perform common formalities on incoming data, i.e., Marshalling, un-Marshalling (converting data to/from byte code machine readable to human readable) and communicating with the concrete components. Other than that, DCOM is considered a protocol, which provides implementation in both state-of-the-art networking protocols TCP and UDP, unlike other technologies. As the component based solution, DCOM provides reusability, maintainability, scalability at the cost of portability, flexibility, and interoperability [85].
Page | 32
Chapter 3
Design and Analysis
Enterprise Java Beans (EJB) Another name, which comes into mind, while short-list the distributed computing paradigms, is EJB. EJB is considered, as a collection of server-site components and the framework to build new components. It provides the ready-made server components to ease the development efforts and emphasize the concentration of application developer on application logic. Like any other framework, EJB also supports the development of new components. The new components designed using EJB inherently provide the distributed features. EJB in its core supports the basic operations, such as object pooling, service discovery, multithreading; which formerly need to be designed by the application developers. EJB used the concept of remote method invocation from Java RMI to access the services on multiple machines. In its latest release (3.0), EJB further enhanced its features to meet the requirements of state-of-the-art distributed application. As the core J2EE technology, EJB is specialized to provide the distributed enterprise solutions comprises of multiple tiers. The services, such as transaction management, security, persistence, and resource management, and the compatibility with other J2EE Application programming interfaces (APIs) are making the EJB best choice for business and e-commerce application developers [15]. Java Messaging System (JMS) As discussed, along with the other approaches, the message passing is another approach, which is considered to provide the networking solution for distributed applications. The message passing is considered as an alternate approach to RPC and embarks on the communication via messages. There are various implementations of messaging systems are available and Java messaging service (JMS) is one of them. It entails the transfer of two types of messages: the text based message and object based messages, which is designed to send the complete objects as a message. JMS also has the ability to provide the asynchronous and synchronous communication. JMS is also capable to support both propagation mechanisms, the machines can communicate with each on one to one basis, which is referred as the point-to-point communication, and also via publisher-subscriber, which considered as one to many communication. JMS is considered to be relatively new and lot of issues and solution still need to be addressed, which includes load balancing, fault tolerance, and scalability [62, 66]. RMI RMI is considered a mature, pure Java based technology, which endorses the concept of sharing objects on different machine. RMI is considered the sophisticated form of RPC and works on the invocation protocol to access the objects on different machines. It employs the concept of remote objects to the objects, which needs to be accessible by other objects on network. Like its contemporaries, RMI uses the concept of stubs and skeletons as in SOAP and RPC. Stubs in RMI are considered, the representative of server objects on the client-site. They handle the invocation of methods to perform the particular task and perform the main tasks, e.g., Marshall and un-Marshall (converting data to/from byte code machine readable to human readable) the data; and call the methods on actual remote object on different machine. The skeletons in RMI work as the server entry-point, to service the incoming clients requests. They also Marshall and un-Marshall the data and call the method of actual remote object for more processing. Other than sending the remote reference, RMI abstracts the complexity of sending complete objects to the other machines by using Java default serialization feature. In RPC based technologies, the RMI is considered simplest and fastest way to implement the distributed objects, due to its OOP based syntax and semantics. Due to
Page | 33
Chapter 3
Design and Analysis
its simplicity, RMI is considered a good choice for Java based Rapid application development (RAD) and prototyping [45, 85]. Simple Object Access Protocol (SOAP) SOAP falls into the category of developing Web-services, which works also as a middleware for distributed applications. Like the other Web-services specifications, SOAP is also based on XML, which is renowned for its neutrality as far as implementation is concerned. SOAP is mostly considered a viable candidate, when the inter-process communication is desired between the processes from different platform. It employs RPC over HTTP or SMTP as the communication protocol. SOAP is governed by the request/response model, in which the client creates a request, consists of XML text, and sends it over HTTP or SMTP to a server; the server picks up the SOAP request, parses and validates it, invokes the requested method with any supplied parameters, forms an XML response, and sends it back over HTTP or SMTP. Being on top of HTTP, the communication behind the firewall is not an issue while implementing solutions with SOAP. Due to its implementation complexity, SOAP is favorite for the business processes and enterprise applications implemented by the domains experts, with the techies with SOAP expertise. There are also other solutions available in the market to develop Web-services, in which XML-RPC is considered older and predecessor of SOAP, but provide the simpler implementation [35].
3.4.4. Custom Networking Solutions Introduction

Sockets The most traditional way of communication between two computers is implemented by sockets. The sockets are considered the lowest level approach to realize the communication between two computers. The reason to refer this approach a low-level is the fact that, all the communication is based the Operating System (OS) transport layer protocols. These protocols include the TCP and UDP, which operate on ports to receive and send data from/to processes on different machines. The writing and reading of the sending and receiving data is also based on the systems I/O mechanism, which generally involves the concepts of streams (turning objects into bytes and then back into objects),
but with a little variation and referred as the Stream Input-Output (IO).
The sockets are considered low-level also based on using the languages capability to use the IO port of any computer. Due to the use of default OS level resources, the languages are supposed to operate only on sending and receiving the data in byte form, and also limited to send primitive types in programming language semantics. Additionally, dealing with all these OS resources by the programmers themselves cause the other issues relating to, threading, concurrency, and synchronization; and makes the sockets hard to use for novice programmer [5, 36]. NIO Background To realize the message passing approaches, the IO capabilities of an individual system are considered. Dealing with these IO is generally referred: the socket programming and considered a dry topic. Like every language, Java also supports IO operation with its Java IO library. To deal with system resources like sockets, ports and threads, and to implement the solutions with IO libraries
Page | 34
Chapter 3
Design and Analysis
considered a nightmare even for the experienced programmer, and the resulting solutions are still observed possessing un-satisfactory performance. We wanted to choose some technology, by which the development of network protocol will not be that much hectic because of already addressed solution for the scalability, robustness, and performance [36]. Generally, the most of the criticism, the traditional Java IO faced, belongs to complexity and scalability. The first major issue with traditional Java IO is of multithreading. It follows the concept of single thread initiated for single client, and due to the fact that Java is considered poor in dealing with multiple threads, this gets worst and the server is considered to be in critical stage after a reasonable number of connections. Other than this scalability issue, these multiple threads invites the discussion on other issues related to them, like synchronization and concurrency, especially in the cases, when they are crucial. Pitching more in-depth addressing concurrency and synchronization between the different threads (clients) opens the door for more complexities and so on. In the past, the developers have to rely on their custom approaches for implementing the solutions for these problems [32, 36]. Considering the main requirements of some network layer providing real-time communication, the non-blocking (asynchronous) is of the highest priority. To complement this requirement decently, the software designer suggests the solutions, which discourage the excessive use of threads. The concept of several threads is considered the root of all problems; and this brings other problems come into action like complexity and scalability, synchronization and performance [32]. The New Input Output (NIO) provided both of these features, and made us to choose the NIO for implementing messagepassing protocol. Additionally, the scalability factor is also of much worth in-case of building heavy simulation and games in future, the protocols and libraries based in this will still be valid and reusable. NIO Architecture NIO addressed the shortcoming in legacy Java IO by employing the event based architecture, which is based on the principle: Dont call us, we will call you. the reactor pattern [14], is one of the design patterns which is considered for event-based communication. The application of reactor pattern is quite evident in NIO development. The design emphasizes on the solution to the problems, exist in legacy Java IO library. It provides the solution by implementing in its core reactor pattern. NIO realizes the main components of reactor pattern and emphasizes in its core the needs of clients as the actors, and the servers as reactor. It facilitates the role of a server, as a system, which implements the reactor; and allows the actors to act upon it and provides the services [79]. To realize these responsibilities, the reactor pattern implements three components Reactor, Dispatcher, and Handler in its conventional way. It works as the mediator and transfers any received events of dispatchers interest to the dispatcher; which the dispatcher further sends to the specific handler for servicing, e.g., Service, Event, IO handler. NIO implements the reactor by providing the typical interested events for server and the typical needs of handler to service those events and reply to clients. It provides the concrete implementation of every component involved in the reactor to fit in the client-server scenario and to implement the event based communication for scalable and logical design [57].
Page | 35
Chapter 3
Design and Analysis
State-of-the-art NIO Frameworks Grizzly The Project Grizzly originally launched as a package with GlassFish project, started in 2004. Grizzly is now considered as one of the NIO and web framework, and available as a standalone project. It exploits NIO to provide the extended thread management for developing scalable servers. Grizzly offers the extended framework components, to address the wide range of application scenarios, by supporting the technologies, such as Servlet, HTTP/S, Bayeux Protocol, HttpService OSGi and Comet. Grizzly seems to work precisely on providing scalability and robustness and centers the development around these two factors, by emphasizing the robust memory management, I/O strategies, and thread handling [60]. Kryonet Kryonet is another network library written in Java using NIO. It provides an intuitive and simple API to facilitate the network communication. Kryonet emphasizes on efficient communication between machines pertaining to client-server architecture. It has its own robust serialization mechanism (Kryo) to support automatic and efficient transfer of objects across the network. Kryo can serialize any object and supports data compression techniques, such as deflate and delta compression. Kryonet also support distributed computing and inter-process communication by providing an easyto-use mechanism for invoking methods on remote objects. Kryonet uses TCP by-default; and provides the support for UDP as an optional feature. It implies no constraints on thread handling and enables the developer to implement threading according to his/her requirements. Kryonet uses lightweight MinLog logging library and can compile with a fixed logging level MinLog JAR, to achieve efficiency. Kryonet runs on both the desktop and on Android. Considering its efficiency, Kryonet can be considered for real-time games [68, 69].
Netty Netty came out as the successor of Multipurpose Infrastructure for Network Applications (MINA), it is written by the same author as the MINA. Netty emphasizes on pruning the redundant features, which trade-off the MINAs out-of-the-box features and ease-of-use. It addresses the design issues while retaining the known strengths of MINA. The project emphasized to provide an asynchronous event-driven infrastructure for creating scalable, robust, and manageable network applications. It supports various protocols and the ability to define custom codecs in a similar way to MINA. A typical client-server application with Netty mainly comprises of Buffer, Bootstrap, Channel, and Encoder/ Decoder; and all advanced features are rooted, and can be adapted by the use of these components. The glimpses of MINA design are evident in Netty. Netty is the result of re-engineering MINA and address the known issues, e.g., OutOfMemoryError, perverse read / write ratio, etc.; by the use of optimized algorithms, approaches, and design patterns. Netty is provided with other state-of-the-art solutions like POJO transfer with channel buffer, the optimized custom HTTP implementation, and other optimized solution for security, i.e., SSL and TSL. The new release of Netty is under development and expected to be marketed soon. Netty has more elaborated and precise documentation, and redundancies and dependencies are strongly avoided [78].
Page | 36
Chapter 3 NIO Framework
Design and Analysis
NIO Framework is another library on top of NIO, which emphasize performance and security. It hides the complexity of plain NIO by encapsulating the unnecessary details and eases the implementation of secure high-performance network applications. It addresses the issues in Java NIO keeping the performance preserved. The core of NIO framework resemble the MINA architecture ; In the core of its architecture it adapts the reactor pattern and maps the core classes of NIO as the components of reactor pattern i.e., handler, dispatcher, for better understanding and realization. Incontrast to the original NIO library, the NIO Framework addresses the parallel systems and provides a robust and secure infrastructure to build them. It used the SSL as an integral part of the library instead-of feature and used the readiness selection as the multiplexing strategy. Due to its primary design, NIO Framework automatically scales performance with the increasing number of available cores [79]. MINA One of the proprietary solutions for network applications is MINA. MINA is written by the Apache Software Foundation and considered relatively more abstract than other libraries. It supports event based communication over TCP and UDP with SLL and TSL. MINA endorses flexibility and customization, at the cost of relatively poor performance. One of the promising features of MINA, is its layer-based design, consisting of IOHandler, IOSession and IOFilter. This layer-based design helps the developer, to achieve the separation-of-concerns between different application components and to define easily the responsibilities of each component. MINA relies on default Java serialization and lacks the support of robust serialization framework. Considering the design popularity, the other networking libraries, e.g., Kryonet, Netty adapts the MINAs design, but the Kryonet default serialization capabilities; and its built-in support for RMI; and Netty s moderate design are also making them enough capable to compete with MINA as the considerable options [75]. QuickServer QuickServer is a TCP based library for rapid development of network applications. The library seems to address a limited scope of scenarios, but endorses separation-of-concern to ease the development, reusability and other promising features. The project is mainly based on traditional Java IO library, and encapsulates the ServerSocket, Socket and other Input-Output classes to provide the abstraction. Other than the normal data and objects, the library also supports XML, to provide the generic data transfer mechanism and offer other features, e.g., security, pooling support to create the robust network application, missing the UDP support and single-threaded server support to handle multiple clients [81]. xSocket The other alternative to provide asynchronous and non-blocking communication is xSocket. xSocket is an easy-to-use NIO-based library and supports writing client-site applications as well as server-site applications in an intuitive way. It emphasizes the solution to complexities involve in dealing NIO selectors, connection pool management, connection timeout detection, and fragmented buffer reads. Being on top of NIO, xSocket supports the asynchronous and non-blocking way of communication. To support asynchronous communication the xSocket employs its Dynamic-callback-handler architecture and provides the Quality-of-service management via dynamic data transfer rate control. Like other library xSocket supports TCP with an option to enable or disable SSL) and UDP communication. The latest version of xSocket 1.2, introduces the Stream IO SPI. The service provider interface allows replacing the built in low-level NIO module by other I/O implementations, Master Thesis Prototyping Real-time Collaborative Applications Page | 37
Chapter 3
Design and Analysis
in which the support for Grizzly and MINA are under development. The Configurable threading behavior, i.e., multi-threaded or single-threaded; and the support for JMX based active monitoring and control; are making the xSocket, a promising choice for server application developers [89].
3.4.5. Analysis
The discussion tells that, the networking solutions are based on two mainstream approaches. Most of the technologies discussed, belong to RPC realm, and seem to be specialized to deal with enterprise scenarios. On the other hand, message passing due to its re-engineering approach is considered, to provide the custom solutions (network layer for the games and simulations). Nevertheless, there are also several frameworks and libraries are available, to facilitate the development of custom networking solutions. In our work to have a brief overview of both, we will present the solution with both approaches, by choosing one of the technologies from each. From RPC based technologies, the RMI seems to be most suitable according to our requirement among other options, e.g., CORBA, DCOM, EJB, because of its versatility. Additionally, the nonfunctional requirements, which can be best satisfied by the RMI, include its edge on rapid development, considering this as the prototypical project, having rigid time constraints. Secondly, considering the RMI limitations across networks, we found the online support redundant at this stage, which also brings the internet dependency in the scenario. On the contrary, we found the support for normal strength of a classroom is enough to be considered in the initial iterations, which can be achieved by Local Area Network (LAN) of 20 to 40 computers. Last, but not least, pursuing the simple projects, i.e., serious games; and excluding the processing sensitive genres, we assume that the amount of data and the network calls will not be high in most of the cases and RMI would be capable of managing these kinds of issues [85]. Nevertheless, to address the problems faced in RMI, and to present the comprehensive solution, to tackle the diverse nature of scenarios using our work, we will provide some other client and servers abstractions employing other possible alternatives. The Implementation of even simple client and server communication is considered cumbersome with Java IO, and the same complexity remains with its successor NIO. To address the complexities involved, various frameworks and libraries are written to encapsulate the complexities. Considering the approach to provide the robust and scalable building blocks, we select some of the frameworks, which will cover the liabilities in preceding iterations and propose the optimize solution for advanced and diverse scenarios. The two frameworks, which we select, are the MINA and Kryonet. Therefore, we will discuss them in more detail to highlight their qualities as the most promising solutions.
Page | 38
Chapter 3 Kryonet
Design and Analysis
Among the RMIs promising feature, considering some of the RMI shortfalls, the RMI default serialization feature is the one, which makes the RMI a debatable option. The default Java serialization is slow and to address this factor, various solutions are introduced to provide faster and efficient serialization. Considering this fact, the Kryonet is chosen as an optimized approach and its flexibility to use custom serialization. A rough comparison of serialization technique used in Kryonet can be seen by the comparison of its Serializer: Kryo, with the other custom serialization solutions, and presented by the chart in Figure 16.
Figure 16: Benchmark illustrating Serialization time leveraging state-of-the-art solutions26.
Evaluating on the scale of performance in term of time taken to serialize, Java default serialization is worst among all. Considering the first position Externalization, the complexity of implementing Externalizable for each object does not seem to be a viable option in our scenario. In-contrast to that considering the second least time to serialize, Kryo seemed to be fast enough and efficient for realtime communication.
26
http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking
Page | 39
Chapter 3
Design and Analysis
Comparison of Kryo precisely with Java serialization and one of the most considered Serializer Protobuf can be seen from the other two graphs presented in Figure 17,
Figure 17 : Bar charts presenting the Kryo benchmark in-contrast with some of its contemporaries27. MINA To address the complexity; MINA is selected to provide an easy-to-use and higher level solution. Considering the MINA high-level API with flexible scalable architecture, we found it an additional potential solution to realize the network layer in the situations, where time constraint is most important; and a flexible architecture is needed to devise a custom protocol for your application.
27
http://code.google.com/p/kryo/wiki/BenchmarksAndComparisons
Page | 40
Chapter 3
Design and Analysis
Figure 18: A Layered structure representing the core elements of MINA design28. As the Figure 18 demonstrates, a typical application with MINA is divided into three parts, in which each of the parts is provided with a representative to support the developer:

IO Service - Performs actual IO IO Filter Chain - Filters/Transforms bytes into corresponding Data Structures and viceversa IO Handler - Manages business logic
Using these utilities a MINA application can be built following the four simple steps: 1. Create IO service Create a connector (Client) or acceptor (Server) 2. Create Filter Chain - Define Filter (*Filter) or create a custom Filter for transforming request or response. 3. Create IO Session Create a session to send/receive a request or response 4. Create IO Handler Implement business logic, depending on received messages
To summarize, the design of MINA allows the developer to extend at any level and emphasize on the particular need with respect to the application. The low coupling between the layers, allows the developer to enhance the individual layer independently, without affecting the other layers [75].
3.5. Summary
In the beginning of the chapter, we prone our requirements more effectively and discussed the possible solutions from various perspectives. To achieve the separation-of-concern, decoupling, and other crucial design traits; we proposed architecture by splitting a real-time collaborative application into two layers. We discussed each layer from the realization perspective, the components each layer will retain, and their realization pertaining existing solutions. Based on these two layers, i.e., application layer and network layer; we went through the process of requirement analysis and design; and discussed the application layer, considering the typical single user application and the existing patterns and frameworks. Bearing in mind the significance of MVC in major areas of software
28
http://mina.apache.org/mina-based-application-architecture.html
Page | 41
Chapter 3
Design and Analysis
development, i.e., desktop, web; we discussed the MVC in detail, and found the significance of the discussion to explain our approach, as it was mainly rooted in MVC and embarked on relocation of the corresponding components, i.e., Model, View, Controller on multiple machines to address the needs of real-time collaborative applications. Entering into another phase, as it is obvious that the development of some GUI application requires the set of GUI components; to pursue this requirement, the set of real-time collaborative controls for real-time collaborative applications; we reviewed some of the existing GUI packages. We select the Swing as it was already governed by MVC and can help enormously to realize our architecture and approach. In the remaining part of the chapter; we discussed the second layer, and discussed; how second layer can be integrated into the first layer and reviewed possible technologies. Considering the two most commonly used approaches to provide communication in distributed applications, we categorized the solutions into two classes: the custom networking solutions and distributed computing paradigms. To present the state-of-theart of these approaches; we briefly discussed the solutions from both classes and selected three of them according to their suitability and our requirements. Finally, we concluded the chapter, by leaving the proof-of-concept and concrete implementation in the form of example application scenario leveraging our selected technologies, on the forthcoming chapter 5.
Page | 42
Chapter 4
Implementation
Chapter 4
4. Implementation
The core of this chapter is to present the development of real-time collaborative application as a case study to have a closer look into the implementation challenges. We will discuss the development of compact network framework, which came as a result of multiple iterations to examine each selected technology. Each technology is examined in a single iteration, and finally the client and server factories [14] are created, to facilitate the rapid development for future use. Considering the ease-of-use, we started with the distributed computing solutions, and implemented the network layer leveraging RMI. Although the RMI satisfied our all requirements, but for the sake of comprehensiveness and versatility; we considered the other layers to address the diverse and distinct requirements. We choose: Kryonet, in the second iteration because of its feature to use custom serialization and to achieve overall optimization, but we realized the use of the custom serialization tricky for large no of objects and for the nave developers. Therefore, we explore another high-level solution based on NIO technology: MINA, as an alternate to both in our last iteration. To demonstrate the use of framework and to cover the typical scenarios, in the first half of the chapter, the RMI layer is discussed, while the second half of the chapter: discusses the realization of application layer in the light of prescribed architecture.
Page | 43
Chapter 4
Implementation
Further, in this chapter; considering the primary use-case of any network layer [6, 8]; we discussed , how data can be sent from one machine to multiple machines, in which the form and the granularity level of the shared data in the context of multiuser games and simulations are precisely considered. Additionally, we covered: the importance of proper granularity level, i.e., complete object or some part of object, with its pros and cons; and the ways to apply proper decoupling to achieve the best performance. To have a brief introduction, first we are presenting, the basic idea, and the terminologies used in the realization of network layer, and particularly how the client and server interacts in general.
Client and Server Interaction The client and server interaction in network applications is recognized by the notion of callback. The notion of callback is used as a metaphor for different updating mechanisms. It is a terminology used as a technical term for Calling in laymans language. The callback is the mechanism referred to server calling the client, or clients calls the server for processing a particular request or call a method on the server. Different types of scenarios demands different approach; there are scenarios, in which the server calls the clients; and there are exist also the scenarios, where the client calls the server. The first approach considered rarely, while the second considered the common practice. In the context of network architectures, i.e., client-server, this call from the server to client is referred as polling; and the call from client to the server is referred as the pushing in technical terms. The polling is considered a better option, when a structure and well-organized design is concerned; it provides a good abstraction; and decoupling of responsibilities. The acquisition of efficiency is considered the challenge in polling realizations, while the pushing is considered bad, in good OOP design realizations; and decoupling is considered a non-trivial task with pushing. Pushing is considered good for most of the network applications, because of network performance; while, it gives reasonable output for network problems, like lagging latency and bandwidth consumption, if proper decoupling on client and server is implemented. Considering the communication between different components involve in our scenario, the application of both updating mechanisms is realized. Pushing seems to be suitable for running the simulation simultaneously on multiple clients, while polling is realized, to make the communication possible between the Swing Models, their Views (JComponents), and the main Controller, to update the control-panels simultaneously on multiple machines.
Page | 44
Chapter 4
Implementation
4.1. A Compact Network Framework

4.1.1. Server-Factory
To realize different types of server implementation leveraging different solutions, we used the Server-factory [14] as shown in Figure 19, to create any type of server as per the application requirement. We simply use the Factory-method pattern to realize different implementations and provide the initial setup needed for echoing the updates and receiving the updates from different clients, leveraging the procedure described and components provided by each library. We provide the measure infrastructure needed for server to play the role of simulation server, in which any simulation engine or simulation component can be easily plugged-in.
Figure 19: Class diagram depicting the design of Server-factory, using Factorymethod pattern.
Page | 45
Chapter 4 Kryonet Server
Implementation
To realize a server, an abstraction of a typical server is provided by Kryonet, which abstracts all the typical server responsibilities. This class binds the server on the desired port and starts the thread to handle incoming connections, reading/writing to the socket, and broadcasting updates to clients. Moreover, to leave the rest of the work, the server provides other methods, i.e., addlistener() to register the new Listener, etc. The role of Handlers is playing by the Listeners in Kryonet, the Listener is used to get notified, it listen the incoming request and receiving updates. It uses received method to receive the incoming object and used the connection instance to send the reply via its sendTCP method to underlying (TCP) connection instance. The data can also be written and read by using methods of the connection object. A connection also supports a couple of convenience methods to provide the ready-made services. MINA Server To implement the server using MINA, the basic classes provided by the MINA, such as; the acceptor, handler, session, and codec are used. First, an acceptor is needed to accept the incoming connection; second, a handler is created and registered with the particular connection. In the last step, the creation of the codec is taken place, keeping in mind the scenario need, and the rest of the work is done by the registered handler. The handlers are provided with basic methods to send or receive the messages. The methods provided by the handlers, use the session object as a parameter to receive and send the data; later the session utilize its method to prepare the data to read and write for further processing.
RMI Server The server implementation with RMI is done in a different way than the typical server implementation as we seen above. With RMI, the server is implemented as a remote object, which can provide the services of a typical server. As a remote object, the RMI server goes thorough all the formalities, which a typical remote object needs to adapt in-case of registering itself as remote object. It bind itself in the RMI registry and implement the remote class from RMI package and make sure to provide its skeleton and register all the methods also as remote to provide the remote services. The main services include the support for polling from client and pushing via callbacks to different clients.
Page | 46
Chapter 4
Implementation
4.1.2. Client-Factory
Like the server-factory, we also create the client-factory [14] represented in Figure 20, to realize the different kinds of client implementations with least efforts. We provide the basic infrastructure for the client to accommodate the need of multiuser simulation. Each client is capable to receive the updates from the server and to send the updates in case of any user interaction. As the common practice, the clients are responsible for drawing the simulation objects according to coordinates received from the server.
Figure 20: Class diagram representing the design of Client-factory, using Factorymethod pattern. Kryo Client The KryoClient works in the same way as the KryoServer, it used all the same objects to handle the updates. The only difference is in the use of the client class from the Kryo library. Like the server class, the client can register the listener, to listen and writes updates to the server [61].
Page | 47
Chapter 4 MINA Client
Implementation
The MINA client adapts the same way as the MINA server, except the client uses the connector NioSocketConnector instead of an Acceptor. The client also extends the IOHandlerAdapter to send and receive the updates from the server, uses IOsession instance to prepare data to read and write to server and the default serialization codec to send the objects on wire. RMI Client To act as a client with RMI, the RMI client also works as the remote object to receive and send updates to the server. In addition to perform client responsibilities, the RMI client also works as an adhoc-server and provide a remote callback method to receive the updates from the server. To illustrate the use of framework, we will create a sample application using one of the network layer; and to demonstrate the simplicity of distributed computing to create real-time collaborative applications. The sample application will also work as a proof-of-concept of the proposed architecture to accomplish the need of real-time collaborative application, and will cover the typical scenarios.
4.2. Real-time Collaborative Physics Simulation

As our goal is to promote the effectiveness of real-time collaborative authoring to ease the STEM learning process, among the various branches of STEM, we choose the domain of physics, and particularly the scenario of simulations to apply the real-time collaborative features. We found the physics concepts relatively difficult among other areas of STEM, and observed the huge application of physics simulations to transfer the physics curriculum via simulations demonstrating physics laws [12, 26, 42]. As the creation of a real-time collaborative authoring environment for kids is a bit unrealistic, due to time constraint involve in thesis; we will create the real-time collaborative physics simulation to cover the typical use-cases, which are most likely to involve in the development of real-time collaborative authoring environment or microworld. First, the implementation of network layer, leveraging RMI layer from our framework, will be discussed, while the later sections will cover the application layer.
4.2.1. Network Layer with RMI

As we select RMI, we will see how network layer can be implemented by the features it offers. We will also present how RMI Object-Oriented semantics and syntax can be helpful to realize the Model-View-Controller in distributed environment. Moreover, it will also clear, how the application of MVC can be beneficial to scalable distributed application layer. We will see the application of patterns in realizing the communication between different components, i.e., Model and Controller, in which the design and analogy depicted by the observer or publisher-subscriber design pattern is the most evident. We realized the design depicted by Master Thesis Prototyping Real-time Collaborative Applications Page | 48
Chapter 4
Implementation
the observer or publisher-subscriber design pattern satisfy the most the needs of desired mechanism, but the now the central problem is to implement this mechanism with RMI [45]. Publisher and Subscriber The implementation of publisher-subscriber or observer pattern involving more than one machine is quite analogous to client-server analogy in networking context. The publisher can be considered as the server, where as the subscribers as the clients. Moreover, the mapping of publisher and subscriber regarding the MVC can also easily realize by considering the Models as publishers, and Controllers as the subscribers. As the gist of publisher-subscriber mechanism is to update the subscribers, which are registered to particular publisher, but there are also cases, where the concept of adhoc-publisher (Server) and subscriber is exploited, which will be also discussed. Initially, we will design basic architecture; and then, we will transform that design in to some real applications. First, we need to define the interface, which is responsible for registering the clients and able to call the methods on clients [45].
Remote Publisher and Subscriber The first step is to create the remote publisher, which can call the clients remote methods. To create a remote object in RMI, there is specific procedure, which needs to be followed. To create the remote object with RMI; first, we have to define interface, which must implement the java.rmi.Remote class and declare all the methods, that needs to be called remotely. The second step involves the class definition, which implement the defined interface and provide the implementation of all defined methods. Additionally, this class must extend the java.rmi.UnicastRemoteObject class to fulfill the low-level requirements of typical remote object in RMI. Therefore, we also start our development by defining interface, which implements remote class and declare the methods, which needs to be called remotely. To be able to register the subscribers, whose methods can be called remotely and client can work also as an adhocserver in certain situation. For that, we need to repeat the same procedure we did for the server. We defined the interface and declare the method we need to be called from the server.
public interface Subscriber extends Remote { public void updateSubscriber() throws RemoteException; }
Page | 49
Chapter 4
Implementation
The client, who will implement this interface, will act also as remote object, whose one method needs to call from server.
public class ConcreteSubscriber implements Subscriber { }
Now, we are back to our publisher; and now it will make more sense to define methods, which subscriber will use frequently. Register/Unregister Subscriber
public synchronized void registerClient (Subscriber newSubscriber) throws RemoteException { clients.addElement(newClient); } public synchronized void unregisterClient (Subscriber newSubscriber) throws RemoteException { clients.remove(newClient); }
State Management Considering the games and simulation development, one of the primary concerns is to transfer the game-state from server to multiple clients [9]. As we seen in the previous chapter, that different types of technologies supports the data transfer in different formats, i.e., the complete objects, XML based messages or in bytes form. RMI make this task simple, which use Java serialization to make objects accessible between different machines. The following method will make use of RMI pass-by-value capabilities to send the custom objects as method argument or return value from one machine to another. Using this mechanism any kind of object, which implements the Serialization interface can be transfer between different machines. To provide a generic way, which can be also viable for other technologies, the transfer of the simple objects rather than complex objects is considered. Additionally, the idea to achieve maximum granularity of data to send over the wire and the transfer of only primitive data-types is emphasized as much as possible, to prone the different constraints, i.e., serialization, and different network complication, which will be discussed in later sections. Considering RMI to realize the transfer of any type of data in any form, the following methods will work as the transporter to transport game-state to multiple clients. Update Subscriber (Client Callback) The primary need of designing any network layer is to realize updating mechanism. Generally, there are two use-cases, which are used frequently an update scheme in multiuser applications. Some application needs periodic updates from server, which means, the server updates after particular intervals of time depends on games Frame per second Master Thesis Prototyping Real-time Collaborative Applications Page | 50
Chapter 4
Implementation
(FPS) need. The other way, is the event based updates, which is considered good solution for the synchronous communication, i.e., the turn based games, where the updates needs to be done only, in the case of change received from the client. Generally, to update the subscribers, the server supposes to call the pre-assigned method of all the registered clients with updated information as parameters. Doing this, the method works as transporter to transfer particular object from publisher to subscriber.
public void updateClients() { Iterator it = clients.iterator(); while (it.hasNext()) { ClientCallback client = (ClientCallback) it.next(); try { client.updateClients(); } catch (Exception e) { // note system does not halt in such situations! System.out.println(Could not update client + client.toString()); } } }
Iterating through the registered clients and calling the update method of each, to send the recently updated object as a parameter. Update Publisher (Server Callback) As discussed, there are also the situations, when client needs to call the publisher (polling). To realize the polling, the getState() method will return all the objects, which are changed on the subscribers request. It again uses the RMI pass-by-value feature, to return all the objects, which are updated by the publisher. In the case of real-time simulation, this method will work as the core, as the subscriber just need to call this method periodically and display the received objects.
public Object[] getState() throws RemoteException { SerializedBall[] locations = new SerializedBall[hash.size()]; java.util.Enumeration iter = hash.elements(); int idx = 0; while (iter.hasMoreElements()) { locations[idx++] = (SerializedBall) iter.nextElement(); } return locations; }
Page | 51
Chapter 4
Implementation
The final design, realizing the preceding scenarios, can be depicted by simple architecture (Figure 21),
Figure 21: Class diagram depicting the remote publisher-subscriber design.
As we have seen how publisher-subscriber mechanism (Network layer) can be implemented in distributed computing environment. The next challenge is to create an application on top of this layer. As we learnt, to create any GUI application the easiest way is to make use of Model, View, Controller analogy, we will map the above designed publisher-subscriber to the different component of MVC, i.e., Model, View and Controller, to proof the validity the MVC architecture for real-time collaborative GUI applications.
Page | 52
Chapter 4
Implementation
As discussed, the publisher was an appropriate map of Model in distributed context, and the Controller was considered for subscribers. Based on this concept, we will revert back them to their roles as we just used the publisher-subscriber for better understanding of role of Model and Controller according to distributed context. Reverting to the Model and Controller will give us a generic design, represented by Figure 22.
Figure 22: Class diagram representing the map of remote Publisher-Subscriber as the remote Model-Controller. The above designed components can be easily realized, as the core of network layer, in which the RemoteModel and RemoteController play the role of entry points of their server and client counterparts. The RemoteModel on a separate machine (Server) can represent all other Models, and RemoteController residing on the other machine (Client), can work as the representative of the all the Controllers and other local MVCs realizing the other GUI components.
Page | 53
Chapter 4
Implementation
4.2.2. Application Layer with Swing and Java3D

As now we have the network layer defined, which in combination with the application logic can give the complete real-time collaborative physics simulation, which can be seen by the Class diagram (Figure 23).
Figure 23: The design of simple real-time collaborative simulation with RMI.
Page | 54
Chapter 4 Model Simulation Physics
Implementation
Generally, to demonstrate the physical phenomena in simulations and games, the usage of physics engines is considered. The physics engines are developed to provide out-of-the-box solutions based on pre-solved equations and formulae possessing different physical phenomena. Due to out-of-the-box and high-level solution: the realization of logic and the usage for demonstrating a particular simple physical phenomenon is usually seen as a cumbersome process even for the experienced programmers. For the sake of simplicity, we employ a simple simulation component, to provide an example for other physics simulations to get integrated into our design. Usually in any single user animation, the terminology used as an engine to run the animation is gameLoop or simulationLoop, which normally works inside a particular method to call the other processing methods repeatedly. Therefore, the main changes, which need to be done, are centered towards this method. Considering the real-time scenario, this method is employed on two computers, and the functionality of this method is also divided between these two. As the core functionality of this method is to update the game engines involve and render the game world in synchronize and repetitive manner. In a multiuser animation, these two tasks are divided into client and server; in which the client just takes care of rendering the world based on the data received, and server get responsible to update the game-state and game logic. Employing the same technique, two gameLoops are implemented on each client and server, in which the server loop calls the Models or engines to run the simulation, while leaving the rendering process on the client-site loop. Considering reusability, the major code we added can also work as the placeholder for the other engines and Models. Other than that, the Start method, which will be called remotely from one of the client to start the simulation, will start a separate thread for only running simulation to avoid the concurrency issues.
public void start() throws RemoteException { if (running == true) { simThread.start(); } else{ running = false; simThread.interrupt(); } }
Afterwards, we confront with most crucial part simulationLoop, which is played the updateAll method, and can also work as place holder for other engines [6].
public void updateAll() { long previousTime = System.currentTimeMillis(); long currentTime = previousTime; long elapsedTime; long totalElapsedTime = 0; int frameCount = 0;
Page | 55
Chapter 4
Implementation
while (true) { currentTime = System.currentTimeMillis(); elapsedTime = (currentTime - previousTime); //elapsed time in sec totalElapsedTime += elapsedTime; if (totalElapsedTime > 1000) { //update/render took longer than current currentFrameRate = frameCount; frameCount = 0; totalElapsedTime = 0; } updateSimulation(elapsedTime / 1000f ); //Plug-in any game engine checkCollisions(); // collision detection try { Thread.sleep(5); } catch (Exception e) { e.printStackTrace(); } previousTime = currentTime; frameCount++; } }
Considering physics logic, for the sake of simplicity, we used the simple engine, demonstrating the Ball Physics. The Ball's movement is broken up into x and y speed vector, a small reduction for each step in y vector is applied to achieve the gravitational effect, while the small decrement in both vectors (each collision with a wall) is done to induce friction. For the time being, the engine assumes the same masses of bodies and for the sake of simplicity and learning, employs the Elastic Collision as a Collision detection mechanism [55]. In addition to physics Models, which are used to provide the simulation logic; to accomplish the real-time collaborative GUI interaction, the Swing components Model are also used on the server to update the conventional GUI controls, i.e., textbox, slider, button, etc., in realtime collaborative manner. Although, the Swing provides the Models for most of the controls it offers, but we just used the JSlider and JButtons Models pertaining to the requirement of simulation. View Simulation Environment To have a better user experience and realistic appearance three-dimensional environment is used. There are various 3D rendering engines are available in Java to support the 3D rendering. They are categorized, based on supporting two types of models used for 3D rendering. One class is called the scenegraph based, and the other is called non-scenegraph based. The scenegraph-based engines are considered high-level, structured, and easier, while contrary to scenegraph based engines, the non-scenegraph based are considered relatively low-level, with steep learning curve and higher level of complexity. Some of the scenegraphbased engines include Java3D, Xith3D, JME, Ardroid, etc.; while, the JOGL, LWJGL are example of non-scenegraph based engines. The JOGL, LWJGL and others, being the nonscenegraph and the wrappers of OpenGL for Java require solid background in graphics areas; Master Thesis Prototyping Real-time Collaborative Applications Page | 56
Chapter 4
Implementation
and can be unviable options for the nave programmer without theoretical graphics and mathematics knowledge [5]. Other than that, the preceding two classes of engines trade-off performance with ease-of-use. To achieve the well defined goals with higher level of expertise, and address scenarios with higher priority of performance; the non-scenegraph based engines are considered; whereas, for the rapid and structured design; the scenegraph based APIs are highly pursued. In the context of simulation and games, we realize the ease of using scenegraph to lessen the efforts on presentation layer and to emphasize on simulation logic. Considering the pros of scenegraph based APIs, we choose the Java3D. It is a scenegraph based API and abstracts away the low-level complexities, and available with huge community support and resources. An idea of a hierarchical and structured design, which can be achieved by using scenegraph APIs; can be seen, by the Figure 24 [5]:
Figure 24: The Java3D Scenegraph representing the simulation world [5]. Master Thesis Prototyping Real-time Collaborative Applications Page | 57
Chapter 4
Implementation
Heavyweight and Lightweight Components As our GUI involves the use of GUI components and Java3D environment; for that, we need to use components from both packages. As we select the Swing component library for control-panel and for overall GUI, i.e., Panels, Frames except simulation world/environment; combining the components from the Java3D library and Swing were quite cumbersome, as they belong to different classes in nature. The Swing components belong to the category of lightweight components and the Java3D components, in which Canvas3D was prominent, belongs to the class of Heavyweight components. Ultimately, all the problems came across were solved leveraging Swing MVC based architecture and particularly java.awt.Component and java.awt.Container classes [6]. Real-time Factor As the basic responsibility of simulation/game world, the View should constantly refresh/update itself for rendering any changes, received from the Model. A general approach, to create the GUIs in Java is to use the Java Swing classes, in which JFrame and JPanel are frequently used. The JFrame is used to group all JPanels representing the simulation environment and the control-panel representing the different components, to control the simulated objects.
public void start(boolean play) { simulate = true; Thread drawWorld = new Thread(this); drawWorld.start(); try { simualtion.start(play); } catch (RemoteException e) { e.printStackTrace(); } }
As per requirement, to keep the simulation running by getting the updates from the Model, the View also requires an endless loop. As discussed earlier, this is actually the part, which makes a difference, converting a single user game to multiuser game or simulation. In single user application, this loop generally did the job of updating the other engine/Models, which we already implemented on server-site, but in the multiuser application, the client is just considered to draw the simulation objects and the rest of the processing is considered perform by the server. Besides the other methods, the drawWorld() is working as core on the client to render the game world and simulation object. It calls the getState() remote method for getting the simulation state and call the getTG method of each object to render the updated object.
Page | 58
Chapter 4
Implementation
public void drawworld() throws RemoteException { ball = remBall.getState(); TransformGroup[] tgs = localSpheres.getState(); for ( int i = 0; i < numOfObjs; i++) { objTg[i].setTranslation(new Vector3f(ball[i].position.getX(), serBall[i].position.getY(), 0.0f)); tgs[i].setTransform(trans[i]); } }
The general sequence of operations, contribute, and interact to run the simulation can be viewed; by the sequence diagram (Figure 25).
Figure 25: Sequence diagram representing the sequence of basic operations involving main components.
Page | 59
Chapter 4
Implementation
Controller The notion of the Controller and exclusively the notion of the MainController is used, for the client-site representative of our architecture. The MainController, as a conventional Controller, takes care of all Views, i.e., representation of simulated objects, JComponents and local JComponent Models; while, as the MainController and being the representative of client-site, the calls to the MainModel and the reception of clients callbacks are also performed by the MainContoller. Controlling Simulation To control any simulation or game the GUI is provided with the control-panel to interact with the objects and for a better user experience. As the control-panel is also part of the View pictorially, we used another JPanel for its representation; but despite the control-panel is part of the GUI and the View; the control-panel is mainly operated by MainController. As the general practice in Java, the GUI components are directly controlled by the Controller, which is considered to provide the Listeners for different events/actions from different GUI components used in the GUI. The common examples of event listeners are; keyListener, actionListener, changeListener. As we used the JButton and JSlider more frequently, we implement the sliderListener, changelistener and actionListener and call their corresponding Models methods in-case of any event trigger, to propagate the same change to all the clients via MainController pushing methods. At the end of the implementation phase, Figure 26 presents the rough view of deployed components on the client and server.
Figure 26: Component diagram demonstrating the deployment of Applications core components.
Page | 60
Chapter 4
Implementation
The final output in the form of real-time collaborative Physics Simulation, can be viewed by the snapshot presented by Figure 27,
Figure 27: A real-time collaborative 3D Simulation demonstrating Ball Physics.
4.3. Critical Review

As a rule of thumb, any technology like the RMI supports such kind of rich development of distributed application, at the expense of several overheads. Although we experienced the handy features of RMI to provide an ease in development efforts; but at the same time, concerning the requirements of large-scale real-time distributed applications; RMI is considered, an inadequate choice from the vast majority of developers because of performance and scalability [45]. The performance and scalability shortfalls in RMI stem from the two most obvious areas, the one of them is remote-call, and the other is serialization [45]. The scenarios, where the multiple objects on different machines needs to communicate with one shared object; the solution embarks in favor of remote-calls, but the process of remote-call considered performance critical due to similar factors, e.g., that one remote-call is 1000 times slower than one local call [63]. On the other hand, the scenarios, where the application logic can be Master Thesis Prototyping Real-time Collaborative Applications Page | 61
Chapter 4
Implementation
achieved by communicating with a copy of an object, the pass-by-value is considered an option; but the serialization uses in pass-by-value, involves the process of marshalling and unmarshalling of data and opens the door for other issues; and considered as the other most performance critical process. Being a mature technology, RMI provides the solutions also for underlying problems. Considering the alternatives to remote-calls, there are various solutions possible, which includes caching the object persistent data on the client-site and used the proxies to delegate the remote-calls, like the other distributed computing paradigms, e.g., CORBA, by using the RMI dynamic loading feature [70, 85]. The other solutions embark on the application of design pattern, i.e., Adapter, Bridge, Command pattern [14], in the early design process; and the techniques like dynamic loading, caching for overall optimization. Concerning the alternatives for the second approach, a couple of solutions and libraries are available, with the optimized algorithm for serialization, and with the preference to implement Externalizable instead-of Serialization [63]. Considering these approaches to achieve optimization in the context of real-time interactive scenario, we examine some approaches, for example, the approach to cache the data. During the discussion and analysis pertaining to the development of multiuser games, most of the time is invested in deciding the network load, the data (simulation or game state), which should be sent on the network. Considering the network issues, which could arise in case of large data transfer, a small amount of data is preferred to send over the network. The caching approach can be considered in this scenario because of its underlying approach to cache the most data on the clients machine and send only the critical one, which updates frequently [70]. Examine the viability of this approach in our scenario; we found that limiting the amount of data directly affects the multiuser interaction, due to the fact that the least amount of data transfer from the server denotes the least amount of interaction from the client and consequently, on each client screen. Considering the user-friendliness and interactivity demands in our scenario any constraint on the data is critical and can affect the other functional requirements. To achieve optimization and keeping in mind the requirement of our scenario, we endorse the pass-by-value as an alternative in our or similar scenarios, if the special attention is paid at the algorithmic level during the serialization process [68, 65].
4.4. Summary
In the starting of chapter 4, the creation of a compact network framework is discussed, which came as a result of iterative approach from Agile methodology. Exploiting the framework, the development of real-time collaborative application with RMI layer was presented; and the results of using other layers were left to present in chapter 5. To have a closer look into problems and implementation challenges, the real-time collaborative simulation was developed as a case study. For the application layer, the Java3D is used to attain the realism, while the Java Swing is used to provide the GUI components for real-time collaborative control of simulation. Due to extensive use of RMI, both features of RMI, i.e., remote-calls and pass-byvalue, to facilitate the data transfer is discussed, and the vulnerability of these to network issues in terms of bandwidth consumption, lagging, timeout, latency, disconnects, and over all network performance is also highlighted. At the end of chapter, the critical review is Master Thesis Prototyping Real-time Collaborative Applications Page | 62
Chapter 4
Implementation
presented to discuss the solutions to underlying problems in general and particularly in the light of our scenario. To have a comprehensive view, the next chapter presents the testing process based on our case study and compact framework.
Page | 63
Chapter 5
Testing
Chapter 5
5.Testing
In the testing phase, we conduct testing by two different methods to test separately the application layer and network layer. For testing the application layer, we exploit Profiling; and for network, we used the prolific network testing software Wireshark29 to examine and compare the network performance of our suggested network solutions. First, we will explain profiling process; later, we will present the results of our network testing.
5.1. Profiling
Profiling is a technique, which indicates the bottlenecks in a particular application. Java introduced a utility in Java development kit (JDK)-6 with the name VisualVM30; we use VisualVM for profiling our application to find the bottlenecks and to measure overall performance. VisualVM allows the developers to generate and analyze heap dumps, perform and monitor garbage collection, trace potential memory leaks, and perform lightweight memory and Central processing Unit (CPU) profiling. VisualVM is immensely helpful to Java application developers to troubleshoot applications, by on-the-fly monitoring of: garbage collection (GC) and heap allocation activity, loaded classes, and running threads of any Java application as it runs. Additionally, the in-depth monitoring make also possible, the per-thread CPU consumption of each application, and displays also the deadlocks, contention, and other potential locking issues. The other handy features include; the identification of memory and CPU critical processes on per application basis, to locate hot spots for further debugging and optimizations [38, 64]. In overall remarks, VisualVM can easily rank as an outstanding opensource utility, and can compete with any vendor specific tools, which needs much more setup and formalities to just startup, e.g., IBM Health Centre31.
29 30
http://www.wireshark.org/ http://visualvm.java.net/ 31 http://www.ibm.com/developerworks/java/jdk/tools/healthcenter/
Page | 64
Chapter 5
Testing
5.1.1. Server-site Profiling

The main bottlenecks as indicated by the Figure 28, we found in the stepAll, which is due its critical role in running the simulation. The other methods are running normally and no performance threat can be seen from their current realization. The getState() remote-calls can be critical in the future, for which the role of optimizations, we discussed in section 4.5,
Figure 28: VisualVM GUI presenting the profiling results using different perspectives.
5.1.2. Client-site Profiling

The same data has been collected in client-site profiling. Considering the methods with highest number of calls, the simulationLoop (stepAll) was running with the same frequency, like the server, and these numbers are almost same, as we collected the number of call on the server-site. In addition to this, as in drawWorld method, we are also calling the transform of game objects to reposition them to new position from the data received by getSimState() from Master Thesis Prototyping Real-time Collaborative Applications Page | 65
Chapter 5
Testing
the server; but, as those calls are not remote and are local, they can be acceptable for similar(medium scale) scenarios. Concerning the Java3D, the negligible performance overhead is measured due to the use of the Java3D, which can be easily overcome by the use of highperformance hardware for the long-term goals.
5.2. Network Testing

To evaluate the networking solutions, and to have a deeper performance review of the used libraries, the network testing is conducted. The Network testing mainly presents a comparison and highlights the impact of the used technologies on network and overall application performance [57, 83]. The comparison can also be considerable, to decide the viability of different approaches in terms of overall performance, application demand and easeof-use. To have a closer sight on network performance, a mainstream network tool, Wireshark, is used to measure and monitor the network activity with each technology [88].
5.2.1. Wireshark
Wireshark is a highly reputed open-source network analyzer in networking community. It is used in various domains including the analysis and development of software and communication protocols, education, and network troubleshooting. Wireshark is crossplatform tool, compatible with various operating systems including UNIX, Linux, Mac OS X, BSD, Solaris, and Windows. It supports the large variety of protocols; e.g., TCP-IP, UDP, SMTP, HTTP, etc., to trace the transmission of diverse data and formats. Wireshark is also widely recognized as the Network Packet Analyzer and Packet Sniffer; it uses Pcap32 to further analyze the captured packets. The two types of filters are provided to filter the packets on different level, i.e., capture and display. The capture filters help to capture traffic/packets; with the specific profile, i.e., IP port protocol. While the display filters let the user chooses the traffic with specific criteria via easy commands. Wireshark assign different colors to different type of data to be easily recognized, and employ the color system to report different problems. It gives the closest look and provides the greater transparency to trace what happens on the network cables [88]. Wireshark is an interesting solution and more importantly a powerful user-friendly tool, which plays an outstanding role to lessen the default complexity of networking domain.
5.2.2. Test-bed
We did not use the specialized systems as test-bed. Normal computer labs desktop systems were used, to have an idea of performance and get closer to real scenario. We did not use the dedicated server, with high processing power and overall resources, which is highly recommendable for specialized network testing, and for more accurate and focused results. We used two PCs in the laboratory and dedicated one as the client and one as the server.
32
http://en.wikipedia.org/wiki/Pcap
Page | 66
Chapter 5
Testing
Client Configuration The tests are performed on Intel Pentium 4 with the following characteristics: System : Windows Xp service pack 2 version 2002 (x86_32) Processor (CPU) : Intel pentium4 CPU 2.40GHz Processor Speed : 2.39 GHz Total memory (RAM) : 1.25 GB Java : OpenJDK 1.6.0_0 32-Bit
Server Configuration The Intel Pentium 4 system used as server with the following characteristics: System : Windows Xp service pack 2 11.1 (x86_32) Processor (CPU) : Intel pentium4 CPU 2.40GHz Processor Speed: 2.39 GHz Total memory (RAM): 1 GB Java : OpenJDK 1.6.0_0 32-Bit
Wireshark GUI capabilities are used to inspect and observe the traffic; and the graphing features provided by Wireshark are exploited to present the different results. We consider few metrics, e.g., network latency, bandwidth, and round-trip time, which are most likely to affect the real-time communication and to estimate the effect of real-time communication [1, 83]. The results showed the impact of the polling and pushing mechanism on the overall network, in the form of load on the server and on the client; and the impact of the form and amount of the data sent on the network [57]. The RMI tests consisted of remote invocations to a single method, which takes none as parameter and returns an array of 10 objects. Each object in the returned array contained 13 instance variables (2 boolean, 9 float, 1 color, none of which were null), which were making total of approximately 56 bytes. The results of the first 100 invocations were excluded, in order to allow the VMs to warm up. The next 1600 invocations were counted and averaged, considering one single ball took 1600 iterations for one complete bounce.
5.3. Throughput Evaluation

We started with the throughput graphs provided by Wireshark. The throughput or bandwidth is the rate (bits per second (bps)) at which the data is transfer from a particular source to a destination [1]. The throughput graphs in Wireshark, demonstrate the throughput using TCP sequence numbers [56]. The normal Ethernet with 100Mbs Master Thesis Prototyping Real-time Collaborative Applications Page | 67
Chapter 5
Testing
connection is exploited; the result and impact on the overall throughput of the network can be seen, by the following snapshots taken during the transmission.
Figure 29: Wireshark GUI displaying the transmission of packets from client to server and server to client using RMI. The above snapshots (Figure 29) presents the detailed view of transmitting of 1196 bytes and 41 bytes via Wireshark GUI, while the results in terms of throughput are represented by the graphs (Figure 30 and 31).
5.3.1. RMI
With RMI, as presented by the graphs 30 and 31, we realized, there is huge impact on the throughput, due to large number of bytes travel across the network; while, with the Kryonet, relatively less number of bytes travelled caused relatively minor load and congestion on the network.
Page | 68
Chapter 5
Testing
Figure 30: Graph showing throughput from client to server in-case of RMI (41 bytes). The throughout graphs in Wireshark display the dots in straight-line pattern, denotes the good throughput against the transmission channel. As seen by the graph (Figure 30), sending the least amount of data, i.e., 41 bytes, relatively good throughput is measured, but with the 1196 bytes the situation gets critical as shown by the graph (Figure 31) [56].
Figure 31: Graph showing Throughput from server to client (1196 bytes). Master Thesis Prototyping Real-time Collaborative Applications Page | 69
Chapter 5
Testing
A comparatively unpromising result, i.e., more congestion and load on network is observed, due to large number of bytes travelled across the network because of default serialization algorithm used for serialization [68]. Considering the remote-calls overhead, 41 bytes are travelled in case of only one remote-call and being the cause of traffic on the network, although that is negligible, but this kind of issues can be critical for relatively complex scenarios. On our behalf as we also presented the optimized options, some results, which are taken by their use, are presented in the upcoming graphs.
5.3.2. Customized Serialization and Java NIO

To examine the effectiveness of NIO technology with customized serialization in contrast to RMI, following graphs are obtained leveraging Kryonet. The same quantity of data and objects were used, as in RMI, but a huge decrement in amount of data is noticed in comparison with transmission using RMI. The transmission of approximately 556 bytes (56 bytes per object) is observed as a result of sending an array of 10 objects to each client, and can be seen by the snapshots taken during the transmission (Figure 32),
Figure 32: Wireshark GUI displaying the transmission of packets from client to server and server to client using Kryonet.
Page | 70
Chapter 5
Testing
In contrast to RMI, as there are no remote-calls involved, and the server asynchronously updates all the clients; the following graph (Figure 33) represents, the transfer of negligible amount of data from client to server.
Figure 33: Throughput observed from client to server in-case of Kryonet. The following graph shows the transfer of 556 bytes from the server to client.
Figure 34: Graph representing throughput from server to client (556 bytes). Master Thesis Prototyping Real-time Collaborative Applications Page | 71
Chapter 5
Testing
5.4. IO Statistics
Other than throughput estimations, we examine other graphs to estimate impact of data transfer on the network and to measure performance in terms of network latency and packet loss. Following are some graphs; we obtained to elaborate the data flow overtime with each technology,
Figure 35: The average response time IO graph with customized serialization.
The spikes shown in graph (Figure 35), represents the delay, which is commonly known as the lag, which is the time between last packet and current packet; thus, tracing the lag and presenting that lag [56]. In networking terminologies, this lag is directly proportional to the latency, the low latency results in the less lagging on the network and vice-versa [57]. We used the average, because the time can vary; while, it depends on how much processes system is currently processing.
Figure 36: The average response time IO graph with default serialization in RMI. The above graph (Figure 36), showing the delay during the transmission of 41 bytes from client to server in-case of RMI transmission, we observed the lesser delay in transmission due to less number of bytes as compared to server, which we will see in next graph, Figure 36.
Page | 72
Chapter 5
Testing
Figure 37: The average response time IO graph with default serialization in RMI. The above graph (Figure 37) indicates the delay during the transmission of 1196 bytes from server to client, we see relatively higher delay in transmission due to large number of bytes as compare to client, which can be easily predicted as cause of lagging and jitter in our scenario.
5.5. Round-trip Time Evaluation

Round-trip time (RTT), which is also known as Round-trip delay, is the time t, which requires for a packet to travel from a particular source to a particular destination and return back again to source, excludes the time required for data transfer the time to fully download the transferred bytes and is therefore considered independent of throughput or bandwidth [82]. The RTT relatively has a higher importance in a wide area network (WAN) or on the Internet and considered the function of latency, which is the time between a request for data and the complete return or display of that data [82]. Nevertheless to present an idea; we test across the LAN, and present some results, which can be seen, by Figure 38 and 39:
Page | 73
Chapter 5
Testing
Figure 38: Graph representing the RTT during transmission with RMI.
Figure 39: RTT observed during transmission with custom serialization (Kryonet).
In Wireshark, graphs represent RTT by low height of dots, closer to each other; and create the horizontal line pattern, indicate the more consistent response [56]. With the RMI, we Master Thesis Prototyping Real-time Collaborative Applications Page | 74
Chapter 5
Testing
have relatively a higher quantity of disperse dots not making any pattern, which shows the lower response as compare to Kryonet. The graphs obtained with Kryonet, proof the good RTT. Generally, the dots in a vertical straight line indicate the poor RTT, which typically means the retransmissions of packets. Considering our cases, we did not find any of such pattern(vertical straight line), which predict the satisfactory results in both of cases, because of average-case scenario due to the absence of various critical factors, i.e., physical distance, number of nodes between the source and the destination, circuit interference, etc.; which mainly influence RTT.
5.6. Summary
Based on two layers: application and network, we split the testing process also into two parts. For the application layer, we applied the well-known technique profiling and for the network layer, we used the open-source network analyzer. As we need to ensure the quality of transmission, to run the simulations smoothly on multiple machines, we discussed and tested the general and likely metrics to test the network performance. In the first half of testing, the first approach was examined deploying the application with network layer leverage RMI for networking; and then the second approach was examined to examine the effectiveness of customized serialization and socket programming with NIO. From the graphs we obtained, we realized that the amount of data needed to be travelled to run the medium-sized simulation on the network can be managed leveraging RMI, but in the case of large and heavy simulations, the use of RMI is likely to create the performance issues and other overheads. To have a comprehensive view, we went into deep and presented more substantially the consequences of using RMI: the trade-off of the ease-of-use with the transfer of huge amount of data; and the overheads (sending meta-information, e.g., class information, versioning data, tags, etc.) due to Java default serialization and sending the lengthy method descriptors during remote method calls [65, 71]. On the other hand, we found the low-level solutions, i.e., NIO frameworks and customized serialization algorithms, better and scalable options due to compression techniques, an optimized serialization algorithm used. However, for the detailed benchmarking of other NIO frameworks, we discussed in chapter 4, Trustin Lees benchmarking [86], can be reviewed.
Page | 75
Chapter 6
Conclusion
Chapter 6
6. Conclusion
6.1. Summary
From the knowledge and experience, we gain in this thesis, we realize, to create an environment, like the EJS or a microworld, like Scratch, by which the pedagogic material can be made without programming is a long iterative process; and the features, like real-time collaborative interaction makes it more complex and adds an excessive amount of efforts and research in the development cycle. As we set the goal of this thesis, to have the robust and scalable foundations for such projects, we present the detailed view of the engineering process, which involves the architectural details, functional or non-functional requirements, overall software development process, and the optimized solution to each problem. We took the development of multiuser games as a reference with a difference of their overall rationale, and an addition of GUI components as application logic. Unlike the multiuser games, as these applications also required, the use of conventional GUI components with the conventional game objects; the logic behind these GUI controls, i.e., textbox, checkbox, combo-box, etc., also treated as the application logic and tailored to meet the real-time collaborative GUI demands; for which the role of existing Java GUI frameworks has also been highlighted. As far as considering this effort as the first step to introduce the real-time collaboration in kids learning environments or in microworlds, various options need to be researched from each domain and their sub-domains, i.e., networking, GUI, application logic, e.g., Physics engines, and CSCW realm. The other crucial consideration in the context of such projects includes; the involvement of qualified experts from each domain right from the beginning, with the distinction of the project as the long-term research project, rather time constrained. From the very beginning, the advanced and latest form of GUIs, e.g., the WYSIWIS, and the concepts, like EJS or similar should be aimed and focused, with the proper time invested on conceptual modeling.
Page | 76
Chapter 6
Conclusion
6.2. Future Milestones

If I got the chance to work on this project on the long term basis; unlike the other projects, e.g., Scratch, which were mainly inspired by the concept of microworlds and address the computer programming domain by exploiting the concept of Building-blocks; I would take the EJS as an inspiration and start with defining a package of physics controls and components as for normal GUI development in Swing and other packages, i.e., button, sliders, labels; which will represent the physical quantities and work as the metaphors to develop the physics simulation. However, I will not overlook the concept of microworlds and exploit for the underlying requirement of a compelling and intuitive learning tool for kids. For the robust, flexible, and scalable architecture and design, i.e., for real-time collaborative need; I would adapt the architecture, like Swings quasi-MVC architecture for development of physics components. As discussed for network layer, I would use the Kryonet and Kryo, or the combination of Netty with some optimize serialization library to best fulfill the real-time communication requirements. Other crucial considerations, pursuing this project on the long-term research include the comprehensive research in sub-domains involve in each domain; e.g., GUI, Networking, Application logic (Physics) of this project; and the exploration of different alternatives from each of them. For example, considering real-time collaborative GUI, the other GUI frameworks and libraries, e.g., Apple Cocoa, Qt Jambi, JavaFX, and WxWidgets, can be examined to explore the capabilities of an expandable GUI framework for real-time collaborative GUI controls. Considering the analogousness of real-time collaborative GUI concept with the WYSIWIS form of GUIs, the corresponding research work and methodologies can be explored and considered. Pursuing the need of intuitive and attractive GUI to promote STEM in children; the languages, such as Squeak, Tweak, and Objective-C designed specially for the underlying purposes should be examined; and the products and frameworks evolved from these languages should be reviewed. Additionally, considering the new technologies like the XML and the User Interface Language (XUL), the GUI frameworks based on these technologies, should be explored for their possible application. The tools and the concept behind the tools, such as EJS, can be further explored; and other languages like the Squeak and C++ should be considered for implementation. Considering the indulgence of the game industry, which offers the huge variety of solutions from graphics libraries to physics engines and network libraries in other languages e.g., C++; the other languages, especially the C++ and python should also be explored for their underlying advantages. Considering the integration of existing physics engines for the application logic (Physics) of these applications, the idea of employing the existing physics engine seems not productive, considering their application to only particular genre of games and their constraints to posses the limited number of physical phenomena. Contrary to that, a specialized robust physics core is advisable to posses the huge variety of physical phenomena and support the desired scalability and flexibility.
Page | 77
Chapter 6
Conclusion
6.3. Personal Thoughts

During this project, I explore the wide range of development methodologies and software technologies ranging from: development, design, graphics, and networking; which is quite overwhelming for me, to pursue my career as a software engineer. Because of the nature of project, I learnt how to tackle the large projects and the projects with the un-conventional goals, addressing the particular age group and involve a huge variety of stakeholders, i.e., Software, Education, Psychological, and Information.
6.4. Secondary Achievements

Adaptation of advanced domains, i.e., WYSIWIS interface in Education for better experience and strict real-time collaborative work; transition from beyond basic lab activities to advanced methods of teaching. Explore and innovate the effectiveness of new information and communication technologies for STEM education. Creation of research-based solutions involving diverse communities and stakeholders. Exploration of un-conventional form of real-time collaboration, for un-conventional domain (multiuser microworlds). Broaden opportunities for youth from unsocial nerds to become social asset by becoming teachers and mentors with real-time collaborative work. Highlighting the need of coordination between the Educationists, Researchers, and IT professionals.
Page | 78
References
Printed References
1. Aaron McCoy, Declan Delaney, Tomas Ward. Game-State Fidelity across Distributed Interactive Games. 2003. ACM Article Volume 9 Issue 4. 2. Alexander Repenning, Andri Ioannidou, John Zola. AgentSheets: End-User Programmable Simulations. 2000. Journal of Artificial Societies and Social Simulation, Vol. 3, No. 3. 3. Alexander Repenning, Andri Ioanniduo, Jonathan Philips. Collaborative use & design of interactive simulations. 1999. ACM conference on Computer Supported cooperative learning (CSCL 99). 4. Andrs Monroy-Hernndez. Designing a website for creative learning Proceedings of the WebSci'09: Society On-Line. 2009. 5. Andrew Davidson, Pro Java 6 3D Game Development. 2007. Apress. Chapter 1, pp. 314. Chapter 5, pp.121-144. 6. Andrew Davidson. Killer Game Programming in Java, O'Reilly Media. 2005. Chapter 2, pp.10-31. Chapter 29. 7. Andrew Davidson. The myths (and truths) of Java games programming, Department of Computer Engineering, Prince of Songkla University, Hat Yai, Songkhla 90112, Thailand. 8. Anonymous. Distributed Application Architecture. 2000. O'Reilly & Associates. 9. Ashwin R. Bharambe, Jeffrey Pang, Srinivasan Seshan. Colyseus: A Distributed Architecture for Online Multiplayer Games. 2006. NSDI'06 Proceedings of the 3rd conference on Networked Systems Design & Implementation - Volume 3 USENIX Association Berkeley, CA, USA. 10. Charles Crook. Children as computer users: the case of collaborative learning, Computers & Education. 1998. Volume: 30, Issue: 3-4, pp. 237-247. 11. Dan Ingalls et al. Back to the future: the story of Squeak, a practical Smalltalk written in itself. 1997. OOPSLA 97: Proc. of the 12th ACM SIGPLAN Conference on Object-oriented Programming. pp. 318-326. 12. Eric Klopfer, Scot Osterweil, Jennifer Groff, Jason Haas. Using the Technology of Today in the Classroom Today. 2009. The Education Arcade, MIT. 13. Fu-Kwun Hwang. Easy Java Simulation: A Modeling Tool for Physics Teaching and Learning. Dept. of Physics, National Taiwan Normal Univ., Taiwan. 14. Gamma, E., Helm, R., Johnson, R. and Vlissides, J. Design Patterns - Elements of Reusable Object-Oriented Software. 1995. Reading MA, Addison-Wesley. Chapter 5, pp 326 337, pp. 121-132. 15. Gerald Brose, Rima Patel Sriganesh. Mastering Enterprise JavaBeans, Third Edition. 2006. Wiley Publishing, pp 3-52.
Page | 79
16. Gerry Stahl, Timothy koschmann, Dan Suthers. Computer-supported collaborative learning: A historical perspective. 2006. In Cambridge handbook of the learning sciences, pp. 409-426. 17. Jeremy Roschelle et al. Developing Educational Software Components. 1999. IEEE Computer - COMPUTER , vol. 32, no. 9, pp. 50-58. 18. Jeroen Warmerdam et al. SimPort: a multiplayer management game framework. 2006. In: Proceedings of 9th International Conference on Computer Games - CGAMES'06, 22-24 November, Dublin, Ireland. 19. Jim Highsmith, Alistair Cockburn. Agile Software Development: The Business of Innovation. 2001. IEEE Computer Society/ ACM joint task force on Computing Curricula 2001, http://computer.org/ education/curricula2001. 20. John Maloney et al. Scratch: A Sneak Preview. 2004. C5 '04 Proceedings of the Second International Conference on Creating, Connecting, and Collaborating through Computing. 21. John Maloney. An Introduction to Morphic: The Squeak User Interface Framework. 2000. WaltDisney Imagineering. 22. Julia Kehl, Claudia Schlienger, Olaf A. Schulte. Evaluation of synchronous e-collaboration tools. 2009. NET, ETH Zurich. 23. K Kahn, ToonTalk - An Animated Programming Environment for Children. 1996. Journal of Visual Languages and Computing. 24. Loo Kang WEE, Wai Keong MAK. Leveraging on Easy Java Simulation tool and opensource computer simulation library to create interactive digital media for mass customization of high school physics curriculum. 2009. Paper presented at the 3rd Redesigning Pedagogy International Conference, Singapore. Source: http://conference.nie.edu.sg/2009/papers_pdf/PAP591.pdf. 25. M. Stefik et al. WYSIWIS Revised: Early Experiences with Multiuser Interfaces. 1987. ACM Transactions on Information Systems, Volume 5 Issue 2. 26. Maria Virvou, George Katsionis, Konstantinos Manos. Combining software games with education: Evaluation of its educational effectiveness. 2005. Educational Technology & Society. 27. Matthew Conway. Alice: Lessons Learned from Building a 3D System for Novices. 2000. CHI 2000. 28. Nikolaos M. Avouris, Meletis Margaritis and Vassilis Komis. Real-time Peer Collaboration in Open and Distance Learning. 2003. Proc 6th HERCMA 2003, Athens. 29. Oren Zuckerman et al. Childrens Participation Patterns in Online Communities: An Analysis of Israeli Learners in the Scratch Online Community. 2009. Interdisciplinary Journal of E-Learning and Learning Objects, pp. 263-274. 30. Seymour Papert. Mindstorms: Children, Computers, and Powerful Ideas. 1980. Basic Books, Inc. New York, USA. Chapter 5, pp. 120-134. 31. Paris Avgeriou, Peter Tandler. Architectural patterns for collaborative applications. 2006. International Journal of Computer Applications in Technology, Volume 25 Issue 2/3, Inderscience Publishers, Geneva, Switzerland. 32. Qusay H. Mahmoud. Distributed Programming with Java. 1999. Manning Publications Co. Chapter 10, pp. 163-171; Chapter 5, pp. 69-84.
Page | 80
33. Randy Pausch et al. A brief architectural preview of Alice a rapid prototyping system for virtual reality. 1995. IEEE Computer Graphics and Applications) User Interface Group, Computer Science Department, University of Virginia. 34. Rena Palloff, Keith Pratt. Building Learning Communities in Cyberspace. Effective strategies for the online classroom, 1st edition. 1999. Jossey-Bass Publishers. San Francisco. 35. Robert Englander. Java and SOAP. 2002. O'Reilly, pp. 7-12. 36. Ron Hitchens. Developing high-performance applications. 2003. o`Reilly. pp 4-7. 37. Sendova, E., Nikolova, I., Gachev, G. WebLabs: Virtual collaborative learning experience for researchers, teachers, and students. 2005. In Proceedings, KAL Workshop, November 2005, Sofia, pp. 21-30. 38. Sheng Liang and Deepa Viswanathan. Comprehensive Profiling Support in the Java Virtual Machine. 1999. 5th USENIX Conference on Object-Oriented Technologies and Systems (COOTS '99), San Diego, California, USA. 39. Sneha Veeragoudar Harrell et al. Virtually There: Emerging designs from STEM teaching and learning in immersive online 3D Microworlds. Graduate School of Education, University of California-Berkeley, Berkeley. 40. Swigger Kathleen M. et al. Real time collaboration over the Internet; what actually work? 1999. SITE 99: Society for Information Technology & Teacher Education International Conference. University of North Texas. 41. Uwe M. Borghoff, Johann H. Schlichter. Computer-supported cooperative work: introduction to distributed applications, 1st edition. 2000. Springer. 42. W. Christian, M. Belloni, and D. Brown. An Open Source XML Framework for Authoring Curricular Material. Computing in Science and Engineering. 2006. pp 51-58. 43. W. Christian. Open Source Physics: A Users Guide with Examples. 2006. AddisonWesley. 44. W. Hibbard. VisAD: Connecting people to computations and people to people. 1998. ACM SIGGRAPH Computer Graphics, Volume 32 Issue 3, pp. 10-12. 45. William Grosso. 2001. Java RMI. O'Reilly. Chapter 10, Chapter 11. 46. William Hibbard et al. Java distributed components for numerical visualization in VisAD. 2005. Communications of the ACM, Volume 48, Issue 3. 47. Wolfgang Christian, Francisco Esquembre. Modeling Physics with Easy Java Simulations. 2008. The Physics Teacher. Volume 45, Issue 10, pp. 475-480.
Page | 81
Online References
48. Agile software development. URL: http://en.wikipedia.org/wiki/Agile_software_development#cite_noteAgile_Manifesto-0 (Accessed on 09/08/2010). 49. Anonymous, Blueprint for Collaborative Application Architecture, Cisco White Paper Cisco Systems. 2008-2009. 50. Anonymous, Java Swing model architecture. URL: http://zetcode.com/tutorials/javaswingtutorial/swingmodels/ (Accessed on 15/7/2011) 51. Anonymous, The opportunity Equation: Transforming Mathematics and Science Education for citizenship and the Global Economy. Carnegie Corporation of New YorkInstitute for Advanced Study, Commission on Mathematics and Science Education. URL: http://www.opportunityequation.org/ (Accessed on 07/02/2010). 52. Anonymous. American competitiveness Initiative: Research and Development Funding in the Presidents 2007 budget. 2007. Office of Science and Technology Policy, Executive Office of the President. URL: http://www.ostp.gov/pdf/1pger_aci.pdf (Accessed on 13/02/2010). 53. Anonymous. American Youth Policy Forum Advancing STEM learning across the educational pipeline: Statewide effort in Ohio. 2009. URL: http://www.aypf.org/documents/STEMIssueBrief-Final.pdf (Accessed on 09/08/2010). 54. Anonymous. The Economic Impact of the Achievement Gap in Americas school. McKinsey&Company. 2009. URL: http://www.mckinsey.com/App_Media/Images/Page_Images/Offices/SocialSector/PDF/det ailed_achievement_gap_findings.pdf (Accessed on 4/9/2009). 55. Ball to Ball Collision - Detection and Handling. URL: http://stackoverflow.com/questions/345838/ball-to-ball-collision-detection-andhandling (Accessed on 4/9/2009). 56. BU-9 Wireshark Charts & IO Graphs. URL: http://sharkfest.wireshark.org/sharkfest.09/bu-9-tompkins-gearbitwireshark_charts_&_io_graphs-sharkfest09.pdf (Accessed on 4/9/2009). 57. David H. Brandt. Accelerating Online Gaming Defining and Defeating Lag in Online Gaming, New Technology. 58. Fowler Amy. A Swing Architecture Overview. URL: http://zetcode.com/tutorials/javaswingtutorial/swingmodels/ (Accessed on 15/7/2011). 59. Gregor Roth. Architecture of a Highly Scalable NIO-Based Server. 2007. http://today.java.net/pub/a/today/2007/02/13/architecture-of-highly-scalable-nioserver.html (Accessed on 09/03/2011). 60. Grizzly. URL: http://grizzly.java.net/ (Accessed on 15/7/2011). 61. H. Jenkins et al. Confronting the Challenges of Participatory Culture: Media Education for the 21st Century, 2006. Chicago: The MacArthur Foundation, Chicago, Illinois, USA. URL: http://digitallearning.macfound.org/atf/cf/%7B7E45C7E0-A3E04B89-AC9C-E807E1B0AE4E%7D/JENKINS_WHITE_PAPER.PDF (Accessed on 4/9/2009) Master Thesis Prototyping Real-time Collaborative Applications Page | 82
62. Java Message Service API Overview. URL: http://www.oracle.com/technetwork/java/overview-137943.html (Accessed on 15/7/2011). 63. Java Performance Tuning. URL: http://www.javaperformancetuning.com/tips/j2ee_rmi.shtml (Accessed on 09/03/2011). 64. Java VisualVM. URL: http://download.oracle.com/javase/6/docs/technotes/guides/visualvm/index.html (Accessed on 15/7/2011). 65. JavaRemoteMethodInvocation Specification. 2004. Sun Microsystems, Inc. URL: http://java.sun.com/j2se/1.5/pdf/rmi-spec-1.5.0.pdf (Accessed on 15/7/2011). 66. JMS. URL: http://en.wikipedia.org/wiki/Java_Message_Service (Accessed on 09/03/2011). 67. John Deacon, Model-View-Controller architecture. 1995. John Deacon Computer Systems Development, Consulting and Training. URL: http://www.jdl.co.uk/briefings/MVC.pdf (Accessed on 09/03/2011). 68. Kryo. URL: http://code.google.com/p/kryo/ (Accessed on 09/03/2010). 69. Kryonet. URL: http://code.google.com/p/kryonet/ (Accessed on 09/03/2011). 70. M. Jeff Wilson, Get smart with proxies and RMI, Use dynamic class loading to implement smart proxies in RMI. URL: http://www.javaworld.com/javaworld/jw-112000/jw-1110-smartproxy.html (Accessed on 15/7/2011). 71. Mark Davis. Serialization. URL: http://macchiato.com/columns/Durable4.html. 72. Matthias Kalle Dalheimer. Qt vs. Java A Comparison of Qt and Java for Large-Scale, Industrial-Strength GUI Development. 2010. Klarlvdalens Datakonsult AB. 73. Message passing vs Remote procedure call. URL: http://www-scf.usc.edu/~shailesn/csci555/mp_vs_rpc.html (Accessed on 09/03/2011). 74. Mikko Kontio. Architectural manifesto: Adopting agile development, Part 1 Is agile development right for your organization? URL: http://www.ibm.com/developerworks/architecture/library/ar-archman1/index.html (Accessed on 09/03/2011). 75. MINA Architecture: http://mina.apache.org/mina-based-application-architecture.html (Accessed on 03/08/2010). 76. Mitchel Resnick, Yasmin Kafai, John Maeda, A network media rich programming in enhanced Technological Fluency at after-School Centers in economical disadvantaged communities. 2003-2007. National Science Foundation (Information Technology Research). URL: http://web.media.mit.edu/~mres/papers/scratch-proposal.pdf (Accessed on 4/9/2009). 77. MVC. URL: http://ootips.org/mvc-pattern.html (Accessed on 09/01/2010). 78. Netty. URL: http://www.jboss.org/netty/documentation (Accessed on 15/7/2011). 79. NIOframework. URL: nioframework.sourceforge.net/ (Accessed on 15/7/2011). 80. Peter Saint-Andre and Ralph Meijer, Streaming XML with Jabber/XMPP. 2005. URL: www.saint-andre.com/jabber/xtech2005.pdf (Accessed on 15/7/2011). 81. Quickserver. URL: http://www.quickserver.org/ (Accessed on 15/7/2011). 82. Round trip time. URL: http://searchnetworking.techtarget.com/definition/round-triptime (Accessed on 15/7/2011). Master Thesis Prototyping Real-time Collaborative Applications Page | 83
83. The network impact on application performance: TCPing IT performance consulting. 84. The role of real time virtual collaboration in product development. 2007. Aberdeen group. URL: http://www.tandberg.com/collateral/The_Role_of_Real_Time_Virtual_Collaboration_in _Product_Development.pdf (Accessed on 15/7/2011). 85. Tom Albertson, Best practices in distributed object application development: RMI, CORBA, and DCOM. URL: http://www.developer.com/tech/article.php/602081/Bestpractices-in-distributed-object-application-development-RMI-CORBA-and-DCOM.htm (Accessed on 09/08/2010). 86. Trustin lee. NIO framework Benchmark. URL: http://gleamynode.net/articles/2232/ (Accessed on 15/7/2011). 87. Victor Szalvay. An Introduction to Agile Software Development, 2004. Danube Technologies, Inc. 88. WireShark. URL: http://en.wikipedia.org/wiki/Wireshark (Accessed on 09/08/2010). 89. xSocket. URL: http://sourceforge.net/projects/xsocket/ (Accessed on 4/9/2009).
Page | 84

Master Arbeit

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Master Arbeit

Hochgeladen von

Copyright:

Verfügbare Formate

PROTOTYPING REAL-TIME

Thesis submitted in partial fulfillment of the degree

2.2. Our Methodology ........................................................................................................................... 14

2.3. Summary .......................................................................................................................................... 16

3. Design and Analysis............................................................................................................................ 17 3.1. Graphical User Interface ............................................................................................................... 19

3.2. GUI Packages .................................................................................................................................. 23

4.2. Real-time Collaborative Physics Simulation ............................................................................... 48

5.2. Network Testing.............................................................................................................................. 66

5.3. Throughput Evaluation .................................................................................................................. 67

5.3.2. Customized Serialization and Java NIO......................................................................................... 70

Master Thesis Prototyping Real-time Collaborative Applications

Master Thesis Prototyping Real-time Collaborative Applications

Master Thesis Prototyping Real-time Collaborative Applications

1.7. Overview of Thesis

Master Thesis Prototyping Real-time Collaborative Applications

Master Thesis Prototyping Real-time Collaborative Applications

2.1.1. Real-time Collaborative Solutions and Opportunities

http://code.google.com/apis/wave/ http://www.adobe.com/products/livecycle/collaborationservice/ 3 docs.google.com/ 4 http://www.adobe.com/uk/acom/buzzword/ 5 http://ietherpad.com/

Master Thesis Prototyping Real-time Collaborative Applications

2.1.2. Pedagogical Repositories

http://www.compadre.org/osp/ http://www.agentsheets.com/ 8 http://www.escot.org/ 9 http://www.eoe.org

Master Thesis Prototyping Real-time Collaborative Applications

Master Thesis Prototyping Real-time Collaborative Applications

2.1.4. Authoring Tools

http://toontalk.com/ http://www.greenfoot.org/ 12 http://www.stagecast.com/

Master Thesis Prototyping Real-time Collaborative Applications

Figure 2: Four different views of the EJS GUI13.

Master Thesis Prototyping Real-time Collaborative Applications

Master Thesis Prototyping Real-time Collaborative Applications

2.1.5. Game Development

2.2. Our Methodology

Master Thesis Prototyping Real-time Collaborative Applications

Master Thesis Prototyping Real-time Collaborative Applications

Master Thesis Prototyping Real-time Collaborative Applications

Design and Analysis

Master Thesis Prototyping Real-time Collaborative Applications

Design and Analysis

Master Thesis Prototyping Real-time Collaborative Applications

Design and Analysis

3.1. Graphical User Interface

Master Thesis Prototyping Real-time Collaborative Applications

Design and Analysis

3.1.2. Model-View-Controller (MVC)

Master Thesis Prototyping Real-time Collaborative Applications

Design and Analysis

Master Thesis Prototyping Real-time Collaborative Applications

Design and Analysis

Master Thesis Prototyping Real-time Collaborative Applications

Design and Analysis

3.2. GUI Packages

Master Thesis Prototyping Real-time Collaborative Applications

Design and Analysis

Figure 10: An adaptation of Separable Model Architecture by a single Swing component21.

Master Thesis Prototyping Real-time Collaborative Applications

Design and Analysis

Figure 11: A detailed view of WYISWYG, Drag&Drop Qt Designer23.

Master Thesis Prototyping Real-time Collaborative Applications

Design and Analysis

Master Thesis Prototyping Real-time Collaborative Applications

Design and Analysis

Master Thesis Prototyping Real-time Collaborative Applications

Design and Analysis

Master Thesis Prototyping Real-time Collaborative Applications