Try OpenEdge Now
skip to main content
Application and Integration Services
AppServer for OpenEdge Applications : Reasons to partition
 

Reasons to partition

Reasons to partition your application using the AppServer include:
*Performance — Using the AppServer together with the NameServer, which offers connection management and load balancing across multiple AppServer instances, you can significantly improve the performance of your distributed application because the AppServer allows you to distribute the processing load across the machines in your network. Network traffic is minimized, which can result in a dramatic improvement in client application throughput and/or response time depending on how you program your application and configure it with the AppServer.
For Web service and ABL clients, you can maximize AppServer process utilization and availability by configuring the AppServer to use a state-free (stateless and connectionless) operating mode.
In an ABL client, you can further improve the performance of your distributed application, especially one that has an event-driven ABL client, by initiating procedure requests asynchronously. By default, a procedure executes on the AppServer as a synchronous request, requiring the client to wait for the result before continuing execution. If you initiate an asynchronous request, the ABL client continues execution without waiting for the result. Thus, the user can continue to execute client functions after submitting one or more asynchronous requests for execution. The client then processes the results of each asynchronous request as it becomes available.
*Security — You can restrict access to data, as required, but at the same time take advantage of the ability to distribute and share data throughout your network. In addition to standard OpenEdge RDBMS security features and any other security features that your enterprise employs, the AppServer allows you to protect your data at the business logic level (where business rules are applied in your application, also known as the application service level). The AppServer accesses your database with user authorization that is independent of the client application. Using the AppServer allows you to restrict database access to the AppServer user, thus forcing all client applications to go through the AppServer to gain access to your corporate data. It is the business logic that you write using ABL and deploy with the AppServer that provides this security at the application service level.
*Maintenance — Because your core business logic is deployed at your AppServer site rather than at the client application sites across the network, maintenance of your distributed application is simplified significantly. A modification to the business logic only needs to be made at the single AppServer site rather than at each of the client sites across the network.
*Open Client Access — Using the Open Client Toolkit, you can build a Java or .NET client application that executes your business logic on an AppServer. Using additional OpenEdge Web services tools, you can also allow most any Web service client, including ABL clients, to access your application service as a Web service. Java, .NET, and Web service clients all view the application service provided by an AppServer as one or more well-defined objects (Open Client objects), depending on how you organize the application service procedures on the AppServer. A single AppServer instance can simultaneously support ABL, Java, .NET, and general Web service client applications, depending on the operating mode that you choose to configure.
*Intelligent Data Interface — As the interface to the OpenEdge RDBMS, the AppServer provides functionality similar to database triggers and stored procedures. In addition to native OpenEdge RDBMS triggers, you can use procedures running on the AppServer to filter or otherwise process database queries and updates.