 |  |
| |
In the last chapter, I focused on SOAP as a standalone technology; your application was a SOAP client talking to a SOAP server, based on nothing but Java and a servlet engine. While this is a perfectly good solution for applications in which you write all the clients and all the services, it is fairly limited for interoperating with other applications. If you've heard anything about SOAP, it's the interoperability aspect that has gotten it such good press lately. The last chapter was incomplete; it did not teach you how to do true servicing of other applications using SOAP as a transport mechanism. This chapter fills in the rest of the picture, and solves the remaining problems in interoperability.
To get you started, I apply some simple definitions to the overused term "web services." Although it's hard to quantify this term right now, since everyone is using it for their own particular flavor of software and architecture, some general principles apply. In almost every definition of web services, you'll find that there is a need for an exchange of information with other applications. This exchange needs a set of standards, and the two that are the most important (at least right now) are UDDI and WSDL. I cover both and show you how they fit in with SOAP. Finally, I'll try and pull all these various acronyms and technologies together into one concrete example to finish off the chapter.
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.
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.
|  | |
| 12.5. What's Next? |  | 13.2. UDDI |
Copyright © 2002 O'Reilly & Associates. All rights reserved.