Chapter 1 Introducing Jaguar CTS

Client-session and component-lifecycle management

Jaguar client sessions are established internally by the client stubs and proxies that applications use to invoke Jaguar component methods. A component's lifecycle determines how instances are allocated, bound to client sessions, and destroyed. Jaguar CTS manages both client sessions and component lifecycles without requiring any specialized knowledge on the part of the application developer.

Client-session management

As discussed in "Client stub/proxy support", client applications use a stub or proxy object to invoke methods on the Jaguar server. Internally, the stub or proxy object establishes a network connection between the Jaguar server and a remote client. All the stub/proxy models discussed in "Client stub/proxy support" require user-authentication parameters in order 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. "Declarative security" describes security support in detail.

All stubs and proxies use the Inter-ORB Invocation Protocol (IIOP) to communicate with the Jaguar server. MASP clients use the Sybase Tabular Data Stream™ (TDS) protocol. "Network protocol support" discusses client protocols in detail.

For more information on stub and proxy objects, see:

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 Jaguar 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. Jaguar 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. Jaguar calls deactivate just before an instance is unbound from a client session (that is, made idle again).
Methods in the component must use the Jaguar transaction state primitives to request early deactivation (see Chapter 3, "Understanding Transactions and Component Lifecycles").

For components that support Jaguar transactions, the time between Jaguar's activate and deactivate calls coincides with the beginning and end of that instance's participation in a Jaguar 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 3, "Understanding Transactions and Component Lifecycles" describes how components participate in instance pooling and Jaguar 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 as long as the number of simultaneous clients is not too large.

For applications with thousands of clients, you can define a Jaguar cluster with several redundant servers to run the application's components. The cluster allows load balancing and failover as follows:

Load balancing Jaguar can use load balancing, which optimizes performance for your Jaguar 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 a Jaguar 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.

For more information, see "Load Balancing and Failover" in the Jaguar CTS System Administration Guide.

Coded character set conversions

Jaguar supports multiple coded character sets for clients and components. When a client and component use different coded character sets, the Jaguar server 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, Jaguar 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 codesets using Jaguar 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 Jaguar client ORB by setting the ORBCodeSet property. See Chapter 17, "Creating CORBA C++ Clients" for more information.

For MASP clients, the codeset is specified as an Open Client or ODBC property before the client connection is opened. See Appendix A, "Executing Methods As Stored Procedures" for more information.