Introduction
One of the more confusing items about Web Services regards defining exactly what and why they are. Let's begin with why they exist.
Web Services exist to make it easier to integrate applications. Existing technologies include Java RMI, CORBA, and DCOM. All of these technologies work over networked environments and allow for application integration. This application integration is possible if all the components are reachable over a LAN. However, when going out to the public Internet, these networked applications start to break down. Another problem is that none of these technologies work well for cross platform, cross language integration. Often, working with one of these technologies ties you to a particular language, operating system, or toolkit that must be uniform across the solution. In today's world, the odds of having all systems being written in the same language or using the same operating system and interconnection libraries is fairly small. Add to this a desire to connect these applications across large distances using the Internet and you will find that almost all of these technologies come up short. The necessity of addressing these shortcomings gave birth to Web Services. So, what are they?
A Web Service is a programmatic interface that is accessible via the Internet. As such, it must rely on standardized protocols. You may be aware of the various technologies surrounding Web Services. SOAP (an abbreviation that does not really mean anything anymore), Web Services Description Language (WSDL), and Universal Description Discovery and Integration (UDDI) are just a few of the technologies that are a part of Web Services. To make Internet accessibility a reality, SOAP v1.1 and v1.2 rely on existing, widely deployed technologies. The de facto minimum requirements for Web Service interaction state that the platform, whether client or server, must understand the following standards:
Hypertext Transfer Protocol (HTTP)
Transmission Control Protocol/Internet Protocol (TCP/IP)
eXtensible Markup Language (XML)
XML Schema Definition (XSD)
Due to the wide adoption of the Internet and XML, it is extremely difficult to find an operating system or programming language that does not have some support for these standards. Because the interest in Web Services is building to a fever pitch, vendors and individuals are rallying to make additional Web Service–specific tools available. While not a silver bullet for interoperability woes, talking to other languages and platforms just got a lot easier to do.
For many people, the promise of interoperability drew them into learning more about Web Services. As a Visual Basic developer, this promise may have caused you to buy this book. One question probably remains: How real is this promise of interoperability? For any two implementations to work together, they typically have to agree on two items: what the WSDL for a particular interface looks like and how to represent the SOAP message for any given operation in XML. To this end, the many serious development teams and individuals are working together to make sure they all agree.
At XMethods, http://www.xmethods.com/ilab, you can see a list of all the participants. This page also describes what it means to pass or fail the set of tests, as well as the tests themselves. If an implementation is not a part of this effort, you should steer clear of it. Yes, the Microsoft implementations are active in this process.