Welcome!

Machine Learning Authors: Liz McMillan, Janakiram MSV, Roger Strukhoff, Yeshim Deniz, Pat Romanski

Related Topics: Machine Learning

Machine Learning : Article

Enterprise Comet: Awaken the Grizzly!

The real deal

There's a common misconception among many end users, consumers, and developers that AJAX is the ultimate solution for the Web and that it can provide all the same functionality as a rich desktop solution. Sure, AJAX can cover most of our expectations for a rich client, mimicking functionality provided by a desktop application, but there's still one area that has yet to be fully integrated ­ scalable server-initiated message delivery.

With server-initiated message delivery, all end users of a particular application are simultaneously notified of any changes to the application state, e.g., at the stock exchange a stock is dropping fast and the trading application has to inform all traders about the sudden change in price.

Server-Initiated Message Delivery
Let's use the trading application as an example for server-initiated message delivery. Each broker has his own preferences in stocks and bonds and requires instant notification of changes in the market. A desktop client for a distributed enterprise application typically registers interest in specific kinds of server messages so the server can notify the desktop client when they occur. This lets the desktop application efficiently use the network on a need-to-know basis instead of having the client actively ask for information.

This approach won't work for a traditional Web-based AJAX application since the server can't initiate a direct connection to the browser because of browser security, firewalls, and Web proxies.

Sure, it's possible with AJAX to "notify" a Web client that a change has occurred on the server using a technique called "polling." By creating a Web application that polls every now and then the end user believes that he's been notified by the server, when in fact it's repeatedly asking for updates like any child asking for candy ­ Can I get it now? Can I get it now? Can I get it now? You get the picture.

Of course, this impacts network bandwidth since there's traffic for each polling request even when no updates are available from the server. We need a way for Web clients to register interest in certain types of messages and then let the server initiate delivery of those messages, pushing them to each browser.

There's a Twist
OK, OK, OK, there is a twist ­ you can't actually "push" messages to a Web-based AJAX application unless you maintain an open connection from the client to the server. However, a thread is kept alive on the server for each open connection so messages can be delivered to the browser immediately.

The fact that you'd even try to maintain an open connection per user to a server would have heads rolling down the corridors in most IT departments. Just imagine thousands, or even hundreds of thousands of connections, using the thread and process pooling models provided by most Web Servers today, keeping each thread alive on the server just to be able to send a message to the client ­ it doesn't scale! Let's come back to that one later.

HTTP Connection Limitations
Today most frameworks leveraging AJAX are using the XMLHttpRequest object, which allocates an HTTP connection for the duration of the request. The HTTP 1.1 specification recommends that browsers support a maximum of two open connections to the hosting server. This presents a problem for highly interactive AJAX Web applications, especially on Microsoft Internet Explorer, which enforces this recommendation.

If there are more than two AJAX frameworks or components using the XMLHttpRequest on the same Web page then there will probably be contention for the two open connections, causing requests to queue. The result will be blocked and ineffective communication, defeating the main purpose of having AJAX on the Web page. There's a need to share server communications over two HTTP connections at most.

Next-Generation Web Communication
The main reason a Web server allocates one thread per connection is because it expects the request to be highly active and short-lived. However, maintaining an open connection to the server is extremely long-lived and activity is mostly dormant. We also need a way to meaningfully share server communications to address the browser connection limit. Thankfully, there are several projects in process addressing the limitations of traditional AJAX Web applications. Let's have a look at some of these projects.

Comet - The Never-Ending Request
First we need a way to create message-driven Web applications that require the server to notify the client about server-side events. This is where Comet comes in as described by Wikipedia:
Comet is a programming technique that enables Web servers to send data to the client without having any need for the client to request it.

Comet provides the means for the server to initiate a response to a client request, and later send a message to that client using the same response ­ for example, in the browser a message will "just" appear. Comet also provides clients with a way to register interest in specific types of messages. When the server publishes a message, it's delivered only to clients that previously registered interest in that kind of message.

Comet doesn't solve everything; in fact it creates some new problems. Using Comet means lots of outstanding requests, ideally one per client, and introduces similar scalability issues at the server as the AJAX polling technique. Keeping a separate thread allocated for each open request will exhaust the server's resources, so for this model to work properly, the Web server has to handle multiple requests without allocating one thread per request.

Asynchronous Request Processing
The idea behind Asynchronous Request Processing (ARP) is to manage incoming servlet requests asynchronously. Rather than committing a separate Java thread to synchronously process each servlet request, a single thread leverages Java NIO to detect when new information needs to be written to the response of any outstanding request. This technique provides a huge scalability win for the Comet use case, giving excellent performance even when there are a large number of outstanding, mostly dormant, requests at the server.

Although there's no standard defined for ARP several teams and projects are providing ARP solutions, such as Jetty Continuations and Grizzly. We take our hats off to these visionary teams providing everyday developers with ARP and Comet solutions.

