One very pleasant day of wave diving and sun soaking later, it is
time to get started at the ODTUG 2007 Kaleidoscope conference, down in
Daytona Beach, Florida. The old gang has gathered once again on a
beach. To enjoy ourselves with stories from the old days but of course
even more stories from today and days to come. BPEL, AJAX, SOA, BI, bit
of Forms, little bit of Designer, lots of ADF and SQL and whiff of
Oracle DBA. Enough to keep us occupied. With all the latest from Oracle
product management, with war stories from Oracle veterans and with lots
of discussion around best application of the current technology and the
expectations for the upcoming stuff. And 11g is looming over this
conference of
As I am writing this, I am sitting in the
Oracle Fusion (Middleware) Symposium, that kickstarts the conference. A
dozen speakers, some Oracle Fusion Middleware Regional Directors and
Oracle ACEs and all of them technological experts, presenting on
architectural and technological challenges with ADF, Java/Web Apps in
general, SOA etc.
In a few moments, my colleague Peter Ebell
will do his presentation "Just Press Next", on Developing an
Intelligent User Interface Through BPEL Workflow Tasks Using Oracle
ADF. This is the presentation he received a Best Award nomination for (https://technology.amis.nl/blog/?p=2075 ), and I am fairly (well, utterly) sure his will be a good presentation – more on that later.
The symposium got started 
with
Paul Dorsey’s talk on "thick database" (would that be the countertpart
of the dumb client?). He argued that most if not all logic in a Java
Web Application should actually reside in the database, suggesting that
performance gains of factor 100-1000 are not at all rare and that
complexity in terms of lines of code will be much reduced. While I
wholehartedly support the notion of using the database for what it is
good at – data manipulation and data integrity for example – I have to
disagree with the complete lack of nuance in Dorsey’s story. Not
everything should be done in the database. Not all complexity is
reduced by moving logic to the database and the performance gains Paul
suggested may occur but are far more rare than he suggested.
Unfortunately, the slots are too short (30 minutes) for real discussion
to take place. (Toon: you would have liked this one!) Maybe later on we
will get to that.
John Flack discussed the use of Cursor
Packages: PL/SQL packages that contain query logic and return REF
CURSORS to callers. REF CURSORS can be dealt with in most languages,
including Perl, Java and PL/SQL. Using cursor packages allows us to
separate all knowledge and logic for querying data from applications
using that data. Both in terms of independence (resilience against
change) and security (fighting SQL Injection for example), this can be
a valuable approach.
Eric Macoux led the audience through his experiences with migrating from an Oracle Forms technology stack to the ADF Java/J(2)EE stack, paying a lot of attention to the ADF Business Components. His talk was very useful to the majority of the audience who are still firmly rooted in Oracle Forms and only just starting (thinking about making) the move to ADF.
Fellow Dutchman Bart Kummel (Transfer
Solutions) talked about AJAX. He discussed what AJAX exactly is (and
what it is not – detergent, football club) and discussed a number of
JSF frameworks: ADF Faces 10.1.3, IceFaces, Ajax4JSF and ADF Faces 11g.
He stated that ADF Faces 10.1.3 does not have AJAX functionality – as
it is not truly asynchronous. While I agree that there is some
limitation in asynchronisation, I do not agree that means ADF Faces
10.1.3 does not have AJAX functionality: the key elements we want from
AJAX (asynchronous, background communication and seamless dynamic page
refresh, allowing for instant validation, conversion, list-updates,
etc.) are all available with ADF Faces 10.1.3. So perhaps to the
literally definition of many people this may not be true AJAX, but to
all intents and purposes and to me… it is.
Bart briefly
discussed how you can AJAX enable most JSF applications, even JSF RI
components, using AJAX4JSF. The example he gave: enter a department
number and have the name of the department asynchronuusly fetched from
the server and display underneath the number, surprised me a little. He
used AJAX4JSF to add this dynamic behavior to an af:inputText:
af4:support event="keyup" reRender="id1" where id1 is the af:inputText
to be refreshed with the Department’s name. This is somewthing in ADF
Faces you do not need AJAX4JSF for, as the PPR features of ADF Faces do
the exact same thing. With one important distinction: PPR requires the
element that wants to refreshed to set its partialTriggers attribute
rather than add the id of that element to the component that should
initiate the refresh, as with AJAX4JSF.
Peter on BPEL and Workflow
By now, Peter has started his talk. He presentation’s structure is very good. Walking the audience through SOA and Services, BPEL and process design & execution – stressing the execution! – he arrives at workflow. With the BPEL4PEOPLE (or BPEL4PPL) standard still in (slow) progress, many BPEL vendors including – or even led by – Oracle have shipped solutions for human workflow integrated with their BPEL products. Peter illustrates the elements of Human Workflows, including comunication via SMS, Fax, Email etc. and complex task allocation algoritms. He next introduces the standard shipped worklist application in Oracle BPEL PM.
Then the time has come to get to the presentation’s title: what if the Worklist application is too complex, or it does not adhere to your UI standards or users do not like to switch between their normal application and the worklist application? Then you use the BPEL Workflow Service API to create your own interaction. By building your own UI. Or by not having such a TODO list at all – users not wanting to be bossed around by "the computer". The approach Peter proposes is to have internal logic in the UI (for example ADF Faces) integrate with the Workflow API to help determine which UI to present (with which data).
BPEL vs. Web Application: BPEL makes it easy to mix automated steps involving services implemented in different technologies and steps requiring User Input. BPEL focuses on the process (logic) rather than mix this logic with UI logic (far more perishable or at least ion a different track than the process logic). Web Applications provide a tailor made UI – BPEL Workflow Tasklist Application is a one size hopefully fits all. COmbining the two is fairly easy: build the UI, task specific interfaces using for example ADF, integrated with the Tasklist API. The Worklist Application is not used at all. The UI does not look like a worklist. It has a NEXT button. The internal logic relying on the BPEL Workflow Service API decides what NEXT means in the current context and takes the user to the next screen, where the context for the next step (task) is presented.
Lucas,
I’ve downloaded and played Paul’s presentation that he presented in Las Vegas a few weeks ago: it’s probably the same one. And yes I indeed do like it. Paul and I are pretty much on the same wavelength concerning this topic, allthough I think that he is sometimes even more extreme than I am (is that possible? Yes it is…).
My views are expressed in this year’s Hotsos symposium: as you know I classify all code of a Window-on-Data (Wod) application into three classes: Data Logic, Business Logic and UI-Logic. Only the latter one should be implemented outside the DBMS. If you need scalability, security, maintainability and (yes even) agility, the first two ones must go into the DBMS and end up as lines of PL/SQL code. Period. Arguments can be found in the Hotsos presentation.
I wish I could be there at the beach…
Toon.
PS. Just curious… did I get nominated again in any way?