Chapter 8 Introducing ADF Business Components

1. Chapter 8Introducing ADF Business Components

2. Introducing ADF Business Components • ADF BC is a Java and XML based framework for developing: • Business logic, including validation and default logic • Queries • Transaction handling • Data access • It does not create a user interface, but is a pure encapsulation of business logic that communicates with a separate client application, which handles user interaction. • Using ADF BC is the simplest way to design data-aware applications with JDeveloper. This chapter presents an overview of ADF BC by describing its components and uses.

3. Why Use ADF BC? • The advantage of ADF BC over UI-enforced business logic is reusability. For example, a single ADF BC layer can provide the business logic for all a company's needs. The business components can be used again and again, with multiple interfaces (a time saver).

4. Advantages of ADF BC • By maintaining a cache of data in memory, ADF BC reduces the number of database trips required by an application resulting in improved performance and scalability. • ADF BC allows the business logic to be written in Java, which saves the trouble of integrating a Java GUI or JSP application with business logic written in PL/SQL code. • Removing the business logic out of the database keeps the database from handling anything but data, which increases an application's modularity and efficiency.

5. Advantages of ADF BC (continued) • There are also advantages to implementing some business logic directly in the database (more robust) since it will be enforced even in a SQL*Plus session. Business logic implemented in the ADF BC layer is only enforced in applications using that layer, but increases performance. • There is a trade-off between robustness and performance. • Therefore, the most critical business logic should be implemented in the database or redundantly in both the database and a ADF BC layer. The remainder of the business logic can be implemented in the ADF BC layer.

6. Advantages of ADF BC (continued) • ADF BC provides four ready-made architectures for business component clients: • JClient, an architecture for creating Java GUIs (useful for intensive data-entry applications requiring high interactivity). • Thin JSP clients are useful for web-based applications where a thin client is more important than very high interactivity, such as self-service and e-commerce applications. • XSQL clients, which generate XML for either flexible display with a style sheet or loose coupling between applications. • UIX, a framework-based architecture for developing web applications.

7. Advantages of ADF BC (continued) • ADF BC also has the advantage of being "deployment-configuration independent". A single ADF BC layer can be deployed as local Java classes or as an Enterprise JavaBean (EJB), with no rewriting of code necessary. You can concentrate on the business logic of your application instead of its deployment requirements. • ADF BC components (whether deployed to a J2EE web module with JSP pages or as an EJB) are fully J2EE-compliant. The ADF BC framework automatically implements the J2EE BluePrints design patterns suggested by Sun Microsystems so you do not need to worry about them.

8. Business Components, Java, and XML • Entity objects, view objects, and application modules each have two parts: a Java class file and an XML file. The files have different purposes. ADF BC is a framework, this means that much of its functionality is contained in a set of libraries. ADF BC classes extend (subclass) the base classes provided by these libraries to provide complex business logic, which requires the procedural power of Java to implement. This allows you (if needed) to: • Easily write code to implement complex business rules inside your entity object Java classes • Code complex query logic in your view object classes • Code complex transaction handling in your application module classes.

9. Business Components, Java, and XML • The base classes in the ADF BC framework are programmed to work with XML files. Some business logic is common and simple and can be handled with a line or two of declarative XML. Instead of writing a procedure to implement this sort of business logic, you can just declare that an entity attribute, for example, must obey a particular validation rule. The base entity object class (and by inheritance, your custom Java class) can automatically read the XML file to enforce the rule. JDeveloper has wizards that write and edit the XML files for you. • The ADF BC framework uses XML files to store static definitions such as the structure of a database table or query. Its base classes can obtain the structure of particular business components by parsing the XML. • This can have performance advantages. For example, an entity object dose not need to query the database at runtime for structural information about the table it represents.

10. ADF Business Component Groups • ADF BC components are divided into two groups: • Business domain components • Data model components

11. Business Domain Components • These components represent features of the database: tables and views, constraints, and relationships. They are the most reusable business components because they can be used by any application that needs to access the same data. • There are three kinds of business domain components: • Entity Object definitions • Associations • Domains

12. Entity Object Definitions • An entity object definition usually represents a database table or database view, but it can also be used to represent EJB entity beans. It acts as a representation of the table or database and handles all of the business rules for that table or view including validation, defaulting, and anything else that happens when a row is created, deleted, or changed. • The power of ADF BC is its interface with the database used by an application. • The ADF BC layer represents the database table as an entity object. An entity object has entity attributes that represent the table columns (mapping may not always be one-to-one). • The types of the properties are Java classes that correspond to the SQL types of the columns.

13. Entity Object Definitions • Example: DEPARTMENTS table • Entity objects for the above table may have the following entity attributes:

14. Entity Object Definitions • Java does not directly support SQL datatypes, but each SQL datatype can be mapped to a Java type. Some Java types are classes in java.langand others in the package oracle.jbo.domain (discussed later). • Entity objects have two parts: • A Java class (like DepartmentsImpl.java) – This contains the procedural code to implement the entity object. • An XML file (like Departments.xml) – This includes metadata describing the entity object, its attributes, and the table upon which it is based, as well as declarative code.

