ADF Business Components Part 2

  In this tutorial we will create ADF BC components for Employee and Department tables using the wizard and do test them by performing DML operations through them.

Step 1: Start the Jdeveloper and choose ‘Default role’ when prompted. 

Step 2:  Select ‘New Application’, give application name as ‘ProjectADF’, Application Package Prefix as ‘sdadi.oracle.apps.hr’, select Fusion Web Application (ADF) as application template and click ‘Finish’.

The general naming convention is <com>.<your company>.<your app>.<your module> and sub packages if any.

Jdeveloper creates two projects ‘Model’ and ‘View Controller’. The model part deals with the ADF Business Components and ‘View Controller’ deals with UI and control parts of the application. In this tutorial we focus only on the Model.

Step 3: Right Click on ‘Model’ and select ‘New’

Step 4:  Select Business Tier > ADF Business Components >> Business Components From Tables and click OK.

Step 5: Click on the ‘+’ to create a new database connection. Provide the connection details (hr/hr) as in the figure. Verify connection details by clicking ‘Test Connection’. Click OK after verifying the connection is 'Success!'

I am assuming that oracle DB is already installed and HR schema is unlocked as given in the earlier post.

Step 6:  Set the package as ‘sdadi.oracle.apps.hr.schema.server’. This is just to ensure that all the Entity objects are created under this folder. Set Name Filter to ‘%’ and Click on ‘Query’ to see all objects (Tables, Views and Synonyms) under HR schema.

                Shuffle ‘Employees’ and ‘Departments’ and change the Entity names to EmployeeEO and DepartmentEO. This is just a naming convention for ease of use in future.

Step 7:  Set the package as ‘sdadi.oracle.apps.hr.server’ and shuffle both the entity objects. Rename the view object names to EmployeeVO and DepartmentVO.

Step 8: We are not planning to create any read only view objects in this so just click on next. (Read Only view objects are similar to read only views in the DB, you cannot use them to do DML operations)

Step 9: Provide package as ‘sdadi.oracle.apps.hr.server’ and name as ‘EmpDeptAM’ and click finish.

Step 10: All the required ADF business components are created automatically by JDeveloper and ready to use. You observe that the required Entity Associations and View Links are created based on the database constraints.

Step 11: Test the created ADF BC by right clicking on ‘EmpDeptAM’ > Run. This will open a window with all the view objects and view links included in the AM.

Step 12: You verify by double clicking the view objects and view links and see that rows are fetched accordingly. You can insert a record, delete a record, commit the database, modify a record or simply navigate between records.

ADF Business Components Part 1

This Tutorial 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.

 About ADF Business Components

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.

Core Benefits of ADF Business Components

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.

Key Components of ADF Business Components

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.

 Entity Objects

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 below shows how an entity object fits in with other objects in an ADF Business Components application.

 Entity Object Within the ADF Business Component Architecture

 Entity Object Definition Files

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 oracle.jbo.server.EntityImpl.

It is also possible to add custom functionality to an entity object by writing custom classes that extend ADF Business Components framework classes. 

Ways to Configure Entity Objects

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.

Entity Associations

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.

View Objects

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 Within The ADF Business Component Architecture

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.

 Types of View Objects

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
• Programmatic sources
• 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.

View Object Definition Files

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 classoracle.jbo.server.ViewObjectImpl.

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.

Ways to Configure View Objects

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.

View Links

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.

 Application Modules

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 below illustrates how an application module works with other business components.

Application Module Within the ADF Business Component Architecture

In addition, application modules have pooling and state management features that simplify making applications scalable, well-performing, and able to handle failover.

 Types of Application Modules

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.

 Application Module Definition Files

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 oracle.jbo.server.ApplicationModuleImpldirectly.

 Service-enabled Application Modules

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

 Application Module Pooling

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.

 Application State Management

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.

Architecture of Oracle ADF

Overview

In modern application development, the framework plays an important role--without the support of a mature framework, rapid application development is quite impossible. Oracle has developed an innovative, mature and stable Java EE development framework called Oracle Application Development Framework (ADF). The ADF framework is part of Oracle's award-winning JDeveloper 11g development environment. Oracle ADF provides infrastructure support as part of the framework, so that developers can concentrate on the actual application development. The integrated tool is very useful for rapid application development. In this article, I will discuss the ADF framework and its architecture.

Introduction

In web application development, MVC (Model-view-controller) design pattern is very popular. Oracle ADF also implements the MVC design pattern. The ADF framework provides all the layers of this popular architecture (MVC) and provides solutions in the following areas:

• Object-Relational Mapping (ORM)
• Data persistence layer
• Reusable controller layer
• Rich user interface based on JSF technology
• Data binding mechanism with the UI layer
• Security features

As a result, the coverage of this tool is very useful in the creation of a composite and efficient web application that goes beyond normal MVC framework.

Why Oracle ADF?

