Sam 106100 Thesis - Final

COMPARATIVE ANALYSIS OF SOFTWARE ARCHITECTURAL PATTERNS FOR MOBILE AD HOC NETWORK VISUALIZATION APPLICATIONS by

Munkhsambuu Badrakh

A thesis submitted in partial fulfillment of the requirements for the degree of Master of Science in Computer Science with Specialization in Software Engineering

Examination Committee:

Prof. Kanchana Kanchanasut (Chairperson) Dr. Paul Janecek Dr. Matthew Dailey

Nationality: Mongolian Previous Degree: Bachelor of Arts in Computer Science American University in Bulgaria Blagoevgrad, Bulgaria Scholarship Donor: Asian Development Bank

Asian Institute of Technology School of Engineering and Technology Thailand July 2009

i

Acknowledgements First and foremost, I would like to acknowledge my advisor, Prof. Kanchana Kanchanasut. Throughout the course of my research she provided me with timely and valuable advice, indispensable support, and excellent facilities. Her courtesy, professionalism, and patience made working with her very rewarding and gratifying. Funding for this research was provided by the Asian Development Bank. My special thanks for their financial support and the approval of a generous scholarship. I would like to thank and express my gratitude to everyone who directly or indirectly contributed to the realization of this thesis. Many thanks to all members of the DUMBO project at IntERLab whose professional work in MANET has had a direct impact on the contribution of this thesis.

ii

Abstract The purpose of this thesis is to compare and contrast software architectural patterns for developing a visualization application for mobile ad-hoc networks. The research focuses on primary requirements of the design and architecture of the proposed system and evaluates blackboard, pipes and filters and layers architectural patterns as suitable candidates for the software implementation. Automated location information software for visualization of nodes in a mobile ad hoc network using geographic coordinates is proposed. The thesis argues that layers architectural pattern with the domain logic layer implemented in a pipes and filters fashion provide the most suitable approach to fulfilling the primary requirements and designing the proposed the system. The components of the overall architecture, data flow and system states are presented with each particular pattern to identify the advantages and drawbacks of the particular implementation.

iii

Table of Contents CHAPTER

TITLE

PAGE

Title Page Acknowledgements Abstract Table of Contents List of Abbreviations List of Figures List of Tables

i ii iii iv v vi vii

1

Introduction 1.1 Rationale for this thesis 1.2 Statement of the problem 1.3 Objectives 1.4 Method 1.5 Structure of the thesis

1 1 1 1 2 2

2

Literature Review 2.1 Mobile ad-hoc network 2.2 Position information in MANET 2.3 Visualization of MANET 2.3 Software Patterns

3 3 7 8 13

3

Analysis of Patterns 3.1 Introduction 3.2 Pipes and Filters 3.3 Layers 3.4 Blackboard

19 19 23 30 34

4

Results and Discussion 4.1 Factors to consider in system development 4.2 Interaction between nodes 4.2 Software specifications and requirements

39 39 40 41

5

Conclusion and Recommendations 5.1 Architectural decision 5.2 Suitable pattern 5.3 Layering alternatives

43 43 43 44

Bibliography

47

Appendixes

50

iv

List of Abbreviations ASP DSRC DUMBO GPS GSM HTTP IMANET InVANET IP ITS IEEE IVC MANET MVS NAM NS OLSR OSI PHP PAC RVC SOA TCP TDF V2R V2V VANET VBScript VoIP XML

Active Server Pages Dedicated short range communications Digital ubiquitous mobile broadband OLSR Global positioning system Global system for mobile communications Hypertext transfer protocol Internet mobile ad-hoc network Intelligent vehicular ad-hoc network Internet protocol Intelligent transportations systems Institute of Electrical and Electronics Engineers Inter-vehicle communication Mobile ad-hoc network Model-view-controller Network animator Network simulator Optimized link state routing protocol Open systems interconnection Hypertext preprocessor Presentation-abstraction-control Roadside-to-vehicle communication Service oriented architecture Transmission control protocol Topology definition file Vehicle-to-roadside Vehicle-to-vehicle Vehicular ad-hoc network Visual Basic Script Voice over internet protocol Extensible markup language

v

List of Figures FIGURE

TITLE

2.1 2.2 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 4.1 4.2 5.1

MANET behavior Architecture of the proposed system Use case model of the visualization system Pipes and filters pattern MANET visualization process as a pipeline Batch processing in a pipeline GeoDraw raw data GeoDraw data elements GeoDraw screenshot GeoDraw XML file Layers pattern MANET visualization application layers Blackboard architecture scenario Basic components of the blackboard model Blackboard model with nodes as knowledge sources Blackboard model with processing units for each task Logistics tracking system MANET visualization system Layers combined with pipes and filters architecture

PAGE

vi

3 10 19 23 25 26 27 28 28 29 30 32 35 37 38 39 41 42 46

List of Tables TABLE

TITLE

3.1 3.2 3.3 3.4 3.5 4.1

Manage Map use case description Manage Nodes use case description Search History use case description Manage Content use case description System data entry properties Distribution of tasks for each architectural pattern

PAGE

vii

20 20 21 21 22 42

CHAPTER I INTRODUCTION 1.1 Rationale for the thesis The motivation for this thesis is to establish a solid foundation for thorough and complete documentation for developing a MANET visualization system from a software design view. Software patterns provide a solution to recurring design problems and MANET visualization is a large and complex task. Evaluating different patterns, selecting suitable approaches, as well as extending and modifying them to suit the requirements and specifications can facilitate a constructive development of software systems. This thesis discusses a possible solution to the problem and describes an implementation of the system. Analyzing existing reusable solutions to many common challenges can effectively support rapid and efficient software development. Even though finding and applying architectural and design patterns in practice still remains largely adhoc and unsystematic, thorough study of elements and relationships contained in the system can pinpoint implementation details of the application. 1.2 Statement of the problem Building robust, efficient, extensible and concurrent application is hard. Many complex challenges must be addressed. There is no clear approach and understanding of the requirements and designs of the proposed visualization system. Current literature and findings on existing similar works are inadequate and far from comprehensive. While there are similar software systems for logistics tracking, the characteristics and implications of wireless network nodes and mobile nodes in particular require a different approach. 1.3 Objectives The main purpose of this study is to compare software patterns for development of a MANET visualization system. The objectives of this study can be specified as follows: 1. To compile necessary knowledge for developing a comprehensive MANET visualization system. 2. To describe and explain the need for the proposed system and its contribution to mobile ad hoc network applications in real life 3. To evaluate different approaches and alternatives of software patterns which are suitable for the proposed architecture 4. To identify the architectural pattern for developing the proposed system and provide initial documentation for future work.

1

1.4 Method Data gathered during the process of an actual MANET visualization system development, requirement and specifications in particular, will be analyzed concurrently with architectural and design patterns. The designing and coding phase would involve implementing requirements and specifications of GeoDraw 2.0 based on feedback received from the previous version, as well as developing necessary prototypes for each selected pattern. 1.5 Structure of the thesis This thesis is organized into five chapters. Chapter 1 provides the general background including statement of the problem and objectives of the study. Chapter 2 imparts review of the relevant literature and past researches. Chapter 3 presents software architecture and design patterns and application of them in MANET visualization system development. Chapter 4 demonstrates the evaluation process of proposed patterns. Finally Chapter 5 consists of conclusions and recommendations for further studies and development. Moreover samples of simulations and tests, their results and other related documents are attached in Appendices.

2

CHAPTER II LITERATURE REVIEW 2.1 Mobile ad-hoc network 2.1.1 Introduction With recent performance advancements in computer and wireless communications technologies, advanced mobile wireless computing is expected to see increasingly widespread use and application, much of which will involve the use of the Internet Protocol (IP) suite. The vision of mobile ad hoc networking is to support robust and efficient operation in mobile wireless networks by incorporating routing functionality into mobile nodes. Such networks are envisioned to have dynamic, sometimes rapidlychanging, random, multihop topologies which are likely composed of relatively bandwidth-constrained wireless links. Within the Internet community, routing support for mobile hosts is presently being formulated as "mobile IP" technology. This is a technology to support nomadic host "roaming", where a roaming host may be connected through various means to the Internet other than its well known fixed-address domain space. The host may be directly physically connected to the fixed network on a foreign subnet, or be connected via a wireless link, dial-up line, etc. Supporting this form of host mobility (or nomadicity) requires address management, protocol interoperability enhancements and the like, but core network functions such as hop-by-hop routing still presently rely upon pre-existing routing protocols operating within the fixed network. In contrast, the goal of mobile ad hoc networking is to extend mobility into the realm of autonomous, mobile, wireless domains, where a set of nodes, which may be combined routers and hosts, themselves form the network routing infrastructure in an ad hoc fashion (Corson and Macker, 1999). Typical Wireless Network

Mobile Ad-Hoc Network

B A

B

B A

A

Figure 2.1. The first image shows that in a typical wireless network a node can establish with nodes only in its direct communication range. However in MANET, all nodes are connected through intermediate neighbors. In addition, if a node moves out of a neighbor’s range, communications are automatically re-routed to maintain connectivity. (Modified from L-3 Communications Nova Engineering, 2009)

3

2.1.2 Applications The technology of Mobile Ad hoc Networking is somewhat synonymous with Mobile Packet Radio Networking (a term coined via during early military research in the 70's and 80's), Mobile Mesh Networking and Mobile, Multihop, Wireless Networking (perhaps the most accurate term, although a bit cumbersome). There is current and future need for dynamic ad hoc networking technology. The emerging field of mobile and nomadic computing, with its current emphasis on mobile IP operation, should gradually broaden and require highly-adaptive mobile networking technology to effectively manage multihop, ad hoc network clusters which can operate autonomously or, more than likely, be attached at some point(s) to the fixed Internet. It is easy to imagine a number of applications where this type of properties would bring benefits. One interesting research area is inter-vehicle communications. It is one area where the ad hoc networks could really change the way we communicate covering personal vehicles as well as professional mobile communication needs. Also, it is area where no conventional (i.e. wired) solutions would do because of the high level of mobility. When considering demanding surroundings, say mines for example, then neither would the base station approach work but we must be able to accomplish routing via nodes that are part of the network i.e. we have to use ad hoc network (Rashmi, 2008). Such networks can be used to enable next generation of battlefield applications envisioned by the military including situation awareness systems for maneuvering war fighters, and remotely deployed unmanned micro-sensor networks. Ad Hoc networks can provide communication for civilian applications, such as disaster recovery and message exchanges among medical and security personnel involved in rescue missions. Some applications of MANET technology could include industrial and commercial applications involving cooperative mobile data exchange. In addition, mesh-based mobile networks can be operated as robust, inexpensive alternatives or enhancements to cell-based mobile network infrastructures. There are also existing and future military networking requirements for robust, IP-compliant data services within mobile wireless communication networks where many of these networks consist of highly-dynamic autonomous topology segments. Also, the developing technologies of "wearable" computing and communications may provide applications for MANET technology. When properly combined with satellite-based information delivery, MANET technology can provide an extremely flexible method for establishing communications for fire/safety/rescue operations or other scenarios requiring rapidly-deployable communications with survivable, efficient dynamic networking. There are likely other applications for MANET technology which are not presently realized or envisioned by the authors. It is simply put, improved IP-based networking technology for dynamic, autonomous wireless networks (Corson and Macker, 1999). 2.1.3 Types of MANET VANET

