Comprehensive interpretation: What is a Web service?

Distributed Applications and Browsers

Looking at current application development, you will find an absolute tendency: people are beginning to prefer browser-based thin client applications. This is certainly not because thin clients can provide a better user interface, but because it avoids the high cost of publishing desktop applications. Publishing desktop applications is costly, half because of application installation and configuration issues, and the other half because of communication problems between the client and the server.

Traditional Windows rich client applications use DCOM to communicate with the server and call remote objects. Configuring DCOM to work properly on a large network can be a challenging task and a nightmare for many IT engineers. In fact, many IT engineers would rather endure the limitations of the browser and not run a DCOM on the LAN. In my opinion, the result is an application that is easy to publish, but that is difficult to develop and has a very limited user interface. In the extreme, you spend more money and time, but develop applications that look weaker to the user. Don't believe? Ask your accountant what they think about the new browser-based accounting software: Most commercial users want a more user-friendly Windows user interface.

A good solution to the client-server communication problem is to use the HTTP protocol to communicate. This is because any machine running a web browser is using the HTTP protocol. At the same time, many current firewalls are also configured to allow only HTTP connections.

Many commercial programs face another problem, which is interoperability with other programs. If all the applications are written in COM or .NET, and they all run on the Windows platform, then the world is peaceful. However, in reality most commercial data is still stored as non-relational files (VSAM) on mainframes and accessed by mainframe programs written in the COBOL language. Moreover, there are still many commercial programs that continue to be written in C++, Java, Visual Basic, and a variety of other languages. Now, with the exception of the simplest programs, all applications need to integrate with and exchange data with applications running on other heterogeneous platforms. Such tasks are usually done by special methods such as file transfer and analysis, message queues, and APIs that only apply to certain situations, such as IBM's "Advanced Program to Program Communication (APPC)" of. Previously, there was no application communication standard that was platform-independent, building models, and programming languages. Only through the Web Service, the client and server are free to communicate using HTTP, regardless of the platform and programming language of the two programs.

What is a Web Service

We have at least two answers to this question. On the surface, a Web Service is an application that exposes an API that can be invoked over the Web. This means that you can programmatically invoke this application via the Web. We call the application that calls this web service a client. For example, you want to create a Web Service whose purpose is to return the current weather conditions. Then you can have an ASP page that accepts the postal code as a query string and then returns a comma-separated string containing the current temperature and weather. To call this ASP page, the client needs to send the following HTTP GET request:

http://host.company.com/weather.asp?zipcode=20171

The returned data is It should be like this:

This ASP page should be counted as a Web Service. Because it is based on an HTTP GET request, it exposes an API that can be called via the web. Of course, there are more things in the Web Service.

The following is a more accurate explanation of Web Services: Web Services is a new platform for building interoperable distributed applications. As a Windows programmer, you may have built component-based distributed applications with COM or DCOM. COM is a very good component technology, but we can easily cite that COM does not meet the requirements.

The Web Service platform is a set of standards that define how applications can interoperate on the Web. You can write web services on any platform you like, in any language you like, as long as we can query and access these services through the Web Service standard.

New Platforms

The Web Service platform requires a set of protocols for creating distributed applications. Any platform has its data representation method and type system. To achieve interoperability, the Web Service platform must provide a standard type system for communicating different types of systems in different platforms, programming languages, and component models. In traditional distributed systems, interface-based platforms provide methods to describe interfaces, methods, and parameters (such as IDL languages ​​in COM and COBAR). Similarly, the Web Service platform must also provide a standard for describing Web services so that customers can get enough information to invoke the Web Service. Finally, we must also have a way to make remote calls to this web service. This method is actually a Remote Procedure Call Protocol (RPC). In order to achieve interoperability, this RPC protocol must also be independent of the platform and programming language. The following three sections briefly introduce the three technologies that make up the Web Service platform.

XML and XSD

Extensible Markup Language (XML) is the basic format for representing data in the Web Service platform. In addition to being easy to build and easy to analyze, the main advantage of XML is that it is platform-independent and vendor-independent. Independence is more important than technical superiority: software vendors do not choose a technology invented by competitors.

XML solves the problem of data representation, but it does not define a standard set of data types, not to mention how to extend this set of data types. For example, what does the integer number mean? 16-bit, 32-bit, or 64-bit? These details are important for interoperability. The XML Schema (XSD) developed by the W3C is a set of standards that specifically address this issue. It defines a standard set of data types and gives a language to extend the set of data types. The Web Service platform uses XSD as its data type system. When you construct a Web Service in a language (such as VB.NET or C#), in order to comply with Web Service standards, all data types you use must be converted to XSD types. The tool you are using may have already done this conversion for you automatically, but you are likely to modify the conversion process to suit your needs. In Chapter 2, we'll dive into XSD and learn how to convert custom data types (such as classes) to XSD types.

SOAP

After the Web Service is built, you or someone else will call it. Simple Object Access Protocol (SOAP) provides a standard RPC method to invoke a Web Service. In fact, SOAP is a bit of a misnomer here: it means that the following Web Service is represented as an object, but this is not necessarily the case: you can write your Web Service as a series of C functions, and still Call using SOAP. The SOAP specification defines the format of SOAP messages and how to use SOAP over the HTTP protocol. SOAP is also based on XML and XSD, and XML is the data encoding method of SOAP. In Chapter 3 we will discuss SOAP and get to know the various elements of SOAP messages.

WSDL

How do you tell others about the functionality of your Web Service and the parameters of each function call? You may write a set of documentation yourself, you may even Speak verbally to people who need to use your web service. At least one of these informal methods has a serious problem: when programmers sit in front of a computer and want to use your Web Service, their tools (such as Visual Studio) can't give them any help because these tools are fundamental. I don't know your Web

service. The solution is to provide a formal description document in a machine readable way. Web Service Description Language (WSDL) is an XML-based language for describing Web services and their functions, parameters, and return values. Because it is based on XML, WSDL is both machine readable and human readable, which is a big benefit. Some of the latest development tools can generate WSDL documents based on your Web Service, as well as import WSDL documents to generate code that calls the corresponding Web Service.