Beispiel sagen mehr als 1000 Worte. Oracle hat deshalb seit kurzem einen Relaunch der Sample Sourcecode Seite von BEA durchgeführt https://www.samplecode.oracle.com/. Nun findet man neben den ex. BEA-Produkten auch viele Beispiele rund um die Oracle Produkte und den Sourcecode des neune Jdeveloper / ADF 11g Buches von Duncan Mills, Peter Koletzke, und Avrom Roy-Faderman.

Heute habe ich ein paar ADF-Beispiele des JDeveloper 11g Handbuchs durchgespielt und einen SQL-Fehler entdeckt. Die Tabelle IMAGE_USAGE muss im plural geschrieben sein (IMAGE_USAGES), damit die Anwendung kein SQL-Exception liefert.

Der Fix dazu ist sehr einfach. In einem beliebigen Sqleditor (sqlplus) als hr/hr@xe anmelden und folgendes Script ausgeführen:

alter table IMAGE_USAGE rename to IMAGE_USAGES;

Den wenigsten ist bekannt, dass ADF-BC seit Begin der Fusion Strategie enorm erweitert wurde und seit Oracle 11g Middleware produktiv verfügbar ist.

Eine tolle neue Eigenschaft ist die erweiterte Einbettung von ADF in eine SOA mit Service Data Objects (SDO).

Was bedeutet das nun? Bisher war es wie zu erwarten möglich Service-Operationen von Komponenten (ApplicationModules) als WebService zu exponieren. Diese ist die Standardfunktion aller Frameworks.  Neu in ADF ist, dass nun das gesamte Datenmodell einer ADF-Anwendung als WebService SOD-Objekte bereitgestellt und darauf remote per SOAP operiert werden kann, wie auf einer lokalen Anwendungsinstanz.

Um das zu verstehen, muss man das Konzept von ADF kennen:
Alle Java Business Objektes, in ADF-BC auch ViewObjects genannt, stellen Fassaden zu den eigentlichen EntityObjects (Java Beans) dar und entkoppeln u.a. die Zugriffsschicht von den eigentliche Datenobjekten (EntityObject). Die ViewObjekte werden zu Data Transfer Objects wenn sie übers Netz gesandt werden. Genau diese ist bei SDO der Fall. Alle ViewObjects können in ADF als SDO-Objecte exponiert werden. Es wird dabei zu jeder ViewObject Struktur eine ein XML-Schama (XSD) erzeugt und die CRUD-Operationen im WEBService Interface (WSDL) mit einem SDO Binding publiziert.  Eine besondere Eigenschaft von SDO ist, dass nur die geänderten Werte per ChangeSummary an den Service per SOAP gesandt werden können und somit die Daten mit minimiertem Traffic auf Client und Server identisch gehalten werden können.

Habe ich nun meine ViewObjects und WebServie als SDO und WebService bereitgestellt, kann ich ein neues ADF Client-Projekt bauen die SDO-ViewObjects anstatt der Datenbanktabellen für meine EntityObjects als Datenlieferanten nutzen. Ein Beispiel dazu wird von Andrejus Baranovskis bereitgestellt. Eine detaillierte Beschreibung ist im ADF Developer Guide vorhanden: http://download.oracle.com/docs/cd/E12839_01/web.1111/b31974/bcextservices.htm

Eine Referenzarchitektur stellt meiner Meinung nach eine konkrete Umsetzungsvorlage des definierten Idealbilds der zu erreichenden IT-Landschaft dar. Der Weg zur Umsetzung der Referenzarchitektur ist lang, und es werden projektbedingt in der Regel externe Einflüsse die Zielarchitektur beeinflussen. Damit der am Horizont positionierte Leuchtturm (Zielarchitektur und Strategie) trotz allem erreicht wird, muss der Architekt, darauf achten, dass der Pfad durch einstreuen von Frameworks, Werkzege oder Produkte durch die Entwickler, nicht zu weit verlassen wird und das Fernziel erreichbar bleibt. Ohne tiefgreifendes Know-How, einem Fundus von Best Practices innerhalb der Referenzarchitekturen und der stetigen Qualitätsprüfung bzw. deren Richtungsanpassung, wird die Architektur nicht stabil sein und sich langfristig in viele Richtungen ausbreiten. Konsequenterweise wird dies in einer unbeherrschbaren Architektur enden, wodurch die prognostizierten Vorteile wie Kostenreduzierung, Qualität und Agilität in unerreichbare Weite rücken. Dem Architekten kommt also eine zentrale Rolle zu, nicht nur bei der Definition, sondern insbesondere auch im gesamten Projektablauf von Strategie bis zur Realisierung.

Mit folgendem Codefragment kann mit ADFFaces und  ADFSecurity auf die registrierte JEE Loginseite verwiesen werden:

}

