DEVELOPING

BUSINESS
OBJECT-BASED
APPLICATIONS

PAGE 1
 DEVELOPING BUSINESS
OBJECT-BASED APPLICATIONS

INTRODUCTION
We are in the midst of a great paradigm shift. Demand is growing rapidly for distributed applications
and services accessible by applications and applets from the smart card to the supercomputer. Java
is a key catalyst behind this shift. To keep up, we have to become entirely re-educated while
maintaining the same degree of productivity. Procedure-oriented languages of the past keep the
progress toward distributed applications in check. It’s hard to develop truly distributed applications
with dataset-based development tools. Java was initially received with a lot of fanfare, but widespread
implementation of object-oriented technology has fallen short of original industry expectations. While
many developers are now programming in Java, they’re still stuck in the procedural paradigm. Today
the primary obstacle we face is in our heads, not our tools or APIs.

The goals of this paper are fairly simple. The first goal is to provide a cursory overview of business
objects and object-oriented design (OOD). It’s important to have a clear understanding of basic OOD
concepts when designing business applications in Java. The second goal is to demonstrate possible
implementations of objects using RMI and CORBA. If you’re a hands-on type, you may want to jump
to the second part of this paper where I’ll be demonstrating the practices of business object
development.

MAKING THE BREAK

FROM THE PROCEDURAL PARADIGM
Making the transition from relational to object oriented thinking is not easy. To succeed we must
suspend our traditional views of data and system design. For some, learning to think in terms of
objects vs. data is like learning to walk again. For those OOD-challenged among us, there is hope.
Later I’ll outline some basic guidelines for sound OOD. Tools like JBuilder are making it easier
because of the open architecture of their component libraries. More and more companies are
beginning to realize the efficiency and power that OO technology can bring to application
development. The potential for maximum code reuse, increased application performance and scalability,
plus reduction in development time and cost far outweighs any obstacle we may face.

The real challenge today is breaking away from our old procedural way of application development.
Just because we’re using an object-oriented language, doesn’t mean we’re developing object-
oriented applications. Surprisingly, the development community as a whole is still grappling with this.
Even though there are more programmers using Java, few are actually creating applications that
employ the full power of true object-oriented analysis, design, and programming.

KEY CHARACTERISTICS
OF OBJECT-ORIENTED APPLICATION DESIGN
A genuine object-based system is modeled after the real world. The entities that make up the system
are representative of real world entities or concepts. The well-designed OO software model mirrors
the behavior or process of your real world model. Understand one, and you understand them both.

PAGE 2
This greatly reduces the learning curve for new developers coming onto a project, and facilitates
code maintenance, since each component or object is completely autonomous. The potential
savings in resources and development time should make OOD an attractive alternative.

We all need to put out better applications at an increasingly rapid rate. There’s an obvious competitive
advantage in a three-month turnaround. Using tools like JBuilder to develop OO applications,
developers could conceivably compact three months of development time into three hours.

Business rules are decoupled from the objects

Highly granular objects are highly interchangeable objects. By decoupling objects and business rules,
we free up code for reuse across systems. By separating data from the UI we can:

• Develop true thin client applications by pushing business logic on to the middle tier
• Apply multiple UIs over the same object or group of objects.
• Share objects across multiple business systems.
• Allow changes to the implementation of the business object without affecting the UI.

Extracting business rules out of the UI gives designers and end users the flexibility to implement
different UI’s over the same exact objects, which means there’s absolutely no reason to have the
same logic coded in more than one place. Instead, the same logic becomes shareable in multiple
systems. Put into practice, this strategy can drastically reduce the cost of maintaining an application
throughout its life cycle.

Our goal should be to code every business rule once, and in only one place. This prevents our
business objects from being impacted every time the business rules change. For example, in
corporate environment, there’s no reason why you would have employee logic coded multiple times
in multiple systems. You should be able to share that same employee logic across all the business
systems. It should not belong to any one system. The system becomes a flexible collection of
components. That way the employee is the same employee in all the enterprise systems. Human
resources, information systems, and finance can all operate on the same employee logic.

Partitioned applications

