Primer: Web Services Experience Language

 
 
By Kevin Fogarty  |  Posted 2005-02-01
 
 
 

What is it? A language designed to allow Web site owners to present—on their own Web sites, and carrying their own brand and look-and-feel—an application they buy or rent from someone else. The idea is to let application developers build software that provides a specific function, and let other people integrate that function into their own offerings without having to build it themselves.

How does it work? Just as the ubiquitous Extensible Markup Language provides a standard method to identify, tag and present data, WSXL provides a method to describe how applications are presented. Using those specifications, developers can change the appearance of an application without changing its underlying functions, allowing them to adapt one application to multiple purposes.

View the PDF -- Turn off pop-up blockers!

What's a real-life example? The same mapping application could appear on a retailer's site to give customers directions to the nearest store, and on a real-estate site to let customers identify neighborhoods in which they'd like to buy.

Right now, it's possible to embed an application from one company's Web site in a portal site created by another. But you can only do that by embedding the interface—logos, look-and-feel, etc.—in the portal site. The program running the portal site knows there's content there, but doesn't know what it is or what to do with it.

With WSXL, the portal would know that, in this case, the map is an application rather than a photo or logo. It would know to change the colors of the text and border to match those of the host site, where on the site the new application should go, and how to format the window and text labeling to match the rest of the site.

Why would I want to try it? You might want to put a stock ticker, travel-booking service or mapping application on your site, but don't want to build it yourself. WSXL is designed to let Web site owners go into business together by presenting one application within another, then sharing the revenue that comes from the combination of the two.

How would the business relationship work? Like a wholesaler and retailer; but it's online, using services instead of physical goods. The site owners, whether or not they actually charge for the service supplied by third-party software, essentially become value-added resellers of that software. Like a retailer who buys computer equipment to resell at a physical store, site owners buy the rights to present a service on their sites, and split the proceeds with the company that provides the service. The application provider might get a cut of any sales made using the tool; or, in the case of the mapping application, might be paid according to the number of times it's used, in the same way a direct-mail-marketing firm is paid for each prospective sale it generates.

What's the drawback? It's complicated—as you might expect from technology designed to get software from several different companies working seamlessly on the same site while securely exchanging financial data.

IBM, which led development of WSXL and released the first development tools, recommends that you build a site by putting together a set of WSXL components that define the site and how the components will interact. Then add some WSXL components to control how the components are presented, and others to do the actual presenting. You'll also have to build or buy software to monitor the activity of each module and control the flow of data among them, or build in the ability to use Web Services Flow Language or Business Process Execution Language (both of which provide some workflow capability as well as discrete process-automation functions) to manage that job.