ADF Business Components

This section provides a high-level overview of ADF Business Components, including a description of the key features they provide for building your business services. Features described include entity objects, view objects, and application modules.

This section includes the following topics:

About ADF Business Components

Oracle ADF architecture is based on Model-View-Controller (MVC) design pattern that consists of four layers – Model, View, Controller, and Business Service. The Business Service layer is supported by the ADF Business Components, which is a framework for managing transactions with data sources and is integrated with JDeveloper tools.

ADF Business Components is a technology to create reusable data-aware business services with minimal developer coding. Developers can use wizards and visual editors to create ADF Business Components services without writing any Java code. It is also possible to extend the core ADF Business Components classes to create more advanced functionality. ADF Business Components services are exposed through ADF Model for use by the application's view layer.

Figure 1-131 shows how ADF Business Components fit into the ADF technology stack. Note that ADF Business Components features directly integrate with ADF Model.

Figure 1-131 ADF Architecture with Business Components

Description of "Figure 1-131 ADF Architecture with Business Components"

In addition, you can expose applications that you create with ADF Business Components as services that can be consumed by other Fusion web applications, composite applications that adhere to the Service Component Architecture (SCA), and other applications via web service calls.

Core Benefits of ADF Business Components

Tight integration with JDeveloper tools simplifies building the business service layer of the Fusion web application. The resulting business objects based on the ADF Business Components framework support managing data transactions at application runtime.

ADF Business Components provides the following benefits for developers of business services:

Management of database access, including connection, data retrieval, locking of records, and insertion and update of records.
Ability to create data models that are tailored for specific types of end users, with only the necessary data exposed.
Creating of data model relationships in addition to those defined by the database.
Ability to use declarative rules to enforce required fields, primary key uniqueness, data precision-scale, and foreign key references.
Capturing and enforcing both simple and complex business rules, programmatically or declaratively, with multilevel validation support.
Implementing end-user Query-by-Example data filtering without code.
Ability to expose components as services that can be integrated with other Fusion web applications and consumed by SOA composite applications.
Ability to raise business events to launch business processes and trigger synchronization of external systems.
A built-in facility for application state management that enables application failover and the handling of user sessions over multiple nodes in clustered and high availability server environments.
Features geared toward performance optimization, such as shared application modules to handle static data and application module pooling.
Wizards and visual editors in JDeveloper that generate XML definitions for the components that you can also edit manually.

Key Concepts of ADF Business Components

The ADF Business Components framework supports modeling data sources for use in Fusion web applications based on declarative business objects that define object hierarchies (master-detail relationships) and that shape the data for display to the end user through application-specific views. The framework manages CRUD (create, read, update, delete) transactions at application runtime with a minimum of coding required.

ADF Business Components is an implementation of Java-based business services that directly incorporate ADF Model. This section provides an overview of the role of business services and how ADF Business Components implements business services.

Implementation of Business Services

Business services are behind-the-scenes components that mediate between an MVC application and a data source (usually a database). In general, business services are responsible for the following tasks:

Retrieving data requested by the rest of the application
Representing this data as Java objects usable by the rest of the application (object-relational ["O/R"] mapping)
Persisting changes made by the rest of the application
Implementing business rules, such as validation logic, calculated attributes, and defaulting logic
Providing services that can perform large-scale batch operations on data upon request

Business services segregate the persistence and business logic of an application from the logic that governs the application's UI and control flow. Keeping persistence and business logic separate allows you to reuse them in multiple MVC applications.

Based on Standard Java and XML

ADF Business Components is a framework implemented in Java. Base framework classes provide generic, metadata-driven functionality. XML files store metadata that you define to configure each component's runtime behavior. You can also extend the base framework functionality to suit your needs.

Figure 1-132 shows the Applications window in JDeveloper and how it represents the files that comprise ADF Business Components services. For example, the DeptVO component is defined with a single XML file that relies entirely on underlying framework classes. On the other hand, the CustomerVO definition consists of an XML definition file that provides metadata and three Java classes that extend the underlying framework classes.

