Under what circumstances should WebService be used

Currently, WebService is a hot topic. But what is WebService? Under what circumstances should we use WebService? Under what circumstances should we not use WebService? We need to understand it correctly.
In fact, the main goal of WebService is cross-platform interoperability. To achieve this goal, WebService is fully based on XML (Extensible Markup Language), XSD (XMLSCHEMA), and other standards independent of the platform and software vendors, is to create interoperable, distributed applications Program . From this we can see that in the following three cases, using WebService will bring great benefits.

long term 1: Cross-firewall communication
if the application has thousands of users and is distributed all over the world, therefore, communication between the client and the server is a tricky problem. Because there is usually a firewall or proxy server between the client and the server. In this case, using DCOM is not that simple, and usually it is not easy to publish the client program to every user with such a large number. The traditional approach is to use a browser as the client, write a lot of ASP pages, and expose the middle layer of the application to the end user. The result is that development is difficult and programs are difficult to maintain.
Figure 1 integration of applications through WebService
for example, to add a new page to an application, you must first create a user interface (web page ), at the end of the page, it contains the intermediate layer components of the corresponding business logic, and at least one ASP page should be created to accept user input information, call the middle layer components, 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, the client programming is much simpler.
If the intermediate layer component is changed to WebService, you can directly call the intermediate layer component from the user interface to save the step of creating an ASP page. To call WebService, you can directly use a soap client such as microsoftsoaptoolkit or. NET, or use a self-developed soap client to connect it to the application. This not only shortens the development cycle, but also reduces Code complexity and enhances the maintainability of applications. At the same time, the application does not need to jump to the corresponding "result page" every time it calls the middle layer components ".
in terms of experience, using the WebService structure in an application with many interactions between the user interface and the middle layer can save 20% of the development time spent on User Interface Programming. In addition, such an intermediate layer composed of WebService can be fully reused in application integration or other scenarios. Finally, the logic and data of applications are "Exposed" Through WebService, and customers on other platforms can reuse these applications.

long term 2: Application Integration
enterprise-level application developers all know that, enterprises often need to integrate various programs written in different languages and run on different platforms. Such integration will take a lot of development effort. Applications often need to obtain data from programs running on 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 WebService, applications can expose functions and data in a standard way for other applications.
for example, an order logon program is used to log on to a new order from a customer, including the customer information, delivery address, quantity, price, and payment method; there is also 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 WebService layer 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.

Item 3: B2B Integration
Using WebService to integrate applications can automate business processing within the company. But what happens when transactions cross the supplier and customer boundaries and break through the company's boundaries? Cross-company business transaction integration is usually called B2B integration.
WebService is the key to successful B2B integration. Through WebService, the company can "expose" key business applications to specified suppliers and customers. For example, if the electronic order system and electronic invoice system are "Exposed", the customer can send orders electronically, and the supplier can send raw material procurement invoices electronically. Of course, this is not a new concept. EDI (Electronic document exchange) is just like this. However, the implementation of WebService is much simpler than that of EDI, and WebService runs on the Internet and can be easily implemented anywhere in the world, resulting in relatively low operating costs. However, WebService is not a complete solution for document exchange or B2B integration like EDI. WebService is only a key part of B2B integration. It requires many other parts for integration.
The biggest benefit of using WebService to implement B2B integration is that it can easily implement interoperability. As long as the business logic is exposed and becomes a WebService, any designated partner can call these business logic, regardless of the platform on which their system runs and the development language. This greatly reduces the time and cost spent on B2B integration, so that many small and medium-sized enterprises that could not afford EDI can also implement B2B integration.

Item 4: software and data Reuse
Software reuse is a big topic. There are many forms of reuse, and the degree of reuse is small. The most basic form is Source code Module or class-Level Reuse, and binary Component reuse.
Figure 2 integrate functions of various applications with WebService to provide a unified interface for users
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 major limitation, that is, the reuse is limited to code, and the data cannot be reused. The reason is that it is easier to publish components or even the source code, but it is not so easy to publish data unless it is static data that will not change frequently.
WebService allows code reuse while reusing the data behind the code. To use WebService, you no longer need to purchase and install software components from a third party, and then call these components from the application. You only need to directly call the remote WebService. For example, to confirm the address entered by the user in the application, you only need to send the address directly to the corresponding WebService, this WebService will help you check the street address, city, province, province, zip code, and other information to confirm whether the address is in the corresponding zip code area. WebService providers can pay for this service on time or on the number of times they use it. It is impossible for such a service to be implemented through Component Reuse. In this case, 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, to create a portal application on a LAN, users can query FedEx packages, view stock market quotations, manage their schedules, and buy movie tickets online. Many Web application vendors have implemented these functions in their applications. Once they expose these functions through WebService, they can easily integrate all these functions into your portal site, provides users with a unified and friendly interface.
In the future, many applications will use WebService to expand the current component-based application structure to a hybrid structure of the component/WebService. Third-party WebService functions can be used in applications, you can also provide your application functions to others through WebService. In both cases, you can reuse the data behind the code and code.
From the above discussion, we can see that WebService is most useful for web-based Interoperability or remote calls. However, in some cases, WebService cannot bring any benefits at all.

Weakness 1: stand-alone applications
Currently, enterprises and individuals still use many desktop applications. Some of them only need to communicate with other programs on the local machine. In this case, it is best not to use WebService, as long as you use a local API. Com is very suitable for working in this case because it is small and fast. The same is true for the software running on the same server. It is best to directly use com or other local APIs to call applications. Of course, WebService can also be used in these scenarios, but it will not only consume too much, but will not bring any benefits.

Article 2: homogeneous LAN applications
In many applications, all programs are developed using VB or Vc, all use Com on Windows platform, and all run on the same LAN. For example, two server applications need to communicate with each other, or one Win32 or winform client program needs to connect to another server on the LAN. In these programs, using DCOM is much more effective than soap/HTTP. Similarly, if A. Net program is connected to another. Net program on the LAN, use. netremoting. Interestingly, in. netremoting, you can also specify soap/HTTP for WebService calling. However, it is better to call RPC directly through TCP, which will be much more effective.

In short, as long as there are other methods that are more effective and feasible than WebService from the perspective of application structure, we should not use WebService.