Portal Development Tools

INTRODUCTION

A number of customer and company needs can be identified, to which Web portal services appear to provide the best answer. These needs include information sharing and accessibility, content management and abstraction with the use of interfaces to multiple data formats, such as physical data, documents, files and databases. The main purpose of a Web portal is to enable users to access and modify information.

This short survey will provide an overview on how portal technology has evolved and how it has acquired a share of the market. The survey will examine the interoperability and integration of portal application products with other technologies and systems; it will then attempt to predict the future of Web portals development; in a next stage it will try to deal with the questions that vendors encounter in the portal implementation process and it will take note of some of the customer requirements. An essential question in dealing with the above concerns whether the next generation Web portal products will be designed as autonomous software independent systems, or as parts of other bundled systems.

The survey will also refer to the dominant players in the field of Web portal development tools. It will address the similarities and differences of the approaches of the various corporations. Each ofthese products will be briefly described and both its distinctive features and the requirements that it fulfils will be presented. The survey will conclude with a reference to the most significant trends in Web portal technology and to the needs that this technology will satisfy in the near future.

BACKGROUND

Reading section 2.1 of the Portlet Specification (Sun, 2003), a portal is defined as: a Web based application that—commonly—provides personalization, single sign on, content aggregation from different sources and hosts the presentation layer of Information Systems. Aggregation is the action of integrating content from different sources within a Web page. A portal may have sophisticated personalization features to provide customized content to users. Portal pages may have different set of portlets creating content for different users.

Table 1. Leading Web portal vendors and corresponding products

A number of products to address the issues described in the above definition are available. The vendors selected for evaluation are listed in Table 1. The corresponding products possess the lion’s share in the portal market (Phifer, Valdes, Gootzit, Underwood & Wurste, 2005).

Along with the commercial portal products, a multitude of open source portal frameworks compliant with JSR and WSRP have been developed. The latest JetSpeed 2.0 (Apache, 2006) from Apache is an implementation of an Enterprise Information Portal written in Java and XML. GridSphere portal framework (GridSphere, 2006) is an open source framework fully compatible with IBM’s WebSphere.

TECHNOLOGICAL EVOLUTION OF WEB PORTALS

When the first Web portal products came out, they had entirely proprietary APIs, and a different set of features. Some had personalization features, while others excelled at enabling workflow or content management (Richardson, Avondolio, Vitale, Len, & Smith, 2004). Along the way, Java 2 Platform

Enterprise Edition (J2EE) began its meteoric rise, providing strong enterprise application development and integration features. It also had a substantial impact on Web development activities with the servlet and JSP specifications.

Quickly, though, the portal capabilities caused technical discriminations, and provided nonstandard extensions to J2EE. These extensions ranged from very close approximations of the standard components, to full-blown rewrites of presentation logic code (Richardson et al., 2004). The problem was that the portal implementations were starting to fracture the J2EE application base, which had a negative effect on the portability of enterprise applications.

To deal with this problem, two standards have been adopted by many of the prominent portal vendors. Rather than compete with one another, these standards compliment one another. In 2003, Sun in cooperation with dominant portal vendors, proposed the JSR 168 specification (Sun, 2003). JSR 168 defines a Java Portlet API for Web application components (portlets) that interact with and can be aggregated in applications such as portals.

Additionally, Web services for remote portals (WSRP) ratified an OASIS standard that views the portal and Web service interaction from a completely different angle, defines visual, user-facing Web services that plug and play with portals or other applications (OASIS, 2003).

Of course, the diverse group of portal vendors presently in the market will offer differing sets of components to leverage within their portal, even addressing points where the portlet specification in its current state falls short, such as interportlet communication, portlet filters, extending the CSS support, and integration of existing Web application frameworks to be leveraged in portlet development, such as JSF/My Faces, Struts, and Spring MVC (Viet & Russo, 2005).

BASIC WEB PORTAL DESIGN CONCEPTS

This section describes the design aspects that define the technological side of a portal platform. The first four criteria stated are presented by Homan and Klima (2001). It is important to emphasize that the majority of portal solutions today comes as a part of an application server platform providing these functionalities by the application server and not by the portal product. However in case of stand-alone portal solutions, these services must be implemented directly by them.

• Fault Tolerance and Clustering: Each portal server instance should also be able to pick up the load when other instances crash either from a hardware or software failure. Load balancing is usually provided between multiple instances of the portal server using algorithms that take a round-robin-based approach (Tanenbaum, 2001).

• Caching: Local data storage so that acceptable response times are preserved since response times from the distributed systems may otherwise be very long as a result of the load of aggregated data some of which may originate from geographically distributed sources.

• Repository Structure: Web portal servers use repositories to store security information and metadata among others. Choices for storage range from flat files or serialized objects to relational databases or lightweight directory access protocol (LDAP) directory servers.

• Platform Support: Because Web portals are designed to work in a cross-platform environment, support for multiple operating systems application platforms (such as those from BEA, Oracle or IBM) is highly desirable.

