SOA+WOA=NOA

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