Steps Did:: - Comparison Entre APEX Et ADF

The document discusses different approaches for integrating Oracle APEX applications developed in Oracle PaaS with Oracle SaaS. It provides steps taken to integrate an APEX application and suggests that integration can be done by registering APEX pages in SaaS via page integration or by creating a page entry in the structure in static or dynamic mode.

Uploaded by

hajerhamid

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as DOCX, PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

47 views3 pages

Steps Did:: - Comparison Entre APEX Et ADF

Uploaded by

hajerhamid

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as DOCX, PDF, TXT or read online on Scribd

You are on page 1/ 3

to integrate Oracle APEX application/Pages(Developed in Oracle PaaS) to Oracle SaaS.

Please
review below steps. If below steps are not right approach to integrate, Please suggest me what will
be right approach for integrating PaaS Apex pages to SaaS.

Steps did:
1. We have created database in Oracle PaaS and enabled required ports for APEX development.
2. Developed APEX application in Oracle PaaS Database.
3. Now able to access APEX application as standalone.
Integration:
we can register APEX pages in SaaS in 3 ways. One of the way has worked out for me.

Solution:
we can register via page integration
we can register via Structure -- > Create page entry
we can register via Structure -- > Create page entry --> can go like Static
we can register via Structure -- > Create page entry --> can go like Dynamic

---------Comparison entre APEX et ADF

Instead, you must first determine if your application is

 Data-driven, or
 User interface driven

A data-driven application is one where the data structure determines the user
interface. Existing Oracle Forms applications tend to fall into this category, and if you
only want to do a one-to-one replacement of a Forms application, the wizard-driven,
browser-based approach of APEX works well.

A user interface driven application is one that starts from a set of requirements to

support a work process. This is typically the case for new application development, or
where an existing Oracle Forms application is being redesigned. User interface driven
applications are typically specified with detailed screen designs that are easier to
implement with the flexible architecture of ADF.

There's no doubt in my mind that APEX is quicker to get started with

than ADF - with APEX you don't have to have the same talent for
development and the initial learning curve is much less steep than
ADF. That said, once a developer is properly up to speed with ADF I
really do believe they are just as productive as someone working APEX,
even with pure DB-based systems. Once you start getting more demanding
requirements - web services, fancier UI layouts, mobile clients, code
reuse, etc - then I think ADF will start to be more productive as most
stuff is built into the framework or JDev.

I still see APEX as an ideal fit for "Access replacement" projects

which is how Oracle initially marketed it. Most organisations have
lots of Access/Excel "mini applications" that have been developed in
an ad-hoc manner (often by business users) and yet many of them will
have become quite important. If these applications are (re)built in
APEX they can have centralised management and control (distribution,
backup, monitoring etc). APEX is also great for DBA automation-style
projects - it's included (i.e. no extra licence cost) and installed by
default with the database and the DBA team can pick it up without
training.

Finally, you may need to consider non-functional requirements like

performance and security:

1) Performance: the big question for me with APEX is how big do you
need to make your database server? If you only have lots of smallish
APEX apps this may be a non-issue, since most modern hardware is
pretty fast anyway. If you're trying to scale up to hundreds or
thousands of users then the architecture of the product needs careful
examination, and I would suggest ADF has far more potential here than
APEX.

2) Security: Firstly, I would say out-of-the-box ADF is more secure

than APEX since the user interaction and application logic is further
away from the database layer. APEX has the option of using a web
server, but ultimately it is still generating content directly out of
the database. Secondly, for demanding UI requirements, you should be
able to do more with the Oracle-tested ADF components than having to
write your own Javascript etc. Therefore using ADF reduces the risk of
you introducing vulnerabilities in custom code.

So in my opinion, APEX is great for applications that might be:

* internal
* tactical or low-budget
* have very short delivery timescales
* developed by one or two people

ADF is probably more suitable for:

* core, strategic systems
* supporting large numbers of users
* apps that are integrated with many other systems, inc SOA
* skilled development teams
* product development (i.e. as sold by ISVs)

MVC - ADF separates the layers - which gives you more flexibility to
change each layer separately and to reuse components from various layers

Component based UI - ADF uses a set of components to do declarative UI

development, which eliminates a lot of the low level Javascript,XHTML,
DOM, Flash coding. It also provides more advanced components, and can
achieve more complex layouts.

Reusable business services - you can reuse your business services in
other systems (ADF Libs), and you can also expose them through other
interfaces (Web services).

Multi-Chanel access - ADF let you develop Mobile, Web, Desktop and Excel
front end to your business services.

Multi-backend services - ADF let you access ADF BC, EJB, Java classes,
Web services, files, XML and more and easily bind to all.