You may have heard of Web service for a long time, and you may have some ideas about Web service. For a while, it seems that all the computer journals, books and Web sites are starting to mention Web service. However, most of the current introductions to Web service do not clearly explain what the Web service really is. They just preach how good the Web service is, it's like advertising. Two things are clear in this article: What the Web Service is, and under what circumstances you should use the Web service.
Distributed Applications and Browsers
If you look at current application development, you will find an absolute inclination: people are starting to favor browser-based thin client applications. This is certainly not because thin customers can provide a better user interface, but because it avoids the high cost of spending on desktop application publishing. The cost of publishing desktop applications is high, in part because of problems with application installation and configuration, and the other half because of communication between customers and servers.
Traditional Windows rich client applications use DCOM to communicate with the server and invoke remote objects. Configuring DCOM to work properly on a large network will be a challenging task, as well as a nightmare for many it engineers. In fact, many it engineers prefer to put up with the limitations of the browser, rather than running a DCOM on a LAN. In my opinion, the result is an application that is easy to publish, but is difficult to develop and has extremely limited user interface. In extreme terms, you spend more money and time developing applications that are less functional from the user's perspective. Don't believe it? Ask your accountants what they think of the new browser-based accounting software: Most business apps users want to use a more user-friendly Windows user interface.
A perfect solution for communication between client and server 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 firewalls are currently configured to allow only HTTP connections.
Another issue that many business applications face is interoperability with other programs. If all the applications are written in COM or. NET language and are all running on the Windows platform, it's all right. In fact, however, most commercial data is still stored in a VSAM file on a large host, and is accessed by a mainframe program written in the COBOL language. Also, there are many business programs that continue to be written in C + +, Java, Visual Basic, and a wide variety of languages. Now, in addition to the simplest programs, all applications need to integrate 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 Queuing, and APIs that apply only to certain situations, such as IBM's Advanced Program to Program Communication (APPC). Previously, there was no application communication standard, which was independent of the platform, the build model, and the programming language. Only through web Service can clients and servers be free to communicate with HTTP, regardless of the platform and programming language of two programs.
What is a web Service
We have at least two answers to this question. On the face of it, a Web service is an application that exposes an API to the outside world that can be invoked over the Web. This means that you can programmatically invoke the application through the Web. We call the application that calls this Web service customer. For example, you want to create a Web service that functions to return to the current weather situation. Then you can create an ASP page that accepts the ZIP code as the query string, and then returns a comma-separated string containing the current temperature and weather. To invoke this ASP page, the client needs to send the following HTTP GET request:
http://host.company.com/weather.asp?zipcode=20171
The data returned should be like this:
21, clear
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 invoked through the Web. Of course, there is more to the WEB service.
The following is a more precise explanation for Web services: Web Service is a new platform for building interoperable distributed applications. As a Windows programmer, you may have built a distributed, component-based application using COM or DCOM. COM is a very good component technology, but we can easily cite COM does not meet the requirements.
The Web service platform is a set of standards that defines how applications can interoperate on the web. You can write Web service in any language you like, on any platform you like, as long as we can query and access these services through the Web service standards.
New platform
The Web service platform requires a set of protocols to implement the creation of distributed applications. Any platform has its data representation method and type system. To achieve interoperability, the WEB service platform must provide a standard set of type systems for communicating different types of systems in different platforms, programming languages, and component models. In traditional distributed systems, interface based (interface) platforms provide methods to describe interfaces, methods, and parameters (IDL languages in COM and Cobar). Similarly, the Web service platform must provide a standard for describing Web service, allowing customers to get enough information to invoke the Web service. Finally, we must also have a way to make remote calls to this Web service. This approach is actually a remote procedure call Protocol (RPC). For interoperability purposes, this RPC protocol must also be independent of the platform and programming language. The following sections briefly describe 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 a Web service platform. In addition to being easy to build and easily analyze, the main advantage of XML is that it is both platform-independent and vendor-independent. Irrelevance is more important than technical superiority: Software vendors do not choose a technology that is invented by competitors.
XML solves the problem of data representation, but it does not define a set of standard data types, much less how to extend this set of data types. For example, what does the number of implants really mean? 16-bit, 32-bit, or 64-bit? These details are important to achieve interoperability. The XML Schema (XSD) developed by the consortium is a set of standards that specifically address this issue. It defines a set of standard data types and gives a language to extend this set of data types. The WEB service platform is used to use XSD as its data type system. When you construct a Web service in a language such as vb.net or C #, all of the data types you use must be converted to XSD types in order to conform to the Web service standards. The tools you use may have automatically done the conversion, but you'll probably change the conversion process according to your needs. In the second chapter, we'll dive into the XSD and learn how to convert a custom data type (such as a class) to an XSD type.
Soap
When the Web service is built, you or someone else will call it. Simple Object Access Protocol (SOAP) provides a standard RPC method for invoking 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 true: you can write your Web service as a series of C functions and still invoke it using SOAP. The SOAP specification defines the format of the SOAP message and how soap is used through the HTTP protocol. Soap is also xml-based and XSD, and XML is the data encoding method of soap. In Chapter three we will discuss soap and get to know the various elements of SOAP messages.
Wsdl
How would you describe to someone what your Web service does, and what are the arguments for each function call? You may be able to write a set of documents yourself, and you may even verbally tell people who need to use your Web service. These informal approaches have at least one serious problem: when programmers get to the computer and want to use your Web service, their tools, such as visual Studio, can't give them any help because they don't know your Web service at all. The solution is to provide a formal description of the document in a way that can be read by the machine. The Web Service Description Language (WSDL) is an xml-based language that describes the Web service and its functions, parameters, and return values. Because it is xml-based, WSDL is both machine-readable and readable, which is a great benefit. Some of the latest development tools can generate WSDL documents based on your Web service, import WSDL documents, and generate code that invokes the appropriate Web service.
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.