CHAPTER 8 PERSISTENT COMMUNICATIONS PATTERN 247 Implementing
CHAPTER 8 PERSISTENT COMMUNICATIONS PATTERN 247 Implementing the Server-Side Monitoring Process One of the major pitfalls of an HTTP server is that it is a reactional server. A reactional server, when confronted with a request, will react and generate a response. After having generated the response, the HTTP server sits idly waiting until another request arrives. The problem with this approach is that the standard HTTP server does not process data when there is no request. Let s consider our two-stream communication mechanism and the status example. As the HTML client is coded, the user is responsible for sending an update. When managing server- side status updates, this is usually not what happens. Instead, some external action occurs that causes an update. The web application needs to be informed of the update, and that is where the problems occur. As illustrated in the version-tracking example, the client waits for the _callCount to increment. Real-life applications are not going to be as simple as waiting for a variable to be incremented. Real-life applications need a signal mechanism. I will not cover how to implement a signal mechanism because it is beyond the scope of this book. However, the way that many projects solve the problem is by creating an HTTP client application that will act like a web browser and submit data to the server. From an architectural perspective, it appears similar to Figure 8-8. Figure 8-8. Active server service using the HTTP server
Check Tomcat Web Hosting services for best quality webspace to host your web application.