Portals and Web services

By Chris Harris-Jones

Web services hold out the possibility of easy and seamless integration of applications and content into portal software. Is that really possible or just a dream of the software vendors.

Much of the confusion that exists about Web services comes from the fact that there is both a technology and business perspective. From a business perspective, Web services is about software as a service, in which software becomes a utility bought, sold and delivered in a similar manner to electricity or telecommunications. Web technology has been developed in a number of ways over the past decade to provide the platform for delivering software as a service. It is that element of Web services that gives rise to the business perspective definition 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. The technology perspective definition comes primarily from the component technology element of Web services as: "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."

Many of the applications described as Web services today adhere to the business definition of a Web service, but do not yet make use of Web service technology or only make use of selected elements of Web service technology. In this article, we focus on the technology definition of Web services and look at the impact it is having on portal software.

Web services in portals

Many 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. That is misleading, because 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.

Traditional connectivity

One of the crucial distinguishing features of portal software over recent years has been its ability to connect to a wide range of data sources and applications. To do that, vendors have written pieces of code, or portlets, that contain customized code to provide the connectivity. Those portlets have also provided the window that is displayed within the portal, which furnishes 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, sometimes multiple connectors. Some vendors will proudly announce that they have many hundreds, some even claim to have thousands. Clearly, maintaining them as applications and content sources evolve becomes a nightmarish proposition for the portal vendors.

Major application vendors also realized it would be to their advantage to develop portlets for leading portals. That guarantees the accessibility of their software through the portal and also removes 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.

The theory

Portals are effectively complex pieces of "string and glue" that deliver functionality and information that comes almost exclusively from outside the portal itself. The portal pulls them together and adds a further layer of functionality to provide coherent delivery and, hopefully, integration across the content sources. That is currently done primarily by handcrafting the large numbers of connections required.

What differentiates Web service technology is the fact 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. Previous mechanisms providing connections between systems were all specialized for particular types of integration. 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 that glue.

Web services in practice

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, that almost invariably requires some coding effort from the portal user, usually in the form of creating a user interface and defining the required Simple Object Access Protocol (SOAP) calls. 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 the Universal Description Discovery Integration (UDDI) standard; read the description of the services--encoded in the Web Services Description Language (WSDL) definition, and then automatically generate a user interface. The Epicentric (epicentric.com) portal can do that, and it will create a default user interface from the WSDL definition. It completely automates the process. One significant effect of using Web services in this way is that it demolishes the differentiator of providing "more connectors than anyone else" that some portal vendors claim to have. If content and applications can be brought into a portal using Web services automatically, then there is no need for anyone to create customized connectors. It certainly holds true for packaged applications and standard content (such as databases), where most vendors can be expected to provide access through Web services over the coming months. Clearly, there will still be a need for hand-coded connectors where no Web services are available.

Web services to build functionality

The use of Web services to connect to content and functionality is only the first step. The next stage is to provide functionality within portals that can string together multiple Web services to assemble complete business processes.

Workflow is an essential (though poorly implemented) element of portals that should provide functions for content to be moved automatically between portlets. It can also be used to construct flows between individual processes that can appear inside a single portlet.

Moving one step further, it should be possible to define entire business processes by creating the underlying workflows, and executing the individual functions required for each process. Web services offer an ideal basis for that type of functionality. The workflow manages the response codes from the Web services and controls the flow accordingly. That provides the ability to create end-to-end business processes that can be automated where the necessary components exist, and the ability to demand user intervention at the other stages. The alerting functions of portals can be exploited to ensure appropriate intervention to guarantee that processes run to completion.

Implementing complete business processes in that way may seem like nirvana, but much of the technology already exists, and it is only a matter of time before it is fully implemented. Vendors are already working hard in this area. The biggest issue is likely to be incompatibility between the new business processes and the existing process components. While the computerized processes may exist, and may have been converted into Web services, they will have been designed for execution under specific circumstances. When that context is removed by extracting functionality into discrete Web services, the process may no longer execute appropriately. It is the old problem encountered years ago with object orientation, processes need to be designed explicitly for reuse. Processes designed as part of a larger application will often not be easy to reuse.

The future

Web services undoubtedly have a strong future within portal software. They will become the default method for accessing content and applications within portals, removing the need for hundreds of specific connections, each of which connects to a single data source or application. That is likely to become widespread within the next six to 18 months. Web services also have a key role to play in the ability of portals to connect multiple functions together into a complex business process. The sticking point will be whether the appropriate discrete functions exist in a reusable form to enable completion of an end-to-end process. We will have to wait longer for that to become a routine process.

Further detailed information on this subject can be found in the Ovum reports “Web Services for the Enterprise” and “Ovum Evaluates: Portal Software.”

Chris Harris-Jones is a senior consultant at Ovum (ovum.com), e-mail chj@ovum.com.