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