WSJ Integration

Digg This!

Page 1 of 2   next page »

The world was about to change, argued Don Box of DevelopMentor when he extolled the virtues of SOAP, the Simple Object Access Protocol, at the 2001 USENIX Conference on Object-Oriented Technologies and Systems (COOTS).

Listening to Box discuss the impending demise of Visual Basic - at least as it was known at the time - and DCOM due to the emergence of .NET and the Common Language Runtime (CLR), as well as animated discussions of a burgeoning new SOAP specification, was my introduction to the Service Oriented Architecture (SOA) Revolution. Of course distributed computing was nothing new, but certainly the scale and universality of the paradigm was set to explode - or so it seemed.

Since this conference, slowly but surely, much of what Box prognosticated has come to pass, albeit not as swiftly or universally as initially indicated. Microsoft .NET has not exactly taken the Web Services World by storm (or HailStorm for that matter), but Web Services in general are making serious inroads nonetheless.

The SOA Revolution
The SOA paradigm is revolutionary because it has changed our view of distributed components. More and more all kinds of organizations are thinking about how to design and build systems and APIs that are self-describing and easily used by other systems elsewhere in the universal federation of globally accessible software components. Today, in fact, a grassroots movement is afoot that seeks to build new and interesting applications out of public Web Services that are known as mashups. Mashups are of great interest because of the relative simplicity and agility with which complex functionality can be built using well-known tools and technologies like SOAP, Really Simple Syndication (RSS), JavaScript, and XML. Deriving complex functionality, simply, is a recipe for widespread adoption and involvement. In essence, this grassroots mashup movement is giving rise to patterns and technologies that can be employed in the enterprise to solve existing problems associated with (agile) external, as well as internal, data integration.

It seems much of the focus today with regard to SOA is on developing outwardly looking APIs for external consumers of an application's data and functionality (i.e., solving problems associated with extra-organizational data integration). For example, a lot of buzz has been generated by Representational State Transfer (REST) - and SOAP-based APIs made available by large commercial Web applications such as eBay, Google, Craigslist, and Yahoo, which are exposed so hackers around the world can create fanciful new mashups - and more market interest and brand awareness in the company exposing the interesting new functionality.

Technologists and average users alike are intrigued to see what interesting new software and eye-candy can be built out of the Web-based building blocks emerging on the Internet today (e.g., Google Maps). This is the sexy side of SOA, (which is arguably most useful for selling ads).

The not-so-sexy side of SOA means addressing the problems associated with the legacy software behind the average enterprise firewall that wasn't initially designed to share data with new and future software applications. It's, ironically, this not-so-sexy side of SOA that may offer the average enterprise the best return on investment (ROI), especially when patterns and technologies from the sexy side are employed.

So without further ado the remainder of this article will focus on the dark side of SOA: integrating new software applications with legacy software. In particular, this article will discuss the use of the gSOAP framework to SOAP-enable legacy C/C++ applications so legacy systems can be turned into Web-enabled APIs, accessible by SOAP-based interfaces for easy internal and/or external integration with existing, as well as future, systems.

As with the sexy side of SOA, agility and simplicity are key components of a successful data integration strategy. Lack of these ingredients may not prevent a working short-term solution, but may very well contribute to these system parts becoming more and more isolated and eventually abandoned over time.

Agility & Simplicity as Key Integration Ingredients
Successful well-baked software has just as many technical ingredients in it as non-technical. Some might say the non-technical ingredients are the most important; they are to software what yeast is to bread. Non-technical ingredients are the intangibles such as software team dynamics, flat organizational hierarchies, agile development methodologies, good, simple tools, and the encouragement of the hacker culture. So what exactly makes a tool or framework agile or simple, and what does this have to do with gSOAP and the SOA Revolution?

