Under what circumstances should Web service be used?

Now I'm going to list three scenarios in which three cases you'll find that using Web service can be a great benefit. Later on, I will cite some scenarios where Web service should not be used.

Cross-firewall communication

If your application has thousands of users and they are all around the world, then communication between the client and the server will be a tricky issue. That's because a firewall or proxy server usually occurs between the client and the server. In this case, it's not that easy to use DCOM, and usually you don't want to publish your client program to a large number of users. So, you finally chose to use the browser as a client, write down a bunch of ASP pages, exposing the middle tier of the application to the end user. And the result? If you're lucky, it's just a little bit more difficult to develop, and if you have bad luck, you'll get an app that can't be maintained at all.

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

Of course. If your middle tier component is a Web service, you can simply call the middle tier component directly from the user interface, eliminating the step of building an ASP page. To invoke a Web service, you can directly use Microsoft SOAP Toolkit or. NET, you can also use your own SOAP client, 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 each time a middle-tier component is called.

In my experience, in an application with more interaction between the user interface and the middle tier, using the Web service architecture, it is easy to 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 entirely 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 it is common for businesses to integrate programs that run on different platforms in different languages, and that integration will take a lot of development power. Your application often needs to get data from programs running on older IBM hosts; or send the data to a host or UNIX application. Even on the same platform, different software vendors produce a variety of software that often needs to be integrated. With Web service, applications can expose functionality and data in a standard way for use by other applications.

For example, you have an order login program that is used to log in to new orders from customers, including information such as customer information, shipping address, quantity, price, and payment method. At the same time, you also have an order execution procedure for the management of the actual delivery of the goods. These two programs are from different software vendors. After a new order comes in, the order login procedure 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, the order login program can call this function to send the goods whenever a new order arrives. Integration of applications through Web service

Business-to-business integration

Integrating Applications with Web service enables you to automate business processing within your company. But what happens when a deal crosses your suppliers and customers and breaks the boundaries of the company? Cross-company business transaction integration is often referred to as a to-do integration.

Web Service is the key to the success of business-to-business integration. With Web service, your company can expose critical business applications to designated vendors and customers. For example, exposing your e-mail system and E-invoicing system, your customers can send you a purchase order electronically, and your supplier can send you an invoice for the purchase of raw materials electronically. Of course, this is not a new concept: Electronic document exchange (EDI) that's the way it is. The main difference between Web service and EDI is that the implementation of a Web service is much simpler than EDI, and that Web service is run on the internet and can be easily implemented anywhere in the world, so it is relatively inexpensive to run. However, Web service is not a complete set of solutions for document exchange or business-to-business integration, as EDI does. Web service is just a key part of business-to-business integration, and many other parts are needed to complete this integration.

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

Software Reuse

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

Web service allows you to reuse the data behind the code while reusing the code. With Web service, you no longer have to purchase, install, and invoke these components from a third party, as you did before. You just need to call the remote Web Service directly. For example, if you want to confirm the email address entered by the user in your application, you simply send the address directly to the appropriate Web service, which will help you to check the street address, city, province, and zip code, Confirm that the address is indeed in the corresponding ZIP code area. The provider of a WEB service can charge for this service by time or by number of uses. It is unrealistic to expect such a service to be implemented through component reuse, because then you have to download and install a database that contains information such as street addresses, cities, provinces, and postal codes, and the 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 create a portal app on a local area network that allows users to query their FedEx packages, look at the stock market, manage their schedules, and buy movie tickets online. Now there are many application vendors on the Web that have implemented these features in their applications. Once they are exposed through Web service, you can easily integrate all of these features into your portal, providing users with a unified, user-friendly interface.

Using Web service to integrate functions in various applications, providing users with a unified interface many applications use Web service to extend the current component-based application architecture to 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 make the functionality of your own application available to others through a Web service. In all 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 not use Web Service

A complete description of the Web service should also include when the Web service should not be used. With the previous introduction, we know that Web service is most useful when it is interoperable or remotely invoked over the Web. However, in many cases, WEB service does not offer you any benefits at all.

Standalone application

Currently, we have many desktop applications for both commercial and personal use. Some of them only need to communicate with other programs that are running on this computer. In this case, we'd better not use the Web service, as long as the local API is available. COM is well suited to working in this situation because it is both 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 not only consumes too much, but does not bring you any benefits.

Homogeneous applications on a local area network

In many applications, all of your programs are developed using VB or VC, all in the Windows platform using COM, all 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 program on the LAN. Using DCOM in these programs is much more effective than soap/http. Similarly, if one of you. NET program to connect to another on the LAN. NET program, then you should use. NET Remoting. Interestingly, in. NET remoting, you can also specify to use Soap/http for Web service calls. However, it is best to make RPC calls directly over TCP, which is much more effective. In short, as long as you look at the structure of the application, there are other ways to be more effective than web service, 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, Web service is based entirely on the platform-independent, software vendor-independent standards of XML, XSD, and so on.

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 degrades the performance of your application without any benefit. For example, a single machine or a homogeneous application running on a LAN should not communicate with a Web service.

Under what circumstances should Web service be used?