This question may sound a little too simplistic for a book on Struts. However, the term "business object" has many connotations, and some developers use it when they really mean something else. A business object (BO) is simply a software abstraction of a real-world entity. It represents a person, place, thing, or concept from the business domain. So, concepts such as items, orders, and customers are all business objects from the Storefront business domain.
Business objects consist of state and behavior. The OrderBO, for example, is aware of information relating to a single customer purchase order, including price, tax, and order status. An OrderBO also should know who the customer is and be able to provide this information. Having both state and behavior is an important criterion for a class to be considered a business object. Let's examine a few other business object characteristics.
For a class to be considered a business object, several conditions should be met:
· Consists of state and behavior
· Represents a person, place, thing, or concept from the business domain
· Is reusable
Business objects also can be grouped into different classifications. Generally, there are three types:
· Entity business object
· Process business object
· Event business object
Probably the most familiar, an entity BO represents a person, place, thing, or concept. These usually are extracted straight from the business domain by considering the nouns in the business. Again, these are concepts such as customers, orders, items, and so on. In an EJB application, these are modeled as entity beans (hence the name). In a more traditional web application, these may be regular JavaBeans that contain the state and behavior of the business application.
Process BO s represent business processes or workflow tasks within an application. They usually are dependent on entity BO objects and are the verbs of the business. In an EJB application, these normally are modeled as session beans or, in some cases, message-driven beans. In a non-EJB application, these may be regular JavaBeans that contain specialized behavior to operate as a manager or controller for the application. Even though these types of business objects are used for processing workflow, they still can hold state for an application. With EJB, for example, there are stateless and stateful session beans.
The final category of business object is the event BO. An event BO represents some event in the application (exception, alert, timed event) that causes or is generated by some action in the system. In a Java Swing application, for example, when you press a button, an event is raised notifying the underlying framework so that an event handler can handle the button press.
Using business objects in an application has several benefits. Probably the most important is that business objects provide common terminology and ideas that can be shared across an organization by technical and nontechnical people alike. Because they represent real-world concepts and ideas, they are very intuitive and should make sense to the entire organization. If multiple applications from the same business domain exist, it's likely that the same business objects exist across the application boundaries. This reuse of information and behavior allows for faster application development and reduces redundancy.
Business objects also have the ability to evolve with the organization through modifications to the original object or through proper specialization. This is very important because as an organization changes, the information and behavior must adapt and change with it.
Finally, business objects have well-defined interfaces—not interfaces in the Java sense, but a clear and cohesive set of functionalities. The internal implementation should be hidden from the client to protect the callers from changes to the implementation details. For example, suppose you have a business object that uses a java.util.ArrayList. Instead of exposing the type ArrayList, you should expose java.util.List. If the implementation changes internally from ArrayList to LinkedList, the caller will not be impacted because the client is programming against the List interface, not the implementation class.
By now, you should be fully aware of the importance that business objects have in an organization. They are present in all but the most trivial applications. You also know that they contain state and behavior that, in most cases, acts on that data. So the next questions should be, where does that state originate and where does it go when the application is stopped? This leads us into the topic of object persistence.