1. Chapter 1 Introduction To Web Services
“Imagination is more important than knowledge.” Albert Einstein.
You’ve probably heard about Web services and may have read about them. It seems like every trade publication, book, and Web site has some mention of Web services. Unfortunately, most of the current coverage of Web services do not clearly explain what they are really all about, they just trumpet how wonderful Web services are, which comes across as hype. In this chapter I focus on two things: Explaining what Web services are really all about and showing you scenarios where you would use Web services and scenarios where you really should not use them.
Distributed Applications and the Browser
If you look around at today’s application development, you’ll find a definite shift towards thin, browser-based clients. Obviously this is not because thin clients offer a richer user experience, it’s because such clients eliminate the high costs of deploying an application to the desktop. Desktop applications are costly to deploy partly due to the issues of installing and configuring the application and partly due to the issues of communicating between the client and the server.
Traditionally, a rich Windows client uses DCOM to communicate with the server and invoke remote objects. Configuring DCOM to work properly in a large network is usually a challenge that most IT professionals dread. In fact, most IT professionals would rather put up with the limited functionality of a browser than the issues of running DCOM over an intranet. The result, in my opinion, is an application that is easy to deploy, but difficult to develop and severely limited in its user interface. This ultimately means you spend more time and money developing what is, from a user’s standpoint, a less functional application. To know exactly what I mean, ask an accountant what they think about the new Web-based accounting application that replaced the older Windows version. Most business application users would rather have the rich Windows user interface.
An ideal solution to the client-server communications problem is to use HTTP as the communications protocol[1]. HTTP is a good choice because any machine that can use a Web browser is by definition running HTTP. Also, many firewalls today are configured to allow only HTTP traffic.
Interoperability
Another issue that many business applications face is that of interoperability with other applications. It would be great if all applications were written in COM or .NET aware languages and running on Windows. However, the fact is most business data is still kept on mainframes in non-relational (VSAM) files and accessed by mainframe applications written in COBOL. There are also many business applications being developed every day in C++, Java, Visual Basic, and a variety of other languages. Today, all but the simplest applications need to integrate and exchange data with other applications running on heterogeneous platforms. Integrating such applications is typically done on a case-by-case basis via file transfer and parsing, message queuing, or possibly proprietary APIs like IBM’s Advanced Program to Program Communication (APPC). There were no standards that enable two applications to communicate regardless of their platform, component model, and programming language. Through Web services standards, clients and servers can communicate over HTTP regardless of platform or programming language.
What are Web Services
There are at least two answers to the question “What are Web services?”. On the surface, a Web service is simply an application that exposes a Web-accessible API. That means you can invoke this application programmatically over the Web. Applications invoking this Web service are referred to as clients. For example, if you wanted to build a Web service that returns current weather information, you could build an ASP page that accepts a zipcode in the query string and returns a comma-delimited string containing the current temperature and condition. To invoke this ASP page, the client would send an HTTP GET request with a URL that looks like this:
http://host.company.com/weather.asp?zipcode=20171
And the returned data might look like this:
86,sunny
This simple ASP page is a legitimate Web service because it exposes a Web-accessible API based on HTTP GET requests. But there is a lot more to Web services than that.
Now for a more accurate explanation of Web services: Web services are a new, standard platform for building interoperable distributed applications. As a Windows developer, you’ve probably built component-based distributed applications using COM and DCOM. While COM is an excellent component technology, there are certain scenarios where it doesn’t work well.
The Web services platform is a set of standards that applications follow to achieve interoperability via the Web. You write your Web services in whatever language and on any platform you like, as long as those Web services can be viewed and accessed according to the Web services standards.
The New Platform
The Web services platform needs a minimum set of features to enable building distributed applications. Any platform must have a data representation format and type system. To enable interoperability, the Web services platform must provide a standard type system that bridges today’s differences between type systems of different platforms, programming languages, and component models.
Traditionally, interface-based platforms for distributed systems have provided some means of formally describing interfaces, methods, and parameters. Similarly, the Web services platform must provide a means for describing a Web service and providing the information others need to invoke this Web service.
Finally, there must be a mechanism for invoking Web services remotely, similar to a Remote Procedure Call (RPC) protocol. To promote interoperability, this RPC protocol must be platform and programming language independent. The next sections briefly describe the technologies that make up the Web services platform.
XML and XSD
Extensible Markup Language (XML) is the basic format for representing data on the Web services platform. In addition to being simple to create and parse, XML was chosen because it is neither platform nor vendor specific. Being neutral is more important than being technically superior: Software vendors are much more likely to adopt a neutral technology rather than one that was invented by a competitor.
XML provides a simple way of representing data, but it says nothing about the standard set of data types available and how to extend that set. For example, what exactly is an integer? Is it 16, 32, or 64 bits? Such details are important to enable interoperability. The W3C XML Schema (XSD) is a standard that specifies some built-in types and language to define additional types. The Web services platform uses XSD as its type system. When you build Web services in your programming language (e.g. VB .NET or C#), the data types you use must be translated to XSD types to conform to the Web services standards. The tools you use might automate this translation for you, but you are likely to have to tweak the result a bit to meet your needs. Chapter 2 explains XSD and how to translate custom types (e.g. classes) to XSD types.
SOAP
Once you’ve built a Web service, you and/or others will want to invoke it. The Simple Object Access Protocol provides the standard RPC mechanism used for invoking Web services. A clever acronym, SOAP is actually a bit of a misnomer: It implies that the underlying Web service representation is an object when in fact it does not have to be. You can write your Web service as a series of functions in C and still invoke it using SOAP. The SOAP specification provides standards for the format of a SOAP message and how SOAP should be used over HTTP. SOAP also builds on XML and XSD to provide standard rules for encoding data as XML. Chapter 3 discusses SOAP and explains the components of SOAP messages.
WSDL
How do you explain to others the functions that your Web service exposes and the parameters each function accepts? You might do it informally by writing up a document that provides this information or you might even tell it verbally to someone who needs to invoke your Web service. The informal approach has at least one serious problem: When a developer sits down to build a client for your Web service, his development tool (e.g. Visual Studio) cannot offer him any help because that tool has no idea about the Web service’s functions and parameters. Providing a formal description in a machine-readable format would solve this problem. The Web Service Description Language is an XML-based grammar for describing Web services, their functions, parameters, and return values. Being XML-based, WSDL is both machine and human readable, which is a big plus. Some modern development tools can generate a WSDL document describing your Web service as well as consume a WSDL document and generate the necessary code to invoke the Web service. Chapter 4 explains the WSDL grammar and shows you examples of WSDL documents generated by various tools.
Typical Web Service Architecture
Regardless of the tools or programming languages you use to build Web services, the high-level architecture is typically as shown in figure 1-1 assuming you are using SOAP over HTTP to invoke the Web service. You’ll typically build your Web service using your favorite programming language (e.g. VB 6 or VB .NET) then expose it using the SOAP Toolkit or .NET’s built-in support for Web services. A client written in any language and running on any platform, can invoke your Web service by processing the WSDL document that describes your service. The client then formulates a SOAP request message based on the service description. Your Web service will sit behind a Web server, typically Internet Information Server (IIS), which receives the SOAP request message as part of an HTTP POST request. The Web server forwards these requests to a Web service request handler for processing. For VB 6 Web services, the request handler is either an ASP page or an ISAPI extension working together with the SOAP Toolkit components. For VB .NET, the request handler is part of the .NET framework. The request handler is responsible for parsing the SOAP request, invoking your Web service, and creating the proper SOAP response. The Web server then takes this SOAP response and sends it back to the client as part of the HTTP response.
Figure 1‑1 Typical Web service architecture.
Remote Procedure Calls vs. Messaging
Web services are all about applications communicating. There are two common ways that applications communicate today: RPC (Remote Procedure Calls) and Messaging. The difference between the two is largely a matter of approach and architecture rather than hard-core technical differences. SOAP supports both RPC and messaging and most of today’s tools (including the Microsoft SOAP Toolkit and .NET Web services) support both formats. Which one you use depends on how you perceive your application’s architecture.
When using RPC, the client thinks in terms of invoking a remote procedure on the server. This usually means instantiating a remote object and invoking its methods or properties. Thinking is centered on the remote object and its interface, i.e. the properties and methods that it exposes and their parameters. DCOM and .NET remoting are examples of RPC mechanisms.
Messaging is typically associated with more loosely coupled systems. A messaging client thinks in terms of sending a message to a server and, possibly, receiving a response message. Thinking in messaging systems is centered on the request and response message format rather than the remote object’s interface. By focusing only on message formats, the client and server are less tightly coupled than in the case of RPC.
Many RPC systems try to provide location transparency: They expose the remote object’s interface as if it were local and hide what’s being sent on the wire so the client does not need to worry about the fact that the server object is on another machine. For example, when you use VB 6 to invoke a remote object via DCOM, your code could look identical to that invoking a local object. Messaging systems on the other hand, let you control what’s on the wire (i.e. the message payload) and hide what’s on the other end. The client has no idea how the server is implemented or how it processes the message.
That being said, you could create a messaging server that dispatches calls to objects based on the messages it receives. This effectively implements RPC via two-way messaging. If the client still thinks and operates in terms of messages, you would call it messaging. If the client thinks and operates in terms of instantiating and invoking a remote object, you would call it RPC.
When you implement XML-based messaging, most of your focus will be on the XML request and response messages. Tools for building Web services in VB .NET do much of the work involved in XML messaging. VB 6 tools (the SOAP Toolkit) also does a great deal of the work, but you have to do a little more work yourself compared to .NET. Therefore in many cases, you’ll need to do some message manipulation yourself. Understanding XML and XML Schemas is essential to effectively implement XML messaging systems.
Throughout this book, you’ll find recommendations to use messaging over RPC whenever possible. This is because messaging relies on XML Schemas to describe the data being transmitted. This close relations with the standard XML type system means messaging can be far more effective at interoperability.
Creating Web Services
By now you are probably anxious to get your hands dirty with some coding and to see Web services in action. This section introduces you to the mechanics of creating and invoking Web services in VB 6 and VB .NET. The intent is to expose you to the tools rather than to provide detailed coverage of how Web services work. The remainder of this book focuses on the inner workings of Web services and of the tools you use including the Microsoft SOAP Toolkit and .NET. See chapters 5 and 6 for details on building Web services with the SOAP Toolkit and .NET respectively.
Using the SOAP Toolkit
Microsoft’s SOAP Toolkit lets you expose COM components as Web services. There are three major components of the toolkit: SoapClient is a COM component that COM-enabled clients use to invoke Web services. SoapServer is a COM component responsible for processing incoming SOAP requests and returning the SOAP response. The WSDL Wizard reads your component’s type library and generates a WSDL document that describes the methods you want to expose.
Assuming you have a COM component that exposes a GetTemperature method:
Public Function GetTemperature(ByVal zipcode As String, _
ByVal celsius As Boolean) As Single
To make this component into a Web service, you start by running the WSDL Wizard and pointing it to the component’s binary (the .DLL). The Wizard will then ask you to choose the methods you want to expose, the URL of the Web service (e.g. http://VBWSServer/VBWSBook/Chapter1/Temperature/) and whether you want an ASP or ISAPI listener (figure 1-2). The wizard will then ask for the folder where the generated WSDL (and possibly ASP) file should be saved.
Figure 1‑2 Using the SOAP Toolkit Wizard to expose a COM component
To invoke this Web service, you use the SoapClient component from VB or any other COM-enabled client. The following code snippet invokes the Web service’s GetTemperature method:
Dim soap As MSSOAPLib.SoapClient
Set soap = New MSSOAPLib.SoapClient
soap.mssoapinit _
"http://VBWSServer/VBWSBook/Chapter1/Temperature/Temperature.wsdl"
MsgBox ("Temperature is: " & _
soap.GetTemperature("20171", False))
First, you initialize the SoapClient by calling mssoapinit and passing it the URL of the WSDL document. The WSDL document’s URL is made up of the URL that you specified when you ran the Wizard with the ServiceName.wsdl appended to it. Once the SoapClient is initialized, you can call the Web service methods as if they were SoapClient methods.
Using .NET
The .NET platform provides built-in support for building and consuming standards-based Web services. Unlike other development platforms, you do not need additional tools or SDKs to build Web services with .NET. All the necessary support is built into the .NET Framework itself including the server-side request handlers and the client side support for sending and receiving SOAP messages. This section gives you an overview of the steps to build and use a Web service with .NET. More details will be discussed starting in Chapter 6.
To build a .NET Web service you create a file with the .asmx extension. In this file, you put a WebService directive with the programming language you’ll use and the name of the class that is to be exposed as the Web service. You then write your class like your normally would adding a System.Web.Services.WebMethodAttribute attribute to each method that you want to expose as shown in listing 1-1.
Listing 1‑1 Creating a Web service with VB .NET. (VBWSBook\Chapter1\myService\calc_vb.asmx).
'a WebService in VB .NET (calc_vb.asmx)
<%@WebService Language="VB" class="Calc" %>
Imports System.Web.Services
Public Class Calc
<WebMethod()> _
Public Function Add(ByVal a As Double, _
ByVal b As Double) As Double
Return a + b
End Function
End Class
You can view a test page for this Web service by using a browser and navigating to the .asmx file. For example, if you placed the calc_vb.asmx file in a folder called myService under the VBWSBook virtual directory, the corresponding URL would be:
http://vbwsserver/vbwsbook/chapter1/myService/calc_vb.asmx
Navigating to this URL brings up the Web service test page shown in figure 1-3. This auto-generated page shows you the service name at the top followed by a list of methods exposed by this service. Below this list of methods, there’s a long essay explaining that you are using the default namespace http://tempuri.org/ and that you should pick a different, unique, namespace for your Web service when you publish it. I’ll discuss XML namespaces in chapter 2. In chapter 6, I will show you how to specify your Web service namespace and otherwise customize the service using CLR attributes.
Figure 1‑3
The auto-generated Web service test page.
If you click on the link to the Add method, you will get an HTML form that you can use to test that method (see figure 1-4). On this form, there’s an HTML input field for each parameter the method accepts. When you enter the parameter values and click Invoke, the form is submitted to the Web server. This is essentially invoking the Web service via an HTTP GET request. You get back the result in a simple XML document that looks like this:
<double xmlns="http://tempuri.org/">158</double>
Alternatively, you can invoke the Add method directly by navigating to the following URL:
http://vbwsserver/vbwsbook/chapter1/myService/calc_vb.asmx/Add?a=123&b=3
As you can see, the method name becomes the actual resource you are requesting (and it is case sensitive) and each method parameter becomes a parameter in the query string. This test form is very convenient for quickly testing a Web service. However, because it uses HTTP GET, it has some limitations on the data types and parameter directions it supports.
Figure 1‑4
The auto-generated HTML Form for testing a Web method.
If you go back to the Web service test page and click on the Service Desciption link at the top of the page, you can view the WSDL document describing this Web service as shown in figure 1-5. You can also go directly to this WSDL document by adding a query string with wsdl at the end of the URL:
http:// vbwsserver/vbwsbook/chapter1/myService/calc_vb.asmx?wsdl
Figure 1‑5
The WSDL document for the Calc service. Note that XML elements are collapsed to show you more of the document.
To invoke this Web service using a .NET client you first need to create a class that acts as a proxy for the Web service. Clients then invoke methods on this class and the class handles invoking the Web service.
While you could manually create such a class, there’s a .NET tool called wsdl.exe that can automatically generate the proxy class for you. This tool reads the WSDL describing your Web service and generates a proxy class that can be used to invoke that Web service. For example, to generate a proxy class for the Calc service, type the following at a command prompt:
wsdl.exe /language:VB http://vbwsserver/vbwsbook/chapter1/myService /calc_vb.asmx?wsdl
Listing 1-2 shows a snippet of the proxy class generated for the calculator service in VB. The generated proxy class inherits from System.Web.Services.Protocols.SoapHttpClientProtocol and exposes a method called Add that takes in two doubles and returns a double.
Listing 1‑2 Snippet of the Web service proxy generated by wsdl.exe.
Imports System.Web.Services.Protocols
'Other code omitted
Public Class Calc
Inherits SoapHttpClientProtocol
'Other code omitted
<System.Web.Services.Protocols.SoapDocumentMethodAttribute( _
"http://tempuri.org/Add", _
RequestNamespace:="http://tempuri.org/", _ ResponseNamespace:="http://tempuri.org/", _
Use:=System.Web.Services.Description.SoapBindingUse.Literal, _
ParameterStyle:= SoapParameterStyle.Wrapped)> _
Public Function Add(ByVal a As Double, ByVal b As Double) As Double
Dim results() As Object = Me.Invoke("Add", _
New Object() {a, b})
Return CType(results(0), Double)
End Function
'Other code omitted
End Class
Calling the Web service from a VB .NET client is as easy as creating an object from the Calc proxy class and invoking its Add method.
Dim ws As New Calc()
Dim result As Double = ws.Add(20.5, 10.9)
MessageBox.Show("Result is: " & result.ToString)
The proxy’s Add method will simply invoke the Web service using the .NET Framework’s SoapHttpClientProtocol class. It’ll then return the result that it gets back from invoking the Web service.
Of course there’s a lot more to creating and invoking .NET Web services than what I just showed you. But before we can dig into those details, you need to understand the underlying technologies that make Web services work, namely XSD, SOAP, and WSDL. The next three chapters explain the foundation for Web services then we dig deep into the tools and mechanics for building Web services starting in chapter 5.
When To Use Web Services
Now I’ll explain some scenarios where you can realize significant benefits by using Web services. After that, I’ll explain scenarios where it makes no sense to use Web services.
Communicating Through a Firewall
When you build a distributed application with hundreds or thousands of users spread over many locations, there’s always the problem of communicating between the client and the server because of firewalls and proxy servers. You cannot easily use DCOM in this scenario and you do not want to deploy a client to the thousands of users out there, so you end up building a browser-based client and writing a façade of Active Server Pages (ASPs) to expose the middle tier to the user interface. The resulting architecture is at best difficult to develop in and at worst down right impossible to maintain.
Consider what you have to do to add a new screen to your application: You must first create the user interface (the Web page) and the corresponding middle-tier components that represent the business logic behind the new screen. But you must also build at least one active server page that receives input from the user interface, invokes the middle tier components, formats the result as HTML, then sends a new “results page” to the browser with the results. Wouldn’t it be great if the client were easier to build with less dependence on HTML forms and if that extra step of building the ASP could be avoided?
You can avoid that step by exposing your middle tier components as Web services and invoking them directly from a Windows user interface running on client machines. To invoke the Web service, you can either use a generic SOAP client like the Microsoft SOAP Toolkit or .NET, or you can build your own SOAP client and roll it out with the application. Not only does this save on development time, but it also reduces the code complexity and improves overall maintainability. In addition, your application no longer has to navigate to a results page every time it invokes a middle-tier component. While using Windows clients requires that you deploy those clients, such deployment is becoming easier with .NET.
From experience, I can tell you that in an application with intensive interaction between the user interface and middle tier, this architecture can easily save 20% of the time spent on developing the user interface. As an added bonus, you end up with a layer of Web services that can be reused for any other purpose such as application integration. Ultimately, exposing your application’s logic and data via Web services provides a foundation for reusing your application from any sort of client running on any platform.[2]
Application Integration
Corporate developers know that a good portion of development efforts is spent on integrating applications written in various languages and running on disparate systems. You typically need to get data into your application from a legacy application running on an IBM mainframe or you need to send data from your application to a mainframe or Unix-based application somewhere. Even on the same platform, applications from different vendors often need to be integrated. By exposing some of its functionality and data via a Web service, an application provides a standard mechanism for other applications to integrate with it.
For example, you might have an order-entry application that’s used to enter new orders including customer information, shipping address, quantities, prices, and payment information. You might also have an order fulfillment application from another vendor. When a new order is entered, the order-entry application must notify the fulfillment application to have it ship the order. By adding a Web service layer on top of the fulfillment application, the “AddOrder” function can be exposed as a Web service. The order-entry application would invoke this function each time a new order is placed as shown in figure 1-6.
Figure 1‑6 Integrating applications using Web services.
Business to Business Integration
By using Web services to integrate applications, you can better automate business processes within a company. But what happens when the business processes cross company boundaries to span your company’s suppliers and/or customers? Integrating business processes across multiple businesses is commonly referred to as business-to-business integration.
Web services are an enabling technology for B2B integration. By using Web services, your business can expose vital business processes to authorized suppliers and customers. For example, you can expose electronic ordering and invoicing thereby enabling your customers to electronically send you purchase orders and your suppliers to electronically send you invoices. This is not a new concept: Electronic Document Interchange (EDI) has been around for a while. The key difference is that Web services are much easier to implement than EDI and operate over the Internet, which is widely available to businesses all over the world at a relatively low cost. However, Web services do not provide a complete solution for document interchange or B2B integration like EDI attempts to. Instead, Web services are a key enabling component in B2B integration with many other components typically needed to complete the picture.
The key advantage to using Web services for B2B integration is low-cost interoperability. By exposing your business functions as Web services, you are enabling any authorized party to easily invoke those services regardless of the platform and programming language they use. This reduces the time and effort it takes to integrate a business process across company boundaries and ultimately leads to savings in time and money. The low cost of integration opens up the playing field for smaller companies that found implementing EDI cost prohibitive.
Software Reuse
Software reuse can take place in various forms and at different levels. The most basic form of code reuse is through reuse of source code modules or classes. Another form of code reuse is binary component-based reuse. There’s a significant market today for reusable software components such as grids and other user interface widgets. But software reuse has always been limited by one key factor: You can reuse the code but not the data behind the code. The reason for that is that you can easily distribute components or even source code, but you cannot easily distribute data unless it is fairly static data not expected to change much.
Web services let you reuse code along with the data it needs. Instead of buying and installing a third party component and calling it from your application, your application would call a remote Web service. For example, if your application’s user enters a mailing address that you want to validate, you could send it to an address verification Web service. This service can lookup the street address, city, state and zip code to make sure the address exists and in the specified zipcode. The service provider might charge you a periodic fee or a per-use fee for using the service. A service like this is not possible with component reuse, you need to have the current database of street addresses, cities, states and zip codes.
Another scenario for software reuse is when you are building an application that aggregates the functionality of several other applications. For example, you might build an intranet portal application that lets the user check on the status of a FedEx package, check a stock quote, view their calendar, and purchase movie tickets. All these functions can be performed today on the Web using individual, separate applications. As those applications begin exposing their functionality through Web services, you can easily write a portal application that combines all their functionalities in one, consistent, easily accessible user interface as shown in figure 1-7.[3]
Figure 1‑7 Using Web services to aggregate functionality from many applications into one, consistent, user interface.
Many applications will take advantage of Web services to extend today’s component-based architectures to be a hybrid of component-based and service-based architectures. You will build applications that utilize one or more third party Web services to perform its function. You might also expose your own Web services for use by others. In all these cases, you are reusing code and the data behind it. This is an extremely powerful form of software reuse.
When Not To Use Web Services
This introduction would not be complete without explaining the situations where you should not use Web services. It is clear that Web services offer the most benefit in cases where interoperability and/or remoting over the Web are desired. That being said, there are many scenarios where you don’t benefit from using Web services.
Single Machine Applications
There are still many desktop applications for business and personal use. Some of those applications might need to communicate with others running on the same machine. In this case, it is almost always better to use a native API rather than a Web service. Software component technologies such as COM and .NET class libraries or components are very effective in this scenario because using such components requires relatively little overhead. The same applies to server applications running on the same server: Use COM or some other native API to invoke one application from the other. While it’s possible to use a Web service in this scenario, it is considered sub optimum and does not buy you anything.
Homogenous Applications on a LAN
In many cases, you’ll have applications developed using Visual Basic and/or Visual C++ and COM and running on Windows platforms on the same Local Area Network (LAN). For example, you might have two server applications wanting to communicate with each other or, more commonly, a Win32 or Windows Forms client that wants to communicate with its server counterpart on the same LAN. It’s much more efficient for two such applications to communicate using DCOM rather than SOAP/HTTP. Similarly, if you have .NET applications that need to communicate with one another over a LAN, you can use .NET remoting. Interestingly, .NET remoting offers the option of using SOAP over HTTP essentially acting as a Web service. But .NET remoting can also utilize a binary format, instead of SOAP, for RPC calls. This binary format is supposedly more efficient than using SOAP due to lower serialization/deserialization overhead. You can use remoting with the binary formatter over HTTP or directly over TCP. Using HTTP as the transport allows you to use remoting through firewalls while using TCP is supposed to yield better performance. Again, you would not use Web services in a scenario where you had other viable options that are more efficient or make more sense from an application architecture viewpoint. This means if you have a scenario where it is feasible to use .NET remoting with the binary formatter over TCP, that’s what you should use.
Summary
Web services are a new, standard platform for building interoperable distributed applications. The main thrust behind Web services is cross-platform interoperability. To achieve this, the Web services platform relies heavily on vendor and platform-neutral standards such as XML and XSD.
Web services offer tremendous value in scenarios that involve applications communicating across platform boundaries and over the Internet. Web service applications include application integration, business-to-business integration, code and data reuse, and facilitating communication between client and server over the Web.
However, Web services are no silver bullet and you should not use them just because you can. There are certain scenarios where using Web services will cost you performance without buying you anything. For example, homogenous applications running on the same machine or on different machines on the same LAN should not use Web services to communicate with one another.
The next chapters will explore the technologies that make up the Web services platform beginning with the Web service type system based on XML and XSD.