Analysis: Web 2.0 Technologies

Few companies adopting Web 2.0 see themselves as living dangerously. But the reality is, Ajax, mashups and REST first appeared in the wilds of the Internet, where it's survival of the fittest and new technologies fight to stand out from the pack. Niceties like security might come later.

Web 2.0 and RIA (Rich Internet Applications) will dramatically change your infrastructure in terms of monitoring, management, deployment and availability. The load on both network and back-end servers could become crushing. Security is too often an afterthought, and two of IT's safety nets--standards and interoperability testing--are sorely lacking. You also may find yourself unable to analyze Web site usage by established methods.

Still, none of this seems to be hindering deployment. Close to half of developers answering Evans Data's Spring 2006 Web Services Development Survey say they're already working with Ajax, a key component of the Web 2.0 architecture, or plan to do so in the coming year. Use of REST (Representational State Transfer), a simple, URI-based service architectural model, is up as well: The Evans survey found a 37 percent increase in respondents implementing or considering REST, with one out of four seeing REST-based Web services as a simpler alternative to SOAP-based services.

Although Web 2.0 technologies can take advantage of SOAP (Simple Object Access Protocol) and your SOA infrastructure, most do not. Why? Because the developers who blazed the way rarely concerned themselves with details like management, security, scalability or support. They were in it for the thrill of the hunt.AJAX Vs. SOAP

SOAP has been the primary mechanism for implementing services in the enterprise for the past several years; it's well understood, and myriad products exist to ensure scalable, manageable and secure SOAP-based applications.

None of this is true right now for Ajax, mashups and REST, and that's making vendors--and smart enterprise IT groups--nervous. We suspect this is the impetus behind industry initiatives such as the OpenAJAX Alliance, a consortium involving leading ISVs including Adobe, BEA Systems, IBM and Sun Microsystems, that's dedicated to interoperability.Unfortunately, there are no standards, other than SOAP and WSDL (Web Services Description Language), on which these vendors can base new Web 2.0 products, and standards groups like OASIS and W3C have yet to step up to the plate. When it comes to putting it all together and building that killer mashup for users, there's still a lot of hand-coding required.

No one disputes that, done right, information-rich Web 2.0 applications can increase end-user productivity. But to take full advantage, services must exist, and that means a whole lot of work for IT to architect, implement, deploy, manage and secure a scalable service-oriented infrastructure.

Building interfaces using a drag-and-drop paradigm is still a dream, and usually not a pleasant one.

Take mashups. Early adopters have thus far had precious few tools available. IBM has taken the lead in this area with its Enterprise Mashup tools, announced in June, and BEA is not far behind, with an array of new Web 2.0-inspired tools--including a mashup-focused software infrastructure--set to see daylight in 2007.

When the buzz around a new technology reaches a dull roar, the temptation for vendors to rush out enabling products can be irresistible. IBM's impressive-sounding "Enterprise Mashup System," now in early adoption phase, really boils down to support for building Ajax-based interfaces using Eclipse development tools. Too bad Ajax isn't ready for prime time use in the enterprise.Yes, you heard us right. Ajax is a great technology and certainly opens the browser up to a wider array of functionality than has previously been available in a thin client. And, the OpenAJAX Alliance is moving to define a single declarative markup language, which would essentially provide a standards-like API for developers.

That said, right now it's open season on Ajax APIs and implementations--IT is finding it nearly impossible to migrate from one Ajax toolkit to another, and interoperability is practically unheard of.

Further complicating matters, few shops have taken into account the network and the server-side impact of Ajax on the enterprise infrastructure. Poorly tuned Web servers can be brought to their knees by just a few Ajax-enabled users. Hundreds may bring your systems crashing to the ground; at the very least, Ajax will hog precious server and network resources needed by mission-critical systems.

