Communication

Communication and interaction in a distributed system for collaboration has to be fluent and robust. The distributed nature of the content on the system relies on the asynchronous communication between the application instances. The communication is very often transparent to the user, and therefore, the state of the service can be unknown if the interaction and user interface has not been carefully designed. Since the system relies on the content distributed from the peer users, the whole value of the service is dependent on the content distribution and communication.

Communication capabilities or collaboration modes enable the communication via different communication channels. In the present concept system the available communication channels are all the available channels that support HTTP connection. These include for example the use of 3G and Wi-fi connectivity if present. Reif et al. [2001] list preferable collaboration modes for mobile collaborative systems. These include ad hoc, connected and disconnected modes. In the presented concept all of these modes are supported.

The ad hoc connectivity can be enabled by an ad hoc Wifi connection, while the connection to the Web can be done via 3G packet data with a suitable gateway solution. There exist though several difficulties when using an ad hoc communication between mobile devices. These will be discussed more in Chapter 7.

4.6.4.1 Infrastructure

When an infrastructure connection like 3G packet data is available it should be used for the communication. For infrastructure connectivity, a gateway solution is needed to overcome the problems encountered by the changing IP address in a wireless network. While there are network layer solutions to overcome this problem, such as the Mobile IP, they are not available yet on commercially available wireless networks. In this work the solution includes a gateway and a DNS resolver provided by Nokia Research Center for their Mobile Web Server connectivity [Ilkka & Vainio, 2007]. This solution can be used already because of its availability as an end-user product.

4.6.4.2 Ad hoc

When an infrastructure connection is not available the communication should be done via an ad hoc connectivity. As the name implies ad hoc connectivity works without a network infrastructure. Thus the address resolving must happen in an ad hoc manner. To overcome the addressing problem the architecture can be used via a denoted super peer, which serves as proxy between the peers. This is a very simple solution, but it scales well to the proposed architecture as well as provides the needed functionality. Some problems were encountered though with the reliability of the connection in an environment with several other Wifi networks around. The architectural comparison between the ad hoc and infrastructure connectivity solutions is illustrated in Figure 12.

Figure 12. Ad hoc and infrastructure communication comparison

A possible group communication scenario is illustrated in Figure 13, including both personal group communication as well as communication outside the group. The communication and messaging between the application instances is described more in the following subsections. These include both the server-side and the client-side technologies.

Figure 13. Group communication – collaboration is done in small groups but the information can be shared to a wider context

4.6.4.3 Ajax

Ajax [Garret, 2005] is a technique using the asynchronous communication provided by the XMLHttpRequest –object with some data interchange format, mainly XML [Bray et al., 2000] to communicate with a Web server. By communicating asynchronously it helps to avoid page reloads and unnecessary data exchange, thus it makes the user interaction seem smoother and the communication more efficient. It also enables the development of Widgets, stand-alone Web applications which are installed on the client-side and only retrieve the content from the server-side. This content can be formatted using for example XML or JSON [JSON.org, 2009]. The comparison of these data serialization formats is given in the next subsection.

4.6.4.4 XML versus JSON

XML has been the de facto language to serialize data [Bray et al., 2000] for quite a long time, both in Web related applications as well as in traditional software.

XML is used in a variety of interface solutions and data representation tasks because of its extendable and adaptable structure. It can represent very complex hierarchies and structures as a tree-type form. One disadvantage of XML though is the inefficiency when parsed to an object format for easier access. The extensive hierarchy makes it cumbersome and resource needy when parsing large XML-documents. In other hand, the advantage of XML is its uniform representation and format which makes it a very domain independent interface language.

JSON is a new approach deriving from the popularity of Ajax and JavaScript. JSON is a lightweight computer data interchange format. It is a text-based, human readable format that represents simple data structures as serialized objects or associative arrays [JSON.org, 2009]. The main difference to XML is that since the JSON is described as an associative array the name-value pairs have to be grouped by unique names. This means that the elements occurring more than once are grouped in an array under the name of that corresponding element [XML.com, 2009].

Figure 14. Communication procedure

The overall communication procedure is depicted in Figure 14. The procedure is started by a request from a client to the service to access a certain resource. Then that request is handled and a response is formed accordingly. In the end that response is sent back to the requestor, which will parse and make use of that resource.