What is WebService?

One of the most basic purposes of WebService is to provide collaborative capabilities for different application systems on different platforms.

In fact, WebService is not a mysterious thing. It is a class that can be called remotely, or a component.

Why use WebService?

WebService is a new concept. It is not first proposed by Microsoft, but Microsoft's DOTNET strategy gives it the widest potential. Maybe the root cause of its popularity is not Microsoft, maybe it is because of the rapid development of bandwidth and storage capacity, but the DOTNET strategy does play a major role, it can be used on a wider development platform. DOTNET's strategy leads Microsoft forward, and Microsoft spent nearly $30 billion for the DOTNET program. Why? Microsoft wants its ideas and methods to be most widely recognized not only in stand-alone software, but even on the Internet. WebService was first applied to platforms such as Sun and crowdsourced security testing, and is looking forward to its development. J2EE is the earliest platform for successful WebService development. It is widely spread and used on the Internet and becomes a real service. When Microsoft's DOTNET plan was about to be implemented, Microsoft began to explore the potential of WebService. Today's web sites only provide user interfaces for browsers, and the next generation of programmable web sites directly link enterprises, applications, services, and devices to each other. These programmable web sites will not only be passively accessed, but will become reusable smart web services. Therefore, we must use WebService to adapt to future development trends. One sentence: In order to adapt to the development of the times.

What are the advantages and disadvantages of WebService?

In early WebService development, due to bandwidth and storage capacity restrictions, it was not noticed. With the development of technology, bandwidth and storage are no longer a problem. A single optical fiber is 1000 m, and a home computer is 160 GB, let alone the terabytes of disk arrays used by servers. However, with the rapid development of the Internet, people should feel the new surprise brought by the Internet, that is, online office. The current online office system is becoming more advanced, but there is a common problem-compatibility issues, so communication is very difficult. However, WebService makes communication smoother. For example, the communication between the two countries requires translation, which is very troublesome. Therefore, it is worse to unify the languages of the two countries. WebService is a new concept. The development of WebService is very short, which leads to a problem-security. Because XML transmission is transmitted in plain text, security issues are not surprising, but you only need to do some work on the data to be transmitted.
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://host.company.com/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.

One of the most basic purposes of WebService is to provide collaborative capabilities for different application systems on different platforms.

In fact, WebService is not a mysterious thing. It is a class that can be called remotely, or a component.

Why use WebService?

WebService is a new concept. It is not first proposed by Microsoft, but Microsoft's DOTNET strategy gives it the widest potential. Maybe the root cause of its popularity is not Microsoft, maybe it is because of the rapid development of bandwidth and storage capacity, but the DOTNET strategy does play a major role, it can be used on a wider development platform. DOTNET's strategy leads Microsoft forward, and Microsoft spent nearly $30 billion for the DOTNET program. Why? Microsoft wants its ideas and methods to be most widely recognized not only in stand-alone software, but even on the Internet. WebService was first applied to platforms such as Sun and crowdsourced security testing, and is looking forward to its development. J2EE is the earliest platform for successful WebService development. It is widely spread and used on the Internet and becomes a real service. When Microsoft's DOTNET plan was about to be implemented, Microsoft began to explore the potential of WebService. Today's web sites only provide user interfaces for browsers, and the next generation of programmable web sites directly link enterprises, applications, services, and devices to each other. These programmable web sites will not only be passively accessed, but will become reusable smart web services. Therefore, we must use WebService to adapt to future development trends. One sentence: In order to adapt to the development of the times.

What are the advantages and disadvantages of WebService?

In early WebService development, due to bandwidth and storage capacity restrictions, it was not noticed. With the development of technology, bandwidth and storage are no longer a problem. A single optical fiber is 1000 m, and a home computer is 160 GB, let alone the terabytes of disk arrays used by servers. However, with the rapid development of the Internet, people should feel the new surprise brought by the Internet, that is, online office. The current online office system is becoming more advanced, but there is a common problem-compatibility issues, so communication is very difficult. However, WebService makes communication smoother. For example, the communication between the two countries requires translation, which is very troublesome. Therefore, it is worse to unify the languages of the two countries. WebService is a new concept. The development of WebService is very short, which leads to a problem-security. Because XML transmission is transmitted in plain text, security issues are not surprising, but you only need to do some work on the data to be transmitted.
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://host.company.com/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.