2. ADF Business Components

Business services layer allow us to interact with our data sources.

ADF BC is mainly responsible for managing data persistence validation and business logic. It is a framework developed for developers who are more familiar with declarative tools and are SQL/relational DB sides.

ADF bindings or model layer - It connect business services and User Interfaces. It is based on JSR227 and abstracts the implementation of business services for UI developers. So, whatever be the service, UI developer will be able to see all in the same way and can simply drag and drop when building UI for application.

ADF BC is itself separated into 3 layers.

1) Entity Objects - First layer is Entity Object (EO) which represents tables in DB (and actually maps to a row in DB table) and allows insert, update and delete operations. Using EO, we can define behaviour of attributes and all sorts of validations. EOs are related to one another using association. Association represents relationship between entity objects.

2) View Objects - Next layer is composed of VOs. It represents sets of data we interact with and can be up-datable or non up-datable. VOs can be defined on specific entity object or can span multiple EOs. VO can be constructed from SQL or we can type in static values or programmatically using a piece of code. If VO is based on EO, then data will be fetched into EO and then in VO. EO can manage cache of data across multiple VOs. These can be related to one another using view links.

3) Application Module - Last layer is AM. It exposes an interface that UI designer will going to interact with (exposes VOs that we want the UI designer to see). It is responsible for connection to DB and transactional management and exposes a specific data model for developer. Data model is constructed out of VO, view links as well as service methods that are written in AM level. AM can be reused across multiple applications and can be nested to construct more complex data models.

After creating data model, we can further refine it. We can refine attribute properties at EO level and those will then get reflected in any VO that is going to use that EO. We can refine attributes in two ways: first way deals with functionality and behavior of attributes such as mandatory, default value or any DB interaction properties. The other way is using UI hints. These are related to the way attribute display when we are going to create a default UI.

Another thing that ADF BC allows us, is add view criteria dynamically to VOs. In this way, developers are not forced to use one VO for each query but other can have flexibility to use a VO across multiple queries as shown below:

The commit and rollback operations are handled by the AM. Another thing that AM does is to expose the data model that are used by the users of our data services.

By default, business components are configured by using XML metadata files. At runtime, the ADF framework uses the configurations stored in metadata XML definition files for instantiating appropriate business components. The only use of java file is when we cannot fulfil requirement declaratively or we need to implement some complex logic. These java files then again can be created for any ADF business layer (EO, VO, AM).

After creating Business services, developers can access it through AM. AM module exposes set of view objects, data links or any specific operation coded at AM level. We can also create method in AM and then expose them as client interfaces. While building UI, data model of AM will be exposed as data control.