OO business applications are more easily partitioned and distributed across the enterprise.
Partitioning an application involves developing small, granular objects that know how to
communicate with each other, have conversations, store themselves, and retrieve themselves. In
other words, you’re creating a series of self-sufficient entities that efficiently execute their singular
responsibilities. It doesn’t matter what tier the objects are running on, or what part of the application
they’re written for. They can be accessed by anyone from anywhere. I may have the data for one
object sitting in Sybase and another in Object Store. If I design them properly, there’s no problem
sharing data between them since neither object knows where it’s being stored. Because they interact
communicatively, there’s no incompatibility. If I decide to go from Sybase to Oracle, I only have to
rewrite my Sybase objects against Oracle, and translate the data. Other systems using that object are
unaffected by the change. The data is completely encapsulated or hidden from the interface.

Java developers have an added edge when implementing applications in a distributed architecture.
Object Request Brokers (ORBs) permit high-level communication between applications. OOD
positions your application for tight integration with today’s evolving network standards.

PAGE 3
Beyond RAD

Developing better business objects from the beginning means spending less time building the
foundations of your second project. The concept of very rapid application development (VRAD)
involves building with pre-built pieces of code — “plug-and-play” style. When you write your first
application, you start from scratch. In a VRAD scenario, you could start the first day of new application
development pulling together chunks of existing code and have a partially finished application at the
end of the day. Design the first project for maximum code reuse, and your second project could be
fifty to seventy percent completed before you add a single line of new code.

The demand for “off-the-shelf” client and server side components is growing, and presents another
interesting market for software vendors. We’re moving beyond rapid application development
(Enterprise Java Beans Spec). As we build our library of reusable business functions, we can
decrease our application development and deployment time.

DISCERNING BETWEEN OBJECT-ORIENTED

AND DATASET-BASED SYSTEMS
Discerning object-oriented from dataset is easy, once you know what to look for. If you’re new to
object-oriented programming, keep your eye out for the following red flags, and avoid falling back
into these procedural habits when you start your first OO project.

You’re working with singular, specific objects

rather than sets of data
An object is a combination of data and methods, and has behavior. When you’re dealing with datasets,
you’re working with row in a matrix or list. A list of things can’t have behavior like an object can. The
key here is that all entities are interactive or have the potential to be interactive. Suppose a
corporation has a “lay off twenty percent of the workforce” method. When that method is invoked,
other entities in that corporation have behavior. The head of the division tells the managers to cut
back their staff. The managers select and notify the affected employees. Employees pack up their
stuff and leave the building. The manager object gives the payroll object the names of the laid off
employees. Payroll then stops writing checks for these employees. A procedural dataset-based
system would have written the logic to affect all the data instead of messaging the proper objects to
accomplish the same thing.

Ask yourself the question: are you operating on a single object or one of a group of data (one piece
of which makes up the data for your object), or do you have a distinct entity that can be operated on
independently? If you’re not, then you’re working with a dataset.

You’re navigating through objects

rather than keys and IDs
A person object has a spouse object. In a relational based system you would go to the person object
or cursor and say “getSpouse.” In an OO system, you’d say Joe.getSpouse().

PAGE 4
Every entity in your system encapsulates
one key abstraction
Every entity must encapsulate one (and only one) key abstraction. If you need more, the best thing to
do is create a composite object of all the objects that contain the abstractions you want to
encapsulate. That way, you can always get down to the granular part of something, if necessary.

To illustrate, let’s use an undergraduate course registration system as an example. In this system you
may define each individual course offering as an object. That makes sense. However, you wouldn’t
want to include any information about the professor in the course object. Professors should also be
treated as individual objects that have a relationship to the course object.

A good rule of thumb is, “If your objects start getting larger than eight attributes, take time to consider
how you might subclass some of them.” If you have over 20, by all means get out the chopping
block. It helps to stretch our minds during the classification process. You also have to make decisions
about if a data entity is an attribute or a related object. An example of this decision is an address
having a state. If we make it a simple address (i.e. a string) we cannot store related pieces of
information like tax rates etc. If we make it a related object, we can store other information with the
state and when that other information changes, it will get updated throughout the system.

Method based vs. data based

In OO terms, the combination of methods and data equals behavior. Take the method away and you
just have data. We need to ask ourselves, is the data there to support the methods, or are the
methods there to support the data? We’ve started to think the system is about data, it’s not. It’s about
methods. For example, we write a payroll system. Is our primary purpose for doing that to record how
much our employees make, or do we do it so it will write checks for us? I think it’s because we want
it to write checks for us. We need to remember that systems are about more than just data. We’ve
lost our focus on the idea of the system’s behavior.

