Chapter 2 Creating Component-Based Applications

Designing the Jaguar application

In the design stage, you plan the infrastructure for developing and deploying the application, define the Jaguar components, the component interfaces, and the Jaguar packages that contain the components. At the end of this phase, you will have packages and components defined in Jaguar Manager.

Follow these steps to design the application:

Plan for server infrastructure needs

For an enterprise application implemented by several developers, you may need to create several Jaguar servers to increase developer productivity. For example, you might want dedicated servers for each of the following:

Component development Servers to test components that are under development or revision. A typical configuration uses one server per developer, running on the developer's personal workstation. Jaguar components (other than ActiveX components) are portable between Windows NT and UNIX. Your developers can develop and test components on inexpensive Windows NT workstations; later, you can deploy production versions to a high-end UNIX or Windows NT server.
Client testing/Quality Assurance (QA) Client developers require a server with a stable installation of the application components, to be used by client developers to test their programs. During the early development phase, you can deploy stubbed components to this server to allow testing of client connectivity and basic method execution. (A stubbed component has empty method implementations. For most component models, Jaguar Manager generates source for a stubbed implementation when you generate the component skeleton.)
For a large application, you will need a dedicated QA team to test the application and a QA server to host configurations that are candidates for production release. The QA server and the client testing server can be the same. The QA server machine should have the same hardware architecture and operating system software as the production machine.
Production You will need to install Jaguar on the host machine for the live version of the application. For Internet applications, this machine must be available to clients that are outside your corporate firewall.

Define Jaguar packages

Components must be installed in a package before they are available for use in applications. You should install components that perform related tasks together in a single package. "Defining packages" describes how to create packages in Jaguar Manager.

Packages are the units of deployment for your application; you can use Jaguar Manager to import and export archives of a package, its installed components, and related application files. For example, you can deploy a tested configuration by exporting packages from your test server and importing them into the production server. For more information, see "Deploy components".

Packages are also one level in the Jaguar authorization hierarchy. You can edit the package's required Role Memberships to restrict which users can access components in the package. (Access can also be configured on the individual component level within the package.) "Declarative security" describes options for configuring user authorization for package and component access.

Define components

For each component, you must choose the component model, design the component interface, determine transactional semantics, and define the component in Jaguar Manager.

Choose the Component Models Choose the component model based on your development team's expertise. "Server-side component support" describes the available component models.

Design the Component Interface and Transactional Semantics Chapter 6, "Defining Component Interfaces" describes how to define interfaces. The component interface defines the methods that the component will implement. Jaguar stores component interfaces as CORBA IDL; however, you can define and edit interfaces using your choice of Jaguar Manager's method editor, Java, or IDL. For ActiveX components, you can also import method definitions from a DLL or type library file that you create using your ActiveX development tool.

While designing the interface, you must decide what transactional semantics the component will follow and how the component lifecycle will be managed. Chapter 3, "Understanding Transactions and Component Lifecycles" explains the design concepts for transaction and lifecycle control in Jaguar components.

The following design decisions determine how Jaguar manages your component's transactions:

Which transaction attribute the component uses
Whether transaction boundaries are managed explicitly in the component implementation or implicitly by Jaguar server

If your component interacts with remote databases, you must specify a transactional attribute that determines how the component's database work is grouped within Jaguar transactions. If another component invokes your component, the transaction attribute determines whether your component's database work is done independently or as part of the existing Jaguar transaction.

You must also decide whether or not you will code your component to manage transaction boundaries explicitly. To manage transaction boundaries explicitly, each method must call one of Jaguar's transaction state primitives to indicate the status of the component's transactional work. "Using transaction state primitives" describes this topic in detail.

Instead of writing code to manage transaction boundaries explicitly, you can set the component's Automatic demarcation/deactivation property in Jaguar Manager. This setting is appropriate if every method in your component executes a complete unit of transactional work (in other words, the transactional outcome is never pending when a method returns). When this option is enabled, Jaguar deactivates the component instance after every method invocation. Upon deactivation, the transaction is always committed unless the component aborts the transaction by calling the rollbackWork transaction primitive or throwing the CORBA TRANSACTION_ROLLEDBACK exception. In Jaguar Manager, the Automatic demarcation/deactivation property is set in the Component Properties window, beneath the Transactions tab. "Configuring component properties" describes how to view and modify component properties in Jaguar Manager.

For any component, transactional or not, you must decide how your component's instance lifecycle will be managed. "Component lifecycles" describes the general instance lifecycle model and your options for instance lifecycle management.

Define the Component in Jaguar Manager Use Jaguar Manager to define the components. If you have already created Java or ActiveX components, you can import the component interfaces into Jaguar Manager--you do not need to define method prototypes again in Jaguar Manager.

"Defining components" describes how to define components in Jaguar Manager.

Define connection caches

Connection caching increases the scalability of your application, since it eliminates repetitive login/logoff operations for connections to remote databases. Connection caching is also required for Jaguar transactions to function as intended.

You must define a connection cache for each remote database that your components interact with, and then implement your components to use cached connections. See the following sections for more information:

"Manage Connection Caches" in the Jaguar CTS System Administration Guide describes how to define connection caches in Jaguar Manager.
Chapter 28, "Using Connection Management" in this book describes how to access cached connections from your component implementation.