comparison between Apex and ADF
3,382 views
Skip to first unread message
amir hosein khanof
Jul 11, 2010, 1:42:24 AM7/11/10
to adf-met...@googlegroups.com
Dear All,
I want to invite everyone to participate in this discussion about ADF and Apex.
Mainly if the following aspect would be discussed, we would have a good comparison.
1. when to use Apex and when to use ADF?
2. how do you see the future of ADF and Apex.
3. is Apex good for a big-scale application?
4. which one is faster in developing DB-based (TPS) systems?
Thanks for your time,
I want to invite everyone to participate in this discussion about ADF and Apex.
Mainly if the following aspect would be discussed, we would have a good comparison.
1. when to use Apex and when to use ADF?
2. how do you see the future of ADF and Apex.
3. is Apex good for a big-scale application?
4. which one is faster in developing DB-based (TPS) systems?
Thanks for your time,
Simon Haslam
Jul 12, 2010, 7:35:36 AM7/12/10
to ADF Enterprise Methodology Group
Amir
Well, you can probably expect opinions leaning towards ADF given the
forum you've posted your question on..!
There are already discussions elsewhere on the web - a quick Google
came up with:
http://dgielis.blogspot.com/2007/12/apex-vs-adf-round-1.html
http://technology.amis.nl/blog/2674/apex-andor-adf-demonstrating-two-similar-yet-different-applications
http://tonguc.wordpress.com/2007/12/20/apex-vs-adf-study/
http://www.inside-oracle-apex.com/reply-to-amis-query-on-apex-and-adf-posting/
These (quite old) posts were triggered from interesting "head to head"
presentations that Lucas Jellema and Dimitri Gielis did in 2007, and
it's fair to say that both ADF and APEX have moved on a bit since then
- the principles are still the same though.
Note: there was lots of debate in the ADF world 2-3 years ago about
JHeadstart (a metadata generation layer that sits on top of ADF, and
sold separately). With the advent of ADF 11g and features such as task
flows and the UI Shell the interest in JHeadstart seems to me to have
fallen off a bit (though others may have a different opinion!). I
think JHeadstart+ADF cf APEX is a slightly different discussion.
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)
Finally, regarding the future of ADF: I suppose the situation is
similar to how Forms might have been in ~1997 - then there were plenty
of other technologies that worked with the Oracle database, but Forms
was going to have a long life to support Oracle Apps if nothing else.
The same is now true with ADF and Fusion Apps: ADF is clearly here to
stay as Oracle has already invested very many person-years in
applications built upon it, and those applications will be one of the
key revenue drivers for Oracle for the next decade. Whether ADF
becomes as popular a tool for building custom apps as Forms has been
remains to be seen (we're living in a very different IT world now, not
least because of OSS).
I know the above opinions aren't direct answers to your questions, but
hopefully provide useful background material. What would be great Amir
is, if at the end of your research, you could write a summary of your
findings which we could put on the wiki.
Simon
Well, you can probably expect opinions leaning towards ADF given the
forum you've posted your question on..!
There are already discussions elsewhere on the web - a quick Google
came up with:
http://dgielis.blogspot.com/2007/12/apex-vs-adf-round-1.html
http://technology.amis.nl/blog/2674/apex-andor-adf-demonstrating-two-similar-yet-different-applications
http://tonguc.wordpress.com/2007/12/20/apex-vs-adf-study/
http://www.inside-oracle-apex.com/reply-to-amis-query-on-apex-and-adf-posting/
These (quite old) posts were triggered from interesting "head to head"
presentations that Lucas Jellema and Dimitri Gielis did in 2007, and
it's fair to say that both ADF and APEX have moved on a bit since then
- the principles are still the same though.
Note: there was lots of debate in the ADF world 2-3 years ago about
JHeadstart (a metadata generation layer that sits on top of ADF, and
sold separately). With the advent of ADF 11g and features such as task
flows and the UI Shell the interest in JHeadstart seems to me to have
fallen off a bit (though others may have a different opinion!). I
think JHeadstart+ADF cf APEX is a slightly different discussion.
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)
Finally, regarding the future of ADF: I suppose the situation is
similar to how Forms might have been in ~1997 - then there were plenty
of other technologies that worked with the Oracle database, but Forms
was going to have a long life to support Oracle Apps if nothing else.
The same is now true with ADF and Fusion Apps: ADF is clearly here to
stay as Oracle has already invested very many person-years in
applications built upon it, and those applications will be one of the
key revenue drivers for Oracle for the next decade. Whether ADF
becomes as popular a tool for building custom apps as Forms has been
remains to be seen (we're living in a very different IT world now, not
least because of OSS).
I know the above opinions aren't direct answers to your questions, but
hopefully provide useful background material. What would be great Amir
is, if at the end of your research, you could write a summary of your
findings which we could put on the wiki.
Simon
steven davelaar
Jul 12, 2010, 8:27:21 AM7/12/10
to adf-met...@googlegroups.com
Simon,
Being chief architect of JHeadstart you are probably not surprised to see I have a different opinion :-)
It has been quiet for a while on the JHeadstart front because building JHeadstart 11 was a considerable effort.
For a few months now, we have a very stable JHeadstsrt 11 production release that leverages all the cool new ADF 11 concepts.
JHeadstart 11 still improves your productivity significantly, but probably even more important for this discussion group is the host of ADF 11 best practices that gets auto-implemented for you.
There is a free downloadable JHeadstart 11 evaluation version, and a very comprehensive tutorial at http://www.oracle.com/technology/products/jheadstart/tutorial/index.html.
JHeadstart-generated taskflows can easily be reused with the UIShell page template, and in the next service update this integration will be completely declarative (you just specify "DynamicTabs"as the page template to use). Functionality to automatically mark a dynamic tab as dirty when the user made changes is also included.
Regards,
Steven.
Being chief architect of JHeadstart you are probably not surprised to see I have a different opinion :-)
It has been quiet for a while on the JHeadstart front because building JHeadstart 11 was a considerable effort.
For a few months now, we have a very stable JHeadstsrt 11 production release that leverages all the cool new ADF 11 concepts.
JHeadstart 11 still improves your productivity significantly, but probably even more important for this discussion group is the host of ADF 11 best practices that gets auto-implemented for you.
There is a free downloadable JHeadstart 11 evaluation version, and a very comprehensive tutorial at http://www.oracle.com/technology/products/jheadstart/tutorial/index.html.
JHeadstart-generated taskflows can easily be reused with the UIShell page template, and in the next service update this integration will be completely declarative (you just specify "DynamicTabs"as the page template to use). Functionality to automatically mark a dynamic tab as dirty when the user made changes is also included.
Regards,
Steven.
--
| Steven
Davelaar| Technology Director | Oracle Consulting Tel +31 30 669 8113 | Fax +31 30 669 9966 Oracle Nederland BV | Rijnzathe 6, 3454 PV De Meern, The Netherlands PO Box 147, 3454 ZJ De Meern,The Netherlands | KvK nr. 30096087 |
| Oracle Expert Services | JHeadstart |
amir hosein khanof
Jul 12, 2010, 8:34:28 AM7/12/10
to adf-met...@googlegroups.com
Simon,
Thanks for your comprehensive article regarding the subject, you know these days many of my clients are talking about Apex they thought that Apex is more easier and faster than ADF, which is annoying for me. because I see ADF very powerful.
Maybe this kind of thought about Apex has came from Oracle Website, maybe Oracle is not defining clearly which technology is more appropriate for which kind of systems.
This lack of clarification would result in a race between Oracle products.
Regarding the ADF, I have been working with ADF more than 3 years and I am supervisor of a development team but you know ADF is very vast and coverage many of these days clients request such as Web and Mobile and Ajax and rapid development.
But believe me that ADF when you develop a big-scale project with it, would result is lots of trouble.
For example the Active/passive for AM is not as good as it seems when the scale of the applications and users are middle-size.
And, I read most of the documents and reviews and Forums and Blog about ADF, my conception is that Oracle and other ADF-fans are trying to show ADF as a lots-of-features framework, but you know if ADF is going to be a replacement for Forms in the years of 1997 it must be as robust as forms.
On those days we had lots of big-scale application with Forms and Reports and as far as the Database was good the application was good too.
But this is not the case with ADF, I can not be sure about lack of performance in ADF for big-scale projects but this is what I have been get from ADF up to now.
I hope Oracle pay more attention to the performance of ADF for big-scale projects than adding fancy feature to ADF. otherwise it can not be a good replacement for Forms or other J2EE frameworks.
Thanks for your post again.
Amir
--
Amir Khanof
Senior Oracle MiddleWare Developer
+989122124673
+982181981721
Thanks for your comprehensive article regarding the subject, you know these days many of my clients are talking about Apex they thought that Apex is more easier and faster than ADF, which is annoying for me. because I see ADF very powerful.
Maybe this kind of thought about Apex has came from Oracle Website, maybe Oracle is not defining clearly which technology is more appropriate for which kind of systems.
This lack of clarification would result in a race between Oracle products.
Regarding the ADF, I have been working with ADF more than 3 years and I am supervisor of a development team but you know ADF is very vast and coverage many of these days clients request such as Web and Mobile and Ajax and rapid development.
But believe me that ADF when you develop a big-scale project with it, would result is lots of trouble.
For example the Active/passive for AM is not as good as it seems when the scale of the applications and users are middle-size.
And, I read most of the documents and reviews and Forums and Blog about ADF, my conception is that Oracle and other ADF-fans are trying to show ADF as a lots-of-features framework, but you know if ADF is going to be a replacement for Forms in the years of 1997 it must be as robust as forms.
On those days we had lots of big-scale application with Forms and Reports and as far as the Database was good the application was good too.
But this is not the case with ADF, I can not be sure about lack of performance in ADF for big-scale projects but this is what I have been get from ADF up to now.
I hope Oracle pay more attention to the performance of ADF for big-scale projects than adding fancy feature to ADF. otherwise it can not be a good replacement for Forms or other J2EE frameworks.
Thanks for your post again.
Amir
--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
--
Amir Khanof
Senior Oracle MiddleWare Developer
+989122124673
+982181981721
Steve McK
Jul 12, 2010, 11:03:08 AM7/12/10
to ADF Enterprise Methodology Group
1. No right or wrong answer here. Spent time researching this and
that was my unhelpful conclusion. There also seems to be two Oracle
camps who, good naturedly, perpetuate the argument that one tool can
do everything the other can. Our 'rule of thumb' is that APEX should
be used for single business unit (Access type) solutions with a single
developer. These can be internal or external facing. For corporate
level solutions using larger teams we would use Forms or ADF. APEX is
still more difficult to manage for larger team developments. But it's
really down to local management to decide not a 'correct' technology
decision.
2. Oracle are commited to both development tools and as they are
complementary I don't see this as an issue.
3. Given a big-scale application is likely to need a big-scale
development team I would say APEX isn't the best for managing the
development team and configuration management/version control that
would be required. So a management decision is required.
4. No right or wrong answer here either. It depends on the
Application Development Lifecycle environments that you have set up
and the trained resource available for your project. If you already
have a stable Data Model you can generate a first cut system quickly
with either technology.
From scratch I would say it is quicker to train a developer to use
APEX than JDeveloper with ADF. Does that make APEX faster?
that was my unhelpful conclusion. There also seems to be two Oracle
camps who, good naturedly, perpetuate the argument that one tool can
do everything the other can. Our 'rule of thumb' is that APEX should
be used for single business unit (Access type) solutions with a single
developer. These can be internal or external facing. For corporate
level solutions using larger teams we would use Forms or ADF. APEX is
still more difficult to manage for larger team developments. But it's
really down to local management to decide not a 'correct' technology
decision.
2. Oracle are commited to both development tools and as they are
complementary I don't see this as an issue.
3. Given a big-scale application is likely to need a big-scale
development team I would say APEX isn't the best for managing the
development team and configuration management/version control that
would be required. So a management decision is required.
4. No right or wrong answer here either. It depends on the
Application Development Lifecycle environments that you have set up
and the trained resource available for your project. If you already
have a stable Data Model you can generate a first cut system quickly
with either technology.
From scratch I would say it is quicker to train a developer to use
APEX than JDeveloper with ADF. Does that make APEX faster?
Shay Shmeltzer
Jul 12, 2010, 12:05:43 PM7/12/10
to adf-met...@googlegroups.com
I think that at the end of the day the question comes down to
architectural differences.
I'll list some of the things that I think differentiate ADF - then it is
up to you to decide if this is important to your specific project.
architectural differences.
I'll list some of the things that I think differentiate ADF - then it is
up to you to decide if this is important to your specific project.
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.
Reusability - ADF allows you to package components for reuse including
ADF BC, ADF Faces declarative components, and ADF Task flows.
Team development - JDeveloper integrates with version management tools,
bug/issue tracking tools.
Development cycle - JDeveloper has debuggers, profilers, code audit and
integration with build tools and testing tools etc.
I think by now you get the picture of what I'm aiming for.
So yeah I guess with both tools you can quickly point to a table in the
DB and create a Web page that access it. But the underlying capabilities
are different. You might not need all of those for every application -
but sometime an application that starts small ends up growing bigger
over time.
Shay
steven davelaar
Jul 12, 2010, 2:39:50 PM7/12/10
to adf-met...@googlegroups.com
There is also a more recent ADF vs APEX thread on Linked In Oracle*Pro
group (requires linked-in acount):
http://www.linkedin.com/groupItem?view=&gid=60191&type=member&item=22111073&qid=ec30cc3b-99b5-4319-a296-c97598b2d7e1&goback=.gmp_60191
http://www.linkedin.com/groupItem?view=&gid=60191&type=member&item=22111073&qid=ec30cc3b-99b5-4319-a296-c97598b2d7e1&goback=.gmp_60191
Steven.
On 12-07-2010 1:35 PM, Simon Haslam wrote:
Jean-Marc Desvaux
Jul 13, 2010, 10:55:47 AM7/13/10
to ADF Enterprise Methodology Group
Above any technical comparison, I think it's essential for people
falling into the PL/SQL/Forms/DB developers category to make the
necessary move and effort to better know middleware capabilities for
the future and not limit the IT Shop capabilites to APEX & Forms.
The road to ADF is steep but to my opinion it has to be seen as an
investment in new huge potential capabilities for the future and not
just as an upgrade path from Forms.
Jean-Marc
falling into the PL/SQL/Forms/DB developers category to make the
necessary move and effort to better know middleware capabilities for
the future and not limit the IT Shop capabilites to APEX & Forms.
The road to ADF is steep but to my opinion it has to be seen as an
investment in new huge potential capabilities for the future and not
just as an upgrade path from Forms.
Jean-Marc
Grant Ronald
Jul 15, 2010, 9:02:32 AM7/15/10
to adf-met...@googlegroups.com
Amir, I think you might be in danger of mixing up topics in this thread
- For a discussion on when to use APEX vs ADF you can check out
http://www.oracle.com/technology/products/forms/pdf/apex_forms_jdev.pdf
This might address your original question.
- For a discussion on when to use APEX vs ADF you can check out
http://www.oracle.com/technology/products/forms/pdf/apex_forms_jdev.pdf
This might address your original question.
For general concerns about ADF specifics I think its better to start a
new thread.
I'd also point out that strictly speaking ADF is not a replacement for
Forms - although you can.
Reagrds
grant
> <mailto:amir.kha...@gmail.com>> wrote:
> > Dear All,
> >
> > I want to invite everyone to participate in this discussion
> about ADF and
> > Apex.
> > Mainly if the following aspect would be discussed, we would have
> a good
> > comparison.
> >
> > 1. when to use Apex and when to use ADF?
> > 2. how do you see the future of ADF and Apex.
> > 3. is Apex good for a big-scale application?
> > 4. which one is faster in developing DB-based (TPS) systems?
> >
> > Thanks for your time,
>
> --
> You received this message because you are subscribed to the ADF
> Enterprise Methodology Group
> (http://groups.google.com/group/adf-methodology). To unsubscribe
> send email to adf-methodolo...@googlegroups.com
> <mailto:adf-methodology%2Bunsu...@googlegroups.com>
amir hosein khanof
Jul 15, 2010, 10:26:26 AM7/15/10
to adf-met...@googlegroups.com
Hi Grand,
Regarding the new post for talking about specification of ADF for Large-scale applications development,thanks for your comment, and I will start a new post for it and maybe it is better, I wait to see the topic of Andrejuis in the OOW 2010 and then I start a new post.
Regarding the PDF you sent, I really appreciate it, that was really what I need :) and I am some how frustrated that why I do not see this before in Oracle Website!, thanks.
But regarding your opinion that ADF is not a replacement for Forms I think that you may misunderstand my sentence.
Of course ADF is not a pure replacement for Forms, as, not any 3 tier technology would be a replacement for any 2 tier technologies, but the Oracle ,as the leader, and all the companies that has been working with form 6i are offered by professionals to upgrade/migrate their old (maybe can call it legacy also!) technology of Form 6i to ADF or Forms 10g, which basically, adopting the ADF is more reasonable than Form 10g mainly because Forms 10g is based upon (applet..) ,not a thin client (applet is somehow thick client). Besides, they have the option to choose .Net or J2EE which is not cost-effective, you know the reason of course.
.
Also maybe that is why we see many companies, serving the migration/upgrade from Forms to ADF and you may know some tools that is doing so.
In the end, although the Forms and ADF are totally different in nature but because of some reason such as the similarity of ADF business model to Forms or easily learn of ADF(about 40 hrs) for Form-developers and also the rich feature of ADF as a truly thin-client, web-based technology and many other facts, these days, there is lots of requests from companies to migrate their development technology or their old systems to ADF, benefiting web and SOA architecture.
Up to know, in our territory(just as a sample) we have more than 30 big companies willing to switch from Form to ADF but we have not even 1 company that works with J2EE and wants to migrate or use ADF(ADF BC + ADF Faces ) neither any .Net based company willing to use ADF.
At last, thanks for your comment,I would sum up the comparison of ADF/Apex/Jheadstart cons and pros feature in this thread soon.
Regarding the new post for talking about specification of ADF for Large-scale applications development,thanks for your comment, and I will start a new post for it and maybe it is better, I wait to see the topic of Andrejuis in the OOW 2010 and then I start a new post.
Regarding the PDF you sent, I really appreciate it, that was really what I need :) and I am some how frustrated that why I do not see this before in Oracle Website!, thanks.
But regarding your opinion that ADF is not a replacement for Forms I think that you may misunderstand my sentence.
Of course ADF is not a pure replacement for Forms, as, not any 3 tier technology would be a replacement for any 2 tier technologies, but the Oracle ,as the leader, and all the companies that has been working with form 6i are offered by professionals to upgrade/migrate their old (maybe can call it legacy also!) technology of Form 6i to ADF or Forms 10g, which basically, adopting the ADF is more reasonable than Form 10g mainly because Forms 10g is based upon (applet..) ,not a thin client (applet is somehow thick client). Besides, they have the option to choose .Net or J2EE which is not cost-effective, you know the reason of course.
.
Also maybe that is why we see many companies, serving the migration/upgrade from Forms to ADF and you may know some tools that is doing so.
In the end, although the Forms and ADF are totally different in nature but because of some reason such as the similarity of ADF business model to Forms or easily learn of ADF(about 40 hrs) for Form-developers and also the rich feature of ADF as a truly thin-client, web-based technology and many other facts, these days, there is lots of requests from companies to migrate their development technology or their old systems to ADF, benefiting web and SOA architecture.
Up to know, in our territory(just as a sample) we have more than 30 big companies willing to switch from Form to ADF but we have not even 1 company that works with J2EE and wants to migrate or use ADF(ADF BC + ADF Faces ) neither any .Net based company willing to use ADF.
At last, thanks for your comment,I would sum up the comparison of ADF/Apex/Jheadstart cons and pros feature in this thread soon.
Reply all
Reply to author
Forward
0 new messages