XML

Automating scalability and high availability services

Lori MacVittie — Wed, 15 Oct 2008 12:37:16 GMT

There are a lot of SOA governance solutions out there that fall into two distinct categories of purpose: one is to catalog services and associated security policies and the other is to provide run-time management for services, including enforcement of security and performance-focused policies.

Vendors providing a full "SOA Stack" of functionality across the service lifecycle (design, development, testing, production) often integrate their disparate product sets for a more automated (and thus manageable) SOA infrastructure. But very few integrate those same products and functionality with the underlying network and application delivery infrastructure required to provide high-availability and scalability for those services.

The question should (and must) be asked: why is that?

Today's application delivery infrastructure, a.k.a. application delivery controllers and load-balancers, are generally capable of integration via standards-based APIs. These APIs provide complete control over the configuration and management of these platforms, making the integration of application delivery platforms with the rest of the SOA eco-system a definite reality.

Most registry/repository solutions today offer the ability of external applications to subscribe to events. The events vary from platform to platform, but generally include some commonalities such as "artifact published" or "item changed". This means a listening application can subscribe to these events and take appropriate action when an event occurs.

1. A new WSDL describing a service interface (hosted in the service application infrastructure) is published.

2. The listening application is notified of the event and retrieves the new or modified WSDL.

3. The application parses the WSDL and determines the appropriate endpoint information, then automatically configures the application delivery controller to (a) virtualize the service and (b) load balance requests across applicable servers.

4. The application delivery controller begins automatically load-balancing service requests and providing high-availability and scalability services.

There's some information missing that has to be supplied either via discovery, policy, or manual configuration. That's beyond the scope of this post, but would certainly be a part of the controlling application.

Conceptually, as long as you have (a) a service-enabled application delivery controller and (b) an application capable of listening for events in the SOA registry/repository, you can automate the process of provisioning high-availability and scalability services for those SOA services.

If you combine this with the ability to integrate application delivery control into the application itself, you can provide an even more agile, dynamic application delivery infrastructure than if you just used one concept or the other. And when you get right down to it, this doesn't just work for SOA, it could easily work just as well for any application framework, given the right integration.

There already exist some integration of application delivery infrastructure with SOA governance solutions, like AmberPoint, but there could be more. There could be custom solutions for your unique architecture as well, given that the technology exists to build it.

The question is, why aren't folks leveraging this integration capability to support initiatives like SOA and cloud computing that require a high level of agility and extensibility and upon which the ROI depends at least partially on the ability to reduce management costs and length of deployment cycles through automation?

It's true that there seems to be an increasing awareness of the importance of application delivery infrastructure to architecting a scalable, highly available cloud computing environment. But we never really managed to focus on the importance of an agile, reusable, intelligent application delivery infrastructure to the success of SOA.

Maybe it's time we backtrack a bit and do so, because many of the same architectural and performance issues that will arise in the cloud due to poor choices in application delivery infrastructure are the same as those that adversely impact SOA implementations.

Governance in the Cloud

Reliability does not come from SOA Governance

Building a Cloudbursting Capable Infrastructure

The Next Tech Boom: Infrastructure 2.0

Technorati Tags: MacVittie,F5,SOA,cloud computing,governance,iControl,automation,virtualization,application delivery,web services,internet,web,infrastructure

Silverlight 2.0 released, support for Eclipse included

Lori MacVittie — Tue, 14 Oct 2008 20:19:08 GMT

Silverlight, if you recall, appears to be Microsoft's answer to Adobe's AIR platform.

Microsoft released Silverlight 2.0 today, as expected. Part of the big exciting news is that you can now code up Silverlight applications in Eclipse. Yeah, not kidding. I know, you just hit weather.com too and checked to see what the temperature was. But seriously, Microsoft is fully supportive of the Eclipse environment for Silverlight despite its own support with its own free tool, Visual Web Developer Express. I haven't checked out the Eclipse version yet, so I'll be interested to see it and hear how well it competes with Visual Web Developer Express (which would admittedly be hard to do) in terms of developing with XAML.

