An application module is a class that represents a business application task. Specifically, it encapsulates the data model associated with a task, plus the custom code to implement the task. An example of an application task might be updating customer information, creating a new order, or processing salary increases.
The business logic tier has one or more application modules that the other tiers — clients and the database — interact with.
An application module represents the data model that your client uses. To create the data model, the application module contains named instances of view objects and view links. (This containership is similar to how a Java frame can contain instances of components, such as a list box and a grid control.)
Together, the view objects and view links represent the various views of data required by the application task. For example, to accomplish the Create New Order task may require,
Different forms or pages in a client can share the view object instances and refer to them by name.
An application module provides a transaction context for the view object instances it contains and use the same set of changes. The transaction keeps track of all changes that affect data in the database. This is an important consideration when deciding what application modules your application needs. For example, you could combine creating an order and adding a customer into the same transaction. View objectsare the vehicles upon which the entity objects are changed.
All changes made during one transaction are committed or rolled back together.
As a general guideline, if you have one form per task, you could structure your application so there is one application module per form.Code specific to a given application task can be written as custom methods on your application module class to encapsulate processing logic and to simplify the job of client pages/frames for using the functionality.
For example, a CreateNewOrderModule application module could have a method called "newOrderForCustomer()" which encapsulated the details of looking up a customer.
An application module represents a data model for a task that is accomplished within one transaction.
Each component in your business logic tier can have Java code associated with it, to perform a particular role. This architecture also makes business components easily reusable. In general, you can determine where to place functionality based on these guidelines:
An entity object contains business logic pertaining to a single business entity. All view objects based on the entity object share the logic. At the entity level, calculations are performed in Java code.
A view object contains logic pertaining to a database query, which is defined by a SQL SELECT statement. This can include SQL-calculated expressions, joins, unions, nested subselects, and so on. You can also add code to the Java source, for example, you can propagate events to the UI from the ViewObjectImpl class, or create a method that calls an entity object method that you want to expose for this view by adding code to the ViewRow class.
An application module's source files can contain logic specific to the task it performs — logic not appropriate to put in an entity object or view object, which multiple application modules performing different tasks can use. If two applications use the same view, you would put logic specific to one of the applications in its application module source files instead of in the entity or view object source files.
In the same way that an application module can use view objects, an application module can use another application module's data model and code by including nested application modules. One application module can contain a variety of simpler application modules that together provide compound functionality. In other words, this feature lets you create new "compound" tasks from application module building blocks. For example, lets say you have separate forms that are each in their own transaction. Later, you decide that you want a form that does many of these tasks at once, in one transaction. So you nest application modules to perform these subtasks in one form, perhaps as separate tabs or dialogs launched from the parent form.
The top-level application module provides a transaction context for the view object instances it contains, including those in all nested application modules. A top-level application module has one connection to the datasource. You define it the same way you define any application module.
Application modules should be nested when they are a reusable part of a specific application task. You should have one form per application module, which can be embedded in other application modules and applications. Nesting an application module implies that it needs to be part of the top-level application module's transaction. For example, an OnlineOrders application module could contain an AddNewCustomer application module.
An application module provides methods that implement the application module behavior and are accessible to clients. There are predefined framework methods that clients can use to work with the application module instance. For example, application modules let you obtain view object instances and execute queries, manipulate the transaction, and so on.
In addition, you can add custom methods and selectively export those public methods you want clients to use. For example, an application module that processes employee salary increases might export methods for finding employee salary information and adding the raise.
You can deploy the same application module in multiple configurations, perhaps using EJB or a web module, without changing its code. Also, the same application module can be used in a physical one-tier, two-tier, or three-tier application (tiers on one, two, or three computers) without code changes.
An application module lets you gather data tailored to a client interface (such as a form), so data can be retrieved in one network roundtrip instead of multiple trips. You can also perform calculations in the business logic tier through remotely accessible methods, reducing client overhead. For bulk operations on application data, you can perform the operation in the business logic tier without downloading all of the data to the client; changes to the data the client is currently viewing are automatically synchronized.
To create and edit an application module at design time, use the Application Module Wizard and Editor. You can also create a default application module by using the Business Components Project Wizard and Package Wizard.
At runtime, a client creates an instance of an application module for its use. They are not shared between clients. The client can create an instance of an application module you created at design time, or an instance of the base application module class, called a generic application module. You can use a generic application module when you want a container for dynamically created view objects, view links, and application modules. For example, if you have a complex application with a client menu containing many tasks, you might decide to create a generic application module that instantiates nested application modules as needed, based on the menu choice, within the same transaction.
A client can use application module instances in a pool. For example, in the case of a web application, you may have 1,000 users but you know that only 100 will be using a certain application module at one time. So you keep 100 application module instances in a pool. When the web client needs an application module instance, it takes a free one from the pool and releases it to the pool when it is finished processing that request. Because the instance is precreated, end users are saved the time it takes to instantiate the application module when they want to perform a task. You can use this feature to improve scalability and performance. Typically, web-based JSP clients use pools. See About Application Module Pooling for more information.