Figure 1-132 XML and Java Objects for ADF Business Components

Description of "Figure 1-132 XML and Java Objects for ADF Business Components"

Figure 1-133 shows the source editor for an ADF Business Components view object definition file.

Figure 1-133 Source View for an ADF Business Components Definition File

Description of "Figure 1-133 Source View for an ADF Business Components Definition File"

JDeveloper also provides visual overview editors for ADF Business Components definition files. Figure 1-134 shows the overview editor for the same view object definition file shown in Figure 1-133.

Figure 1-134 Overview Editor for an ADF Business Components Definition File

Description of "Figure 1-134 Overview Editor for an ADF Business Components Definition File"

Application Server and Database Independence

Because ADF Business Components services are implemented using plain Java classes and XML files, applications and services built using ADF Business Components can run on any Java-capable application server, including any Java EE-compliant application server. These applications and services can be run both within and outside of a Java EE server container.

You can use ADF Business Components components with both Oracle and non-Oracle databases. Numerous optimizations are built into ADF Business Components for use with Oracle databases.

Declarative Metadata for Implementation Classes

ADF Business Components objects are based on a set of Java classes that provide built-in runtime functionality that you control through declarative settings. You use an XML component definition file to specify metadata for things like object/relation mapping for database tables, data access methods, and validation rules. At runtime, the metadata is injected into the implementation classes to create instances of the services. For typical use cases, developers do not have to write any Java code to implement the services.

Optional Custom Java Code

It is possible to further configure the behavior of a component by adding custom Java code to the component's definition. When you need to write custom code for a component, for example to augment the component's behavior, you can enable an optional custom Java class for the component in question.

Ability to Expose Services to SOA Applications

After you have developed ADF Business Components services, you can publish them as external services that can be consumed by applications that are based on a service-oriented architecture (SOA). For more information, see Service-enabled Application Modules.

Application State Management

ADF Business Components has a state management facility for application modules that enables you to save the state of a user session, which simplifies recovery and failover scenarios.

For more information on application module state management, see Application State Management.

Key Components of ADF Business Components

The business service layer of the Fusion web application based on ADF Business Components is comprised of entity objects to model the data source (including support for object hierarchies, such as master-detail relationships) and view objects to shape the data for display to the end user through application-specific views. Other components include application modules which support CRUD (create, read, update, delete) transactions on specified view objects at application runtime.

The ADF Business Components architecture consists of the following key components:

Entity objects, which encapsulate individual objects in a data source, such as tables in a database, and which add business logic for working with that data.
Entity associations, which define the relationships between individual entity objects.
View objects, which provide access to data in a form that can be used through ADF Model bindings in a user interface. View objects that allow updating of data are based on entity objects.
View links, which define master-detail hierarchies between view objects.
Application modules, which encapsulates the view objects needed for a logical unit of work related to an end-user task.

Entity Objects

ADF entity objects are business components that encapsulate data, persistence behavior, and business rules for items that are used in your application. For example, entity objects can represent:

Elements of 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

Entity objects map to single objects in the data source. In the vast majority of cases, these are tables, views, synonyms, or snapshots in a database. For example, you might create an entity object called Departments that represents a database table called DEPARTMENTS. Advanced programmers can base entity objects on objects from other data sources, such as spreadsheets, XML files, or flat text files.

Figure 1-135 shows how an entity object fits in with other objects in an ADF Business Components application.

Figure 1-135 Entity Object Within the ADF Business Component Architecture

Description of "Figure 1-135 Entity Object Within the ADF Business Component Architecture"

Entity Object Definition Files

When you use JDeveloper's wizards and visual editors to create and configure an entity object, JDeveloper creates an XML file that contains the declarative metadata that defines the runtime behavior of that entity object, including its O/R mapping, validation rules, UI hints, and other metadata. At runtime, this metadata is injected into an instance of the generic framework class oracle.jbo.server.EntityImpl.