Desktop systems are often the last to be upgraded in the enterprise, and this reality may defeat the very purpose of moving ahead with Ajax-based apps. Although mashups and other information-aggregation technology may indeed improve employee productivity by reducing the number of pages required to display information, if the load time on that single page increases beyond the time it would have taken to load several individual pages, you haven't gained a thing.

Until there's at least a modicum of a standard markup language and the impact of rich interfaces on network and server resources is better understood, early Ajax adopters are gambling with the operational wellbeing of their infrastructures. Exercise caution. Implementing a few closely controlled pilots is the only way to understand whether your infrastructure and desktops can handle the load or will need to be upgraded.Unsafe At Any Speed

More than half of readers responding to our recent SOA reader poll didn't have comprehensive security in place--heck, 33 percent had no strategy whatsoever to protect their Web services infrastructures (see "Marshall Your Web Services" at and "NWC Analytics: Strategic SOA Management").

With a foundation like that, good luck trying to lock down Web 2.0 applications. Ajax and REST have a higher requirement for traffic validation than the more narrowly defined SOAP, which is constrained by well-defined XML schemas and WSDL-based contracts. Ajax data flying back and forth between browser and server is rarely predefined by a schema, and in cases where development has occurred using toolkits like those from the Dojo Foundation, IT may not even have control over those formats!

And yet, you need to secure and validate data, for the safety of both the client and the server. You also must monitor and manage traffic to understand the load on your network, which will get a workout once Web 2.0 technologies are deployed. Even if bandwidth usage doesn't increase, the number of requests your Web and application servers will need to support it will go up. And this load will cascade, putting an additional burden on just about every piece of Web application infrastructure in your data center.

SOA security gateways offered by Forum Systems, IBM-DataPower, Layer 7 Technologies and Reactivity have long been capable of securing SOAP, but out of the box they're less adept at dealing with generic Ajax and REST traffic. Problem is, they can't use the industry-standard WS-Security to lock down Web 2.0 apps because, by default, neither Ajax nor REST understands SOAP--a requirement for WS-Security.

Fortunately, SOA security gateways are, for the most part, capable of protecting any XML-based data and will keep malicious attacks, such as SQL injection and cookie poisoning, from being injected into Ajax requests. Most can validate Ajax if a schema exists, or at least ensure that the data is well-formed (see our review of one such offering at "XML Threat Defense"). Most products in this market are capable of extracting credentials from XML messages using XPath, but discuss this option with your chosen vendor before signing on the dotted line.

A less expensive source of protection against attacks injected into XML traffic are standalone XML firewalls, such as Forum Systems' XWall and Reactivity's XML Firewall. XML firewalls are one component of the SOA security gateway that should be implemented, even if a large SOA initiative isn't in your future.

It's The Components, Stupid

The advent of Web 2.0 technologies raises the bar for Web analytics as well. The old paradigm of analyzing Web site usage by page views just doesn't work with Web 2.0 technologies like Ajax and Flex/Flash.As is true with other service-oriented technologies, log-culling apps are unable to provide thorough analysis of Web 2.0 sites. And, very few Web analytics products in use today can accurately provide a picture of component usage--counting page views isn't enough anymore. Each component essentially acts like its own page within an application, so page-oriented Web analytics apps are woefully unable to accurately measure the use and effectiveness of Web 2.0 technologies. The page (the application) is loaded once, but its components (such as combo boxes, lists or tables) may load data multiple times throughout a user session.

Omniture is one of the few Web analytics vendors to have addressed this issue. Through instrumentation, its SiteCatalyst can provide detailed measurement and usage statistics of Web 2.0 components, for both Flex/Flash (through ActionScript) and Ajax (through JavaScript). This measurement and monitoring is critical to understanding the value your customer base places on Web 2.0 components--the data provided by such systems can indicate whether the new additions are hindering or enriching the user experience, provide metrics on the most popular components on your site, and assist in determining whether the ROI on your Web 2.0 investment has panned out as expected.

And I Get What For All This?