A purely data-based system has the potential of scattering the system logic because we centralize it
around the data as opposed to around the functionality. Some industry studies have shown that
business rules are recoded an average of four times in an average system. When we design, we
need to consider both application logic and data as things that need to be stored in a repository. If
data is wrong or missing in our system, more than likely it is because the application logic is wrong
or isn’t forcing the data to adhere to the business rules. Our application logic needs to be centralized.
We need to centralize all of our application logic in one place. If the application logic is totally
dispersed through the system, you may be looking at a dataset-based system.

THE PROBLEM WITH DATASET-BASED

APPLICATIONS
Working with members of datasets rather than objects reduces our ability to distribute applications.
To be highly interactive with the business rules, we have to code some business rules into the UI. For
instance if we just put the rule in a trigger in the database, the user could fill out an entire form and
them post the data to find out that information that they entered on that form was already in the
system. When we push the rules farther to the server side, they are enforced more, but then we have
a very awkward system. By pushing the rules to the client we end up with a fat client. When I pass a
dataset to a client, my business rules are running on the client even if they’re running independent of
the GUI, (if they are being interactive). In other words, my application logic is not sitting on the middle
tier; it is running on the client.

PAGE 5
Given the choice, I believe most programmers would prefer object-oriented design. The problem is
that very few people know what a true OO system looks like! Until now, tools that supported true OO
development haven’t been readily available. There’s no default binding mechanisms to bind to
objects as opposed to datasets.

HOW BUSINESS OBJECTS SOLVE THIS PROBLEM

The solution is to develop a truly OO system of independent objects and groups of objects that each
serve one and only one purpose. Objects that serve a single purpose are ultimately easier to manage
and deploy across the enterprise, letting you take full advantage of distribution mechanisms and run
your application logic on the middle tier.

Let me illustrate one situation where a truly object-oriented approach would serve us better. Suppose
we were to design a stock trading application for Big Name Brokerage House. We could build a stock
quote object that contains the stock quote (the data) and notifies all registered users whenever the
quote changes (the method). Big Name Brokerage House can then put the object out on their
application server and have one thousand Big Name brokers and customers registered to it.
Whenever the quote changes, it notifies all of its registered listeners automatically. Unlike static sets
of data, our stock quote is dynamic because it has behavior. It can communicate, act upon other
objects, and react to other objects.

DEFINING BUSINESS OBJECTS

What is and what is not a business object? A business object is a person, an invoice, or a piece of
inventory. It’s world related, not technology related. It shouldn’t even know how to “talk technical.” A
business object is not a GUI control, it’s not a threading mechanism, it’s not an inventory control, and
it’s not an error handler. Business objects represent the marriage of data and behavior that represent
real world entities. David Taylor puts it best:

The central activity in working with objects is not so much a matter of programming, as it is
representation ... [in object oriented development] each important real world object or concept is
represented by a software object and all the information and behavior associated with that real world
object are represented by the software object.”

A business object represents each important real object or concept in the business environment. All
the behavior of that real world model should be represented or mirrored in the software object. That’s
the core of a business object. Examples of a business object are things that you find in the real world,
or any concept in a real world that crosses objects. Patients, immunizations, and lab tests may be
objects in a hospital administration system. In a growing software and hardware manufacturing
company, invoices, components, software CDs and employees may be objects. These are all
examples of “real world” objects, or “noun” objects.

Objects can also represent concepts. Just as in the real world, relationships exist in the object world
to tie two or more objects together and define the scope or behavior of their interaction. Each unique
object, like people, can interact with others differently based upon their relationships. Our relationship
with our boss is different from our relationship with our spouse or children. Our behavior towards our
boss and our children is different because each relationship is different. If an object model is truly
representative of the problem domain, it is possible to reproduce the behavior of the business by
causing the objects to act out their role within the model. As mentioned earlier, thinking in objects is
the hardest but most critical part of OO design. If we can effectively mirror all the functionality of our
real world problem domain into a system, including clearly defined object relationships, then we can
be sure the system will successfully complete the tasks it’s designed to perform.
PAGE 6
KEY BUSINESS OBJECT CONCEPTS
Let’s take a moment to review several important concepts of business objects. This may be review
material for most readers; however, some of these terms are becoming so widely used that it is
important to make sure they’re understood with regards to business object development.