As we know. J2EE is a set of specifications for building robust, scalable, secured multi tier applications. But J2EE does not provide any set of tools to make the application itself. So the biggest challenge for making J2EE applications is the selection of tools. There are many different J2EE compliant tools in the marketplace but the selection of the best tool is one of the major criteria behind successful J2EE application development.

So we need a framework that provides an abstract layer on top of the complex J2EE platform. This is the role of the Oracle Application Development (ADF) framework as it provides the infrastructure and design implementation support as part of the framework. Oracle ADF also provides a visual and declarative development approach to support rapid development.

Oracle ADF Key Features

The following are the key features provided by the ADF framework.

• Integrated development environment: Oracle ADF comes bundled with JDeveloper. So JDeveloper works as a perfect tool for ADF application development using visual and declarative approach. It minimizes the development effort.
• Vendor neutral: Oracle ADF is vendor neutral. The Oracle ADF runtime can be used with any J2EE compliant application server.
• Technology support: Oracle ADF provides different layers for J2EE application development. The layers can be developed using different technologies. So the Oracle ADF is also technology neutral.
• Composite end to end solution: Oracle ADF provides support for complete end to end development of J2EE application. So the developers can completely concentrate on the development work instead of the tool or technology selection.

Oracle ADF Architecture

We have already discussed that Oracle ADF follows the MVC design pattern. A typical MVC application contains the following three layers.

• Model layer that holds the business logic.
• View layer that handles the user interface.
• Controller layer that manages the interaction between Model and View layers.

All the components of the application are loosely coupled. This helps with the maintenance of the application and increases the reusability. So the architecture can be defined as Service Oriented Architecture (SOA).

Oracle ADF has four layers in its MVC implementation. It has separate model layer and business service layer to implement service oriented architecture. So we can define the Oracle ADF architecture as MVC model with a business service layer. Here are the four layers of ADF architecture:

• Business Service layer: This layer handles data from various sources and business logic.
• Model layer: This layer does not handle business logic directly; rather it provides an abstract layer on top of the business service layer. This particular design pattern helps the view and controller to work with various business service implementations.
• Controller layer: It controls the web application flow.
• View layer: It provides the user interface.

The figure below represents the core architecture of the Oracle ADF framework. Different layers and their interaction are shown as an example. The components in different layers can be changed per the application requirement.

Figure 1: Oracle ADF basic architecture diagram

As we have seen in different layers, the choice of technology is very flexible. The view layer supports desktop, mobile and web interfaces. The controller and model layer comes under the ADF framework so there is not much change. The business service layer can be anything such as Java, EJB, Web, Portlet, etc. And the same flexibility is there for data layers. The application can interact with RDBMS, web service, legacy system, etc. The flexibility of Oracle ADF framework makes is very popular in the Java EE application development domain.

Now let us discuss a bit of the details about the different layers shown in the diagram.

Business Service Layer

The business service layer is the addition component in the Oracle ADF framework. ADF provides the flexibility to implement this layer using any technology, and some of those technologies are shown in the diagram. This layer manages the following tasks.

• Interaction with data persistence layer
• Object-relational mapping
• Transaction management
• Business logic execution

Model Layer

The model layer provides the single interface to connect to any business service. This model layer in the ADF architecture does not handle business logics itself, rather provides the abstraction on top of the business services. So the flexibility of implementing any business service is a great advantage of the ADF framework. The model layer in ADF is also called 'ADF binding'. It has following to components.

• Data controls: It provides abstraction on top of business service layers
• Data bindings: It exposes data control methods to the UI layer.

Controller Layer

The controller layer is responsible for handling application flow and user input. The navigation rules are defined on a diagram to manage application flow. Here are the two types of controllers used in web-based applications.

• JSF controller
• ADF controller

Note: ADF controller extends the functionality of JSF controllers.

View Layer

The view layer is the front end of any application. The front end layer can be a desktop application, mobile application or web-based application. The multichannel support of the Oracle ADF framework is very useful for developing any type of application. Oracle ADF provides more than 150 Ajax based, ready-made JSF components for creating dynamic web interfaces.

Benefits of the Oracle ADF Framework

The following are some of the benefits of Oracle ADF framework:

• Support for visual and declarative view and controller development
• Various options to construct business service layers
• End to end solution for all the Java EE layers
• Technology and platform independence
• Meta data driven development
• Support for reusability and flexibility

Conclusion

There are different vendors who provide development tools, frameworks based on Java EE specifications. So for developing any Java EE application, developers need to know these tools and their usage. But most of these tools do not support all the layers of Java EE application development. As a result, developers are sometimes a bit confused when choosing tools or frameworks. Oracle ADF provides a complete development environment, infrastructure code, design patterns and ease of development. So the combination of Oracle ADF framework and visual development environment is very popular in the Java EE development community.

- See more at: http://www.devx.com/architect/architectural-overview-of-oracle-adf.html#sthash.8lZT12N7.dpuf