You can read many of the juicy tips and find all the relevant links about the new version at Scott Hanselman's always excellent blog.

Need to learn XAML so you can make the most of Silverlight and get creating some cool apps?

Are you going to be at Dr. Dobb's SD Best Practices?

If you are, stop by the F5 booth and score a signed copy of XAML in a Nutshell.

And then ask us how we can secure, scale, and deliver Silverlight/XAML-based applications.

Technorati Tags: MacVittie,f5,dr. dobbs,sd best practices,adobe Flash,microsoft,silverlight,adobe AIR,XAML,XML,visual web developer express,security,scalability,application delivery,developers,Scott Hanselman,oreilly,XAML in a Nutshell

How Microsoft is bursting into the cloud with BizTalk

Lori MacVittie — Mon, 06 Oct 2008 10:29:05 GMT

Darren Jefford has an excellent (and detailed with code examples) post

Related Posts

regarding what could easily be categorized as cloudbursting with BizTalk workflows.

In a nutshell, Microsoft allows hosting of BizTalk activities in the cloud at BizTalk labs. Developers then integrate those cloud hosted activities into a BizTalk workflow (orchestration) by calling them as they would any other web-based service or hosted activity.

In doing so, Microsoft is essentially allowing developers to extend the compute capacity of their data centers by leveraging the much larger data centers maintained by Microsoft.

The Three "Itys" of Cloud Computing

Bursting the Cloud

Building a cloudbursting capable infrastructure

4 things you need in a cloud computing infrastructure

What is an activity?

An activity is a discrete step in a business process (workflow). Activities range from calling a remote service to perform a task, e.g. calculating taxes, performing currency conversions, looking up inventory, to custom-defined services.

Activities are orchestrated together together a workflow in BizTalk using XOML (eXtensible Object Markup Language).

In other BPM (Business Process Management) solutions, activities are orchestrated using BPEL (Business Process Execution Language).

Both XOML and BPEL are XML-based markup languages used for orchestrating workflows.

BPEL is an industry standard; XOML is Microsoft's propriety solution.

How Microsoft BizTalk workflows take advantage of cloud-based activities

While the first definitions of cloudbursting are focused on reactive capacity management, Microsoft appears to be taking a proactive approach to cloudbursting and capacity management. By encouraging developers to utilize the compute capacity of BizTalk labs up front during the design and development process, it alleviates the need to react hastily later when it becomes apparent that more compute resources are necessary for a specific workflow activity.

The concept remains the same: utilize the cloud for additional capacity when it is apparent your own data center can't handle the load and it is cost-prohibitive to invest in additional servers and infrastructure to increase capacity.

One can easily imagine that future offerings might include the ability of other organizations to subscribe to and use activities developed by third-parties, essentially offering yet another path to monetize the cloud.

Technorati Tags: MacVittie,F5,cloud computing infrastructure,cloudbursting,BizTalk,Microsoft,BPEL,BPM,workflow,XOML,cloud computing,internet,web

Why it's so hard to secure JavaScript

Lori MacVittie — Fri, 12 Sep 2008 11:49:44 GMT

The discussion yesterday on JavaScript and security got me thinking about why it is that there are no good options other than script management add-ons like NoScript for securing JavaScript.

In a compiled language there may be multiple ways to write a loop, but the underlying object code generated is the same. A loop is a loop, regardless of how it's represented in the language. Security products that insert shims into the stack, run as a proxy on the server, or reside in the network can look for anomalies in that object code. This is the basis for many types of network security - IDS, IPS, AVS, intelligent firewalls. They look for anomalies in signatures and if they find one they consider it a threat.

While the execution of a loop in an interpreted language is also the same regardless of how it's represented, it looks different to security devices because it's often text-based as is the case with JavaScript and XML. There are only two good options for externally applying security to languages that are interpreted on the client: pattern matching/regex and parsing.

Pattern matching and regular expressions provide minimal value for securing client-side interpreted languages, at best, because of the incredibly high number of possible combinations of putting together code.

Where's F5?

