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:
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:
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. EAServer components (other than ActiveX components) are portable between Windows and UNIX. Your developers can develop and test components on inexpensive Windows workstations; later, you can deploy production versions to a high-end UNIX or Windows 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, EAServer 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 EAServer 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.
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.
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:
Which transaction attribute the component uses
Whether transaction boundaries are managed explicitly in the component implementation or implicitly by EAServer.
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.
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:
Chapter 4, “Database Access,” in the EAServer System Administration Guide describes how to define connection caches in EAServer Manager.
Chapter 26, “Using Connection Management” in this book describes how to access cached connections from your component implementation.
