|
Tackle Interoperability Challenges in Web 2.0 Dev
Web 2.0 is a fabulous new methodology, but it's important to understand and plan ahead for the interoperability challenges that you face when building Web 2.0 apps.
By Laurence Moroney and Marina Fisher
September 18, 2006
Web 2.0 and its associated technologies, such as Asynchronous JavaScript and XML (Ajax), have been touted as the most significant technology trend of 2006. With the ongoing expansion of the Web and the growing reliance on Web applications, it is only natural that any technology that makes the Web more efficient and easier to use will catch on quickly.
However, as you move beyond the hype and take a closer look at Web 2.0 technology and its uses, you will see the reemergence of troublesome pitfalls, such as .NET-J2EE interoperability challenges, that have persisted because Web 2.0 overlaps with previous architectures. In addition to these concerns, the Ajax integration technique called "mash-ups" leads to client-side integration that poses new interoperability challenges, including those caused by the browser misinterpreting JavaScript, and more importantly, Ajax applications accessing Web services incorrectly.
Lots of applications require that resources from many different systems are integrated into a coherent whole. This provides a consistent user experience, regardless of the backend resources' locations, and the technology used to retrieve and represent them. You can see a typical nTier architecture in Figure 1.
When different layers in the technology stack use different technologies, such as a .NET-based presentation layer and a J2EE-based business logic layer, then a communication layer, such as Web services or bridging, is necessary for them to work together. This adds complexity, cost, and performance overhead to an application. In connected systems, you can solve this problem simply—unify the two platforms at runtime to reduce or eliminate interoperability problems caused by data type mismatches.
An nTier architecture in a Web 2.0 design is illustrated in Figure 2. The presentation logic has moved (at least in part) to the browser, but the main difference in Figure 2 is that the browser needs to communicate with more than one server. In Figure 1, the Web server (on which the presentation tier is implemented) is the sole deliverer of content to the browser. As such, with the Web 2.0 design, a new layer to the architecture is added. It is a complex layer that by intent communicates with multiple layers above it.
Adding to the complexity, you must use interpreted script (as opposed to compiled code) to communicate with this layer, which is difficult to debug and maintain. Tools vendors, such as Microsoft Corporation, Sun Microsystems, and TIBCO Software, Inc., have introduced one method for you to cope with this problem: Enable with tools the automatic generation of JavaScript for the browser layer that interfaces with the Web server(s) above it.
Interoperability Challenges in Web 2.0
You can create either an HTML or ASP.NET project in Visual Studio, depending on your application goals, to begin developing The first hurdle introduced by Web 2.0 technology is "browser level" interoperability. Each browser handles Ajax and JavaScript differently. For example, here is the script you implement to use the XMLHttpRequest object in Microsoft Internet Explorer:
var xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
And here is the script you implement to use it in Mozilla:
var xmlHttp = new XMLHttpRequest();
These JavaScripts first check the current browser and version, and then run the appropriate code. Without these scripts, your user will get an error. Many server-side toolkits can speed up application development by performing this type of exception checking.
One such example is Microsoft's Ajax Extensions for ASP.NET, or Atlas, which is currently in Community Technical Preview, but is due for release by the end of 2006. This toolkit contains a JavaScript compatibility layer that manages the correct use of each browser at runtime.
The second challenge is service interoperability. Browser level integrations, or mash-ups, require that the browser takes content from several different sources and integrates them. These sources are typically HTML-over-HTTP, XML-over-HTTP, or XML-over-SOAP. In the first two types of sources, integration is relatively straightforward. In the third type of source, where JavaScript code consumes Web services, the challenge is greater.
Back to top
|