Last week I attended DOAG Konferenz & Ausstellung in Nürnberg Germany. The DOAG (Deutsche ORACLE-Anwendergruppe e.V.) is the biggest German Oracle user group. The conference covers all Oracle products and technologies, way too much to name them all.
As my personal center of gravity is middle-ware and here ADF and the surrounding technologies, I attended lot’s of sessions about middle-ware, cloud, ADF, MAF and JET. The big picture of Oracle becoming a cloud company is getting clearer.
The way developers currently are working on premise with their products migrating to the cloud is getting clearer. There where about 4-5 sessions which gave explicit advice when to use which technology and what problems might arise mixing them. I’ll cover the main three here.
Frank Nimphius started with a session ‘The Future of Application Development Welcome to your new Job’ where he summarized areas of future of application development as
- “Server-less” deployment
- [Micro] [Cloud] Services
- REST & JSON
- Mobile centric
- API first
- Multi channel
- Artificial Intelligence
- Cloud Native Development
and defined different job roles around this like
- Citizen (Low Code) Developer
- Mobile Developer
- Service Developer
- Line of Business Manager
Each role using different technologies to fulfill the tasks. This should open spaces for new and old developers
Duncan Mills tackled the bear from a different perspective. In his session ‘Standing at Crossroads’ (Oracle ADF and Oracle JET) he pointed out the differences between ADF and JET
|Oracle ADF||Oracle JET|
|Support 5 + 3 + unlimited, no backport limitations||Major release every 6 month, backports only to previous version|
|API are stable||No guarantee of API stability|
|Could or on premis||Cloud|
|Metadata focused||Code focused|
|Full stack solution||Client only solution|
|Has to „own“ the page||Can be used „anywhere“|
However, there are things both have in common, as Duncan states:
“Don’t assume the you have to go to JET to look ‘modern'”
“Don’t assume that JET will automatically be more perfomant”
There are more things you have to take into account before making a decision between ADF and JET like
- Transaction and Services: here you have to check if your services and data model can support a stateless model. Same for your UI which handles the interaction with the user. One thing to note too is that using JET will produce less client – sever traffic.
- Need to shape the services for the convenience of the UI: paging data, pre-computation, attribute reduction and mega endpoints
If you plan to mix ADF and JET there are a couple of things which should make you think twice:
- No session sharing between ADF and JET
- ADF and JET can’t use the same cache
- No shared transaction
- Separate timeouts
- geometry management
- Drag & drop not possible between ADF and JET
- Different maintenance and different libraries
- Different popup’s and glasspane
Summary is that there are plenty of reasons not to mix ADF and JET. If you want to mix ADF and JET in a project you should stick to module level and not mix them on one page.
The decision for ADF or JET should take these points into account.
Shay Shmeltzer attended the German Oracle (ADF) Developer Community meeting on the DOAG and we ask him to talk about this topic ‘The Future of Developer Frameworks’.
Shay started by giving a main difference between ADF and JET:
“ADF is a framework, JET is a toolkit”
meaning that ADF allows development in all tires (MVC) whereas JET is only a client technology. Using JET you still have to have a back-end which generates the needed REST services. Here ADF comes into the picture again.
“ADF hides the complexity of the technology from the developer”
True, building a REST service from an exiting ADFbc model is very easy and allow shaping the service too. Besides ORDS (Oracle REST Data Service, a tooling which allows to develop modern REST interfaces for relational data in the Oracle Database ) this is the easiest way I know.
During the Q&A of his talk we specifically ask him how Oracle sees the future of ADF as some rumors are that ADF is dead. Shay answered (loud and clear):
“ADF isn’t dead!”
Oracle is using ADF heavily in the SaaS products and will going on to do so. There are areas where building UI with JET is preferred (not in SaaS), but here the points mentioned by Duncan Mills are always considered.
My personal opinion is that ADF is alive will be used in the future, but there are options now which allow developers to choose different technologies in certain areas. Using ADF in the model layer and working with relational data bases, create REST or SOAP services with ease is a big plus. For the UI there are use cases where JET will be used, but ADF has its share too.