Oracle Application Development Framework

Oracle Application Development Framework, Oracle ADF short, is a commercial Java EE framework, which has set itself the goal of developing a simple, visual, declarative and efficient way Java enterprise applications. ADF offers a range of components and a group of frameworks ( such as TopLink, JSF and Struts ) a holistic approach based on the Model-View- Controller (MVC) principle. Through the use of proven design patterns, metadata- driven components and visual tools is Rapid Application Development supported.

Properties

The basis of this framework is based on a strict separation between data ( Model), which are encapsulated by the business logic and graphical presentation layer ( view) and belonging to the presentation layer control unit (controller). An important central component, the BindingNavigator (JSR -227 ) dar. The following figure illustrates the architecture at a glance:

Evident are 4 layers ( Layers), which are briefly described from bottom to top:

• Business Services Layer - includes the access layer to the data from different sources and the actual business logic (Data Services )
• Model layer - provides an abstraction layer to the business services layer to enable the overlying layers ( View, Controller ) in a consistent manner with the various business services work.
• 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 the Data Services of View and Controller layer takes place in the model layer. Basically, it consists of two components:

• Data Controls
• Data Bindings

Which are described by metadata. Data controls abstract the implementation details of the business services. Whereas the data bindings expose the methods of the Data Controls and attributes in the UI components to ensure a clean separation between the view and controller. The metadata architecture creates connect to for the developer a consistent approach all business services with the view and controller layers. The JSR -227 ( A Standard Data Binding & Data Access Facility for J2EE), the standardization of the data binding has set itself the goal.

Components

ADF Faces

