EAServer client sessions are established internally by the client stubs and proxies that applications use to invoke EAServer component methods. A component’s lifecycle determines how instances are allocated, bound to client sessions, and destroyed. EAServer manages both client sessions and component lifecycles without requiring any specialized knowledge on the part of the application developer.
Client applications use a stub or proxy object to invoke methods on EAServer. Internally, the stub or proxy object establishes a network connection between EAServer and a remote client. All the stub/proxy models discussed in “Client stub and proxy support” require user-authentication parameters to instantiate a stub or proxy object. The communication protocol is also determined when the stub or proxy object is instantiated. Once the stub or proxy object exists, all details of network communication are hidden from the application developer.
The user name determines which components a client session can access. If a component does not allow access to the user, attempts to instantiate a proxy or stub fail. The EAServer Security Administration and Programming Guide describes security support in detail.
All stubs and proxies use IIOP to communicate with EAServer. MASP clients use the TDS protocol. “Network protocol support” discusses client protocols in detail.
A component’s lifecycle determines how instances of a component are allocated, bound to specific client sessions, and destroyed. In the simplest case, an instance is allocated for each stub or proxy created by the client and is destroyed when the client explicitly requests destruction or when it disconnects, whichever happens first.
More sophisticated components can be coded to support instance pooling. Instance pooling allows EAServer to maintain a cache of component instances and bind them to client sessions on an as-needed basis. Instance pooling requires the following changes to your component:
The component must provide activate and deactivate methods. EAServer calls the activate method just before an instance is bound to a client session. activate must be able to reset the component to an as-allocated state. EAServer calls deactivate just before an instance is unbound from a client session (that is, made idle again).
Methods in the component must use the EAServer transaction state primitives to request early deactivation.
For components that support EAServer transactions, the time between EAServer activate and deactivate calls coincides with the beginning and end of that instance’s participation in an EAServer transaction.
Using components that support instance pooling increases the scalability of your application. Instance pooling eliminates execution time and memory consumption that would otherwise be spent allocating unnecessary component instances.
Chapter 2, “Understanding Transactions and Component Lifecycles,” in the EAServer Programmer’s Guide describes how components participate in instance pooling and EAServer transactions.
In the simplest scenario, your application’s components are deployed to one server, and all clients connect to that server to execute the component’s business logic. This scenario works well when the number of simultaneous clients is not too large.
For applications with thousands of clients, you can define an EAServer cluster with several redundant servers to run the application’s components. The cluster allows load balancing and failover as follows:
Load balancing EAServer can use load balancing, which optimizes performance for your EAServer cluster by adjusting the load across the servers, based on load metrics and a distribution policy, or based on a random algorithm. When a client resolves the name of an EAServer component, the name server returns several candidate server addresses. When you allow the algorithm to randomly distribute the processing load over servers in the cluster, the client ORB tries the addresses in random order. When you specify the load metrics and distribution policy, the load is distributed according to each server’s current load.
Failover You can configure components to allow automatic failover that is transparent to client applications. If a component allows automatic failover, the client ORB automatically reconnects to another server within the cluster when a previously connected server goes offline.
In-memory failover support allows component state to be maintained on a pair of servers, without incurring the overhead of using a remote database to store component state. See Chapter 28, “Configuring Persistence for Stateful Session Components,” in the EAServer Programmer’s Guide.
See Chapter 7, “Load Balancing, Failover, and Component Availability,” in the EAServer System Administration Guide.
| Copyright © 2005. Sybase Inc. All rights reserved. |
|
|