• Standards Support: Standards-based portals are a must. If the product complies with portal standards, such as WSRP and JSR-168, and Web services standards (SOAP, WSDL), users are assured that third-party products will work with it and the applications they develop will work with the existing infrastructure (MacVittie, 2004).

• Security Services: Portal security encompasses a range of technologies that address the issues of authentication, integrity and confidentiality so as to support mechanisms to ensure these features (Richardson et al., 2004).

DOMINANT VENDORS IN THE FIELD AND THEIR APPROACHES

The top Web portal solutions will run on common J2EE application servers (such as IBM WebSphere or BEAWebLogic) or .NET, or both. According to Heck (2004), a difference between two otherwise closely matched products is: whether a portal runs best on a vendor’s own platform and how well it truly integrates with existing enterprise systems.

IBM WebSphere Portal

WebSphere Portal (IBM Corporation, 2006) is typically built on top of the J2EE-compliant WebSphere application server. The portal server provides development and runtime infrastructure for the portal. WebSphere Portal itself installs as an Enterprise application in WebSphere Application Server. The portal infrastructure allows load balancing, fault tolerance, caching and external security management (IBM Corporation, 2006).

WebSphere Portal Server has the option to use operating system (OS) level security, LDAP server for user authentication and single sign-on. The WebSphere Portal has a strong standard support which includes JSR-168, JSR-170, WSRP and the Apache Struts MVC framework (IBM Corporation, 2006).

Microsoft SharePoint Portal Server

SharePoint Portal Server (Microsoft Corporation, 2006) requires Windows Server Operating System; works best with SQL Server, Active Directory and Internet Information Server (IIS); and is highly integrated with Microsoft Office. It supports a distributed architecture and optimal portal performance by offering deployments through the ability to support server farms (centralized grouping of network servers). A server farm provides a network with load balancing, scalability, and fault tolerance (Laahs McKenna & Vanamo, 2005).

SharePoint Portal security depends on the underlying Windows Operating System and the variety of components that cooperate with SharePoint, such as ASP .NET, IIS and SQL Server (Townsend, Riz & Schaffer, 2004).

Probably the biggest weakness in SharePoint Portal Server is the way it locks companies into using only (new) Microsoft products to support and interact with the portal. Additionally, it lacks support for existing portlet specifications contributing to lower interoperability standards.

Oracle Application Server Portal

Oracle Portal (Oracle Corporation, 2006) is closely tied to Oracle Application Server. The portal solution inherits the robust features of the Oracle Application Server such as its extensive caching capabilities, support for fault tolerance, a J2EE core, improved Web services support and tighter coupling with the suite’s integration capabilities.

Furthermore, Oracle Single Sign-On and Java’s Authentication and Authorization Service (JAAS) are key security components. They make it possible for a user to sign on to the Application Server once and access not only the available internal applications, but also external applications using an HTTP security interface.

SAP NetWeaver Portal

SAP positions its enterprise portal (SAP Corporation, 2006) product as a building block of the NetWeaver stack, rather than as an individual portal component. SAP NetWeaver is J2EE-compliant and is designed to be completely open and to interoperate with other platforms including Microsoft .NET and IBM WebSphere (SAP Corporation, 2006).

The portal supports both UNIX and Microsoft Windows servers and is compliant with the JSR-168 and WSRP portlet standards, WSDL (Web Services Description Language), SOAP and UDDI as well as industry specific process standards (PIDX, RosettaNet).

SAP delivers encryption and integrity mechanisms using SSL and provides authentication using Single Sign-On (SSO) or X.509 certificates.

Sun Java System Portal Server

Sun has adeptly applied its Java leadership and hardware technology to the Web portal area, yielding a secure, extensible and high-performance solution. Additionally, Java System Portal Server (Sun Corporation, 2006) runs on non-Sun application servers, allows substitution of other third-party components and fully complies with the JSR 168 and WSRP specifications.

Security, a traditional Sun strength, is evident in its portal solution; there exist several types of authentication, including LDAP directories, secure single sign-on throughout multiple portals – not just those that are Sun based (Heck, 2004).

BEA webLogic Platform

WebLogic Portal (BEA Systems Corporation, 2006) is an Enterprise Application implemented using the J2EE architecture, and is in fact a J2EE application that runs in the WebLogic Server environment. It consists of a collection of Enterprise Java Bean (EJB) components and a set of Web applications (servlets, JSPs). Both the portal functionality itself and the portal management tools are part of the J2EE Enterprise Application.

Because WebLogic Portal is a WebLogic Server application, it leverages the infrastructure provided, such as security, JDBC connection pooling, caching, clustering for failover and load balancing, Web services support, system-level administration and management. For example, the WebLogic Portal Enterprise Application can be deployed over a set of clustered servers. This is in stark contrast to other Java-based portal implementations, which are typically confined to the servlet engine and the Web container and take little advantage of a J2EE application server.

