5.1 Business Logic and Business Objects

Business logic, in a very broad sense, is the set of procedures or methods used to manage a specific business function. Taking the object-oriented approach enables the developer to decompose a business function into a set of components or elements called business objects. Like other objects, business objects have both state (or data) and behavior. For example, an employee object has data such as a name, address, social security number, and so on. It has methods for assigning it to a new department or for changing its salary by a certain percentage. To manage a business problem you must be able to represent how such business objects function and interact to provide the desired functionality. The set of business-specific rules that help identify the structure and behavior of the business objects, along with the pre- and post-conditions that must be met when an object exposes its behavior to other objects in the system, is known as business logic.

The following discussion demonstrates how to define the structure and behavior of a business object from the requirements imposed by the business problem it addresses. For example, the sample application uses a group of business objects:

• A catalog object to show available pets
• A shopping cart object to temporarily hold a client's selection of pets
• An account object to keep information about a client
• Order objects to keep track of placed orders

Using the account object as an example, its requirements include:

1. Each client must have a unique account.
2. Each account should have contact information for a client such as name, street address, and e-mail address.
3. Clients must be able to create new accounts and close (or remove) accounts.
4. Clients must be able to update contact information for their accounts.
5. Clients must be able to retrieve information for their accounts.
6. Clients can retrieve and update only their own account information.
7. The account information must be maintained in persistent storage.
8. Multiple clients must be able to access their account information at the same time.
9. Multiple clients cannot update the same account concurrently.

The first two requirements specify the structural attributes of the account object. Following these rules, the account object should have a field to hold account identification and several other fields to hold address, phone, and other contact information.

The behavior of the account object is described in requirements three, four, and five. For example, accounts should have methods to create a new account, to update contact information, and to get the account information.

The last four requirements specify general conditions that must be met so that the account object can properly carry out its functionality. For example, when a client updates an account, the client should be authorized to access that particular account and updated account information should be written to persistent storage. No other client should be able to access the particular account concurrently.

Similar analysis and requirement definitions could be performed for other objects. For example, an order object has a set of general conditions on its behavior that have a significant correlation to the behavior of an account object. That is, a client needs to be authorized before updating or reading the status of an order, order details need to be written to a persistent storage, and so on.

If you examine business objects in similar applications you will see that even though the actual structure and behavior of the object is tied closely to the business problem it is going to solve, many services that these business objects provide follow specific patterns that are quite generic in nature.

5.1.1 Common Requirements of Business Objects

This section describes common requirements of business objects.

A business object often needs to maintain state between method invocations. This state can be either conversational or persistent. Conversational state is state maintained in an object during the conversation between a client and the application. Persistent state is state that is stored in a database or other persistent store, outliving the conversation between a client and the application.

Consider a shopping cart object. The state of the shopping cart object represents the items and quantities of the items purchased by the client. The cart is initially empty and gains meaningful state when a user adds an item to the cart. When a user adds a second item to the cart, the cart should have both items in it. Similarly, when a user deletes an item from the cart, the cart should reflect the change in its state. When a user exits the application, the cart object is reclaimed and the conversational state no longer exists. When the object gains, maintains, and loses its state as a result of repeated interactions with the same client, we say the object maintains conversational state.

To understand persistent state, consider an account object. When a user creates an account, the account information needs to be stored permanently so that when the user exits the application and re-enters the application, the account information can be presented to the user again. The state of an account object needs to be maintained in persistent storage, such as a database that will survive system crashes.

Another common characteristic of business objects is that they often operate on shared data. In this case, measures must be taken to provide concurrency control and appropriate levels of isolation for access to the shared data. An example of such a scenario would be multiple users updating the same account information. If two users try to update the same account at the same time, a mechanism must be used to keep the data in a consistent state.

A transaction can be described as a set of tasks that need to be completed as a unit. If one of the tasks fails, all the tasks in the unit will be rolled back. If all of them succeed, the transaction is said to be committed.

Business objects often need to participate in transactions. For example, order placement needs to be transactional because of the set of tasks required to complete an order--decrementing the quantity of the purchased item in inventory, storing the order details, and sending an order confirmation to the user. For the transaction to be completed, all of these tasks must succeed. If any one of these tasks fails, work done by other tasks needs to be undone.

In many business operations, transactions may span more than one remote data source. Such transactions--called distributed transactions--require special protocols to ensure data integrity. Chapter 8 discusses the issues involved in transaction management.

A business object should be able to provide its services to a large number of clients at the same time. This translates into a requirement for instance management algorithms that give each client an impression that a dedicated business object is available to service its request. Without such a management mechanism, the system will eventually run out of resources and will not be able to service any more clients.

A business object should remain available to clients even when systems crash, a service referred to as high availability. The EJB container in which a business object resides provides this service by utilizing strategies to mask various server errors from the clients.

A client should be able to remotely access services offered by a business object. This means that the business object should have some type of infrastructure to support servicing clients over the network. This in turn implies that a business object should be part of a distributed computing environment that takes care of fundamental issues in distributed systems, such as location and failure transparency.

The services offered by business objects often require some type of client authentication and authorization mechanism to allow only a certain set of clients to access protected services. For example, it should be verified that a client is authorized to update account information in an account business object before allowing it to do so. In many enterprise scenarios, different levels of access control are needed. For example, employees should only be allowed to view their own salary objects, while a payroll administrator can view as well as modify all salary objects.

A common requirement of business objects is that they be reusable by different components of the same application and/or by different applications. For example, an application used by the payroll department to keep track of employees' salary may have two business objects: employee and salary. A salary business object may use the services of an employee business object to get the grade level of an employee. An application that tracks the employee vacation allowances may want to use this employee object to get the name of the employee through the employee number. Business objects are able to be used by inter- and intra-application components when they are developed in a standard way and run in an environment that abides by these standards. If these standards are widely adopted by the vendor community, an application can be assembled from off-the-shelf components from different vendors. In addition to enabling rapid application development, this approach helps developers avoid vendor lock-in.