Oracle ADF

from Wikipedia, the free encyclopedia
Oracle ADF
Basic data

developer Oracle
Current  version 12.2.1.3
(August 31, 2017)
operating system platform independent
programming language Java
category Java EE Framework
License Oracle license
Oracle ADF

Oracle Application Development Framework , shortly Oracle ADF is a commercial Java EE - Framework to develop, which has set itself the goal in an easy, visual, declarative and efficient way Java enterprise applications. With a range of components and a combination of frameworks (such as TopLink , JSF and Struts ), ADF offers a holistic approach based on the Model-View-Controller principle (MVC). Rapid application development is supported through the use of proven design patterns, metadata-driven components and visual tools .

properties

The basis of this framework is based on a strict separation between data (model), which is encapsulated by the business logic, and the graphic display layer (view) and the control unit (controller) belonging to the display layer. The binding (JSR-227) is an important central component. The following figure shows an overview of the architecture:

ADF11g architecture.png

You can see 4 layers, which are briefly explained from bottom to top:

  • Business Services Layer - contains the access layer to the data from various sources and the actual business logic (Data Services)
  • Model Layer - represents an abstraction layer on the business services layer to enable the layers above (view, controller) to work consistently with the various business services.
  • Controller Layer - is the control unit for navigation within the web application
  • View Layer - describes the user interface of the application (web client, fat client or mobile client).

The binding between data services of the view or controller layer takes place in the model layer. It basically consists of two components:

  • Data controls
  • Data bindings

which are described by metadata. Data controls abstract the implementation details of the business service. Whereas the data bindings expose the methods of the data control as well as attributes in the UI components in order to ensure a clean separation between view and controller. The metadata architecture creates a uniform procedure for the developer to connect all business services with the view and controller layer. The JSR-227 (A Standard Data Binding & Data Access Facility for J2EE) aims to standardize data binding.

Components

ADF faces

The ADF Faces Framework offers the developer the ability to visually and declaratively implement modern, web-based, dynamic and interactive user interfaces (UIs). The UI components can be updated in the browser at runtime using client and server-side technologies (AJAX or server push technologies) without having to completely reload the website. The ADF Faces component library extends the Apache-MyFaces-Trinidad components with various rich client UI and data visualization components (e.g. Maps, Gantt, Hierarchy Viewer). The ADF Faces Framework supports:

  • Partial Page Rendering (PPR)
  • Data streaming
  • ADF data binding support
  • Dialog, popup and menu functions
  • Drag & drop features
  • full JavaScript API
  • Templating
  • Skinning via CSS
  • Multilingualism
  • Expression Language Support
  • various Java EE containers

The data is kept in the UI components on the client side as a DOM and on the server side as an in-memory tree. The renderer enables the UI components to be displayed for various end devices (mobile devices, browsers).

ADF task flow

In the figure above, ADF Taskflow represents the controller component and extends the JSF Controller with reusable control flow components (task flow components). Instead of representing a single, large page flow in a web application, the task flows help to divide the entire website control into smaller units. In addition, not only the page view / sequence is controlled, but other, different code blocks can be executed in one sequence. The task flows are divided into 2 categories:

  • unbounded task flow
  • bounded task flow.

An Unbounded Task Flow serves as an entry point to a web application and is viewed as a top-level flow or outer task flow. In contrast to the bounded task flow, the limits are not well defined. Bounded task flows are characterized by their well-defined boundaries, with a single point of entry, their own memory area (page flow scope) and declarative transaction management. As a result, they represent independent processes that can be reused on different pages or regions on a page (ADF regions). Security, monitoring, control, transaction management and exception mechanisms round off the ADF controller.

ADF model and data binding

The ADF model is the core of Oracle ADF. It represents an abstraction layer between the business service layer and the user interface and was first introduced with Oracle JDeveloper 9.0.5. Before that, every developer was responsible for the connection between the user interface (e.g. Swing , JSP or JSF ) and the business service ( data binding ). For example, JSP tags had to be used to connect a text field in the interface with an attribute of the business service. With the ADF model, an additional abstraction layer is introduced: the developer now connects the surface with the model and the model with the business service. This concept was described in specification JSR-227 and submitted for standardization. The ADF model thus provides a uniform programming interface for a wide variety of business services ( web service , Enterprise JavaBeans , Java, JDBC etc.). In addition to being more complex, this architecture offers several advantages:

  • The user interface developer can concentrate on the development of the user interface without knowing the underlying business service.
  • A business service can be exchanged without affecting the surface of the application. Only adjustments in the ADF model are necessary.
  • All applications use the same programming interface (API) and the same metadata format to describe the data binding.

