This figure illustrates an example of a multi-tier configuration.
BC4J provides a standards-based, server-side framework for
creating scalable, high-performance Java 2, Enterprise Edition (J2EE ™)
applications. It includes design-time facilities and runtime services to simplify
the tasks of building, debugging, customizing, and reusing business components.
Applications developed with BC4J can be deployed on any J2EE platform and can
be accessed from a wide variety of clients including Web browsers, professional
desktop clients, XML clients, and wireless devices.
The framework handles common development cases with built-in
behavior, and you can take advantage of these benefits without compromising
your ability to control the way your application works. Any behavior provided
by the framework can be easily overridden in your domain-specific components
with a few lines of code, so you are never locked in to a certain way of doing
things.
In general terms, entity objects encapsulate the business
policy and data for the logical structure of the business, such as product lines,
departments, sales, and regions business documents, such as invoices, change
orders, and service requests physical items, such as warehouses, employees,
and equipment. Specifically, an entity object stores the business logic and
column information for a database table (or view, synonym, or snapshot). You
can create entity objects from existing database tables (reverse generation)
or define entity objects and use them to create database tables (forward generation).
A view object uses a SQL query to specify filtered subsets
of business data that can be related to attributes from entity objects. You
create views based on what the client needs to display. The views of data can
be based on but are independent of the underlying entity objects, enabling flexible
data retrieval to support the required UI. In other words, you can query a set
of data exactly as you want to show it in the display. The view object defines
the attributes of the view row class, which represents a row in the query result,
and optionally refers to underlying entity objects.
View objects provide clients with row sets they can scroll
through and update without concern for or knowledge of the underlying entity
objects. Clients manipulate data by navigating through the result set, getting
and setting attribute values; changes are made to the data in the underlying
database when the transaction is committed. Relationships between view objects
are expressed using view links. Each view object provides a default iterator
that you can use to navigate through its result set. For example, the following
figure shows the relationship between a view object, entity object, and the
underlying database table. A view object named EmpNames operates on the Emp
entity object to provide a view of the EMPNO and ENAME columns of the EMP table.
By eliminating the substantial coding and testing
work related to common "application plumbing" facilities, BC4J lets
application developers focus full-time on implementing business solutions. The
benefits of using this framework include reduced development cost, lower project
risk, and shorter time-to-market.
Design Patterns Overview
Design patterns, which represent proven solutions to recurring
problems, have their roots in the writings of Christopher Alexander, an architect
(of buildings, not software) who in the late 1970s formalized a way to describe
patterns for building better rooms, buildings, and cities. In the 1990s, when
applications based on distributed objects were deployed in unprecedented numbers,
software developers found themselves wrestling again and again with issues like
memory leaks and performance bottlenecks, and interest in design patterns surged.
Design patterns continue to emerge as communities of developers
solve problems and share what they've learned. Some of these problems arise
because client- and application-objects are at opposite ends of the network.
To carry out a workflow, for example, client objects must make numerous remote
calls to access the EJBs, leading to increased network traffic and reduced performance.
A number of design patterns solve such problems by means of a façade,
a programmatic false front presented to clients. One popular pattern, the Session
Façade, presents client objects with a unified interface to the underlying
EJBs. Client objects interact only with the façade, which resides on
the server and invokes the appropriate EJB methods, reducing network traffic.
Other design patterns describe ways to package objects and
data to optimize efficiency. The Value Object design pattern (also known as
Data Transfer Object) describes a container for a set of related data. It is
often (but not necessarily) used with the Session Façade pattern to reduce
network traffic and the number of method calls required to get an entity's attribute
values. For example, when a customer orders a product online, the application
may generate an order comprising several attributes including order ID, order
date, customer name, and shipping address. To retrieve the details of an order,
an application that does not implement the Value Object pattern would have to
make a remote get method call for each attribute (examples: order.getID, order.getDate),
adding to network traffic and increasing EJB container resource usage.
Another example is the Data Access Object (DAO) design pattern,
which avoids unnecessary marshalling overhead by implementing dependent objects
as lightweight, persistent classes instead of each as an Enterprise Bean. The
DAO pattern gives clients an interface to a data source while hiding the implementation
details. Also, a Data Access Object class can provide access to a particular
data resource without coupling the resource's API to the business logic. The
data source could be any of the following:
- Persistent store (example: RDBMS)
- External service (example: B2B exchange)
- Repository (example: LDAP database)
- Business service accessed via CORBA IIOP or low-level sockets
The DAO acts as an adapter between the client and the data
source, exposing a consistent interface regardless of the underlying data source.
This design pattern enables an application to use different storage schemes
without affecting its clients, and separates business logic from data access
logic.
About BC4J and Design Patterns
At its core, BC4J is a metadata-driven Data Access Objects
framework. It provides time-saving features that add value in all of the tiers
of the J2EE application architecture:
-
Business Logic Tier. BC4J simplifies
producing EJB Session Beans for efficient business services supporting either
Container-Managed or Bean-Managed transactions. These Session Beans implement
the Session Façade pattern, and wrap access to efficient, lightweight
Data Access Objects that expose Fast-Lane Reader SQL views and implement
object/relational persistence.
-
Web Tier. BC4J provides declarative data-binding
for JSP pages using a generic tag library that works in tandem with the
BC4J Data Access Objects. These same DAO's also simplify XML-based business
integration through native support for reading and writing XML datagrams
from any view or hierarchical set of related views of data.
-
Client Tier. BC4J provides declarative
data-binding for rich JFC/Swing displays through a set of pre-built Swing
models and a large number of pre-built data-bound Swing controls.
The following figure shows the architecture of a typical J2EE
application built using BC4J.
The figure describes a simple Payment Terms Management application,
assembled from the core BC4J framework components:
-
Entity Objects like Customer, Bill, and
Payment are lightweight Data Access Objects that are designed to encapsulate
business logic that is shared across applications and handle database persistence
for your business entities,
-
View Objects like SlowPayingCustomers and
LatePayments are companion Data Access Objects that assist in joining, filtering,
projecting, and sorting your business information using the full power of
SQL for the specific needs of a given application scenario or task. View
objects can be used on their own to provide efficient, read-only data access
using SQL, or they can be used in cooperation with entity objects to provide
fully-updatable views of information joining data from any number of underlying
business entities.
-
Associations relate and compose entity objects
to capture important relationships and expose them for easy programmatic
navigation. For example, code in the Bill entity class can easily call getCustomer
to retrieve its related Customer instance, and getPayments
to retrieve the collection of related Payment instances.
-
View Links are used to build hierarchies of
master-detail queries to support sophisticated user interfaces and XML datagram
structures, and finally
-
Application Modules like PaymentTermsManagementApp
provide a Model/View/Controller application object implementation, conveniently
exposing a complete data model for a given application task. Application
modules can contain both process and business logic that is specific to
a particular application task. Application modules are deployed as EJB Session
Façades that wrap access to the other data access objects in the
framework. These Session Beans can support either Bean Managed or Container
Managed transactions and can be deployed to J2EE application servers like
Oracle9iAS and WebLogic.
Final note: In their quest for patterns, developers have also
discovered antipatterns, strategies
that have been shown not to work. It's tempting to think of an antipattern
as a pattern's evil twin, but antipatterns are just as valuable. If a design
pattern can save you from reinventing the wheel, an antipattern can save you
from reinventing the Yugo.
Bookmark
