Advantages of ADF over alternatives

[Ajay Koranne]

Hi All,

On my current project, the client is wondering what are advantages
over other alternatives like Spring MVC or Wicket?
My client is mainly from the open-source background. With management
shuffle, they decided to get Fusion stack (Webcenter, ADF, SOA,
BPEL).

We are on the first project are about a month into it and it is due in
2 months. In my experience, to learn ADF can take from 3-5 months. So,
we are pretty in the learning period. Add to that, the reluctance of
most developers (they would rather use Glassfish or Jetty instead of
Weblogic and CXF instead of the SOA suite for web services), and the
developer community is frustrated.

Add to that, Oracle hasn't made things easier. The upgrade to PS2
could not have been more extensive. To setup all environments in
clustering with load balancing takes over 10 days. And not mention the
open SR we have with Oracle for missing keystore issue in PS2. That is
also the reason, why the roles are propagated from the portal to the
portlet.

So, given all this, I can understand the frustration. And I would like
to give a good answer, why the client should continue on ADF and how
there is a big payout at the end. Sadly, I am coming up short on words
and discussion points.

So, to all the ADF gurus, why should my client not dump ADF and move
to alternative technology?
Any thoughts?

Thanks,
--ajay

[Chris Muir]

Hi Ajay

Phew, a bit of a moving target of questions there, as a suggestion try to focus on one thing at a time.

Anyway I'll let others chime in with their experiences of why they did/didn't adopt ADF over other solutions including open-source, .Net etc.  However I'll point out we published a page on the ADF EMG sometime back "How to convince others to adopt ADF & JDeveloper" and specifically the section "How to convince 'Java programmers' to adopt ADF & JDeveloper" hopefully will be relevant to you:

http://groups.google.com/group/adf-methodology/web/how-to-convince-others-to-adopt-adf-jdeveloper?hl=en

A final anecdote from down here in Australia, we have 2 popular locally made cars, "Commodores and Fords" as they're known (owned by GM and Ford respectively).  Sometimes it doesn't matter if one manufacturer releases a better model than the other, the Commodore fans love their Commodores regardless, and the Ford guys still rant on about Fords, there's no point persuading them otherwise.  But, in the end if the missus (the boss in my house hold) bought one over the other, that's what you're stuck with ;-)

Cheers,

CM.

--
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

--
Chris Muir

Oracle Systems Consultant & Trainer
SAGE Computing Services Pty Ltd
http://www.sagecomputing.com.au

Oracle ACE Director
http://www.oracle.com/technology/community/oracle_ace/index.html

Email: chris...@sagecomputing.com.au
Blog: http://one-size-doesnt-fit-all.blogspot.com/
Mobile/Cell: 043-828-6421
International: +61-43-828-6421
Gmail chat: chris...@gmail.com
Twitter: twitter.com/chriscmuir
LinkedIn: http://www.linkedin.com/in/chriscmuir

[Shay Shmeltzer]

We listed some of the advantages and benefits of ADF here:

http://www.oracle.com/technology/products/adf/pdf/ADF_11_overview.pdf

One aspect that is not covered there is the completeness of the
solution especially when you take into account the built in
integration with the Oracle SOA suite and WebCenter.

On the technical innovation front I don't think you'll find
equivalents out there to the ADF controller's reusability, richness of
components of ADF Faces, the ease of binding UI, or the customization
offered by MDS.

Shay

Shay Shmeltzer
Senior Group manager
Oracle

[Zeeshan Baig]

Hi,

In addition to the above suggestions If you are using Oracle database
so its better to get complete solution from one vendor instead of
going here and there. Oracle ADF and SOA suite gives you all tightly
integrate technology solutions within one IDE i.e JDeveloper so
developers life becomes easier.

Best Regards,
Zeeshan Baig
My Oracle Blog: http://baigsorcl.blogspot.com/
Twitter: http://twitter.com/baigsorcl

[Grant Ronald]

Ajay, it is not clear from your email if the "10 day" frustration is
specifically down to ADF to whether it is to do with a more general
middleware issue (which you would have had if you had used some other
tool/framework with the same middleware).
Also, when you mention developers wanted to use Glassfish, are you
comparing like with like? Would you get everything you need if you use
Glassfish? If you are using the Fusion stack with Webcenter, SOA, BPEL)
then its like comparing a Fiat Punto to a Hummer :-)

