Distributed Systems Week part IV: The Service-Oriented Architecture

A hot thing these days is the Service-Oriented Architecture (SOA). The basic idea is that instead of focussing on self-containing applications, you focus on offering and using services. It’s a little like object-oriented programming. With OOP you identify the different parts that your system consists of, like customers, companies and bills. You think in terms of objects. With SOA you think in terms of services. Services like billing, customer administration, ordering.

*Why?*
Why is this so great? Well, whether it’s great depends on your situation. Let’s take the classic example of an online bookstore. The bookstore has different suppliers of books which each offer services to order books from them. To make the online bookstore more useful, the owner also wants to include book reviews. There’s another company offering a service that offers book reviews. All the bookstore owner has to do is tie the different services together. When a visitor wants to read a review of the book, the book review service is used. When the visitors wants to buy the book, the book is ordered from one of the book suppliers.

What should become clear from this example is that, as I said before, the book suppliers and book review company chose to act as services that other companies can take advantage of. Of course, this doesn’t mean services are only useful in a business to business scenario. If your company has different departements the different departements might also offer different services. The HRM departement offers services to handle salary and hiring; the different other departements offer services to retrieve reports on what they’ve been up to, that the management can use. The different services can be “aggregated” to supply the different users with more useful results.

Another reason to use services is because of legacy systems. Legacy systems are a big problem. They were written years ago in an obscure language like Fortran or COBOL and don’t work together with other parts of your system. You can’t afford to rebuild these legacy systems and you don’t really want to, these systems have worked for years and new stuff will only cause more trouble. Yet, you want to integrate these systems into the rest of your IT architecture. Do you feel it coming? Yes, indeed, you could build a thin layer on top of your legacy system that exposes its functionality as a service. One side of this layer communicates with your old system and on the other side offers a service to the rest of your IT architecture.

Are services a new idea in IT? No, not at all. The idea has been around for ages, generalized in the concept of RPC. RPC stands for Remote Procedure Call and is a way of running a procedure on a remote machine (who ever said all that IT buzz was hard to understand?). One machine offers a service that another can use through RPC. RPC is not a particular implementation or protocol, it’s just a concept that has multiple implementations.

*CORBA*
Until a couple of years ago CORBA, the Common Object Request Broker Architecture was the most well-known way to do this. The idea is that you supplied an interface to your service in “IDL”:http://www.omg.org/gettingstarted/omg_idl.htm (Interface Definition Language). IDL is a C++-like “language”. A small example:

interface salestax  {
float calculate_tax ( in float taxable_amount );
}

From this interface code can be generated for different languages (for example C++ and Java) to use this service. The protocol that is used for the combination is fully standardized. This means that you can call a service running on a mainframe from your PC, no matter how the different machines encode their bytes or different data types they use.

*XML Webservices*
For reasons not really known to me, people thought it was time for an XML protocol to do RPCs. The most commonly used one is “SOAP”:http://www.w3.org/TR/soap/, the Simple Object Access Protocol. Interfaces are published in another XML format called WSDL, WebService Description/Definition Language. Like with CORBA there are many tools that can convert WSDL descriptions into C++, C#, Java, Python, Perl, PHP and many other languages code. These things are called webservices because they usually run from a webserver using the HTTP protocol.

Because big corporations like “IBM”:http://www.ibm.com and “Microsoft”:http://www.microsoft.com are backing up this webservices initiative, it gets a lot of press. Everything seems to be about webservice these days. What’s cool about that webservices pop up everywhere. The “Google APIs”:http://www.google.com/apis/ for example, and “Amazon’s webservice”:http://www.amazon.com/gp/aws/landing.html. There are many directories that list publicly available webservices, for example “BindingPoint”:http://www.bindingpoint.com and “xmethods”:http://www.xmethods.net. These contain webservices that you’re free to use in your own websites or applications. Have a look at them, they might do something that might enrichen the user experience of your applications, as marketing guys like to say.

*Short reach RPC*
RPC is not something that is only used to cross machine boundaries, there are many mechanisms and reasons to use it locally aswell. What if applications have to communicate with one another? “iPodder”:http://ipodder.sf.net for example, after downloading new podcasts, adds the downloaded MP3s to iTunes and tells iTunes to synchronize with the iPod. How does it do that? On the Mac this is done using Applescript, which does, I suppose, also a kind of RPC. In Windows there’s a mechanism for that called COM, the Component Object Model. Once again, it’s an RPC mechanism. iTunes exposes an interface that other applications can use.

In Windows there are more of these RPC mechanisms for different purposes, for example COM+ and DCOM. In an attempt to unify all (or at least many) of these RPC protocols, Microsoft has a project called “Indigo”. Indigo will provide a set of APIs (which will be available for Windows XP, 2003 and Longhorn) that allow you to just do RPC, independent of it will actually use COM, COM+, DCOM or XML Webservices.

Tomorrow I’ll be talking about distributed computing.