Web Service "Four long and two short"

Web Web Service "Four long and two short"
(China computer newspaper Chen Youliang November 01, 2001 17:42)

Currently, Web service is a hot topic. But what exactly is a Web service? Under what circumstances should you use a Web Service? Under what circumstances should you not use a Web Service? is what we need to know correctly.

In fact, the primary goal of WEB service is interoperability across platforms. To achieve this goal, the Web Service is a new platform for creating interoperable, distributed applications based entirely on platform-independent, software-independent standards, such as XML (Extensible Markup Language), XSD (XML Schema), and so on. It can be seen that in the following three situations, the use of Web service can bring great benefits.

Forte One: communication across firewalls
If the application has thousands of users and is distributed around the world, communication between the client and the server will be a tricky issue. Because there is usually a firewall or proxy server between the client and the server. In this case, the use of DCOM is not so simple, it is often not easy to publish the client program to such a large number of each user hands. The traditional approach is to choose to use the browser as the client, write down a large pile of ASP pages, the application of the middle tier exposed to the end user. The result of this is that the development is difficult and the program is difficult to maintain.


Figure 1 Integrating applications through Web service
For example, add a new page to the application, you must first create a user interface (Web page), and after this page, include the middle-tier component of the corresponding business logic, and then create at least one ASP page to accept the user input, call the middle-tier component, and format the result in HTML. Finally, send the results page back to the browser. If client code is no longer so dependent on HTML forms, the client's programming is much simpler.

If the middle-tier component is replaced with a Web service, the middle-tier component can be invoked directly from the user interface, eliminating the step of building an ASP page. To invoke a Web Service, you can directly use a SOAP client such as Microsoft SOAP Toolkit or. NET, or you can use a SOAP client that you develop, and then connect it to your application. Not only shortens the development cycle, but also reduces the complexity of the code and enhances the maintainability of the application. At the same time, the application no longer needs to jump to the corresponding results page each time the middle-tier component is invoked.

From experience, in an application where there is more interaction between a user interface and the middle tier, the use of a Web service structure can save 20% of development time spent on user interface programming. In addition, the middle tier, which consists of Web service, can be reused in application integration or other contexts. Finally, the application's logic and data are "exposed" through Web service and can be reused for customers on other platforms.

Forte Two: application integration
Enterprise-Class application developers know that organizations often have to integrate programs that are written in different languages and run on different platforms, and this integration will take a lot of development power. Applications often need to get data from a program running on an IBM host, or send data to a host or UNIX application. Even on the same platform, different software vendors produce a variety of software also often need to integrate. With Web Service, applications can "expose" functionality and data to other applications using standard methods.

For example, there is an order login program that is used to log in new orders from customers, including customer information, shipping address, quantity, price and method of payment, and an order execution procedure for the management of the actual delivery of goods. The 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 layer of web Service to the Order execution program, the Order execution program can "expose" the "ADD orders" function. Thus, whenever a new order arrives, the order login program can call this function to send the goods.

Forte III: 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 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, companies can "expose" critical business applications to designated suppliers and customers. For example, to "expose" an electronic billing system and an electronic invoice system, customers can send orders electronically, and suppliers can send raw material purchase invoices in an electronic manner. Of course, this is not a new concept, EDI (electronic document exchange) is already the case. However, the implementation of the Web service is much simpler than EDI, and the Web service runs on the internet and can be easily implemented anywhere in the world, with relatively low operating costs. However, Web service is not a complete solution 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 achieve integration.

The biggest benefit of business-to-business integration with Web service is the ease with which interoperability can be achieved. As long as the business logic is "exposed" and becomes a Web Service, it allows any designated partner to invoke these business logic, regardless of the platform on which their system runs, and what development language they use. This greatly reduces the time and cost of business-to-business integration and enables business-to-business integration for many small and midsize enterprises that are otherwise unable to withstand EDI.

Forte Four: Software and data Reuse
Software reuse is a very big theme, reuse a lot of forms, the degree of reuse is greatly small. The most basic form is the source code module or class one level reuse, the other form is binary form of component reuse.


Figure 2 integrates functionality in various applications with Web service to provide a unified interface for users
Currently, reusable software components, such as tabular controls or user interface controls, have a large share of the market. However, the reuse of such software has a large limitation, that is, reuse is limited to code, data can not be reused. The reason is that it's easier to publish components and even source code, but it's not as easy to publish data, unless it's static data that doesn't change very often.

Web Service can reuse the data behind the code while allowing it to be reused. With Web service, it is no longer necessary to purchase, install, and then invoke components from a third party, and then call them from the application, just to call the remote Web Service directly. For example, to confirm the user input address in the application, simply send the address directly to the appropriate Web service, this Web service will help you check the street address, city, province and postal code, etc. to confirm that this address is 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 impossible for such a service to be implemented through component reuse, so you must download and install a database that contains information such as street address, City, province, and zip code, and this database cannot be updated in real time.

Another scenario for software reuse is to integrate the functionality of several applications. For example, to build a portal application on a local area network, allowing users to query FedEx packages, view stock quotes, manage their own 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" through the web Service, they can easily integrate all of these features into your portal, providing a unified, friendly interface for users.

In the future, many applications will use Web service to extend the current component-based application architecture into a hybrid structure of component/web service, to use the functionality provided by Third-party WEB service in the application, or to put their own application functionality through the Web Service provided to others. In both cases, the code and the data behind the code can be reused.

As you can see from the above discussion, Web Service is most useful when interoperating through the Web or remotely invoked. However, there are also situations where WEB service does not bring any benefits at all.

shortcoming One: stand-alone application
At present, enterprises and individuals also use a lot of desktop applications. Some of them only need to communicate with other programs on this computer. In this case, it is best not to use the Web Service, as long as the local API is OK. COM is ideal for working in this situation because it is small and fast. The same is true for server software running on the same server. It is best to use COM or other local APIs directly to make calls between applications. Of course, Web Service can also be used on these occasions, but that would not only consume too much, but would not bring any benefits.

Disadvantages Two: The homogeneous application of LAN
In many applications, all programs are developed with VB or VC, all in the Windows platform using COM, are running on the same LAN. For example, there are two server applications that need to communicate with each other, or programs that have a WIN32 or WinForm client program to connect to another server on the LAN. In these programs, using DCOM is much more effective than soap/http. Similar to this, if one. NET program to connect to another. NET program on the local area network, you should use the. NET Remoting. Interestingly, in. NET remoting, you can also specify the use of Soap/http for Web Service calls. However, it is better to make RPC calls directly through TCP, which is much more effective.

In short, as long as there are other ways to be more efficient and viable than Web service from an application architecture perspective, do not use Web service.