Introduction to Web Service

Distributed applications and browsers

Looking at the current application development, you will find an absolute tendency: people begin to prefer browser-based thin client applications. This is not because thin customers can provide better user interfaces, but because it can avoid high costs for desktop application Publishing. The cost for publishing desktop applications is high, half because of application installation and configuration problems, and the other half because of communication between the customer and the server.

Traditional Windows Rich Client Applications Use DCOM to communicate with servers and call remote objects. Configuring DCOM to work properly on a large network is a challenging task and a nightmare for many IT engineers. In fact, many IT engineers prefer to endure the functional limitations imposed by browsers and do not want to run a DCOM on the LAN. In my opinion, the result is an application that is easy to publish but difficult to develop and has extremely limited user interfaces. To put it bluntly, you spend more money and time developing applications with weaker functionality from the user's perspective. Believe it? Ask your accountant what he thinks about the new browser-based accounting software: most commercial users want to use a more friendly Windows user interface.

A perfect solution for communication between the client and the server is to use HTTP protocol. This is because any machine running a web browser is using the HTTP protocol. At the same time, many firewalls are configured to only allow HTTP connections.

Many commercial applications face another problem: interoperability with other programs. If all applications are written in the com or. NET language and run on the Windows platform, the world is too peaceful. However, in fact, most commercial data is still stored on large hosts in the form of non-relational files (VSAM) and accessed by mainframe programs written in the COBOL language. Moreover, many commercial programs are still being written in C ++, Java, Visual Basic, and other languages. Now, except for the simplest program, all applications need to be integrated with applications running on other heterogeneous platforms for data exchange. Such tasks are usually performed 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). In the past, there was no application communication standard, which was independent of the platform, modeling, and programming language. Only through web service can the client and server communicate freely with HTTP, regardless of the platform and programming language of the two programs.

What is Web service?

We have at least two answers to this question. On the surface, Web Service is an application that exposes an API that can be called through the Web. That is to say, you can use a programming method to call this application through the Web. We call the Web service application a customer. For example, if you want to create a web service, its function is to return the current weather conditions. You can create an ASP page that accepts the zip code as a query string and returns a string separated by commas (,), containing the current temperature and weather. To call this ASP page, the client needs to send the following http get request:

Http: //.../weather. asp? Zipcode = 20171
The returned data is as follows:

21, clear

This ASP page can be regarded as a web service. Because it is based on http get requests, it exposes an API that can be called through the Web. Of course, there are more web services.

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 created a component-based distributed application using COM or DCOM. Com is a very good component technology, but we can easily cite situations where COM does not meet the requirements.

The Web service platform is a set of standards that define how applications implement interoperability on the web. You can use any language you like to write Web Services on any platform you like, as long as we can query and access these services through web service standards.

New Platform

The Web Service Platform requires a set of protocols to create 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, interfaces-based platforms provide methods to describe interfaces, methods, and parameters (such as the IDL Language in COM and Cobar ). Similarly, the Web service platform must provide a standard to describe the web service, so that the customer can obtain sufficient information to call the web service. Finally, we must have a way to remotely call this web service. This method is actually a Remote Procedure Call Protocol (RPC ). To achieve interoperability, this RPC protocol must also be independent of the platform and programming language. The following sections briefly describe the three technologies that constitute the Web service platform.

XML and XSD

The Extensible Markup Language (XML) is the basic format for data representation on the Web service platform. In addition to ease of establishment and analysis, XML has the primary advantage of being platform-independent and vendor-independent. Independence is more important than technical superiority: software vendors will not choose a technology invented by competitors.

XML solves the problem of data representation, but it does not define a set of standard data types, let alone how to extend this set of data types. For example, what is the integer number? 16-bit, 32-bit, or 64-bit? These details are important for implementing interoperability. XML Schema (XSD) developed by W3C is a set of standards dedicated to solving this problem. It defines a set of standard data types and provides a language to extend this data type. The Web service platform uses XSD as its data type system. When you use a language (such as VB. net or C #) to construct a web service, to comply with the Web service standard, all the data types you use must be converted to the XSD type. The tool you use may have automatically completed the conversion, but you may modify the conversion process as needed. In chapter 2, we will go deep into XSD and learn how to convert Custom Data Types (such as classes) to XSD types.

Soap

After the Web Service is created, you or others will call it. Simple Object Access Protocol (SOAP) provides standard RPC methods to call Web Services. In fact, soap is a bit inappropriate here: it means that the following Web Service is represented in the form of an object, but this is not necessarily the case: you can write your web service as a series of C functions and still use soap for calling. The SOAP specification defines the format of soap messages and how to use soap over HTTP. 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 understand the various elements of soap messages.

WSDL

How do you introduce to others the functions of your Web Service and the parameters for each function call? You may write a set of documents on your own. You may even verbally tell people who need your web service. These informal methods have at least one serious problem: when programmers sit in front of a computer and want to use your web service, their tools (such as Visual Studio) they cannot provide any help, because these tools do not know your web

Service. The solution is to provide a formal description document that can be read by machines. The Web Service Description Language (WSDL) is an XML-based language used to describe Web services and their functions, parameters, and returned values. Because it is based on XML, WSDL is both readable and readable, which is a great benefit. Some of the latest development tools can generate a WSDL document based on your web service, and import the WSDL document to generate code that calls the corresponding web service.

UDDI
Universal Description, discovery and integration
A plan launched to accelerate the promotion of web services and enhance web service interoperability capabilities, based on standard service description and discovery specifications (specification ).
By sharing resources, multiple operators run the UDDI business registration center in the form of web services.
The core component of the UDDI program is the UDDI commercial registration. It uses XML documents to describe the enterprise and its web services.
UDDI commercial registration provides three types of information:
White page contains the address, contact method, and known Enterprise ID.
Yellow page contains industry categories based on standard classification.
Green page contains technical information about the web service provided by the enterprise, which may be a pointer to a file or URL, and these files or URLs serve the service discovery mechanism.