It is also possible to add custom functionality to an entity object by writing custom classes that extend ADF Business Components framework classes.

Ways to Configure Entity Objects

Entity objects are part of ADF Business Components implementation of ADF Model. As such, you can add declarative metadata to an entity object definition to configure its behavior. The following are some of the things for which you can set metadata on an entity object:

UI hints, which are settings that the view layer can use to automatically display the queried information to the user in a consistent, locale-sensitive way.
Validation rules, which you can set at both the level of entity objects or individual attributes.
Business events, which you can use to launch business processes and trigger external systems synchronization.

Entity Associations

Relationships between entity object definitions are handled by entity associations, which define a relationship between two entity object definitions based on sets of entity attributes from each. Associations map to relationships between single objects in the data source. In the vast majority of cases, these are relationships among tables, views, synonyms, and snapshots in a database. Advanced programmers can use associations to represent relationships within other data sources, such as spreadsheets, XML files, or flat text files.

When the data source is a database, associations often map to foreign key relationships between tables in the database. Although there does not need to be a foreign key constraint between tables for you to create a one-to-one or one-to-many association between the corresponding entity objects, there should be an appropriate logical relationship between the tables.

View Objects

ADF view objects are business components that collect data from the data source, shape that data for use by clients, and allow clients to change that data in the ADF Business Components cache. Among other things, a view object definition can gather the information needed to:

Populate a single table element in a form
Create and process an insert or edit form
Create a list of values for populating a dropdown list
Create a search form with specific search criteria

Once you have created a view object definition and included it in the data model of an application module, you use the Data Controls panel to create UI components based on the collections, attributes, and operations of that view object.

Figure 1-136 View Object Within the ADF Business Component Architecture

Description of "Figure 1-136 View Object Within the ADF Business Component Architecture"

View object definitions must have a mechanism for retrieving data from the data source. Usually, the data source is a database, and the mechanism is a SQL query. ADF Business Components can automatically use JDBC to pass a query to the database and receive the result. When view object definitions use a SQL query, query columns map to view attributes in the view object definition. The definitions of these attributes reflect the properties of these columns, such as the columns' data types and precision and scale specifications. When view object definitions use other data sources, view object attributes map to "columns" of data from those data sources, as defined by the programmer.

Typically, when you work with a view object, you work with only a single row set of results at a time. To simplify this use case, the view object contains a default RowSet, which, in turn, contains a default RowSetIterator. The default RowSetIterator allows you to call all of the data-retrieval methods directly on the ViewObject component itself, knowing that they will apply automatically to its default row set.

In addition, you can declaratively define view criteria for a view object. With a view criteria, you specify query conditions that augment the WHERE clause of the target view object in order to filter the results. You can then use those view criteria to create Query-by-Example search forms, filter row sets or lists-of-values (LOVs) at runtime, or create varying view instances based on a single view object definition.

Types of View Objects

There are two main types of view objects:

Entity-based view objects, which access data from one or more entity objects and coordinate with those entity objects to update the data source based on user actions.
Read-only view objects, which have direct access to the data. Because read-only view objects do not require intermediary objects, they access data more quickly than entity-based view objects. Create read-only view objects if you have use cases where you need to access data without modifying it. You might have a read-only view object and an entity-based view object for the same table.

In addition, you can create view objects with other data sources such as:

Direct SQL queries of the database
Programmatic sources
Static data from CSV files

You can also create polymorphic view objects, in which multiple row set types with a common inheritance hierarchy are represented in a single view object.

View Object Definition Files

Similar to working with entity objects, when you use JDeveloper's wizards and visual editors to create and configure a view object definition, JDeveloper creates an XML file that contains the declarative metadata that defines the runtime behavior of that view object and features that are used in the UI, such as UI hints and validation rules. At runtime, this metadata is injected into an instance of the generic framework class oracle.jbo.server.ViewObjectImpl.