In the development with ADF, this looks specifically in such a way that the developer of the business service provides so-called data controls. The data controls include all of the data and methods of the business service that are to be made available to the interface. The user interface developer connects these data controls with components in the user interface and thus creates the so-called data binding. The syntax of the JSTL Expression Language (EL) is used to define the data binding . Oracle ADF contains predefined implementations of the data controls for the most common business service technologies.

ADF Business Components

ADF Business Components (ADF BC) represent the data / persistence layer on the relational DB with the associated transaction and locking mechanisms (?) And appear as business services in the above architecture illustration. In addition, ADF Business Components offer a unique aspect of software engineering, the Event Driven Model approach. ADF BC objects contain anchor points (hook points) for injecting self-written Java codes for the extension of specific operations. Similar to the events in Oracle Forms, ADF BC provides methods that can be overwritten and change the behavior in detail, e.g. B. pre and post commit, DML execution, create new data record and the like. a. The essential components of ADF BC include:

  1. Entity Objects
  2. View Objects
  3. Associations and Viewlinks.
  4. Application Modules (AMs)
  5. Business Component Tester

An Entity Object (EO) represents a table in a relational database in a simple way. It defines the data type of the table attributes, validation rules with regard to the data type, primary key and additional auxiliary constructs (business logic) to write data to the target table. As a result, the EO serves as a direct data access / validation engine (support for CRUD operations) on the database tables.

The View Object (VO) can be understood as a data source or as a specific data view that interacts with one or more entity objects. VOs can be based on EOs, which are comparable to SQL queries and are used for data extraction or programmatic data summarization or static lists of data. In most cases, VOs based on EOs are used. The view object asks for data and makes it available as a data source. While some validation options are also available for view objects, in practice it is recommended to store special logic in the entity objects, because this logic is cached within an entity for all view objects. Several view objects share the same memory (cache). At runtime, when a query is executed, data related to a view object is divided into the responsible entity object records and stored in the entity cache. This procedure supports different view objects to ensure access to the same data set, under the premise of reducing the memory usage and the different validation rules for all entity objects. This is similar to normalization at the DB level.

Association and Viewlink define the links between EOs and VOs. Associations in detail represent relationships between EOs. They are regarded as PrimaryKey / ForeignKey relationships between tables. View links refer to the relationships between the view objects and define join conditions. A viewlink can be based on association or on attributes. Association-based viewlinks have the same advantage as the entity cache.

The application module summarizes the VOs and serves as data control. It creates and manages database transactions. It provides the data and methods required by the client for the ADF model layer. From the end user perspective, the interaction options and transactional capabilities are provided by the application module.

The Business Component Tester is the most common test tool for executing the Business Components and checking the implemented data model. It serves as the first line of defense for checking the data provision and the data model as it is required without creating a separate user interface.

ADF Metadata Services

Metadata Services (MDS) are an important part of the declarative development of enterprise applications with ADF. With MDS, applications become multi-tenant and dynamically adaptable for individual identities (roles, site user, user). The stored metadata for each individual identity is kept in a repository (based on files and RDBMS). The adaptability can be defined down to the ADF component level. During development, a basic set of metadata (base document) is created in the repository as a document (XML representation). Additional adjustments based on different side views and user views are viewed as a respective individual layer and the difference to the base document or the layer above is stored as a further document in the repository. Each individual document in the repository can be versioned.

ADF Mobile

ADF Mobile is based on the Application Development Framework and extends it with a mobile component. It enables mobile applications to be developed as platform-independent as possible in order to run them on different device platforms without significant additional effort. To achieve this goal, two approaches are being pursued. The framework offers to design applications on the one hand to run in a mobile browser and on the other hand to implement them as a locally installed client (incl. Local MVC stack and database). Both variants will now be described.

ADF Mobile Browser

