The following is an article that I co-authored (along with Brijesh Chenan and Rahul Sawhney) almost 4 years back. We represented Philips Software and presented this for the ‘Road Ahead Contest’ conducted by Microsoft India and got selected as the best paper :-)
But why talk about this now? Well, I came across this document when I was going through some of my old papers and what struck me was that, most of the stuff that we predicted in this paper have (or is in the process of) become a reality. So please read on…
Today we are witnessing another era of explosive growth on the web. The web has come a long way, from static content to dynamic content and now to programmable web services. The Internet has metamorphosed into a pervasive computing domain, providing value-added services. This means that the web is now available in ways never imagined in the past.
The web is now mature enough in terms of availability of services. All the functionality that you would want is probably already there on the web. But the truth is that only a knowledge worker can harness the full power of the programmable web. Further there is no integration of web services into applications that people use daily. It is time to start thinking about bringing this power to the common man.
This paper proposes some enhancements to the existing web services framework for better integration between web services and applications accessing them.
While embarking on a web services approach, several important questions come to mind.
As web service providers
As application developers,
The answers to these questions lead us to the next generation of killer applications.
These applications will be able to utilize the zillions of services out there and the ones that are yet to come. Armed with the knowledge of web services, they will be able to proactively help users in getting their work done. As developers we should focus not only on exposing services but also be capable of locating and binding to existing and future services on the net.
To illustrate, let’s look at the following scenario.
Suppose you are interested in online trading and would like to check out the top-ten movers. Further, you might also want to transact on them. In today’s world, typically you would use your browser to search the web for online stock trading services. You would then choose one of these services and then navigate to its site. Here, you would click the link for the top-ten movers. In the list returned, you find MSFT (Symbol for Microsoft Corporation stock at NASDAQ) interesting and want to buy 100 shares. To do this, you would click the corresponding link on the site and make the transaction. Now, suppose you want more information about MSFT from some other service, or make the trade elsewhere, you would have to perform the same operations all over again at the second site. You obviously cannot use the data you obtained from the first site to invoke services at the second site.
Let us see how the killer applications of tomorrow alter this scenario. You fire up the next generation Excel and run a web query on the top-ten movers. The web query returns the results from the web service and formats it on screen. You find MSFT interesting, so you right click on the symbol ‘MSFT’. The context menu shows you the option “Web Actions -> Get Detailed Stock Quote…”. When you click this option, it returns the latest stock quote update on MSFT. You then decide to buy 100 shares, so you right click and select “Web Actions à Buy this stock…” on the context menu and go on to complete the transaction (See figure below).
Using Excel, you query your portfolio (probably from another web service) and see your open positions. You see that you are long on ‘MSFT’ and decide to sell 50. You go to the corresponding field and edit it to 50. Excel automatically prompts you “Do you want to sell?” You press “Yes” to complete the transaction.
This can be achieved through a combination of two enhancements to current web services framework.
The WSDL (Web Service Description Language) file provides the application with an interface description of that web service. Each of these web methods returns XML data. With the current standards, it is not possible for the application to figure out what further can be done on these data. The application will have to rely on custom hard-coded logic to invoke further actions on the data. If we have another XML file that will contain the mapping between the data elements and what actions can be invoked on them, the application can be much more proactive in helping the user get the work done. These actions relate to other web-service methods, which could be provided by either the same or some other web-service provider.
In short we propose to provide a link to an XML file within the WSDL file for a web-service. Bodies such as W3C (World Wide Web Consortium) can standardize the schema for this XML file.
With this in place, the application in the illustrated Scenario will be able to provide context actions like “Get Latest Stock Quote” and “Buy this stock” because it automatically knows what can be done with the data.
We feel that the concept of associating web services and data is very powerful. It opens up new avenues for applications to interact with multiple web services on behalf of the user without him having to write any programming logic.
We have seen how the mapping between data and actions will enable the user to invoke services for that data. But the user has to initiate this action, probably through a context menu. We can take this to the next level by making our applications intelligent so as to invoke corresponding services automatically.
In the above Scenario, when the user modified the field containing the number of stocks in his portfolio, Excel understood that the user is doing an ‘Edit’ action on that data item (which was returned by a web service). It is now up to Excel to find out which method corresponds to the ‘Edit’ action for the data item being edited. Once this method is identified, consent from the user is obtained to invoke it on the server to make the transaction.
A standardizing body can define an XML file that lists certain commonly performed actions (e.g. verbs like edit and delete). Next generation applications should be aware of these verbs defined in this XML file and be able to translate user-actions to them. A service provider while publishing the service can also provide a mapping XML file. This file specifies the verbs associated with data that is returned from each web method. In turn, each verb is mapped to a web method that is invoked when the user performs the corresponding action at the application side. The schema for this file should also be standardized.
The Internet will continue to evolve as a source of computational services rather than a repository of content. The web will gradually move towards a state where more and more value-added services will be presented as web services. The killer applications of tomorrow will be the ones that can seamlessly integrate these web services. These applications will replace the browser as the main interaction point to the web and blur the boundary between the local and the remote.
The standards of today focus more on how to locate, identify and bind to services. We should also focus on standards that define consumption of these services. This will allow applications to behave intelligently to identify and invoke services from disparate sources, transparent to the user.