Last month I introduced the XML components of Web services: SOAP (simple object access protocol), WSDL (Web services description language) and UDDI (universal description, discovery and integration). This column provides two examples that illustrate how Web services can be used within and between enterprises.
The first example uses Web services within an enterprise. The problems that we discussed in previous months arising from redundant data with redundant data entry to make required changes to each redundant database resulted in redundant work, staffing and often training for the different data entry procedures for each database. Manual procedures were used to make the required changes. These procedures were slow, error-prone and expensive. Additionally, other problems were encountered until all changes were made because the different versions of the data were not synchronized.
Web services offer considerable benefit here. Using SOAP, each data entry maintenance program used to change a redundant database can be defined so that the data changes are expressed as Web services. For example, a Web service can be defined to create new customer using SOAP, invoking the create customer logic and business rules within the customer data entry program used by the sales department. Similarly read customer, update customer and delete customer Web services can also be defined to invoke the corresponding read, change or delete logic and business rules in the customer data entry program. In the same way, create client, read client, update client and delete client Web services can be defined with SOAP to invoke the corresponding logic and rules in the client data entry program for the credit control department. Similar SOAP Web services can also be defined to invoke the debtor data entry program logic and rules in the accounts receivable section of the finance department.
Previously, if a customer database change was made manually by the sales department, a change database notice form also had to be printed. This was then sent to the credit control and accounts receivable sections so they could also make the relevant manual data changes to the client and debtor databases that they maintain. We discussed that these manual changes were slow, error-prone and expensive. In the past, the only way to avoid this manual updating was to completely replace the separate redundant databases with an integrated database. In addition, all of the previous application programs that used the redundant databases would have had to be replaced by new, integrated programs that used the integrated database. This database and application program redevelopment and replacement were extremely expensive and complex.
Now these data changes are expressed as Web services for each of the redundant databases. Each Web service is specified using WSDL, which identifies the defined SOAP specifications and relevant SOAP input and output messages. When the WSDL specifications are published to the intranet Web server, the change database notice form is replaced by WSDL-defined Web services. Each WSDL specification identifies the relevant SOAP messages needed to invoke data change logic and business rules in the customer, client or debtor databases.
The slow, error-prone manual procedures for data entry are now replaced by real-time, dynamic Web service transactions. These are sent via the intranet as SOAP messages that invoke the relevant Web service in each database needed to keep the redundant data current. The result is the immediate completion of all related database changes to all relevant databases. With Web services, you may keep redundant databases which may be updated by their separate data entry programs. This updating is now faster and automatic using SOAP messages and Web services in real time and may be a better alternative than redeveloping and replacing the databases and programs with integrated databases and programs.
In the second example, we will look at the ordering of products or services from an online store via the Internet to show the use of Web services outside the enterprise.
The store accepts orders online for payment by credit card. The credit card must first be approved by the relevant bank. If the card is valid and credit is available, payment is credited to the store's bank account. The store then orders the requested products or services from its supplier and arranges with a shipping company for the goods to be picked up from the supplier and delivered directly to the customer. This is called "drop-shipping."
In the past, the drop- shipping was arranged via mail, phone or fax in communication with the bank, the supplier and the shipping company. This process took time and often introduced errors or delays. To improve customer service, the store replaced this mail, phone and fax communication with online coordination. However, in the past, this presented severe problems using remote procedure call technologies. For example, the bank may use CORBA for online credit card authorization and payment. The shipping company may use COM, and the supplier may use yet another RPC approach. These different RPC interfaces added dramatically to the complexity and the time required to implement this online coordination.
Now let us consider this scenario using Web services. The bank defines its credit card approval and credit card payment processes using SOAP. It publishes the SOAP interfaces, as well as the input and output SOAP message formats, to its Internet Web server using WSDL. Then it registers these credit card Web services (defined by SOAP and WSDL) using UDDI to the UDDI registry at http://www.uddi.org/. Similarly the supplier and the shipping company register their respective Web services using SOAP, WSDL and UDDI.
To locate banks, suppliers and shipping companies that offer relevant Web services, the store visits the UDDI registry online. It issues UDDI "find" requests to locate Web services that satisfy its requirements. Using the SOAP, WSDL and UDDI specifications published by relevant companies, the store prepares the SOAP interface and input and output messages. It sends these SOAP messages to the URL Internet address of the relevant Web servers as published in the UDDI registry via UDDI and WSDL by the selected bank, supplier and shipping company.
This Web services approach has many benefits. A standard integration with Web services offered by any organization is used, regardless of global location. This has clear advantages of greater simplicity and ease of use. Benefits include faster implementation and lower cost which may increase profits or enable the company to lower prices.
Each of the Web services companies gain benefits also. Web services can be easily published for worldwide access. Depending on the value of a Web service to users worldwide, each Web service can be charged on a per-use basis. Such Web services which previously may have been inaccessible can now also generate additional revenue.
Next month I will provide a brief summary of vendors of Web service development tools. I will also provide links to a number of Web service resources on the Internet.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access