Interface

An interface is the contact point through which outside entities or objects can interact with an object.
It defines what data a business object contains, and what behavior it has in its methods. Interfaces let
you change an object without breaking the rest of the system. When you implement an interface, you
contain the methods. I should be able to ask the business object, “Are you a person?” If it responds,
“Yes,” then I can cast it to a person type. I can ask the person, “Are you an American citizen?” If it
answers yes, then I can cast it as an American and interact with it based on the fact that it’s an
American. How I talk to the object depends on its interface.

Business rules

Each object has its own particular laws or restrictions. We can center the business rules in the object,
but a better choice would be to separate the rules out and register them to the object. When we
separate the rules out, it becomes easier to keep track of the rules the object is enforcing. This also
permits better interactivity between objects because once we separate the rules; they can effectively
span multiple objects.

For example, suppose we’re building a banking system. In this system we need to be able to track
open accounts, and closed accounts. The system must be able to correctly identify which accounts
can be drawn from and which cannot be drawn from: “This checking account number is valid,” or
“This checking account number is invalid.” These rules can apply anywhere that an account number
applies in the system. A purchasing system that’s buying things against an account or a receiving
system that receives against the account could use it. The goal would be to code the “ValidAccount”
rule once that all of the banks systems could use. ATMs could use it. Sales transactions could use it.
The banks mortgage department could use it. The employees that prepare checking statements
could use it. By taking the rules out of the object itself, we can achieve greater autonomy of objects
and interaction between objects. If we coded the rules right into the object, we’ll never really know
what rules the object enforces.

Behavior

Data and methods combine to form behavior. Methods encapsulate the objects’ entire behavior.
Behavior is seen most clearly when two or more objects interact. To illustrate, I have a person object
with a method “Die.” This behavior can be internally invoked in the person (i.e., “you’re dead now.”)
and it can be invoked externally by informing the person’s next of kin object. The next of kin person
has a method “Mourn,” “Contact other family members,” or “Dig out the life insurance policy.”
However, how the objects react to the message is up to their methods. Every object may react
differently.

Classification

This is the act of deciding what is an object and what is not. There are no really hard and fast rules for
this. I will only say that there is no perfect way to do it. See Collaboration/Object Responsibility for

PAGE 7
more on this concept. Without a clean object model, your object-oriented system will fall apart.
Persistent objects will generally fall into two categories: “Is,” as in “is an employee” and “Has,” as in
“has an office.” There are other objects that may not represent a real world concept rather than a
data-based entity. These objects generally work on the persistent objects in your system. An example
may be an invoice printer — this would not qualify as a persistent object, but it could operate on
persistent objects in the system.

Subclassing

Building, abstracting from, or extending off an existing class to create a new or specialized class is
called subclassing. Inheritance, specialization, and generalization are all different ways of subclassing.

Inheritance

Inheritance is the act of generating a new class that extends or modifies behavior present in an
existing class by editing a duplicate copy of an existing parent class to create a new child class. Child
classes enhance or modify the behavior of their parent classes while inheriting the data structures
and methods of the parent class.

Specialization

Specialization is the process of tweaking an object through subclassing. For example, from boats you
can subclass many specific or specialized kinds of boats such as sailboats, cruise ships, and aircraft
carriers.

Generalization

The process of taking the common behavior out of two objects to make a third object or interface is
referred to as generalization. Sometimes it’s difficult to find the commonality between two objects. In
this case, it’s better to start with your specialized objects first. It’s easy to find the commonality
between a canoe and an aircraft carrier. They’re both boats. Once I have the pieces then I can make
observances about their common attributes and methods. In this example, both canoe and aircraft
carrier could have methods called takeOnWater() and sink(). The process of generalization leads to
polymorphism in your system. Both of the boats could come off a “Vehicle” class that can
encompass a wide range of transportation methods including water, air, and ground vehicles.

Attributes

An attribute is a data member of an object, such as a person’s first name. It’s part of the object
definition.

Encapsulation

