Using Business
Objects to handle data-storage and retrieval.
This
document deals with the scheme how data is transferred between client
and JAS (Java Application Server).
As a 'side-task' this document
starts with the explanation how data is stored when the database is
situated on the local machine and the application is not a
'Fat-Client' but a 'Stand-Alone' where data-access is limited to a
single workstation (where the application and the database is
running).
N.B.
This document refers mainly to the scheme of developing a Fat-Client
as described by the documents indexed in this
document.
Why
design a business-object (and not something that reflects a
database-table) :
Business-Objects
reflect more complex data-structures than one database-table can do:
With
a Business-Object, data of it can be stored in several database
tables – and will be with the exemption of very simple
Business-Objects.
For
example, the Business-Object of a 'Invoice' may consist of the
following 'areas', where the data of each 'area' is stored in its own
(relational) database-table (DB-table).
Please
keep in mind that the scheme is very simplified.
The
Business-Object is a structure, that contains all data belonging to a
defined entity – no matter over which database-tables this data
is distributed.
This makes the Business-Object a model that is
closer to the business-model than keeping the data from several
database-tables together and synchronized.
As the Business-Object
can have methods implemented (as any object in Java), there can be
methods designed that retrieves data from several databases and
stores new oder changed data on the adjacent database-tables.
These
methods should also include, that the data that should be written is
checked for consitency.
Concluding
remarks:
My argumentation may not be true for the usage of
Object-Databases.
But compared to relational databases,
Object-Databases are not available for every operating system.
Also,
if one vendor of an Object-Database is choosen and and the code for
an application is adapted for this special Object-Database, it is
impossible to change to the Object-Database of another vendor without
changing the code. (This
was true at the time of writing this document and might have changed
inbetween:)
In my opinion, the decision to
choose a Object-Database over a relational database should be well
founded; particularly as it ties the application close to the future
development of the vendor of the database.
top.
Business-Objects
can have methods that check the validity of the attributes within the
structure:
As
mentioned in the paragraph above, Business-Objects have methods
implemented.
This allows complex validity checks before the first
database-table is updated.
A
right designed application will route every change of data onto a
database-table over the fitting Business-Object.
This
Business-Object will verify the data for consitency before it calls
the method to insert or update one ore more database-tables.
Example:
When
a product should be deleted the Business-Object for 'Product' can
cross-check if this product is in a pending-status; i.e. It is
ordered from a vendor but did not arrive at stock till now.
In
that case - and if the product really should be deleted – the
order has to be cancelled first.
top.
Java
can transfer this complex structure over a network:
Java
has a functionality called Remote Management Invocation (RMI) that
allows to transfer a Java-Object (no matter how complex it is) over a
network with TCP/IP-protocol.
RMI
never has to be called directly when developing an application. It is
hidden in the mechanism that transfers EJBs (Enterprise Java Beans)
between a Java Application Server (JAS) and the Client-Application.
N.B.:
If
you ever worked with CORBA (Common Object Request Broker
Architecture) you will realise that defining Business-Objects and let
Java to the transfer over a network is an advantage that is
lightyears ahead over CORBA.
Example:
The
Client-Application can send an unique identifier (e.g. the
Invoice_Number) to the Server-Application (the EJB running on the
JAS).
In
the Server-Application, objects for
database-access 'collect' the requiered data and build the
Business-Object.
The Business-Object is send over to the
Client-Application and its data is displayed on the screen.
The
values can be altered and the Business-Object with the altered data
is sent back to the Server-Application.
There it is checked for
validity, objects for database-access take their part of the
variables and update the database-tables.
top.
How
copying between Server-Side and Client-Side is done:
Java
has a functionality called Remote Management Invocation (RMI) that
allows to create a Java-Object (no matter how complex it is) over a
network (with TCP/IP-protocol) and call its methods.
By passing
values as parameters to the methods, data can be transferred over the
network.
RMI
never has to be called directly when developing an application. It is
hidden in the mechanism that transfers EJBs (Enterprise Java Beans)
between a Java Application Server (JAS) and the Client-Application.
The
ability to subclass makes it possible, that the method
'copyFrom_xxx_yyyy_BO()' - implemented in the 'general class' is also
available in the subclasses.
Therefore, data from the Server-Side
Business Object can be copied to its Client-Side 'twin'
whenever requested by the Client-Side Business Object.
Vice versa,
the Client-Side Business Object can request the 'Construction' of a
Server-Side Business Object and pass itself as parameter.
The
constructor-method of the Server-Side Business Object calls the
method 'copyFrom_xxx_yyyy_BO()'
and transfers the values of the passed Client-Side Business Object to
itself.
After the construction, the Client-Side Business Object
may call a method to update the database.
N.B.:
If
you ever worked with CORBA (Common Object Request Broker
Architecture) you will realise that defining Business-Objects and let
Java to the transfer over a network is an advantage that is
lightyears ahead over CORBA.
top.
Related
Documents:
Detailed
descriptions concerning Business Objects can be found in the
following documents: