An Application Module can store application-specific code on the middle tier. For example, suppose a View Object named EmpView is shared by two client applications, and one client needs to calculate the sum of all employee salaries each time a row is added to the view. You could add the code directly to EmpView, but doing so increases the effective size of the object, adding to the processing burden on every client and application that uses it. A more efficient approach is to add the code to the Application Module. That way, the custom code is available only to clients that need it. Figure 1 shows both approaches.
Code attached to an Application Module executes in the middle tier, which might be more efficient than executing the code on the client. For example, suppose a client form needs to calculate a value based on values in a table. If that table contains (for example) 130 rows, the calculation requires that all 130 rows be brought to the client, resulting in 130 network round trips. Client-side performance can deteriorate when working with large tables.
When the code resides in the Application Module, the data stays in the middle tier. Performance is optimized, because the client gets the result in a single network round trip. The Business Components for Java framework handles the details of making selected Application Module methods available to clients.