if (!ADFContext.getCurrent().getSecurityContext().isAuthenticated()) {
            ExternalContext ctx =
                FacesContext.getCurrentInstance().getExternalContext();
            HttpServletRequest request = (HttpServletRequest)ctx.getRequest();
            String loginURL =
                request.getContextPath() + "/adfAuthentication?login=true&success_url=/faces/welcome";

            ctx.redirect(loginURL);

            return null;
        }

Wie oft steht man vor dem Problem eine Architektur zu entwickeln, die Performant sein soll und gleichzeitig die Daten auf Client/Middletierseite aktuelle sein müssen. Übliche Lösungen setzden deshalb auf Client/MiddleTier-Seite Caches wie EHCache unter Hibernate oder JDBC oder ähnliches ein. Der Refresh erfolgt dann zyklisch per Poll oder Löschen ALLER Objekte im Cache.  

Mit Oracle Database Change Notification lässt sich dies jetzt eleganter lösen. DB-Änderungen werden nun satzgenau dem Client per Notification übermittelt. Im OTN existert dazu ein Beispiel für die 11g DB. Der Mechanismus funktioniert jedoch auch schon mit der Oracle XE DB Version 10.2 und dem ojdbc5 Treiber (dieser ist z.B. im 11g Jdeveloper enthalten).
Das im OTN veröffentliche Beispiel „Oracle Database Change Notification„
muss dann jedoch die Methode „onDatabaseChangeNotification“ wie folgt ersetzen:


public void onDatabaseChangeNotification(DatabaseChangeEvent e)
{
/* QueryChangeDescription [] changes = e.getQueryChangeDescription();
// Object ox = e.getTableChangeDescription();
// QueryChangeDescription change = changes[0];
*/
TableChangeDescription [] tableChanges = e.getTableChangeDescription();
TableChangeDescription tableChange = tableChanges[0];
RowChangeDescription[] rowChanges = tableChange.getRowChangeDescription();
RowChangeDescription rowChange = rowChanges[0];
oracle.sql.ROWID rowid = rowChange.getRowid();
demo.getUpdateForROWID( rowid );
}
}


Oracle bietet in der DB mehrere Möglichkeiten Werte in der DB zu verschlüsseln. Hat man jedoch den Anwendungsfall nur ein einzelnes Feld (z.B. Passwort) in der DB zu verschlüsseln und muss man sowohl per Java als auch per PL/SQL dazu eine LoginCheck-Funktion implementieren, kann dies mit folgender Routine einfach umgesetz werden.

Angepasste PL/SQL Funktion aus Oracle Metalink zur Verschlüsselung:


FUNCTION md5encode (CLEARTEXT IN VARCHAR2) RETURN VARCHAR2
IS
chk VARCHAR2(16);
hex VARCHAR2(32);
i INTEGER;
c INTEGER;
h INTEGER;
BEGIN
IF CLEARTEXT IS NULL THEN
RETURN '';
ELSE
chk := dbms_obfuscation_toolkit.md5(input_string=>CLEARTEXT);
FOR i IN 1..16 LOOP
c := ASCII(SUBSTR(chk, i, 1));
h := TRUNC(c / 16);
IF h >= 10 THEN
hex := hex || CHR(h + 55);
ELSE
hex := hex || CHR(h + 48);
END IF;
h := MOD(c, 16);
IF h >= 10 THEN
hex := hex || CHR(h + 55);
ELSE
hex := hex || CHR(h + 48);
END IF;
END LOOP;
RETURN hex;
END IF;

END;


Dazu passende Java Verschlüsselung:

public String md5encode( String password ) throws Exception {
MessageDigest md5 = MessageDigest.getInstance( "MD5" ) ;
byte[] rawBytes = md5.digest( password.getBytes() ) ;

byte rawByte;
for (int i = 0; i> 4) & 0xF;
sb.append(charIndex.charAt(ix));
ix = rawByte & 0xF;
sb.append(charIndex.charAt(ix));
}
return sb.toString();
}


Die Checkroutine verschlüsselt nun das Klartextpassword per md5encode () und macht mit dem gespeicherten verschlüsselten Password einfachen einen String-Vergleich.

Java Psoudocode dazu:

String myCurrentPassword = „hallo123″
if(obfuscatedPasswordFromDBColumn.equals(md5encode(myCurrentPassword)) == true)
System.println(„Login OK“);
else
System.println(„Login Fehlgeschlagen“);

Mit Oracle 11g ist es nun möglich über seine eigen geschriebene Loginseite ein J2EE Security-Context aufbauen.

Es ist dabei nicht mehr notwendig ( aus Sicherheitsgründen jedoch empfohlen) den in der web.xml definierten Security-Context mit konfigurierter Loginseite zu verwenden.

Mit JSF kann beispielsweise innerhalb einer JSF-ManagedBean mit folgender Methode der J2EE SecurityContext des OC4J-Containers aufgebaut werden. 

