Portals and Web Services: Services at the User Interface

Lately, there has been so much talk about Web Services, Service-Oriented Architectures, and machine-to-machine communications of all sorts that it’s easy to forget that computers are meant to serve the needs of humans. After all, interacting with humans requires different approaches from interacting with automated systems. In particular, humans require a user interface that provides both an intuitive visual display of information as well as a logical way in which to interact with a particular system. Fortunately, there exist a wide range of solutions to our user interface challenges: rich clients with graphical user interfaces (GUIs), portals with Web-browser based interfaces, text-based interfaces, and solutions in between. However, this plethora of user interfaces has presented yet another problem: user interface integration.

Until the rise of the World Wide Web, the user interface for a particular application was necessarily tightly coupled to the application logic beneath the interface. And for a very good reason – most GUIs consist of application logic combined with the interface code for presenting that logic. However, the Web popularized the idea that we can separate presentation and application logic by providing a generic UI client (the browser) loosely coupled from a general UI server (the Web server). Companies soon realized the power, ease of use, and low TCO that Web-based interfaces offered. Nevertheless, both Web interfaces and the fat interfaces that preceded them provided separate interfaces to separate application functionality, as shown in Figure 1.

Figure 1: Separate Interfaces to Separate Applications

As companies sought to leverage Web-based interfaces for access to enterprise data and applications, the portal began to emerge as the accepted corporate interface to data and software functionality dispersed throughout the organization. When portals first emerged, they were a way of consolidating separate corporate Web sites and Web interfaces to corporate applications into an aggregated view that users could personalize, along the lines of “My Yahoo.” Rather than working with separate interfaces to multiple different applications, the portal ties together the various UIs.

Such portals provided a personalized, role-based view of many of the information systems and resources used within an organization. The main reason why enterprises implemented these portals was to lower content and application delivery costs and extend the reach of back-end applications. In addition, portals provided role-based administration, access to semi-structured and unstructured content, and knowledge management and collaboration capabilities. However, while providing an integrated view of information from multiple systems, these early portals didn’t integrate applications at the user interface level. Instead, these portals provided separate views into separate applications, as shown in figure 2:

Figure 2: Portal with Siloed Interfaces to Siloed Applications

Portals and Processes

A portal’s greatest benefit comes not from creating a single view of multiple resources, but from linking these resources directly to business processes, even when those processes involve multiple resources. Having multiple portlet views into application silos is not particularly helpful. What companies need is a cohesive integration of the various pieces of information presented to the user, and a logical flow that connects applications and human workflow tasks. Simply put, a portal must provide a user interface to a process, not to a single application.

The second generation of portals are based on business processes. These portals wrap individual UIs to siloed applications with portlets that interact with each other as though each portal were a reusable component, as shown in Figure 3. In this approach, the portal enables business processes by allowing portlets to communicate with each other within the portal framework. While enterprises can enable many business processes and workflow applications using this cross-portlet communication, the integration approach is still tightly coupled with the target application. As a result, such portals tend to be inflexible when changes to the underlying applications occur, leading to increased costs and risk for the enterprise.

Figure 3: Integration of Siloed Applications at the UI Level

Service-Oriented Portals

In order to mitigate the costs and risks of integrating siloed applications in the portal, portals must supply interfaces to loosely coupled, coarse-grained Services that in turn provide access to business logic without requiring integration within the user interface. Rather than simply providing access to information, this third generation of portals are beginning to provide interfaces to the processes people need to do their jobs. Indeed, companies don’t implement portals because they aggregate user interfaces – they implement them because they provide a window on the business processes that are important to an organization. Rather than simply connecting directly to the back-end systems and providing visual islands of information, portals should provide a process-driven approach to assembling logical flows of information from disparate data and information sources and provide a role-based, personalized presentation layer on top of those flows.

This new generation of portals provides UIs to composite application functionality in the form of Service-Oriented Processes (SOPs). In an SOP, a process consists of an orchestrated flow of Services, and the process itself is exposed as a Service. In this manner, the actual details of the process are abstracted from the portal that consumes these Services, as shown in Figure 4. Another benefit of a Service-oriented process is that it doesn’t specify any particular user interface – the process may be consumed automatically as part of a behind-the-scenes integration activity, or it may be exposed to the user via a portal as part of an interactive, workflow activity.

Figure 4: A Portal to a Service-Oriented Process

Human actions typically initiate most business processes, especially coarse-grained, business-oriented ones. Service interfaces must therefore wrap human-oriented workflow tasks. The portal then provides the primary mechanism for involving people in process flows. However, in order to accomplish this goal, the architecture of a portal must migrate from simply providing user interface-level integration to providing an interface to an SOP that provides process definition and execution. The SOP tool is then responsible for communicating with the various Services on the network in order to accomplish some integrated task.

ZapThink Take

In the future, companies won’t be purchasing monolithic enterprise applications that each contain their own, separate user interface. Rather, enterprises will buy application functionality exposed as Services that they can deploy in an SOA that uses the portal as its primary user interface. Such Services must be stitched together into SOPs that users interact with via enterprise portals. Services will become the norm by which enterprises interact with enterprise applications. Companies should not only demand standard interfaces via Web Services-based APIs, but also demand SOA solutions that expose Service-oriented business processes that enterprise portals can consume.