Building Distributed
Applications
Using the Progress AppServer
Configurations
The Progress AppServer affords great flexibility in how you distribute an application. In addition to the most basic configuration, one client application connected to one AppServer, you can distribute your applications using any combination of the following basic configuration scenarios:
Each of these scenarios is described in the following sections.
Multiple Client Applications Connected to One AppServer
Figure 2–4 shows a connection to an AppServer from multiple client applications, with the AppServer configured with a local database. In this scenario, all running Application Server processes share self-service access to the same database. Client applications, however, have access only to data that the AppServer provides and never access the database directly. To regulate this data access, you can implement many different security arrangements on the AppServer. Each one typically restricts remote procedure access and execution based on any combination of user-based (authorization) and application-based (functional) security.
Also, each client application can be quite different and unrelated to the others, except that they all require data that the same AppServer provides. In the course of interacting with the AppServer, a client application might call a remote procedure that connects and accesses an additional database connected only to the Application Server process handling that particular request.
NOTE: Each Application Server process in any AppServer configuration has the same database access capabilities as a standard 4GL client, including access to remote database servers.Figure 2–4: Multiple Clients Connected to an AppServer
![]()
Client Applications Connected to Multiple AppServers
A client application can connect to multiple AppServers on the same, or on different, machines. For example, a client application can be concurrently connected to an AppServer on a UNIX machine and have separate connections to two different AppServers running on Windows NT machines.
Figure 2–5 shows how this configuration might look with a client application connected to three different AppServers running (respectively) on one UNIX and two NT machines. In this scenario, the UNIX AppServer accesses a local database. Each NT AppServer accesses the same remote database server (or DataServer) running on UNIX, which thus implements a three-tier distribution of application resources.
Figure 2–5: Client Connected to Multiple AppServers
![]()
AppServers Connected to One Another
Application Server processes can connect as 4GL clients to other AppServers. Figure 2–6 shows three AppServer machines (on NT and two UNIX) and one client application connected in an n-tier fashion. AppServer-1 on the NT machine accepts remote requests from the initial client application. AppServer-2 on UNIX accepts remote requests from AppServer-1, and AppServer-3 on UNIX accepts requests from AppServer-2.
Note that there is a separate AppServer session within each Application Server process and the connection that an Application Server process establishes with another AppServer is part of its AppServer session. That is, a connection that an Application Server process establishes with another AppServer is part of its session context and is not shared with any other Application Server process. For example, each Application Server process running on AppServer-2 establishes and manages, as client, its own unique connection to AppServer-3.
Figure 2–6: AppServer-to-AppServer Connections
![]()
Copyright © 2004 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095 |