15. ADF BC Relationships (page 228)

16. Associations • Like tables, entity objects are often related to one another. The relationships between entity objects are called associations. An association matches one or more attributes of a "source" entity object with one or more attributes of a "destination" entity object. • This is like a foreign key constraint that matches one or more columns of a child table with one or more columns of a parent table. • Associations are stored in an XML file.

17. Domains • Domains are special java types used by ADF BC as the types for many entity object and view object attributes. In the coverage of entity objects earlier, a class that implements the Departments entity object has some entity attributes of type oracle.jbo.domain.Number. The entity attributes of an entity object Java class are objects, not primitive Java types such as int. • Database columns of SQL datatype VARCHAR2 have the Java class java.lang.String. For other SQL types (NUMBER, etc.), ADF BC provides domains to wrap the SQL datatype. Domains like oracle.jbo.domain.Number are basically object wrappers for scalar types. • JDeveloper will automatically create a domain if you base an entity object on a table with an Oracle object type column in it. This domain represents the Oracle object type, giving you Java wrappers for each of the object type's fields and methods. • You can also create your own domains.

18. Data Model Components • They are business components that collect data and present it to the view and controller through the ADF model layer. They are not reusable as business domain components because their design is based on the data needs of a particular client application. • They are still independent of a user interface. • There are three kinds of data model components: • View object definitions • View link definitions • Application module definitions

19. View Object Definitions • Generally you should not present all of the information stored in a database object (entity object) in one application. You may also want/need data taken from more than one database object. • SQL provides the queries necessary to select exactly the data you need from one or more tables. This is why ADF BC has view object definitions, which correspond to SQL queries. A view object definition actually stores a SQL query.

20. View Object Definitions(continued) • A view object definition has view attributes (like entity objects have entity attributes) that correspond the columns of a query result. For example, consider the view object for the following query: SELECT Departments.DEPARTMENT_ID, Departments.DEPARTMENT_NAME, Employees.EMPLOYEE_ID, Employees.FIRST_NAME, Employees.LAST_NAME FROM DEPARTMENTS Departments, EMPLOYEES Employees WHERE Departments.MANAGER_ID=Employees.EMPLOYEE_ID; This view object would have the following view attributes:

21. View Object Definitions(continued) • The above view attributes may be (but not required to be) associated with attributes from entity objects. • View objects have two parts: • A Java class (like ManagerViewImpl.java) – This class handles the complex logic or the queries, controlling the client's access to the data. • An XML file (like ManagerView.xml) – This stores information about the query and its relationships to entity objects.

22. View Link Definitions • A View link represents a relationship between the query result sets of two view objects. It associates one or more attributes of one view object with one or more attributes of another.

23. View Link Definitions (continued) • For example: • A view object, DepartmentsView, containing the following query: • Another view object, EmployeesView, containing the following query: • A view link, DeptEmpFkLink, that associated the DepartmentId attribute of EmployeesView with the DepartmentId attribute of DepartmentsView. SELECT Departments.DEPARTMENT_ID, Departments.DEPARTMENT_NAMEFROM DEPARTMENTS Departments SELECT Employees.EMPLOYEE_ID, Employees.FIRST_NAME, Employees.LAST_NAME, Employees.DEPARTMENT_ID, FROM EMPLOYEES Employees

24. View Link Definitions (continued) • DeptEmpFkLink represents a master-detail relationship between the query result sets of DepartmentsView and EmployeesView. • View links between view objects can be (but do not have to be) based on associations between underlying entity objects. A view link is represented in an XML file (more on this in later chapters).

25. Application Module Definitions • An application module is a container for view usages (instances of view objects). It lists all of the view usages your application requires and specifies how they are related by view links. These relationships • can be represented by a tree (application module's data model). • For example, an application module might contain usage of DepartmentsView, called AllDepartments, and a usage of EmployeesView, called DepartmentEmployees, linked by an instance of EmpDeptFkLink, called DepartmentToEmployees.

26. Application Module Definitions(continued) • This uses the following data model: Using this model, the two view usages are tied together by a link representing a master-detail relationship between them (EmpDeptFkLink). Using this application module, your client application could select a row in AllDepartments, and the ADF BC framework would immediately synchronize DepartmentEmployees so that it would only return employees from the selected department.

27. Application Module Definitions(continued) • Your application module could contain a usage of DepartmentsView and a usage of EmployeesView without using EmpDeptFkLink, as in the following data model: This module provides usages of the same two view objects, but the view usages are linked. Your client application could select rows in AllDepartments and Allmployees usages independently.

28. Application Module Definitions(continued) • You can even include two instances of EmployeesView in an applicationmodule: one a detail of an instance of DepartmentsView and one independent as in the data model below: With this application module, a client application could select rows in DepartmentEmployees and have them automatically synchronized with AllDepartments and could also select rows in AllEmployees independently.

29. Application Module Definitions(continued) • An application module definition is a template for application module instances, which are individual copies of the data model used by particular instances of the application. Each instance represents an individual database transaction.

30. The hands-on practice beginning on page 234 examines a default ADF BC layer. ENJOY!