When you create a web service, you need to address various design issues to build an effective and portable web service. In this article we will discuss various design issues that we face while building a web service.
Here I am categorizing the various design issues into four different categories.
- Synchronous and Asynchronous Communication
- Session State Management
- Transactions
- Caching
Synchronous and Asynchronous Communication
Before we build a web service, we need to decide whether the service should use Synchronous or Asynchronous communication.
Mostly real time applications use the synchronous communication whereas the asynchronous communications are used mainly to reduce the process waiting time.
Synchronous communication will run each application thread until it completes, but it will slow the system down and affect the end user's experience. Asynchronous communication allows application threads to send requests for a system resource, but it continues the other process rather than waiting for that particular resource. Here the waiting time is completely reduced. But its unusable in the real time applications, in that case Synchronous communication is recommended.
Session State Management
A client server communication can be made either a stateless or stateful communication. It purely depends on the requirements. Our web development provides us the various mechanisms to maintain the session state, such as application variable, session variable, cookies and etc...
But as per web service design perspective, it's better to avoid the using application variable or session variable to avoid the extra memory space required in the servers. The best way to handle this issue is, we should design the web service in such a way that they provide discrete pieces of functionality. If we still need some value means, we can include the values explicitly in the soap message itself.
Transactions
Transactions can be defined as a set of actions that succeeds or fails. If any of the actions fail, all the object states should be rolled back.
Transactions are not at all an issue relevant to a single web service; the problem arises only when there is an involvement of multiple web services.
Time Stamped snapshots can be implemented to handle this. We can take the time stamps of the changed data and based on that we can rollback or commit transactions. But that's also a partial solution and not a complete solution. There are more Web Service Specifications being developed to handle this situation very effectively.
Caching
Some web services often provide the static data on each request; in that case we can implement caching in web services. But it won't help where the data changes frequently, for example you can take the currency converter, because it should produce different range of output depends on the user input.
Whenever the caching is implemented in your application, it should be validated in certain interval of time. Expiration duration should be set to each cache data to avoid keeping the old values otherwise the clients will get the wrong values.
The above four key things should be considered while designing a web service. If this four things are handled in an effective manner, surely the web service is going to perform well.