Wizard API updated!
Tim Boudreau has released a new version of the Swing Wizard library (version 0.997) that fixes the WizardException bug reported in JavaWorld's recent Open Source Java Project profile. The article's examples have been reworked to test out the new, improved WizardException. Thanks, Tim, for this helpful fix!
Open Source Java Projects: The Wizard API

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters

Email Address:

Search business objects in enterprise applications using J2EE

J2EE design patterns can help you add a search component to your applications

Search serves the purpose of retrieving a view or list of already persisted instances of business objects for a business scenario. For example, in a bank account system, a typical search would be, List all transactions made during January through June in the years 2000 through 2004 for amounts involving 0,000 or more for all California customers. This search involves a set of related business objects such as customer, credit, debit, transaction, state, account type, and so on. For a medium-sized California bank, this search could retrieve a large result set involving at least a million records. The main difference between the search defined here and transaction handling is that transaction handling works on one business component (a set of business objects linked as a tree), called the model's instance, whereas search typically works with a group of business objects (instances) mainly needed for display/read-only purposes for the clients to see before acting on the results. Now J2EE provides some design patterns to do these types of complex searches.

Even when J2EE was not popular, developers had to endure this problem of searching numerous business objects in enterprise applications. They used JDBC (Java Database Connectivity) calls and wrapped RowSets to develop the search application component in Java. The need for a search component in enterprise applications comes mainly from the usage of relational databases for persistence.

Designing an object-oriented multitiered enterprise application has its challenges in the usage of relational database management systems or any non-object-oriented system as the persistent layer. Enterprise application designers like to use relational database systems because of their maturity. Relational databases are also successful for numerous other reasons, such as volume-handling, transaction-handling, and EAI (enterprise application integration). Object-oriented database management systems (OODBMS) are sparse and also not popular in the industry.

When designing object-oriented systems in Java using relational databases as the persistence mechanism, we abstract business as Java business objects and represent the business objects as tables in relational databases. In J2EE, this abstraction is data access objects (DAO), entity beans, and (sometimes) session beans. The persistence layer (tables) falls below this abstract layer, which is controlled either programmatically using bean-managed persistence (BMP) or, leaving it to J2EE, as container-managed persistence (CMP). This allows J2EE application designers to work without bothering with persistence code; thus, they develop robust enterprise applications using object-oriented methodologies, worrying little about the persistence mechanisms.

Many discussions and articles are available on the transaction-handling systems and OLTP (online transaction processing) systems, but few cover this niche area of search, where doing it the J2EE way could improve your application in terms of response time, security, memory management, and design-patterned code that looks neat and maintainable—which means a lot to us techies.

1 | 2 |  Next >

Discuss

Start a new discussion or jump into one of the threads below:

Subject Replies Last post
. PCMcZDLJDCxet
By usa dollar
0 03/29/08 03:26 PM
by Anonymous
. Search business objects in enterprise applications
By JavaWorldAdministrator
1 03/01/06 10:43 PM
by JavaWorld


Resources