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, then 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—see Chapter 2, “Understanding Transactions and Component Lifecycles,” in the EAServer Programmer’s Guide.
For components that support EAServer transactions, the time between EAServer’s 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 Components can be configured 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 for more information about in-memory stateful failover.
For more information, see Chapter 7, “Load Balancing, Failover, and Component Availability,” in the EAServer System Administration Guide.
EAServer supports multiple coded character sets for clients and components. When a client and component use different coded character sets, EAServer automatically converts character data from one character set to another. For example, if the client uses the roman8 character set and the component uses iso_1, EAServer converts string parameters and return values automatically from roman8 to iso_1 when the client calls the component methods.
In accordance with the Java and ActiveX standards, Java components, Java clients, ActiveX components, and ActiveX clients all use 16-bit Unicode. Unicode contains mappings for all characters in all other known coded character sets.
For C and C++ components, you can specify code sets using EAServer Manager. The server Codeset property specifies the default for all C and C++ components (this property is set on the General tab in the Server Properties window). You can override the default for an individual component by setting the Codeset component property (located on the General tab of the Component Properties window).
For C++ clients, you can specify a character set when initializing the EAServer client ORB by setting the ORBCodeSet property. See Chapter 15, “Creating CORBA C++ Clients,” in the EAServer Programmer’s Guide for more information.
For MASP clients, the code set is specified as an Open Client or ODBC property before the client connection is opened. See Appendix A, “Executing Methods As Stored Procedures,” in the EAServer Programmer’s Guide for more information.
| Copyright © 2003. Sybase Inc. All rights reserved. |
|
|