4

Vehicular Ad Hoc Networks (VANETs) are used for communication among vehicles and between vehicles and roadside equipment. A Vehicular Ad-Hoc Network, or VANET, is a form of Mobile ad-hoc network, to provide communications among nearby vehicles and between vehicles and nearby fixed equipment, usually described as roadside equipment. The main goal of VANET is providing safety and comfort for passengers. To this end a special electronic device will be placed inside each vehicle which will provide AdHoc Network connectivity for the passengers. This network tends to operate without any infra-structure or legacy client and server communication. Each vehicle equipped with VANET device will be a node in the Ad-Hoc network and can receive and relay others messages through the wireless network. Collision warning, road sign alarms and in-place traffic view will give the driver essential tools to decide the best path along the way. There are also multimedia and internet connectivity facilities for passengers, all provided within the wireless coverage of each car. Automatic payment for parking lots and toll collection are other examples of possibilities inside VANET. Most of the concerns of interest to MANETs are of interest in VANETs, but the details differ. Rather than moving at random, vehicles tend to move in an organized fashion. The interactions with roadside equipment can likewise be characterized fairly accurately. And finally, most vehicles are restricted in their range of motion, for example by being constrained to follow a paved highway. Vehicular Ad-hoc Networks are expected to implement variety of wireless technologies such as Dedicated Short Range Communications (DSRC) which is a type of WiFi. Other candidate wireless technologies are Cellular, Satellite, and WiMAX. Vehicular Ad-hoc Networks can be viewed as component of the Intelligent Transportation Systems (ITS). Vehicles communicate with each other via Inter-Vehicle Communication (IVC) as well as with roadside base stations via Roadside-to-Vehicle Communication (RVC). The optimal goal is that vehicular networks will contribute to safer and more efficient roads in the future by providing timely information to drivers and concerned authorities. Various forms of wireless communications technologies have been proposed for intelligent transportation systems. Short-range communications (less than 500 yards) can be accomplished using IEEE 802.11 protocols, specifically WAVE or the Dedicated Short Range Communications standard being promoted by the Intelligent Transportation Society of America and the United States Department of Transportation. Theoretically, the range of these protocols can be extended using Mobile ad-hoc networks or Mesh networking. Longer range communications have been proposed using infrastructure networks such as WiMAX (IEEE 802.16), Global System for Mobile Communications (GSM), or 3G. Long-range communications using these methods are well established, but, unlike the short-range protocols, these methods require extensive and very expensive infrastructure deployment. There is lack of consensus as to what business model should support this infrastructure (Ecole Polytechnique Federale de Lausanne, 2005). InVANET Intelligent vehicular ad hoc networks (InVANETs) are a kind of artificial intelligence that helps vehicles to behave in intelligent manners during vehicle-to-vehicle

5

collisions, accidents, drunken driving etc. InVANET integrates on multiple ad-hoc networking technologies such as WiFi IEEE 802.11 b/g, WiMAX IEEE 802.16, Bluetooth, IRA, ZigBee for easy, accurate, effective and simple communication between vehicles on dynamic mobility. Effective measures such as media communication between vehicles can be enabled as well methods to track the automotive vehicles are also preferred. InVANET helps in defining safety measures in vehicles, streaming communication between vehicles, infotainment and telematics. Automotive vehicular information can be viewed on electronic maps using the Internet or specialized software. The advantage of WiFi based navigation system function is that it can effectively locate a vehicle which is inside big campuses like universities, airports, and tunnels. InVANET can be used as part of automotive electronics, which has to identify an optimally minimal path for navigation with minimal traffic intensity. The system can also be used as a city guide to locate and identify landmarks in a new city. Communication capabilities in vehicles are the basis of an envisioned InVANET or intelligent transportation systems (ITS). Vehicles are enabled to communicate among themselves (vehicle-to-vehicle, V2V) and via roadside access points (vehicle-to-roadside, V2R). Vehicular communication is expected to contribute to safer and more efficient roads by providing timely information to drivers, and also to make travel more convenient. The integration of V2V and V2R communication is beneficial because V2R provides better service sparse networks and long distance communication, whereas V2V enables direct communication for small to medium distances/areas and at locations where roadside access points are not available. Providing vehicle-to-vehicle and vehicle-to-roadside communication can considerably improve traffic safety and comfort of driving and traveling. For communication in vehicular ad hoc networks, position-based routing has emerged as a promising candidate. For Internet access, Mobile IPv6 is a widely accepted solution to provide session continuity and reachability to the Internet for mobile nodes. While integrated solutions for usage of Mobile IPv6 in (non-vehicular) mobile ad hoc networks exist, a solution has been proposed that, built upon on a Mobile IPv6 proxy-based architecture, selects the optimal communication mode (direct in-vehicle, vehicle-tovehicle, and vehicle-to-roadside communication) and provides dynamic switching between vehicle-to-vehicle and vehicle-to-roadside communication mode during a communication session in case that more than one communication mode is simultaneously available. Currently there is ongoing research in the field of InVANETs for several scenarios. The main interest is in applications for traffic scenarios, mobile phone systems, sensor networks and future combat systems. Recent research has focused on topology related problems such as range optimization, routing mechanisms, or address systems, as well as security issues like traceability or encryption. In addition, there are very specific research interests such as the effects of directional antennas for InVANETs and minimal power consumption for sensor networks. Most of this research aims either at a general approach to wireless networks in a broad setting or focus on an extremely specific issue (Thangavelu, 2007). iMANET

6

Internet Based Mobile Ad-hoc Networks (iMANET) are ad-hoc networks that link mobile nodes and fixed Internet-gateway nodes. In such type of networks normal ad-hoc routing algorithms don't apply directly. It is an emerging technique that combines a wired network (e.g. Internet) and a mobile ad hoc network (MANET) for developing a ubiquitous communication infrastructure. However, iMANET has several limitations in fulfilling user's demands to access various kinds of information, including limited accessibility to the wired Internet, insufficient wireless bandwidth, and longer message latency due to multihop transmission (Lim et al., 2003). 2.1.4 Issues and challenges

Any application working in a MANET environment must deal with following issues and challenges: •

Salient Characteristics of the Wireless Network o Packet loss due to transmission errors o Variable capacity links o Frequent disconnections/partitions o Limited communication bandwidth o Other link characteristics

•

Limitations Imposed by Mobility o Dynamically changing topologies/routes o Lack of mobility awareness by system/applications

•

Limitations of Embedded Applications o Battery usage (energy) o More precious processing and memory resources

•

Limitations in Security o Limited physical security o Hard to detect volatile nodes o Lack of authorization facilities o Intrinsic mutual trust vulnerable to attacks o Security protocols for wired networks cannot work similarly on ad hoc networks

•

Lack of fixed infrastructure, need for self-organization at all layers of the protocol stack

2.2 Position information in MANET 2.2.1 Benefits of location awareness in wireless networks The current effort in mobile wireless network protocols is to make them perform better at a lower maintenance overhead. For that matter, a joint effort has been conducted 7

in order to better adapt the structures created by the protocols to the dynamic topology created by nodes mobility, yet still limiting the requirement to a resource demanding maintenance process. Unfortunately, the current mobile network protocols have not been created to understand and benefit from nodes mobility but have instead only been designed to react blindly to the effects of mobility on the network topology. They are notably unable to benefit from the knowledge of nodes mobility in order to optimize the structure with respect to the instantaneous or an expected future network topology. The knowledge of position information is one of the solutions to improve mobile network protocols and optimize their maintenance in order to make them more reactive with respect to the constraints created by nodes mobility on the network topology. The community working in this field became aware of the potential benefits from using position information in order to improve links stability, periodic maintenance, power consumption or even security. Position information is essential in use cases such as vehicular MANET where the geographic coordinates are directly used as well as wireless sensor networks where position information could be used to drastically improve the routing structure and optimizing the communication and energy consumption while avoiding usage of naïve flooding to find routes. In almost all of the cases all of the required nodes are equipped with global positioning systems (GPS) devices allowing the network to have a synchronized time as well position information (Haerri et al., 2008). 2.2.2 Connecting to GPS GPS is the most widely used tool to calculate a device’s physical location. GPS is a worldwide, satellite-based radio navigation system. The GPS system consists of 24 satellites in six orbital planes. The satellites transmit navigation messages periodically. Each navigation message contains the satellite’s orbit element, clock and status. After receiving the navigation messages, a GPS receiver can determine its position and roaming velocity. To determine the receiver’s longitude and latitude, at least three satellites are needed. One more satellite is required to determine the altitude. More satellites can increase the positioning accuracy. The positioning accuracy of GPS ranges in about a few tens of meters. GPS receivers can be used almost anywhere near the surface of the Earth. The GPS coordinates can be either added in the MANET packets or dedicated software for managing position information can be added to the necessary nodes. In addition to applying location information in different stages of routing, location-dependent applications and services are being developed to facilitate current trends and needs (Ilyas, 2002). 2.3 Visualization of MANET 2.3.1 Key requirements

8

Following functional requirements should be met when developing a visualization tool for MANET: 

Receive topology data of the nodes o Links between connected nodes o GPS data such as latitude and longitude coordinates o Relative position to the current area



Store complete history of topology data with respective time stamps o Snapshot of the topology o Tracking of the whole network or selected nodes o Movement of the whole network or selected nodes given a certain period of time



Receive map images of the current location o Satellite images from the internet o Previously stored custom map images



Display the network topology o Combine topology data with map images

In addition there are several non-functional requirements that should be taken into account: 

Smooth transition between displays of topology o Prevention of system failure in case of invalid data or complete absence of it



Handling erroneous data o GPS device irregularities o Rapid and often unpredictable changes in topology

2.3.2 Main components The system can be viewed as a collaboration of separate sub-components each responsible for distinct tasks: • • • •