VMWorld
Sept 15-18 in Las Vegas
Storage Decisions
Sept 23-24 in New York
Networld IT Roadmap
Sept 23 in Dallas
Oracle Open World
Sept 21-25 in San Francisco
Storage Networking World
Oct 13-16 in Dallas
Storage Expo 2008 UK
Oct 15-16 in London
Storage Networking World
Oct 27-29 in Frankfurt

As we learned from preventing SQL injection and XSS, attackers are easily able to avoid detection by these systems by simply adding white space, removing white space, using encoding tricks, and just generally finding a new permutation of their code.

Parsing is, of course, the best answer. As 7rans noted yesterday regarding the Billion More Laughs JavaScript hack, if you control the stack, you control the execution of the code. Similarly, if you parse the data you can get it into a format more akin to that of a compiled language and then you can secure it. That's the reasoning behind XML threat defense, or XML firewalls. In fact, all SOA and XML security devices necessarily parse the XML they are protecting - because that's the only way to know whether or not some typical XML attacks, like the Billion Laughs attack, are present.

But this implementation comes at a price: performance. Parsing XML is compute intensive, and it necessarily adds latency. Every device you add into the delivery path that must parse the XML to route it, secure it, or transform it adds latency and increases response time, which decreases overall application performance. This is one of the primary reasons most XML-focused solutions prefer to use a streaming parser. Streaming parser performance is much better than a full DOM parser, and still provides the opportunity to validate the XML and find malicious code. It isn't a panacea, however, as there are still some situations where streaming can't be used - primarily when transformation is involved.

We know this already, and also know that JavaScript and client-side interpreted languages in general are far more prolific than XML. Parsing JavaScript externally to determine whether it contains malicious code would certainly make it more secure, but it would also likely severely impact application performance - and not in a good way. We also know that streaming JavaScript isn't a solution because unlike an XML document, JavaScript is not confined. JavaScript is delimited, certainly, but it isn't confined to just being in the HEAD of an HTML document. It can be anywhere in the document, and often is.

Worse, JavaScript can self-modify at run-time - and often does. That means that the security threat may not be in the syntax or the code when it's delivered to the client, but it might appear once the script is executed. Not only would an intermediate security device need to parse the JavaScript, it would need to execute it in order to properly secure it.

While almost all web application security solutions - ours included - are capable of finding specific attacks like XSS and SQL injection that are hidden within JavaScript, none are able to detect and prevent JavaScript code-based exploits unless they can be identified by a specific signature or pattern. And as we've just established, that's no guarantee the exploits won't morph and change as soon as they can be prevented.

That's why browser add-ons like NoScript are so popular. Because JavaScript security today is binary: allow or deny. Period. There's no real in between. There is no JavaScript proxy that parses and rejects malicious script, no solution that proactively scans JavaScript for code-based exploits, no external answer to the problem. That means we have to rely on the browser developers to not only write a good browser with all the bells and whistles we like, but for security, as well.

I am not aware of any security solution that currently parses out JavaScript before it's delivered to the client. If there are any out there, I'd love to hear about them.

Technorati Tags: MacVittie,F5,web application security,security,XML firewall,JavaScript,parserss,interpreted languages,XML,XSS,SQL injection

A Billion More Laughs: The JavaScript hack that acts like an XML attack

Lori MacVittie — Thu, 11 Sep 2008 11:01:27 GMT

Don is off in Lowell working on a project with our ARX folks so I was working late last night (finishing my daily read of the Internet) and ended up reading Scott Hanselman's discussion of threads versus processes in Chrome and IE8. It was a great read, if you like that kind of thing (I do), and it does a great job of digging into some of the RAMifications (pun intended) of the new programmatic models for both browsers.

But this isn't about processes or threads, it's about an interesting comment that caught my eye:

This will make IE8 Beta 2 unresponsive

<div id="test"></div>
..
t = document.getElementById("test");
while(true)
{
  t.innerHTML += "a";
}

What really grabbed my attention is that this little snippet of code is so eerily similar to the XML "Billion Laughs" exploit, in which an entity is expanded recursively for, well, forever and essentially causes a DoS attack on whatever system (browser, server) was attempting to parse the document.

