While hypothetical case studies are sometimes interesting, nothing beats examining a real company offering a real product. A few years ago, our team sat down to create our first product, called eventSherpa. In sharing our experience with building this product, we hope to illustrate why the marriage of Linux servers and Windows clients is an important one.

Why Both Windows and Linux?

While Linux is making great inroads on the desktop, the dominant player is still Windows in most, if not all, of our target enterprises. In reality, when developing new applications for these enterprise desktops, the decision often comes down to either a rich Windows client or a Web application offered through the browser. A Web application, regardless of its many benefits, in our case was not the perfect choice as our service required a very rich user interface and the ability to integrate easily with other office productivity applications. We decided to use Visual Studio .NET to build our rich Windows client.

At the same time, our proposed desktop client would also leverage the Web to provide additional services to our users. Web services fulfill that need, enabling our desktop client to add the networked services. At a past technology startup, I've run a Windows-based Web server farm, and I remember vividly my nightmares of scheduled reboots and server crashes during product demonstrations. Given our current budget restraints and the stability we've grown accustomed to with our Linux-based Web servers, we are hesitant to give IIS another chance. With the ever-growing number of open source projects available, developing on the Linux platform aids us in our rapid application development. Our primary concern with this approach is the added complexity of developing advanced Web services that interoperate flawlessly with our .NET client. Fortunately, many open source packages have matured significantly in the past few years, enabling smooth integration. We decided to build our Web services to be offered using the Linux platform.

Advantages of a Windows-Linux Marriage

• Maximum desktop reach: Let's face it - the majority of users in most enterprises are running Windows on the desktop.
• Low licensing costs on the server: No expensive Windows licenses to purchase as we scale the service. Depending on our choice of database, we may also save considerably on database license fees.
• Stability and reliability on the server: Resuming counseling for my IIS nightmares is not an option.
• Reusable libraries are available at low or no cost for server development: While there are many sites devoted to facilitating code exchange between Windows developers, there are a greater number for Linux. The Linux community thrives on collaboration and openness.

Disadvantages of a Windows-Linux Marriage

• A hybrid solution requires multiple complementary skill sets: Developers have to be split across skill sets or trained in both.
• The client is not cross platform: Although the DotGNU and Mono projects are advancing quickly, our .NET client will most likely never be cross platform as we integrate it with other office productivity applications and operating system functions.
• You may experience hiccups with advanced Web services utilizing complex data structures: Perfect interoperability is not yet there with many open source packages for implementing SOAP on Linux.

The State of the Union

In developing Web services on Linux, there are indeed many options. Java, PHP, and Perl are some of the more popular choices when selecting a language for development. Protocol-wise, XML-RPC (an XML-based protocol for performing remote procedure calls over HTTP) and SOAP are both frequently used. There are many industry examples to reference as success stories. Six Apart's Movable Type is written in Perl and offers Web services via XML-RPC. eventSherpa currently employs PHP, XML-RPC, and SOAP in providing connectivity to the client.

Given the built-in support, SOAP is an ideal choice for consuming Web services using Visual Studio .NET. Using freely available libraries, XML-RPC with .NET is also a viable option. The remainder of this article focuses on exploring a Web service that utilizes SOAP for the inter-machine communication.

A Simple Example

In creating an example, let's involve what many are calling the technology of 2004 - RSS. RSS is a Web content syndication format based upon XML. Depending on who you talk to, RSS stands for either Really Simple Syndication or RDF Site Summary. RSS is being used by the media, companies, and individuals to syndicate information in machine-understandable format. RSS is used by CNN, the New York Times, the BBC, and many other major media players, not to mention hundreds of thousands of bloggers.

One problem with RSS is that there are many versions available, and new offshoots like Atom are still emerging. Keeping the RSS parser on the server allows us to add support for new RSS formats without upgrading our client application. For this example, we will build a simple Windows .NET C# client that passes a RSS reference URL to the server. The server will parse the RSS feed and return a list of syndicated articles for the client to display.

Creation of the server and client applications should take you less than 20 minutes. The finished projects are available for download.

Building the Sample Server

In order to assist us with parsing and manipulating the RSS feeds, we can use another open source package called Mag-pieRSS. MagpieRSS is compatible with RSS .9 through RSS 1.0, and supports the RSS 1.0 modules.

Begin creating your SOAP server by creating a PHP file called index.php, and set the include path to include the NuSOAP and MagpieRSS libraries.

<?
ini_set("include_path", ".: /linuxworld:/linuxworld/magpierss-0.6a");
require_once('nusoap.php');
require_once 'rss_fetch.inc';

Now create a SOAP server object and define your namespaces. In order to the have the generated WSDL work flawlessly with your .NET client, ensure that you set your server and schema namespaces to be the same.

$server = new soap_server;

$server->configureWSDL('RSSReader','http://www.thehookup.ca/linuxworld');
$server->wsdl->schemaTargetNamespace =
'http://www.thehookup.ca/linuxworld';

Now add your user-defined data types. In our case we'll pass back to the client an array of structs. Each struct contains the article name and URL. Ensure that standard types supported by NuSOAP, such as string, are preceded with "xsd:". Precede user-defined types with "tns:" (see Listing 1).

Now create the function that utilizes MagpieRSS to fetch the RSS feed and parse it into our user-defined array of structs. This is the main function for our server that provides the core functionality. It is created no differently than any other PHP function; we simply expose it using NuSOAP later in the code (see Listing 2).

Finally, register the function with and enable the SOAP server. You can see that we define what we expect as input and what we will return to the SOAP clients, including type information (see Listing 3).

When you visit the URL for the Web service in a Web browser you should see a human readable version. Clicking the WSDL link displays the autogenerated WSDL file and provides you with the URL that you will use in creating your client (see Figure 1).

Our sample PHP Web service is now complete, and once it's deployed we're ready to build our sample client. If you do not have access to hosting, you may use my version hosted at www.thehookup.ca/linuxworld/.

Building the Sample Client

Now you need to enable support for consuming Web services (see Figure 3). In the Solution Explorer right-click on References and select Add Reference. Under the .NET tab, select System.Web.Services.dll.

There are a couple ways to consume our newly created PHP Web service from within Visual Studio .NET. For this article we will create a proxy class (see Figure 4). Open a .NET Command Prompt and use the Web Services Description Language Utility wsdl.exe tool to generate a proxy class for your PHP Web service. Type "wsdl URL_TO_WSDL_OF_WEB_SERVICE" in the .NET Command Prompt. For example, "wsdl http://www.thehookup.ca/linuxworld/index.php?wsdl".

Now add your newly created proxy class to your project by right-clicking on your project and selecting Add Existing Item.

Your proxy class should now be listed in the Solution Explorer (see Figure 5). Double-click RSSReader.cs within the Solution Explorer to examine the generated code.

Now add the code in Listing 4 to your main entry point for the application.

Press Debug, then Start, and you should see the Console displaying your Web service results (see Figure 6).

That's it! You've successfully integrated a Windows .NET C# client with a Linux- hosted PHP Web service.

The sample code for both the client and server can be found at www.thehook up.ca/linuxworld/samplecode.zip.

Summary

References