On the surface, Web service is an application, which exposes an API that can be called through the Web. In other words, you can call this application programmatically through the Web. A more accurate explanation of Web services: Web services are a new platform for building interoperable distributed applications. As a Windows programmer, you may have built a component-based distributed application with COM or DCOM. COM is a very good component technology, but it is easy to cite the situation that COM can't meet the requirements. Web service platform is a set of standards that define how applications can achieve interoperability on the Web. You can write Web services in any language you like and on any platform you like, as long as we can query and access these services through web service standards. No matter what tool or language your Web service is written in, as long as you call it through HTTP with SOAP protocol, the overall structure is consistent. Usually, you build your Web service in your favorite language (such as VB 6 or VB). NET), and then through SOAP Toolkit or. Net. Therefore, customers of any language and platform can read their WSDL documents to call this Web service. The client will generate a SOAP request message according to the WSDL description document. Web services are placed behind Web servers (such as IIS), and SOAP requests generated by clients are embedded in HTTP POST requests and sent to the web servers. The Web server forwards these requests to the Web service request handler. For VB 6 programs, the Web service request handler is an ASP page or ISAPI extension, which works with SOAP toolkit components. For VB.NET programs, the Web service request handler is. NET framework. The function of the request handler is to parse the received SOAP request, call the Web service, and then generate the corresponding SOAP response. After the Web server gets the SOAP reply, it will send it back to the client via HTTP reply. 2. Basic concept After the SOAPWeb service is built, others will call it. Simple Object Access Protocol (SOAP) provides a standard remote procedure call (RPC) method to invoke Web services. SOAP specification defines the format of SOAP message and how to use SOAP through HTTP protocol. SOAP is also based on XML and XSD, and XML is the data encoding method of SOAP. The method call request and the result return value between the client and the server are placed in these messages. XML and XSD Extensible Markup Language (XML) are the basic formats for representing data in Web service platforms. Besides being easy to build and analyze, the main advantage of XML is that it is independent of platforms and vendors. Indifference is more important than technological superiority. 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 exactly does an integer stand for? 16,32 or 64? These details are very important to achieve interoperability. XML Schema(XSD) developed by W3C is a set of standards to solve this problem. It defines a set of standard data types and gives a language to extend this set of data types. The Web service platform uses XSD as its data type system. When building a Web service in a certain language (such as VB.NET or C#), all data types used must be converted to XSD types in order to meet the Web service standards. Wsdl (web service description language) is used to describe the XML format of services provided by the server. WSDL file describes the services provided by the server, the calling methods provided, and the format to be followed when calling, such as the format of calling parameters and return values. WSDL, much like IDL (Interface Description Language) in COM programming, is a contract between the server and the client, and both parties must implement their functions in strict accordance with the contract. WSML(Web Services Meta Language) is used to describe the mapping relationship between the method provided by WSDL and the COM object that implements the method. This file is unique to Microsoft's implementation and is not part of the SOAP standard. Generally speaking, files only exist on the server. Technical characteristics of 3.3. Webservice: communication across the firewall If the application has thousands of users and is distributed all over the world, the communication between the client and the server will be a thorny issue. Because there is usually a firewall or proxy server between the client and the server. In this case, using DCOM is not so simple, and it is usually inconvenient to distribute client programs to such a large number of users. The traditional way is to choose a browser as the client, write a large number of ASP pages, and expose the middle layer of the application to the end users. Therefore, it is difficult to develop and maintain programs. For example, to add a new page to an application, you must first set up a user interface (web page), and at least set up an ASP page behind this page to accept the information input by users, call the middle-tier components, format the results into HTML, and finally send the "result page" back to the browser. If the client code is no longer so dependent on HTML forms, the programming of the client will be much simpler. If the middle-tier component is replaced by a Web service, you can call the middle-tier component directly from the user interface, thus eliminating the step of creating an ASP page. To invoke a Web service, you can directly use a SOAP client, such as Microsoft SOAP Toolkit or. NET, or you can use your own SOAP client and connect it with the application. It not only shortens the development cycle, but also reduces the code complexity and enhances the maintainability of the application. At the same time, the application no longer needs to jump to the corresponding "result page" every time it calls the middle-tier component. From the experience point of view, in applications with more interaction between user interface and middle tier, using this structure of Web Service can save 20% of user interface programming and development time. In addition, such a middle tier composed of Web services can be reused in application integration or other occasions. Finally, the logic and data of applications are "exposed" through Web services, and customers can reuse these applications on other platforms. Project 2: Application integration. Enterprise application developers know that enterprises often have to integrate various programs written in different languages and running on different platforms, and this integration will consume a lot of development power. Applications often need to get data from programs running on IBM hosts; Or send data to a host or UNIX application. Even on the same platform, various softwares produced by different software vendors often need to be integrated. Through Web services, applications can "expose" functions and data in a standard way for other applications to use. For example, there is an order registration program for registering customers' new orders, including customer information, delivery address, quantity, price and payment method; There is also an order fulfillment program to manage the actual delivery of goods. These two programs are from different software vendors. After the new order comes in, the order login program needs to inform the order execution program to send the goods. By adding a layer of Web services to the order executor, the order executor can "expose" the function of "adding orders". In this way, every time a new order arrives, the order login program can call this function to send the goods. Web services are the key to successful B2B integration. Through Web services, companies can "expose" key business applications to designated suppliers and customers. For example, the electronic ordering system and electronic invoice system are exposed, customers can send orders electronically, and suppliers can send raw material purchase invoices electronically. Of course, this is not a new concept. EDI (Electronic Document Exchange) has been like this for a long time. However, the implementation of Web services is much simpler than EDI. Moreover, Web services run on the Internet and can be easily implemented anywhere in the world, so its running cost is relatively low. However, Web services are not a complete solution for document exchange or B2B integration like EDI. Web service is only the key part of B2B integration, and many other parts are needed to realize the integration. Item 4: Software and data reuse Software reuse is a big topic with many forms and varying degrees. The most basic form is source code module or class-level reuse, and the other form is component reuse in binary form. At present, reusable software components such as table controls or user interface controls occupy a large share in the market. However, the reuse of this kind of software has a great limitation, that is, the reuse is limited to code and the data cannot be reused. The reason is that it is easy to publish components and even source code, but it is not so easy to publish data, unless it is static data that will not change frequently. Web services can reuse the data behind the code, while allowing the code to be reused. With Web services, it is no longer necessary to buy and install software components from third parties before calling them from applications. Just call the remote Web service directly. For example, to confirm the address entered by the user in the application, just send the address directly to the corresponding Web service, and the Web service will help you check the street address, city, province, postal code and other information to confirm whether the address is in the corresponding postal code area. Internet service providers can charge for this service according to the time or the number of uses. Such a service cannot be reused by components. In this case, you must download and install a database containing information such as street address, city, province and postal code, and this database cannot be updated in real time. Another situation of software reuse is to integrate the functions of several applications. For example, establish a portal application on the LAN, where users can query FedEx packages and check the stock market, manage their own schedules, and buy movie tickets online. Now there are many application vendors on the Web, all of which have realized these functions in their own applications. Once they "expose" all these functions through Web services, they can easily integrate all these functions into your portal website, providing users with a unified and friendly interface. In the future, many applications will use Web services to expand the current component-based application structure into a hybrid structure of component /Web services. They can use the functions provided by third-party Web services in their own applications, or provide their own application functions to others through Web services. In both cases, you can reuse the code and the data behind it.