Portal Architecture

It should be apparent that portals are really Web-enabled applications. Given that reality, it might be a good idea to discuss the architecture and components of portals. The following components comprise portal architecture (see Figure 5.5):

• Web clients

• Web servers

• Database servers

• Back-end applications

• Application servers

Figure 5.5. Portal architecture and components.

Web Clients

The Web client is a PC or any device that runs a Web browser and is capable of displaying HTML and graphics. The Web browser makes requests to the Web server and processes the files the Web server returns. Rather than exchanging messages, the Web client exchanges entire files. Unfortunately, the process is inefficient and resource intensive. Still, with the Web as our preferred common application platform, these drawbacks are also inevitable.

Today, Web browsers need not run on PCs. They can also run on wireless devices such as personal digital assistants (PDAs) and cellular phones.

Web Servers

Web servers, at their core, are file servers. Like traditional file servers, they respond to requests from Web clients, then send the requested file. Web servers are required with portals because the information coming from the application server must be converted into HTML and pumped down to the Web browser using HTTP. HTML, graphics, and multimedia files (audio, video, and animation) have been traditionally stored on Web servers.

Today's Web servers pull double duty. Not only do they serve up file content to hordes of Web clients, but they perform rudimentary application processing, as well. With enabling technologies such as Common Gateway Interface (CGI), Netscape Application Programming Interface (NSAPI), and Internet Server Application Programming Interface (ISAPI), Web servers can query the Web client for information, and then, using Web server APIs, they can pass that information to an external process that runs on the Web server (see Figure 5.6). In many cases, this means users can access information on a database server or on application servers.

Figure 5.6. Using the Web server API to customize information sent to the client level.

Database Servers

Database servers, when leveraged with portals, work just as they do in more traditional client/server architectures they respond to requests and return information. Sometimes the requests come from Web servers that communicate with the database server through a process existing on the Web server. Sometimes they come directly from Web client communication with the database server via a Call-Level Interface (CLI), such as JDBC for Java or ODBC for ActiveX.

Back-End Applications

Back-end applications are enterprise applications existing either within a single enterprise or across many enterprises. These are typically a mix of ERP systems, such as SAP R/3 or PeopleSoft, custom applications existing on mainframes, and newer client/server systems. Portals gather the appropriate information from these back-end systems and externalize this information through the user interface.

Although the mechanism employed to gather back-end information varies from technology to technology, typically, portal development environments provide connectors or adapters to link to various back-end systems, or they provide APIs to allow developers to bind the back-end systems to the portal technology.

Application Servers

Application servers work with portal applications by providing a middle layer between the back-end applications, databases, and the Web server. Application servers communicate with both the Web server and the resource server using transaction-oriented application development. As with three-tier client/servers, application servers bring load-balancing recovery services and fail-over capabilities to the portal. (Application servers are covered in detail in the context of transactional middleware in Chapter 8.)

What Are Digital Exchanges?

Digital exchanges support the notion of a portal and are loosely defined by a few new vendors. Most digital exchanges are just portal sites set up by a particular industry to support trade within that industry (see Figure 5.7). Anyone can access information through the portal and execute trades, such as the transfer of inventory from one company to another.

Figure 5.7. Digital exchanges provide portals for particular vertical industries.

Let us say, for example, that a digital exchange is established to create an enterprise for the automotive parts industry. The digital exchange would be able to publish catalogs from various parts suppliers and allow parts-consuming organizations to order parts online. Digital exchanges would also be able to provide information on availability, current price (perhaps bidding between vendors), and logistics, such as when the part will ship and what time it will arrive. This scenario generally accounts for million-dollar trades in support of larger industries. However, smaller digital exchanges are cropping up, such as those that sell day-old bread to retailers. These exchanges, as you might imagine, deal with transactions of less than a thousand dollars.

There are two types of digital exchanges: active and passive. Passive digital exchanges publish catalogs for a particular industry, such as our automotive industry example. They do so with information extracted from a static database and do not support direct interaction with a supplier's information system. At some point, the information is transferred from the operational systems to the digital exchanges and updated as needed. The disadvantage of this method should be obvious. Information published by the digital exchange is not current. Inventory that shows availability could, in fact, be out of stock an eventuality that might not be discovered until the supplier organization processes the order.

For this reason, active digital exchanges provide a better solution. Active digital exchanges publish information extracted in real time from the supplier's information systems. The advantage of this approach is up-to-the-minute information presented to the digital exchange user, including up-to-the-second inventory levels. The drawback of this scenario is the investment of time and money required to get an active digital exchange up and running, and integrated with all of the supplier's systems.