In this chapter we will get an introduction to Oracle Application Development Framework (Oracle ADF) and its layered architecture. We will also develop a simple ADF web application towards the end of this chapter.
Here is the brief outline of the topics that we are going to cover in this chapter:
Introduction to Oracle ADF
Why Oracle ADF?
Oracle ADF architecture
Developing with ADF
Your first Fusion web application
Many of today's huge enterprise applications run on the Java Platform Enterprise Edition (Java EE) platform. The core Java EE technology has been improved considerably in the recent past. The Enterprise Java application development has become much easier with annotations, dependency injection, Enterprise Java Beans (EJB) 3.0, and Java Persistence API (JPA). However, if you take a closer look at the core Java EE technology with a developer's eye, you may notice certain gaps in it:
The learning curve is steep for a beginner
Even experienced Java developers find it hard to understand, when he/she goes deeper into the technology stack
It lacks tooling support that provides a visual and declarative development experience
Java EE specification does not cover all the generic needs
The way to deal with these problems is to use a framework that abstracts the complexity of the Java EE platform, adhering to standard patterns and practices. The Oracle ADF framework is the most promising one in that category.
The Oracle ADF framework is a complete Java EE framework that simplifies next generation enterprise application development by providing out-of-the-box infrastructure services, and a visual and declarative development experience. In this book, you will explore the core ADF features in detail with real-life code samples.
The world moves very fast, and so does technology. It's very important for an enterprise to have dynamic business applications aligned with a growing customer base. In other words, an enterprise application should be smart enough to adapt with the changes in the business eco system and scale with growth of the enterprise. Let us take a look at some of the challenges of enterprise application development with regard to the tools and technology:
Choice of the right tool and platform: The right choice of the tool for development is very critical for the success of any business applications. The tool should be complete, matured, and flexible enough to meet the requirements of different phases of an application lifecycle.
The developer's productivity: The productivity of a developer is the rate at which he/she delivers a quality software product that meets the requirements of the customer. The developer's productivity is thus very important for the success of a product. A tool, which can talk a common language and provides a visual and declarative development experience, has a significant impact on developers' productivity, especially if the application development team is comprised of developers with different skills.
One product and many customers: The unique needs of customers grow more complex every day. In order for a product to do well in the market, besides the generic features, it should also be customizable to meet the unique needs of diverse user groups. A finished software product should always anticipate changes to survive in the market.
Businesses grow and so do the business users: Performance, scalability, and reliability are really important for any enterprise application. An enterprise application should handle increasing demands while maintaining the acceptable performance levels. For example, when a business grows for an enterprise, it may need to consider the large customer base. This may eventually result in an increase in the number of active users for the business applications used in the enterprise. The business application and the underlying technology should be scalable enough to meet tomorrow's needs.
There are many tools and technologies around us that build enterprise applications, but if we need a tool, which is really capable of meeting today's challenges, the list shrinks and we do not have much choice left. Oracle ADF is considered as one among the few best frameworks for building a rich enterprise application.
End-to-end solution: The Oracle ADF framework provides complete solution for building enterprise applications right from inception to the post-production phase, addressing requirements from each layer of applications.
Improved developer productivity: The declarative nature of ADF improves the developer's productivity, allowing users to focus on the business logic of the application, rather than focusing on technology complexity.
Technology choice: Oracle ADF lets the developer choose multiple technologies for each of the layers of the application and does not enforce a specific technology or a specific development style on the developer.
Reference architecture: The enterprise applications built using ADF inherit the layered architecture of the underlying ADF stack, without leaving a chance for you to go wrong on choosing the right architecture.
Scalable architecture: ADF is shipped with a lot of tuning options to meet the increased load of application in production. You are free to override the default tuning parameters based on the usage pattern of the application.
Modular architecture: The Oracle ADF framework supports modular architecture for enterprise scale applications. Multiple modules can be bundled together to build a complete composite ADF application. These modules are also reusable across multiple ADF applications.
Oracle ADF has a well-proven, extensible, and layered architecture, which improves the flexibility, maintainability, and scalability of an application.
What does that mean to you?
As an architect, you can pick up the best fitting technology from a wide range of lists while building each of the layers. For example, ADF supports a variety of ways to build business services, which include EJB or (JPA), web services, simple Java objects, and ADF Business Components (ADF BC). On the client tier, applications can choose from Java Swing, core Java Server Faces (JSF), ADF Faces, or ADF, Mobile UI. Oracle ADF along with JDeveloper IDE, offers consistent development experience across different technologies.
If the use case demands, your ADF application can be easily enhanced later to use other technologies from Oracle Fusion Middleware Stack, such as Service Oriented Architecture (SOA), WebCenter, and so on, with minimal integration effort.
Oracle ADF follows the Model-View-Controller (MVC) design paradigm. The layered architecture of the framework simplifies maintenance, decouples implementations from interfaces, and improves reusability of the components across applications. The layered architecture of the ADF application is really useful when you need to build a User Interface (UI) for various channels such as web, mobile, tablet, and desktop, reusing the existing business services.
It is time for us to give a glance at the architectural building blocks of ADF to study how are they put together to build high performing service-oriented applications.
The View layer contains the UI for the application ADF stack that supports the following view technologies, targeting various presentation channels such as the web browser, desktop, mobile, tablet PC, and Microsoft Excel:
JSF: Core JSF web technology from the Java EE stack
Microsoft Excel: Provides Microsoft Excel frontend for your ADF business services
The Controller layer controls the flow of the application. ADF Controller is used for the ADF Faces application, which provides an improved navigation and state management model on top of JSF. The greatest advantage of ADF Controller over the navigation model offered by core JSF is that it improves the modularity of the system by splitting a single monolithic navigation model to multiple reusable navigation cases known as task flows. Task flows are declarative solutions. Developers typically do not need to write any code for defining navigation in applications. Apart from the support for modular application design, ADF task flows also offer a declarative transaction model and state management solutions.
The ADF model layer plays a very vital role in the entire technology stack. It is the model layer along with JDeveloper IDE that provides a visual and declarative UI development experience for the end user, irrespective of the technology used for building business services. The glue code used for binding the UI with the data model is plumbed by the model layer at runtime based on the binding metadata definition for the page.
Plain Old Java Objects (POJO)
Business Activity Monitoring (BAM)
Business Intelligence (BI)
ADF is built on top of the Java and Java EE stack. If you are familiar with Java EE, this topic is for you. Let us take a quick look at the basic building blocks of these two technologies to see what they have in common:
JSF is a request-driven MVC web framework, which intends to standardize the development of web-based user interface in a Java EE web applications. ADF Faces forms the view layer of a Fusion web application. This is built on top of JSF with lots of extra features, such as graphs and charts, a dialog framework, declarative components, data streaming, embeddable task flows, and rich AJAX-enabled UI components.
In a Java EE web application, it is the JSF controller that intercepts all the page requests and dispatches them to the appropriate view along with the necessary data. The JSF Controller also controls the page navigation. The ADF Controller is extended from the JSF Controller to support modular web application development by decomposing the single monolithic application into multiple reusable web modules, termed as ADF task flows. Each task flow can have its own transaction attributes, resource management, managed bean definitions, and navigation cases.
The data binding layer of ADF (also known as ADF Model) is quite unique in nature and does not have any real counterparts in the Java EE world. The ADF Model decouples the UI from the business service implementation and provides a generic binding behavior for the collection returned from the business services.
Conceptually, Context and Dependency Injection (CDI) does a similar welding job for Java EE web applications, however, feature wise there are many differences, which we will discuss in the coming chapters.
ADF Business Components simplifies the business services implementation by freeing the developer from writing infrastructural code required by enterprise applications. ADF Business Components mainly constitutes of the entity object, view object, and application module.
The ADF entity objects are similar to the Java Persistence API (JPA) entities, however functionality wise the former scores. The major advantages of the ADF entity object are out-of-the-box support for caching of data in middle tier, matured transaction management, declarative validation support, and the ability to triggerthe SOA process during the transaction post cycle.
The ADF view objects are data shaping components. The ADF view objects are similar to Java Persistence Query Language (JPQL) in the Java EE stack. Some of the advantages of ADF view objects over JPQL are the visual and declarative development experience, support for building model-driven UI, and declarative state management.
The ADF application module is the transaction component that wraps your business service—conceptually similar to a session facade built using a session bean in an EJB application. However, we need to keep in mind that these two technologies are in no way related in their underlying implementation, though at the end of the day everything boils down to Java binaries and JDBC calls.
The best way to learn technology is to start coding. In the next section, we will build a simple web application and walk through the application source generated by the development tool. In the coming chapters, we will analyze each piece in detail, taking real-life use cases.
Let us set up the environment for building applications with ADF. The development environment setup includes setting up the Integrated Development Environment (IDE), version controlling the source, picking up the right build tool, and setting up team collaboration.
The success of a development framework is well complimented by a smart development tool, which simplifies the creation of applications by using this framework. Oracle JDeveloper is the IDE that we will be using for building ADF applications. JDeveloper has better tooling support for ADF, covering an end-to-end development lifecycle. You can download and install the studio edition of the latest JDeveloper release from http://www.oracle.com/technetwork/developer-tools/jdev/downloads/index.html. The studio version of JDevloper comes packaged with Java EE and ADF libraries.
If you just want to try out Oracle ADF, installing studio version of JDeveloper alone is enough to keep you going with the technology. In this chapter, you will find some other discussion points such as versions controlling the source, automated build process, and team collaboration. These are required only in real-life enterprise application development with ADF.
Once you have decided on tools and technologies for development, the next step may be to set up the Software Configuration Management (SCM) tool. SCM is the task of tracking and controlling changes in the source code during the application development. There are many source control tools available on the market. JDeveloper is packaged with client support for Subversion (SVN)—the most popular version control tool among Java developers. In fact, you are not limited to SVN; JDeveloper can work with most of the popular tools if you have the right extensions installed. The supported version control list includes Concurrent Version System (CVS), Perforce, Serena Dimensions, Rational ClearCase, and so on.
JDeveloper has built-in support available for compiling and generating deployable artifacts from the application source. This may be enough when you build less complex applications. However, if you are building more complex enterprise applications and the team size is fairly big, you may need to have automated build support and a Continuous Integration (CI) process to improve the quality of the work and fast delivery. In such scenarios, it's required to build the applications outside of JDeveloper. Fortunately, we have multiple options available to address such requirements. Let us take a quick look at the options that are available to build the ADF applications:
Built-in Make and Rebuild options on JDeveloper: When you right-click on a project in JDeveloper and use the Make option, the IDE compiles source files that have changed since they were last compiled, or have dependencies that have changed. The Rebuild option allows you to fire an unconditional compilation on the source.
Ant: Ant is a Java-based build tool, which automates the build process. JDeveloper has in-built support for using ant as build tool for projects. To learn more about ant, go to http://ant.apache.org/index.html.
Maven: Maven is a software management and build automation tool, which bridges ant's shortcomings in many areas. You can learn more about Maven at http://maven.apache.org. JDeveloper provides basic infrastructure support through which Maven can be used for building ADF projects. If you plan to use Maven for building an ADF application, you may need to follow some manual tasks such as adding all the dependencies to your project's
pom.xmland populating the Maven repository with the required ADF libraries.
To learn more about version controlling with JDeveloper and build tools, refer to the Oracle Fusion Middleware User's Guide for Oracle JDeveloper documentation. To access the documentation visit http://www.oracle.com/technetwork/developer-tools/jdev/documentation/index.html and navigate to Oracle JDeveloper and ADF Documentation Library | User's Guide for Oracle JDeveloper. Use the search option to find specific topics..
When you work on larger projects, you may end up using different tools to perform various tasks at various stages of the application lifecycle. Many of these tools do not run co-operatively and may call for a lot of manual labor to get your job done. What we really need is a platform that will integrate all these tools—making our life easier. JDeveloper supports such a platform, which is shipped as Oracle Team Productivity Center.
Oracle Team Productivity Center is a JDeveloper-based Application Lifecycle Management tool that is useful when we work with a larger team spread across different geographic regions in a connected network. The list of features includes the following items:
Team navigator, which enables multiple grouping of users and acts as an access point for the team collaborative features
A build dashboard displaying the nightly built test results on your IDE
Administration console to manage users and teams
The Team Productivity Center client software: This is the JDeveloper client software for the Team Productivity Center. As with any other JDeveloper extensions, this can also be downloaded from the JDeveloper update centre.
The Team Productivity Center server software: The server software manages the connections between the team's Team Productivity Center features in Oracle JDeveloper and data repositories such as a bug database, feature wiki, or directory of product features and specifications.
The Team Productivity Center connectors: As you may have imagined, connectors are used for enabling the connection between the Team Productivity Center client software, running inside JDeveloper and data repositories such as bug-tracking systems, feature databases, and so on. Standard connectors can be installed from the update centre. Even you can build your own connectors, if needed.
In-depth coverage of the Team Productivity Center is beyond the scope of this book. More details on the Oracle Team Productivity Centre including an installation guide and downloads are available at http://www.oracle.com/technetwork/developer-tools/tpc/overview/in dex.html.
Oracle ADF and JDeveloper go hand in hand. JDeveloper is aimed to simplify your job as an application developer by providing visual and declarative aids for development. Let us take a quick tour of the IDE to get familiarized with the commonly used editor windows and tools.
Application navigator: The application navigator window helps us to manage the contents and associated resources of an application. You can create new projects and source files using the options available in this window.
Application resource panel: The application resource panel window displays the application-level resources and configuration files. This includes database connection information, metadata files used to configure ADF Business Components, and so on.
Data control panel: The data control panel displays the data collections, attributes, built-in operations, and business methods from the business services exposed through a data control registry. The exposed items from the data control panel can be dragged-and-dropped on the UI, which will generate a metadata XML file to bind the business data with the UI.
Structure window: The structure window displays a structural view of the data in the document that is currently selected in the active window. Structure window can be used to view or edit the contents. For example, you can drag-and-drop components from any palette to the structure window.
Visual editor: The visual editor window will help you to visually build the UI for ADF applications. It provides a visual WYSIWYG— What You See Is What You Get—editor for HTML, JSP, JSF, Facelets, native mobile UI, and Java Swing. The visual editor allows developers to visually lay out the UI. Note that JDeveloper synchronizes the selection in the structure window with the visual editor and vice versa.
Property inspector: A property is a named attribute of a class or component that can affect its appearance or its behavior. The property inspector displays the exposed properties of the component selected in the structure window or in the visual editor.
It's time for us to break the suspense and get a feel for the smart technology that we are discussing. Are you excited? Good; let us jump start and build a simple Fusion web application. During this course, we will also analyze the generated artifacts by uncovering the magic behind visual and declarative development.
Our use case is very simple, primarily meant for giving you a feel of the development environment and the basic configuration required for an ADF web application to run. In this example, we will build a web application to display the department details from the
DEPARTMENTS database table.
Once the JDeveloper installation is complete, you are ready to launch it for application development. The first time JDeveloper is run, it will prompt for selecting a role that matches your requirement, as shown in the following screenshot:
JDeveloper IDE enables appropriate features to be used based on the role that you select on startup. The default role selected by the IDE is Studio Developer, which includes all the features offered by the IDE. You will use the Studio Developer role for building our first example, which we will discuss shortly. You can switch to a specific developer role if you want to restrict IDE from displaying many other features that are not relevant to the application that you are building.
JDeveloper is packaged with a variety of application templates, which may help us to set up the basic skeleton for applications leveraging well proven architectural patterns. Based on the complexity of the application, you are free to extend this basic structure by adding more projects later in the development cycle.
Click on New Application within the Application Navigator tab in the JDeveloper. This will display New Gallery with a set of predefined templates targeting various technologies.
For ADF web applications, select the Fusion Web Application (ADF) template and click on OK.
Once you select the Fusion Web Application (ADF) template, JDeveloper will launch the Create Fusion Web Application wizard, which may let you key in the application name and location to store the source files.
As the names suggest, these projects hold your business services and UI-related sources respectively. While navigating through the setup screens for each project, you are free to change the default name of the project and package name of your Java files. As this is our first application, let us leave the default values set by the IDE as they are and finish the wizard.
When you finish the Fusion web application generation wizard, the following files are generated in your source folder. Let us take a quick look at these metadata XML files to understand the role of each item in our application.
faces-config.xmlfile contains the configurations for a web application built using JSF. This file allows us to configure managed beans, data convertors, and validators used in the UI, navigation cases, global resource bundles, view handlers, page lifecycle phase listeners, and custom lifecycle factory implementation for the application.
adfc-config.xml: ADF Faces is built on top of the JSF with a lot of extra features, which are not covered by the core JSF. ADF Faces uses
adfc-config.xmlto keep its configurations. As a Fusion developer, you should use
adfc-config.xmlto configure the navigation cases and managed bean definitions. To run your Fusion web application, you may need both
adfc-config.xmlfiles—which is true even if you have not added any custom configuration entries in
trinidad-config.xml: Apache MyFaces Trinidad forms the base for the ADF Faces component set. In fact, Trinidad components earlier were ADF Faces components, which were donated to Apache Software Foundation later in the journey. By default, the generated
trinidad-config.xmlfile contains only the skin family name. However,
trinidad-config.xmlcan be used to override the default configurations for accessibility settings, locale settings, state management, and so on.
web.xmlfile acts as deployment descriptor for a Java-based web application. When you generate a Fusion web application by using JDeveloper, a default
web.xmlfile with default settings will be created for you. The default entries include context parameters for configuring the runtime state of the system, security filters, data binding filters for web pages, and resource look up filters. The
web.xmlfile also includes servlet context listeners for initializing the management and monitoring services for view and model layers.
adf-config.xmlfile contains application-level settings, which manage the runtime infrastructure—such as failover behavior for the application modules, global fetch limit for all the view objects, caching of resource bundles, automated refresh of page bindings, and so on—for your application.
The next step is to create a database connection that will be used later in the development phase to generate the data model from database objects.
We will be using the
HR schema in our samples. The
HR schema is included with the Oracle 10g or Oracle 11g database. While you define the database connection, key in the credentials set for your local
For building a sample application, you can also use Oracle Express Edition (Oracle Database XE) as the database. Oracle Database XE is an entry-level, small-footprint database. All the examples used in this book use Oracle Database XE as the database. To learn about Oracle Database XE, visit http://www.oracle.com/technetwork/products/express-edition/overview/index.html.
When you create a database connection, JDeveloper generates a set of metadata XML files to keep the connection information. Let us take a quick look at these files.
connections.xml: This file contains the database connection detail that we create for development. If your application consumes web services or map viewer services, the corresponding connection uniform resource locator (URL) will also be present in this file.
jps-config.xmlfile is used to store the Oracle Platform Security configurations. The location of this file is configured in
adf-config.xml. If your application is not configured to use ADF Security, this file, at a minimal level, acts as a pointer to
cwallet.sso, which contains the password for the database connection details present in
cwallet.ssofile follows the Oracle Platform Security Services (OPSS) specification and it is used as a credential provider in connecting to external systems, such as databases. This file is normally not edited directly.
The basic infrastructure required for building our first ADF application is in place now. First, we will start the business service implementation by generating the data access layer, followed by the business service layer exposing the services to client.
Our example uses ADF Business Components for building business services where the data access layer is formed by entity objects and view objects. The application module generates the business service layer.
An entity definition represents an object in the database such as table, synonym, view, and so on, and an entity instance corresponds to a row from the database object. When you commit a transaction, entity objects are responsible for posting the modified data back to the database.
To generate an entity object, follow these steps:
Right-click on your model project in which you want to create entity, and select New from the context menu. JDeveloper may respond with the New Gallery dialog with a variety of options.
In the New Gallery dialog, expand the Business Tier node, select ADF Business Components, and then select Entity Object. When you confirm the selection by clicking on OK, JDeveloper displays the Create Entity Object wizard.
In the Create Entity Object wizard, you can browse through the schema objects and select the table for which you want to create an entity object, as shown in the following screen shot:
The remaining steps in the wizard's dialog will help you to modify the default properties, such as data types, attribute names, and so on, for entity attributes, and optionally generate Java classes to override the default behavior of entity objects.
In this example, we will generate an entity by selecting the
DEPARTMENTS table and modify the default name as
DepartmentEO. We will suffix
EO with all the entity names in the examples used in this book to improve the readability of the data model. We will skip the remaining steps, accepting the default values generated by the IDE.
In a very simplified form, a view object contains a query to retrieve data from the datasource and data shaping logic to be used by the client.
Right-click on your model project in which you want to create a view, and select New from the context menu to get the New Gallery window.
In the New Gallery dialog, expand the Business Tier node, select ADF Business Components, and then select View Object. When you confirm the selection by pressing OK, JDeveloper will display the Create View Object wizard as shown in the following screenshot:
In the first step of the Create View Object wizard, you can key in the name and select datasource for the view object. In this example, we will build a view object for the
DepartmentEOentity object that we created in the preceding section. Modify the default name for the view object as
DepartmentVO. We will suffix
VOwith all the view names in the examples used in this book to improve the readability of the data model. Click on Next to continue the wizard.
In the Entity Objects page of the wizard, select the entity object(s) for which you are building the query. In this example, you will select DepartmentEO and click on Next to continue.
The Attributes page displays the attributes from the selected entity objectsfrom the preceding step. You can select the attributes you want to include from each entity usage in the Available list and shuttle them to the Selected list. For DepartmentVO, we will select all the attributes of DepartmentEO by shuttling them to the Selected list.
You can continue with the wizard further if you want to customize the default settings of the view object by altering the default attribute properties that are originally copied from the entity object. The wizard will also let you override the default query in the next step. As the default settings are good enough for DepartmentVO used in our example, we will skip these steps by clicking on Finish.
The application module(s) wrap(s) the business service and data model of your application. An application can have multiple application modules depending on the complexity and logical grouping of the services.
Right-click on your model project in which you want to create an application module, and select New from the context menu.
In the New Gallery dialog, expand the Business Tier node, select ADF Business Components, and then select Application Module. After clicking on OK, JDeveloper will display the Create Application Module wizard, as shown in the following screenshot:
On the Name page, you can key in the name for the application module and optionally modify the package name. This example names the application module as
HRServiceAppModule. Click on Next to continue the creation of the application module.
The Data Model page of the wizard will let you expose the view object instances to the client by shuttling the view object(s) from the Available list to Data Model. In this example, we will add DepartmentVO to the application module as the DepartmentVO1 instance, which can be consumed from the client later. Either you can finish the wizard at this stage, leaving the default values set by the IDE as they are, or continue the wizard.
If you continue the wizard, the Application Modules page may help you to nest another application module (if any) under the current one to build composite services. The Java page of the wizard can be used to optionally generate the Java files for the application module, which can be used for adding custom business service methods. These steps can even be performed later during development by editing the existing application module definition.
When you finish generating business components from the database tables by following the steps that we have discussed earlier, JDeveloper will generate metadata XML files and optionally Java classes to hold component definitions for entity objects, view objects, and application modules. Let us take a quick look at the model project source for our example generated by the wizard.
DepartmentEO.xmlfile contains the name of the
DEPARTMENTStable that we selected for generating the entity and attribute definitions, reflecting the properties of the columns from the
HRServiceAppModule.xmlfile contains information about the view object instances and optional service method definitions. The view object instance used in our example is
<model-project-name>.jpxfile is used by both ADF design-time tools and runtime components. The
.jpxfile contains the pointers to business component definitions in the
modelproject, where each entry describes the package name and type of business components in the package. In more complex applications, it may also contain metadata for the shared application module, which is primarily used at runtime to share the same data between clients. This file is located in the package folder for your
When you create an application module, JDeveloper IDE automatically creates a data control that contains all the functionality of the application module. You can click on the refresh icon in the Data Controls panel window to view the data control generated for the application module that you added to the
The data control exposes the following:
View object instances as named data collection
Built-in operations on data collection and custom business methods
You can design a data bound user interface by dragging an item from the Data Controls panel and dropping it on a web page as a specific UI component.
To create a web page, perform the following steps:
Right-click on the view controller project and select New.
In New Gallery, expand Web Tier, and select JSF/Facelet. Select Page as item. Confirm the action by clicking on OK. Refer to the following screenshot:
In the Create JSF Page dialog, you can key in the name for the page and optionally select a template. We will use the Oracle Three Column Layout template to build the
departments.jsfpage for our example.
You can use the drag-and-drop offerings from JDeveloper to visually lay out controls on a page. To build a UI table displaying data from the
departmentsview object, you just need to drag the instance of the
departmentsview from the Data Controls panel and drop it on the page by choosing the desired display component available in the list. The following screenshot illustrates this feature:
It will be interesting to take a look at the
ViewController project source at this stage. When you drag-and-drop the
departments view object on the page, the IDE generates two metadata XML files to enable the data binding for the page.
departmentsPageDef.xml: The department page definition XML file is used at runtime to fetch the data when you access the page through the browser. This file will act as binding container for the web pages.
DataBindings.cpxfile defines the binding context for the entire application. This file acts as the registry for page definition files. It also holds metadata for the business services implementations.
adfm.xmlfile acts as the registry of registries, holding pointers to each registry metadata file used in the project. In our example,
adfm.xmlcontains the path for the
Wow… congratulations! You are done with the implementation even without writing a single line of Java code! We can run this application either by directly a deploying to the application server integrated with JDeveloper, or generating deployable artifact from the application source and then installing to the target server.
ADF applications are certified against Oracle WebLogic and IBM WebSphere Servers. Oracle ADF essential (free version of ADF) version is also certified against GlassFish 3.1 (or higher).
To run your page by using integrated WebLogic
Server, select the
.jsf page in the application navigator, right-click on it, and choose Run. When running a page by using the integrated application server, JDeveloper creates an exploded EAR at a location that has been pre-configured for the
server to look at. Then, the server follows the normal deployment process.
To deploy the application to a standalone server, we may need to prepare the application for deployment. This involves creating deployment profiles for each project and then generating a deployment profile for the whole application, including the required projects. Deployment profiles can be generated by choosing the New Deployment Profile option in the New Gallery window on your JDeveloper.
The last step is to generate the deployable artifacts, such as an Enterprise Archive (EAR) file, for the application by choosing the already created deployment profile. The Deploy option is available in your JDeveloper under the Build menu of main toolbar.
To learn more about deploying an ADF application to a standalone sever, refer to the Oracle Fusion Middleware Administrator's Guide documentation. To access the documentation visit http://www.oracle.com/technetwork/developer-tools/jdev/documentation/index.html and navigate to Oracle JDeveloper and ADF Documentation Library | Administrator's Guide. Use the search option to find specific topics.
In this chapter, you were introduced to Oracle ADF, its layered architecture, and the advantages of using ADF as an enterprise platform to build next generation applications. We also set up the development environment to use JDeveloper and ADF, and built a simple application to get a feel for the technology stack. This chapter is essential for the easy understanding of what we will learn in the rest of the book. In the coming chapters, we will examine various parts of the Oracle ADF framework in detail.
In the next chapter, we will discuss ADF Business Components, used for building your business services.