To help you decide whether these new technologies are worth the agita, let's dissect the key pieces of Web 2.0. That's not as easy as one might think: While the term is everywhere--we got almost 130 million Google hits--its definition morphs, depending on the company in which you discuss Web 2.0.

So let's play the, "Which of these things is not like the others?" game. Is Web 2.0:

OK, it's a trick question. Three of the four definitions are technologies, while one is built on those technologies, among others. To the average Joe and Jill user, Web 2.0 may well refer to Wikipedia and social networking sites like MySpace.com. But those of us sitting on the enterprise-IT side of the cube wall tend to view Web 2.0 in terms of the interactive technologies that serve as the foundation for this brave new Web.Although there are several technology types under the Web 2.0 umbrella--and just as many approaches--all focus on one goal: Delivering a better user experience. Maybe they provide a sexier, easier-to-use GUI or eliminate the need to refresh the entire page in an application. Some seek to deliver more useful information or slash response times. For IT, the advantages of a zero-footprint client application are obvious, though the immaturity of Ajax and browser-compatibility issues may make these applications more difficult to maintain in an open-deployment environment.

» AJAX. As we discussed earlier, Ajax should be approached with caution. Still, it's likely the most common technology referenced in a discussion of Web 2.0. Early Ajax implementations began as toolkits within which communication between browser and server was simplified for developers. More recently, Ajax also has come to include widget libraries that simplify the creation of rich user interfaces built on the DHTML (Dynamic HTML) and CSS (Cascading Style Sheet) specifications.

User interfaces built using Ajax toolkits such as OpenLaszlo and the Dojo Toolkit are capable of emulating nearly a complete fat-client experience. The increase in user productivity from an Ajax-based interface comes from the exploitation of the XMLHttpRequest object--back in the day, it was one of a few extras Microsoft added to Internet Explorer that was rapidly adopted by other browsers as developers saw the advantages of opening an "under the covers" communication channel from the browser back to the server. The XMLHttpRequest object provides a mechanism for developers to directly access server resources through HTTP using JavaScript without requiring a page reload. This reduces the overall page size in data-heavy applications, as only immediately applicable data must be loaded initially; as the user drills down, relevant data can be silently pulled from the server without waiting for the entire page to reload.

This capability is particularly useful in CRM software. Companies keep a lot of customer data sitting around, and representatives must often get at that data fast, because the customer is on the phone. Using Ajax technology, the representative can choose a customer from a prepopulated list; such data as contact information, order history or open trouble tickets can be refreshed without forcing the rep to wait for the entire page to reload. This increases productivity by reducing wait times. No more, "My computer is really slow today" from the rep, as the data being transferred has ostensibly been reduced and should--theoretically--transfer faster.Why "theoretically"? Although the overall amount of data being transferred is less in terms of what's being pulled from back-end systems, the actual data transfer generally uses XML or JSON (JavaScript Object Notation). Both formats increase the overall size of the data being returned because of syntactical requirements. There's also the need for the browser to parse the XML once it's been returned, and as we all know, XML parsing is a CPU- and memory-intensive operation.

Older hardware--say, below the 512-MB/1.3-GHz mark--will impede the performance of Ajax applications on the desktop. Whether current hardware will need to be upgraded should be part of the overall cost analysis before moving forward with large Ajax-based initiatives.

Another factor not often considered is the additional overhead of communicating with the server and loading the Ajax libraries necessary to perform formatting of elements, such as combo boxes, lists, form elements and data-driven sortable tables. Although these elements generally must be retrieved only once, when the application is loaded, this can adversely effect initial load time and should be considered as part of the overall performance equation.

The current crop of Ajax-based toolkits is immature, but evolving rapidly. The Dojo Foundation has the highest rate of vendor adoption--including Adobe, BEA, IBM and Sun--but other toolkits are not necessarily out of the running. OpenLaszlo and Google's WebToolkit are favored competitors to Dojo, and all have pros and cons that should be carefully weighed before committing. These toolkits are not interoperable, so the choice of one over another is important--you're committing to a single-vendor solution that cannot easily be changed.

