Developer Product Briefs

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
• 09/01/2006

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.

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.

Atlas toolkits to generate server-side JavaScript are also available to alleviate this problem, but they should be used with caution. Even though Atlas has some of the best support for Web services among the various toolkits used for browser level integrations, it's still not foolproof. Consider how you run a simple Web service, written in C#, on ASP.NET with Ajax extensions that add two numbers. You use a simple Web method:

    [WebMethod]
    public int AddInts(int a, int b) {
        return a+b;
    }

When your application runs, the familiar test harness is generated (see Figure 3).

When Web services run on an Atlas-enabled server, the '/js' can be appended at the tail of the Universal Resource Identifier (URI) to get the Web services to generate a JavaScript proxy automatically. Figure 4 demonstrates this process.

You can easily create an Ajax client that calls the Web service illustrated in Figure 4 using the Ajax extensions. Here's the code:

<form id="form1" runat="server">
  <atlas:ScriptManager ID="ScriptManager1" runat="server">
    <Services>
      <atlas:ServiceReference GenerateProxy="True" Path="Addem.asmx" />
    </Services>
  </atlas:ScriptManager>
  <br />
  First Number:
  <input id="InA" />
  <br />      
  Second Number:
  <input id="InB" />
  <br />
  <input ID="cmdAdd" type="button" Value="Add 'Em"
         onclick="return cmdAdd_Click()" />
  <br />
</form>

<script type="text/javascript" language="javascript">
    
function cmdAdd_Click()
{
  nVal1 = document.getElementById('InA').value;
  nVal2 = document.getElementById('InB').value
  request = Addem.AddInts(nVal1, nVal2, OnComplete, OnTimeOut); 
            
}

function OnComplete(result)
{
  alert(result);
}
function OnTimeOut(result)
{
  alert(result);
}
</script>

This is a simple and powerful example. The <atlas:ServiceReference> tag allows you to specify a reference to the service, which will generate the proxy to the service and download it to the client automatically. Then, you can invoke the services simply by using its namespace as shown in the cmdAdd_Click() function. Using this methodology, you can easily create a mash-up where the client is consuming Web services that support the Microsoft Ajax extensions.

If you're running an ASMX Web service that isn't on a machine using the Ajax extensions, then this service reference won't work, nor will it work on a machine using Java Web services. You encounter these roadblocks because the <atlas:serviceReference> tag generates a URI ending in '/js'  and adds an <add src="URI"> tag to the JavaScript automatically. In an Atlas-based Web Service, the proxy is generated and downloaded. In other types of services, it isn't.

Here's the end result of using an <atlas:ServiceReference> tag to specify three services (The first service in this example is a Java-based Web service; the '/js' is appended at the end of the reference, and it causes an HTTP 404 error.):

<add src="http://portaldev:8988/JavaWebService-JWS
-context-root/MyWebService1SoapHttpPort?WSDL/js&amp;__svcPath=
http%3a%2f%2fportaldev%3a8988%2fJava
WebService-JWS-context-root%2fMyWebService1SoapHttpPort%3fWSDL" />

The second is a Microsoft AJAX Extensions (Atlas) based Web service. This works fine.

<add src="http://localhost/AtlasService/AtlasWS.asmx/js?__svcPath=
http%3a%2f%2flocalhost%2fAtlasService%2fAtlasWS.asmx" />

The third is a Non Microsoft AJAX Extensions based Web service. Appending '/js' to the URI causes an HTTP 500 error.

<add src="http://localhost/NonAtlasWS/Service1.asmx/js?__svcPath=
http%3a%2f%2flocalhost%2fNonAtlasWS%2fService1.asmx" />
  </references>

This example shows the beginning of an interoperability problem. Three different methodologies are necessary for communication among the three services—service reference for Atlas, bridging for non-Atlas ASMX, and hand-coding of SOAP for Java—which is a development problem. This interoperability concern is not limited to Microsoft and its Atlas toolkit. Other server-side toolkits exhibit the same properties.

Interoperability Is a Key Requirement
The growing demand for Web 2.0 applications doesn't leave you with a choice about whether or not to use vendor toolkits to generate your apps' Ajax code. This article showed one example where dependency on a toolkit created problems with interoperability of client-based aggregation in Web services.

When building Web 2.0 products today, you must think about these challenges before you begin developing your apps and brainstorm ways to solve them. The Microsoft Atlas approach, where the service generates its own proxy, is a great place to start; and if you're not using this API, you might want to build something similar to it in your Web services. But despite precautions, you will still find additional challenges when using different browsers, as well as using more complex Web services, such as those that require security and authentication.