The Ovum View: Portals and web services: a match made in heaven?

Introducing the portlet...

Web services hold out the possibility of easy and seamless integration of applications and content into portal software. Chris Harris-Jones, Principal Analyst at Ovum, asks is this really possible, or just a software vendors' dream? Much of the confusion that exists about web services comes from the fact that it can be defined from both a technology and a business perspective. From a business perspective, web services is about 'software as a service', whereby software becomes a utility, bought, sold and delivered in a similar manner to electricity or telecommunications. Ovum defines this element of web services as "a term used to describe software applications and functions that can be delivered over the web". From a technology perspective, web services is about a particular set of specifications that are used for packaging software into easily accessible components for use by other computers. Ovum's technology perspective definition is "a set of specifications for packaging technology that allows functions of a software system to be published (WSDL), discovered (UDDI) and executed (SOAP) by other programs over the Internet, an intranet or extranet, regardless of their location or implementation". Today, many of the applications described as web services adhere to the business definition of a web service but do not yet make full use of web service technology. Many of the portal vendors use both the business and technology definitions in their literature, often interchangeably, which can be highly confusing. The individual components that are delivered by portals, which are increasingly referred to as 'portlets', are sometimes also called web services. This is dangerously misleading, since the use of web services (the technology definition) has a significant effect on the way that portals do their job and the potential they have for the future. The same is definitely not true for the business definition. One of the crucial distinguishing features of portal software has been its ability to connect to a wide range of data sources and applications. To do this, vendors have written pieces of code which contain customised code to provide the connectivity. These 'portlets' have also provided the window that is displayed within the portal. This provides a simple stovepipe connection between the portal and the content or application. The main problem with this approach is that every content source and application requires a different connector, often multiple connectors. Some vendors will proudly announce that they have hundreds, some even claim to have thousands. Maintaining these as applications and content sources evolve becomes a nightmarish proposition for the portal vendors.
Major application vendors also realised it would be to their advantage to develop portlets for leading portals. This guarantees the accessibility of their software through the portal and also removed some of the pressure from the portal vendors. However, the best solution would be to have some form of common interface that could be used to connect data and applications directly into portals. Enter web services. Portals are effectively complex pieces of 'string and glue' that deliver functionality and information. The portal pulls these together and adds a further layer of functionality to provide coherent delivery and, hopefully, integration across the content sources. This is currently done largely by using pre-built or handcrafted connections. What differentiates web service technology is that it is a simple and universally-agreed packaging technology, accessible over the Internet, and does not need technology tied to any vendor's platform. Web services technology is different because it 'makes all kinds of glue look the same'. If enterprises can use the same type of glue for all portal connectivity, then internal content and applications, external information, trading partner applications, online services and rented applications can all be brought together - web services provide the glue. Portal vendors are increasingly supplying a simple portlet that can access a web service. In theory, the user only has to take a copy of the default portlet, identify the web service to it, and generate the new portlet. In current implementations, this almost invariably requires some additional coding effort from the portal user. Many of the portal vendors have already reached this stage. A more sophisticated approach is for the web services portlet to locate the web services automatically (using UDDI), read the description of the services (encoded in WSDL) and then automatically generate a user interface. The Epicentric portal can do this, and it will create a default user interface from the WSDL definition. This completely automates the process. One significant outcome of this is that it will demolish the differentiator of providing 'more connectors than anyone else' that some portal vendors claim. If content and applications can be brought into a portal using web services automatically, then there is no need for anyone to create customised connectors. This certainly holds true for packaged applications and standard content (such as databases), where most vendors will eventually provide access through web services. There will still be a need for hand-coded connectors where there are no web services available. Web services undoubtedly have a strong future within portals becoming the default method for accessing content and applications. This removes the need for hundreds of specific connections, each of which links to a single data source or application. Ovum predicts that this approach is likely to become widespread by the end of 2003. Related Ovum research: Web Services for the Enterprise and Ovum Evaluates: Portal Software. For further information email: info@ovum.com or visit www.ovum.com