» MASHUPS AND COMPOSITE APPLICATIONS. In the wild, they've been dubbed mashups; in the enterprise, composite applications or EMSs (enterprise mashup systems). Ever wonder where the SOBA (service-oriented business applications) buzzword went? SOBA and composite applications essentially mean the same thing--a recombination of services into a single application.

Examples of mashups abound in the wild. They usually take advantage of services available from established providers, such as Google and Amazon, and turn them into an application that is visually appealing while imparting the information users desire (see "Fighting Crime One Mashup at a Time," right).

Within the enterprise, rudimentary mashups generally take the form of portals, which were the precursor to this technology. Portal products such as IBM WebSphere Portal, OracleAS 10g Portal, Microsoft Office SharePoint Portal Services and Vignette Application Portal provide interaction between portlets (mini-applications), but are not yet capable of truly "mashing up" data from disparate systems. For example, call-center employees might see customer information in one portlet. When they choose an account, another portlet displays that customer's order history or credit status. What enterprise mashups provide is the ability to pre-join that same data in a single application (see "Mashups Provide the Big Picture," right).

» ADOBE FLEX/FLASH. Believe it or not, Adobe is fully supportive of Ajax and similar technologies, and is part of the OpenAJAX Initiative coalition formed this past summer to promote the use of Ajax and Web 2.0 technologies. Adobe views Ajax as a gateway, claiming it can only take you so far before you need more functionality.

In a real-life example of diminishing returns, Adobe and many others view Ajax and Web 2.0 as the last frontier of productivity increases to come out of the browser, extending its usefulness yet only delaying the inevitable. To an extent this is certainly true. The browser is not an application-client platform. Yet the latter is exactly what Ajax and Web 2.0 technologies are hoping to achieve--the extension of the browser into a client application platform.Adobe and its acquired Flex/Flash technology are already there, and the company is on record as planning to evolve the Flash runtime into a rich, client application platform that does not suffer from the limitations of its less flexible Ajax cousin--namely, platform and browser dependence (see "Ajax for the Masses" ).

Adobe notes that the XMLHttpRequest object on which almost all Ajax technology relies was introduced by Internet Explorer in 1998 but did not gain widespread support in other browsers until 2003. Even now, the mechanisms through which an object is accessed and used varies, reintroducing a slew of cross-browser capability issues for Ajax toolkits that must be addressed with every new browser release.

Conversely, Adobe expects adoption of its newest Flash player to hit 80 percent within 12 months and 95 percent within 18 months of release. Binary compatibility is not an issue for Adobe, which gives it a definite advantage in moving forward quickly with new features and functionality.

Flex offers the same advantages of most Ajax toolkits, namely improved user interfaces and service-oriented communication with back-end servers. Differences are in support, for which Adobe has many options while Ajax toolkits offer few to none, and in the enterprise-class goodies Adobe can provide, such as debuggers, integration with regression testing tools from Mercury (now HP), professional services, real documentation, support for video as a first-class citizen and development environments that exist now--and not just in press releases.

The drawback is, of course, cost. Although Adobe does offer a free version of the Flex Data Services server-side program, it's limited and may not be useful to the enterprise. The Flex SDK, which differs from the Flex Data Services server-side program, is free, but its enterprise-class server-side extensions are not.IDEs cost money. Support and professional services, too, are not inexpensive and may be too much to ask for a fledgling pilot project in the enterprise.

Adobe isn't the only ISV to offer something for free in hopes of drawing in customers; Laszlo Systems offers a free Ajax toolkit, OpenLaszlo, to entice users to upgrade later on to its commercial offering, which is more in line with Flex/Flash than with the more simplistic Ajax toolkits offered by the Dojo Foundation and others.