Client interface for passing requests and responses o Displaying the topology generated by the system o Handling client requests and commands Component for handling location data (GPS data gateway) o Receiving coordinates from nodes o Adding timestamps to location data Database for storing historical data o Storing data for individual nodes and topologies for lookups Component for receiving and/or storing map images o Receiving satellite images from internet source o Handling custom map images if working in offline mode 9

•

Component for processing input and generating topology visualization o Processing and converting external input o Generating topology views for client view

GPS Location Data

Client Interface/View

Processing Unit/Server

Data Repository

Map Images

Figure 2.2. Broad architecture of the proposed MANET visualization system. 2.3.3 DUMBO Project Project DUMBO deploys mobile wireless network on an ad hoc basis for emergency conditions, such as after a natural disaster when a fixed network infrastructure is not available or had been destroyed. A mobile ad hoc network (MANET) consists of mobile nodes that automatically cooperate to support the exchange of information among the nodes through wireless medium. Since the MANET does not rely on fixed telecommunication infrastructure, the MANET is suitable for emergency situations and can be set up within a relatively short amount of time. Using lightweight portable mobile nodes, MANET coverage can stretch out and penetrate deep into areas not easily accessible by roads or into areas where telecommunication infrastructure has been destroyed. DUMBO allows streaming video, VoIP and short messages to be simultaneously transmitted from a number of mobile laptops to the central command center, or to the other rescuers at the same or different disaster sites. The DUMBO command center has a face

10

recognition module that identifies potential matches between unknown victims’ face photos taken from the field and a collection of known face images stored at the command center. In addition, sensors can be deployed to measure such environmental data as temperature and humidity. Data from the sensors can be sent to the command center that analyzes or passes it on to the other mobile nodes. The command center can flexibly be located either in the disaster areas or anywhere with Internet access (Kanchanasut et al., 2007). Project DUMBO is collaboration among three main research groups: AIT’s intERLab (Thailand), INRIA (France), and the WIDE Project (Japan). 2.3.4 GeoDraw Project The GeoDraw project establishes automated software for visualization of nodes in a mobile network on an ad hoc basis. The application was developed as a contribution to Digital Ubiquitous Mobile Broadband OLSR (DUMBO) project by Internet Education and Research Laboratory (intERLab) of Asian Institute of Technology. The system aims to enhance Mobile Ad-Hoc Network (MANET) for post-disaster management by providing physical locations of mobile users. The proposed solution will allow users to monitor the nodes, their movement and links between nodes. This application will lay groundwork necessary for a large-scale project needed for a complete node tracking system. The project aims to demonstrate the use of mobile ad hoc networks in an environment where fixed network infrastructure is not available, such as in the case of natural disaster. Deploying and setting up mobile wireless network on an ad hoc requires relatively short amount of time and is suitable for emergency situations. Using lightweight portable mobile, MANET coverage can stretch out and penetrate deep into areas not easily accessible by roads or into areas where telecommunication infrastructure has been destroyed. Lack or significant damage to infrastructure, such as absence of roads and landmarks creates a need for location-based information. Tracking rescuers with mobile laptops will not only provide command center with complete representation of the network with respect to actual site, the information can be used to enhance command center activities such as organizing, communicating and coordinating rescuers. Satellite, map and hybrid images of the area provided by Google can be combined with environmental data such as temperature and humidity giving enhanced information about the site. A critical component of any successful disaster rescue operations is time. Knowing the precise locations of landmarks, roads, building, emergency service resources and rescuers reduces that time. Global positioning system data serves as a facilitating technology in addressing this issue. Command center can create maps of the disaster areas for rescue and aid operations, as well as assess damage based on geographic information gathered from GPS-enabled rescuers. 2.3.5 Existing MANET visualization tools

11

Simulation is the research tool of choice for majority of the MANET community. Leading way to develop visualization tools and overcome MANET challenges is simulation. Some of them have been briefly described below. Ad-Hockey The developers of network simulators (NS-2) implemented a visualization tool, the Network Animator (NAM). NAM allows users to create TCL based NS-2 scripts through a graphical user interface as well as view NS-2 trace files in playback form. Cartesian coordinates have been added to NAM to playback NS-2 generated trace files for wireless simulations. However, the playback for wireless based scenarios is limited node movements and emitting a circular pattern to represent the node’s transmission signal. The concepts of links and queues are not supported in the NAM wireless animations, because NAM does not show the wireless links. The wireless extension to NS-2 initially included a visualization tool called adhockey. The Monarch Project that offered the extensions to NS-2 planned to have adhockey visualize NS-2 wireless trace files and provide a graphical environment to build wireless scenarios. The first release of ad-hockey was in 1997, and the final release was in 1998 [23]. These early versions produced the trace file visualization, but became incompatible with the NS-2 wireless trace format and with the TCL versions used in NS-2 in 1999 (Kurkowski et al., 2005). iNSpect Interactive NS-2 protocol and environment confirmation tool (iNSpect) allows the visualization and animation of NS-2 based wireless simulations. Because it can animate a mobile ad hoc network without executing NS-2 itself (by reading the mobility file, which is an input to NS-2), and because it can post-process successful NS-2 simulations (by reading the trace file, which is an output from NS-2), iNSpect is an agile tool that can be utilized with minimal overhead. iNSpect is available to other interested researchers (Kurkowski and Camp, 2006). FRANC The LSR laboratory of EPF Lausanne (CH) developed a Java based framework for Mobile Ad-hoc Networks called FRANC which can be run on nearly any device from desktop computers to PDA's (apart some restrictions, depending on the JVM that is being used). This framework is based on layer architecture and thus completely configurable with different functionalities. Its aim is to discover the network topology of a Mobile Ad-hoc Network consisting of clients running the FRANC layer stack. The discovered topology may then be represented by a graph, thus making it possible to quickly get an overview of the reachable nodes - and to answer the question whether the desired interlocutor is reachable or not (Thurnherr, 2003). TDFvisualizer The U.S. Army Research Laboratory (ARL) has been conducting research in mobile ad hoc networks (MANETs) with external researchers though the Collaborative Technology Alliances (CTA) program for several years. As ARL is building an emulated

12

MANET research test bed, the visualization and animation tools were developed to support this effort. The tools are used for visually inspecting, verifying, demonstrating, and reviewing a desired topology (Nguyen, 2006). An emulation of a MANET at ARL is accomplished by using a software tool called tsm to create logical topologies for an ordinary local area network. Executing the tsm tool requires the availability of an input topology definition file (or simply a tdf file). Each tdf file contains sequences of topology definitions expressed in the scenario definition language (SDL). The tsm tool and SDL were developed by Telcordia Technologies, Inc., a CTA research member. To display accurately the positions of each MANET node on a computer screen requires position location information, but the original SDL does not include any rules to specify a location for each node. Therefore, ARL has extended the SDL grammars to include a way to express position location information and created graphical software tools that can display the position of each MANET node on the screen as intended by topology designers. The tools include the TDFvisualizer tool and the TDFanimator tool. The latter is the successor of the former. The former is designed to visualize a fixed-sized MANET. The latter can deal with changing-sizes of a MANET, and it provides the user with a method for controlling the animation manually. The tools have played an essential role in the design and the verification of desired topologies required for the emulation of an ad hoc network at ARL and at Telcordia Technologies, Inc. The successful creation of the tools has enabled the design, visualization and animation of complex topologies for an emulated MANET. The employment of ARLdeveloped visualization tools at CTA laboratories attests to the usefulness of the tools and to the contribution of ARL. The tools provide MANET researchers with at least the following methods for visualizing and animating scenario definition files: • • • • • •

A method for verifying the accuracy of a topology scenario by visually inspecting a tdf file instead of reading through sequences of textual topology descriptions. A method for visually conducting dry-runs of an emulated topology. A method for inspecting large tdf files through visualization and animation. Without the visualization tools, manually tracking the changes of a dynamic topology would be an extremely time-consuming and difficult task. A method for graphically illustrating the behavioral complexity of a MANET to unfamiliar users for their education and training. A method for graphically demonstrating to actual and potential customers and supporters the capability of the test bed and the emulation of a MANET. The real impact of the visualization and animation tools on its users is the notable increases of their productivity and satisfaction. Using these tools, CTA researchers were, for the first time, able to systematically visualize and verify topology definition files quickly and reliably; therefore, they could save time and effort, reduce complexity, and avert errors.

2.3 Software Patterns

13

2.3.1 Introduction From a design perspective, software is often thought of in terms of its parts: functions, source files, modules, objects, methods, classes, packages, libraries, components, services, subsystems, and so on. These all represent valid views of the different kinds and scales of units of composition with which developers work directly. These views focus on the parts, however, and de-emphasize the broader relationships and the reasoning that make a design what it is. In contrast, patterns have become a popular and complementary way of describing and evolving software designs, capturing and naming proven and common techniques. They emphasize the why, where, and how of designs, not just the what (Buschmann et al, 2007). A pattern documents a recurring problem–solution pairing within a given context. A pattern, however, is more than either just the problem or just the solution structure: it includes both the problem and the solution, along with the rationale that binds them together. A problem is considered with respect to conflicting forces, detailing why the problem is a problem. A proposed solution is described in terms of its structure, and includes a clear presentation of the consequences—both benefits and liabilities—of applying the solution. The recurrence of patterns is important—hence the term pattern—as is the empirical support for their designation as patterns. Capturing the commonality that exists in designs found in different applications allows developers to take advantage of knowledge they already possess, applying familiar techniques in unfamiliar applications. Of course, by any other name this is simply ‘experience.’ What takes patterns beyond personal experience is that patterns are named and documented, intended for distilling, communicating, and sharing architectural knowledge. Patterns span several levels of abstraction, from high-level architectural patterns and medium-level design patterns to low-level idioms. •

Architectural Patterns An architectural pattern expresses a fundamental structural organization or schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them. o Relationship between subsystems

•

Design Patterns A design pattern provides a scheme for refining the subsystems or components of a software system, or the relationships between them. It describes commonly recurring structure of communicating components that solves a general design problem within a particular context. o Relationship between classes and objects

•

Idioms

14

