WebService related concepts

1. Preface

Everyone has heard of WebService (Web service) more or less. For a period of time, many computer journals, books and websites have mentioned and promoted WebService technology, including a lot of bragging and advertising. But we have to admit that WebService is really an emerging and promising technology, so what exactly is WebService? When should it be used?

The current application development has gradually shown two completely different trends: one is browser-based thin client application, the other is browser-based rich client application (RIA), and of course the other one is browser-based thin client application. This technology is relatively more fashionable (such as the now popular Html5 technology), and I will mainly talk about the former here.

　Browser-based thin client applications are not because thin clients can provide a better user interface, but because they can avoid the high cost of publishing desktop applications. Publishing desktop applications is expensive, partly because of application installation and configuration issues, and partly because of communication issues between client and server. Traditional Windows rich client applications use DCOM to communicate with the server and call remote objects. Configuring DCOM to work properly in a large network will be an extremely challenging task, and it is also a nightmare for many IT engineers. In fact, many IT engineers would rather endure the functional limitations brought by the browser than run a DCOM on the LAN. Regarding the communication problem between the client and the server, a perfect solution 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 only allow HTTP connections. Another problem many commercial programs face is interoperability with other programs. If all applications were written using COM or .NET language and all ran on the Windows platform, then the world would be peaceful. However, in fact, most business data is still stored in the form of non-relational files (VSAM) on mainframes and accessed by mainframe programs written in COBOL language. Moreover, many commercial programs continue to be written in C++, Java, Visual Basic, and various other languages. Now, all but the simplest programs need to integrate and exchange data with applications running on other heterogeneous platforms. Such tasks are usually accomplished by specialized methods, such as file transfer and analysis, message queues, and APIs that are only suitable for certain situations, such as IBM's Advanced Program to Program Communication (APPC). Previously, there was no application communication standard that was platform, component model, and programming language independent. Only through Web Service can the client and server communicate freely using HTTP, regardless of the platform and programming language of the two programs.

2. What exactly is WebService? In a nutshell: WebService is a cross-programming language and cross-operating system platform remote calling technology.

The so-called cross-programming language and cross-operating platform means that the server program is written in java, and the client program can be written in other programming languages, and vice versa! Cross-operating system platform means that the server program and the client program can run on different operating systems.

The so-called remote call is a method that a program on one computer A can call to an object on another computer B. For example, the POS card swiping system provided by UnionPay to the mall, the transfer method called by the POS machine transfer in the mall The code actually runs on the bank server. For another example, Amazon, weather forecast system, Taobao, Xiaonei.com, Baidu, etc. expose their system services in the form of webservice services, allowing third-party websites and programs to call these service functions, thus expanding the market share of their own systems Efficiency, in a larger concept, is the so-called SOA application.

In fact, WebService can be understood from multiple angles. On the surface, WebService is an application that exposes an API that can be called through the Web to the outside world. That is to say, the application can be called through the Web using programming methods. . We call the application that calls this WebService the client, and the application that provides this WebService is called the server. From a deeper perspective, WebService is a new platform for building interoperable distributed applications. It is a platform and a set of standards. It defines 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 the Web service standard.

The WebService platform requires a set of protocols to achieve the creation of distributed applications. Any platform has its data representation method and type system. To achieve interoperability, the WebService platform must provide a standard type system for communicating different type systems in different platforms, programming languages, and component models. The Web service platform must provide a standard to describe the Web service so that customers can get enough information to call the Web service. Finally, we must 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 platform and programming language independent.

3. WebService platform technology

XML+XSD, SOAP and WSDL are the three major technologies that constitute the WebService platform.

