Archive for the ‘Physical Design’ Category

REST Service Implementation using HTTP – Cross Domain Request

Sunday, March 29th, 2009

By Phavanhna Douangboupha, 03/29/09

The three main basic ideas of a REST process are to process a client request, to response to the request, and return a result/data in XML format according to the request.

Two techniques that can be used are getting parameters from client through a URL query string and the use of HTTP methods. The first technique is easier to implement compared to the second technique. The main disadvantages of the first technique include the size of the URL string, the maximum length of the URL string consisting of query parameters, and a possible negative side effect. The first limitation, the size of URL string, can be overcome by using POST method instead of GET method for a client request. However, POST and GET methods should be applied according to a specific task (see the blog on Creating REST Web Service for more detail). Consequently, the HTTP methods are a better solution for REST service.

I have already talked about how to implement a REST client using a URL query string from my previous post, now I will talk about how I implement a REST service for the cross server client request using HTTP methods.

For this exercise, a database server, a web host server and a web client server are assigned in different machines and hosted by different domains. The database server is hosted at STREAMER. The web host server is hosted by CHW domain and finally the demonstrated web client request comes from GIBSON domain (Figure 1 shows system architect for the REST cross domain service). STREAMER is a house to MySQL database which is hosted in a different domain from the web server.

System architect for REST cross domain service
System architect for REST cross domain service

Figure 1: System architect for REST cross domain service

GIBSON is used as a demonstration client to request data from another domain (CHW). The four main files implemented here are a normal HTML file (index.html), a JavaScript file (client_local.js), and two php using cURL libraries files (getclient_chw.php and postclient_chw.php). The Javascript file is used to implement Ajax to send a request and to receive responded data sent back by a server asynchronously. The data is displayed on the HTML file. The JavaScript file uses HTTP request object to send a request to either getclient_chw.php (”How Many Users?” in the database) or postclient_chw.php (”Add New User” to the database). getclient_chw.php and postclient_chw.php use cURL libraries to set up a HTTP request where getclient_chw.php uses the GET method to request to get data from a server and postclient_chw.php uses the POST method to request to post data to a server (please see table 1 for the correspondent HTTP methods to the database query). Both of the files make a request to process data with the web server on CHW. The client side has no relation to the database server on STREAMER and it only sends a HTTP request which will later be checked by the web server.

Use Gibson to act as a client to make REST request​ (Figure 2) - http://people.rit.edu/~pxd8840/restclient/index.html . As you click one of the two buttons – “How Many Users?” (HTTP GET) and “Add New User” (HTTP POST), you will see that the displayed results are updated asynchronously. These are done via Ajax using REST service to perform a cross-domain request instead of the <script> tag hack solution as mentioned from my previous post.

index.html, client requests on GIBSON

index.html, client requests on GIBSON

Figure 2: index.html, client requests on GIBSON

On the web host server (CHW), there are two main files – rest_database.php and ConnectDB.php. ConnectDB.php is an Object Oriented PHP class that contains methods to connect to the database and the required methods to process or retrieve data from STREAMER database server. The rest_database.php file also contains all the logic check method that received from a client. The rest_database.php file is used to check what kind of request being made if it is a HTTP GET request or a HTTP POST request. According to the request, it retrieves data from the database. Then it creates XML responses to the client.

Table 1: HTTP method, REST action, and SQL command for a client request

HTTP Request Method REST Action SQL database command Description
GET GET SELECT Search/Request for
data (getdata)
POST POST INSERT Add/Insert new data
(postdata)

List of files

Client Side

  • index.html
  • client_local.js
  • postclient_chw.php
  • getclient_chw.php

Server Side

  • rest_database_php
  • ConnectDB.php class code on the server side contains database connection and database process methods

References:

Links to other blogs in this project

WIMP is Dying, Long Live WIMGi

Wednesday, March 4th, 2009

From WIMP to WIMGi

The WIMP (”Windows, Icons, Menus, Pointing-device”) formulation for human–computer interaction design has lasted a long time (it was coined by Merzouga Wilberts in 1980). The phrase has become perceived as pretty much a synonym for “desktop GUI”, but I think it is dying (or at least past it’s prime). I think the death of WIMP will be a result of two things: the spread of touch-gesture oriented handheld devices, and the emergence of practical & relatively inexpensive multi-touch screens (see especially the work of Jeff Han).

