AJAX stands for Asynchronous JavaScript And XML. AJAX is a web development technique used for creating interactive web applications. AJAX is the logical next step in the services-oriented architecture revolution. With AJAX, user interfaces from within the browser can use web services as their data source to store and retrieve information. Asynchronous JavaScript and XML is not a technology in itself, but is a term that describes a "new" approach to using a number of existing technologies together, including: HTML or XHTML, Cascading Style Sheets, JavaScript, The Document Object Model, XML, XSLT, and the XMLHttpRequest object. When these technologies are combined in the AJAX model, web applications are able to make quick, incremental updates to the user interface without reloading the entire browser page. This makes the application faster and more responsive to user actions. AJAX is said to be quicker at Internet use. AJAX technology allows a web page to request data from a server without refreshing the whole page, making it possible to update only parts of a web page. This should generally result in smother, faster page loading.
Compare Bargains on AJAX Programming
ASP.NET AJAX. (Microsoft®), ASP.NET AJAX is a set of technologies to add AJAX (Asynchronous JavaScript And XML) support to ASP.NET. It consists of a client-side script framework, server controls, and more. More ASP links.
How To Use AJAX Patterns. Design patterns make development more efficient by speeding up common programming processes and eliminating the need to write redundant code across multiple projects. AJAX design patterns are emerging with the increased popularity of its use in Web application development. In this article, I'll focus on a few patterns that are specific to AJAX development.
Ajax Web Programming Ajax Web Programming Forum
AJAX Developer Resource Center From SDN - The Source for Sun Developer Solutions
Build Your Own AJAX Web Applications. By Matthew Eernisse.Doloto is an AJAX application optimization tool, especially useful for large and complex Web 2.0 applications that contain a lot of code, such as Bing Maps, Hotmail, etc. Doloto analyzes AJAX application workloads and automatically performs code splitting of existing large Web 2.0 applications. After being processed by Doloto, an application will initially transfer only the portion of code necessary for application initialization.
Internet Explorer 8: Ajax (Videos) More Browser links
Adobe AIR lets developers use their existing web development skills in HTML, AJAX, Flash and Flex to build and deploy rich Internet applications to the desktop.
Web Design References (Covers most Web stuff, CSS, etc)
TurboGears Features: easy-to-use, database-driven, easy Ajax and designer- and programmer-friendly.
jQuery is a fast, concise, JavaScript Library that simplifies how you traverse HTML documents, handle events, perform animations, and add Ajax interactions to your web pages.
Latest News from AJAX & RIA Journal Scaling applications that include AJAX and non-AJAX components may require more than just tuning your web server A common problem after deploying a Web 2.0 AJAX-based application shows itself through poor performance or lower capacity on the server, often both. Web serving tuning is almost always the first step in improving performance and capacity, but the inherently competing behavior of AJAX-requests and “normal” HTTP requests quickly becomes problematic as well. Tune for the AJAX requests and performance of regular old HTTP requests suffers. Tune for regular old HTTP requests, and performance of AJAX-requests suffer. This is primarily because of the way in which the client-side application, the browser, interacts with the server. “Regular old HTTP requests” are typically those that GET a piece of content, static or dynamic, and that’s it. There may be many of these requests whenever a page (URI) is requested – all the images, client-side scripting files, style sheets, etc… – but they are not interactive. The browser requests them, receives them, and that’s it. AJAX-based requests, however, are inherently interactive. They are often automatically refreshed on an ongoing basis, on a prescheduled interval, or invoked by the user as they interact with the application. These requests are not “load and forget” like their traditional staticesque counterparts, but rather they are expected to be made often. The overhead associated with opening and closing connections is well understood, and it is often the case that the web server configuration will be adjusted to meet the more demanding nature of the AJAX-based requests in an application. This is often accomplished by ensuring the KeepAlive setting (in Apache) is “on” and that the KeepAliveTimeout (in Apache) is high enough that AJAX-based requests occur before the timeout closes the connection. This allows the continued reuse of an existing connection between the browser and the server and improves performance. But it also ties up resources on the server keeping that connection open, which reduces the overall capacity of the server in terms of its ability to serve users. Optimally a short KeepAliveTimeout, if any, is best for non-interactive requests and often disabling KeepAlive actually improves performance for non-interactive applications. Obviously these two behaviors are completely at odds with one another. There are a number of ways in which the competing needs and interests of the interactive (AJAX) and non-interactive portions of your web application can be addressed. 2. A second means of addressing the problem of resource depletion and performance with AJAX-based applications is to use a load balancing solution to mediate for the clients and employ the use of TCP multiplexing on the server-side to optimize resources. Because a load balancer is almost certainly capable of simultaneously handling a significantly higher 3. A third solution might be found in scaling up (beefier hardware) and leveraging virtualization. For web applications, specifically, it may be the case that virtualization of the application will actually improve performance. This is particularly true of I/O intensive web applications, but is also likely true of high-connection oriented applications as well. This is because as a web server begins to reach its capacity in terms of connections it requires more processing to “find” a given connection. Nearly all TCP-based applications exhibit similar performance characteristics and, upon reaching a certain threshold of connections, performance degrades. By finding the “sweet spot” ,i.e. the highest number of connections that retains acceptable user response time, and deploying multiple instances of that application, each tuned for that upper bound, it may be possible to squeeze out better performance and higher capacity of your web applications. Multiple instances will require a proxy, i.e. load balancing, solution as well, but this would allow for a “scale up” solution that takes advantage of a single, beefy physical server that eliminates the IT management and maintenance overhead of additional hardware in the data center. In all three cases the solution to the problem of competing resource utilization between interactive and non-interactive components of a web application involve architecture. Some might believe that simply moving the application to “the cloud” would address the problems and, in some ways, it will. Cloud computing environments can indeed be managed such that applications are automatically scaled out to maintain performance and increase capacity, but the interesting thing about that is the environments are essentially implementing a combination of the three solutions heretofore presented. The bad news is that such a solution does not optimize resource utilization, and thus the costs associated with a cloud computing solution to the problem may be surprising and even prohibitive depending on your IT budget. And the cloud computing solution, of course, is ultimately also about architecture, as it is the architecture that allows for automated scalability. In most cases involving web applications the answer to scalability challenges is going to end up being architecture, and that architecture is increasingly requiring the use of application network components such as load balancers to implement. This is why it is often advised that applications are architected to take advantage of application networking components from the beginning, even if such solutions will not be necessary to address capacity and optimization on day one. By architecting a solution that includes application networking as part of its design and deployment model, there is far less disruption later when such a solution does become necessary. Related blogs & articles: Latest News from AJAX & RIA Journal