3.1, XML + XML is the format for representing data in the WebService platform. In addition to being easy to create and easy to parse, the main advantage of XML is that it is both platform-independent and vendor-independent. Irrelevance is more important than technical superiority: software vendors will not choose a technology invented by a competitor.

　 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 do integer numbers represent? 16-bit, 32-bit, 64-bit? These details are important to achieve interoperability. XML Schema (XSD) is a set of standards that specifically solves this problem. It defines a standard set of data types and provides a language to extend this set of data types. The WebService platform uses XSD as its data type system. When you use a certain language (such as VB.NET or C#) to construct a Web service, in order to comply with the WebService standard, all data types you use must be converted to XSD types. The tool you use may have automatically completed this conversion for you, but you will most likely modify the conversion process to suit your needs.

3.2, SOAP

When WebService sends requests and receives results through the HTTP protocol, the request content and result content sent are encapsulated in XML format, and some specific HTTP message headers are added to illustrate the content format of the HTTP message. These The specific HTTP header and XML content format is the SOAP protocol. SOAP provides standard RPC methods to call Web Services.

SOAP protocol = HTTP protocol + XML data format

The SOAP protocol defines the format of the SOAP message. The SOAP protocol is based on the HTTP protocol. SOAP is also based on XML and XSD. XML is the data encoding method of SOAP. To make an analogy: HTTP is an ordinary highway, XML is the green isolation belt in the middle and guardrails on both sides, and SOAP is a highway transformed from an ordinary highway by adding isolation belts and guardrails.

3.3, WSDL

Just like when we go to a store to buy something, we must first know what is available in the store, and then make a purchase. What businesses do is to put up advertising posters. The same goes for WebService. To call a WebService service, the WebService client must first know where the address of the service is and what methods can be called in the service. Therefore, the WebService server must first use a WSDL file to describe its home page. What services can be called externally, what is the service (what are the methods in the service, what parameters are accepted by the method, what is the return value), which URL address is used to represent the network address of the service, and how is the service called?

　 WSDL (Web Services Description Language) is such an XML-based language used to describe Web Services and their functions, parameters and return values. It is a standard format that both the WebService client and the server can understand. 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 not only generate WSDL documents based on your Web service, but also import WSDL documents to generate proxy class code that calls the corresponding WebService.

　The WSDL file is saved on the web server and can be accessed through a url address. Before the client calls a WebService, it must know the address of the WSDL file of the service. The WebService service provider can expose its WSDL file address in two ways: 1. Register with the UDDI server so that it can be found; 2. Tell it directly to the client caller.

4. WebService development

WebService development can be divided into two aspects: server-side development and client-side development

4.1. Server-side development

Publish the business methods of the company's internal system into WebService services for remote cooperation units and individuals transfer. (With the help of some WebService frameworks, you can easily publish your business objects into WebService services. Typical WebService frameworks in Java include: axis, xfire, cxf, etc. Java ee servers usually also support publishing WebService services, such as JBoss.)

4.2. Client development

Calling WebService services published by others. Most people are engaged in development in this area, for example, calling weather forecast WebService services. (Use the manufacturer's tools such as WSDL2Java to generate statically called proxy class code; use the client programming API class provided by the manufacturer; use SUN's early standard jax-rpc development kit; use SUN's latest standard jax-ws development kit . Of course SUN has been acquired by ORACLE)

4.3. Working calling principle of WebService

For the client, we pass the url address of the wsdl file to these various WebService client APIs, and these APIs will create the underlying proxy Class, I can access the webservice service by calling these proxies. The proxy class turns the client's method call into request data in soap format and sends it out through the HTTP protocol, and returns the received soap data into a return value. For the server, the essence of various WebService frameworks is a large Servlet. When the remote calling client sends it request data in soap format through the http protocol, it analyzes the data and knows which Java class to call. Which method, then find or create this object, call its method, and then package the result returned by the method into data in soap format, and send it back to the client through an http response message.

5. Applicable occasions

1. Cross-firewall communication

If the application has thousands of users and is distributed around the world, then the communication between the client and the server will be a thorny problem. Because there is usually a firewall or proxy server between the client and the server. In this case, using DCOM is not that simple, and it is usually not convenient to publish the client program to such a large number of users. The traditional approach is to choose to use the browser as the client, write a lot of ASP pages, and expose the middle layer of the application to the end user. The result of this is that development is difficult and the program is difficult to maintain. If the middle-tier component is replaced by WebService, the middle-tier component can be called directly from the user interface. Judging from most people's experience, in an application with a lot of interaction between the user interface and the middle layer, using the structure of WebService can save 20% of the development time spent on user interface programming.

2. Application integration

Enterprise-level application developers all know that enterprises often have to integrate various programs written in different languages ​​and running on different platforms, and this integration will cost a lot of money. Great development power. Applications often need to obtain data from programs running on the IBM mainframe; or send data to mainframe or UNIX applications. Even on the same platform, various software produced by different software vendors often need to be integrated. Through WebService, applications with different structures can be easily integrated.

3. B2B integration

　Using WebService to integrate applications can make the company's internal business processing more automated. But what happens when transactions span suppliers and customers, pushing the boundaries of the company? The integration of business transactions across companies is often called B2B integration. WebService is the key to successful B2B integration. Through WebService, companies can "expose" key business applications to designated suppliers and customers. For example, by "exposing" the electronic ordering system and electronic invoicing system, 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 Interchange) has been like this for a long time. However, the implementation of WebService is much simpler than EDI, and WebService runs on the Internet and can be easily implemented anywhere in the world, so its operating cost is relatively low. However, WebService is not a complete solution for document exchange or B2B integration like EDI. WebService is only a key part of B2B integration, and many other parts are needed to achieve integration.

The biggest advantage of using WebService to achieve B2B integration is that interoperability can be easily achieved. As long as the business logic is "exposed" and becomes a WebService, any designated partner can call these business logic, regardless of what platform their system runs on or what development language they use. This greatly reduces the time and cost spent on B2B integration, allowing many small and medium-sized enterprises that cannot afford EDI to achieve B2B integration.

4. Software and data reuse

Software reuse is a big topic, there are many forms of reuse, and the degree of reuse varies. The most basic form is source code module or class level reuse, and one form is binary form component reuse. WebService applications can use standard methods to "expose" functions and data for use by other applications to achieve business-level reuse.

6. Not applicable occasions

1. Stand-alone applications

Currently, businesses and individuals still use many desktop applications. Some of them simply need to communicate with other programs on the machine. In this case, it is best not to use WebService, just use the local API. COM is ideal for working in this situation because it is small and fast. The same goes for server software running on the same server. It is best to directly use COM or other local APIs to make calls between applications. Of course, WebService can also be used in these situations, but that not only consumes too much, but also does not bring any benefits.

2. Isomorphic applications on LAN

In many applications, all programs are developed with VB or VC, all use COM under the Windows platform, and all run on the same LAN. For example, there are two server applications that need to communicate with each other, or there is a Win32 or WinForm client program that wants to connect to another server program on the LAN. In these programs, using DCOM will be much more efficient than SOAP/HTTP. Similarly, if a .NET program wants to connect to another .NET program on the LAN, .NET remoting should be used. Interestingly, in .NETremoting, you can also specify to use SOAP/HTTP to make WebService calls. However, it is better to make RPC calls directly through TCP, which is much more efficient.

For more articles related to WebService related concepts, please pay attention to the PHP Chinese website!