This is the practice of hiding details of the implementation. “Don’t tell me how you do it; just do it.” A
well-designed object separates the “what” from the “how.” Suppose you have an object called Car
with a method “Start.” To invoke Start, the user doesn’t need to know that Start first checks to see if
the car is in park or neutral, then opens the choke, turns on the fuel pump, etc. Those details of
implementation are hidden. All they need to know is that to get Car to run, they must invoke Start.
Notice that I didn’t state they had to turn a key — that’s because there are cars that you can start by
pushing a button. The interface is the concept of Start, not the actual how-to procedure.

PAGE 8
Polymorphism

The concept of designing multiple objects with similar actions to have the same public interface with
potentially different behavior, depending on the implementation of their class is polymorphism. Take
the car example above and subclass it to make an Electric Car. Electric Car also has a method called
Start. Under the hood, Electric Car’s start method is very different from Car’s start method. Polymor-
phism lets subclasses override a mechanism and do their own thing, and lets you view different
objects through a common lens. And lets you act on different objects based on their
common interface.

Collaboration/Object Responsibility

A class should contain all of the functionality that is defined as its responsibility. Objects can collabo-
rate with other objects to accomplish their responsibilities. Objects can also contain other objects, or
can they can create and use new objects. The application should not have to create two objects to
get one task done. If you need two objects to accomplish one logical unit of work, you should build
a composite object to do that task. You may have two objects that have to perform the same task.
Rather than code the same task behavior into both objects, build a third object that’s solely
responsible for the task at hand. Then you can instruct the first two objects to call the third when it’s
time to perform the task.

KEY PRINCIPLES OF BUILDING BUSINESS OBJECTS

Here are some rules of thumb to keep in mind when designing business objects.

Don’t model objects around the presentation

Model your object around the real world business, not around the implementation of the user
interface. When you design your objects around a UI model, you can’t reuse them in other
applications.

Develop business objects independent of the GUI

This is one way to ensure that you are developing business objects isolated from presentation. Don’t
even allow yourself to think about the GUI until you’ve identified your business objects and their
associated behavior. Once the development team agrees on public properties and methods, you can
begin developing the GUI against those properties and methods.

Don’t talk directly to GUI

If you build objects that communicate directly to the GUI, you can’t reuse them in other applications.
As soon as you say Form1.Label1.setCaption (“Save Worked”) the code becomes non-portable and
you lose any hope of reuse. If you need to inform the user of something, or talk to a user, do so
though an object designed for that purpose. Users can then customize the way that the application
talks to them.

PAGE 9
Make the business object responsible for enforcing
the rules
If the business rule isn’t enforced by design, the decision is not being enforced in the object.
Whenever you assign business rules to objects, make sure you comment in the object where it’s
enforced, and why it’s enforced there. Suppose you have a stored procedure that gathers a lot of
information from the database, then returns true or false to indicate whether you can proceed or not.
Because you’re reading a lot of data at the database quickly, placing the code there is a good choice.
A programmer looking at the business object should be able to know where its rules are enforced
and why.

Hide the implementation from the GUI

The published interface of an object describes what the component does. The client doesn’t have
(and in most cases should not be able) to discover from the published interface how the data is
stored or retrieved. You should be able to change the internal implementation of the rules and data
access without affecting the object’s public interface at all. There may be cases where public
interfaces defined in an abstract class are implemented in totally different ways by each of the class
descendants. The way you implement a business object that hits a particular platform-specific SQL
database or database table may be different, but the GUI can remain the same, since it’s interacting
with the published interface, not the details of implementation.

Don’t have “technical” public methods

Unless the real world object has a concept called openTables(), resizeArray() or flushCache(), your
object shouldn’t contain these methods.

Objects should hide all of the technical details of

how they’re implemented
If the object hides the details of its implementation, then getCustomer() may open the tables or
transferAccount() may delete a record, update a summary table and insert a record in another table.

CALL 877.667.6070 OR +1.757.420.7500 OR VISIT WWW.OOP.COM FOR MORE INFO. JFRAMEWORK, HAMMOCK,
PAGE 10
WEBESP, AND ELIMINATE THE LIMITS ARE TRADEMARKS OF JAVA BUSINESS SOLUTIONS, DBA OOP, AND JAVA IS
A REGISTERED TRADEMARK OF SUN M ICROSYSTEMS, INC. IN THE UNITED STATES AND OTHER COUNTRIES.