An idiom is a low-level pattern specific to a programming language. An idiom describes how to implement particular aspects of components or the relationships between them using the features of the given language. o Language-specific model 2.3.2 Architectural pattern Architectural patterns are a key concept in the field of software architecture: they offer well-established solutions to architectural problems, help to document the architectural design decisions, facilitate communication between stakeholders through a common vocabulary, and describe the quality attributes of a software system as forces. Regrettably, finding and applying the appropriate architectural patterns in practice still remains largely ad-hoc and unsystematic. This is due to the lack of consensus in the community with respect to the “philosophy” and granularity of architectural patterns, as well as the lack of a coherent pattern language (Avgeriou and Zdun, 2005). Architectural patterns are software patterns that offer well-established solutions to architectural problems in software engineering. It gives description of the elements and relation type together with a set of constraints on how they may be used. An architectural pattern expresses a fundamental structural organization schema for a software system, which consists of subsystems, their responsibilities and interrelations. In comparison to design patterns, architectural patterns are larger in scale. Even though an architectural pattern conveys an image of a system, it is not architecture itself. An architectural pattern is rather a concept that captures essential elements of software architecture. Countless different architecture may implement the same pattern and thereby share the same characteristics. Furthermore, patterns are often defined as something strictly described and commonly available. For example, layered architecture is a call-and-return style, when it defines an overall style to interact. When it is strictly described and commonly available, it is a pattern. One of the most important aspects of architectural patterns is that they embody different quality attributes. For example, some patterns represent solutions to performance problems and others can be used successfully in high-availability systems. In the early design phase, a software architect makes a choice of which architectural pattern(s) best provide the system's desired qualities. 2.3.3 Examples of architectural patterns •

Layers The Layers pattern helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction.

•

Piper and Filters The Pipes and Filters pattern provides a structure for systems that process a stream of data. Each processing step is encapsulated in a filter component. Data is passed

15

through pipes between adjacent filters. Recombining filters allows you to build families of related systems. •

Blackboard The Blackboard pattern is useful for problems for which no deterministic solution strategies are known. In Blackboard several specialized subsystems assemble their knowledge to build a possibly partial or approximate solution.

•

Broker The Broker pattern can be used to structure distributed software systems with decoupled components that interact by remote service invocations. A broker component is responsible for coordinating communication, such as forwarding requests, as well as for transmitting results and exceptions.

•

Model-View-Controller The Model-View-Controller pattern (MVC) divides an interactive application into three components. The model contains the core functionality and data. Views display information to the user. Controllers handle user input. Views and controllers together comprise the user interface. A change-propagation mechanism ensures consistency between the user interface and the model.

•

Presentation-Abstraction-Control The Presentation-Abstraction-Control pattern (PAC) defines a structure for interactive software systems in the form of a hierarchy of cooperating agents. Every agent is responsible for a specific aspect of the application's functionality and consists of three components: presentation, abstraction, and control. This subdivision separates the human-computer interaction aspects of the agent from its functional core and its communication with other agents.

•

Microkernel The Microkernel pattern applies to software systems that must be able to adapt to changing system requirements. It separates a minimal functional core from extended functionality and customer-specific parts. The microkernel also serves as a socket for plugging in these extensions and coordinating their collaboration.

•

Reflection The Reflection pattern provides a mechanism for changing structure and behavior of software systems dynamically. It supports the modification of fundamental aspects, such as type structures and function call mechanisms. In this pattern, an application is split into two parts. A meta level provides information about selected system properties and makes the software self-aware. A base level includes the application logic. Its implementation builds on the meta level. Changes to information kept in the meta level affect subsequent base-level behavior.

2.3.4 Design pattern In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design

16

that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Algorithms are not thought of as design patterns, since they solve computational problems rather than design problems (Gamma et al., 1994). Not all software patterns are design patterns. Design patterns deal specifically with problems at the level of software design. Other kinds of patterns, such as architectural patterns defined above, describe problems and solutions that have alternative scopes. 2.3.5 Examples of design patterns •

Whole-Part The Whole-Part pattern helps with the aggregation of components that together form a semantic unit. An aggregate component, the Whole, encapsulates its constituent components, the Parts, organizes their collaboration, and provides a common interface to its functionality. Direct access to the Parts is not possible.

•

Master-Slave The Master-Slave pattern supports fault tolerance, parallel computation and computational accuracy. A master component distributes work to identical slave components and computes a final result from the results these slaves return.

•

Proxy The Proxy pattern makes the clients of a component communicate with a representative rather than to the component itself. Introducing such a placeholder can serve many purposes, including enhanced efficiency, easier access and protection from unauthorized access.

•

Command Processor The Command Processor pattern separates the request for a service from its execution. A command processor component manages requests as separate objects, schedules their execution, and provides additional services such as the storing of request objects for later undo.

•

View Handler The View Handler pattern helps to manage all views that a software system provides. A view handler component allows clients to open, manipulate and dispose of views. It also coordinates dependencies between views and organizes their update.

•

Forwarder-Receiver The Forwarder-Receiver pattern provides transparent inter-process communication for software systems with a peer-to-peer interaction model. It introduces forwarders and receivers to decouple peers from the underlying communication mechanisms.

•

Client-Dispatcher-Server

17

The Client-Dispatcher-Server pattern introduces an intermediate layer between clients and servers, the dispatcher component. It provides location transparency by means of a name service, and hides the details of the establishment of the communication connection between clients and servers. •

Publisher-Subscriber The Publisher-Subscriber pattern helps to keep the state of cooperating components synchronized. To achieve this it enables one-way propagation of changes: one publisher notifies any number of subscribers about changes to its state.

18

CHAPTER III ANALYSIS OF PATTERNS 3.1 Introduction Different architectural patterns lead not only to different high-level designs, but designs with significantly different properties and behavior. In this chapter we look at three different architectural patterns and how they affect the overall design of our visualization system. An early design decision will determine how the system is broken down into components and how the tasks and responsibilities are divided among those components. For each architectural pattern the background, its common applications and application scenario for the proposed system is described and comparatively analyzed. Fulfillment of functional requirements and specifications along with benefits and drawbacks of particular architectural patterns will be showcased. The analysis will be focused on raw GPS data processing manner. The data flow, processing units and system states are evaluated as part of our study. We will look in detail at the distribution of domain logic, interaction of system components, as well as implementation of application interface and system repository management. 3.1.1 Use Case model

Visualization System

Manage Map

Manage Nodes Administrator

User Search History

Manage Content

Figure 3.1 Use Case model of the visualization system. 19

Use Case Name: Manage Map ID: 1 Importance Level: High Primary Actor: User Use Case Type: Essential Stakeholders and Interests: User – wants to change the view of the map Brief Description: This use case describes how to manage a map. Trigger: User accesses the visualization system to view the topology map. Type: Internal Relationships: Association: User Include: Exclude: Generalization: Normal Flow of Events: 1. User accesses the visualization system. 2. User changes the view of the map by selecting the appropriate type (satellite, map and hybrid). Sub Flows: Alternate/Exceptional Flows: Table 3.1 Manage Map use case description. Use Case Name: Manage Nodes ID: 2 Importance Level: High Primary Actor: User Use Case Type: Essential Stakeholders and Interests: User – wants to change the nodes to be viewed on the map Brief Description: This use case describes how to manage nodes. Trigger: User accesses the visualization system to view the topology map. Type: Internal Relationships: Association: User Include: Exclude: Generalization: Normal Flow of Events: 3. User accesses the visualization system. 4. User changes the nodes to be viewed on the map by selecting the specific subset of nodes of the topology. Sub Flows: Alternate/Exceptional Flows: Table 3.2 Manage Nodes use case description.

20

Use Case Name: Search History ID: 3 Importance Level: High Primary Actor: User Use Case Type: Essential Stakeholders and Interests: User – wants to change the view the historical data stored in the application. Brief Description: This use case describes how to search the history. Trigger: User accesses the visualization system to view the topology map. Type: Internal Relationships: Association: User Include: Exclude: Generalization: Normal Flow of Events: 5. User accesses the visualization system. 6. User selects the specific time frame period and subset of nodes to view the previous position and movement of nodes. Sub Flows: Alternate/Exceptional Flows: Table 3.3 Search History use case description. Use Case Name: Manage Content ID: 4 Importance Level: High Primary Actor: Administrator Use Case Type: Essential Stakeholders and Interests: Administrator – wants to change content of the application Brief Description: This use case describes how to manage the content of the application. Trigger: Administrator accesses the visualization system to view and manage the content. Type: Internal Relationships: Association: Administrator Include: Exclude: Generalization: Normal Flow of Events: 7. Administrator accesses the visualization system. 8. Administrator edits the historical data received and stored from the nodes. Sub Flows: Alternate/Exceptional Flows: Table 3.4 Manage Content use case description. 3.1.2 System Data The proposed visualization system is data-centric as the data received from nodes is processed to generate the topology view and stored in the system repository. Considering the nature of mobile ad hoc network nodes, time is a crucial component of our data. The system will process two types of records, a single node and a link. The node record represents the current geographic location along with identification information. The link record is generated when neighboring nodes establish a connection.

21

Node Link Type, Latitude, Longitude, Timestamp> Table 3.5 System data entry properties. By including the timestamp in our records the system is able to track the movement of nodes with regard to time. The snapshot of the topology will consist of geographic location of all nodes and the links between connected nodes at a specific point in time.

22

3.2 Pipes and Filters Pattern 3.2.1 Background The Pipes and Filters architectural pattern provides a structure for systems, having components that process a stream of data (filters) and connections that transmit data between adjacent components (pipes). This architecture provides reusability, maintainability, and decoupling for the system processes having distinct, easily identifiable, and independent but somehow compatible tasks. The usage of Pipes and Filters pattern is limited to systems where the order in which filters are processed is strongly determined and sequential in nature. The pattern applies to problems where it is natural to decompose the computation into a collection of semi-independent tasks. In the Pipeline pattern, the semi-independent tasks represent the stages of the pipeline, the structure of the pipeline is static, and the interaction between successive stages is regular and loosely synchronous. A pipeline is a definition of steps/tasks that are executed to perform a business function. Each step may involve reading or writing to data confirming the pipeline state, and may or may not access an external service. When invoking an asynchronous service as part of a step, a pipeline can wait until a response is returned (if a response is expected), or proceed to the next step in the pipeline if the response is not required in order to continue processing (Buschmann et al., 1996).

Figure 3.2 Pipes and Filters Pattern scenario (Modified from Buschmann et al., 1996) Use the pipeline pattern when: • •

You can specify the sequence of a known/determined set of steps. You do not need to wait for an asynchronous response from each step.

23

•

You want all downstream components to be able to inspect and act on data that comes from upstream (but not vice versa).

Advantages of the pipeline pattern include: • •

It enforces sequential processing. It is easy to wrap it in an atomic transaction.

Disadvantages of the pipeline pattern include: • •

The pattern may be too simplistic to cover all cases in business logic, especially for service orchestration in which you need to branch the execution of the business logic in complex ways. It does not handle conditional constructs, loops, and other flow control logic as it's mostly sequential in nature (Buschmann et al., 1996).