You'll always have the philosophical discussions with developers who
will often want use what they know best (it's understandable), but I
think you have to accept there is a learning curve with new
technologies/frameworks/tools that, in the long run, make life simpler -
otherwise we'd all be writing our applications in notepad.

If there are specific ADF concerns it would be good to break then out
here so we can address them

Regards
Grant

[Jean-Marc Desvaux]

Hi Ajay,

The problem of not getting developers inside the project equation is
indeed a huge one.
Adding to it a delivery target of 2 months is a "near suicide" and ADF
won't be the cause.

The fact today is that you have two kind of ADF developers, the one
from an Oracle backgrounds (driving Fords for years as mentionned by
Chris... Sorry Chris if you are driving a Commodore..), those from an
open-source background and a few ADF experts.
Though, the ADF community is growing, you can't find easily developers
with a good ADF experience, instead you can find open-source
developers ... but most of the time relatively reluctant to everything
not open-source.

I also think it's easier to convince at strategic level with a long
term roadmap instead of a pure technical comparison based on the
current state of technologies.
But this is hard when you have a 2 months roadmap...
The only thing I see is maybe to challenge some of the developers to
build a small application with ADF and others with the open-source
technology and discuss/compare productivity etc.. this will involve
developers in the change process. Add to it the strategic aspects and
try to gain a majority for ADF.

Good luck.
Jean-Marc

[Ajay Koranne]

Hi All,

First thank you for taking time and responding to my query. I really
appreciate it.
Second, Grant you are right. I kinda went on a rant here. I should
compile the ADF issues more precisely and not generalize it.
So, here is my list of issues on ADF side.

1. With each version of JDeveloper, it seems like the resource needs
are increasing constantly. The size of the java-script (used for
client-side scripting keeps increasing). Why is that?

2. The size of the page is huge compared to other technologies. The
app we are developing is to be exposed to external parties (outside
the company). If the page size is huge, it affects the performance of
the page because too much data is needed to be transmitted. I don't
have specific numbers to back it up, but in my observation the page
size seems to be increasing with new release of JDev. This could very
well be the an issue related to #1 mentioned earlier.

3. Ajax calls! I understand the use of Ajax and its value. But
seriously, can't the Ajax call be made more intelligent? When I click
on the icon to collapse a PanelBox why does it have to make a round
trip to the server?
When I click on the date-picker on an input date field, why does it
have to make a round trip? I have seen Avarom's and Frank's article on
how to add clientlistener and cancel the event, but that works some
times and feels more like a band-aid solution. Why can't ADF (as a
framework) figure a simple thing?

The problem with this approach is, if I have 5 select boxes on the
page, that Ajax call forces it to refresh all those boxes. That in
itself is crazy. If I am updating one component, why does it have to
refresh every look-up on the page? Fixing this, in my opinion, will
the biggest bang for the buck for Oracle.

4. Building an ADF ear file. Why do I need to install the darn
JDeveloper just to build a freaking ear? Has anyone in Oracle ever
thought how idiotic that argument is? Especially with JDeveloper
taking a Gig of disk space, it is a very difficult sale.

These are just some issues for starters. I will add more later.
I just want to say upfront, that I am not trying to offend anyone. I
am just frustrated.

Any thoughts anyone.
Thanks,
--ajay

[Andrejus Baranovskis]

Hi Ajay,

In order to expose ADF apps on public/external network, you will need to setup Oracle WebTier (WebCache + HTTP server) to cache and compress Web content. I documented it, based on previous project experience - http://andrejusb.blogspot.com/2010/06/oracle-webtier-11g-configuration-for.html

Without WebTier, it will be really problematic to access large ADF pages, as you are saying.

If you build EAR without using OJDeploy (with plain ANT for example) - no need to install JDeveloper on deployment server. Its enough to install Application Development Runtime package, it contains all ADF libraries (JRF files).

Regards,

Andrejus

--
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

--
Oracle ACE Director

My Blog - http://andrejusb.blogspot.com/
My JDev/ADF Samples list - http://andrejusb-samples.blogspot.com/

