Object oriented programming has been the dominant technology for some time now - it's very successful for developing `normal' applications, and approaches like RMI (and others like CORBA and Microsoft .NET Remoting) basically amount to extending the OO model to distributed applications. And it clearly works in that we can build code that does what it's supposed to. However, it's not without its problems.
There's now a general view that stretching the OO model to distributed systems was a mistake: and we should look at some different paradigm. We are just at the beginning of the technological development in this area, and a consequence of that is that the whole area is vague and confused. The definitions of concepts (`SOA', `REST', `RPC', `Web Service') are rather vague and people don't really agree on them; technologies now used for one purpose were originally introduced for another. As far as possible, we'll try to explain the development and current situation in the field, but be warned - all is not clear.
The first stage in the development of an alternative to RMO-like systems was the use of XML to encode method calls and responses, instead of using some specially-designed format, and to use HTTP, FTP, or some other well-established protocol to handle the communication (if you don't know anything about XML, it's in a later chapter). The reason was simply this: existing technologies - RMI, CORBA - had trouble with firewalls and network security. So why not replace them with technologies that are well established in networking? Quite often you'll find statements saying that doing this is `web services' - but strictly, web services are more than this.
The initial technology for this was the very simple XML-RPC - XML - Remote Procedure Call A remote procedure call is exactly what it says: a call to a procedure/function/method on a remote machine. It's a well-established term and concept (at least decades old). XML-RPC was, and is, very simple, and it later gave rise to the more sophisticated SOAP. This orginally stood for Simple Object Access Protocol; then this changed to Service Oriented Architecture Protocol; and now it just stands for SOAP. (PHP has a similar acronym revisionism history.)
These XML based technologies have a number of advantages.
There are a couple of disadvantages too: the system is generally less efficient, because the packaged data is larger and there is no persistence of connections over multiple calls, and because we can't pass executable code we can't do so many `clever' things. However, there is a growing feeling that lots of these `clever' things (like Sun's general purpose compute server) are a bit too clever, and ultimately make life difficult and complicated. An analogy would be the self-modifying programs that were popular in the 1960s and early 1970s, before software engineering and other principles made it clear that, clever or not, such things were bad practice.
It's important to realise that early work on XML-RPC and SOAP was simply aimed at replacing the existing mechanisms based on the concept of remote procedure calls - that is, the client would package up some arguments in a specific way, call a specific named procedure (or function, or method) on the server, and get back specifically packaged results. Such systems are tightly coupled - you can't just replace the server with something else unless it understands the precise syntax (modulo binding issues) and semantics the client expects. This is fine and well established and reliable for communication within an application. However, the fact that a widely-understood standard for message passing (XML-RPC or SOAP) is being used to communicate gives us the opportunity to relax, or loosen the coupling between applications.
A commonly-used analogy is a DVD player. DVD players provide a service - playing DVDs. You can put any DVD in a player and, assuming it's not defective and ignoring regionalization issues, it will play. What's more, you can replace the DVD player with another one, and expect it to work. This is because DVDs are a widely-understood standard. The object oriented analogy would be that every DVD would come with its own player - since data and operations are linked in the OO paradigm.
A different and more useful analogy might be a stock market data service (providing equity price data). If we can manage to loosely couple it with our client application that consumes its data, then there is no reason why we would be dependent on a specific service provider - we could change to a new one if the old one became unavailable, or a better or cheaper one came along. And we should be able to do this without substantial (or ideally any) changes to our application. Applications structured in this way are commonly called service oriented architectures (SOA).
This might seem a lot to ask, but with XML formatted data it's pretty easy. Even if the XML data is not in exactly the same format, then it's straightforward to transform it using technologies like XSL (a bit more on that later), and we can specify which bits of the data we want with tools like XPath. In essence, the service is supplying a document from with the client picks the bits it wants, rather than just responding with the specific bits of data that the client requests, via some arguments to some method call.
If this all sounds a bit vague, then that's because it is - you can show the same application to different people and they will disagree whether it's RPC or SOA. And that's because everything is currently in its infancy. To confuse things further, there's another alternative - Representational State Transfer, or REST. REST is arguably a derivative of SOA, though it has an independent development. REST is based on the concept of resources, identified by URIs. So, for example, an RPC version of our stock data example would probably be based around methods, like:
int getStockPrice(String stock) {...
and a call might look like:
int value = stockServer.getStockPrice("IBM");
In contrast, with REST, the value of IBM's stock would be associated with a URI:
http://www.OurStockServer.com/stockprices/IBM
where the URL is (probably in this case) dynamically generated. What we have done is encode the semantics of the method call and it's parameters in the URL, instead of a traditional method name and argument list.
There is much more, obviously, to REST than this - and much more to SOA. But this is a technology-focussed module: not software engineering. So we won't go into any more strategic detail here. Like all methodologies, SOA, REST and so on have their place: for some applications they are well suited, and for others they are not. Although this is fairly obvious, as usual in such cases, they have their fans who think that their own favourite is suited to (nearly) everything.
As well as loose coupling, there are a number of other characteristics of SOA (and REST). Note that these are somewhat `ideal' and occasionally violated in practice.
Our main focus in this module is getting the technology to work: in practice, RPC, SOA and REST are founded on the same technological tools (though don't have to be, but in practice they are). That is, XML encoded method, or service, calls and responses over, usually, HTTP. To understand how they work, and get them working, we need to know a bit about XML, how the interface to a service (including syntax and semantics) is encoded in XML, using the Web Service Description Language (WSDL), and how to actually write them and their clients. We are going to write them in Java in this module. If you also study the successor module to this one, you will get to do them in .NET as well.