It is also possible to add custom functionality to a view object by writing custom classes that extend ADF Business Components framework classes.

Ways to Configure View Objects

View objects are part of ADF Business Components implementation of ADF Model. As such, you can add declarative metadata to a view object definition to configure its behavior.

You can define the same declarative metadata for a view object as you can for an entity object (with the exception that you cannot raise business events in view objects). In addition, you can set other types of metadata for a view object, such as the following:

View criteria, which function as further refined queries and which are represented in the Data Controls panel as named queries, from which you can declaratively create search forms.
List UI hints, which can be used to guide how lists of values are presented in the user interface.
UI categories, which can be used for presenting titled groups of attributes in dynamic forms.
View accessors, which can be used to provide a data source for view instance attributes involved in either list-based attribute validation or lists of values.
Row finders, which can be used to match view instance rows by non-key attribute values and to initiate row updates either programmatically or through ADF web services.

View Links

Relationships between view objects are handled by view links, which define a relationship between two view objects based on sets of entity attributes from each. Like entity associations, these can range from simple one-to-many relationships based on foreign keys to complex many-to-many relationships.

Individual instances of view objects can also be related by individual instances of view links, which create a master-detail relationship between the query result sets. For example, suppose that you have view object definitions representing a query for department information and a query for employee information, and a view link between the view objects representing the relationship between a department and its employees. If an instance of the former view object definition, allDepartments, is related to an instance of the latter, employeesInDepartment, by an instance of the view link, those instances will be synchronized: whenever a particular row of allDepartments is selected, employeesInDepartment will only display details of that row.

Application Modules

Oracle ADF application modules are the ADF Business Components implementation of ADF Model data controls. Application modules represent particular application tasks. The application module definition provides a data model for the task by aggregating the view object and view link instances required for the task. It also provides services that help the client accomplish the task. For example, an application module can represent and assist with tasks such as:

Updating customer information
Creating a new order
Processing salary increases

Figure 1-137 illustrates how an application module works with other business components.

Figure 1-137 Application Module Within the ADF Business Component Architecture

Description of "Figure 1-137 Application Module Within the ADF Business Component Architecture"

In addition, application modules have pooling and state management features that simplify making applications scalable, well-performing, and able to handle failover.

Types of Application Modules

You can use application module definitions in the following ways:

As a service object, in which case each instance of the MVC application has access to one instance of the application module. These root-level application module instances control ADF Business Components transaction objects, which in turn control the entity and view caches.
As a reusable object for nesting, in which case you can create a data model and service methods on it and then nest one of its instances in other application module definitions. Those application module definitions can, in turn, access the nested module's methods and data model. Nested application modules share the root-level application module's transaction
As a shared application module, in which data is cached for reuse across sessions and requests. Shared application modules are particularly useful for optimizing performance when you have data that does not change very frequently and needs to be accessed across multiple sessions and requests.

Application Module Definition Files

An application module definition can have one or two parts:

An XML file, which represents the portion of the application that can be developed declaratively: the view object and view link instances that the application module contains and the way in which they are related. For many application modules, the XML file by itself is sufficient.
An application module class, which lets you write custom code such as service methods that an MVC application can invoke for batch data handling. Application module classes extend the class oracle.jbo.server.ApplicationModuleImpl. If you do not need to write custom service methods, you need not generate an application module class—ADF can use oracle.jbo.server.ApplicationModuleImpl directly.

Service-enabled Application Modules

Service-enabled application modules are ADF application modules that you advertise through a service interface to service consumers. There are three scenarios for service consumers to consume a published service-enabled application module:

web service access
Service Component Architecture (SCA) composite access
access by another ADF application module

