|
|
Solutions for centralized data, application, and process integration are becoming ever more popular—both on the Internet and within companies. The accompanying processes and products to these solutions use middleware, application servers, component models, communication standards, and database technologies. New standards, such as XML and SOAP, are used to an ever-increasing degree in the relevant integration environments, based on the Microsoft .NET Framework, for example. The term portal has become established as the overall name for these means of accessing information and applications. Portals are usually characterized by their ability to personalize user access and content. This necessitates auxiliary components for authentication and session administration.
The term portal is used in a wide variety of contexts. In corporate environments there are portals for content management, information management, document management, Enterprise Application Integration (EAI), Enterprise Resource Planning (ERP), and customer relationship management (CRM). What the different portal types have in common is the fact that they can be personalized, integrate processes or applications, and simplify user activities in networks. In most cases, portals access application servers with a process logic based on Web technologies. Microsoft ASP.NET and .NET Web services, in particular, provide the ideal basis for this. However, companies want to use portals in a corporate environment not only because of the enticing technical approach, but especially because of the opportunities a portal offers to cut costs. Costs can be reduced because all of the required applications and information are gathered at one central point. Users therefore spend less time finding the “right” applications or even installing them themselves, which usually gives rise to considerable subsequent costs. In the ideal situation, all needed information and all applications relating to the individual user roles will be available through the portal.
But what does all of this have to do with terminal servers? A portal becomes a valuable integration tool if the required application logic is not available as a Web application but still needs to be made available through a portal’s centralized environment. What kind of Web pages on the portal allow access to applications that run on terminal servers? For these type of Web pages, it is not enough to simply provide the links to RDP or ICA client software components for the applications to be accessed through a Web browser. Instead, further technical features must be added to meet the requirements for the use of an application access portal across a company. This scenario, focusing on the personalized aggregation of links to Windows- based applications, is referred to as Windows Forms application integration. However, it should not be compared or confused with powerful concepts from the field of EAI portals. These portal environments are generally based on pure Web applications and usually include industry-specific modules for process and workflow modeling. Such functions do not play as promiment a role for application access portals in the context of terminal servers. What is much more important for these portals is that they can make available the links to terminal server applications and to Web applications simultaneously and in a manner to suit the specific users.
Users, therefore, can no longer directly see whether they are accessing a Microsoft Windows or a Web application through a state-oriented or stateless protocol. This allows the administrators in the background to migrate applications from one basic technology to another without passing on the link to the application to the end user through complicated distribution mechanisms. All they have to do is to change the logic behind the application icon in the portal. It is not necessary to install applications locally or to modify the local desktops on the client.
At this point it should be pointed out that centrally executed Web applications or terminal server applications are nothing new from a technical perspective. Even mainframe computers were, and still are, based on the same concepts: a centralized host provides its computing capacity to several users to execute the application logic. The interaction with the user is delegated to a remote computer via a special protocol. This computer can be a terminal, a Web browser, an RDP client, or an ICA client. The most significant differences between these client types are only their use of graphical elements and the possibility of using a mouse. In principle, Web browsers, RDP clients, and ICA clients are the modern variants of the more antiquated terminals or terminal emulators.
To follow up on this rather abstract introduction to Windows Forms application access portals, we will now look at the practical requirements. This section lists the technical features of an ideal environment that would enable the optimum integration of Windows Forms applications. Generally speaking, however, no real product will fulfill all of these requirements optimally. The following list should therefore serve as more of a guide for comparison. We purposefully did not rate or prioritize the individual features because each environment has different requirements.
Mapping the portal logic in a Web application (for example, as an ASP.NET application) that can present all of the icons required for terminal server applications in a structured manner. The traditional desktop is thereby shifted to the Web browser. To improve scalability and availability, the portal is ideally implemented so that it can be executed on several Web servers in parallel. This requires mechanisms to facilitate load balancing.
A centrally configurable standard to a user interface with standard elements that comply with a company’s standards (otherwise known as the corporate design). All of these elements should also be adjustable, to a limited extent. This applies, for example, to company logos, colors, navigation elements, font types, and font sizes. If more than one company or division within a company—each with its own corporate design—is to be included in the same portal, the portal must be able to support several separate user groups or organizational units with different features.
Provision of a graphical user interface with syntactically and semantically consistent navigation mechanisms. Even though the environment should provide as much flexibility as possible, this requirement must still be considered to prevent the usability of the system from being jeopardized. Implementing this requirement requires a clearly determined set of atomic and integrated standard graphical elements that can be produced at high throughput using an abstract model. The accompanying technical solutions often follow the same pattern with respect to design and optimization as a well-known conventional graphical user interface—the Windows desktop.
Avoidance of any overly long waits when a page loads and when changing masks. The reaction times should remain within predefined limits even at times of peak load, to prevent the interaction from tiring the user. This can be achieved for a predetermined maximum number of simultaneous users by optimizing the generation, rendering, and presentation of standard graphical elements.
Administration of all user sessions to guarantee that users are identified when they access the stateless HTTP protocol for a second or subsequent time. This can be done using cookies or by adding a user-specific chain of characters in each HTML link. This task is far from trivial, so special session management components are often used; these are programmed independently of the rest of the portal logic and integrated by means of interfaces.
Support of as many browser types and clients as possible for connection to the terminal server. This allows a company’s previously independent organizational units with different IT environments to be integrated more easily. This feature is particularly important for large companies faced with repeated structural changes as a result of mergers or changes to the corporate structure.
User and group-specific presentation of the portal interface and integrated graphical elements (such as application icons). This individualization of the graphical user interface is generally enabled by linking the portal logic with a directory service such as Microsoft’s Active Directory directory service. Managing the status of each individual user session is particularly important here.
The possibility for users who have logged on to change the portal interface to their taste. If these parameters are to be saved and reloaded the next time the user logs on, the mechanisms for managing a user profile must be integrated.
A database system or configuration files for the centralized provision of portal content and as a basis for the portal logic. Further parameters for the creation of portal pages originate in the directory service and from information queries to the terminal server. In the optimum scenario, all portal pages are dynamically generated.
Client software that can display the applications in full without the underlying desktop. This makes a remote application behave in exactly the same way as a local application. The individual applications must, however, have the possibility to run in the same logical user session. This allows the applications invoked to be linked through the old but still commonly used OLE or COM mechanisms, as long as they are executed on the same terminal server.
Windows applications load-balancing mechanisms provided by terminal servers. The portal logic must incorporate the relevant output parameters of all the terminal servers concerned to select a suitable assignment when the first application request is made. Alternatively, it is, of course, possible to use other established load-balancing mechanisms. For all subsequent attempts to access the Windows applications, the portal logic or the load-balancing mechanism must, where necessary, make sure that only the initially selected terminal server can be accessed for predefined applications within a user session. A feature of the load-balancing mechanism might include saving the ID of the terminal server that the user worked with most recently.
The potential to organize terminal servers in several separate units (that is, farms) that allow it to provide different sets of applications. This functionality improves the scalability and usability in larger companies. However, the complexity of the load-balancing mechanisms relating to individual farms might increase.
The option of switching the portal interface between different languages. This applies both to text and graphical elements and to different terminal servers to which the portal refers via the application icons.
Mechanisms to control the bandwidth used between the individual servers within the portal infrastructure. This includes the possibility to limit the resources requested so as to prevent overload in extreme situations.
These requirements can be used to draw up a list of specifications for an application access portal. However, the preceding requirements do not include any security mechanisms. Only with security mechanisms can a portal be operated in an environment that is subject to external influences and even, sometimes, to attacks.
It is important to consider the subject of security in sufficient detail. We will therefore expand on the basic requirements to incorporate security considerations.
Secure logon options from a Web browser with which the individualized portal interface and the integrated application icons can be launched. The possibility of user identification can range from anonymous logon to user names and passwords, or even to smartcards and certificates. Here, too, the connection to a directory service plays a central role. The logon information must be passed on securely to the terminal servers for the applications to start up.
Different options for encrypting all data streams between the portal servers, terminal servers, and all other involved servers. This allows this technology to be used even in highly security-conscious environments, such as military bases, government bodies, banks, hospitals, or public administrations.
The possibility to distribute certain services and programs to dedicated servers that can, if necessary, be located in different zones (often called demilitarized zones) of a perimeter network. This increases both the security and the scalability of the overall infrastructure. Even features that can analyze and control all data streams passing from one security zone to another within the perimeter network can be integrated where required.
So what would an ideal and secure application access portal look like in reality? Sadly, there is no simple and universal answer to that question. However, there are some products available on the market that attempt to fulfill at least some of the preceding technical requirements. Some of the products are so complex and powerful that each would merit a whole book of its own. Nevertheless, the following section presents the main portal solutions that integrate terminal servers and MetaFrame servers.
|
|