Quo vadis ADF?

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
  • JavaScript
Future Application Development Summary 1

Future Application Development Summary 1

Future Application Development Summary 2

Future Application Development Summary 2

and defined different job roles around this like

  • Citizen (Low Code) Developer
  • Mobile Developer
  • Service Developer
  • Architect
  • Line of Business Manager

Each role using different technologies to fulfill the tasks. This should open spaces for new and old developers

Mobile Job Roles

Mobile Job Roles

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:

  1. No session sharing between ADF and JET
  2. ADF and JET can’t use the same cache
  3. No shared transaction
  4. Separate timeouts
  5. geometry management
  6. Drag & drop not possible between ADF and JET
  7. Different maintenance and different libraries
  8. 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.

duncan_doag5

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

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

Advertisements

DOAG DevCamp 2015

Upcycling Software!

The DOAG (Deutsche ORACLE-Anwendergruppe e.V.) meets for the DevCamp 2015 in Frankfurt a.M., 29th & 30th of April 2015. This event is a great opportunity to meet German Oracle users, Oracle ACE and Oracle ACE Directors as well as Oracle Product Management to discuss your matters.

The event will be held as a bar camp where everybody can suggest topics at the start of the event which are then evaluated and scheduled for discussion during the event. There is no better chance to discuss your problems, hopefully get some answers or pointers and meet your peers.

I’m looking forward meeting customers, colleagues and friends for interesting discussions and some hacking. This years main topic is ‘Upcycling Software’. Two big Oracle customers (Bundesagentur für Arbeit and IKB) tell us about their challenge in upcycline software.

If you are not already registered take the opportunity and visit [DevCamp 2015|http://barcamp.doag.org/] now!

DOAG Development Conference, JDeveloper 12c New Features

Yesterday, 14th June 2012, the first DOAG Developer Conference to place in Bonn, Germany. Among the many sessions one hosted by Frank Nimphius revealed new features for the upcoming major release of JDeveloper 12c. As the version is still in development there is no guarantee that all features he talked about are in when we get 12c. Nevertheless I like to mention some of the features. The list I present here is not the full list as there are way too much to mention them all.

    • GlassFish will be a supported server
    • Pretty URL: URLs of applications will be more human readable, aka we don’t see the state tokens any longer
    • IDE window system is based on NetBeans code
    • New Wizzards to create OSGI Extension. Most code to wire the extension up is generated, we only need to add code to some methods.
    • No need to deploy an extension. It can be tested and run right out of JDeveloper 12c
    • Full Maven Support with Hudson integration: ojdeploy plugin for Maven
    • Better RESTservice support
    • Groovy debugger: allows to set breakpoints in Groovy code and see the attributes like in normal java debugger
    • EL2.2 support: methods with parameters possible
    • write EL direct in the page without the need of an af:outputText
    • faster page loading: use of CSS3, HTML5 and smaller JavaScript size allows faster page loading
    • JDev helps to (manually) convert jspx to jsf pages. You need to do it manually but get hints or work lists on what to do
    • Multi file upload component together with a nice looking progress window (popup)
    • ‘Placeholder’ watermarks for inputText components
    • New component to edit code: like the rich text editor but for code
    • Templates can not only be used, but copied into your project to allow easier manipulation
    • More help to find out which skin selectors a component uses
    • All button and link components are put together in on ‘magicButton’ component (thanks Chris for the name). The old components are still available.
  • There was plenty more which I couldn’t write down in the short time. Let’s see when DOAG provide the slides. I’ll add more info then.