ADF Business Components
- by Arda Eralp
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
