The Basics of Web Services
The concept of sharing data between computers is hardly new. For years, developers have used such technologies as Distributed COM (DCOM) and Remote Data Services (RDS) to access objects that reside on servers across local area networks and even the Internet. However, with the recent introduction of Web services, many of the issues previously encountered when deploying and supporting DCOM or RDS solutions have radically changed for the better. In this article, we'll take a basic look at Web services and how to implement them, with code examples.
High Level Review
Before we dive into code examples, let's take a moment to review the general architecture of a Web service. We'll do this at a rather high level just to be sure you are familiar with the primary components of a Web service. You can find lots of documentation online that describes the architecture of a Web service in far more detail. For now, however, we'll assume you are relatively new to the Web service concept.
Web services provide the ability to share data with a large variety of clients. As the developer of the service, you do not need to know anything about the system your clients use. You build Web services using open standards that allow client developers to create and interact with Web services from a variety of sources. Using the Extensible Markup Language (XML), the data generated to and from your service is formatted in a standard, non-proprietary way. A client has no specific requirements to develop solutions that use your service.
Components
A Web service consists of three primary components:
- The SOAP "listener"
- The business logic object
- The discovery of Web service file (DISCO file)
Web services and clients use the Simple Object Access Protocol (SOAP) when communicating with one another. SOAP essentially allows a client to make a request to a registered object on a server via standard Internet protocols, such as HTTP. This means that, unlike DCOM or RDS, system administrators do not need to configure special ports to allow access to your Web service. Instead, the service can be implemented to run right over the same HTTP port that a typical Web server runs. This also allows your administrators to implement the appropriate security using tools they are already familiar with.
The second component of a Web service is what I call the "business logic object." This is the object that your clients need to access. This object can be a traditional COM object or a newer .NET component. However, the objects supported by Web services are not limited to Microsoft technologies. For instance, you can create and share a JavaBean or CORBA object.
The discovery file makes up the third component of a Web service. This is often called the DISCO file. Developers use the DISCO file at design time to obtain a reference to the Web service. When you create a service using Visual Basic or C#, Visual Studio will generate this file with the .vsdisco extension automatically. C developers will get a file with the .disco extension.
When your client developers link to a DISCO file using Visual Studio .NET, they can more easily develop against the service since it appears like a normal reference to an object. For example, your Web service fully supports the Intellisense features we've come to take for granted in previous versions of Microsoft development languages.
Together, these three components constitute a Web service. When you use Visual Studio .NET to create a Web service, all three components are built into a single Web service project. The SOAP listener and DISCO file are created automatically. This leaves you free to focus on implementing the business logic required by your object.
Print