Administration and development tools  Naming services

Chapter 1: Introducing EAServer

Client-session and component-lifecycle management

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-session management

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.

Component-lifecycle management

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:

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.

Load balancing and failover

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:

See Chapter 7, “Load Balancing, Failover, and Component Availability,” in the EAServer System Administration Guide.

Copyright © 2005. Sybase Inc. All rights reserved. Naming services