As more and more companies seek to conduct significant business over the Internet, they face the problem of making their applications work with those of their customers and suppliers.
The difficulty with this type of integration isn’t that it’s hard to get applications to send data and instructions to one another – you just decide on a common standard, write any needed converters, and that’s it. But as the number of applications goes up, the number of possible communications paths increases much faster.
Until recently, the only solution to this problem was to go with a middleware product. For example, the Windows operating system, which you can think of as a very successful middleware application, provides a common messaging environment for much of today’s desktop software.
But suddenly, all of those middleware vendors (including Microsoft Corp.) are scrambling furiously to position themselves to survive what’s about to be a big shock to the current system: Web services.
Web services are applications that use a universal language to send data and instructions to one another, with no translation required. And they use the Internet, so most of the connection problems are eliminated.
So far, the Internet has been used primarily in a people-centric way. Applications send out data for humans to read through Web browsers. If another application is on the receiving end, it has to “scrape” the information off the screen (a task bound to fail as Web and application designers change page layouts and move elements around), or it has to use a dedicated back channel.
An example of a company using both strategies is Yodlee.com Inc., a Redwood Shores, Calif.-based provider of financial account aggregation services to banks and portals. Yodlee either scrapes your checking and credit card balances off Web pages by logging in and pretending to be you, or it asks each financial institution individually to send it the data.
It’s a slow process. And just the kind of thing Web services could handle better.
What’s To Come
Here’s a hypothetical example of how Yodlee could work in a year or two, if banks were to create appropriate Web services: Tired of fielding numerous requests for data feeds, each bank could set up a Web service that provides account balances.
The address of the Web service would be published in a directory the Universal Description, Discovery and Integration directory which locates each Web service on the Internet.
Then each bank would write a description of what its Web service would require as input and what information would be given out in return. For example, the bank would want the customer’s account number and personal identification number or password, and confirmation that payment for the information had been sent. The format for this description would be defined in the XML-based Web Services Description Language.
On the front end, the bank would need to limit access to customers’ account balances to a select list of approved intermediaries. That would require authentication through passwords, public keys or other mechanisms. Then it might want to prioritize requests say, by how much customers are paying the bank for the service. Finally, it would want to confirm that payment for the service had arrived and maybe even send a receipt.
Several vendors are lining up to enable all of these functions as Web services. One such vendor is Grand Central Networks Inc. in San Francisco, which offers a choice of authentication methods, access restriction, prioritization and nonrepudiation. Another security and authentication provider is New York-based CertCo Inc.
If a bank wanted to build a system from scratch, Microsoft offers BizTalk Server, which can handle logging, authentication and routing. On the back end, the Web service would have to get each customer’s balance somehow. One way would be to scrape the data off a green screen or other interface. This isn’t much more advanced than what happens today, except that the bank itself would be doing the scraping and thus could control the process.
Another alternative would be to turn the legacy application into a Web service by adding code or recompiling it to run on, say, Microsoft’s emerging .Net platform. Microsoft claims that its .Net initiative supports a variety of languages and that it will be able to turn legacy applications into Web services when it’s released later this year.
Existing middleware infrastructures could also be used for that purpose, and the leading vendors are lining up products including IBM’s WebSphere and San Jose-based BEA Systems Inc.’s WebLogic.
Now, the really interesting questions involve the longer-term implications of Web services. What happens when new applications can interact with all others regardless of machine, language, operating system or middleware? What new, unforeseen applications may emerge from this capability? And will we be able to adequately safeguard such increased traffic?
More examples of Web services can be found at http://www.xmethods.com. Want to try some out? San Jose-based Adobe Systems Inc. has a Web service that translates HTML, graphics and Microsoft Office files into Portable Document Format files. It can be found at https://createpdf.adobe.com. Another Web service ( http://webservices.eraserver.net/zipcoderesolver/) will look up the ZIP code of any U.S. address.
Standards For Web Services
SOAP (Simple Object Access Protocol)