LoginContext ctx = new LoginContext(„myContext“, subject, callback);

Die zur Ausführung kommende JAAS-LoginModule werden über die jps-config.xml Datei konfiguriert und über den Kontextname (hier im Beispiel „myContext“) referenziert.

<jpsContext name=“myContext“>

   <serviceInstanceRef ref=“myLoginmodule“/>

   <serviceInstanceRef ref=“xds.loginmodule“/>

   <serviceInstanceRef ref=“SAML.loginmodule“/>

   <serviceInstanceRef ref=“idstore.loginmodule“/>

</jpsContext>

Die hier referenzierten LoginModule (serviceInstanceRef) werden ebenfalls in der Datei jps-config.xml konfiguriert.

 Die Einbindung eines eigenen Loginmodules (JAAS-konform) und die gleichzeitige Ausführung der Standardmodule – beispielsweise das Setzen eines SAML-Tickets für WebService oder SSO – kann somit ebenfalls sehr einfach erfolgen.

<serviceInstance name=“de.bmaier.sample.security“ provider=“jaas.login.provider“>

<description>My Sample LoginModule</description>

<property name=“loginModuleClassName“ value=“<hier muss der Klassename mit Package-Angabe des eigenen LoginModules eingetragen werden „/>

<property name=“jaas.login.controlFlag“ value=“REQUIRED“/>

</serviceInstance>

Ein Beispiel findet sich im Oracle-Forum   

Der Versuch BPEL Prozesse aus BEA AquaLogic aufzurufen wird mit folgender Meldung fehlschalgen:

An unexpected error occured accessing information about the WSDL of the service:
com.bea.wli.config.component.NotFoundException: Can not compute effective WSDL for : BusinessService SecureInvocation/BizServices/ORCL MyTestBPELProzess standalone


Das Problem kann einfach durch Anpassung der  generierte AquaLogic  WSDL behoben werden:

Ändern zu:

<plnk:partnerLinkType name="MyTestBPELProzess" xmlns:clientABC="http://xmlns.oracle.com/TestBPELProzess/TestBPELProzess/MyTestBPELProzess"> 
 

<plnk:role name=“MyTestBPELProzessProvider“>
<plnk:portType name=“clientABC:MyTestBPELProzess“/>
</plnk:role>
</plnk:partnerLinkType>

Mit Active Data Service stellt das ADFFaces Framework (11g) nun einen Mechanismus  bereit auf Datenänderungen im Backend zur reagieren und einen automaitschen Seiten-Refresh durchzuführen. Trotz dass die Funktion auf AJAX basiert, ist es dabei nicht notwendig JavaScript zu implementieren.

Einzig muss der JSF-Datenlieferant einer ADFFaces-Komponente – hier im Beispiel af:table – das Interface ActiveDataModel implementieren.

public class MyTableData extends CollectionModel implements ActiveDataModel {

….

Zu Beginn ruft der DataUpdateManager (ADF-Class)  die Methode  startActiveData() des ActiveDataModel und übergibt u.a. die ADF-Komponente, die auf Änderungs-Events horcht. 

    public synchronized void startActiveData(Collection<Object> rowKeys,
int startChangeCount,
ActiveDataListener listener) {

Zur Deregistrierung ruft ADF die Methode stopActiveData(...) auf. Im Normalfall wird man hier den Listener wieder aus seiner lokalen ListenerListe entferenen und bei Änderungen keinen Event mehr senden.

Informiert werden die ADFKomponenten über Events, wenn sich im Backend etwas geändert hat.
Dazu werden im Backend meist asynchrone Mechanismen wie Queues (MDB, JMS, AQ …), Threads, oder typische asynchrone Protokoll wie Mails/Chat verwendet.

Eine Benachrichtigung wird gewöhnlich in der Callback-Routine (z.B. onMessage  bei MDB) wie folgt aussehen:       

  List<ActiveDataEntry> myList = new ArrayList();
        myList.add(newEntry);
        ActiveDataUpdateEvent event =
            new MyActiveDataUpdateEvent(this, count, myList);
        for (ActiveDataListener listener : registeredActiveDataListeners) {
                registeredActiveDataListeners.dataChanged(event);
        }

Um ADF noch mittzuteilen welche Werte sich tatsächlich geändert haben und somit in dem UI refreshed werden sollen (AJAX), muss das Interface ActiveDataEntry für alle Rückgabewerte implementiert werden. Gewöhnlich wir man hier ein ActiveDataEntryWrapper implementieren und über Methoden  wie z.B. getChangeTyp() mitteilen, um welche Art von Änderungen es sich handelt. 

In der JSF-Seite ist an der Komponente lediglich die datenliefernde MannagedBean mit dem Interface ActiveDataModel einzutragen: