WebService series Teaching (2)

Web 3. Technical characteristics of WebService
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 question
Problem. 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.
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.

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.