An Introduction to Web Services

By Guido L. Geerts, Robert L. Paretta, and Clinton E. White, Jr.

E-mail Story Print Story

Finance and Accounting Web Services

Finance and accounting-oriented web services are proliferating rapidly. A particularly interesting one can be found at: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnxpwst/html/odc_ofwstrex.asp. This web service uses the delayed stock quote web service provided by Xmethods (www.xmethods.net) to download specific stock quotes directly into a Microsoft Excel spreadsheet. Finance and accounting professionals often need data about a company’s financial performance to use for further analysis. The normal process is to get the required data either online or from a printed document, manually enter it into the appropriate cells of a spreadsheet, and run the analysis. This web service, however, uses an Excel spreadsheet to “talk” to a database of stock quotes on the Internet, downloading specific data as requested.

Another finance and accounting web service is a subscription service that provides real-time access to the Edgar database of SEC filings. Created by XigniteEdgar (www.xignite.com), this web service enables users to monitor the SEC Edgar database for submissions and then download recent filings.

Yet another is a web service provided by Inkostar, which translates accounting data in XML (Extensible Markup Language) format to IIF (Intuit Interchange Format) for input to a QuickBooks application (www.inkostar.com/iifws/default.asp).

Flexibility of Web Services

Web services do not require extensive modification of existing software. Dun & Bradstreet offers “Tracking Folders,” a web service that allows subscribers to continually monitor customer, suppliers, competitors, or business partners, for credit checks, collection processes, and more. Subscribers to the Dun & Bradstreet tracking web service maintain folders on their local computer and automatically receive information that could affect business decisions. Essentially, the service plugs various Dun & Bradstreet software applications into software applications on a subscriber’s computer. The subscriber pays an ongoing fee for the service, and can add additional applications or drop them at any time without modifying or disabling software applications.

How Do Web Services Work?

The key to making web services work is data, process, and communication standards. The communication protocol standard is the same as the Internet, TCP/IP. All computers can “talk” TCP/IP. The data standard is XML, a set of syntax rules for adding meaning to data and for building other XML standards. The process standards are actually a set of evolving XML standards: SOAP (Simple Object Access Protocol), for packaging messages from one software application to another; WSDL (Web Services Description Language), for describing the web services processes in terms a software application can understand; and UDDI (Universal Description, Discovery and Integration), for describing how to find and use an available web service.

The actual workings of web services can be described from a provider’s and a user’s perspective. From a provider’s perspective, a web service is created by using the data, process, and communication standards identified above to create a web interface to one or more software applications. Most of the web services described above provide data from a database in response to specific request parameters. In essence, a web service responds to a “get data” command by reading the data from a database and sending it back to a software application on the Internet. To actually create such a web service, the provider uses WSDL to define the allowable read access “get data” commands that the database management software can understand. The web service also knows how to put the results in a SOAP envelope addressed to the requesting software application and how to send it via the Internet.

From a user’s perspective, a software application must be able to issue the appropriate commands, put them in a SOAP envelope, and send them to the web service interface for processing. This usually requires downloading the WSDL and plugging it into a software application. For example, to use the Xmethods delayed stock quote web service, users employ a web browser to access the WSDL, plug it into an Excel spreadsheet, click the “insert stock quotes” icon that gets added to the Excel tool bar, and fill in the necessary information in the po-pup window. Because the Excel spreadsheet knows how to process XML, it packages the commands in a SOAP envelope addressed to the web service and sends it. When the return SOAP envelope arrives from the web service, Excel knows how to process it and insert the requested data in the appropriate cells. All current software packages, including Microsoft Office, Internet Explorer, and Quicken, can understand and process XML and can therefore interface with web services. General ledger and other accounting packages should soon become XML-enabled.

A further objective is to fully automate the process of finding and using web services. Web service providers will publish the availability of their applications, using UDDI to describe their location and available services and WSDL to define how to use them. When a user logs on to the Internet and launches a software application, it will be able to identify available web services by reading the UDDI. The software application will then “learn” how to use the web services by accessing their WSDL definitions. When the desired web service is found, the user will simply tell the software application to access it by downloading its WSDL interface instructions. All of the complexity is hidden behind the interface.

Today, IBM, Microsoft, and a few others have established UDDI repositories of web services that work similarly to the stock quote example above. The future holds fully automated web services from many entities, available by way of UDDI repositories.