Applications that are later to be displayed on mobile browsers are developed in JDeveloper in a similar way to what one is used to from web applications for normal web browsers . The relationship to conventional web applications enables web programmers to get into the technology relatively quickly. However, there is a difference in the display layer. Where common web applications are implemented with Java Server Pages (JSP) or Java Server Faces (JSF; expanded to include ADF Faces), a separate technology is used in the development of the mobile browser. This is where the Apache MyFaces Trinidad library comes in. This is technically necessary in order to achieve the desired platform independence - to be able to display the content correctly on many heterogeneous mobile phone browsers. With the development environment, surfaces can be created completely declaratively, the pages are created according to the visual modular principle. One strength that needs to be highlighted is the browser switch that occurs at runtime. The differentiation of the requesting browser at runtime has the advantage of delivering a platform-specific layout. If this is the safari browser of an iPhone, the corresponding browser page can be designed in the design of a native iPhone app. For this it is necessary to create a separate CSS file for each of the supported platforms. The Oracle Skinning Guide provides a good insight into this.

The mobile browser is well suited for adding a mobile component to existing web applications. The common situation is therefore an existing application. The ADF framework offers the option of exporting these and integrating them into the mobile development project as a .Jar file. This has the advantage that database connections and objects, views, business logic etc. do not have to be recreated, but only have to be reassembled. The only thing that needs to be done, as already described, is to redesign the surfaces with Trinidad components. This fact first raises the question of why this is necessary, since it would be more elegant to take over the entire web application. Against this is the point that the ADF Faces technology used by ADF cannot be rendered by mobile browsers. In addition, it does not necessarily make sense anyway to adopt surfaces designed for the large web browser without adapting them. The limited space available on a mobile phone display requires new, adapted surfaces.

ADF Mobile Client

In addition to the browser solution, Oracle ADF Mobile also provides a client variant. It is one of the few frameworks that take both approaches. In contrast to the browser, which receives all of the content over the network from an application server, the client and the necessary business logic are available directly on the mobile device - an MVC paradigm therefore runs directly on the mobile phone. The basis is a Java runtime. If a target device provides this or if it is possible to install a runtime, the device is a potential target platform for ADF Mobile Client. The credo Write once - deploy everywhere is thus fulfilled. There is a significant difference to be observed in the component display at runtime such as buttons etc. While you specify the look and feel in the browser using a CSS file, i.e. you have to define it at design time, the design of a client application in JDeveloper is only recorded on a meta level. At runtime, when the device is informed, for example, that a button should be drawn at a certain point, this is also meta information. The button itself is then drawn natively from the own device library. In this way, exactly the same surface design is achieved as with a native app.

ADF Mobile Database

If the mobile client application requires a local database, this is also installed once on the device (via Developer). The primary advantage of a local database is the fact that data can be read out, changed or entered even in situations in which no network is available. This creates the challenge of ensuring that the database is synchronized again at a later point in time. For this, Oracle provides the mobile server. This software is the mediator between the local database and the central database server and achieves consistent data management through the so-called MGP (Message Generator and Processor). If this process is initiated, the client loads the changed information into an "In Queue" of the mobile server. This is followed by the MGP, so to speak the merging of the data. A large number of settings can be made for this via the administration interface of the mobile server (server wins / client wins etc.). Incorrect processes are saved in an error queue, newer data that must be updated on the device are transmitted to the device via an "out queue".

history

Some components of ADF were released by Oracle in 1999, such as: B. ADF Business Components - then known as "JBO" (Java Business Objects) and later as "BC4J" ("Business Components for Java"). The current generic model / binding layer in the ADF architecture was introduced with JDeveloper 9.0.5. In June 2006, Oracle donated a large part of the ADF Faces component library (Oracle's JSF implementation with over 100 components) to the open source project Apache Trinidad .

Licensing

Licensing details are described on the Oracle Technology Network (OTN).

literature

  • Frank Nimphius and Lynn Munsinger: Oracle Fusion Developer Guide , ISBN 0071622543 .
  • Duncan Mills, Peter Koletzke, Avrom Roy-Faderman: Oracle JDeveloper 11g Handbook - A Guide to Oracle Fusion Web Development, ISBN 0071602380 .
  • Ronald Grant: Quick Start Guide to Oracle Fusion Development , ISBN 0071744282 .
  • Sten E. Vesterli: Oracle ADF Enterprise Application Development - Made Simple , ISBN 1849681880 .
  • Nick Haralabidis: Oracle JDeveloper 11g R2 Cookbook , ISBN 1849684766 .

Web links

Individual evidence

  1. Oracle JDeveloper and Oracle Application Development Framework Pricing. In: www.oracle.com. June 2008, archived from the original on May 1, 2013 ; accessed on September 16, 2019 (English).