5.1 Business Logic

Business logic, in a very broad sense, is the set of guidelines 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, these business objects will have both characteristics (state or data) and behavior. For example, an employee object will have data such as a name, address, social security number, and so on. It will have methods for assigning it to a new department or changing its salary by a certain percentage. To manage this business problem we must be able to represent how these objects function or interact to provide the desired functionality. The business-specific rules that help us 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 belongs to. For example, the sample application contains a group of business objects: a catalog object to show available pets, a shopping cart object to temporarily hold client's selection of pets, an account object to keep information about clients, and an order object to keep track of placed orders. We consider the requirements on an account object:

1. Each client must have a unique account.
2. Each account should have contact information for a client such as name, street address, and email address.
3. Clients must be able to create new accounts.
4. Clients must be able to update contact information for their account.
5. Clients must be able to retrieve information for their account.
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, update contact information, and to get the account information.

The last four requirements specify general conditions that must be met when realizing the behavior of the account object. For example, when a client updates an account, the client should be authorized to access that particular account, updated account information should be written to persistent storage, and concurrent access to the account information to multiple clients should be prohibited.

Similar analysis and requirement definitions could be performed for other objects. For example, an order object will have 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.

5.1.1.1 Maintain State

A business object often needs to maintain the state represented in its instance variables between the method invocations. The state can be either conversational or persistent.

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 another item to the cart, the cart should have both the 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 needs to be reinitialized. 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. Typically, the business objects that operate on session-neutral data exhibit persistent state maintenance.

5.1.1.2 Operate on Shared Data

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 of 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, the business object should provide a mechanism to keep the data in a consistent state.

5.1.1.3 Participate in Transactions

A transaction can be described as a set of tasks that need to be completed as a unit. If one of the tasks fail, 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 the item 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 fail, 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. In the sample application, order placement is a distributed transaction because the inventory table and the order table reside in different data sources.

5.1.1.4 Service a Large Number of Clients

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 mechanism, the system will eventually run out of resources and will not be able to service any more clients.

5.1.1.5 Provide Remote Access to Data

A client should be able to remotely access the 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.

5.1.1.6 Control Access

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, an account business object needs to validate the authenticity of the client before allowing it to update its account information. In many enterprise scenarios, different levels of access control are needed. For example, employees are allowed to view only their own salary objects, while a payroll administrator can view as well as modify all salary objects.

5.1.1.7 Reusable

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. In order for business objects to be able to be used by inter- and intra-application components, they need to be 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.