3.2.2 Applications of pipeline architecture Pipeline architecture is suitable for applications requiring sequential processing. One such family of applications is lexical analyzer. A lexical analyzer takes the source character stream and produces a stream of tokens. The system can be viewed a pipeline of translators. Each translator reads a series of input objects and produces another series of objects for the next translator. Translator in a lexical analyzer can be viewed as filter. The filter consumes input objects, modifies their values and attributes or extracts the necessary information and passes the data the next filter through the pipe. Each translator is a series of pattern-action rules, if the pattern of a rule matches the translator’s input, the action of that rule is executed to produce the output. 3.2.3 Pipeline architecture and MANET visualization Visualizing the network topology of a MANET from location information collected from networks is a complex task. Despite the complexity of this multipart task, the individual units of processing are distinct, easily identifiable and divisible. Most importantly these adjacent subtasks are independent. The pipes and filters pattern provides a structure for systems where order in which data is processed is strongly determined and sequential in nature. Our proposed system can be viewed as processing of geographic location data through several steps in order to produce the final topology view. The name pipeline comes from a rough analogy with physical plumbing in that a pipeline usually allows information to flow in only one direction, like water often flows in a pipe. The other natural concept in everyday life would be an assembly line. Assembly line does not decrease the time for a single batch of data to be processed. It increases the throughput of the system when processing a constant stream of input data. In our particular case the assembly line is the processing component of the command center, with raw node data coming in from one side and network topology view being generated at the other. Sequential processing has been adopted in the implementation of GeoDraw system. The data received from the nodes includes, but is not limited to, geographic coordinates 24

with timestamps from the GPS receiver, links to neighboring connected nodes and node identification data such as IP or any other designated naming. It is necessary to take apart the raw data and process the elements in a specific order. One possible sequence could be receiving the data, converting and extracting necessary information, placing nodes on the map, drawing links between connected nodes, storing the readable data to the repository for future playback. Displaying the movement of nodes would add another stage in the sequence, extracting relevant historical information from the repository. While this architectural pattern enforces sequential processing and provides decoupling for system processes the nature of our problem prevents us from fully taking advantage of its main benefit, parallelism. The processing and generation of the final result is only possible when information is gathered from all nodes and processed in a single batch. This form of pipes and filters is known as the pseudo-pipeline. Pseudo-pipelines act like true pipes with a pipe buffer of unlimited size, disk space and memory limitations notwithstanding. The significant restriction is that a receiving process could not read any data from the pipe buffer until the sending process finished completely. Since the data is processed in batches and at every stage the destination process waits for the source process to complete the batch buffering is essential for our system. Buffering is combined with a request acknowledge routine, where in each stage can detect when it is finished. Two neighboring stages exchange request and acknowledge messages to pass the processed data from one stage to the next one.

Raw Data

GPS Data Receiver Filter

Pipe

Raw Data Processor (Node/Link Extractor)

Pipe

Filter

Topology Map Generator

Pipe

Data Management Unit

Filter

Figure 3.3 MANET visualization process implementation as a pipeline. Processing of raw data in batches prevents us from utilizing parallelism in the pipes and filters application. The batch of data is passed from one filter to another in a sequential manner. Each filter performs the necessary operation on the data and sends it to the next filter via the adjacent pipe.

25

Pipe

GPS Data Receiver

Raw Data Processor

Pipe

Pipe

Topology Generator

Raw Data Raw Data Batch Data

Raw Data

Batch Data

Raw Data

Nodes & Links

Batch Data Batch Data

Nodes & Links Topology Map

Nodes & Links Nodes & Links Topology Map

Figure 3.4 Pipeline implementation of the proposed visualization system displaying the sequential nature of the model. The pipeline model for our system will increase the throughput our system since the filters will be executing independent instructions and processing data in parallel. Each batch of data will generate a topology map, a snapshot of the nodes with a particular timestamp. Each batch is then inserted into the data repository. Issues to consider: •

When developing the proposed application using the pipes and filters architectural pattern there must be a method for temporarily suspending the topology generator filter from the processing sequence. When a user requests to view historical data, the nodes and links information is retrieved from the repository and the topology map needs to be generated using that data. In other words the system has to use the topology generator unit outside of the raw data processing sequence. Otherwise

26

building another component with exact same functionalities would create unnecessary duplication. •

While the pipeline model is designed to increase the throughput by allowing independent processing of filters, the processing load is solely dependant on the data input. In our case, when tracking movement of nodes, requesting and processing location information every second is not very practical. Even though GPS devices provide update range of 1 second refresh rate, especially considering the fact that we are tracking rescuers in a disaster environment, the emphasis is on the exact current location of the rescuers rather than continuous flow of GPS data. During our experiments and initial testing we found that refresh rates of below 10 seconds is not practical. If the pipeline receives a batch of raw data periodically it will remain idle in between the incoming batches.

Raw data sent from nodes is processed sequentially and transmitted between adjacent components as a batch. As an example, let’s take a look at states and transformations data goes through in GeoDraw: 1. Raw data received from nodes: Location [198.162.39.22, 98.2962, 7.8362, 2, 100144];Location [198.162.39.33, 98.2973, 7.8293, 2, 100144];Location [198.162.39.44, 98.2904, 7.8384, 2, 100144];Location [198.162.39.55, 98.2915, 7.8315, 2, 100144];Link [198.162.39.11, 198.162.39.22];Link [198.162.39.11, 198.162.39.33];Link [198.162.39.11, 198.162.39.44];Link [198.162.39.11, 198.162.39.55];

Figure 3.5 GeoDraw raw data. 2. Necessary data is extracted and broken down into separate elements

27

Location Name/IP: 198.162.39.22 Latitude: 98.2962 Longitude: 7.8362 Type: 1 (EEE PC) Timestamp: 100144 Location Name/IP: 198.162.39.33 Latitude: 98.2973 Longitude: 7.8293 Type: 2 (Micro Client) Timestamp: 100144 Link 198.162.39.11 198.162.39.22 Link 198.162.39.11 198.162.39.33

Figure 3.6 GeoDraw data elements. 3. The nodes and links representing connected nodes are drawn on the map.

Figure 3.7 GeoDraw screenshot. 4. The data is stored in XML format for future playback.

28

Figure 3.8 GeoDraw XML file. 3.2.4 Summary Pipes and filters pattern is the primary candidate when developing our proposed system. Not only it provides a base structure for processing components, the pipeline model is the relatively less complex to implement given the straightforward nature of the problem. Applying the pipes and filter model to our application resulted in simple sequential processing of data without clearly taking advantages of the architectural pattern. The filters described as components of the system resemble steps in a single processing unit. One prominent advantage is standardization of data structures in the application. Processing of input data is the central issue in the visualization system. As the GPS location data is processed between different stages the data goes through transformations, with each processing unit having a standard format. Standard format for data stream allows the individual processing filters to be developed independently. In addition, it becomes possible to connect filters in different combinations and process the data stream in different ways if necessary thus increasing the long-term usefulness of processing units. However, the pipeline architecture mainly deals with the processing of GPS data to map parameters. The raw GPS location data is converted to map marker points and connecting lines and stored in the application repository. There are no distinctive characteristics for individual nodes like the blackboard model, or graphical user interface side of the application similar to the presentation layer in the layers architecture.

29

3.3 Layers 3.3.1 Background Layers is an architectural design pattern that structures applications so they can be decomposed into groups of subtasks such that each group of subtasks is at a particular level of abstraction (Buschmann et al., 1996).

Figure 3.9 Simple layer pattern architecture scenario (Modified from Buschmann et al., 1996) Advantages • • • • •

A layered pattern supports increasing levels of abstraction, thus simplifying design This allows a complex problem to be partitioned into a sequence of manageable incremental strategies (as layers) Like Pipes and Filters, layers are loosely coupled, so maintenance is enhanced because new layers can be added affecting only two existing components (as layers) Layers support plug-and-play designs. As long as the interfaces do not change, one layer can be substituted for another changing the behavior of the layer system Lowest Common Denominator issues of Pipes and Filters is not present in Layers

Disadvantages • • •

Close coupling of juxtaposed layers lowers maintainability Each layer must manage all data marshaling and buffering Lower runtime efficiency (Buschmann et al., 1996)

3.3.2 Applications of layer architecture Decomposing an application into groups of subtasks responsible for a particular level of abstraction is achieved through layered architecture. Besides the traditional 3-layer

30

client-server architectures consisting of presentation, logic and data layers, Open Systems Interconnection Reference Model or OSI Model is one example of layered architecture. OSI model is an abstract description for layered communications and computer network protocol design. In its most basic form, the model divides the network architecture into seven layers, one on top of each other: •

Application - Provides services to user. Examples include telnet, TCP, HTTP.

•

Presentation - Structures information and attaches semantics.

•

Session - Provides dialog control and synchronization facilities.

•

Transport - Responsible for segmenting long messages into packets. Recovers lost packets with acknowledgments and retransmissions. Flow control. Congestion control. Breaks messages into packets and guarantees delivery.

•

Network - Responsible for routing packets from source to destination host. Selects a route from sender to receiver.

•

Data Link - Responsible for moving packet from one node (host or packet switch) to next node. Error detection and correction. Medium access.

•

Physical - The physical layer, the lowest layer in the OSI stack, is responsible for moving information between two systems connected by a single physical link. The physical layer provides the abstraction of bit transport, independent of the link technology. Specifies voltage levels, bit spacings.

The OSI model is a great example of layered architecture because it displays the general types of services required for machines to talk to each other. While each layer provides services to the layer above two instances of one layer communicate horizontally. 3.3.3 Layers and MANET visualization MANET visualization system contains both significant presentation and domain components. A popular approach is to factoring the application classes into layers. Layering architecture is not only simple it can have many beneficial effects if applied in the proper way. Our proposed system can be decomposed into group of subtasks such that each group of subtasks is at particular level of abstraction. The pattern breaks down the application into three major areas of functionality. The presentation or user interface layer, the business layer responsible for domain logic and the data layer for managing physical storage and retrieval of data. This approach gives a clearer separation of concerns, which is always preferred. Segmentation of high-level from low-level issues allows breaking down a complex problem into smaller more manageable pieces. Since specification of a layer says nothing about its implementation, the implementation details of a layer hidden from other layers.

31

User

User Interface Components

Domain Logic Components Raw Data Manager

GPS Data Processing Unit

Topology Generator

Data Access Components

GPS Location Information

Data Repository

Figure 3.10 Proposed system architecture following the layers pattern. The following architecture clearly distinguishes the responsibilities and data flow in the proposed system implementation: •

User Interface o Presentation of the application to the user o Displaying the final result of the domain logic generated topology view o Receiving user input  Type of view (satellite, map or hybrid) selection  Selection of nodes to be viewed  Selection of time frame for historical view

•

Domain Logic o Processing location information to generate topology o Processing user input and communicating with data access layer

