In the design stage, you plan the infrastructure for developing and deploying the application, define the EJB Server components, the component interfaces, and the EJB Server packages that contain the components. At the end of this phase, you will have packages and components defined in the Adaptive Server plug-in.
Follow these steps to design the application:
For an enterprise application implemented by several developers, you may need to create several EJB 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.
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, the EJB Server generates source for a stubbed implementation when you generate the component skeleton.)
Production You will need to install EJB Server 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. Chapter 6, “Working with EJB Packages and Components,” describes how to create packages in the Adaptive Server plug-in.
Packages are the units of deployment for your application; you can use the Adaptive Server plug-in 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 EJB Server authorization hierarchy. You can edit the package’s required Role Memberships to restrict which users can access components in the package.
For each component, you must choose the component model, design the component interface, determine transactional semantics, and define the component in EJB Server.
Choose the component model Choose the component model based on your development team’s expertise. “Server-Side Component Support” on page 7 describes the available component models.
Design the transactional semantics You must decide what transactional semantics the component will follow and how the component lifecycle will be managed. Chapter 5, “Understanding Transactions and Component Lifecycles” explains the design concepts for transaction and lifecycle control in EJB Server components.
The following design decisions determine how EJB Server manages your component’s transactions:
Which transaction attribute the component uses
Whether transaction boundaries are managed explicitly in the component implementation or implicitly by EJB Server
If your component interacts with the database, you must specify a transactional attribute that determines how the component’s database work is grouped within EJB Server 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 EJB Server 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 EJB Server’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 the Adaptive Server plug-in. 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, EJB Server 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. In the Adaptive Server plug-in, 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 the Adaptive Server plug-in.
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 the Adaptive Server plug-in Use the Adaptive Server plug-in to define the components. If you have already created Java components, you can import the component interfaces into the Adaptive Server plug-in—you do not need to define method prototypes again in the Adaptive Server plug-in.
Connection caching increases the scalability of your application, since it eliminates repetitive login/logoff operations for connections to databases. Connection caching is also required for EJB Server transactions to function as intended.
You must define a connection cache for the database that your components interact with, and then implement your components to use cached connections. See “Managing connection caches”, which describes how to define connection caches in the Adaptive Server plug-in