Agility and simplicity are the raison d'être behind technologies like SOAP. The Common Object Request Broker Architecture (CORBA) and Java's Remote Method Invocation (RMI), for example, are arguably not agile or simple frameworks comparatively speaking for solving interoperability problems; they're rather complex to build with and unwieldy to deploy. RMI facilitates distributed computing, but only among homogeneous Java components. CORBA opens up distributed computing to a wider array of objects written in other programming languages, but neither can scale to the level of HTTP and SOAP. What the early SOA revolutionaries realized is that most organizations run a Web server, and many use the default port 80 with firewall provisions for external access to this port. They also realized that there was a large Web developer community that understood Web servers and the Hypertext Transfer Protocol (HTTP) and XML. Long-term ROI from the technologies used is closely tied to grassroots developer acceptance of a given technology today. HTTP, unlike the Internet Inter-Orb Protocol (IIOP) employed by both RMI and CORBA, offers ubiquity in terms of use and infrastructure. It's lightweight and easy to understand. HTTP is an agile, simple protocol. SOAP piggybacks on top of HTTP making it an agile cousin. Agile, simple tools and technologies, therefore, provide greater ROI than their less agile, more complicated counterparts primarily because of such things as application maintenance, the implementation time due to simplicity and documentation, the universality of acceptance and adherence to standards, scalability, etc. Intangibles such as agility and simplicity have nothing and everything to do with SOAP, the SOA Revolution, and gSOAP.

What is gSOAP?
gSOAP is an Open Source (General Public License) SOAP-based framework that facilitates the generation of SOAP client and server code from Web Services Description Language (WSDL) files. Existing C/C++ header files can also be used to generate WSDL files. It provides native and user-defined C and C++ bindings to XML and vice versa. The current version of gSOAP is 2.7.7. Target platforms include MS Windows (Win32, Cygwin, and MS-DOS), Linux (Red Hat and SuSE), Unix (Solaris, HP-UX, FreeBSD, TRU64, Irix, QNX, and AIX), Mac OS X, VxWorks, WinCE, Palm OS, and Symbian. The gSOAP framework is supported and maintained by Genivia, a company founded by Robert A. van Engelen, an associate professor of computer science at the Florida State University. There are a number of SOAP-based frameworks to choose from these days, but gSOAP is one of the most performant. In sum, gSOAP is a lightweight framework easily employed to create Web Services from C/C++ components.

A Quick Introduction
The gSOAP distribution comes with many sample programs that should be sufficient to get up and running with the framework relatively quickly. For clarification relative to this discussion, however, a quick tutorial for writing a Hello World C++ SOAP service is presented. This brief example presents the fundamental elements required for Web-enabling legacy system functions written in C/C++ libraries using gSOAP.

A Hello World gSOAP Server
The first step when writing a Web Service is to think about the functionality you want to expose to the world. In this case, our simple Hello World function will be called shareLegacyData(). This will be the entry point of our SOAP endpoint. This function will in turn call a function in an existing static C++ library and will return the results of the library call. Listing 1 has the C++ code for the gSOAP server example.

Once compiled, this server can be run as a Common Gateway Interface (CGI) script in Apache or IIS by putting the resulting binary in the cgi-bin directory of your Web server as a quick way of getting a gSOAP server up and running. But CGI-based gSOAP servers aren't the only option. While it's beyond the scope of this article to discuss gSOAP servers in depth, it's worth noting the various server options:

1. Servers can be a CGI program (as just demonstrated).
2. Servers can be a CGI program using FastCGI or with the Apache mod_gsoap module.
3. Use the gSOAP framework to write your own multi-threaded standalone server using pthreads.

The server method you choose is completely up to you. Obviously there are pros and cons associated with each. Compiling your server as a simple CGI is probably the easiest route when getting used to the framework. Production gSOAP servers should probably employ the second or third option because of the inherent inefficiencies associated with CGI.

One key aspect of this simple example is the somewhat subtle integration of the SimpleLibrary class. This library can be compiled as a static or shared C++ library. If compiled as a static library, using this library in our example server class is straightforward when deploying the Web Service as a CGI server. Once compiled, the functions in the static SimpleLibrary class get baked into the end product - article.cgi - which requires no additional environmental configuration as in Listing 1.

If SimpleLibrary is compiled as a shared library (*.so), however, the SimpleLibrary.so shared library contains functionality external to article.cgi (not baked in), and must therefore be properly referenced at runtime using environment configurations like LD_LIBRARY_PATH, or otherwise making sure gSOAP Server can find the required shared libraries. As a result, to run article.cgi in Apache using libSimpleLibrary.so, for example, one could configure Apache by adding the following line to httpd.conf:

httpd.conf Configuration
SetEnv LD_LIBRARY_PATH /full/path/to/shared/lib

You could also copy libSimpleLibrary.so to /usr/lib, for example, to ensure the library is found for use at runtime.

Page 1 of 2   next page »