Chapter 13. Web Services

13.1. Web Services

Web services seems to have become the next big thing in computing these days, so I've made room for this chapter in the second edition of this book. However, trying to define the term is somewhat tricky; from one person's perspective, it may be correct, but from everyone else's it's probably completely off-base. I'm left with trying to boil down the hype and differences in implementation to a simple set of concepts that remain true across the board.

Web services is about interoperability. More and more, applications must communicate with each other. But the problems in communication grow, instead of shrink, with every new day of technology innovation. As more languages, increasingly complex data structures, and varied business needs develop, the difference between one system and another (even if they are performing the same business task!) also grows. For systems to interoperate, there must be a common language. This isn't a language in the sense that Java is a language; programs not written in Java must have just as much access as those that are in Java. Instead, it's a language that anyone with a dictionary can access; even if the words aren't the same, applications have access to the words, which can be translated into something that can be understood.

XML solves the problem of data transfer, and is one piece of that language. It is accepted and usable in almost every programming language around: C, Perl, Python, LISP, Java, Pascal, C#, Visual Basic. . . the list goes on and on. However, web service frameworks seek to go quite a bit further. The key to interoperability is not just data, but what data. What information can I get from your system? What can you find out from mine? In other words, there must be a means of broadcasting what services an application makes available. And this is where we have, until recently, had a gaping hole.

However, recent additions to the web services realm have begun to fill this hole. First, UDDI provides a means of discovering other services and registering your services for others to discover. Second, WSDL offers a way to provide the needed information about a discovered service to allow a client to interact with it. I've purposely left out the explanation of what UDDI and WSDL stand for and mean for now, because I want to focus on the big picture.

Figure 13-1 shows how the process flows. To begin, a service provider codes up a service (like you did in the last chapter). This service could be as simple as adding CDs to a catalog, or as complex as storing the VIN (vehicle identification numbers) for all automobiles registered in Massachusetts that are used by the government. As long as the service is web-accessible, it's a candidate for a service registry. This is all part of the UDDI portion of the picture. UDDI also allows a user to search all registered services for a specific service name, like "cd-catalog" or "govt-bin-numbers." The registry returns all the matching services.

Figure 13-1. The web services process

Hopefully, the client has found the desired service. But interaction takes more than just a name; it requires the URL to connect to and the parameters required, as well as the return value. This is accomplished through XML in a WSDL format, which I cover as well. And then, your client interacts with the located service, knowing (because of WSDL) you are using the service correctly. Life is grand, and all because of web services. Of course, I've skimmed over all the hard parts, but I'll delve into some of that complexity now that you have the big picture.