1. Configure two different servers: one to serve interactive content, i.e. AJAX-based requests, and one to serve non-interactive requests, i.e. everything else. This way, each server can be specifically tuned (and sized) according to the application behavior. This is beneficial for several reasons, including the ability to “scale out/up” only the interactive-serving functions when or if it becomes necessary. This can be achieved simply by using specific host names for specific requests. If you do not have a public IP address that can be assigned to each host, however, you’ll need a proxy, like a Load balancer, to sit in front of the servers and handle the direction of requests appropriately or you could use mod_rewrite to achieve a similar architecture. When a mediating solution like a load balancer is used to implement this solution, there are a several ways to achieve the behavior. One method is to rewrite requests directed at a specific URI, for example: http://www.example.com/ajax/request1.php would be redirected to the server designated as the “interactive” server while other requests would be forwarded to the non-interactive server. An application aware load balancer, i.e. application delivery controller, can examine the request itself and base the same decision on the actual data being exchanged. For example, many AJAX frameworks (XAJAX, SAJAX, Prototype, etc…) often use the HTTP POST method to send a request and use specific parameters such as “xjxfun” to indicate which function is being invoked on the server side. By examining the data being exchanged an application aware proxy (load balancer) can use that information to send the request to the appropriate server.
volume of connections than a single web server, the competing behavior of interactive and non-interactive HTTP requests in a web application do not impede performance or impact its capacity. By allowing a load balancer to mediate for those requests, it can better manage the resources on the server and ensure that both capacity and performance are maintained. For every X client connections, the load balancer maintains only a fraction of X connections to the server and reuses them as the means to optimizing the server-side resources. This method is actually likely to increase overall capacity because it will reduce the number of connections required to be in use at any given time on the server(s) and eliminates the performance overhead associated with opening and closing TCP connections.
Perhaps the simplest example to see this in action is the case of JavaScript being disabled in the browser - this is occasionally true for certain corporate clients concerned about security, and sometimes the case for very old browsers.
JSF handles this usecase pretty well - consider the following code:
1
2 <f:ajax render="grace :text">
3 <h:selectBooleanCheckbox value="#{grace.checked}"/>
4 </f:ajax>
This creates a checkbox input with an onclick event handler registered. If there’s no JavaScript enabled, it will continue to function as thought the ajax tag wasn’t there at all. But the user will need to submit the form with a button press...
There is another way to handle this: we could instead create a link, which uses view parameters:
1 <f:metadata>
2 <f:viewParam name="checked" value="#{grace.checked}"/>
3 </f:metadata>
4 <h:link value="check me">
5 <f:param name="checked" value="#{!grace.checked}"/>
6 </h:link>
That works, but isn’t as clean looking as the first, ajax method. Combining these approachs should provide a better user experience - and doing so isn’t especially difficult:
1 <f:metadata>
2 <f:viewParam name="checked" value="#{grace.checked}"/>
3 </f:metadata>
4 <h:outputText id="text" value="Checked: #{grace.checked}"/>
5 <h:form id="form">
6 <h:panelGroup id="grace" layout="block">
7 <h:panelGroup id="default">
8 <h:link value="check me">
9 <f:param name="checked" value="#{!grace.checked}"/>
10 </h:link>
11 </h:panelGroup>
12 <h:panelGroup id="enhanced" style="display: none">
13 <f:ajax render="grace :text">
14 <h:selectBooleanCheckbox value="#{grace.checked}"/>
15 </f:ajax>
16 </h:panelGroup>
17 <script type="text/javascript">
18 var def = document.getElementById("form:default");
19 var enh = document.getElementById("form:enhanced");
20 def.style.display = "none";
21 enh.style.display = "block";
22 </script>
23 </h:panelGroup>
24 </h:form>
First, create two divs, one with the link and the other with the checkbox, which is hidden by default. If JavaScript is enabled, then hide the link and show the checkbox. This is the basic idea behind Progressive Enhancement - first, create something that you’ll be happy with in any browser, then add features (in this case, an Ajaxified checkbox) as needed.
That’s all for today. One personal note: Today is my last day officially employed by Sun Microsystems - I wasn’t offered a position at Oracle, and I’m currently actively looking for something. Please feel free to checkout my resume, and let me know if you know of any openings that you think might be a fit for me.


