Conceptualizing a dynamic web service demo engine

Introduction: Ever since the dawn of the Internet Application Service Providers have developed internet based applications for which they can charge through a subscription based business model. Earlier there was no standardization across these online service offerings, but web services emerged to create various standards for providing these online services: SOAP, UDDI, etc. Internet businesses adopted web services quickly and started introducing pay-to-use services on the Internet. Many companies even made publishing web services through a subscription model as their core business (weather services, financial data, etc.).

Problem: One of the challenges that you face, when you are selling web services is this: "how do you showcase your product to a potential customer". The answer can be simple, make a demo web page which allows prospects to play with the web service and try it out before subscribing to it. This is indeed simple, if you are selling one or two web services. However, if you are providing anything more than a handful of services, then creating, maintaining, updating, and updating a web page for every service and its various versions that you sell can be a nightmare.

Solution: A solution for such a scenario can be the use of an engine which can dynamically render a user interface for any given web service on demand. Let’s call this as the ‘web service demo engine’.

The advantages for such an engine are obvious:

• no additional effort when publishing new services
• smaller code-base to maintain

There are various challenges to as well, if such an engine is to be implemented. These include:

• the engine needs to be extensible to and flexible to absorb any changes to existing web services.
• web service parameters can vary from being simple data types (such as integers) to collections, custom objects, etc. The demo engine needs to be able to interpret any data type and render its UI efficiently.
• similarly, the web service response may contain a variety of data types (though XML) – tables, charts, images, etc. The engine should be able to interpret this data an render the output correctly.
• the engine should render the UI to allow users to enter the input data for the web service, and should perform basic business rule validation to ensure input data makes sense.
• the basic goal is that the engine should be completely configurable, and should not require re-coding whenever a new service is released.

As can be seen, some of this information is not even present in the WSDL of the web service, so any engine that hopes to achieve all of the above needs some help other than the WSDL. A possible solution is to have a configuration file published with every new web service that carries this information. Such a configuration file would carry a number of items:

• business data definition
• input controls information
• output controls information
• information about grouping of input and output controls
• business rules for input validation
• output data rendering information
• information about the web service itself
• mapping for input control to web service parameters

This configuration file can be generated by hand, or auto-generated partially through the use of custom code attributes or custom tools when the web-service itself is being developed.  Through the use of this information, an engine which renders demo pages for any given web service is conceivable.

How is creating a configuration file per web service better than creating individual web pages per service? There are several ways in which this is better:

• the configuration files generation can be largely automated.
• the central demo engine makes it easy to have consistent UI and style when rendering.
• you only manage one code base. Imagine if tomorrow, you wanted to add specific authentication mechanisms to provide access to the demo pages. If you had a demo engine, you only will have to make that change in one place.
• it decouples the rendering of the UI from the web service itself – a web page per service is very tightly coupled with the service it is demonstrating.

Has anyone implemented a similar solution or encountered a similar problem and provided a different solution? We would love to discuss this through the comments.