Client-Server Based Applications and common approaches
There are plenty of scenarios which a simple stand-alone application cannot meet your needs. Data management applications with search and reporting capabilities are not the only Client Server Architecture software. Exchange of Ideas, concurrent usages and online access are basic requirements which impose Client Server Model applications. The first step to build a Client Server Application is deciding about the overall structure. A system architect cannot make a good judgment if he or she does not know all the options for such development. In this article I intend to introduce what one needs to design a Client Server Model application. First we start with a topological view of the network and then review the options to develop a client server application.
Client Server architecture is opposed to the Peer-To-Peer architecture where all clients can talk to each other directly. A basic example of peer-to-peer architecture is file sharing of windows which each computer in the local network can share and access files from the others and every computer can act as a server while being a client at the same time. On the other hand in the typical client-server architecture there is a server which processes request from clients and responds to them. Although in such systems communication between clients is possible through a bridge passing from the server, these systems are different from Peer-to-peer architectures because clients don’t communicate with each other directly.
There are varieties of solutions to implement client server model applications all starting from server underlying infrastructure to handle requests from clients. From a low level, much closer to machine level perspective, the network protocol which handles our requests, forms our subsequent conclusions for design and implementation. At the lowest level, you can start communicating with the network card directly and process network packets although you don’t need to most of the times. At a higher level you can handle requests on top of TCP/IP i.e. you can develop our own layer 7 protocol using socket programming and explicitly manage packets on top of TCP/IP. Although there may be cases for doing so, for most client server applications such design and implementation is not also recommended. A more common approach to develop Client Server Apps is to rely on existing protocols and infrastructures; in this approach you don’t get involved in socket programming and most of your programming relies on high level languages which provide you the infrastructure e.g. PHP or ASP.NET.
A good example of relying on existing platforms and infrastructure to provide you the requirements for a client and server communication is wide-spread web. Despite the language World Wide Web (WWW) applications are developed with, they use the same infrastructure. In a typical WWW Client Server scenario, client and server are using HTTP for communication. Server application in this scenario—most of which are called websites— is installed on a web server (mostly Apache or IIS) and the client application is the user internet browser software. Another example is desktop applications that communicate data using a database. In a general scenario, there is a database server like SQL or postgresSQL and a bunch of desktop applications that are reading and writing to the database as clients. In both of these examples, programmer does not involve in network programming; they rely on existing infrastructure.
Although the aforementioned examples were instances of client server model applications, the programmer is involved either in developing the server application, developing the website for the first example, or the client application, the desktop application to connect to database server. In a more complex scenario developing both the client and the server application is inevitable. Most of mobile applications are instances of such cases. To understand the difference, compare this category with the previous one. In the previous scenarios programmer write codes of the web or the desktop application but does not involve in handling the client requests. In case of web application, web server handles the request and executes the program codes line by line. In case of database, database server processes the queries and returns the results. However in this design pattern, the programmer writes a piece of application for the server side that handles the requests of the client while at the same time he develop a client app to send the requests.
When you need to develop both the client and the server application, defining custom standards to establish the communication between client and server is unavoidable. If you do not plan to get involved in lower level of communication we described (which is the case for most scenarios!), you probably want to use SOAP, REST, Web services (not restful) or even sometimes a raw html processor. In a small application, using a simple web service for communication does no harm while for an enterprise level application SOAP or REST based implementation should be adopted. Raw html processor is used when the server is already developed.
SOAP vs. REST
SOAP and REST are competitors in the context of client server model applications even though they vary significantly. SOAP is a communication protocol for exchanging message that can be used over HTTP, FTP, SMTP and etc. WSDL is just one standard of the SOAP standard stack. In a SOAP standard a XML file defines the framework of communication. In a SOAP based communication, different programming platforms can talk and communicate using the defined standard. On the other hand REST is an architectural style for web services over HTTP. I believe the best description of REST is given by Umapathy and his colleagues at the University of North Florida:
“REST suggests a resource-oriented model for designing interactions among Web services”
In a RESTfull web service, resources are identified by a URL and to manipulate the data, HTTP methods are used. In contrast to SOAP where narrowed standards like WSDL exist, REST is based on a series of principals. This made development of applications by REST much more time consuming because there are already tools that aid you in SOAP based development but not any for REST. In a RESTfull based implementation you should adopt the principals and build your own standards. From the performance perspective, in “Comparing Performance of Web Service Interaction Styles: SOAP vs. REST” paper, Umapathy and his colleagues published REST and SOAP implementation based results. Their results show that REST has a better performance.
In a client server model, nodes are communicating with each other. Deciding how deep you want to get involved in the network communication means forms your subsequent actions. A client server model does not necessarily need both the client and server application although sometimes developing both is inevitable. In case of planning to develop both the client and server applications, standards are a most. In a layer 7 client server scenario, SOAP and REST are the most common methods to use. Developing based on REST principals is slower but the performance of REST is better than SOAP.