Download Chapter 8 Introducing ADF Business Components

Chapter 8
Introducing ADF Business
Components
1
Introducing ADF Business Components
ADF BC is a Java and XML based framework for developing:
• Business logic, including validation and default logic
• Queries
• Transaction handling
• Data access
It does not create a user interface, but is a pure encapsulation of business
logic that communicates with a separate client application, which handles
user interaction.
Using ADF BC is the simplest way to design data-aware applications
with JDeveloper. This chapter presents an overview of ADF BC by
describing its components and uses.
2
Why Use ADF BC?
The advantage of ADF BC over UI-enforced business logic is reusability.
For example, a single ADF BC layer can provide the business logic for all
a company's needs. The business components can be used again and
again, with multiple interfaces (a time saver).
3
Advantages of ADF BC
By maintaining a cache of data in memory, ADF BC reduces the number
of database trips required by an application resulting in improved
performance and scalability.
ADF BC allows the business logic to be written in Java, which saves the
trouble of integrating a Java GUI or JSP application with business logic
written in PL/SQL code.
Removing the business logic out of the database keeps the database
from handling anything but data, which increases an application's
modularity and efficiency.
4
Advantages of ADF BC (continued)
There are also advantages to implementing some business logic directly
in the database (more robust) since it will be enforced even in a
SQL*Plus session. Business logic implemented in the ADF BC layer is
only enforced in applications using that layer, but increases performance.
There is a trade-off between robustness and performance.
Therefore, the most critical business logic should be implemented in the
database or redundantly in both the database and a ADF BC layer. The
remainder of the business logic can be implemented in the ADF BC
layer.
5
Advantages of ADF BC (continued)
ADF BC provides four ready-made architectures for business
component clients:
• JClient, an architecture for creating Java GUIs (useful for intensive
data-entry applications requiring high interactivity).
• Thin JSP clients are useful for web-based applications where a
thin client is more important than very high interactivity, such as
self-service and e-commerce applications.
• XSQL clients, which generate XML for either flexible display with
a style sheet or loose coupling between applications.
• UIX, a framework-based architecture for developing web
applications.
6
Advantages of ADF BC (continued)
ADF BC also has the advantage of being "deployment-configuration
independent". A single ADF BC layer can be deployed as local Java
classes or as an Enterprise JavaBean (EJB), with no rewriting of code
necessary. You can concentrate on the business logic of your application
instead of its deployment requirements.
ADF BC components (whether deployed to a J2EE web module with
JSP pages or as an EJB) are fully J2EE-compliant. The ADF BC
framework automatically implements the J2EE BluePrints design
patterns suggested by Sun Microsystems so you do not need to worry
about them.
7
Business Components, Java, and XML
Entity objects, view objects, and application modules each have two
parts: a Java class file and an XML file. The files have different purposes.
ADF BC is a framework, this means that much of its functionality is
contained in a set of libraries. ADF BC classes extend (subclass) the base
classes provided by these libraries to provide complex business logic,
which requires the procedural power of Java to implement. This allows
you (if needed) to:
• Easily write code to implement complex business rules inside your
entity object Java classes
• Code complex query logic in your view object classes
• Code complex transaction handling in your application module
classes.
8
Business Components, Java, and XML
The base classes in the ADF BC framework are programmed to work
with XML files. Some business logic is common and simple and can be
handled with a line or two of declarative XML. Instead of writing a
procedure to implement this sort of business logic, you can just declare
that an entity attribute, for example, must obey a particular validation
rule. The base entity object class (and by inheritance, your custom Java
class) can automatically read the XML file to enforce the rule.
JDeveloper has wizards that write and edit the XML files for you.
The ADF BC framework uses XML files to store static definitions such
as the structure of a database table or query. Its base classes can obtain
the structure of particular business components by parsing the XML.
This can have performance advantages. For example, an entity object
dose not need to query the database at runtime for structural
information about the table it represents.
9
ADF Business Component Groups
ADF BC components are divided into two groups:
• Business domain components
• Data model components
10
Business Domain Components
These components represent features of the database: tables and views,
constraints, and relationships. They are the most reusable business
components because they can be used by any application that needs to
access the same data.
There are three kinds of business domain components:
• Entity Object definitions
• Associations
• Domains
11
Entity Object Definitions
An entity object definition usually represents a database table or database
view, but it can also be used to represent EJB entity beans. It acts as a
representation of the table or database and handles all of the business
rules for that table or view including validation, defaulting, and anything
else that happens when a row is created, deleted, or changed.
The power of ADF BC is its interface with the database used by an
application.
The ADF BC layer represents the database table as an entity object. An
entity object has entity attributes that represent the table columns
(mapping may not always be one-to-one).
The types of the properties are Java classes that correspond to the SQL
types of the columns.
12
Entity Object Definitions
Example: DEPARTMENTS table
Entity objects for the above table may have the following
entity attributes:
13
Entity Object Definitions
Java does not directly support SQL datatypes, but each SQL datatype can
be mapped to a Java type. Some Java types are classes in java.lang and
others in the package oracle.jbo.domain (discussed later).
Entity objects have two parts:
1. A Java class (like DepartmentsImpl.java) – This contains the
procedural code to implement the entity object.
2. An XML file (like Departments.xml) – This includes metadata
describing the entity object, its attributes, and the table upon
which it is based, as well as declarative code.
14
ADF BC Relationships (page 228)
15
Associations
Like tables, entity objects are often related to one another. The
relationships between entity objects are called associations. An
association matches one or more attributes of a "source" entity object
with one or more attributes of a "destination" entity object.
This is like a foreign key constraint that matches one or more columns
of a child table with one or more columns of a parent table.
Associations are stored in an XML file.
16
Domains
Domains are special java types used by ADF BC as the types for many entity object
and view object attributes. In the coverage of entity objects earlier, a class that
implements the Departments entity object has some entity attributes of type
oracle.jbo.domain.Number. The entity attributes of an entity object Java class are
objects, not primitive Java types such as int.
Database columns of SQL datatype VARCHAR2 have the Java class
java.lang.String. For other SQL types (NUMBER, etc.), ADF BC provides domains
to wrap the SQL datatype. Domains like oracle.jbo.domain.Number are basically
object wrappers for scalar types.
JDeveloper will automatically create a domain if you base an entity object on a table
with an Oracle object type column in it. This domain represents the Oracle object
type, giving you Java wrappers for each of the object type's fields and methods.
You can also create your own domains.
17
Data Model Components
They are business components that collect data and present it to the
view and controller through the ADF model layer. They are not
reusable as business domain components because their design is based
on the data needs of a particular client application.
They are still independent of a user interface.
There are three kinds of data model components:
• View object definitions
• View link definitions
• Application module definitions
18
View Object Definitions
Generally you should not present all of the information stored in a
database object (entity object) in one application. You may also
want/need data taken from more than one database object.
SQL provides the queries necessary to select exactly the data you need
from one or more tables. This is why ADF BC has view object
definitions, which correspond to SQL queries. A view object
definition actually stores a SQL query.
19
View Object Definitions (continued)
A view object definition has view attributes (like entity objects have
entity attributes) that correspond the columns of a query result. For
example, consider the view object for the following query:
SELECT Departments.DEPARTMENT_ID,
Departments.DEPARTMENT_NAME,
Employees.EMPLOYEE_ID,
Employees.FIRST_NAME,
Employees.LAST_NAME
FROM
DEPARTMENTS Departments, EMPLOYEES Employees
WHERE Departments.MANAGER_ID=Employees.EMPLOYEE_ID;
This view object would have the following view attributes:
20
View Object Definitions (continued)
The above view attributes may be (but not required to be) associated
with attributes from entity objects.
View objects have two parts:
1. A Java class (like ManagerViewImpl.java) – This class handles
the complex logic or the queries, controlling the client's access to
the data.
2. An XML file (like ManagerView.xml) – This stores information
about the query and its relationships to entity objects.
21
View Link Definitions
A View link represents a relationship between the query result sets of
two view objects. It associates one or more attributes of one view
object with one or more attributes of another.
22
View Link Definitions (continued)
For example:
A view object, DepartmentsView, containing the following query:
SELECT Departments.DEPARTMENT_ID,
Departments.DEPARTMENT_NAME
FROM
DEPARTMENTS Departments
Another view object, EmployeesView, containing the following query:
SELECT Employees.EMPLOYEE_ID,
Employees.FIRST_NAME,
Employees.LAST_NAME,
Employees.DEPARTMENT_ID,
FROM
EMPLOYEES Employees
A view link, DeptEmpFkLink, that associated the DepartmentId attribute of
EmployeesView with the DepartmentId attribute of DepartmentsView.
23
View Link Definitions (continued)
DeptEmpFkLink represents a master-detail relationship between the
query result sets of DepartmentsView and EmployeesView.
View links between view objects can be (but do not have to be) based
on associations between underlying entity objects. A view link is
represented in an XML file (more on this in later chapters).
24
Application Module Definitions
An application module is a container for view usages (instances of
view objects). It lists all of the view usages your application requires
and specifies how they are related by view links. These relationships
can be represented by a tree (application module's data model).
For example, an application module might contain usage of
DepartmentsView, called AllDepartments, and a usage of
EmployeesView, called DepartmentEmployees, linked by an
instance of EmpDeptFkLink, called DepartmentToEmployees.
25
Application Module Definitions (continued)
This uses the following data model:
Using this model, the two view usages are tied together by a link representing a masterdetail relationship between them (EmpDeptFkLink). Using this application module,
your client application could select a row in AllDepartments, and the ADF BC
framework would immediately synchronize DepartmentEmployees so that it would
only return employees from the selected department.
26
Application Module Definitions (continued)
Your application module could contain a usage of DepartmentsView
and a usage of EmployeesView without using EmpDeptFkLink, as
in the following data model:
This module provides usages of the same two view objects, but the view
usages are linked. Your client application could select rows in
AllDepartments and Allmployees usages independently.
27
Application Module Definitions (continued)
You can even include two instances of EmployeesView in an application module:
one a detail of an instance of DepartmentsView and one independent as in the data
model below:
With this application module, a client application could select rows in
DepartmentEmployees and have them automatically synchronized with
AllDepartments and could also select rows in AllEmployees independently.
28
Application Module Definitions (continued)
An application module definition is a template for application module
instances, which are individual copies of the data model used by
particular instances of the application. Each instance represents an
individual database transaction.
29
The hands-on practice beginning on page
234 examines a default ADF BC layer.
ENJOY!
30