Super Services, Process Portals and the Road to Composite Applications

Publicly accessible web services seem to be proliferating like rabbits days.   Not only are high profile early adopters such as Amazon.com, Ebay, Google and FedEx launching a plethora of new services, but an increasing number of more obscure firms are throwing their hats into the ring, offering everything from commodity futures prices to bible quotes.

Super Services
Theoretically, this large pool of publicly accessible web services should foster the creation of a new class of “super services”.  Super services simply combine several different web services into one master service.  They can be custom-designed to serve the needs of a specific company or be repackaged and offered to the public as yet another service.  In fact, there are already some interesting examples of enterprising developers stringing together a few web services to create a rudimentary websites which themselves could be exposed as super services such as this "mashup" of Amazon/Google/Yahoo, this mixing of Flickr and the US Government's zip code database, and this combination of Google Maps and Craigslist.

Unfortunately, creating a true super service is much harder than these early examples might suggest.  To create super services developers must not only link web services at a semantic and programmatic level but they must also find a way to successfully orchestrate a business process across these services in an orderly enough fashion that a basic level of performance and transactional integrity is maintained.   Luckily, emerging business process orchestration technologies, most prominently BPEL, provide a standardized mechanism for creating the process logic underpinning super services.   However, while adding BPEL to the mix has tremendous benefits it also makes the act of building super services even more complex and less accessible.

Process Portals
In recognition of both the increasing number of web services and the increasing complexity of linking them together, a new crop of start-ups has emerged including such companies as eSigma,  Bindingpoint, Xmethods, and Strike Iron.  Initially these start-ups appear to have the rather mundane goal of creating directories of publicly available web services or even libraries of proprietary web services (such as Strike Iron and Xignite have done), but dig a bit deeper and you realize that their ambitions may extend much further.

Take eSigma for example.  I had the opportunity to chat with its founder, Troy Haaland, the other day.  As Troy explained, the simple portal-like interface of eSigma actually hides an increasingly complex infrastructure.  Right now, at the core of this infrastructure is a fully functioning UDDI directory.  All of the services you can browse via the portal are actually formally registered in the UDDI directory making them programmatically discoverable.   The goal is to link this directory core to a higher level process management capability via a BPEL-based visual authoring/scripting platform.  Not only would such a platform allow enterprising developers to easily create and, theoretically re-sell, their own super services, but more importantly it would allow enterprises to create composite applications that exist solely in the “cloud”.  Such “cloud based” composite applications could then be used a back-bone of inter-enterprise applications.

In this way, what appear at first to be simple directories may ultimately be transformed into Process Portals, or sites that not only centralize web services meta-data, but host a set of custom-designed super-services and composite applications as well as the visual authoring tools needed to create them.

The Road Ahead
While this is clearly a long term vision, there are indications that elements of this vision may be closer at hand than one might imagine.  Within the enterprise, there are already a number of products, from companies such as Amberpoint, Blue Titan, and Digital Evolution vying to manage the low-level provisioning and performance of intra-enterprise web services.  As the number of web services multiplies within an enterprise, a directory infrastructure is a logical next step (indeed some products have already taken this step) and some kind of orchestration layer will also clearly be necessary if enterprises want to foster re-usability and enable the creation of super services.   In some ways then, the writing is on the wall: Process Portals are an inevitable result of the increasing number of web services.  The key questions outstanding then are: 1. Will these portals first make their presence felt inside the enterprise as packaged applications or outside the firewall as publicly accessible Process Portals?  2.  Will de novo start-ups be best positioned to own this space or will the pre-existing web services management products “grow” into this space? and 3. Just when exactly will this space generate enough revenue to make it interesting from an investment standpoint?