The Evolution of the e-Business Portal (Part II)

by Colin White

May 2002

Portal directory entries are typically organized by subject area, where each subject is related to a specific business topic or concept. The business taxonomy that defines this subject area structure is developed during the portal design process, and is one of the most important elements of portal development and ongoing maintenance.

The business rules for this taxonomy are used by the categorization manager in determining the most appropriate subject area with which to associate metadata about business content. The taxonomy rules are evaluated by the categorization manager using information extracted from the business content itself, or from the metadata about the business content (application name, file name, Web page URL, author, etc.). Services (publishing services, for example) and tools that use the portal directory interface can employ the categorization manager to assist in assigning portal directory entries to a suitable subject area.

Products vary significantly in their portal directory and categorization manager capabilities, and in the types of metadata they maintain in the portal directory. Some products simply document the name and location of the content, while others support more detailed information about its business meaning and usage. Similarly, some products provide robust automated categorization managers, while others require all categorization to be done manually. Portal directory and categorization manager functionality are key distinguishing factors between products.

The portal adapters component supplies a set of services for collecting information about business content and for accessing that content. As already discussed, the information about business content that can be accessed via a portal is kept as metadata in the portal directory. Portal adapters can take several forms – examples include programmable interfaces, file import and export mechanisms, and automated tools (sometimes called crawlers) that scan business content at regular intervals. A portal may provide adapters for databases and files, business intelligence products, content and document management systems, groupware and office objects (e-mail, word processing documents, spreadsheets and Web pages for example), or applications (front-office, back-office, and e-business).

Portal adapters vary in sophistication. Some may consist of a rudimentary generic database or file interface, while others are tightly integrated into the source content, like an e-business commerce application, for example. When selecting products, it is not the number of adapters that are provided by a portal that matters, but the capabilities provided for each adapter. More sophisticated adapters are being added to portal products by vendors. Examples include adapters for interoperability with enterprise application integration (EAI) software, for text mining, and for cataloging expertise and tracking relationships between different job skills based on usage data.

Portal developers can add content adapters to a portal using the portal development kit. A PDK should provide facilities that enable Java or Microsoft ActiveX wrappers to be written that access business content, and present this content and its associated metadata to the portal in the form of an XML-based data stream. The PDK should also be able to support content adapters that can interact with other portal services so that sophisticated vertical portals can be built that handle interrelationships between various types of business content and business processing. A portal adapter may, for example, need to interact with workflow services so that a vertical portal application can be developed for managing the flow of business content between different portal users. These types of vertical portal applications will be developed by ISVs, and tailored by individual customers to match business needs. Packaged vertical portal applications built using an open portal development platform significantly reduce the amount of effort required by an organization to implement and integrate a portal.

Most portals interact with the business user via a Web-based interface. The underlying Web services that provide this interface may be contained in the portal infrastructure itself, but products usually employ a separate Web server to handle this processing. The Web server facilities used by portal products vary from simple HTTP listener services to reliance on the Web server for administration and development tools, security, and interfaces to back-end business content stores. Although it is important for portal products to provide portability between leading Web servers, it is also crucial, as user volumes build, that products exploit features such as directory services, caching, load balancing and fail-over in Web application servers.

Portal Evolution

We can see from the above discussion that portal products are rapidly evolving, and some clear industry trends can be seen in the portal marketplace.

1. Support for enterprise transaction applications (legacy systems, front- and back-office application packages, e-business applications) using custom portal content adapters or third-party EAI software.
2. Support for a wider range of business information (business intelligence tools, content management systems, database data, office documents, Web information, syndicated data) and expertise using custom portal content adapters.
3. The creation of portal developments kits (PDKs) that enable IT developers, ISVs, and system integrators to add and customize portal adapters for accessing business content. Product examples include Ascential Axielle type manager, Epicentric portal modules, IBM WebSphere Portal portlets, Microsoft Web parts, Oracle portlets, Plumtree gadgets, TopTier iViews and Viador portlets. One issue here is that most of the PDKs support documented, but proprietary interfaces, which means that adapters cannot be interchanged between products. The Java Apache Project has published an open XML-based portal adapter interface (known as Jetspeed), but few vendors other than IBM support this. Some vendors are working on supporting other vendor’s adapters. Plumtree, for example, is working with Microsoft on making Microsoft Web parts work in the Plumtree portal environment. TopTier (recently acquired by SAP) has a relationship with Microsoft to enable TopTier iViews to run as Microsoft Web parts.
4. Support for a broad range of Web devices including mobile and wireless devices using facilities such as XML and XSL. Examples products that focus on mobile and wireless support include Corechange Coreport 3g, IBM WebSphere Everyplace Suite and Oracle Oracle9iAS Wireless Edition.
5. The integration of portal technologies into Web application and commerce servers. Examples here include the BroadVision InfoExchange Portal, IBM WebSphere Portal, Oracle Oracle9iAS Server, and Sun iPlanet Portal Server.
6. The integration of portal technologies into groupware and office solutions. Key examples here are the Lotus Knowledge Discovery System, Microsoft SharePoint Portal Server, and Correlate K-Maps for both Lotus and Microsoft.
7. Enhanced portal product functionality in the areas of security, search services, rules processing, metadata support, workflow and collaboration. Examples of products here include Ascential Axielle (metadata management), Microsoft (search and collaboration services), Verity Portal One (search services), and Viador E-Portal (security).
8. The integration of portal technology into vertical application packages. Examples of key vendors here include Oracle, PeopleSoft, and SAP.
9. Industry consolidation by product acquisitions and mergers. Examples of recent acquisitions include TopTier (by SAP to form SAP Portals, Inc.) and Sequoia Software (by Citrix Software).

No single portal product currently meets all the requirements of a portal solution, and it is important when evaluating portal products to match product features to application requirements, and to select products that provide support for an open portal framework.