comparison

A comparison is carried out of a selection of portal vendors including Oracle AS Portal, Sun Java System Portal Server, Vignette Portal and open source alternatives (JetSpeed, GridSphere, JBoss, uPortal). The focus is directed on technological design aspects rather than portal functionality such as personalization or usability.

Table 2. Web portal vendors and product features

Table 2 has been adopted from Heck (2004) and it has been modified to satisfy the needs of this survey. It summarizes the technical features of each reviewed product. There are two basic Web portal formats. One favors a tightly integrated application platform suite approach. Here, the application server, the integration framework and the Web portal are combined into one platform. BEA, Oracle, Sun, Microsoft, and IBM follow this model (Heck, 2004). This characteristic, although a similarity, is illustrated in Table 2.

The second format is the path Plumtree and Vignette follow offering conventional enterprise portals, that is, standalone products, with the ground to sacrifice some ability to manage applications throughout their life for the freedom to choose the best application server and other components to meet specific needs.

A close study of these products demonstrates that perfect portal solutions do not exist. In fact, some of the most successful portal projects combine technology from several vendors for true customization.

FUTURE TRENDS

All of the solutions examined come as parts of an Application Server. These products inherit much of features of the respective Application Servers, such as load balancing or clustering which banishes the burden to explicitly include these features in the portal products themselves. This fact is in accordance with the market shares (Phifer et al., 2005) and contributes to the extinguishment of the independent portal servers and their integration to an application server. Root (2005) has also concluded: “the trend is that Web portals will be bundled in the application server platforms. BEA, Oracle, Sun, Microsoft, and IBM have combined functionality traditionally provided by application servers, portal servers, integration servers, and development tools into application platform bundles.”

E-commerce is experiencing a tremendous growth rate (Johnson & Tesch, 2005). Along with the revenue increase from the online sales, the cost of security violations is also increasing (Waters, 2005). If a portal plans to accept payment for goods or services via credit cards or electronic checks, then the issues of minimizing credit-card fraud or “bad” checks become familiar to the developers.

Enhanced product functionality in the area of security constitutes an emerging challenge for a Web portal solution, a challenge that will continue to grow similarly with the e-commerce revenues. The next generation of the development tools will support flexible security options for authentication or integrity and common security enhancements to assist the portal developers in the creation of robust and secure Web applications.

CONCLUSION

Portals have many advantages, which is why they have become the de facto standard for Web application delivery. In fact, analysts have predicted that portals will become the next generation for the desktop environment (Apache, 2006). Portals are high on the information technology priority lists. They offer broad, measurable business benefits for many types of organizations. Now that the technology and products for portals have reached a certain maturity, they have entered the mainstream.

With the proliferation of portals and portal products, there can be no doubt that portals are a significant phenomenon. They are here to stay and evolve into more sophisticated forms. Indeed, the underlying standards and technologies that make up today’s portals are likely to be taken for granted in the future and be incorporated into nearly all Web sites.

KEY TERMS

Application Server: A scalable, secure middle-tier software platform that provides the infrastructure required to develop, deploy and run middle-tier applications. This software is dedicated to running certain software applications.

Business-to-Consumer (B2C) Portal: These portals sell products and services to anyone visiting the site. They (must) support secure electronic transactions and provide a high level of customer support. The revenue model for a consumer portal is selling goods and services, with a secondary revenue stream from advertising and affiliations. Examples of such portals include eBay and Amazon.com.

Business-to-Employee (B2E) Portal: A portal that aims to provide everything that an employee might hope to find on an intranet, for example, a corporate directory, or customer support information, thus increasing efficiency and saving time.

Enterprise Portal: A portal that provides access to an appropriate range of information and software applications about a particular company. It enables companies to unlock internally and externally stored information, and provide users (employees, executives, customers and suppliers) a gateway to personalized information needed to make informed business decisions. (The term Corporate Portal is also found in relation to this definition.)

Integration: The process of achieving unity of effort among the various subsystems in the accomplishment of the organization’s task. Developers can be more productive in a single integrated development environment (IDE) than in multiple environments and languages, one for every product or service.

Interoperability: The ability of a system or a product to work with other systems or products transparently and effectively in such a way so as to maximize opportunities for exchange and re-use of information, whether internally or externally. Interoperability can be achieved by adhering the respective specifications and guidelines.

Scalability: The ability to increase workloads or the number of users, ports or capabilities when resources (hardware or software) are added with minimal impact on the unit cost of business and the procurement of additional services.

Service-Oriented Architecture (SOA): A service-oriented architecture is an information technology approach or strategy in which applications make use of (perhaps more accurately, rely on) services available in a network. Implementing a service-oriented architecture can involve developing applications that use services, making applications available as services so that other applications can use those services, or both. What distinguishes an SOA from other architectures is loose coupling. Loose coupling means that the client of a service is essentially independent of the service.