Chapter 8 Introducing ADF Business Components

1
Chapter 8Introducing ADF Business Components
2
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.

3
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).

4
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.

5
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
  SQLPlus 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.

6
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.

7
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.

8
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.

9
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.

10
ADF Business Component Groups

• ADF BC components are divided into two groups
• Business domain components
• Data model components

11
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

12
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.

13
Entity Object Definitions

• Example DEPARTMENTS table
• Entity objects for the above table may have the
  following entity attributes

14
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
• A Java class (like DepartmentsImpl.java) This
  contains the procedural code to implement the
  entity object.
• 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.

15
ADF BC Relationships (page 228)
16
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.

17
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.

18
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

19
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.

20
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_IDEmployees.EMPLOYEE_ID
This view object would have the following view
attributes
21
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
• A Java class (like ManagerViewImpl.java) This
  class handles the complex logic or the queries,
  controlling the client's access to the data.
• An XML file (like ManagerView.xml) This stores
  information about the query and its
  relationships to entity objects.

22
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.

23
View Link Definitions (continued)

• For example
• A view object, DepartmentsView, containing the
  following query
• Another view object, EmployeesView, containing
  the following query
• A view link, DeptEmpFkLink, that associated the
  DepartmentId attribute of EmployeesView with the
  DepartmentId attribute of DepartmentsView.

SELECT Departments.DEPARTMENT_ID,
Departments.DEPARTMENT_NAMEFROM DEPARTMENTS
Departments
SELECT Employees.EMPLOYEE_ID,
Employees.FIRST_NAME, Employees.LAST_NAME,
Employees.DEPARTMENT_ID, FROM EMPLOYEES
Employees
24
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).

25
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.

26
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 master-detail
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.
27
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.
28
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.
29
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.

30
The hands-on practice beginning on page 234
examines a default ADF BC layer.
ENJOY!