What makes scripts like this scary is that many forums and blogs that are less vehement about disallowing HTML and script can be easily exploited by a code snippet like this, which could cause the browser of all users viewing the infected post to essentially "lock up". This is one of the reasons why IE8 and Chrome moved to a more segregated tabbed model, with each tab basically its own process rather than a thread - to prevent corruption in one from affecting others. But given the comment this doesn't seem to be the case with IE8 (there's no indication Chrome was tested with this code, so whether it handles the situation or not is still to be discovered).

This is likely because it's not a corruption, it's valid JavaScript. It just happens to be consuming large quantities of memory very quickly and not giving the other processes in other tabs in IE8 a chance to execute.

The reason the JavaScript version was so intriguing was that it's nearly impossible to stop. The XML version can be easily detected and prevented by an XML firewall and most modern XML parsers can be configured to stop parsing and thus prevent the document from wreaking havoc on a system. But this JavaScript version is much more difficult to detect and thus prevent because it's code and thus not confined to a specific format with specific syntactical attributes. I can think of about 20 different versions of this script - all valid and all of them different enough to make pattern matching or regular expressions useless for detection. And I'm no evil genius, so you can bet there are many more.

The best option for addressing this problem? Disable scripts.

The conundrum is that disabling scripts can cause many, many sites to become unusable because they are taking advantage of AJAX functionality, which requires...yup, scripts. You can certainly enable scripts only on specific sites you trust (which is likely what most security folks would suggest should be default behavior anyway) but that's a PITA and the very users we're trying to protect aren't likely to take the time to do this - or even understand why it's necessary.

With the increasing dependence upon scripting to provide functionality for RIAs (Rich Interactive Applications) we're going to have to figure out how to address this problem, and address it soon. Eliminating scripting is not an option, and a default deny policy (essentially whitelisting) is unrealistic.

Perhaps it's time for signed scripts to make a comeback.

Technorati Tags: MacVittie,F5,ARX,ASM,XML firewall,AJAX,JavaScript,billion laughs,exploits,digital signatures,RIA,IE8,Chrome,threads,processes,Scott Hanselman,security,Web 2.0,web,http,internet

How AJAX can make a more agile enterprise

Lori MacVittie — Tue, 02 Sep 2008 10:50:54 GMT

In general, we talk a lot about the benefits of SOA in terms of agility, aligning IT with the business, and risk mitigation. Then we talk about WOA (web oriented architecture) separately from SOA (service oriented architecture) but go on to discuss how the two architectures can be blended to create a giant application architecture milkshake that not only tastes good, but looks good.

AJAX (Asynchronous JavaScript and XML) gets lumped under the umbrella of "Web 2.0" technologies. It's neither WOA nor SOA, being capable of participating in both architectural models easily. Some might argue that AJAX, being bound to the browser and therefore the web, is WOA. But WOA and SOA are both architectural models, and AJAX can participate in both - it is neither one or the other.

It's seen as a tool; a means to an end, rather than as an enabling facet of either architectural model. It's seen as a mechanism for building interactive and more responsive user interfaces, as a cool tool to implement interesting tricks in the browser, and as yet another cross-browser incompatible scripting technology that makes developer's lives miserable.

But AJAX, when used to build enterprise applications, can actually enable and encourage a more agile application environment. When AJAX is applied to user-interface elements to manipulate corporate data the applications or scripts on the server-side that interact with the GUI are often distilled into discrete blocks of functionality that can be reused in other applications and scripts in which that particular functionality is required.

And thus services are born. Services that are themselves agile and thus enable broader agility within the application architecture. They aren't SOA services, at least that's what purists would say, but they are services, empowered with the same characteristics of their SOA-based cousins: reusable and granular.

The problem is that AJAX is still seen as an allen wrench in an architecture that requires screwdrivers. It's often viewed only in terms of building a user interface, and the services it creates or takes advantage of on the back-end as being unequal to those specifically architected for inclusion in the enterprise SOA.

Because AJAX drives the development of discrete services on the server-side, it can be a valued assistant in decomposing applications into its composite services. It can force you to think about the services and the operations required because AJAX necessarily interacts with granular functions of a service in a singular fashion.

If we force AJAX development to focus on the user-interface, we lose some of the benefits we can derive from the design and development process by ignoring how well AJAX fits into the service-oriented paradigm. We lose the time and effort that goes into defining the discrete services that will be used by an AJAX-enabled component in the user-interface, and the possibility of reusing those services in the broader SOA.

An SOA necessarily compels us to ignore platform and language and concentrate on the service. Services deployed on a web server utilizing PHP or ASP or Ruby as their implementation language are no different than those deployed on heavy application servers using JSP or Java or .NET. They can and should be included in the architectural design process to ensure they can be reused when possible.

AJAX forces you to think in a service-oriented way. The services required by an AJAX-enabled user-interface should be consistent with the enterprise's architectural model and incorporated into that architecture whenever possible in order to derive agility and reuse from those services.

AJAX is inherently an agile technology. Recognizing that early and incorporating the services required by AJAX-enabled components can help build a more agile, more consistent, more SOA-like application infrastructure.

Technorati Tags: MacVittie,F5,SOA,AJAX,PHP,ASP,Ruby,JSP,Java,.NET,agile,reuse,user-interface,services,internet,web,http,architecture,application infrastructure,Web 2.0

Layer 7 Switching + Load Balancing = Layer 7 Load Balancing

Lori MacVittie — Tue, 12 Aug 2008 11:44:57 GMT

Modern load balancers (application delivery controllers) blend traditional load-balancing capabilities with advanced, application aware layer 7 switching to support the design of a highly scalable, optimized application delivery network. Here's the difference between the two technologies, and the benefits of combining the two into a single application delivery controller.

LOAD BALANCING

Load balancing is the process of balancing load (application requests) across a number of servers. The load balancer presents to the outside world a "virtual server" that accepts requests on behalf of a pool (also called a cluster or farm) of servers and distributes those requests across all servers based on a load-balancing algorithm. All servers in the pool must contain the same content.

Load balancers generally use one of several industry standard algorithms to distribute request. Some of the most common standard load balancing algorithms are:

round-robin
weighted round-robin
least connections
weighted least connections

Load balancers are used to increase the capacity of a web site or application, ensure availability through failover capabilities, and to improve application performance.

LAYER 7 SWITCHING

Layer 7 switching takes its name from the OSI model, indicating that the device switches requests based on layer 7 (application) data. Layer 7 switching is also known as "request switching", "application switching", and "content based routing".

A layer 7 switch presents to the outside world a "virtual server" that accepts requests on behalf of a number of servers and distributes those requests based on policies that use application data to determine which server should service which request. This allows for the application infrastructure to be specifically tuned/optimized to serve specific types of content. For example, one server can be tuned to serve only images, another for execution of server-side scripting languages like PHP and ASP, and another for static content such as HTML , CSS , and JavaScript.

Unlike load balancing, layer 7 switching does not require that all servers in the pool (farm/cluster) have the same content. In fact, layer 7 switching expects that servers will have different content, thus the need to more deeply inspect requests before determining where they should be directed. Layer 7 switches are capable of directing requests based on URI, host, HTTP headers, and anything in the application message.

The latter capability is what gives layer 7 switches the ability to perform content based routing for ESBs and XML/SOAP services.

LAYER 7 LOAD BALANCING

By combining load balancing with layer 7 switching, we arrive at layer 7 load balancing, a core capability of all modern load balancers (a.k.a. application delivery controllers).

Layer 7 load balancing combines the standard load balancing features of a load balancing to provide failover and improved capacity for specific types of content. This allows the architect to design an application delivery network that is highly optimized to serve specific types of content but is also highly available.

Layer 7 load balancing allows for additional features offered by application delivery controllers to be applied based on content type, which further improves performance by executing only those policies that are applicable to the content. For example, data security in the form of data scrubbing is likely not necessary on JPG or GIF images, so it need only be applied to HTML and PHP.