So, what is taking the place of WIMP? I think we are entering the Age of WIMGi (rhymes with “whimsy”): Windows, Icons, Menus, Gesture-interface. Why is WIMGi taking hold so strongly, and what is so different about it that we need a new acronym?

New Paradigms Require New Labels

Labels have symbolic power, and a new way of thinking about the “palmtop” and “desktop” environments requires a new label. A pointing device like the “mouse” is radically different than the gestures of the human hand-and-fingers. A mouse has one on-screen representation (the “pointer”), while fingers (plural) may require a different on-screen representation and definitely require different responses (”event handling”) from a computer.

WIMGi is a new paradigm for human computer interaction; it requires new thinking about how people will get work done, and about what operations it is possible for them to command easily. In the “palmtop” environment, WIMGi is perceived by users as “more natural”. In the “big screen” environment, WIMGi seems to require more work getting “used to it”.

Big-Screen Multi-Touch

Many people were amused to note the number of “giant multi-touch video walls” appearing on television during the 2008 Presidential election. I was interested to observe that correspondents had trouble “getting used to using it” (on the physical level), and that producers had trouble figuring out how best to use such displays (on the information-transmission level). So many shows used these devices simply “because they were sexy and new”, that a range of spoofs emerged like one segment in this “Saturday Night Live” program:

Palmtop Device Multitouch

On the other hand, even simple 2-fingered stretch/shrink gestures are “understood” almost immediately by people using “palmtop” devices. I think palmtops, laptops, and architectural-drawing-stand-like surfaces are probably the easiest venue for WIMGi to take hold within, as the scale and the gestures “just seem natural” to users. I think it will take a bit longer for big-screen WIMGi to take hold.

Just as many people had a somewhat steep learning curve when first introduced to computers with pointing devices, I think many people will have a harder time learning to use big-screen WIMGi computers than palmtop WIMGi devices. Who among us has not performed multi-finger gestures on a small scale, like on the palm of your other hand? Multi-finger/multi-hand gestures “writ large” on a wall-sized screen may take longer to learn.

What do you think of all this? Critical thinking, comments, new ideas are what I am after here. And so I repeat:

WIMP is Dying, Long Live WIMGi

Web-based resource tracking system implemented on a mobile device

Wednesday, October 29th, 2008

by Phavanhna Douangboupha

The objective of this project is to develop a prototype for an easy to use web-based resource tracking system implemented on a mobile device. It provides real time data to a decision maker so that he/she can effectively and efficiently monitor resources and access the situation accordingly. By the same token, emergency personnel (e.g. a doctor or a police man) has the advantage of system auto login without manual report upon their arrival to an affected location. The system architecture of the web-based resource tracking during a disaster or crisis situation can be seen below in Figure 1.

System architecture of Web-based resource tracking during a disaster or crisis situation
System architecture of Web-based resource tracking during a disaster or crisis situation

Figure 1: System Architecture of Web-based resource tracking during a disaster or crisis situation

Resources are, a human resource (e.g. a doctor, a policeman), a moving resource (an ambulance, a police car), and a building resource (e.g. a hospital).

The prototype includes three main applications – position tracking, resource management, and identity manager modules.

The resource management system consists of emergency classification, search, and alert systems. The project aims to design an easy to use user interface for the system so that users and decision makers can get to important information as quickly as possible. One of the solutions to such an objective is to have a classification of emergency combined with a recommendation system. The application utilizes the pre-existing data to recommend resources (what are required resources and their locations) for a certain situation such as flooding. Apart from the recommendation system, the system offers another search option, nearest search option, for users to search for required resources for the crisis that they have to manage.

The identified needed resource shall be alerted by the system. For a moving resource such as a doctor or an ambulance, the system should automatically provide routing or direction information to his/her GPS-enabled device. This functionality links to the position tracking application.

The second application is the position tracking application that consists of real time location update, routing, and the time statistic module. As a doctor responds to the system alert, his/her GPS enabled device will automatically send his current geographic X, Y coordinate location in thee form of an XML file. The XML file also includes the login id which is the unique device id. Before being passed through the network, the XML file is encrypted and only the system can decrypt the information (the identify manager module). As each resource travels toward the site, the decision maker will have a virtual map showing real time information about the resources. In addition, the system shall be able to provide a report on number of resources at each near by location. The routing information and the estimate time statistic prediction on when each resource will reach the site will also be an option on the decision maker’s screen. Using API technology, a virtual map is requested from a map server.

