.NET is designed from the ground up to work with XML Web services, along with all the other Internet standards and protocols. XML Web services in .NET and Visual Studio .NET are not a design afterthought like they are in some languages and tools. It typically takes about 4 to 5 times more code to add XML Web services capabilities to a .NET application compared to one written in Java using tools such as JBuilder. XML is also baked into the CLR. Now streaming, parsing, and passing XML has never been easier and makes the CLR a powerful proposition, even without mentioning anything else. Using XML, you can now build standard services that can be invoked from anywhere on the Internet. As far as providing Web services in general, you don't even need .NET. Web Services can be built from scratch as long as you've provided the standard means of describing what services you offer and allow them to be invoked in standard fashion. Using .NET just makes this much easier. You can now just select the language you feel most comfortable with to implement these services.
You can also distribute any service to any device that speaks to the Internet and can read an XML stream. This idea changes how applications are viewed . Applications can now be sold as a set of services instead of an entire product. These are acute to mini-application service processors for those looking to leverage existing services within their own frameworks. No longer does each end point of a communication channel require that each support a proprietary and vendor-specific protocol. As long as you are on an Internet or other TCP/IP-based backbone and interchange data using XML, you now can speak freely to one another. Clients no longer have to be tethered to wired networks and can even consist of a cell phone (as in the case of Pocket PC).
To see one of the first nontrivial public implementations of a Web service, check out http://terraserver.microsoft.net/. The Web service on this site features map and aerial photograph information from around the world utilizing the Microsoft TerraService project, along with information from the U.S. Census Bureau. To see a map or aerial photograph of any city, simply enter the city in the Find Place edit box at the top of the screen. Figure 1.2 shows an aerial photo of San Diego. On this screen, you can vary the output by using the provided ASP.NET form that will give you an update shot and clicking the Go button. This page provides the viewer with a typical Web-site-like user experience. However, this site is actually based on XML Web services and now can be seamlessly invoked by a process other than that of a user using a browser. Using .NET Web service methods , Terra server information can now be retrieved in a programmatic way. Here I use my browser to interact with the TerraService (http://terraserver.microsoft.net/terraservice.asmx) but this could even be done from most non-.NET development environments that support HTTP or SOAP, such as Visual Basic.
Figure 1.2. The TerraService main page used for interactively viewing maps and aerial shots.
Using the following list of Web methods (Figure 1.3), other services (Figures 1.4 and 1.5) can easily incorporate TerraService information into their own sites and applications.
Figure 1.3. Web methods list from TerraService.
Figure 1.4. The GetPlaceList Web method entry page from TerraService.
Figure 1.5. The GetPlaceList results after searching for Houston.
Other forms of public Web services already available include:
By the time this book is published, there will be many more XML Web services publicly available, some of which will still (I hope) be free. Not all XML Web services will be implemented using .NET but as an information consumer, it usually will not matter. The point is that information can now be shared in a uniform manner using XML Web services, and it does not matter how they are implemented. This opens up many challenges to designers and architects building systems that will externally leverage these services.
Some of the issues a Web service consumer will face are:
This also presents those wishing to distribute their own services with an entirely different set of business opportunities and confrontations . The issues for a Web service provider are the same as those for a consumer (e.g., security, change control), with the following additional concerns:
When you combine the fact that several developers have never worked with a true object-oriented system or with Web service models, you should begin to appreciate the paradigm gap these folks will face. I hope you will also begin to see the need for design guidance. Microsoft itself is even beginning to provide more developer collateral in the areas of design principles and architecture guidance. The .NET framework makes it all the more simple to begin playing with objects and Web services. However, when you get past the initial "hello world" sample, you will begin to face some interesting design challenges. Now more than ever does the following OO adage apply: The better the discipline, the better the application. Rarely should developers now rely on the fact that they can throw a system together without design initiatives in hand. For those Java converts (and there will be many ”I'm one), this won't even be a question; it will be a requirement.
Unfortunately, I don't have the room to exhaust all there is about XML Web services and how to build them with .NET. There will be plenty of books devoted solely to that topic. However, for those who have not had any exposure to them, I've provided the following primer in hopes that the material in this book can be better understood .