Smashing Magazine has a cool “cheat sheet” for those interested in the ongoing development of HTML 5. Of interest is what’s being excluded and what’s new, as well as the length of time it’s going to take before HTML 5 is completely supported:
XHTML is dead, long live HTML 5! According to W3C News Archive, XHTML 2 working group is expected to stop work end of 2009 and W3C is planning to increase resources on HTML 5 instead. And even although HTML 5 won’t be completely supported until 2022, it doesn’t mean that it won’t be widely adopted within the foreseeable future.
Part of the “completely supported” should include, if necessary, application infrastructure: load balancing, acceleration, caching, and security. Because these types of infrastructure solutions are not only aware of content but rely upon it as actionable data for decision making processes it’s important to consider early how changes to the specification might impact that application infrastructure.
One of the big changes in HTML 5 that leaps out in terms of infrastructure is that it’s getting more granular about content. Rather than being limited to the generic
In most cases the changes thus far appear to be positive in that they would afford the infrastructure with more granular information on which to base application of policies. That’s a good thing, as it allows the infrastructure to get even smarter about how it deals with web-based applications.
The thing with HTML – and all content returned from web applications – is that it has very little impact on requests. That’s because the requests don’t include tags, it’s just a URI. The response, however, is laden with content and tags and information that can transformed and otherwise potentially optimized and sanitized before it is returned to the client. Thus any impact on infrastructure will likely be focused on the response.
LOAD BALANCING / APPLICATION SWITCHING
At first glance there really isn’t anything new in HTML 5 thus far that requires a change to load balancing or application delivery infrastructure. What it will do, however, is encourage architects to optimize application architecture. One of the most efficient means of achieving an optimized architecture is to “specialize” application servers. This is especially efficient in a virtualized architecture.
By separating out content types and optimizing the application server (virtual or physical) or that specific content type, architects can improve the performance and resource utilization of the entire application infrastructure. But in order to do that the infrastructure must be able to route requests to the correct application server. Hence the need for application switching or layer 7 load balancing rather than simple layer 4 load balancing. If the application delivery infrastructure is smart enough to route specific content types or URIs to specific servers, the entire application architecture benefits. Application infrastructure is already able to do this, but the granular tags in HTML 5 should make it even easier to configure on-demand routing via transformation (automatic replacement).
That means replacing attributes such as the href in the event there is a need to redirect the specific content to another application server or even a different data center. The ability to modify the URI on-demand will be important as cloud adoption increases and new ways of leveraging application services continue to appear. That particular ability will make it easier to implement architectures that utilize a hybrid cloud approach, i.e. multiple data centers comprising a traditional physical data center and any number of “cloud-based” data centers.
WEB ACCELERATION & CACHING
Web acceleration and caching may benefit from HTML 5 and its more granular tagging. Parsing responses should be easier because you know exactly what you’re looking for, which means instead of using redirection to content delivery networks or other intermediaries in the infrastructure you can likely transform the reference to the object on the response rather than waiting for the reply. Removing the intermediate step of redirecting improves application performance as you’re eliminating a request-response cycle from the process.
Taking that a step further, and leveraging a unified application and data delivery infrastructure, one could include global application delivery techniques with the transformation to really distribute objects across multiple data centers or clouds. As with load balancing this can be accomplished now, but it should be easier to actually do using specific tags to identify content types.
WEB APPLICATION SECURITY
Web application security is going to get more complex and will likely be affected the most by the adoption of HTML 5. There are new content types that are certain to be exploited long before mainstream adoption. That means web application security – and browser security, too – is going to need to get up to speed quickly on securing these objects from tampering and exploitation. Tags such as: and even appear to be likely targets for exploitation.
Unfortunately the only tag being excluded from HTML 5 that is a good thing is , but as of today the specification keeps so the benefits of losing the former (clickjacking, for example, relies on the use of frames) are negated by keeping the latter.
MINIMAL IMPACT on INFRASTRUCTURE
There doesn’t appear to be anything in HTML 5 right now that is worrisome or different enough from XHTML and HTML 4 that would require significant change in application infrastructure. Certainly the additional options and granularity will be a boon for management and configuration of intermediaries designed to deliver and secure web applications, but in terms of functionality that may be affected there appears to be no impact at the moment.
It would be nice to see the inclusion as standard attributes some of the Web 2.0 functionality we’ve come to depend on today, or tags to indicate dynamic requests that include standardized attributes to be used for handlers and event processing. This would alleviate the issue of cross-library compatibility and make it much easier to move from one dynamic library to another, or use them simultaneously in the same application.
But the real impact is likely to be on architecture and on the way in which infrastructure is leveraged to secure and deliver web applications. At least that’s the way it looks right now. We’ll see if that changes in the future, but the direction thus far would appear to indicate that radical change to HTML is unlikely. Unless that turns out to be false, there shouldn’t be a huge impact on application infrastructure.