[Ajay Koranne]

Hi Andrejus,

Thanks for your reply. Yes, we have entire infrastructure including
load balancing when we go to production. That, I believe, does include
web tier. I have to look if it includes Web Cache or no. We are still
developing.

As for building the EAR, the requirement of installing anything other
than Ant or maven itself, in my view an overhead. Yeah, I can get away
with Application Development runtime package, but still it is an extra
installation. Yeah it might not be a gig size still it is a very
vendor specific way of doing builds.

Why can't I just make a build using Ant or Maven? Yes, it is my
responsibility then to figuring out the libraries needed. The real
problem I have with OJDeploy is at the time of building the ear file,
it creates some files on the fly and add its to the ear. If that
wasn't the case, I could very well copy all libraries and archive them
into an ear with a simple ant script. What is the idea behind OJDeploy
building files at its runtime and putting in the ear?

Can you shed some light on it?
Thanks,
--ajay

On Jun 18, 9:24 am, Andrejus Baranovskis

<andrejus.baranovs...@gmail.com> wrote:
> Hi Ajay,
>
> In order to expose ADF apps on public/external network, you will need to
> setup Oracle WebTier (WebCache + HTTP server) to cache and compress Web

> content. I documented it, based on previous project experience -http://andrejusb.blogspot.com/2010/06/oracle-webtier-11g-configuratio...

>
> Without WebTier, it will be really problematic to access large ADF pages, as
> you are saying.
>
> If you build EAR without using OJDeploy (with plain ANT for example) - no
> need to install JDeveloper on deployment server. Its enough to install
> Application Development Runtime package, it contains all ADF libraries (JRF
> files).
>
> Regards,
> Andrejus
>

> > unsubscribe send email to adf-methodolo...@googlegroups.com<adf-methodology%2Bunsu...@googlegroups.com>
>
> --
> Oracle ACE Director
>
> My Blog -http://andrejusb.blogspot.com/

[Simon Lessard]

Hi Ajay,

I'm not sure why you were not able to create an EAR file using only Maven; we do so on our project without any problem. However, we deployed the ADF library directly on WLS as shared libraries so that may be why we were able to.

For the increased JS size, have you checked the partitioning feature? Each version adds new components and component have JS files attached to them so if you disable partitioning, it's understandable that the JS file size increase with every releases.

As for AJAX, it's a more complicated issue. I'm not sure the panelBox goes to the server for its collapse unless there's a discloseListener, but it certainly does for the expand, which is understandable. For the inputDate, it has to do first some locale elements I think as well as disabled days, but that one could probably be modified to be handled on the client completely.

About the page size now, I kind of agree with this one, ADF Faces does produce more HTML than it should, ie some components could have used simpler structure. That being said, I don't think the size delta is going to matter that much with today bandwidth, so I consider this point kind of moot.

Finally, the migration issues. Sadly, I have to agree whole-hearty about that one. I migrated 2 different projects for a total of about 6 times in the past years and none took less than 2 weeks, it was getting so critical that we just skipped the last one, we're going to migrate only during the evolution phase to not put the release schedule in peril. That being said, with the very short calendar target you had (2 months), attempting a migration altogether might not have been the best idea, even if some bug fixes looked irresistible. Trying out a new technology on such a short term project was also a questionable management decision imho.


Regards,

~ Simon

[Andrejus Baranovskis]

Hi Ajay,

Yes, you are right - we can't simply build ADF app without OJDeploy, only using ANT scripts. When packaging and producing WAR/EAR, additional metadata files/information is added into package. Same metadata is created when you build directly from JDeveloper or from outside using OJDeploy.

In my first project, with early 11g releases, we were building with ANT scripts and we were implementing custom parsing logic and generating required metadata by ourselves. Real pain with this approach, when migrating to new ADF release - lots of work to rewrite and update build scripts.

Its why I prefer to use 1 GB disk space and run OJDeploy, it builds my apps on different ADF versions, and no need to change build scripts.

Regards,

Andrejus

My Blog - http://andrejusb.blogspot.com/

[Ajay Koranne]

Hi All,

Thank you for your input. I appreciate you all taking time and
responding. However, I must admit, I find these responses inept.

