On the AMIS Technology blog, Lucas Jellema has posted an article : "EJB 3.0 Persistence Nieuwe Industriestandaard voor Java/Database communicatie"
blog : http://technology.amis.nl/blog/?p=993
article : http://www.amis.nl/tech_artikelen.php?id=297
The article is in Dutch, but near the end Lucas asks a pertinent question (my translation):
"Also the position of BC4J or ADF Business Components becomes less clear. I wonder how long Oracle will commit itself to ADF BC. Although, at the moment, this is what we get told related to Fusion Tools, I hear things within Oracle that suggest the focus could shift to EJB 3.0 ."
Is there anyone from Oracle that whishes to comment on this Oracle commitment to ADF BC? (Or is there an SOD for ADF BC available somewhere?)
I have had some further communications with reliable sources within Oracle that suggest there will be support for EJB 3.0 Persistence of some sort in ADF Business Components. My intial doubts were perhaps somewhat premature as it seems that we yet may see an ApplicationModule implementing the EntityManager interface. I have had some strong suggestions that ADF BC will be the primary ORM/Model component in the Fusion Tool stack.
do you have a timely project dependency on the decision whether or not to use ADF BC in favor of EJB 3.0 ? I am asking because I don't think that the SOD will be available in a few days or weeks.
ADF Business Components can be deployed as Enterprise Java Beans 2.1 to enable distributed deployment. I am not an expert in the interior of ADF Business Components and EJB, but knowing that many customers use ADF Business Components in production, It would scare me if it was based on a non-existing EJB standard (EJB 3.0 is supposed to become official in JEE 5.0).
However, this too should be part of the SOD to give users an understanding of when EJB 3.0 can be expected to be in and what the benefits are they would gain from this change in technology.
Until then I wouldn't give too much believe on any sort of information that comes through the grapevines.
I tried to make the point clear in this OTN whitepaper:
"ADF Developer's Guides and Recommended Technology Stacks for JDeveloper/ADF 10.1.3"
For the last many years, at present, and in the future, the Oracle Applications technology stack uses ADF Business Components for building business services.
That future of Oracle Applications is what we're now calling Oracle Fusion applications, where for the user interface, they are using JSF/ADFFaces, together with ADF Model layer and ADF Business Components. With the infusion of 4GL developers coming into Oracle's ranks with PeopleTools and SiebelTools experience, the internal numbers of 4GL applications developers in Oracle who's next-generation releases will be built using this Oracle Fusion stack is truly impressive.
Like many other customers coming from a 4GL development background, Oracle Applications chooses ADF Business Components because it delivers the highest application-building productivity for the kinds of developers we have in Oracle building our enterprise applications.
As the same article points out, ADFBC isn't right for every kind of developer, that's why we've worked hard in 10.1.3 in the ADF data binding layer to embrace other technologies like Java beans, web services, EJB, etc.
It had previously been our goal in the future to allow ADF entity objects, with all their declarative validation rules and other built-in features, to take advantage of some of Oracle Toplink's more sophisticated mapping features. (Truth be told, we honestly don't get many requests, either from internal teams or external customers, for that more sophisticated kind of O/R mapping support, but as I said it was our goal to get there.) However, as the Toplink team has gotten involved in the EJB 3.0 specification and reference implementation delivery, our goal in ADF BC has naturally refocused on eventually taking advantage of the persistence facilities coming out of that standard for our EntityImpl POJO. We worked with our EJB 3.0 spec representatives to draw attention to a key design limitation in earlier EJB 3.0 spec drafts about POJO's not being able to inherit from a framework class that wasn't itself another POJO, and this limitation was removed in later drafts of the spec. The executive summary is that taking advantage of EJB 3.0 persistence facilities is on our long list of items we're investigating for future releases of ADF.
If you are a developer whose background and experience compels you to use EJB 3.0 immediately, then I'd hope you'll evaluate the hard work we've already done in the 10.1.3 release in the ADF 10.1.3 data binding layer and JDeveloper 10.1.3 design time to make ADF + EJB 3.0 + JSF a productive combination for your needs.
For the moment we do not have a "timely project dependency" on this question. (But that can always be the case in a few days or weeks.)
Although a clear statement of direction on ADF BC is a minimum to even make it a candidate technology for any new project.
I my opinion, now is the moment for such a SOD, not in a few months from now (but that is just my opinion).
Until there is a SOD on ADF BC, I can already point people who think ADF BC will be thrown overboard by Oracle in favor of EJB 3.0 to this forum thread.
I understand the "it depends on your background" approach, but I'm not sure this will convince all people waving with "standard and open versus proprietary" arguments.
I also see many colleagues with a 4GL development background trying Oracle Application Express (HTMLDB) with great success an productivity. I know it is hard to compare Oracle Application Express with the many choices in ADF, but if you look at the bottom line, in many cases, Oracle Application Express will get the job done at a much smaller "cost".
Many people choose to solve something with what they know, and all to often, in an Oracle context, that is PL/SQL and not Java (and J2EE).
It goes without saying that Oracle Application Express is simpler in virtually every aspect than the full-fledged J2EE development environment that JDeveloper 10g and ADF provide. If Oracle Application Express' capabilities satisfy a developer's needs, then I would wholehearted recommend that they use it since it the end of the day, it's all about getting a job done. If the job is a little more complex that Oracle Application Express can handle, then JDeveloper 10g and ADF is a great choice, but does have a bigger learning curve.
I'm working together with our documentation team to hopefully make a big difference in this area with the ADF Developer's Guide for Forms/4GL Developers that we're working on. But even with a great developer's guide, there will still be a learning curve. No way 'round it. :-) Just hopefully a little less inclined of a slope...
It's like Microsoft Access and the full-fledged Visual Studio 2005 Enterprise Edition in Microsoft's offering for Windows-only developers. I'm sure there are plenty of tasks where a Microsoft-centric developer reaches for Access instead of the full Visual Studio 2005 environment.
I agree that there are not many one-size-fits-all technologies and one should choose the right tool for the job.
But if you put things on the "easy job - moderate job - complex job" scale, both easy and moderate can be done with Oracle Application Express these days by ex-4GL developers, and for the complex ones the J2EE experts get called in.
This is my opinion, so I wonder why any ex-4GL developer should consider the bigger learning curve for ADF (BC) instead of applying his PL/SQL skills and be productive (almost) from day one?
I disagree that complex applications can only be built by J2EE experts. 4GL-type developers who just want to deliver an application effectively are orders of magnitude more numerous than J2EE experts in my opinion. I hope these developer masses will find a comfortable home with either with Oracle Application Express or JDeveloper 10g; by evaluating both, the can pick the one that best fits their needs.
True, you don't always need J2EE experts to build complex applications, frameworks like ADF can be a great help in that area.
I was only trying to point out that, in my opinion, the playing field for ADF BC gets smaller now with a productive tool like Oracle Application Express and with a simplified standard like EJB 3.0 ... I wonder where does a (proprietary) Oracle framework (ADF BC) with a bigger learning curve fit in?
Yes, there are many (ex-)4GL-type developers, yes , they have to make an evaluation of the area in which to advance their technology skill ... but what would be the explicit reasons to choose for ADF BC?
If we want to be able to say to some of our customers "yes, we can build a robust solution with ADF BC to solve your problem in a timely manner" we will have to have the ADF BC skills. For that, some people will have to be convinced to aquire those ADF BC skills, but what are the arguments for them to invest in learning ADF BC?
My short answer would be, "you should invest in learning Oracle ADF, including ADF Business Components, because -- in combination with JDeveloper 10g -- it is the most productive way to build J2EE enterprise applications. The applications you build use standard Java and XML, can be deployed on any J2EE application server, can be designed to work with any database. Full source code to the framework is available to supported customers. Once you've learned to use ADF, you can target desktop applications with Swing (client/server or 3-tier), Web applications with JSF, Struts, JSP, Mobile applications (PDA's, Telnet), and Web Services with a single technology stack that is the one Oracle bet's its business on for enterprise applications. And besides the 4000+ developers using it in-house at Oracle today (growing to over 8000 in the next year or two), it doesn't hurt that we have several thousand external customers using the technology stack successfully as well. It's also free if you deploy to an Oracle Application Server."
And, it will soon have a killer Developer's Guide, that will accompany the framework to assist developers in getting up to speed even more quickly.
This page tries to summarize some of the key benefits: