Tutorials : The Mysteries of Business Object - Part 1 :

The Mysteries of Business Object - Part 1

Business Objects are present in any real-life application. In the world of application architecture, Business Objects are a constant challenge to the designers to achieve the right level of granularity and reusability. The myths surrounding the Business Objects often blur the focus and bloat the system design. In this series, we will attempt to clear the cloud surrounding the Business Objects. In the first part, we cover the ground work of defining Business Objects, and compare different strategies for implementing them. Also, we shall discuss embedding business logic and data validation with Business Objects and see how to expose Business Objects to the client application.

What are Business Objects?

There are many views of what the definition of a Business Object is. However, the most commonly accepted definitions of a Business Object can be stated as follows:

Business Objects represent tangible entities within an application that the users create,access and manipulates while performing a Use Case. The Business Objects within a system are typically stateful, persistent and long-lived. Business Objects contain business data and models the business behavior.

From the above definition of Business Object, we might be able to gather a vague idea of how to identify and define Business Objects in our system, but still there are many questions that will arise during the design phase of the application. For example, consider the following questions:

Should the Business Objects need to be always user- facing? Can we have a Business Object that the user never interacts with?
Why Business Objects need to be stateful? Can I define a Business Object that does not maintain state?
How and where do we persist the Business Object?
What about validation of the data within a Business Object?
How do we handle the concurrency and transaction issues with a Business Object?

And there are many more.... we will try to address these issues and few more in the following sections of this article.

The Nature of Business Objects

The Business Objects are the core of any application. A system will generally have more than one Business Objects interacting with each other to offer a whole range of functionalities. Once the business process is complete the Business Objects tend to persist themselves in a permanent data-store for future use. Typically, when modelling an application, business objects come out of the nouns defined within a use case statement. These Business Objects are acted upon by the external actors such as User of the System. In this sense, the Business Object is client-facing. On the other hand, there are some Business Objects, which are acted upon by the system itself. For example, in an order-processing system, there may be a Business Object, which validates all the orders gathered on a particular day and analyses all the orders over $1000 and processes them in a priority basis. This Business Object will never be exposed to the client domain but will be used by the System itself.

We have discussed before that Business Objects encapsulate business data and the behavior. For example, a Customer Business Object can hold data about the details of a particular customer and can also expose the behavior to change the customer contact details.

Now one important thing to note is that Business Objects are not same as data objects. The distinction between Business Objects and Data Objects is that the Data Objects purely hold data and has no behavior. A Business Object might be composed of one or more Data Objects. For example, Customer Business Object might be composed of a data object called CustomerData.

Typically, Business Objects persist themselves into a permanent data-store such as database. However, Business Objects may or may not preserve their state between two consecutive calls to the same Business Object. Depending upon whether the Business Object should maintain state between two calls or not, the Business Object becomes stateful or stateless. This concept is familiar to the EJB developers who often create a stateful session bean. Typically, when a business process takes more than one call to the Business Object to complete the process, we may need to maintain the state between those calls. Otherwise, if it is always a one call to do a business process to a Business Object, the Business Object does not need to maintain its state and can be implemented as stateless.

Thus, as far as Business Objects are concerned they can be implemented either stateful or stateless. In some cases, however it is more appropriate to design the Business Objects to be stateful. For example, in a Customer Order Processing Application, assume that the user can add more than one item to the shopping cart and finally press the checkout button to complete the process. You will need to have the Business Object to capture each order item in a shopping cart and it needs to be stateful in order to hold the complete order list. The Business Object might finally persist the order information to a database, when the user has checked out.

Often, people get confused over maintaining state and persisting state. Maintaining state means preserving the object state within the same business process and persisting state will mean that storing the final state of the object in a permanent store for future reference. A stateful Business Object will lose its state, if the component responsible for the state management shuts down (e.g. The application server shuts down) but the persistent storage operates independent of the application container.

Home / Tutorials / The Mysteries of Business Object / 1

Applet Index
(sorted alphabetically)
A B C D E F G H I J K
L M N O P Q R S T U
V W X Y Z #s

The Java Source
(applets w/source code)
A B C D E F G H I J K
L M N O P Q R S T U
V W X Y Z

How to Add Java Applets to Your Site

New on the Java Boutique:

New Review:

Java Studio Creator 2: Trading Ease-of-use for Performance
Is Java Studio Creator 2 the IDE beginning and small-scale application developers have been looking for? With its low cost, drag-and-drop GUI, and easy database connectivity, the answer may be yes—but be prepared to make some trade-offs.

New Applet:

MultiTab JApplet 2.0
MultiTab JApplet 2.0 is a highly configurable Java Applet that allows you to display multiple Web pages with the minimum of screen space taken, using tabular navigation.