The system will make the use of the REST web-service to bridge the connection between the server and clients. The REST web-service and the WWW solution for the prototype are selected to avoid certain mobile specific standards. REST provides a solution for the mobile device system to interface with the system in manageable lightweight implementation. Since, REST utilizes URI namespace technology, it makes the application scalable and the data can be easily shared with different servers. In addition, REST uses HTTP and XML solutions and hence it is well understood by firewalls and security administrators.

Links to other blogs in this project

Designing & Implementing Sites I: Server-Side Technique

Monday, March 31st, 2008

Divide & Conquer: Modularize your site

Separate the physical & logical design of your site, then build modular components which can be mixed and matched when needed. Your site will be easier to maintain and modify, your designers & developers will have an easier time, and your users will have a better experience.

Separation of Concerns, the MVC Paradigm, & Other Design Ideas

In the (almost) beginning there was NAPLPS, and it was good. Content and Presentation were separated, and the maintenance was (relatively) easy. When HTML first came along, Content and Presentation were jumbled together for a while, but gradually CSS emerged and separation of concerns came to the fore again. With the emergence of Javascript/ECMAScript to deal with Behaviors, the MVC paradigm came into full flower on the Web: (X)HTML provided us with a model of the data, CSS provided us with the presentation or view of the data, and Javascript/ECMAScript provided us with code to act as controller of page/user behaviors.

Website designers learned to take advantage of this approach to make their lives easier, through modularization of XHTML/CSS/Javascripts into separate files and subdirectory structures. This “divide and conquer” strategy allows site designers to utilize request-time assembly of response-payloads on the server-side, as well as programming client-side requests for additional components to happen at run-time. Separation of concerns means content creators and visual designers can work with reusable components, and that they can maintain/modify whole sites/sections with the greatest of ease.

Server-Side Assembly of Payloads

Good designers remember that HTTP is a request/response protocol, they realize that logical and physical site design do not need to be the same, and they recall the old adage that “a lazy programmer is a good programmer”. Good design often results in reusable modules of code (in this case: XHTML, CSS, Javascript/ECMASCript). One of the critical factors in good site design is deciding what the “atomic unit” is for a particular case.

Site designers can take advantage of just-in-time technologies such as “server-side includes” to assemble payloads for clients on demand, resulting in the <style/> and <script/> nodes being inserted into a server-side template at request-time but before response. For example, the following code in an (X)HTML file would cause the server to insert site-wide <style/> and <script/> nodes at request-time into the payload actually being delivered:


<style type="text/css" media="all">
/*
<![CDATA[ */
<!--#include virtual="./stylesheets/content.css" -->
<!--#include virtual="./stylesheets/tabNav.css" -->
/* ]]>
*/
</style>
<script type="text/javascript" charset="utf-8">
// <![CDATA[
<!--#include virtual="./javascripts/appendStylesheet.js" -->
// ]]>
</script>

Note that this design approach can be implemented using any of a number of other server-side technologies, such as PHP or Perl. The temptation to generate the content of the payload on the fly rather than just assembling it can be overwhelming for some site designers/implementers, but this is dangerous. Just-in-time assembly of a client payload at a Website means using atomistic units which match a physical and logical design, and units simple enough (being just XHTML, CSS, and ECMAScript/Javascript) that a very wide range of people in an organization can create and modify them. Using server-side scripting (like PHP) to generate the content at request-time hides elements of the site design in the content generation scripts, thus increasing the specialization-level required for someone to create new or modify existing site content.

Separating logical and physical design like this helps reduce site-wide maintenance costs and site-redesign difficulties as well as supporting graceful degradation and progressive enhancement of CSS.

Graceful Degradation & Progressive Enhancement

Okay, so that tells us something about how to think about designing the logical and physical structure of a site… we break things up into reasonable units, and we assemble what is needed at request-time. But what about after the payload is delivered to the client? Designers have gotten used to applying the idea of graceful degradation to their work. Due to the wide range of handheld, mobile, and big-screen devices we need to serve, these days designers and implementers also need to think about progressive enhancement.

We will take up designing for graceful degradation & progressive enhancement of both CSS and Javascript/ECMAScript on the client-side next. The server assembles at request-time, and the client can change (the DOM and other things) at response-time.

Be sure to tune in for our next post, coming to this blog soon:

Designing & Implementing Sites II: Graceful Degradation & Progressive Enhancement of Client-side CSS & Javascript/ECMAScript