The Service Component Architecture (SCA) provides an open, technology-neutral model for implementing remotable services that are defined in terms of business functionality and that make middleware functions more accessible to application developers. ADF Business Components supports an SCA-compliant solution through application modules you can publish with a service interface. The service interface is described for Fusion web application clients in a language-neutral way by the combination of WSDL and XSD.

When you service-enable your application module, JDeveloper generates the artifacts, which comprise the following files:

the Java interface defining the service
an EJB session bean that implements this Java interface
a WSDL file that describes the service's operations
an XML Schema Document (XSD) that defines the service's data structures

SCA defines two kinds of service:

Remotable services, typically coarse-grained and designed to be published remotely in a loosely coupled SOA architecture
Local services, typically fine-grained and designed to be used locally by other implementations that are deployed concurrently in a tightly coupled architecture

ADF Business Components services fall into the first category, and should only be used as remotable services.

ADF Business Components services, including data access and method calls, defined by the remote application modules are interoperable with any other application module. This means the same application module can support interactive web user interfaces using ADF data controls and web service clients.

Any development team can publish a service-enabled application module to contribute to the Fusion web application. The Fusion web application assembled from remote services also does not require the participating services to run on a single application server.

Although the web applications may run on separate application servers, the appearance that SCA provides is one of a unified application. Consuming client projects use the ADF service factory lookup mechanism to access the data and any business methods encapsulated by the service-enabled application module. At runtime, the calling client and the ADF web service may or may not participate in the same transaction, depending on the protocol used to invoke the service (either SOAP or RMI). Only the RMI protocol and a Java Transaction API (JTA) managed transaction support the option to call the service in the same transaction as the calling client. By default, to support the RMI protocol, the ADF web service is configured to participate in the same transaction.

Application Module Pooling

Applications you build that leverage an application module as their business service take advantage of an automatic application module pooling feature. This facility manages a configurable set of application module instances that grows and shrinks as the end-user load on your application changes. Due to the natural "think time" inherent in the end user's interaction with your application user interface, the number of application module instances in the pool can be smaller than the overall number of active users using the system. As a given end user visits multiple pages in your application to accomplish a logical task, an application module instance in the pool is acquired automatically from the pool for the lifetime of each request. At the end of the request, the instance is automatically returned to the pool for use by another user session.

To optimize your application's performance, you can tune application module pooling properties, such as initial and maximum pool size and the amount of time application module instances must be inactive before they can be removed from the pool.

Application State Management

You can use application module components to implement completely stateless applications or to support a unit of work that spans multiple browser pages. An application module supports passivating (storing) its pending transaction state to an XML document, which is stored in the database in a single, generic table, keyed by a unique passivation snapshot ID. It also supports the reverse operation of activating pending transaction state from one of these saved XML snapshots. This passivation and activation is performed automatically by the application module pool when needed. Activation can be triggered by server failover or simply because a user session spans multiple instances in the application module pool before it is completed.

Overview of the ADF Business Components Process Flow

Modelling a data source to create the business service layer of the Fusion web application that you develop with Oracle ADF Business Components follows a step-by-step process that is supported by JDeveloper tools.

Creating a business service layer based on ADF Business Components consists of the following general steps:

In JDeveloper, create an application workspace for the application.
Create custom classes that extend the base framework classes and then configure the model project to base any business components that you create on these custom classes. These classes provide a mechanism to later change base framework behavior and have those changes apply to all of the business components you have created in the application.
Using wizards in JDeveloper's New Gallery, create a combination of the following objects:
- Entity objects
- Entity associations
- View objects based on the entity objects
- Optionally, view objects based on queries directly to the database
- View links between view objects to establish master-detail relationships
- Create application modules and include the appropriate view objects and view links within them to establish your data model
Optionally, use JDeveloper's visual editors to declaratively specify business rules for the entity objects and view objects.
Use the ADF Model Tester to test the data model's business logic.
Tune the application modules for performance.
If participating in a SOA application, publish the services so that they can be consumed by an external application.
Using the Data Controls panel and various binding editors, create databound components in the view layer.