Of course Flex and Flash are already accepted in the enterprise, and may be the most viable alternative to a true SOA-based rich interface in the interim. Although it requires a plug-in, Flash has been well tested and is almost universally accepted as a solid, stable user-interface platform. The risks involved in implementing Web 2.0 via Adobe's technologies are extremely low.

The Rest Of The Story

One interesting development of late has been the increase of REST-based services over SOAP services. Both can, and often do, take advantage of WSDL as a contract mechanism, but the manner in which they're accessed differs. REST is gaining popularity as Web 2.0 adoption grows, primarily because of the simplicity of the architectural model and the fact that it can easily be used without a complex SOA infrastructure.REST, like SOAP, uses XML as its data-transfer format, but unlike SOAP, REST does not use an additional set of headers and envelopes to wrap requests and responses. Also differentiating the two is that REST is resource-oriented, while SOAP is method-oriented. In SOAP you call a service. In REST you retrieve a resource. While both may use the same back-end services to retrieve required data, the interfaces employed to retrieve that data are very different.

REST supports a service-oriented architectural model while reducing the requirements--hardware, software and, of course, financial--necessary to begin supporting Web 2.0 applications.

The drawbacks to REST are management and security. REST services generally map a URI to a specific resource, so conventional Web-based security mechanisms must be used to secure them. In addition, most SOA-specific security gateways can't handle REST-based services, and SOA management suites are geared toward SOAP-based services, not REST.

Vendors such as Layer 7 Technologies are beginning to address this lack of security and management for REST-based services, but widespread support will not be available for some time. For more on REST check out our Tech Tracker, "Take a REST From SOAP".

Bottom line, Web 2.0 technologies will eventually mature and evolve into enterprise-class technologies and products, just as SOAP has done. When they're ready for prime time, they will be a boon to the enterprise.But for now, we'd prefer to refer to these technologies as Web 1.9--almost, but not quite, ready to be relied on for mission-critical applications. n

Lori MacVittie is an NWC Senior Technology Editor working in our Green Bay, Wis., Real-World Labs. Write to her at [email protected].

AJAX Alternatives

There are several alternatives to AJAX, most in wide use today. Fat clients are, of course, the most common, but thin(ner) clients taking advantage of plug-in technologies such as ActiveX or Java are also ubiquitous. Each alternative provides capabilities comparable to Ajax and can be easily melded into your SOA infrastructure. The standard reasons for not using ActiveX or Java--mainly platform, browser and version support issues--are still valid, but in controlled environments, these can be overcome.

Mashup AlternativesSure, mashups are cool, but you can achieve the same results without using bleeding-edge technology and tools. For example, EII (Enterprise Information Integration) suites aggregate data for use in composite applications. They just do it differently.

Although mashups generally require the client or application server to pull data from multiple sources and join it together, EII suites can join data on an optimized server in a more targeted, fashion. This reduces the amount of data traversing the network and, more important, reduces the compute requirements on the client and application servers.

And if SOA is your thing, you're in luck--all current enterprise-class EII suites, including those from vendors such as Composite Software, IBM, MetaMatrix and Sybase, can service-enable aggregated data views, making them good citizens within your SOA infrastructure.

Adobe Flex/Flash Alternatives

Competing more directly with Flex/Flash will be Microsoft's XAML (Extensible Application Markup Language), due to be introduced in Vista when the newest Windows OS finally launches. XAML provides most of the same functionality as Flex/Flash, including a browser-hosted runtime and support for video, image manipulation, animation and server-side extensions. It also will sport IDEs, thorough documentation and debugger support.The drawback, as is usually the case with Microsoft technologies, is that XAML is platform-specific. It won't run on alternative OSs/browsers, and so like ActiveX is likely an option only in controlled deployment environments. It is, however, an alternative for Microsoft-specific shops and validates the usefulness and need for Flex/Flash and similar technologies.