When you’re dealing with conditional formatting of objects based on enumerated values you can eliminate conditional assignments by directly mapping your ENUMs to CSS classes.
There are many cases where enumerated values are used to describe values, especially in the world of infrastructure 2.0. Availability status, for example, is a commonly used enumeration to indicate whether a load balancing related object – a virtual server, a pool, a node (server) – is available, unavailable, or in some unknown state. When building web-based dashboards or management interfaces for such solutions, the server-side code often ends up with a lot of conditional formatting statements as developers map enumerated status codes to HTML to make it look, well, a lot more attractive. I’m using iControl and infrastructure as an example – any application that requires formatting based on enumerated values may find this technique useful in reducing the amount of code (and time) spent on conditional formatting.
By directly mapping enumerated values to CSS classes, you can eliminate the conditional formatting statements in the code which reduces the overall footprint and execution time but also has the added benefit of making it easier to hand off the styling and CSS chores to a web designer without having to worry about CSS class names and documentation around formatting. This also eliminates the need for a mapping via an associative array or other dictionary-style structures in which statuses are mapped to classes.
I’ve defined a couple of classes to differentiate between a virtual server status (highest level) and component (pools, nodes) statuses, and then further defined a style for each availability status that sets the background color of the HTML element to the corresponding status “color”. I’ve made these specifically DIV classes rather than global classes, but that’s just me – you could just define a global CSS class for each availability status if you want. Flexibility is fun!
div.statusbar {
width: 350px;
margin-bottom: 20px;
padding: 5px;
}
div.poolstatusbar {
width: 250px;
border: thin solid white;
margin-left: 50px;
margin-top: 10px;
}
div.AVAILABILITY_STATUS_GREEN {
background: green;
}
div.AVAILABILITY_STATUS_RED {
background: red;
}
div.AVAILABILITY_STATUS_BLUE {
background: blue;
}
You can see that the style class names map directly to the enumerated values used by iControl (not all options are shown in sample code). In the past the PHP code to retrieve the status of virtual servers and their associated pools relied upon conditional statements to format each component based on the value of the availability_status property.
1: foreach ($member as $item) {
2: $color = "green";
3: if ($member->availability_status == 'AVAILABILITY_STATUS_RED')
4: $color = "red";
5: else
6: if ($member->availability_status == 'AVAILABILITY_STATUS_BLUE')
7: $color = "blue";
8: else
9: if ($member->availability_status == 'AVAILABILITY_STATUS_GRAY')
10: $color = "gray";
11: echo "<div style=\"background: $color; width: 350px; padding: 5px;\">";
12: echo "<b>$item->address:$item->port</b><br/>";
13: echo "</div>";
14: }
I’ve now removed all that code and replaced it by simply assigning the enumerated value to the class on each DIV containing the components.
1: foreach ($member as $item) {
2: $status = $member->availability_status;
3: echo "<div class=\"poolstatusbar $status\">";
4: echo "<b>$item->address:$item->port</b><br/>";
5: echo "</div>";
6: }
The result is what you’d expect: each component is properly formatted based on its availability status. Much cleaner. Even using a switch statement wouldn’t have cleaned up as nicely as directly mapping the enumerations to CSS classes. The resulting HTML is not very exciting but then I’m not a GUI design specialist and it just turns out that all the component statuses match up with the virtual server statuses at the moment.
What this does is remove the need to code specifically for special formatting and style and lets me (and you) focus on meaty coding rather than on the more tedious formatting code. It’s obviously very easy to do this with enumerated values but any property whose values are constrained could be used in the same way to map directly to CSS classes for formatting. I chose enums because in general they’re (1) static, (2) have a very constrained set of values, and (3) used in just about every language there is, which makes this technique very portable.
Happy coding!
Related blogs & articles:


Four or five years ago if you said to your web guru, "let's make a
site map!" You'd probably end up with a quaint-looking single web page that had a list of links and categories indexing your site. You can still find these from time to time. As it turns out, Apple still has one, go figure. As you may recall, this was yet another alternative to a search engine, to help visitors find your content. Not your grandfather's web code, the "site map" of the 21st century, however, is something a bit different but with the same goal of helping visitors find your content, albeit in a bit more "high tech" fashion.

