ICT705 Data and System Integration For Key System

Answer:

Introduction

Most communication between applications involves exchange of data that may not be homogenous. As such, communication becomes error  prone and difficult as the client must be able to discern the type of data beforehand. Thus, applications become very tightly coupled in communication with most systems unable to do so without modification. In the light of that, Service Oriented Architectures provide a standardized way of making requests between various applications in a platform agnostic fashion. The service oriented architectures define a set of methods that can be invoked by the client in a standard way. This removes the complexity and tight coupling hence facilitation efficient and fast application between applications (T. Sanders, A. Hamilton Jr and A. MacDonald, 2008). It also removes the need to install additional resources in interpreting communication of modification of programs to allow communication. There are many softwares that assist in creating these service oriented architectures although they are not necessary required to achieve that outcome.

Key System Concepts

In order to be able to discuss the demo application, various system concepts need to be addressed. These are the major areas that affects our application in its operations. The major areas are data merging and cleaning.

Data merging and cleaning

Data merging involved consolidating data from various sources. This is done differently in every programming language. However, the goal is to be able to come with data that is complete. Various sources of data include XML files, JSON repositories, Comma separated values and even relational databases. Data is joined on a key field that is present in the participating data sets. This may be thought of as a primary key – foreign key relationships in relational databases. However, in such sources as these mentioned above, the relationship may not be enforced and therefore some fields are likely to be left. In the demo application, this merging was achieved using a library in python call petl. This library contains various methods for querying different types of data sources and coming up with a standard datasets that can then be used in the merging process. In this application, the data sources were the comma separated values and xml files. These data sources where merged using key column on one source that is also present in the other source.

Data cleaning is preparing data by removing incorrect data from the collection. It can even include removal of unwanted characters such as spaces and special symbols. In the demo application, the cleaning was done on the email address by removing spaces and making sure that the email was in the correct format.  Therefore, cleaning can involve joining or splitting. It is mostly achieved using the regular expressions that allow to define the pattern of characters to be manipulated based on a given pattern or order of occurrence.

RESTful Webservices

REST stands for Representational  State Transfer (Fielding Dissertation: CHAPTER 5: Representational State Transfer (REST), no date). It is a standard that is used to allow applications communicate over the internet by using a defined standard.  In this standard, almost anything is defined as a resource that can be accessed by a URL like a webpage. These URL are the endpoints through which the external application requests the resource.  Additionally, these resources can be accessed through HTTP methods defined in the HTTP protocol. Such methods are GET, POST, PUT and DELETE. GET can be used for read only requests, while PUT is used to create a new resource. This can involve saving data to a database or creating a file such as an XML file. The DELETe method is intended to be used for deleting resources from the collection. It can be used to delete a record from a database or from the storage.  POST can be used for creating and updating an existing resource.  All these methods are mapped on the CRUD operations that many application perform on resources.

Mashup

The mashup application is a page that facilitates sending requests to the backend server application. In this model, the application first sends a get request to the python application which responds with JSON data that is used to fill the Service Ids. The user select an id and sends a request to the server application which responds with full details about the clinic. After that, the javascript is used to create the page dynamically from the JSON response.

Demo and Running the application

The application is made of python. Thus it can be hosted in the simpleHTTPServer that comes installed with python. This can be achieved by executing the start server command and passing the port number from the command prompt.

The HTML file with Javascript creates the requests to the server application listening on port 8000 on localhost. The application replies by sending data in form of JSON that is used to dynamically create a web page. In this case, it involves the marking the map on the Google map.

The bottle library used does not impose any strict requirements because it can be distributed with the application. It also does not depend on their party libraries but those of the core python. Installing these libraries is easy because they are free and can be installed using the pip command.

Conclusion

The developed application has been able to mimic stateless communication between application as exhibited in Service Oriented architectures. This has been achieved by implementing various methods that can be called by an external application during the communication process. It not only makes it easy to implement communication but also allows developers to be able easily create applications that can communicate with each other without the fear of complexities.

References

Fielding Dissertation: CHAPTER 5: Representational State Transfer (REST) (no date). Available at: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm (Accessed: 7 June 2018).

Sanders, D., A. Hamilton Jr, J. and A. MacDonald, R. (2008) Supporting a Service-oriented Architecture. doi: 10.1145/1400549.1400595