Web Services application scenarios

Web Service is a new Web application branch. It is a self-contained, self-describing, and modular application that can be released, located, and called through the Web. Web services can execute any function from simple requests to complex business processing. After deployment, other Web service applications can discover and call the services deployed by the application.
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 a new platform for creating interoperable and distributed applications. From this we can see that in the following three cases, using WebService will bring great benefits.
Item 1: Cross-firewall communication
If the application has thousands of users distributed all over the world, communication between the client and the server will be a tough 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.
Item 2: Application Integration
Enterprise-level application developers know that enterprises often need to integrate various programs written in different languages and run on different platforms, this 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, there is an order logon program used to log on to new orders from customers, including customer information, delivery address, quantity, price and payment method, and an order execution program, it is used to manage the actual delivery of goods. 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.
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.
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.
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.