The ADF Faces framework provides designers with the opportunity to realize visually and declaratively, modern web-based, dynamic and interactive user interfaces ( UIs ). The UI components can be updated in the browser at runtime by client- and server-side technologies (AJAX or server push technology ), without performing a new HTTP request. The ADF Faces component library extends the Apache MyFaces Trinidad components to various rich client UI and data visualization components (eg, 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
• Complete JavaScript API
• Templating
• Skinning via CSS
• Multilingualism
• Expression Language Support
• Various Java EE container

The data are stored on the client side in the UI components as DOM and server side as in-memory tree. The renderer allows the display of UI components for different devices ( mobile devices, browser ).

ADF Task Flow

In the illustration above, ADF Task Flow is the controller component and extends the JSF controller to control flow reusable components (task flow components ). Instead of representing a single, large side drain ( Page Flow ) in a Web application that will help task flows to divide the complete website control into smaller units. In addition, the page view / drain is not only controlled, but more, different code blocks can be performed in a sequence. The task flows are divided into 2 categories:

An unbounded task flow is used as an entry point to a Web application and is considered as a top -level flow or external task flow. The boundaries are not well defined in contrast to the bounded task flow. Bounded task flows are characterized by their well-defined boundaries, with a single entry point ( single point of entry ), private storage area ( page flow scope) as well and the declarative transaction management. Consequently they constitute separate processes (ADF Regions) can be reused on different pages or regions on a page. Security, control, management, transaction management and exception mechanisms round out 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. Prior to each developer was (for example, Swing, JSP or JSF) and Business Service responsible for the connection between the surface ( databinding ). Thus, for example, had JSP tags are used to connect a text field in the surface with an attribute of the business service. With the ADF Model an additional abstraction layer is introduced: the developers now combines the surface with the model and the model with the Business Service. This concept has been described in the specification JSR -227 and submitted for standardization. The ADF model thus provides a unified programming interface for a variety of Business Services ( Web services, Enterprise JavaBeans, Java, JDBC, etc. ) are available. In addition to a higher complexity of this architecture offers several advantages:

• The surfaces developers can concentrate on the development of the user interface, without knowing the underlying business service.
• A business service can be replaced without the interface of the application is affected. There are only adjustments in the ADF Model necessary.
• All applications use the same programming interface (API ) and the same metadata format to describe the DataBinding.

In development with ADF sees this in concrete terms so that the developer of business service called Data Controls provides. The Data Controls include all those data and methods of the business service to be provided to the interface. The surfaces developer combines these DataControls with components in the surface and thus produces the so-called data binding. To define the data binding syntax of JSTL Expression Language ( EL) is being used. Oracle ADF provides the common business service technologies predefined implementations of the Data Controls.

ADF Business Components

ADF Business Components (ADF BC ) represent the Daten-/Persistenzschicht relational DB with the associated transaction and locking mechanisms is (?) And immerse in the above figure as an architecture Business Services on. 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 injection self-written Java code for the extension of specific operations. Similar to the events in Oracle Forms provides ADF BC methods that are overridden and can change the behavior in detail, eg pre and post commit DML execution, new record, etc. that include the essential components of ADF BC. :

An Entity Object (EO ) represents in a simple way a table in a relational database. It defines the data type of the table attributes, validation rules on the data type, primary keys and additional auxiliary constructs ( business logic ) to write data to the target table. Consequently, the EO serves as a direct Datenzugriffs-/Validierungsmaschine (support for CRUD operations ) to the database tables.

The View Object ( VO) can be interpreted as data source or a specific data view that interacts with one or more Entity Objects. VO 's may be based on EO 's, the SQL queries are comparable and are used for data extraction or data programmatically summary or static lists of data. In most cases, VO 's are used based on EO 's. The View Object asks for data and makes it as a data source. While some validation capabilities available for View Objects are available, it is recommended in practice to store special logic in the Entity Objects, because this logic is cached within an entity for all View Objects. Multiple View Objects share the same memory ( cache). A query on a view object related data in the responsible Entity Object records are split at runtime execution and secluded in the entity cache. This approach supports different View Objects to access the same data set to ensure, under the premise, to reduce the memory usage and the different validation rules for all Entity Objects. This is similar to the normalization on DB level.

Association and View Link define the links between EO 's and VO 's. Associations in detail represent relationships between EO 's; they are as PrimaryKey / ForeignKey considered relationships between tables. View links point to the relationships between view objects and define join conditions. A View Link can be based on association or attributes. View -based links to associations have the same advantage of the Entity cache.

The Application module summarizes the VO 's and serves as a Data Control. It creates and manages database transactions. For the ADF Model layer, it presents the data and methods needed by the client, are available. From end-user perspective, the interaction and transactional capabilities through the application modules are delivered.

Business Component Tester is the most common test tool to perform the business Componets and check the implemented data model. It serves as the first line of defense for examination of data provision and data model, as it is needed, without its own interface ( user interface) to create.

ADF Metadata Services

An important part of the declarative development of enterprise applications with ADF Metadata Services (MDS). With MDS applications are client-capable and individual identities ( roles, site user, user) dynamically adaptable. The metadata stored for each individual identity be kept in a repository (file - based and RDBMS ). Adaptability is defined up to ADF component level. In the development of a basic set of metadata (base document) is created in the repository as a document ( XML representation ). Additional adjustments that are based on different page views and user views are considered relevant individual layers and the difference in each case to the Base Document or the overlying layers saved as another document in the repository. Each individual document in the repository is versioned.

ADF Mobile

ADF Mobile is based on the application development framework and extends this with a mobile component. It allows you to develop mobile applications largely platform independent, to make this run on different device platforms without significant additional work in the course. To achieve this, two approaches are followed. Thus provides the framework, applications to design one for the course in a mobile browser, to implement the other as a locally installed client (including local MVC stack and database). Both variants will now be described.

ADF Mobile Browser

Applications that will later be displayed on mobile browsers, are similarly developed in JDeveloper, as you would expect from web applications for normal Internet browser. The relationship to traditional Web applications allows web programmers a relatively timely access to the technology. However, one difference is the display layer dar. Where common web applications with Java Server Pages (JSP ) and Java Server Faces (JSF, ADF Faces extended to ) be implemented, is used when developing for the mobile browser, a proprietary technology. Here is the Apache MyFaces Trinidad library is used. This is technically necessary to achieve the desired platform independence - to be able to display the contents on many heterogeneous mobile browsers correctly. With the development of environmental surfaces can be created declaratively complete, the page is edited in visual building block principle. A strength that needs to be pointed out is that taking place at runtime browser switch. The information to be at runtime distinction of the requesting browser has the advantage to deliver platform-specific layout. If this is the Safari browser is an iPhone, the corresponding browser page can be designed in the style of a native iPhone app. For this purpose it is necessary, a separate CSS file to create for each of the supported platforms. A good insight this gives the skinning guide from Oracle.

The mobile browser is well suited for it to add a mobile component to existing Web applications. Common situation is therefore an existing application. The ADF framework provides the ability to export this and involve as. Jar file into the mobile development project. This has the advantage that database connections and objects, views, business logic, etc. are not re-created, but must be assembled only once. Only, as already described, it is important to decorate the surfaces with Trinidad components new. This fact first raises the question as to why this is necessary, it would be more elegant to take over the entire Web application. Speaking against the point that the ADF Faces technology used by ADF can not be rendered by mobile browsers. Moreover, it is anyway not necessarily make sense, surfaces, designed for the big Internet browser to accept without adjustment. The sparse space of a cell phone displays requires new customized finishes.

ADF Mobile Client

Oracle ADF Mobile browser provides in addition to the solution is a client version available. It is one of the few frameworks that both approaches are used. In contrast to the browser that receives the totality of the content over the network from an application server, the client together with the necessary business logic directly on the mobile device is present - ie a MVC paradigm runs directly on the phone. It is based on a Java Runtime. If a target device it available or 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 met. In the component display at runtime like buttons etc. A significant difference is observed. While look- and-feel pretends in browsers with CSS file, so it must specify at design time, the design of a client application in JDeveloper is only held on a meta level. At run time when it is communicated to the device, for example, that a button should be drawn at a certain place, so this is also a meta-information. The button itself is but then tightened natively from their own device library. Thus, the exact same surface design is achieved as in a native app.

ADF Mobile Database

Requires the mobile client application to a local database, so this will only be installed once on the device (via Developer). The primary advantage of a local database is the fact to change, even in situations where no network is available, read data, or einzupflegen. Hence the challenge to provide at a later date for bringing the database back to a synchronous state. For this, Oracle provides the Mobile Server. This software is an intermediary between the local database and the central database server and achieved consistent data by the (Message Generator and Processor) so-called MGP. If this process is initiated, the client loads the edited information in an "in queue " of the mobile server. This is followed by the MGP, so to speak, the merging of the data. For this purpose, can the admin interface of the Mobile Server, a variety made ​​to settings (server wins / client wins, etc.). CDPs are stored in an error queue, recent data that need to be updated on the device are transmitted via an " Out Queue " to the device.

History

Some components of ADF were published by Oracle in 1999, such as ADF Business Components - then known as the " JBO " (Java Business Objects) and later as " BC4J " ( " Business Components for Java "). The current generic model / Binding Layer in the ADF architecture was co-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 more than 100 components) the open source project Apache Trinidad.

Licensing

Details of licensing are described on OTN ( Oracle Technology Network).