Application architecture  Implementing components and clients

Chapter 1: Creating Component-Based Applications

Designing the EAServer application

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

Follow these steps to design the application:

  1. “Plan for server infrastructure needs”

  2. “Define EAServer packages”

  3. “Define components”

  4. “Define connection caches”

Plan for server infrastructure needs

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

Define EAServer 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 EAServer Manager.

Packages are the units of deployment for your application; you can use EAServer 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 “Deploying components”.

Packages are also one level in the EAServer 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.) Chapter 2, “Securing Component Access,” in the EAServer Security Administration and Programming Guide 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 EAServer Manager.

Choose the Component Models Choose the component model based on your development team’s expertise. See Chapter 3, “EAServer Components,” in the EAServer Feature Guide if you are not familiar with the supported component models.

Design the Component Interface and Transactional Semantics Chapter 5, “Defining Component Interfaces” describes how to define interfaces. The component interface defines the methods that the component will implement. EAServer stores component interfaces as CORBA IDL; however, you can define and edit interfaces using your choice of EAServer 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 2, “Understanding Transactions and Component Lifecycles” explains the design concepts for transaction and lifecycle control in EAServer components.

The following design decisions determine how EAServer manages your component’s transactions:

If your component interacts with remote databases, you must specify a transactional attribute that determines how the component’s database work is grouped within EAServer 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 EAServer 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 EAServer’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 EAServer 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, EAServer 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 EAServer 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 EAServer 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 EAServer Manager Use EAServer Manager to define the components. If you have already created Java or ActiveX components, you can import the component interfaces into EAServer Manager—you do not need to define method prototypes again in EAServer Manager.

“Defining components” describes how to define components in EAServer 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 EAServer 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:

Copyright © 2005. Sybase Inc. All rights reserved. Implementing components and clients