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 briefly introduces the technologies used to form the Web service platform.
1. 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 creation and analysis, XML has the primary advantage of being independent from the platform and the vendor. XML was created by the World Wide Web society (W3C). xml schemaxsd developed by W3C defines a set of standard data types and provides a language to extend this data type.
The Web service platform uses XSD as the data type system. When you construct a web service in a language such as VB. NET or C #, to comply with the Web service standard, all the data types you use must be converted to the XSD type. To enable it to be transmitted across different organizations on different platforms and software, you also need something to wrap it. This is a protocol, such as soap.
2. Soap
Soap is the Simple Object Access Protocol. It is a lightweight protocol used to exchange XML encoding information. It has three main aspects: XML-envelope defines a framework for describing information content and how to handle content, encodes program objects into XML object rules, and executes Remote Procedure Calls (RPC). Soap can run on any other transmission protocol. For example, you can use SMTP, or the internet email protocol, to transmit soap messages, which is tempting. The headers in the transport layer are different, but the XML payload remains the same.
The Web Service allows different systems to call each other in the form of "software-software conversation", breaking the incompatibility between software applications, websites, and various devices, achieve the goal of "seamless web-based integration.
3. WSDL
Web Service Description Language (WSDL) is a formal description document provided by machines that can be read. It 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 machine readable and human readable. In 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 at all. 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.
4. UDDI
The purpose of UDDI is to establish standards for e-commerce. UDDI is a set of web-based, distributed, and standard standards for implementing information registration centers for Web Services, it also contains a set of access protocols that enable enterprises to register their own web services so that other enterprises can discover.
5. Remote Procedure Call RPC and message passing
Web services are actually implementing communication between applications. Now we have two methods for Application Communication: RPC remote process call and message transmission. When RPC is used, the client calls the Remote Process on the server. Generally, a remote object is instantiated and its method and attributes are called. The RPC system tries to achieve the transparency of a location: the server exposes remote object interfaces, and the client is like the interfaces of these objects used locally, in this way, the underlying information is hidden, and the client does not need to know the machine on which the object is located.
When to use WebService ??
Now I will list three cases. In these three cases, you will find that using Web Service will bring great benefits. Afterwards, I will cite some situations where web services should not be used.
Communication across firewalls
If your applications have thousands of users and all of them are distributed across the world, communication between the client and the server will be a tricky problem. This is because there is usually a firewall or proxy server between the client and the server. In this case, it is not that simple to use DCOM. In addition, you usually do not want to publish your client program to such a large number of users. Therefore, you finally chose to use a browser as the client, write a bunch of ASP pages, and expose the middle layer of the application to the end user. What are the results? If you are lucky, you will get an application that is not maintained at all.
Imagine how you should add a new page in your application: you must first establish a user interface (web page), and after this page, an intermediate layer component that contains the corresponding business logic. This is not enough. You need to create at least one ASP page to accept user input, call the middle layer component, and format the result as HTML, finally, the "result page" is sent back to the browser. If the client code is no longer so dependent on HTML forms, isn't client programming much easier? Also, can the step for creating an ASP page be omitted?
Of course. If your middle layer component is Web service, you can directly call the middle layer component from the user interface, thus saving the step of creating an ASP page. To call web service, you can directly use Microsoft soap toolkit or. you can also use a self-developed soap client such as. Net to connect it to your application. This not only shortens the development cycle, but also reduces the complexity of the code and enhances the maintainability of the entire application. At the same time, your application no longer needs to jump to the corresponding "result page" every time you call the middle layer components.
In my experience, the Web service structure is used in an application with many interactions between the user interface and the middle layer, you can easily save 20% of the development time spent on User Interface Programming. Another benefit of doing so is that you will get an intermediate layer composed of Web services that can be fully reused in application integration or other scenarios. Finally, expose the logic and data of your application through web service, and allow customers on other platforms to reuse your application.
Application Integration
Enterprise Application developers know that enterprises often need to integrate various programs written in different languages on different platforms, this integration will take a lot of development effort. Your applications often need to get data from programs running on older IBM hosts, or send data to hosts or Unix applications. Even on the same platform, various software products produced by different software vendors often need to be integrated. Through web service, applications can expose functions and data in a standard way for other applications to use.
For example, you have an order logon program to log on to new orders from customers, including customer information, delivery address, quantity, price, payment method, and other information. At the same time, you also have an order execution program for the management of actual goods delivery. These two programs come from different software vendors. After a new order comes in, the Order login program needs to notify the order execution program to send the goods. By adding a web service to the order execution program, the order execution program can expose the "addorder" function. In this way, every time a new order arrives, the Order login program can call this function to send the goods. Then integrate the application through Web Service
B2B Integration
Using Web service to integrate applications can make your company's internal business processing more automated. But what happens when the transaction crosses your suppliers and customers and breaks the company line? Cross-company business transaction integration is usually called B2B integration.
Web Service is the key to successful B2B integration. With Web service, your company can expose key business applications to specified suppliers and customers. For example, if you expose your electronic order system and electronic invoice system, your customers can send you purchase orders electronically, however, your suppliers can send you raw material procurement invoices electronically. Of course, this is not a new concept: electronic document exchange (EDI) is just like this. The main difference between Web Service and EDI is that the implementation of Web Service is much simpler than EDI, and Web service runs on the Internet and can be easily implemented anywhere in the world, in this way, the running cost is relatively low. However, unlike EDI, Web Service is a complete solution for document exchange or B2B integration. Web Service is only a key part of B2B integration. It requires many other parts to complete this integration.
The biggest benefit of implementing B2B integration with Web services is that it can easily implement interoperability. As long as you expose your business logic and become a web service, you can make it easy for any specified partner to call your business logic, regardless of the platform on which their system runs, what development language is used. This greatly reduces the time and cost spent on B2B integration. This low cost makes B2B integration possible for many small and medium-sized enterprises that could not bear the original EDI investment costs.
Software reuse
Software reuse is a big topic, with many forms and degrees. The most basic form is source code module or class-Level Reuse. Another form is binary Component reuse. Currently, reusable software components such as table controls or user interface controls have a large share in the market. However, the reuse of such software has a very serious limitation: reuse is limited to code, and data cannot be reused. The reason is that you can easily publish components or even source code, but it is not so easy to publish data unless the data is static data that will not change frequently.
Web service allows you to reuse the data after the Code while reusing the code. To use web service, you no longer need to buy and install software components from a third party, as before, and then call these components from your application. You only need to directly call the remote web service. For example, if you want to confirm the email address entered by the user in your application, you only need to send the address directly to the corresponding web service, this Web service will help you check the street address, city, province, province, zip code, and other information to confirm that the address is indeed in the corresponding zip code area. Web service providers can pay for the service on time or on the number of times they use it. This kind of service needs to be implemented through Component Reuse, because you must download and install a database containing information such as street addresses, cities, provinces, and postal codes, the database cannot be updated in real time.
Another case of software reuse is to integrate the functions of several applications. For example, if you want to create a portal application on a LAN, You can query their FedEx packages, view the stock market, and manage their schedules, you can also buy movie tickets online. Currently, many web application vendors have implemented these features in their applications. Once they expose these functions through web services, you can easily integrate all these functions into your portal site, provides users with a unified and friendly interface.
Integrates functions of various applications with Web Services to provide users with a unified interface
Many applications use web services to extend the current component-based application structure to a hybrid structure of components and Web services. You can also use the functions provided by third-party web services in applications. You can also provide the functions of your application to others through web service. In all these cases, you can reuse the data behind the code and code. In short, Web Service is a very powerful form of software reuse.
When should I use web service?
A complete introduction to Web Services should also include when web services should not be used. After the previous introduction, we know that Web services are most useful for Web interoperability or remote calls. However, in many cases, Web Services cannot bring you any benefits at all.
Standalone application
At present, we still have many desktop applications for commercial use and personal use. Some of them only need to communicate with other programs running on the local machine. In this case, we 'd better not use web services any more, as long as we use local APIs. Com is very suitable for working in this case because it is small and fast. The same is true for the server software running on a server: It is recommended that you use com or other local APIs to call applications directly. Of course, Web services can also be used in these situations, but that will not only consume too much, but also will not bring you any benefits.
Homogeneous applications on LAN
In many applications, all your programs are developed using VB or Vc, all of which use Com on the Windows platform and run on the same LAN. For example, you have two server applications that need to communicate with each other, or you have a Win32 or winform client program to connect to another server program on the LAN. Using DCOM in these programs is much more effective than soap/HTTP. Similarly, if one of your. net programs is connected to another. Net program on the LAN, you should use. Net remoting. Interestingly, in. Net remoting, you can also specify the use of SOAP/HTTP for Web service calls. However, it is better to call RPC directly through TCP, which will be much more effective. In short, as long as you look at the application structure, there are other methods that are more effective and more feasible than web services, then do not use web services.
Summary
Web Service is a new platform for creating interoperable distributed applications. The main goal of Web Service is cross-platform interoperability. To achieve this goal, Web services are fully based on XML, XSD, and other standards independent of platforms and software vendors.
Web service is very useful when applications communicate across platforms and networks. Web Service is suitable for application integration, B2B integration, code and data reuse, and communication between clients and servers through the Web.
Of course, Web services are not omnipotent. You cannot abuse web services everywhere. In some cases, Web Service Reduces the application performance without any benefits. For example, a homogeneous application running on a machine or a LAN should not communicate with Web Services.