CIS-8020 Assignment-2 VM Swine Flu Cases In U.S - Using Google Visualization API

Assume we are a working in the national department of disease control. The country is in the grips of a Swine Flu Pandemic. The President has declared a national emergency. The need of the hour is to have a co-ordinated nationwide response to the epidemic. An effective response is dependant on having real-time update on the spread of the Swine-Flu. All emergency personnel, federal and state healthcare agencies and hospitals need to have upto-date information about the impact of Swine flu in their state. This data is going to be critical to prioritize the shipment of Flu Vaccines and other critical medical supplies needed to combat this epidemic.

Using the Google Visualization API - Intensity Map is an effective way to keep track and publish the information on the spread and effect of Swine Flu. The Gadget uses a simple shared excel spreadsheet to record the data and the maps are updated instantaneously. By providing update access to the spreadsheet to key departments or agencies across different areas in all the states, we can ensure that accurate and timely information is obtained and that the information is easily available to everyone.

The ease of integrating the gadget, elimination of the need to write and maintain complex code , elemination of the need to transfer this data and associated complexities from multiple locations to a central location before publishing are the some of the major advantages of using this gadget.




The source data for this prototype can be found at this link

http://spreadsheets.google.com/pub?key=tzF8dlHGhRLiBSlv6YAK-sg&single=true&gid=1&output=html

Disclaimer: All numbers are shown for demo purposes only. These numbers do not indicate the actual number of Swine flu cases/deaths.

Assignment No. 2 T D Google Visualization API

A project manager wants to track the progress of his project.The Manager wants this information to be available to the other members of his team and also to his Superiors in the Organization.The Project Manager can achieve this by making a Gantt Chart for the project.A Gantt chart is a type of bar chart that illustrates a project schedule. It is a graphical representation of the duration of tasks against the progression of time.It is a useful tool for planning and scheduling projects and also monitoring the progress of projects.

Using Google Spreadsheets and the Google Visualization API the Gantt Chart can be made available to the entire team.The Gantt chart component can be added as a Gadget to the Google Spreadsheet and to publish the Gantt chart on a web page the Google Visualization API can be used.Google Visualization API enables you to expose your own data, stored on any data-store that is connected to the web, as a Visualization compliant datasource(in this case a Google Spreadsheet).Furthermore,if the manager wants other members of the team to update their progress on the Spreadsheet,he/she can enable this by using the Google Spreadsheets API.The team members can track their progress as well as the progress of the entire project .As and when the data in the Google Spreadsheets gets updated, the Gantt Chart made using the Google Visualization API will get Updated as well.

The fact this can easily be embedded in HTML pages gives it an advantage over other Gantt chart implementations such as no additional software needs to be installed to view the Gantt Chart and the Gantt chart can also be viewed over mobile devices with internet browsers.

The following is an example of how this can be achieved:

GANTT CHART:



The Google Spreadsheet from which the Gantt chart is being populated can be viewed here:

http://spreadsheets.google.com/pub?key=tH_dK_13Xc0UMaSYPbQdWKQ&single=true&gid=0&output=html

CIS8020 Assignment2 SR Google Calendar

A company conducts shareholder meetings and other related events at periodic intervals. Along with intimating its shareholders, it also wants to enable visitors to its website to view its monthly agenda.
Google Calendar API provides a simple solution. It allows embedding an internal calendar hosted in Google sites, on the company’s website. A static calendar image displays the events scheduled and gets updated every time a new event is added to the internal calendar. The viewer can choose the mode of display. Following is an example:



Google Calendar is extremely easy to use and does not need to be programmed or coded. Since the application itself is hosted on Google sites, the company need not bother itself with performance issues. Updating the calendar is hassle free as it requires changes to be made only once, in the internally hosted company calendar. Moreover it is free to use.

REST vs SOAP Web Services

After the presentation by the CIS Integratem team on REST last week I began to wonder as to what the major differences between REST based and SOAP based webservices are and why in some cases REST is preferred and in others for SOAP. This is what I found:
At a fundamental level the difference between REST based WS and SOAP based WS depends on whether the application is Resource oriented or Activity Oriented.
REST based WS can be classified as Resource Oriented. Resources are identified and located by a Universal Resource Identifier (URI), and the operations that might be performed against those resources are defined by the HTTP specification. In RESTful web services, the emphasis is on simple point-to-point communication over HTTP using plain old XML (POX).
REST is an architectural style that can be summed up as four verbs (GET, POST, PUT, and DELETE from HTTP 1.1) and the nouns, which are the resources available on the network (referenced in the URI). The verbs have the following operational equivalents:
HTTP CRUD Equivalent
===== =========================
GET read
POST create, update, delete
PUT create, update
DELETE delete

On the other side of the coin are Activity-Oriented Services. SOAP based WS are typically Activity Oriented.These types of applications focus on actions that you might perform rather than on the resources upon which they act. Unlike resource-oriented services, where the operations that might be performed remain relatively constant regardless of the type of resource, operations in activity-oriented services depend entirely on the type of activities being performed.
In resource-oriented services, a common set of operations play a supportive role, allowing clients to access and manipulate resources. However, the resource is the center of attention, as shown in Figure 1 below.

Figure 1. Comparing resource-oriented services (REST) to activity-oriented (SOAP) services





In activity-oriented services, the operations are the center of attention, with a single operation for each activity the client might request to be performed.
The Pros and Cons of the SOAP and REST based WS can be summed as follows:
SOAP
Pros:
• Language, platform, and transport agnostic
• Designed to handle distributed computing environments
• Is the prevailing standard for web services, and hence has better support from other standards (WSDL, WS-*) and tooling from vendors
• Built-in error handling (faults)
• Extensibility

Cons:
• Conceptually more difficult, more "heavy-weight" than REST
• More verbose
• Harder to develop, requires tools
REST
Pros:
• Language and platform agnostic
• Much simpler to develop than SOAP
• Small learning curve, less reliance on tools
• Concise, no need for additional messaging layer
• Closer in design and philosophy to the Web
Cons:
• Assumes a point-to-point communication model--not usable for distributed computing environment where message may go through one or more intermediaries
• Lack of standards support for security, policy, reliable messaging, etc., so services that have more sophisticated requirements are harder to develop ("roll your own")
• Tied to the HTTP transport model

The REST architecture might appear less complex as compared to the SOAP WS arch but it should also be kept in mind that it offers less functionality in key areas such as reliable messaging .
Hence, while deciding on the type of WS to be used the Pros and Cons of each should be considered and also the kind of functionality which is desired should be taken into account.

References:
http://www.ibm.com/developerworks/webservices/library/ws-restvsoap/?S_TACT=105AGY82&S_CMP=GENSITE
http://www.ajaxonomy.com/2008/xml/web-services-part-1-soap-vs-rest