•

Data Access o Receiving GPS location information data o Receiving and storing processed topology data o Retrieving historical data from the repository

32

Issues to consider: •

The technology, platform and programming language to be more specific, used to implement our system will play a critical role in client logic distribution of the application. PHP and ASP dynamic web pages are generated by the web server and sent to the client. On the other hand pages enhanced with client-side scripts such as JavaScript or VBScript enable the user to change the content depending on the input. User requests and instructions can be followed and executed without further communication with the server (Kyrnin, 2009).

•

Manipulation of maps through different application programming interfaces to access map and satellite images such as Google Maps will depend on particular API employed by the developers.

Layering allows re-usage of functionality as well as sharing services of lower layers to numerous upper layers. For example, the location information from the nodes can be retrieved from a text file or received via socket. Instead of complete overhaul, an additional external interface layer can be developed to accommodate new external interface where lower business logic layer is unaware and unchanged. This type of plug and play design provides flexibility, reuse and scalability. In MANET visualization system presentation layer will be directly connected with user for getting user data and then passing it to the business logic layer for further procedure. User manipulation can change the current view to display the network topology map in different modes such as satellite or hybrid. Commands to select nodes to be displayed and historical playback intervals will also be retrieved via the presentation layer. Business logic layer would represent the central processing unit working as a bridge between presentation layer and data. All the user values received from the user and results from data are converted and processed according to the business logic and rules of the application. Processing of geographic location data into nodes and links, in other words, adding the logic to data is carried out in business logic layer. Data access layer acts upon queries and parameters received from the business logic layer. Geographic coordinates and link information gathered from nodes is stored in the repository via data access layer. GeoDraw uses an XML file to store historical data for future playback. While implementing layers architectural model it is important to avoid coupling of adjacent layers. Close coupling layers lower maintainability and shared responsibility of a certain function can lead to other quality attributes such as portability. In addition, confusion between logical abstraction layers and physical tiers can cause faulty levels of indirection and decreased performance. In case of MANET visualization, a web implementation of the system would split the presentation layer to both client and server tiers. 3.3.4 Summary Since our proposed application for displaying MANET topology from GPS location data is still in its early stages, many changes can be foreseen before it becomes a comprehensive system. Layers pattern enforces standardization of tasks and interfaces which in turn allows developers to change, reuse and add layers over time. 33

Layering clearly separates the database from the interface and application logic. The presentation layer will handle the interaction between the user the topology map. Data source layer will be responsible for getting and sending GPS location data. And finally the domain logic layer will be responsible for processing and validating the GPS data to generate the topology view. If the proposed system is developed as a web application, like GeoDraw, all layers will run server-side. It is possible to move some of the presentation logic to the client to increase responsiveness. For example, Ajax-style graphical user interface can enable the user to manipulate the playback of node movements without reloading the map image from the server (Kyrnin, 2009).

34

3.4 Blackboard 3.4.1 Background The idea behind the Blackboard architecture is a collection of independent programs that work cooperatively on a common data structure. Each program is specialized for solving a particular part of the overall task, and all programs work together on the solution. These specialized programs are independent of each other. They do not call each other, nor is there a predetermined sequence for their activation. Instead, the direction taken by the system is mainly determined by the current state of progress. A central control component evaluates the current state of processing and coordinates the specialized programs. This data-directed control regime makes experimentation with different algorithms possible, and allows experimentally-derived heuristics to control processing (Buschmann et al., 1996).

Figure 3.11 Blackboard pattern architecture scenario (Modified from Buschmann et al., 1996) Advantages • •

Efficiency by parallel processing Flexibility by recombination makes exchanging product families easy

Disadvantages • • • • • •

Different sources of input data exist (i.e., network connection or hardware sensor) Need many algorithms with variation Need to synchronize the state of cooperating components The number and identities of the cooperating components is not known, nor static There is more than one object that may handle a request Can be expensive on system resources if large volume of data (Buschmann et al., 1996) 35

3.4.2 Applications of blackboard architecture There are many applications of blackboard architecture in software systems. Any system based on multiple cooperating knowledge sources contributing to a single associate memory can be implemented using the blackboard model. Examples of blackboard architecture include Hearsay, a speech recognition system, cryptanalysis, threat assessment and curriculum design (Bahill, 2002). Let’s take a closer look at the threat assessment system. The knowledge sources or agents in this case are multiple sensors and detectors cooperating to gather military intelligence: • • • • • • • •

Synthetic aperture radar (SAR) Infrared (IR) detectors Identification friend or foe systems (IFF) Global positioning satellites (GPS) Electro-optical (EO) sensors Communications intelligence (COMIT) Electronic intelligence (ELINT) Moving target indicators (MTI)

Each of the agents would contain an identifier, a type value with certain factor holding the state estimate and error bounds. If a sensor detects a certain value thus raising the flag a sequence of events takes place. The sequence of events or scenarios trigger preplanned activities for the rest of the system agents. 3.4.3 Blackboard architecture and MANET visualization Blackboard architectural model is one of the more suitable candidates for implementing a MANET visualization application. In a blackboard system, a set modules share a common global database called the blackboard and work together to solve a problem. Each independent module, also known as the knowledge source, updates the blackboard with a partial solution when its internal settings and constraints match the blackboard state. This idea of collection of independent programs working cooperatively on a common data structure to solve an overall task can be applied directly to our purpose. Network nodes can be viewed as knowledge sources, each of them contributing to the central control component generating the network topology view. In a conventional knowledge base system, diverse group of specialist knowledge sources iteratively update the blackboard with a partial solution. Ability to support interaction and cooperation among diverse contributors providing specific expertise is one of the main advantages of this architectural pattern. However, in this particular case of blackboard system implementation, problem solving modules residing on nodes are identical. The format, structure and content of the knowledge, as well as the technology and behavior of the knowledge sources would be identical on all nodes of the network except the central control component residing on the command center node. The central

36

control component would be responsible for evaluating the current state of processing and coordinates the specialized programs and their contribution to the blackboard. Relegating the responsibility of gathering GPS data and sending the location information to individual nodes prevents loss of data and generation of incomplete topology view in case the node is temporarily disconnected from the network and unable to send its data to the command center. The node can store its location information while the GPS receiver keeps collecting new coordinates along with timestamps. Once the connection is re-established the data missing at the command center is received from the unstable node allowing the system to recreate the view of the topology. As mentioned above identical nature of knowledge sources takes away the main advantage of the blackboard architecture. The contribution of the nodes does not depend on the state of the blackboard and other nodes. There is no hierarchy among nodes. Blackboard acts as a very general communications facility and synchronization of the state of cooperating components is needed to function properly. On the other hand, this architecture still supports cooperation of knowledge sources. Partial solution and progress to final complete solution exists through late arrival of necessary data. Since identity of cooperating nodes and input data is known to the central control component combining and processing the knowledge will not be difficult as long as the system is able to handle growing amounts of data.

Knowledge Source

Blackboard

Control Component

Knowledge Source

Knowledge Source

Figure 3.12 Basic components of the Blackboard model. Knowledge sources can be viewed as intelligent agents with its own knowledge and information base. Each knowledge source acts in parallel with other sources and cooperates to achieve a common set of goals. In a dynamic environment, intelligent knowledge sources must be responsive to unanticipated conditions. When such conditions occur, a source may have to stop a previously planned and scheduled course of actions and

37

re-plan, reschedule, start new activities and initiate a new problem solving process to successfully respond to new conditions. Node A (Knowledge Source)

Topology Map (Blackboard)

Central Processor (Control Component)

Node B (Knowledge Source)

Node C (Knowledge Source)

Figure 3.13 Blackboard model with nodes acting as independent knowledge sources. In a blackboard model with nodes acting as independent knowledge sources, or intelligent agents, each node is responsible for gathering, storing and sending GPS data to the blackboard. An unanticipated condition could be a sudden loss of connection to the network. If the node is unable to send the GPS to the shared blackboard located at the command center node, it is responsible for storing the gathered GPS data until the connection is restored. Once the connection is restored the node can send the stored data and clear the buffer if necessary. In this scenario the direction taken by the system is determined by a single factor. Whereas in comprehensive blackboard system the knowledge sources cooperate their actions based on the current state of the system, our implementation would require only two states, active and inactive. Connected nodes would have to check if the blackboard is in active receiving mode to send GPS data.

38

Raw Data Processor

Topology Map (Blackboard)

Central Processor (Control Component)

Node/Link Drawing Component

Data Management Unit Figure 3.14 Blackboard model with independent processing units for each task. In the previous model intelligent agents were geographically distributed with each network acting as a knowledge source. MANET visualization process can be broken down into simple processing elements operating on a single computer. This is a relatively conventional implementation of the blackboard model where each knowledge source changes the blackboard data to incrementally generate the final solution. The solution is built one step at a time, in a sequential manner. Each knowledge source would perform its execution on the blackboard data and notify the next component by changing the blackboard state. However, this particular architecture is similar to pipes-and-filters system which is already described in detail in this paper. 3.4.4 Summary While the blackboard architectural pattern provides us one clear benefit of independent nodes acting as knowledge sources and distribution of some of the application logic the model generates more problems than it solves. The blackboard pattern is mostly used when there is no deterministic or optimal solution known for problem with the immature or poorly specified domain. The data format, data flow and system states are clearly identified in our case and there is no clear need for partial solution. In blackboard model all of the knowledge sources contribute to generate the final solution by communicating through the blackboard and reading the current partial solution. However in our case the nodes are not required to communicate or read the current partial solution. Sending its current GPS location information along with links indicating connected nodes are sufficient for the generation of the topology view.

39

CHAPTER IV RESULTS AND DISCUSSION 4.1 Factors to consider in system development In this research paper the emphasis is on geographic location, how the system enables monitoring of location and movement of objects that can transmit their geographic location via GPS or similar technologies. There are certain similarities as well as major differences between the proposed visualization system and logistics tracking systems in general. Let us take a look at the features which reside in both cases, starting with GPS. Vehicle tracking is one of the fastest-growing GPS applications. GPS equipped vehicles, public transportation systems, delivery trucks, and courier services use receivers to monitor their locations at all times. Not only can vehicle tracking help improve efficiencies and productivity in mobile businesses, but they can also help overcome common problems such as getting lost and vehicle theft. Monitoring location of nodes in a network via GPS provides the same benefits and possibilities. Knowing the location of workforce at all times can facilitate communication. Time will not be wasted simply finding out where workers are, because their location is displayed onscreen. Lost workers will be able to get immediate directions from the command center. Customers and victims have decreased wait time for services. Communication is the main reason behind building tracking systems (Brickhouse Security, 2009). Tracking and communication enables the users to react to rapid and unexpected events. In commercial systems, if a customer calls in for an unscheduled stop, you can locate, contact and route the nearest vehicle to their location in order to accommodate them. In an emergency situation, command center can contact, organize and coordinate workers to their location. However, here is where the major differences can be seen. Commercial logistics tracking systems mostly rely on schedule and predictability. The system is targeted at improving a certain supply chain. If a certain job or route is taking less time than is scheduled for them, routing can be altered to fit more jobs into a given workday, which will satisfy more customers and increase productivity. For example, customers want to know when to expect a delivery. Through tracking and communication the users can improve the current business process. Whereas, in emergency situation the importance is placed on the current events and actions of the emergency workers since there is not predictable or set time and everything has to be done as soon as possible. One case to illustrate this point would be movement of emergency workers in a disaster-stricken area, where they have to adapt to location and take different routes if roads are destroyed. Whereas, if a vehicle with shipment moves out of its service area the dispatcher would be alerted of the violation of schedule.

40

4.2 Interaction between nodes In the previous section the tracking of objects has been compared in context of a complete system. What truly sets apart the proposed MANET visualization system from logistics tracking systems in general is interaction of nodes. The links between connected nodes is as important as the locations of the nodes being tracked. Only when locations of individual nodes are combined with the information of connected nodes the system will display the complete topology of the network. Each node senses the presence of neighboring nodes, thus self-organizing and adapting to the environment and other external changes.

Figure 4.1. Shipping company’s logistics tracking system would only be concerned with the current location of the vehicles equipped with GPS devices.

41

Figure 4.2. Displaying the topology of a MANET requires not only geographic location of the nodes. The links between connected nodes needs to be shown also. 4.3 Software specifications and requirements Feature/Pattern Location data receiving

Pipes and Filter Raw data sent to the command center and transferred to the initial filter of the pipeline

Location data processing

Raw data is processed by number of pipes and filters with a specific data format structure

Storing location data

A specific pipe will send the data and store it to database The last filter of the pipeline can prepare the ready to store data

Layers The data is received by the system through the external input interface Also can be handled by the data source layer for receiving raw data Business logic layer is responsible for processing and validating the raw data from nodes Data source layer is responsible for storing and extracting necessary historical data for playback

Table 4.1 Distribution of tasks for each architectural pattern.

42

Blackboard Each node is responsible for collecting and sending its location data to the common blackboard map The control component residing at the command center will coordinate and process raw data coming from knowledge sources As the knowledge sources contribute to the blackboard the control component will have to store the data once its written to the blackboard

CHAPTER V CONCLUSIONS AND RECOMMENDATIONS 5.1 Architectural decision Generally, architectural decisions are conscious design decisions that may concern the software system as a whole, or one or more core components. Architectural decisions are significant because they may directly or indirectly determine whether a system meets its nonfunctional requirements, such as software quality attributes. The scope of architectural decisions varies. Many architectural decisions are specific to a particular view, such as the architectural decision to assign a certain functional responsibility to a logical component. Others serve as glue between different views. There are benefits to considering decisions related to the relationship between views. Selecting an overall logical layering scheme for a system under construction qualifies as an architectural decision First and foremost, layering is an architectural pattern. Selecting the layers pattern is an architectural decision driven by the desire for organization and flexibility; components in a particular layer should talk only to one another and to lower layers. Interfaces that encapsulate and hide implementation details isolate the components in different layers from one another as much as possible. If the pattern is applied, layer implementations can seamlessly switch from one technology to another, and there is no need to rewrite the elements contained within one of the adjacent layers. 5.2 Suitable pattern Finding and applying architectural patterns in practice still remains largely ad-hoc and unsystematic. First, it is important to be able to recognize common paradigms so that high-level relationships among components can be understood and so that new systems can be built as variations on old systems. From there developer can select and combine different architecture styles and patterns to suit the given problem. A comprehensive large system requires decomposition. One way to decompose a system is to segment it into collaborating objects. In large systems a first-cut rough model might produce hundreds or thousands of potential objects. Additional refactoring typically leads to object groupings that provide related types of services. When these groups are properly segmented, and their interfaces consolidated, the result is a layered architecture. Layering allows segmentation of high-level issues from low-level issues. Complex problems can be broken into smaller more manageable pieces. Each layer is responsible for exposing a principal service, and layers are typically divided based on their primary functional responsibilities. Packages are an excellent way to represent the logical layers composing an application. Higher-level layers (or a package representing a layer) sit atop lower-level layers, using their services. Lower-level layers, however, know nothing of the higher-level layers that use them. Furthermore, each layer usually hides its lower layers

43

from the layers above, though the transparency of individual layers must be a conscious decision. Defining meaningful application layers is important because well-defined layers promote maintainability and reusability, which is central to software architecture. When layering an application, consciously defining the coupling between layers is paramount. Subsequently, designing package relationships is vital. Additionally, because higher-level layers should use the services provided by lower-level layers, but not vice versa, package relationships should be unidirectional. Taking into account the need for straightforward and uncomplicated system which will be processing specific input at a constant rate in real time the most suitable architectural pattern would be the layers pattern. However, with the business layer itself processing data in pipes and filters fashion. Presentation layer would be responsible for display of application user interface components and handling user requests. This includes the final image of display generated by the system and necessary controls for manipulating the current view and history of the movement. On the other hand, domain logic layer encapsulates the business logic rules of the system. Processing of raw data and incorporating it with map images to generate the topology is carried out within this layer. Finally, the data access layer is responsible for storing and retrieving system data, such as previous locations of nodes and connections. 5.3 Layering alternatives Selecting an overall logical layering scheme for a system under construction qualifies as an architectural decision. Selecting the layers pattern is an architectural decision driven by the desire for organization and flexibility; components in a particular layer should talk only to one another and to lower layers. Interfaces that encapsulate and hide implementation details isolate the components in different layers from one another as much as possible. If the pattern is applied, layer implementations can seamlessly switch from one technology to another, and there is no need to rewrite the elements contained within one of the adjacent layers. When developing enterprise applications, some of the layering alternatives are: •

Single layer o All logic in the application is kept together. Logical components are not assigned to any particular layer.

•

Presentation domain data source layering o This layering encompasses the traditional three display, processing, and persistence layers used in logical enterprise application design. o The presentation layer contains all rich or thin client logic for displaying user interfaces to human users. Components in this layer may belong to both the client and the server tier in a physically distributed system, for instance a Web browser and Java servlets. o The domain layer contains business logic, which is activated in response to stimuli from the presentation layer. Examples are executable business processes, calculations, and modifications of business objects. 44

o The data source layer makes enterprise data, such as customer profiles and order information, persist. It also provides interfaces that let the domain layer access this data when executing its logic. •

Enterprise Service-Oriented Architecture layering o The following four layers were defined by Dirk Krafzig in Enterprise Service-Oriented Architecture: o The enterprise layer contains application front ends and public enterprise services. o The process layer defines long-running, multi-step, multi-actor business processes, such as order management or load processing, which are composed of basic services and make use of intermediary services. o The intermediary layer provides integration capabilities and other technical capabilities, such as authentication, authorization, and logging. o The basic layer encompasses business services that are discrete, atomic units of work, each corresponding to a certain business task (activity) to be invoked as part of a process (or directly from the enterprise layer). Examples include customer address lookup and validation, profile updates, and risk calculations. Proxies for externally provided public enterprise services also reside on this layer.

•

SOA solution stack layering o This layering with resource, service component, service, process, consumer, integration, quality of service (QoS), information, and governance layers was first defined by Ali Arsanjani in “Service modeling and architecture” and then extended by the SOA solutions stack (S3) project. This layering scheme is not as strict as the previous two. It places integration and QoS capabilities, which may be provided by middleware, into vertical layers. By default, the vertical layers are visible to all other layers. This softens the strict hierarchy in the original layering pattern. Such a semi-strict layering scheme is easier to adhere to. However, additional architectural principles must be established to govern which interactions between layers are permitted.

The logical layering-scheme decision pertains to the logical viewpoint. Any of the alternatives here suggest a different way of organizing the top-level components in a logical view in a strict or semi-strict hierarchy. There are many trade-offs. For instance, introducing too few layers carries the risk of violating the separation of concerns principle because coupling many components in a layer rather tightly has a negative impact on quality attributes such as maintainability and portability. However, if you introduce many layers, you must be careful not to introduce too many levels of indirections, which when projected to the physical viewpoint, might decrease performance (Zimmermann et al., 2008). It's important not to confuse the logical and physical viewpoints in this discussion. Logical layering does not imply physical distribution. Introducing many physical layers (often called tiers) might be an issue, depending on the non functional requirements for the system under construction. Fowler’s First Law of Distributed Object Design states "Don’t distribute your objects!"

45

Presentation Layer

Domain Logic Layer

Node Raw Input

Topology Link

Data Access Layer

Figure 5.1. Three layer architecture with pipes and filters pattern incorporated into the domain logic layer

46

BIBLIOGRAPHY Avgeriou, P., Zdun, U., (2005 July). Architectural patterns revisited: a pattern language. Retrieved March 2009, from Institute for Management Information Systems (MIS) and Institute for Information Systems and New Media site: http://wi.wuwien.ac.at/home/uzdun/publications/ArchPatterns.pdf Bahill, T. (2002). Applications of Blackboard Architecture. Retrieved April 2009, from Department of Systems and Industrial Engineering of University of Arizona site: http://www.sie.arizona.edu/sysengr/ Brickhouse Security (2009). GPS Tracking Solutions. GPS Tracking System – Small Covert GPS Device. Retrieved March 2009, from Brickhouse Security site: http://www.brickhousesecurity.com/gps-tracking-system.html Buschmann, F., Henney, K., Schmidt, D. (2007 June). On Patterns and Pattern Languages. Retrieved March 2009, from Wiley – Knowledge for Generations site: http://media.wiley.com/product_data/excerpt/28/04700590/0470059028.pdf Buschmann, F., Meunier, R., Rohnert, H. (1996). Pattern-Oriented Software Architecture: A System of Patterns. Retrieved March 2009, from Hillside Group site: http://hillside.net/patterns/books/Siemens/abstracts.html Corson, S., Macker, J. (1999 January). Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations. Retrieved March 2009, from The Internet Engineering Task Force site: http://www.ietf.org/rfc/rfc2501.txt Ecole Polytechnique Federale de Lausanne (November 2005). Security of Vehicular Networks. Retrieved March 2009, from Ecole Polytechnique Federale de Lausanne site: http://ivc.epfl.ch/ Gamma, E., Helm, R., Johnson, R., Vlissides, J. (October 1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional. Haerri, J., Bonnet, C., Filali, F. (2008 July). MANET Position and Mobility Signaling: Problem Statement. Retrieved March 2009, from The Internet Engineering Task Force site: http://tools.ietf.org/id/draft-haerri-manet-position-problem-statement01.txt Hussain, B., (2006 February). Pipes-and-Filters Pattern – An architectural design Pattern. Retrieved March 2009, from The Code Project site: http://www.codeproject.com/KB/architecture/PipesAndFilters.aspx Ilyas, M. (2002). The Handbook of Ad Hoc Wireless Networks. CRC Press. Kanchanasut, K., Tunpan, A., Awal, M., Das, D., Wongsaardsakul, T., Tsuchimoto, Y. (2007 January). A Multimedia Communication System for Collaborative Emergency Response Operation in Disaster-Affected Areas. Retrieved January 2009, from 47

