This chapter 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 chapter includes the following sections:
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 4-1 shows how ADF Business Components fit into the ADF technology stack. Note that ADF Business Components features directly incorporate ADF Model.
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.
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 by hand.
ADF Business Components technology 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.
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.
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 4-2 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 4-3 shows the source editor for an ADF Business Components view object definition file.
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.
ADF Business Components implements the Java EE design patterns that you would normally need to understand, implement, and debug yourself to create a real-world enterprise Java EE application. These patterns solve problems such as clean separation of application layers, efficient database access, and application scalability.
To cross-reference the names of these design patterns from the Java EE specifications with their ADF Business Components counterparts, you can refer to "ADF Business Components Java EE Design Pattern Catalog" in Developing Fusion Web Applications with Oracle Application Development Framework.
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.
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.
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 Section 18.104.22.168, "Service-enabled Application Modules."
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.
The ADF Business Components architecture consists of the following main 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.
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 4-5 shows how an entity object fits in with other objects in an ADF Business Components application.
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
It is also possible to add custom functionality to an entity object by writing custom classes that extend ADF Business Components framework classes. For information, see "Generating Custom Java Classes for an Entity Object" inDeveloping Fusion Web Applications with Oracle Application Development Framework.
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.
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 at least be an appropriate logical relationship between the tables.
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.
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 this 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 will 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 value (LOVs) at runtime, or create varying view instances based on a single view object definition.
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
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.
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
It is also possible to add custom functionality to a view object by writing custom classes that extend ADF Business Components framework classes. For information, see "Working Programmatically with View Objects" in Developing Fusion Web Applications with Oracle Application Development Framework.
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 can not 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.
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.
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 4-7 illustrates how an application module works with other business components.
In addition, application modules have pooling and state management features that simplify making applications scalable, well-performing, and able to handle failover.
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.
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
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.
For information on enabling an application module as a service data object (SDO) component, see "Integrating Service-Enabled Application Modules" in Developing Fusion Web Applications with Oracle Application Development Framework
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.
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.
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 configuring 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:
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.
The following resources provide detailed information about using ADF Business Components in applications:
For information on creating business services with ADF Business Components, see "Building Your Business Services" in Developing Fusion Web Applications with Oracle Application Development Framework.
For information creating user interfaces that use ADF Model data binding, see "Creating a Databound Web User Interface" in Developing Fusion Web Applications with Oracle Application Development Framework.
For Javadoc documentation related to ADF Business Components, see the
oracle.jbo package in the Java API Reference for Oracle ADF Model