Note: There's hope that ARP will be standard in the Servlet 3.0 and Java EE 6 specifications.

The Comet Messaging Protocol
With Comet and ARP we now have the means to build message-driven Web applications but, as mentioned earlier, W3C recommends at most two active connections from the browser to the Web server at any one time. Therefore, we'd prefer to have a single active connection being used for Comet notifications, leaving the other connection free to download images, CSS, and JavaScript or communicate with the server. This requires a way to manage multiple logical channels of information over a single shared Comet notification response.


More Stories By Kaazing Blog

Kaazing is helping define the future of the event-driven enterprise by accelerating the Web for the Internet of Things.

More Stories By John Fallows

John brings to Kaazing his 17 years’ experience in technology development and software design, and is considered a pioneer in the field of rich and highly interactive user interfaces. As CTO he formulates Kaazing Corporation’s vision of enabling mobile users, marketplaces and machines to connect and communicate in real-time, more reliably and at unprecedented scale. He defines the architecture of the Kaazing product suite and oversees its development. Prior to co-founding Kaazing, John served as Architect for Brane Corporation, a startup company based in Redwood City, California. Before joining Brane, he was a Consulting Member of Technical Staff for Server Technologies at Oracle Corporation. During his last five years at Oracle, he focused on designing, developing, and evolving Oracle ADF Faces to fully integrate Ajax technologies. Originally from Northern Ireland, he received his MA in Computer Science from Cambridge University in the United Kingdom and has written several articles for leading IT magazines such as Java Developer’s Journal, AjaxWorld Magazine, and JavaMagazine (DE), and is a popular speaker at international conferences. He is co-author of the bestselling book Pro JSF and Ajax: Building Rich Internet Components (Apress).

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


CloudEXPO Stories
Cloud-Native thinking and Serverless Computing are now the norm in financial services, manufacturing, telco, healthcare, transportation, energy, media, entertainment, retail and other consumer industries, as well as the public sector. The widespread success of cloud computing is driving the DevOps revolution in enterprise IT. Now as never before, development teams must communicate and collaborate in a dynamic, 24/7/365 environment. There is no time to wait for long development cycles that produce software that is obsolete at launch. DevOps may be disruptive, but it is essential. DevOpsSUMMIT at CloudEXPO expands the DevOps community, enable a wide sharing of knowledge, and educate delegates and technology providers alike.
In a recent survey, Sumo Logic surveyed 1,500 customers who employ cloud services such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). According to the survey, a quarter of the respondents have already deployed Docker containers and nearly as many (23 percent) are employing the AWS Lambda serverless computing framework. It's clear: serverless is here to stay. The adoption does come with some needed changes, within both application development and operations. That means serverless is also changing the way we leverage public clouds. Truth-be-told, many enterprise IT shops were so happy to get out of the management of physical servers within a data center that many limitations of the existing public IaaS clouds were forgiven. However, now that we've lived a few years with public IaaS clouds, developers and CloudOps pros are giving a huge thumbs down to the...
Kubernetes is an open source system for automating deployment, scaling, and management of containerized applications. Kubernetes was originally built by Google, leveraging years of experience with managing container workloads, and is now a Cloud Native Compute Foundation (CNCF) project. Kubernetes has been widely adopted by the community, supported on all major public and private cloud providers, and is gaining rapid adoption in enterprises. However, Kubernetes may seem intimidating and complex to learn. This is because Kubernetes is more of a toolset than a ready solution. Hence it’s essential to know when and how to apply the appropriate Kubernetes constructs.
To enable their developers, ensure SLAs and increase IT efficiency, Enterprise IT is moving towards a unified, centralized approach for managing their hybrid infrastructure. As if the journey to the cloud - private and public - was not difficult enough, the need to support modern technologies such as Containers and Serverless applications further complicates matters. This talk covers key patterns and lessons learned from large organizations for architecting your hybrid cloud in a way that: Supports self-service, "public cloud" experience for your developers that's consistent across any infrastructure. Gives Ops peace of mind with automated management of DR, scaling, provisioning, deployments, etc.
xMatters helps enterprises prevent, manage and resolve IT incidents. xMatters industry-leading Service Availability platform prevents IT issues from becoming big business problems. Large enterprises, small workgroups, and innovative DevOps teams rely on its proactive issue resolution service to maintain operational visibility and control in today's highly-fragmented IT environment. xMatters provides toolchain integrations to hundreds of IT management, security and DevOps tools. xMatters is the primary Service Availability platform trusted by leading global companies and innovative challengers including BMC Software, Credit Suisse, Danske Bank, DXC technology, Experian, Intuit, NVIDIA, Sony Network Interactive, ViaSat and Vodafone. xMatters is headquartered in San Ramon, California and has offices worldwide.