Mainstream adoption and implementation of SOA is rapidly approaching critical mass.

As Microsoft continues to release SOA-enabled platforms like Vista, Longhorn, Office 2007, and BizTalk, the availability of services within your environment continues to explode. Your SOA implementation can now take advantage of a wealth of services offered not only by your diligent development efforts, but by the underlying platforms themselves. Its an exciting time for developers, but theres something missing: a rich, interactive user-interface that takes advantage of the services offered by your SOA implementation.

Analysts have recently coined the term WOA (Web oriented architecture) as an all-encompassing acronym that describes the explosion of Web 2.0 technologies forming the foundation for deploying RIAs (rich interactive applications). Whether youve adopted Vistas new markup language XAML or discovered the world of AJAX with Microsofts ASP.NET AJAX, youve discovered WOA and the benefits of pairing Web 2.0 with SOA to enable rapid development of new applications that address the volatile business environment of todays Internet.

Its unlikely that you anticipated the resulting stress on the network, however, and have now discovered yet another TLA: NOA (network oriented angst). Its purely coincidental, of course, that this acronym, when spoken rapidly, is the same sound that network administrators and developers make when discovering the effects of the explosion of traffic and connections arising from the combination of WOA and SOA deployments.

The introduction of WOA as the primary mechanism for building out the client-facing portion of a SOA application has completed the end-to-end equation. Unfortunately, the two architectural styles combined can incur serious performance penalties that may dampen the initial excitement over this new breed of application.

Making Your Connections
The most obvious impact on the network of deploying a WOA application is the rate and size of requests exchanged between the browser and the server. An application that, when developed in a page-centric paradigm, had a predictable usage pattern suddenly balloons into a quagmire of unpredictable requests. Instead of the user following a designated flow through the application, they are suddenly clicking around, loading data willy nilly, while under the covers the browser is doing its own thingupdating RSS feeds and live data while simultaneously handling the increase in user initiated requests for more data.

This increase in requests has a deleterious effect on your application infrastructure. The server that once managed to service thousands of concurrent users is suddenly only able to service a fraction of its former capacity. The network is clogged with three or four times the amount of traffic, giving the server and intermediate delivery infrastructure that bloated sensation that comes from handling just one more request.

The server slows down. Taxed with managing more connections, more often, the overhead of setting up and tearing down TCP sessions combined with the actual work of serving the requests is chewing up resources faster than a kid eats an ice-cream. The browser, ever concerned about the server, starts sending out concerned queries about the status of its last request. The additional TCP retransmited begins to cause additional congestion on the network as intermediary devices try to keep the traffic flowing as smoothly as possible.

Your network performance suddenly seems like a typical afternoon at Chicago OHare. Congestion. Delays. Cancellations.

And then your application starts missing connections. Timeouts on the server caused by the overload of requests and congestion on the network cause real-time updates to simply stop updating. Requests generated by the user are suddenly lost in the ether or take forever to return, resulting in performance problems with your application and causing acceptance of your new WOA application to plummet.

You and the network team scramble to find the answer, and then realize that youve all been afflicted with the same thing. Youve all got NOA.

The Cure
Luckily there are several cures for NOA, but the one best suited to your environment, application infrastructure, and budget is heavily dependent upon a number of factors, all of which are unique to your organization. One aspect of the cure that is common to all organizations is that it will require coordination between you, the server, and network administrators. This collaboration is increasingly important in the world of WOA and SOA as the factors that affect application performance are increasingly distributed across disparate areas of expertise.

Performance Tuning: As is sometimes the case, a few tweaks of your application server may solve the issues inherent with deploying Web 2.0 applications. Increase the TCP timeout value to be in-line with the rate of requests coming from your client. Check the Connection Timeout in IIS and make sure its set higher than the anticipated request rate. This will reduce the number of connections that time-out due to network congestion and will further reduce the overhead of initiating TCP connections as existing connections can be reused.

Increase Browser Connections: Depending on your level of control over the browser, you can manually modify the configuration imposed limits on the number of simultaneous connections allowed by the browser. This requires a registry edit for Internet Explorer, so if your primary users are consumers this may not be an acceptable option. Increasing the number of connections available from the browser will remove the delays introduced by the client waiting for an available connection over which it can make a request.

Deploy an application delivery network solution: These network-deployed devices are designed to efficiently manage connections for all types of web-based applications. With a plethora of options to choose from, these devices can not only clear up your connection problems, but provide additional benefits such as security, acceleration, compression, and optimization of applications, all of which will severely reduce and even eliminate the possibility of a recurrence of NOA.

If youre already experiencing the effects of NOA, consider the options above. If youre concerned about preventing NOA in your organization altogether, consider deploying an application delivery network solution before you deploy your WOA-based application to ensure a smooth deployment and to reduce the possibility of catching a nasty case of NOA. As grandma said, an ounce of prevention is worth a pound of cure.

Lori MacVittie
The author is Technical Marketing Manager, F5 Networks
maildqindia@cybermedia.co.in

Page(s)   1