Layer 7 load balancing also allows for increased efficiency of the application infrastructure. For example, only two highly tuned image servers may be required to meet application performance and user concurrency needs, while three or four optimized servers may be necessary to meet the same requirements for PHP or ASP scripting services. Being able to separate out content based on type, URI, or data allows for better allocation of physical resources in the application infrastructure.

Technorati Tags: MacVittie,F5,load-balancing,layer 7 switching,application delivery,application switching,SOA,XML,SOA delivery,clustering

Honey? Does this format make my data look fat?

Lori MacVittie — Wed, 09 Jul 2008 11:31:53 GMT

CNet is reporting that Google is ditching XML for a faster, more compact alternative known as ProtocolBuffers. I'm going to type this post really fast before Don finds out and starts laughing at me because he's always had this thing against XML, claiming it was too bloated and slow.

Apparently Google, the 800-pound gorilla, is on Don's side of this argument, as it just blogged about its newest creation, ProtocolBuffers.

From CNet's Blog PostGoogle thought of using XML as a lingua franca to send messages between its different servers. But XML can be complicated to work with and, more significantly, creates large files that can slow application performance.

I disagree with the statement that it is XML that creates large files. No, no it's not. It's people that create large files in a data format, and that can happen regardless of whether it's binary or not. If you've ever worked in digital cartography or drafting, then you know what I'm talking about. AutoCAD files are huge, and they're binary. It's the application and the people designing the application combined with the amount of data that's being stored or transferred that determines whether a file will end up large or small. While binary is almost always more compact and more efficient than XML, it isn't always the case, nor is it inevitable that XML files will end up large and bloated.

Bad code can be just as inefficient and slow and bloated as inefficient use of a data format. I'm not saying Google's engineers have written bad code or that they are going to write bad code. In fact they probably won't given their track record. But blaming poor performance on a data format is like blaming poor car performance on the car's frame. There's just too many other factors that go into application performance to single out a data format. Network conditions, server load, server platform, coding techniques, etc... can all impact the performance of an application positively and negatively.

While it's certainly likely that Google will see an improvement in performance by moving to its new data exchange format, it's going to be losing at the same time. It's losing the simple integration and interoperability that comes from a standards-based technology like XML. We've been moving away from EAI-like technology that requires coding and development to integrate applications since the advent of SOA, so it's surprising to see such a services-oriented organization like Google move back into the dark ages of integration with this decision. XML became the lingua-franca of integration because it's much easier to integrate into a meta-data driven architecture, which is really one of the foundational pillars of Web 2.0 and SOA.

I will admit that ProtocolBuffers are intriguing and that given the performance needs of an organization like Google it very well may be necessary for it to move away from XML due at least in part to the performance of modern parsers to something more processor efficient, which certainly sounds like ProtocolBuffers. But it's the rare organization that needs that kind of speed and, for the most part, XML will continue to suit the majority of folks just fine.

Technorati Tags: MacVittie,F5,Google,XML,ProtocolBuffers,integration,EAI,binary,web,server

We iz in ur networkz, deep inspecting ur XML packetz. Wait, what?

Lori MacVittie — Thu, 22 May 2008 19:12:03 GMT

A recent article discussing the recent challenges to enterprise service bus (ESB) products by XML/SOA gateway products contained a sentence that I found extremely puzzling.

Puzzling sentence

...the technology behind both solution-sets is based on deep XML packet visibility and manipulation capabilities.

I know what the author was trying to say, but this sentence really is full of epic fail. "Packet" visibility is even more irrelevant to XML than it is for HTML or any other application layer protocol, for that matter.

The problem with putting "XML" and "packet" together is that application layer data is almost never contained within any single packet, and if you're going to interpret, act on, or manipulate the actual application messages (i.e. the XML, the HTML, the application protocol) then you have to assemble the packets into a document or message first.