One thing I learned in 20 years of my career, technology is a tool. It
is a tool to help business. None of the responses above give me a
business reason. I am looking for something that says, if the client
continues with ADF, it will be very easy to build Portal or they can
leverage all existing legacy systems much better in Webcenter than may
be in a life-ray portal or something on that level. Something that I
can sell to my client as a business case.

I made it amply clear to my client, on more than one occasion, using
ADF or Webcenter or the Oracle stack for one project is a bad idea. It
is an over kill and possibly a waste of time and resources. If you
want to use the Oracle stack, you must have a clear vision on what the
final goal is. Also there must be a road map to achieve that vision.
Only then I can give an educated recommendation on ADF, Webcenter and
rest of the Oracle stack.

I know it will go against fiber of your being, but for a moment, can
you please stop being techies and think in terms of business
reasoning? I know this is an ADF methodology group. But, I hope, you
experts can provide me some business reasoning too. You ADF gurus
should be able to provide a more appropriate answer to a simple
question, what are the advantages of ADF?

I must say, in all my integrity and professionalism, right now,
reading your answers, I cannot go to my client and tell them that they
should continue with ADF.

I sincerely apologize, if you find my tone harsh or offending anyone.
That is not my intent. I am just hoping to get some answers.

Thank you in advance!
Sincerely,
--ajay

On Jun 19, 5:30 am, Andrejus Baranovskis
<andrejus.baranovs...@gmail.com> wrote:
> Hi Ajay,
>

> Yes, you are right - we can't simply build ADF app without OJDeploy, only
> using ANT scripts. When packaging and producing WAR/EAR, additional metadata
> files/information is added into package. Same metadata is created when you
> build directly from JDeveloper or from outside using OJDeploy.
>
> In my first project, with early 11g releases, we were building with ANT
> scripts and we were implementing custom parsing logic and generating
> required metadata by ourselves. Real pain with this approach, when migrating
> to new ADF release - lots of work to rewrite and update build scripts.
>
> Its why I prefer to use 1 GB disk space and run OJDeploy, it builds my apps
> on different ADF versions, and no need to change build scripts.
>
> Regards,
> Andrejus
>

> > <adf-methodology%2Bunsu...@googlegroups.com<adf-methodology%252Buns...@googlegroups.com>

[Simon Haslam]

OK Ajay, before you get carried away calling the responses "inept" can
I highlight a few points:

1) As you acknowledge, the people who have responded to your question
had done so out of their own generiosity and many will have done it in
their own time.

2) You have mixed up both technical and strategic points in your
questions. It is unfair to then criticise people for giving technical
answers.

3) Members of the ADF EMG are in the whole looking for best practices
for building ADF-based systems. By and large the decision for them to
use ADF has already been taken. As you know new software tools come
and go all the time (particularly with Open Source) so you it is
unlikely that someone who invests a lot of their time in ADF is likely
to keep up with them all.

4) As I'm sure you recognise, unless your application is simple, the
odds of an on-time and on-budget delivery are stacked against it if it
seriously has only has a 2-3 month duration and no-one on the team
knows ADF. I think this would be true for any "enterprise-grade"
development environment, not just ADF.

5) Correct me if I'm wrong, but aren't you acting as a consultant to
your customer? In which case I would expect it is your job to
understand both your customer's requirements and the available
technologies, and then provide a balanced recommendation in your
customer's best interest.


Finally, Chris and I try to take a light-handed role in moderation of
the EMG but rudeness and table thumping will not be tolerated. I
realise you are frustrated with ADF at the moment. Possibily you feel
it's being forced on you by management and you'd rather use something
else. Either way there's no point venting your frustration on the
group.

So, why don't you write up what you've found out so far about the pros
and cons of ADF, post it here and then ask people to suggest if you've
misunderstood or forgotten anything? Alternatively why don't you
approach Oracle or an Oracle Partner for advice - products like SOA
Suite and WebCenter are high value and they will be able to help you
work on the business case.


Simon
ADF EMG Joint Moderator

On Jun 20, 5:10 am, Ajay Koranne <akora...@gmail.com> wrote:
> Hi All,
>

[Michael Koniotiakis]

Hey Ajay

The business reason you are looking for is:
--> It sells.