Internet Education and Research Laboratory http://www.interlab.ait.ac.th/dumbo/DUMBO.pdf

(intERLab)

site:

Kurkowski, S. et al. (2005 October). MANET Simulation Studies: The Current State and New Simulation Tools. Retrieved January 2009, from the Toilers site: http://toilers.mines.edu/pub/Public/PublicationList/CSM-MCS-05-02.pdf Kurkowski, S., Camp, T. (2006 January). A Visualization and Analysis Tool for Wireless Simulations: iNSpect. Retrieved February 2009, from the Toilers Research Group at the Colorado School of Mines site: http://toilers.mines.edu/pub/Public/PublicationList/MCS-06-01.pdf Kyrnin, J. (January 2009). What is Ajax? Building Web Applications Just Got More Fun. Retrieved April 2009, from the About.com Web Design/HTML site: http://webdesign.about.com/od/ajax/a/aa101705.htm L-3 Communications Nova Engineering (2009). MANET (Mobile Ad Hoc Networking). Retrieved March 2009, from L-3 Communications Nova Engineering site: http://www.nova-eng.com/Inside.asp?n=Library&p=Manet Lim, S., Lee, W.-C., Cao, G., Das, C.R. (October 2003). A Novel Caching Scheme for Internet Based Mobile Ad Hoc Networks. Retrieved March 2009, from IEEE Explore Digital Library: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1284147 Marfia, G., Lutterotti, P., Pau, G. (2007). MobiTools: An Integrated Toolchain for Mobile Ad Hoc Networks. Retrieved January 2009, from UCLA Computer Science Department site: http://fmdb.cs.ucla.edu/Treports/mobitools-2007-main.pdf Nguyen, B. (February 2006). A Tool for Visualizing Mobile Ad Hoc Network Topology Definition Files. Retrieved January 2009, from Unique Persistent Identifiers for Internet Resources site: http://handle.dtic.mil/100.2/ADA444158 Ohrt, M. (September 2007). PHP GoogleMapAPI by Monte Ohrt. Retrieved January 2009 from PHP Insider site: http://www.phpinsider.com/php/code/GoogleMapAPI/ Rashmi, S. (2008 August). MANET (Mobile Ad-Hoc Network). Technology and Computers. Retrieved March 2009, from Saching site: http://www.saching.com/Article/MANET---Mobile-Adhoc-NETwork--/334 Shacklette, M. (2009). Object Oriented Arhictecture, Design and Methodology. Retrieved March 2009, from The University of Chicago Department of Computer Science site: http://www.classes.cs.uchicago.edu/archive/2009/winter/51023-1/ Thangavelu, A (2007 February). Location Identification and Vehicular Tracking for Vehicular Ad-Hoc Wireless Networks. Retrieved March 2009 from IEEE Explore Digital Library: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?isnumber=4141003&arnumber=415659 5&count=139&index=23

48

Thurnherr, S. (2003 June). Discovering the Network Topology of a MANET. Retrieved January 2009, from Ecole Polytechnique Federale de Lausanne: http://infoscience.epfl.ch/record/49930/files/Thu03 Nii, Y. (1986 June). Blackboard Systems. Retrieved March 2009, from Stanford University Department of Computer Science site: ftp://reports.stanford.edu/pub/cstr/reports/cs/tr/86/1123/CS-TR-86-1123.pdf Zimmermann, O., Schuster, N., Eeles, P. (August 2008). Modeling and Sharing Arhictectural Decisions. From retrospective decision capturing to proactive decision modeling. Retrieved March 2009, from developerWorks site: http://www.ibm.com/developerworks/architecture/library/ar-knowwiki1/

49

APPENDICES

50

APPENDIX A Source code of geodraw.php setAPIKey('ABQIAAAAAnrct4nfQ95oL7p2T2lDZRSwey2rpYzjE5f9RMwd2CinDca6UxR BRRpaMKm8Mxzar9ks3gPbZt4Zzw'); $map->disableDirections(); $map->enableOverviewControl(); $map->setMapType('satellite'); $map->setCenterCoords(98.2943, 7.8383); $map->setZoomLevel(18); //Read the file contents 51

ReadFromSock(); //SetBorders(); ReadFromFile(); String2Objects(); //Read the content and prepare the string function ReadFromFile(){ global $fileContent, $filePath; $fh = fopen($filePath, 'r'); $theData = fread($fh, filesize($filePath)); fclose($fh); $fileContent = str_replace(" ", "", $theData); //$fileContent = "Location [198.162.39.1, 100.612, 14.0805, 1, 100144]"; } function SetBorders() { $map->addMarkerByCoords(99, 9, 999, 999, 999); $map->addMarkerByCoords(98, 9, 989, 989, 989); $map->addMarkerByCoords(99, 9, 999, 999, 999); $map->addMarkerByCoords(98, 8, 988, 988, 988); } function ReadFromSock(){ echo "sock1 start... "; session_start(); global $fileContent; $address = '127.0.0.1'; $port = 33333; echo "init... "; // Create a TCP Stream socket $sock = socket_create(AF_INET, SOCK_DGRAM, SOL_UDP); echo "created... "; // Bind the socket to an address/port socket_bind($sock, $address, $port) or die('Could not bind to address'); //echo "bound"; //Accept incoming requests and handle them as child processes $read = array($sock); $write = NULL; $except = NULL; $num_changed_sockets = socket_select($read, $write, $except, 10); //echo "selected"; if ($num_changed_sockets == false) { echo "no data-read from session";

52

$fileContent = $_SESSION['content']; } else if ($num_changed_sockets > 0) { /* At least at one of the sockets something interesting happened */ $fileContent = socket_read($sock,10000,PHP_BINARY_READ); //echo $fileContent; echo "data recv length: " . strlen($fileContent); $fileContent = str_replace(" ", "", $fileContent); $_SESSION['content'] = $fileContent; } socket_close($sock); } //Split the string into locations and links function String2Objects(){ global $fileContent, $allObjects, $allSplit, $iconMicroClient, $iconEEE, $map, $linkExists; global $startLng, $startLat, $endLng, $endLat; global $color, $weight, $opacity; $iconImage = ""; $allObjects = explode(";", $fileContent); //echo "starting to draw: " . $fileContent; foreach ($allObjects as $oneObject){ $geoType = substr($oneObject, 0, 4); if ($geoType == "Loca"){ $oneObject = substr($oneObject, 9, strlen($oneObject) 11); $allSplit[] = explode(",", $oneObject); if ($allSplit[count($allSplit) - 1][3] == "1"){ $iconImage = $iconMicroClient; } if ($allSplit[count($allSplit) - 1][3] == "2"){ $iconImage = $iconEEE; } if ($iconImage != ""){ $map->addMarkerIcon($iconImage, $iconImage, 16,16,16,16); } $map->addMarkerByCoords($allSplit[count($allSplit) - 1][1], $allSplit[count($allSplit) - 1][2], $allSplit[count($allSplit) - 1][0], $allSplit[count($allSplit) - 1][0], $allSplit[count($allSplit) - 1][0]); } if ($geoType == "Link"){ $oneObject = substr($oneObject, 5, strlen($oneObject) - 6);

53

$allSplit[] = explode(",", $oneObject); Start2Coords($allSplit[count($allSplit) - 1][0]); if ($linkExists == true){ End2Coords($allSplit[count($allSplit) - 1][1]); if ($linkExists == true){ $map->addPolyLineByCoords($startLng, $startLat, $endLng, $endLat, $color, $weight, $opacity); $linkExists = false; } } } } } //Get the coordinates for the starting point of the link function Start2Coords($StartLocation){ global $startLat, $startLng, $linkExists, $allSplit; $startLat = 0; $startLng = 0; $linkExists = false; $i = 0; $len = count($allSplit); while($i < $len): if (count($allSplit[$i]) > 4){ if ($allSplit[$i][0] == $StartLocation){ $startLng = $allSplit[$i][1]; $startLat = $allSplit[$i][2]; $linkExists = true; break; } } $i = $i + 1; endwhile; } //Get the coordinates for the end point of the link function End2Coords($EndLocation){ global $endLat, $endLng, $linkExists, $allSplit; $endLat = 0; $endLng = 0; $linkExists = false; $i = 0; $len = count($allSplit); while($i < $len): if (count($allSplit[$i]) > 4){ if ($allSplit[$i][0] == $EndLocation){ $endLng = $allSplit[$i][1]; $endLat = $allSplit[$i][2];

54

$linkExists = true; break; } } $i = $i + 1; endwhile; } //Socket /* // Set time limit to indefinite execution //set_time_limit (0); // Set the ip and port we will listen on $address = '127.0.0.1'; $port = 33333; // Create a TCP Stream socket $sock = socket_create(AF_INET, SOCK_DGRAM, SOL_UDP); // Bind the socket to an address/port socket_bind($sock, $address, $port) or die('Could not bind to address'); // Start listening for connections //socket_listen($sock); //Accept incoming requests and handle them as child processes while(packetComing == true): $read = array($sock); $write = NULL; $except = NULL; $num_changed_sockets = socket_select($read, $write, $except, 3); $input = socket_read($sock, 1024); echo "finally something coming"; //$output = ereg_replace("[ \t\n\r]","",$input).chr(0); //my function endwhile socket_close($sock); //$client = socket_accept($sock); // Read the input from the client – 1024 bytes // Strip all white spaces from input // Display output back to client //socket_write($client, $output);

55

// Close the client (child) socket // Close the master sockets //socket_close($sock); */ ?> <meta http-equiv="refresh" content="15"> printHeaderJS(); ?> printMapJS(); ?> <style type="text/css"> v\:* { behavior:url(#default#VML); }

printMap(); ?>

printSidebar(); ?>

Refresh this page

56

APPENDIX B GeoDraw screenshots

Screenshot 1. GeoDraw in satellite mode

Screenshot 2. GeoDraw in map mode

57