"Packet" level visibility is a term used to describe network devices like routers, switches, traditional firewalls and network drivers. These types of products work on a packet-processing level; they look at individual packets, at the IP and TCP characteristics contained within the headers, and little more. Packet-processing devices aren't designed to provide "deep" visibility into application layer protocols because they aren't designed to reassemble the documents and messages.

Packet processing is to delivering applications what fingers are to an individual. Having just one means you might be able to identify the person/application, but you don't *know* anything else about either. Basically, there may be some amount of application data that is valuable in any given packet that might be of limited use, say in identification of application type for rate shaping / classification purposes. This is often what's behind the use of the term "deep packet inspection" as it relates to applications. Identification.

In the context of any network-positioned device, like an XML or SOA gateway, an application delivery controller, or an XML firewall, visibility and processing must necessarily be at the application layer. The contents of any single given packet are irrelevant and, in the case of XML, practically useless.

XML must be parsed and put into a format which can be interpreted by a machine, and that means that it must be reassembled first. While "streaming" parsers appear to do this on a per-packet basis that is not completely accurate, for it is often the case that a specific element will be nested deep enough and be large enough to span two packets, which breaks the packet-processing model completely. Streaming simply means that the XML is being interpreted as the document is being reassembled; the document is still being viewed as application data, not necessarily individual packets.

What the author was trying to convey the sense that XML & SOA gateways are capable of reassembling XML documents and processing them, providing security and routing and message enrichment functionality just like an ESB, because though they are "network" devices, they are also full-proxies.

But that's not "deep XML packet inspection", or even just "deep packet inspection". That's flow or even message-based processing, not packet processing. The terms "packet inspection" and "[insert application layer protocol here]" should never be used concurrently in the same sentence.

Unless you're trying to explain why it is that packet processing is teh fail when it comes to true visibility into and manipulation of application messages.

Imbibing: Water

Technorati Tags: MacVittie,F5,XML,packet-processing,message based processing,full proxy,SOA

Accelerating AJAX

Lori MacVittie — Tue, 20 May 2008 11:36:38 GMT

If you've ever used the quite popular Prototype framework, you've noticed that there are some unique options available that are designed to help reduce the number of connections made to the server when automatically updating specific content. The decay rate in Prototype's PeriodicalUpdater is designed to help reduce the number of requests made to the server when content is not refreshing on every request.

Ajax.PeriodicalUpdater("content-id", "url", { frequency: 10, decay: 2, method: 'get'} )

This code will start making a call to url and updating content-id every 10 seconds. If the content hasn't changed, decay will be used to increase the update interval, essentially doubling the time between calls until the content has changed, at which time the interval is reset to its original value and the process begins again.

I point this out because it's an attempt to ameliorate the problems inherent with making continuous requests for content including the additional burden on the server of maintaining a connection. Maintaining the connection requires the maintenance of a session on the server, which consumes resources and may impact the total capacity of that server.

One would think that by increasing the interval when content is not changing would decrease the burden on the server, but that's not entirely true. At some point the interval between requests becomes high enough that a new connection will be necessary and the burden changes from maintaining a session to opening/closing a TCP/IP connection and creating a new session on the server.

Basically, the solution is a good effort, but it still places a burden on the server. Combining this partial solution with an application delivery network that combines connection optimization and web application acceleration technology such as dynamic caching will complete the solution. The web application acceleration solution alleviates the burden on the server when the content hasn't changed, thus making Prototype's solution even more efficient, and is smart enough to know when to revalidate the content it's caching.

The connection optimization features of the application delivery controller ensure that the server isn't overwhelmed at any time by excessive requests, even if the content is changing every second and requires processing on the server, by mediating client requests and managing the connections to the server.

Not using Prototype but still want to get the benefits of dynamically updating intervals? An application delivery controller can help you there, too, if it's smart enough to be a platform on which you can programmatically manipulate content in requests and responses. This post explains how to use iRules and a BIG-IP to dynamically adjust the AJAX update interval for requests.

Imbibing: Coffee

Technorati Tags: MacVittie,F5,BiG-IP,application acceleration,application delivery,prototype.js,AJAX,Web 2.0,caching,connection management,development