More and more software development companies deside to invest on
oracle tools.

I am a technical guy also, yet i see increased requests for ADF
experts, developers, etc.

I know companies, changing from microsoft or opensource to ADF (as
your's)

I know customers asking for it and buying oracle fusion products.

Ofcourse the market is never stable but the risks going with Oracle is
less than going with opensource (i guess)

So since the market define the business i would say learning ADF is a
good investment.

> ...
>
> διαβάστε περισσότερα »- Απόκρυψη κειμένου σε παράθεση -
>
> - Εμφάνιση κειμένου σε παράθεση -

[Andrejus Baranovskis]

Hi Ajay,

Business reason depends on specific customer and probably can't be
really generic.

As Michael says, companies are evaluating Oracle Fusion and buying
Fusion products for production use. It comes as natural process -
based on market offer.

From my experience, customer decided to move entire company IT
environment to Oracle Fusion platform and train all developers (about
50 people with Forms and Java experience) on ADF. Their main business
reason was - Oracle Fusion gives entire platform you need for
business, no need to buy anything from other companies.

In other words - Software. Hardware. Complete. :)

Andrejus

> --
> 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
>

--
Oracle ACE Director

My Blog - http://andrejusb.blogspot.com/

[shay shmeltzer]

I know it will go against fiber of your being, but for a moment, can
you please stop being techies and think in terms of  business
reasoning?

Ajay, don't be surprised that you get technical answers when you post a question like this to a technical list - especially since your initial thread started as a rant on specific technical issues you had.

In any case, here are what I believe are the major business reasons customers choose ADF as their development platform:

1. Faster development cycle
With the visual and declarative approach a lot of the basics of your application can be done very rapidly, especially compared to the code centric approach of many of the open source frameworks out there. The development style also makes it simpler for newer developers to be productive faster (even if they need something a little bit more experienced to finish some tasks for them).

2. Complete solution
Instead of trying to tailor patches by choosing one framework for UI, another for O/R, another for controller, another for binding, another for security - ADF gives you a unified solution with all the parts working together. Add to this the unique capability to customize and personalize the application with MDS - something no other framework out there provides today.

3. Consistent development approach for multiple channels.
With ADF you use the same development style and technologies to build Web, desktop and mobile applications. You can reuse your business services and security across those different UIs. This also makes it easy for the developer to migrate between developing for different targets.

4. Built in integration with SOA
Automatic exposure of your business services as SDO components, easy consumption of Web services in your ADF UI, generation of human task lists, eventing between the layers and more.

5. Built in integration with WebCenter
Generate portlets from your flows, customize your pages, add portlets to your JSF pages, add document management to your JSF pages, add Web 2.0 services to your JSF application - all integrated out of the box using the same technology and same development tool and framework.

6. A reliable company
Support, training and consulting that back your chosen platform and that you can turn to in time of need.

7. Fusion Applications
Many companies who are today using Oracle's enterprise applications (EBS, PSFT, Siebel, JD-Edwards etc) realize that ADF is the platform they'll be using for future customizations of their next generation applications (Fusion Applications) - and using the same technology for their customized development simplifies their tooling/skills needs.

Shay

[BradW]

From a project perspective, here are my thoughts.

1) Adding a new technology with no expertise on the team has HUGE
risk.
2) What is being mandated by the client?
3) Is there any flexibility in the timeline? What about after
delivery?

Sometimes you need to get a solution to market by a certain date.
However, you may incurr technical debt along the way. So, you have a
three choices. 1) Go back to the client and get the proper resources
and develop it properly in ADF (Change Order) or 2) Develop it with
the existing team proficiencies and do a change order to the timeline
to remedy the solution after delivery or 3) Develop it with the
existing team proficiencies and let the client handle it in
sustainment.

REGARDLESS, all three options should involve a change order NOW so
that they are aware of the thechnical challenges you are having to
meet the timeline due to the teams experience with ADF. This is not a
slam on ADF, just the teams experience using ADF. To me, the project
was setup for failure by not having the proper resources to
competently (experience designing and developing several applications
using ADF) deliver an ADF application. The nice thing with this
approach is that the client is informed and they make the decision
that is best for the business (IT Sustainment team and the business
end users).

My two cents,


BradW