ADF Business Components and JDeveloper simplify the development, delivery, and customization of business applications for the Java EE platform. With ADF Business Components, developers aren't required to write the application infrastructure code required by the typical Java EE application to:

• Connect to the database
• Retrieve data
• Lock database records
• Manage transactions

 

ADF Business Components addresses these tasks through its library of reusable software components and through the supporting design time facilities in JDeveloper. Most importantly, developers save time using ADF Business Components since the JDeveloper design time makes typical development tasks entirely declarative. In particular, JDeveloper supports declarative development with ADF Business Components to:

• Author and test business logic in components which automatically integrate with databases
• Reuse business logic through multiple SQL-based views of data, supporting different application tasks
• Access and update the views from browser, desktop, mobile, and web service clients
• Customize application functionality in layers without requiring modification of the delivered application
• The goal of ADF Business Components is to make the business services developer more productive.

 

ADF Business Components provides a foundation of Java classes that allow your business-tier application components to leverage the functionality provided in the following areas:

Simplifying Data Access

• Design a data model for client displays, including only necessary data
• Include master-detail hierarchies of any complexity as part of the data model
• Implement end-user Query-by-Example data filtering without code
• Automatically coordinate data model changes with business services layer
• Automatically validate and save any changes to the database

 

Enforcing Business Domain Validation and Business Logic

• Declaratively enforce required fields, primary key uniqueness, data precision-scale, and foreign key references
• Easily capture and enforce both simple and complex business rules, programmatically or declaratively, with multilevel validation support
• Navigate relationships between business domain objects and enforce constraints related to compound components

 

Supporting Sophisticated UIs with Multipage Units of Work

• Automatically reflect changes made by business service application logic in the user interface
• Retrieve reference information from related tables, and automatically maintain the information when the user changes foreign-key values
• Simplify multistep web-based business transactions with automatic web-tier state management
• Handle images, video, sound, and documents without having to use code
• Synchronize pending data changes across multiple views of data
• Consistently apply prompts, tooltips, format masks, and error messages in any application
• Define custom metadata for any business components to support metadata-driven user interface or application functionality
• Add dynamic attributes at runtime to simplify per-row state management

 

Implementing High-Performance Service-Oriented Architecture

• Support highly functional web service interfaces for business integration without writing code
• Enforce best-practice interface-based programming style
• Simplify application security with automatic JAAS integration and audit maintenance
• "Write once, run anywhere": use the same business service as plain Java class, EJB session bean, or web service

 

Streamlining Application Customization

• Extend component functionality after delivery without modifying source code
• Globally substitute delivered components with extended ones without modifying the application

 

ADF Business Components implements the business service through the following set of cooperating components:

Entity object

An entity object represents a row in a database table and simplifies modifying its data by handling all data manipulation language (DML) operations for you. These are basically your 1 to 1 representation of a database table. Each table in the database will have 1 and only 1 EO. The EO contains the mapping between columns and attributes. EO's also contain the business logic and validation. These are you core data services. They are responsible for updating, inserting and deleting records.

The Attributes tab displays the actual mapping between attributes and columns, the mapping has following fields:

• Name : contains the name of the attribute we expose in our data model.
• Type : defines the data type of the attribute in our application.
• Column : specifies the column to which we want to map the attribute with
• Column Type : contains the type of the column in the database

 

View object

A view object represents a SQL query. You use the full power of the familiar SQL language to join, filter, sort, and aggregate data into exactly the shape required by the end-user task.

The attributes in the View Objects are actually coming from the Entity Object. In the end the VO will generate a query but you basically build a VO by selecting which EO need to participate in the VO and which attributes of those EO you want to use.

That's why you have the Entity Usage column so you can see the relation between VO and EO.

In the query tab you can clearly see the query that will be generated for the VO. At this stage we don't need it and just use it for information purpose. In later stages we might use it.

Application module

An application module is the controller of your data layer. It is responsible for keeping hold of the transaction. It exposes the data model to the view layer. You expose the VO's through the Application Module. This is the abstraction of your data layer which you want to show to the outside word.It defines an updatable data model and top-level procedures and functions (called service methods) related to a logical unit of work related to an end-user task.

While the base components handle all the common cases through built-in behavior, customization is always possible and the default behavior provided by the base components can be easily overridden or augmented.

When you create EO's, a foreign key will be translated into an association in our model. It defines the type of relation and who is the master and child as well as how the visibility of the association looks like.

A similar concept exists to identify relations between view objects. These are called view links. These are almost identical as association except that a view link is based upon attributes defined in the view object. It can also be based upon an association.

Here's a short summary:

• Entity Objects: representations of tables
• Association: Relations between EO's. Representations of foreign keys
• View Objects: Logical model
• View Links: Relationships between view objects
• Application Model: interface to your application