You are probably thinking, "yikes, does my techie guru have to keep that stuff updated?" The answer is yes, but the good news is really that no one need keep up your entire sitemap manually. There are many tools out there to generate these for you. Really -- don't ever even think about coding it manually!
Ever wonder why requests coming through proxy-based solutions, particularly load balancers, end up with an IP address other than the real client? It’s not just a network administrator having fun at your expense. SNAT is the question – and the answer.
SNAT is the common abbreviation for Secure NAT, so-called because the configured address will not accept inbound connections and is, therefore, supposed to be secure. It is also sometimes (more accurately in the opinion of many) referred to as Source NAT, however, because it acts on source IP address instead of the destination IP address as is the case for NAT usage.
In load balancing scenarios SNAT is used to change the source IP of incoming requests to that of the Load balancer. Now you’re probably thinking this is the reason we end up having to jump through hoops like X-FORWARDED-FOR to get the real client IP address and you’d be right. But the use of SNAT for this purpose isn’t intentionally malevolent. Really. In most cases it’s used to force the return path for responses through the load balancer, which is important when network routing from the server (virtual or physical) to the client would bypass the load balancer. This is often true because servers need a way to access the Internet for various reasons including automated updates and when the application hosted on the server needs to call out to a third-party application, such as integrating with a Web 2.0 site via an API call. In these situations it is desirable for the server to bypass the load balancer because the traffic is initiated by the server, and is not usually being managed by the load balancer.
In the case of a request coming from a client the response needs to return through the load balancer because incoming requests are usually destination NAT’d in most load balancing configurations, so the traffic has to traverse the same path, in reverse, in order to undo that translation and ensure the response is delivered to the client.
Most land balancing solutions offer the ability to specify, on a per-IP address basis, the SNAT mappings as well as providing an “auto map” feature which uses the IP addresses assigned to load balancer (often called “self-ip” addresses) to perform the SNAT mappings. Advanced load balancers have additional methods of assigning SNAT mappings including assigning a “pool” of addresses to a virtual (network) server to be used automatically as well as intelligent SNAT capabilities that allow the use of network-side scripting to manipulate on a case-by-case basis the SNAT mappings. Most configurations can comfortably use the auto map feature to manage SNAT, by far the least complex of the available configurations.
WILS: Write It Like Seth. Seth Godin always gets his point across with brevity and wit. WILS is an ATTEMPT TO BE concise about application delivery TOPICS AND just get straight to the point. NO DILLY DALLYING AROUND.
Related blogs & articles:
The long, lost application delivery spell compendium has been found! Its once hidden, arcane knowledge is slowly being translated for the good of all web applications. Luckily, you don’t have to be Elminster or Gandalf or <insert powerful wizard you know here> to cast this spell over your infrastructure
Detect Invisible (Application) Stalkers ![]()
School of Magic: Abjuration (Protective Spells)
Components: Somatic (requires gestures), Material (requires physical component)
Casting Time: special
Range: Layers 3-7
Area: global
Duration: Until discharged
Saving Throw: Special
Spell Resistance: No
Invisible (application) stalkers are creatures native to the Internet. They sometimes serve miscreants, corporate spies, and script kiddies, who summon them to perform attacks against specific targets. A summoned invisible stalker undertakes the form of a legitimate application request, pretending to be a real user, and will tirelessly undertake whatever task the caster commands, even if the task sends packets hundreds or thousands of miles away. The creature follows a command until the task is completed and obeys only the caster.
Invisible (application) stalkers operate only at layer 7 and eschew the use of forms commonly recognized as being of evil intent. Thus an invoke firewall log spell will show only multiple requests over time from similar agents, and intrusion detection spells have no effect on the creatures. Only a detect invisible (application) stalker spell can recognize and subsequently dismiss these agents of evil.
This spell inserts into the path of the invisible (application) stalker a wall which cannot be avoided, blocking them or reporting to the caster their proximity, as determined by the caster. The material component for this spell is a web application firewall, which must be placed between the invisible (application) stalker and its intended target. The somatic component requires the caster to complete a series of mouse clicks and keyboard strokes that deploy an application security policy including the ability to prevent web scraping. The casting time for this spell varies based on the complexity of the existing environment, and how many victims are being targeted by the invisible (application) stalkers.
Once completed, the spell will last until the caster discharges it by disabling the policy created by the somatic gestures.
The invisible (application) stalker may attempt a saving throw (Will) to realize it is being blocked. If it makes the save, it may attempt to figure out how the wall is blocking it. It must then make a second Will save or discorporate immediately. If the spell is cast as a reporting only mechanism, there is no saving throw allowed and the invisible (application) stalker will never be aware it has been detected.
Similarly, web scraping attacks are nearly impossible for a developer to detect because there is nothing in the request that would indicate anything is out of the ordinary. Nothing. No special code, no special characters, no odd manifestations within the headers or network data. In order for the developer to detect such an attack s/he would need to be able to determine whether the client is manned by a human being or is a script/bot. And no, using User-Agent headers isn’t going to work on this one because miscreants have figured out that too many security devices are able to block their attacks based on that value and thus have learned to circumvent it by scripting real browsers or manipulating the HTTP headers such that their bots/scripts appear to be valid user-driven browsers.
But that’s what a web application firewall (WAF) was designed to do: to watch, to evaluate requests in context, across all instances and all requests. It has the visibility, it has the capability, and it can detect attacks that are not easily if at all detected from within the application. Even if the WAF isn’t blocking the attacks, it can at least tell you they are happening, which is something the developers need to know if they’re going to put in place solutions to prevent them.
“Security manager, ‘J.F. Rice,’ whose name and employer have been disguised for obvious reasons” explains his need to “see” inside connections and understand what is happening in his environment.
Web application security requires visibility as well as the expected defensive capabilities. A web application firewall can provide both capabilities even though you may not leverage both at the same time or at all. Using a WAF as a mechanism to determine what kind of attacks are being directed at your web applications is just as valuable a proposition as enabling its preventative capabilities.
Either way, knowing is the first step to moving forward on a strategy to address it.
Related blogs & articles:
Google’s desire to speed up the web via a new protocol is laudable, but the SPDY protocol would require massive changes across networks to support
ArsTechnica had an interesting article on one of Google’s latest projects, a new web protocol designed to replace HTTP called SPDY.
SPDY uses a single SSL-encrypted session between a browser and a client, and then compresses all the request/response overhead. The requests, responses, and data are all put into frames that are multiplexed over the one connection. This makes it possible to send a higher-priority small file without waiting for the transfer of a large file that's already in progress to terminate. Compressing the requests is helpful in typical ADSL/cable setups, where uplink speed is limited. For good measure, unnecessary and duplicated headers in requests and responses are done away with. SPDY also includes real server push and a "server hint" feature.
Having recently emerged from a trip into the world of service-providers and its associated protocols, the description of SPDY immediately brought to mind other asynchronous, message-oriented protocols such as SIP and DIAMETER. It therefore made me seriously consider the kind of massive changes that would be required to support such a protocol across all data center components: security, load balancing, acceleration, web servers, application servers, caches. Basically any network intermediary based on the premise of a strict request-reply, synchronous behavior would likely need radical changes to its core protocol handling systems.
SPDY, as described, is asynchronous and message-oriented. Like DIAMETER, SPDY would allow multiple requests per connection, effectively turning a single connection designed to be used and then closed into a long-lived connection. This is more along the lines of a SIP connection which is initiated and held open until the session is terminated.This is very different from the HTTP model in which connections are opened and closed within fairly short time intervals and are not expected to be held open for exceedingly long periods of time. SPDY thus eliminates the overhead associated with opening and closing many connections and the negative impact that has on application performance.
The current draft of the SPDY protocol states that “from the perspective of the server business logic or application API, nothing has changed”. But from the perspective of the infrastructure that needs to process the protocol, everything changes.
KEY CHANGES TO HTTP HEADERS
The following are directly from the draft of the SPDY protocol and document the changes from HTTP to SPDY
REQUEST CHANGES
method, url, and version. These keys are required to be present. The 'url' is the fully-qualified URL, containing protocol, host, port, and path.Content-length is not a valid header. RESPONSE CHANGES
status and version. These keys are required to be presentContent-length is no longer valid. These changes would have a huge impact on infrastructure solutions, many of which rely on URI or HTTP headers (custom and standardized) to perform specific actions such as blocking, scanning, persistence (server affinity), or routing. The requirement that SPDY be transported via SSL has its own, well understood impact on infrastructure and is already dealt with by most devices, but SPDY also requires that headers are compressed via gzip. This means every intermediary requiring to perform some action based on the headers will need to decompress, process, and then likely recompress the headers before sending it on to the next hop. Coupling required compression with SSL would not only require support on all relevant infrastructure but will also likely reintroduce latency that could offset some of the performance gains claimed by testing of SPDY thus far.
SINGLE-CONNECTION: LONG LIVED SESSIONS
That all communication would essentially flow between the client and server over a single connection also poses a challenge for intermediaries that perform any kind of analysis or are required to act on the data exchanged. Load balancers, for example, are not generally designed to handle switching of messages in what becomes a 1:N connection:server scenario. The protocol could likely be supported as is by most load balancing solutions on a strictly layer 4 load balancing basis but advanced features that take advantage of application-aware capabilities such as message header and payload value routing (content-based routing) as well as egress functionality like Data Leak Prevention (DLP) would be much more difficult to implement, if not impossible for some solutions. This capability actually sounds a lot like HTTP pipelining on the request side.
The single, long-lived connection would have more of an impact on the overall architecture and capacity planning. In some respects it would be easier, as there would be an easy 1:1 ratio between users and connections. But because each user is effectively being handed dedicated compute resources, this would actually change the resource consumption model on servers and make it more difficult to support high volumes of users without building out a scalable infrastructure.
ASYNCHRONOUS EXCHANGE OF MESSAGES
Further complicating the ability of infrastructure solutions to handle SPDY is its definition as asynchronous. Essentially asynchronous protocols do not enforce order of replies. That means a client could send three requests in a row without waiting for a response and the server could send back the response in a completely different order. Again, from the draft SPDY protocol:
Because TCP provides a single stream of data on which SPDY multiplexes multiple logical streams, it is important for clients and servers to interleave data messages for concurrent sessions.
This may not sound like a problem, but for infrastructure that is optimized to handle HTTP and has been built around its implicit behavior this would require changes to the core networking stacks on most devices. In a typical HTTP scenario a request is received, the infrastructure solution processes any applicable ingress policies, and then initiates a connection to the appropriate server and waits for a response. It appears that with SPDY, like DIAMETER, the infrastructure still processes any applicable ingress policies and initiates a connection but does not necessarily wait for a reply as it might need to act upon the next incoming message.
This means a single network “session” would need to carefully track multiple incoming requests and outgoing responses at the same time on a per connection basis. This is not something most infrastructure is typically prepared to handle. Combined with the possibility that different requests may need to be routed to different servers within the infrastructure, this complicates the nature of application delivery and load balancing and could have a huge impact on the costs associated with cloud computing. Long lived sessions/connections initiated on secondary or tertiary servers launched to handle temporary capacity increases could hold open those connections long enough to incur excess charges that are unnecessary.
Also similar to DIAMETER is the inclusion of a “real server push” feature. The ability of a server to act like a client and vice-versa is inherent in DIAMETER and this reverse flow of traffic is not something most infrastructure is prepared to process.
Any infrastructure solution that is heavily focused on application layer (HTTP) processing for any purpose would likely need to make radical changes to its core networking and processing engines. Some solutions, particularly those tasked with load balancing and scaling existing message-based protocols may already be capable of supporting a protocol like SPDY. Whether the solutions that support DIAMETER and SIP load balancing and scalability could support SPDY without modification is highly dependent on whether support for the service-provider focused protocols is based on an underlying generic message-based implementation [PDF] or a protocol-specific implementation. The latter would be difficult to adapt to a new protocol while the former would be more easily extended to specifically support the requirements of new message-oriented protocols.
But that’s only load balancing and scalability. There are many other infrastructure devices that are used to secure, monitor, accelerate, and otherwise manage HTTP that would need to be updated to handle such a new protocol. The upheaval across data centers would likely be on par with the anticipated challenges associated with mass migration from IPv4 to IPv6. Like that migration, however, support for both SPDY and HTTP could be achieved through the use of translating gateways; infrastructure capable of supporting both SPDY and HTTP or able to translate between the two could be utilized to enable a smoother transition.
While it’s a fascinating and exciting notion, the introduction of a completely new protocol to replace HTTP seems more academic than realistic. More realistic would be for gradual implementation through adaptation of SPDY’s core concepts into the next generations of HTTP until HTTP is indistinguishably from a protocol such as SPDY. Making modifications and improvements to HTTP would be an evolutionary step rather than the revolutionary change implied with SPDY that would be almost too disruptive to adopt.
That said, not everything that comes out of Google Labs is adopted as an industry wide solution. It’s an experimental environment and a good one at that. What may come out of the SPDY project may well in fact be changes to HTTP rather than the presentation of a new, radically different protocol. Regardless, SDPY and Google’s efforts have people talking about what’s wrong with HTTP and how it might be fixed and that conversation is one we’ve probably needed to have for quite some time now.
You can read more about the tools Google offers and general problems with web performance at Google’s “Let’s Make the Web Faster” site.
Related blogs & articles:
These three things have a lot more in common than you might think and all three tend to evoke similar levels of frustration.
A very real problem women face when shopping is
this: no two brands define a size the same. If you usually wear a size 8 in “Brand X” you might actually wear a size 10 or 6 in “Brand Y”, depending on how the brand decided to define its sizing. Customers, women in this case, cannot count on consistency in sizes across brands. This makes shopping annoying because every time you change brands you’re never quite sure what you need and if the size increases across brands, well, it becomes obvious that perhaps brand lock-in is in part the reasoning behind these differences in sizing.
Now, consider the differences in the definition of “The Cloud”. We have IaaS (Infrastructure as a Service). We have PaaS (Platform as a Service). We have SaaS (Software as a Service). All three have very different definitions of what makes it “a cloud” and there is very little consistency across those definitions. Oh, there are vague similarities: elasticity, automation, easy provisioning. But those are nebulous terms that are about as useful as slapping a “Size 8” on a pair of jeans and expecting a woman to know what that means. She doesn’t, and neither does the consumer of “cloud.”
Dig into “cloud computing” and “intercloud” and standards efforts and you’ll see this is true at the infrastructure layer, as well. The challenge of defining standards around intercloud computing and cloudbalancing and just collaboration within a single cloud computing environment is made infinitely more challenging because infrastructure Vendor X “size 8” doesn’t match up with Vendor Y “size 8.” Features, naming, resource models, capabilities – all different. Yet all must be able to communicate and collaborate to not only provide the basic foundation for a cloud computing environment, but to be able to migrate from one provider to another.
This is what’s going to make defining standards more challenging than ever: we’ve got to not only standardize protocols but common industry and market definitions as well. The former will likely turn out to be much easier than the latter because it’s more abstract; it’s about management and control without regard to implementation. It is the resource model that will be difficult to nail down.
William Vambenepe writes in Separating model from protocol in Cloud APIs:
Things become a lot more sensitive when you touch the resource model, which reflects the actual capabilities of the Cloud management infrastructure. How much flexibility in the network setup? What kind of application provisioning? What affinity/anti-affinity control level? Can I get block-level storage? Etc. Having to implement the other guy’s interface in these matters is not just a matter of glue code, it’s a major product feature. As a result, the resource model is a much more strategic control point than the protocol.
William nails the problem with his assessment of the differences between the resource model and protocols. Given his obviously intimate knowledge of web services standards and thus SOA, this is no surprise. One of the core tenets of SOA is the separation of these two very different but very vital components. The interface should be separate from the implementation. In InterCloud, we must separate resource model (data protocol implementation) from interface (command and control protocol) in order to achieve standardization.
Interestingly enough at the last Infrastructure 2.0 Working Group, which is focusing on this problem, Vint Cerf mentioned out of hand that the separation of IP from routing “in the beginning” was actually accidental. If you read the IP RFC you’ll note that it ends up being just a “resource model”; it describes the format of information being exchanged and mentions how packets should flow across internetworks, but it defines no API-style protocol for doing so. It offers only minimal guidance on the higher level interfaces that might be used to transmit and receive Internet Datagrams. That accidental omission turned out to be the best thing since sliced bread. Routing protocols have come and gone since then, but IP remains at the heart of the Internet. Basically we need to duplicate that, but at a higher layer in the stack.
Any InterCloud protocol will almost certainly be easier to develop than the resource model. While there already exists some commonality across components and concepts in the infrastructure, still there are many more resources for which every vendor has their own definition. It is that disparity that needs to be addressed independently and codified in a common set of resource models that at the same time allows for extensibility on a per vendor basis to account for uncommon resources.
This is no easy task. Consider a very simple example – persistence in load balancing solutions. Persistence is a commonly implemented feature in all load balancers that can be achieved in a number of ways. Among the most common are: source IP, destination IP, Cookie, and SSL session ID. Now take a look at the difference in definition of these - from a purely naming standpoint – between Citrix Netscaler and F5 BIG-IP:
| Citrix Netscaler XML API “Size 8” | F5 BIG-IP iControl “Size 8” |
Looking at both implementations – and remember this is just naming – you’ll notice that the most common methods of persistence exist in both solutions, but use very different naming conventions. Netscaler defines source IP-based persistence as “SOURCEIP” while F5 uses “PERSISTENCE_MODE_SOURCE_ADDRESS_AFFINITY”; same concept, different terminology. Once you get beyond the common methods you find even more disparity and it becomes more difficult to map between the two without a firm foundation of knowledge of both systems. For example, is the Citrix “CALLID” the same as the “PERSISTENCE_MODE_SIP” definition? Perhaps they are, perhaps they aren’t. You can imagine that at the operation level, the API, the naming conventions used there are so drastically difference that attempting to map the two would drive even the most experienced integration developer a bit insane.
Just as cloud computing providers continue to roll out new services over time, behaving in a manner similar to Web 2.0 applications that never quite come out of beta, so, too, will the standards of InterCloud need to evolve. It’s going to take a lot of comparisons, discussions, and mappings to figure out what is an acceptable common resource model for each infrastructure component and in the process we’re going to have to abstract quite a bit. Less challenging will be the need for a common namespace for this resource model across all infrastructure components. After all, an IP address is the same whether it’s used by a virtual machine, an IPS, a load balancer, or a firewall. But these are easier to discover and define than elements unique to a particular solution space and once we get the ball rolling one can hope that the momentum keeps it rolling.
The Internet wasn’t built in a day – really, it took the ‘founding fathers’ quite a bit of discussion and hard work to get the standards defined that allowed mass interoperability and collaboration. But I am willing to bet that we’ll see InterCloud standards long before the fashion industry decides to standardize its sizing for women.
Long before then, I’m sure.
Related bogs & articles:
Xajax Project Introducing Xajax Ajax-enable your PHP application with a simple toolkit that gets the job done fast. Runs on any PHP 4.3.x/PHP 5.x and Apache/IIS platform. xajax is an open source PHP class library that allows you to easily create powerful, web-based, Ajax applications using HTML, CSS, JavaScript, and PHP. Applications developed with Xajax can asynchronously call server-side PHP functions and update content without reloading the page.
Atlas is a very powerful Ajax framework generally associated with ASP.NET
The ASP.NET AJAX Control Toolkit helps you bring your web sites to life! The ASP.NET AJAX Control Toolkit is a collection of samples and components that makes it easier then ever to build and consume rich client-side ASP.NET AJAX controls and extenders. The toolkit provides both ready to go samples and a powerful SDK to simplify the creation and re-use of your own custom controls and extenders. More ASP, Active Server Page links
Ajax PHP Magazine More PHP links
What is Ajax Good for. Ajax Tutorial XML Training and Ajax XML Application development tutorial and Ajax Javascript.
Free AJAX Tools, Frameworks, Libraries and Source Code
AJAX Tutorial AJAX is not a new language, but just a new way to use existing standards. With AJAX you can create better, faster, and more user friendly web applications. AJAX is based on JavaScript and HTTP requests.
Coding in Pardice AJAX Tutorials. This page has various tutorials, articles, and blog posts I've created concerning AJAX and AJAX techniques. Real World AJAX. Blog Tutorials & Projects.
Ajax: A New Approach to Web Applications. Ajax is said not to be an acronym.
Go Beyond HTML Forms With AJAX implementing features such as auto-saving, just-in-time validation, submission throttling and popup forms.
WPF/E is the Microsoft solution for delivering rich, cross-platform, interactive experiences including animation, graphics, audio, and video for the Web and beyond. Utilizing a subset of XAML (eXtensible Application Markup Language)-based Windows Presentation Foundation technology, WPF/E will enable the creation of content and applications that run within multiple browsers and operating systems (Windows and Macintosh) using Web standards for programmability. Consistent with Web architecture, the XAML markup is programmable using JavaScript and works well with ASP.NET AJAX. Broadly available for customers in the first half of 2007, WPF/E experiences will require a lightweight browser plug-in made freely available by Microsoft.
WPF/E (codename) Software Development Kit (SDK) Community Technology Preview (Dec 2006)
DHTML Goodies. A library of DHTML and AJAX scripts. Also Widgets.
XAP - eXtensible Ajax Platform. An Ajax-based Rich Internet Application framework.
TurboGears Features: easy-to-use, database-driven, easy Ajax and designer- and programmer-friendly.
FireBug lets you explore the far corners of the DOM by keyboard or mouse. All of the tools you need to poke, prod, and monitor your JavaScript, CSS, HTML and Ajax are brought together into one seamless experience, including a debugger, error console, command line, and a variety of fun inspectors.
Using Ajax to Improve the Bandwidth Performance of Web Applications
Atlas is a very powerful Ajax framework generally associated with ASP.NET
Ajax Endangers Pageviews As A Metric. Hits eventually yielded to page-views when it came to counting web traffic, but the growing usage of Ajax technologies that refresh content without triggering a new page-view could bury that metric.
Ajax Information from HTML Source
Cleaning up the web with AjaxAjaxian » Front Page
OnLamp. Curt Hibbs demonstrates the use of Ajax within Ruby on Rails applications. More Ruby links. ( Onlamp The Open Source web Platform).
LAMP is an acronym for a set of free software programs commonly used together to run dynamic Web sites: Linux, the operating system; Apache, the web server; MySQL, the database management system (or database server); Perl, PHP, and/or Python, scripting languages.
Yahoo! Maps AJAX API - Getting Started Guide. Learn the fundamentals of the Yahoo! Maps AJAX API and get started creating your own maps. Yahoo Developer Network Yahoo! Answers API: Now With Filtering and Sorting!
IP Location Lookup This is not an SEO tool, but is very useful in determining the geographic location of an IP address, Check and IP address e.g. 203.113.20.70, (hit Enter after entering your IP address on the page), using a bit of AJAX and Maps.
W3C The Semantic Web provides a common framework that allows data to be shared and reused across application, enterprise, and community boundaries. It is a collaborative effort led by W3C with participation from a large number of researchers and industrial partners. It is based on the Resource Description Framework (RDF).
AJAXSLT is an implementation of XSL-T in JavaScript, intended for use in fat web pages, which are nowadays referred to as AJAX applications. Because XSL-T uses XPath, it is also an implementation of XPath that can be used independently of XSL-T.
Operating Systems and Graphical User Interfaces. Windows Visa/XP, Linux, Apple, BeOS, etc.
ColdFusion Programming Language
Programming Languages and Computer Code and Scripting
Web Services. UDDI (Universal Description, Discovery and Integration). WSDL (Web Services Description Language). SOAP (Simple Object Access Protocol).
Mashups. Mashable, Mashable links
Internet Speed. Internet Speed Testing. Improving Internet Speeds.
Web Master Tools and Utilities
Web Masters. Click Here Now to start making money. A Great opportunity to make some money. Receive 50% by offering your users Ton's of Keywords on A Great Portal websites. Our Affiliate Program Pays you 50% on Level 1 of Every Sale of our Text Link both searchable and static Text Link!
A Computer Portal. Freeware, Shareware. Download software. Computer languages and Programming code. Including PERL Scripts and Java Scripts. Webmaster Tools. Internet Marketing, Website promotion. Hardware Help from BIOS to Windows and UNIX.
® © ™ are owned by respective authors and websites. There may be a charge for some software. Google™ is a trademark of Google Inc, These pages are not endorsed by Google or any other Company