Under what circumstances should you use a Web service?

WebService now I'm going to list three things, and in these three cases, you'll find that using Web service can be a great benefit. Thereafter, I will also cite some cases where Web service should not be used.

Communication across the firewall

If your application has thousands of users and they are all around the world, communication between the client and the server will be a tricky problem. That's because there's usually a firewall or proxy server between the client and the server. In this case, you want to use DCOM is not so easy, and, often you do not want to publish your client program to such a large number of users in the hands of each. So, you finally chose to use the browser as the client, write down a stack of ASP pages, the application of the middle tier exposed to the end user. The result? If you're lucky, it's just a little hard to develop, bad luck, and you'll get an application that can't be maintained at all.

Imagine how you might add a new page to your application: You must first create a user interface (a Web page) and a middle-tier component that contains the appropriate business logic behind the page. This is not enough, you have to create at least one ASP page, used to accept user input information, call the middle-tier components, the results formatted as HTML, and finally the "results page" returned to the browser. If client code is no longer so dependent on HTML forms, is the client programming much simpler? Also, the step of building an ASP page can be omitted?

Of course. If your middle-tier component is a Web service, you can simply invoke the middle-tier component from the user interface, eliminating the step of building an ASP page. To invoke the Web service, you can use the Microsoft SOAP Toolkit or. NET, you can also use the SOAP client you developed yourself, and then connect it to your application. This will not only shorten the development cycle, but also reduce the complexity of the code and enhance the maintainability of the entire application. At the same time, your application no longer needs to jump to the corresponding "results page" every time the middle-tier component is invoked.

In my experience, in an application where there is more interaction between a user interface and a middle tier, the use of a Web service structure can easily save 20% of the development time spent on user interface programming. Another benefit of doing this is that you will get an intermediate layer of Web service that can be reused in application integration or other contexts. Finally, exposing your application's logic and data through a Web service can also allow customers on other platforms to reuse your application.

Application integration

Enterprise-Class application developers know that enterprises often have to integrate various programs written in different languages on different platforms, and this integration will cost a lot of development power. Your application often needs to get data from a program running on an old IBM host. or send the data to a host or UNIX application. Even on the same platform, software produced by different software vendors often needs to be integrated. With Web service, applications can expose functionality and data to other applications using standard methods.

For example, you have an order login program that is used to log in new orders from customers, including information about customer information, shipping address, quantity, price, and payment methods. At the same time, you also have an order execution procedure for the actual delivery of goods management. The two programs are 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 layer of Web service to the order execution program, the order execution program can expose the "AddOrder" function. Thus, whenever a new order arrives, the order login program can call this function to send the goods. And then integrate the application through the Web service

Business-to-business Integration

Integrating applications with Web service can make business processes within your company more automated. But what happens when a deal crosses your suppliers and customers and breaks the boundaries of the company? Business transaction integration across companies is often called business-to-business integration.

Web Service is the key to successful business-to-business integration. With Web service, your company can expose critical business applications to designated suppliers and customers. For example, if you expose your electronic billing system and electronic invoice system, your customer can send you a purchase order electronically, and your supplier can send you an electronic invoice to purchase the raw materials. Of course, this is not a new concept: Electronic document interchange (EDI) is a long way off. The main difference between Web service and EDI is that Web service implementations are much simpler to implement than EDI, and Web service is run on the internet and can be easily implemented anywhere in the world, so it costs less to run. However, unlike EDI, WEB service is not a complete solution for document exchange or business-to-business integration. Web service is just a key part of business-to-business integration, and many other parts are needed to complete this integration.

The biggest benefit of business-to-business integration with Web service is the ease with which interoperability can be achieved. As long as you expose your business logic and become a Web service, you can allow any designated partner to easily invoke your business logic, regardless of what platform their system is running on and what development language they are using. This greatly reduces the time and cost of spending on business-to-business integration. This low cost makes business-to-business integration possible for many small and medium-sized enterprises that cannot afford EDI investment costs.

Software Reuse

Software reuse is a big topic, it has a lot of form and degree. The most basic form is the source code module or class-level reuse. Another form is the binary form of component reuse. Currently, reusable software components such as tabular controls or user interface controls have a large share of the market. But 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 and even source code, but it's not easy to publish data unless those data are static data that doesn't change very often.

Web service allows you to reuse code, while reusing the data behind the code. With Web service, you no longer have to purchase, install, and invoke components from third parties, as you did before. All you have to do is call the remote Web Service directly. For example, if you want to confirm a user's email address in your application, just send the address directly to the appropriate Web service, which will help you look up street addresses, cities, provinces and postal codes, Confirm that this address is indeed in the corresponding ZIP code area. The provider of a WEB service can charge for the service by time or by the number of times it is used. It is impractical for such a service to be implemented through component reuse, because then you must download and install a database that contains information such as street address, City, province, and zip code, and this database is not updated in real time.

Another scenario for software reuse is to integrate the functionality of several applications. For example, you want to build a portal application on a LAN that allows users to query their FedEx packages, see stock quotes, manage their schedules, and buy movie tickets online. There are now many application vendors on the Web that implement these features in their applications. Once they are exposed to the Web service, you can easily integrate all of these features into your portal and provide a unified, friendly interface to your users.

Use Web service to integrate the functions of various applications, to provide users with a unified interface many applications use Web service to extend the current component-based application architecture into a hybrid structure of components and Web service. You can also use the functionality provided by Third-party Web service in your application. You can also provide the functionality of your own application to others through a Web service. In all of these cases, you can reuse the code and the data behind the code. In short, Web service will be a very powerful form of software reuse.

When should you not use Web service

A complete introduction to Web service should also include when the Web service should not be used. After the previous introduction, we know that Web service is most useful when it is interoperable through the Web or remotely invoked. However, there are many situations in which Web service does not offer you any benefit at all.

Stand-alone applications

At present, we also have a lot of desktop applications for commercial and personal use. Some of these only need to communicate with other programs running on this computer. In this case, we'd better stop using the Web service, as long as the local API is available. COM is ideal for working in this situation because it is small and fast. The same is true of server software running on a single server: It is best to use COM or other local APIs to make calls between applications directly. Of course, Web service can also be used in these situations, but that will not only consume too much, but it does not bring you any benefits.

Homogeneous applications on the local area network

In many applications, all of your programs are developed with VB or VC, all in the Windows platform using COM, are running 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 on the LAN. Using DCOM in these programs is much more effective than soap/http. Similar, if one of your. NET program to connect to another on the LAN. NET program, then you should use. NET Remoting. Interestingly, in the. NET remoting, you can also specify the use of Soap/http for Web service invocation. However, it is better to make RPC calls directly through TCP, which is much more effective. In short, as long as you look at the application structure from the point of view, there are other ways than the Web service more efficient, more feasible, then do not use the Web service.

Summarize

Web Service is a new platform to create interoperable distributed applications. The primary goal of WEB service is interoperability across platforms. To achieve this goal, the WEB service is completely based on XML, XSD, and other platform independent of the software vendor's standards.

Web Service is useful for applications that communicate across platforms and across networks. Web service is useful for application integration, business-to-business integration, code and data reuse, and for client and server communication over the Web.

Of course, Web service is not everything, you can't abuse Web service everywhere. In some cases, Web service can degrade the performance of your application without bringing any benefits. For example, a machine or a homogeneous application running in a local area network should not communicate with a Web service.