EAM & Semantic Web und Apache Fuseki OWL-Reasoner

•16. Juni 2013 • Kommentar verfassen

 

Aktuell arbeite ich an einer EAM-Ontologie, um aus wenigen Architektur-Informationen gewinnbrigende Aussagen ableiten zu können – dafür eignen sich die Mittel des Semantic-Web hervorragend. Ein typisches EAM-Fragestellung könnte lauten: Ermittle alle Abhängigkeiten einer Anwendung für die Modernisierungsplanung, ohne dafür die gesamte Anwendungslandschaft akribisch zu untersuchen und alle Elemente zu inventarisieren.

Mit der Kombination einer EAMOntologie auf OWL-Basis, einer EAM-Methodik und einem OWL-Reasoner ist diese Aussage auch alternativ ohne den vielen Excel-Inventarlisten zu schaffen. Elemetar wichtig ist jedoch Regeln zu hinterlegen, die bei jeder Abfrage implizit angewandt werden. Dafür sind im Semantic-Web Umfeld ja die Reasoner und das Inferencing zuständig,
Leider sind diese trotz OWL-Formulierung, -Ablage und SPARQL nicht immer im Standard konfiguriert und somit das Ergebnis nicht wirklich wie zu erwarten . Verwendet man z.B. Apache Fuseki Server (Jena Framework), so muss man die Standardkonfiguration ändern und explizit sagen, dass die gegebenen Fakten und formulierten Regeln durch eine Reasoner aufgelöst werden und damit implizite Aussagen getroffen werden können, ohne diese explizit erfasst zu haben oder Abfragen zu müssen. Dazu ein einfaches Beispiel:

Die Anwender sprechen gerne von Linux-Rechner wenn sie eine bestimmte Hardware meinen, die IT spricht jedoch von konkreter Hardware-Architektur oder  Virtual-Maschinen, die ja eine Rechner-Architektur emulieren kann. Soll die konkrete Frage beantwortet werden, welche Runtime-Umgebung für eine Software zum Einsatz kommen kann, so sollten dann auch alle in der Firma vorhandene VMs auflistet werden und nicht nur die Rechner der gegebenen Architektur.

In OWL-könnte man den Äquivalenz-Ausdruck anwenden und dazu folgende Formulierung wählen:

</rdf:RDF>
  <owl:Ontology rdf:about="computer"/>
  <owl:Class rdf:ID="CPUx86"/>
  <owl:Class rdf:ID="VirtualMachine">
    <owl:equivalentClass  rdf:resource="#CPUx86"/>
  </owl:Class>
  <j.0:CPUx86 rdf:about="#DellPowerEdge"/>
  <j.0:VirtualMachine rdf:about="#OracleVirtualBox"/>
</rdf:RDF>

Damit wird gesagt, dass die OracleVirtualBox auch für das Hosting verwendbar ist nun nicht nur der DELL-PowerEdge Server. Als Ergebnis erwartet man mit der SPARQL-Query:

SELECT ?subject ?object
WHERE { ?subject a ts:CPUx86 }

--------------------------------
| subject             | object |
================================
| ts:DellPowerEdge    |        |
| ts:OracleVirtualBox |        |
--------------------------------

Das Ergebnis ohne OWLReasoner ist jedoch: 

--------------------------------
| subject             | object |
================================
| ts:DellPowerEdge    |        |
--------------------------------

In Fuseki muss dazu in der config.ttl Datei folgender Eintrag zugefügt werde, um das gewünschte Ergebnis zu erhalten:

 

<#service4> rdf:type fuseki:Service ;

    # URI of the dataset — http://host:port/ts

    fuseki:name                        "ts" ;

    fuseki:serviceQuery                "sparql" ;

    fuseki:serviceQuery                "query" ;

    fuseki:serviceUpdate               "update" ;

    fuseki:serviceUpload               "upload" ;

    fuseki:serviceReadWriteGraphStore  "data" ;    
    fuseki:serviceReadGraphStore       "get" ;

    fuseki:dataset                     <#computerDataset> ;

    .

<#computerDataset>    rdf:type ja:RDFDataset ;

    rdfs:label "T-EAM" ;

    ja:defaultGraph

      [ rdfs:label "TEAM" ;   
        a ja:InfModel;

        ja:content [ja:externalContent <file:Data/computer.owl> ] ;

       ja:reasoner  [ ja:reasonerURL <http://jena.hpl.hp.com/2003/OWLFBRuleReasoner>];

      ] ;

    .

fuseki:services (

  <#service1>

  <#service2>

  <#service3>

  <#service4>

) .

 

Zudem muss nun der Server mit der angelegten Konfiguration gestartet werden

./fuseki-server –update –config=config.ttl /ts

Artikelserie „Industrial SOA“ ist nun online

•23. April 2013 • Kommentar verfassen

Nun kommt die SOA-Artikel-Serie online… Zusammen mit meinen Freunden werden wir unsere Erfahrungen rund um SOA nun auch in Englischer Sprache online bereitstellen. Die ersten zwei Artikel (Preface : Industrial SOA  [OTNSTM], SOA Blueprint – A Toolbox for Architects [OTNSTM] ) sind bereits da.

 

Industrial SOA is a 14-part  article series focused on service orientation, written collaboratively by a group of recognized experts and community leaders in service oriented architecture. I’m really happy and proud to be part of that group. 

NewImage

SOA and service-orientation have laid the foundation for a variety of emergent service technology innovations, while the original building blocks of SOA and service-orientation continue to evolve by embracing fundamental service technologies, concepts and practices. These new technology innovations do not replace service-orientation; they use it as their basis. Service-orientation continues to evolve towards a factory approach, towards industrializing integrated platforms, such as BI, master data management (MDM), mobile front-ends, BPM, adaptive processes, Big Data and Cloud Computing – all of which add architectural layers upon SOA-based infrastructure. All of these technologies can interface via standardized data and functions, published as service contracts, in order to avoid redundancy – that’s service-orientation.

The articles are & will be published both on Oracle Technology Network (OTN) and Service Technology Magazine (STM).

Available and upcoming Articles:

Preface : Industrial SOA (OTNSTM)
Chapter 1: SOA Blueprint: A Toolbox for Architects (OTNSTM)
Chapter 2: Project Categories
Chapter 3: Service Categories
Chapter 4: SOA Maturity
Chapter 5: Enterprise Service Bus (ESB)
Chapter 6: Security
Chapter 7: Transactions and Compensation
Chapter 8: SOA and User Interaction (UI)
Chapter 9: Mobile
Chapter 10: Events
Chapter 11: MDM and SOA
Chapter 12: BPM and ACM
Chapter 13: SOA and Cloud 

Thomas Erl, Editor of Service Technology Magazine: “Welcome to this special issue in which we are launching an extensive article series dedicated to the exploration of contemporary SOA topics and issues. This refreshing view of what is termed as “Industrial SOA” highlights some of the more recent innovations in practice that will especially be of interest to those who want to learn some techniques that go beyond the academic essentials. This issue begins with a preface by Oracle veteran Juergen Kress, and then moves on to the first of twelve articles in the series. Subsequent issues of the Service Technology Magazine will publish new articles, which will take the series into early 2014. These articles were authored by a group of SOA experts that have received wide-spread recognition throughout Europe and have been nicknamed the “Masons of SOA”. One of the masons, Clemens Utschig, was also a co-author of the SOA Manifesto back in 2009.”

Send us your feedback Twitter @twitter/soacommunity  #industrialSOA

Industrialized SOA – Thema des Business Technology Magazin 3.12

•7. September 2012 • Kommentar verfassen

Zusammen mit meinen Freunden haben wir ein Update zum SOA-Magazin geschrieben: 

Auch wenn es ruhiger geworden ist um SOA, beerdigt ist das Konzept noch lange nicht. Ganz im Gegenteil, über die Jahre hat es einen neuen Maturity Level erreicht. Hype-Themen wie Cloud Computing oder Big Data haben SOA aus den Schlagzeilen verdrängt, aber „ersetzen die neuen Hype-Themen die Serviceorientierung nicht, sondern bauen darauf auf“.

Wir haben in der Zwischenzeit bei einer Vielzahl von SOA Projekten mitgewirkt, weshalb wir für diese Ausgabe von Business Technology unser kollektives Wissen zusammengetragen und ein angepasstes Bild, des aktuellen Zustands von SOA geschaffen haben.
Nach unserer Überzeugung entwickelt sich SOA evolutionär weiter, in Richtung Fabrikansatz, in Richtung Industrialisierung, in Richtung ‚ganzheitliche Plattform‘“ zu einer neuen Industrialized SOA.

Die Ausgabe 3.12 des BT Magazins bekommen Sie als iPAD-App (http://it-republik.de/business-technology/bt-magazin-ipad-app), per Post (http://it-republik.de/business-technology/bt-magazin-ausgaben/Industrialized-SOA-000516.html) oder am Kiosk!

Weitere Informationen auf www.bt-magazin.de

Html5 WebSockets mit Apache Camel

•2. Juni 2011 • 1 Kommentar

HTML5 wird das Internet nochmals revolutionieren, da bin ich mir ganz sicher. Altgediente Web-Frameworks, die nach dem Request/Reply Muster verfahren, werden langsam durch HTML5 Rich Clients ersetzt. Diese ist vor allem den Html5-WebSockets und Mobiles geschuldet.

Welches Potential hinter dieser Technik steckt verdeutlicht ein von uns (Claus, Chris, und mir) erstelltes Beispiel sehr gut: Ein Anwender gibt in seinem Browser (Chrome, Firefox, Opera, Safari,… http://html5test.com/)  einen Text ein und alle parallel angemeldeten Anwender erhalten unmittelbar die Nachricht im Browser dargestellt. Dazu haben wir das Apache Camel Framework erweitert, um die Nachricht zusätzlich über eine Datei auf dem Server zu spoolen. Das heißt, wir können mit Camel einen einfachen Protokollwechsel implementieren und Nachrichten z.B. aus der DB, FTP, Mail, RMI, … direkt in WebSockets wandeln und an den Browser senden – natürlich auch umgekehrt.

Eine detaillierte Anleitung hat Claus Straube zusammengefasst, womit die Demo in 10min auf jedem Rechner lauffähig sein sollte. Sourcecode ist unter GitHub verfügbar. Viel Spaß beim Testen!

JSR 94 mit Oracle Business Rules & Spring Modules

•4. Januar 2011 • 1 Kommentar

Die Integration der Oracle Rules mit Spring Modules ist leider nicht beschrieben, jedoch durch die Implementierung des JSR 94  möglich.

Folgender funktionsfähiger Testcode möchte ich deshalb mit interessierten teilen (Umsetzungszeit 10 Minuten). Es muss dazu weder die SOA-Suite noch die Oracle Business Rule Engine installiert werden. Eine paar Libraries in Classpath reichen aus, um die Oracle RuleEngine zu nutzen. Zudem ist die Regelsprache intuitiv und kann direkt ohne Konvertierung mit Java-Objekten umgehen.

  • Herunterladen des JSR94 Spring Module
  • Die mit dem JDeveloper mitgelieferten Oracle Rules Libraries in den Classpath aufnehmen: jsr94_obr.jar, jsr94.jar, rl.jar, rl_dms.jar, rules.jar, rulesdk2.jar,  xmlparserv2.jar 
  • applicationContext.xml laut Muster anlegen:

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"
        xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance"
        xmlns:aop="
http://www.springframework.org/schema/aop"
        xmlns:tx="
http://www.springframework.org/schema/tx"
        xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd
http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.5.xsd">

    <bean id="ruleServiceProvider"
          class="org.springmodules.jsr94.factory.DefaultRuleServiceProviderFactoryBean">
      <property name="provider"><value>
http://www.oracle.com/</value></property>
      <property name="providerClass">
        <value>oracle.rules.jsr94.RLRuleServiceProvider</value>
      </property>
    </bean>

    <bean id="ruleRuntime"
          class="org.springmodules.jsr94.factory.RuleRuntimeFactoryBean">
      <property name="serviceProvider"><ref local="ruleServiceProvider"/></property>
    </bean>

    <bean id="ruleAdministrator"
          class="org.springmodules.jsr94.factory.RuleAdministratorFactoryBean">
      <property name="serviceProvider"><ref local="ruleServiceProvider"/></property>
    </bean>

    <bean id="ruleSource" class="org.springmodules.jsr94.rulesource.DefaultRuleSource">
      <property name="ruleRuntime"><ref local="ruleRuntime"/></property>
      <property name="ruleAdministrator"><ref local="ruleAdministrator"/></property>
      <property name="source">
       
<value>file:/D:/projekte/prototype/RulesIntegration/src/de/bmaier/rules/test/MyOracleRules.rl</value>
     
</property>
      <property name="bindUri"><value>MyTestOracleRules</value></property>
    </bean>

    <bean id="testRule" class="org.springmodules.jsr94.core.Jsr94Template">
      <property name="ruleSource"><ref local="ruleSource"/>
      </property>
    </bean>

</beans>

  • Wichtig sind die Einträge:
    • providerClass = oracle.rules.jsr94.RLRuleServiceProvider
    • source = Lokation der Regeldatei: (file:/D:/projekte/prototype/RulesIntegration/src/de/bmaier/rules/test/MyOracleRules.rl)
    • bindUri = Beliebiger Name, der später aus dem JavaCode bei der Regelausführung referenziert wird (hier MyTestOracleRule
  • Die RegelDatei im XML-Format JSR94 anlegen und darin die Oracle RL definieren (Beispiel Funktioniert mit Oracle Rules 11g):

    <rule-execution-set xmlns="http://xmlns.oracle.com/rules/jsr94/configuration"
    xmlns:xsi="
    http://www.w3.org/2001/XMLSchema-instance" version="1.0">
        <name>CarRentalDemo</name>
        <description>The Car Rental Demo</description>
        <rule-source>
            <rl-text>
             ruleset DM {

                   final String DeclineMessage = &quot;Rental declined &quot;;

                   public class Decision  supports xpath {
                      public String driverName;
                      public String type;
                      public String message;
                  }

                   function assertXPath(String package,
                                        java.lang.Object element, String xpath) {
                      //RL literal statement
                      main.assertXPath( package, element, xpath );
                   }

                   function println(String message) {
                      //RL literal statement
                      main.println(message);
                   }

                   function showDecision(DM.Decision decision) {
                      //RL literal statement
                      DM.println( &quot;Rental decision is &quot; + decision.type +
                                  &quot; for driver &quot; + decision.driverName +
                                  &quot; for reason &quot; + decision.message);
                   }
             }
            </rl-text>
        </rule-source>
        <rule-source>
            <rl-text>
                ruleset vehicleRent {
                    rule UnderAge {
                        priority = 0;
                        if ((fact de.arbeitsagentur.robaso.rules.test.Driver v0_Driver &amp;&amp;
                            (v0_Driver.age &lt; 19))) {
                                DM.println( &quot;Rental declined: &quot; + v0_Driver.name +
                                &quot; under age, age is: &quot; + v0_Driver.age);
                                retract(v0_Driver);
                        }
                    }
                    rule DriverAge {
                        priority = 0;
                        if ((fact de.arbeitsagentur.robaso.rules.test.Driver v0_Driver &amp;&amp;
                            (v0_Driver.age &gt; 18))) {
                                DM.println( &quot;Rental permitted for: &quot; + v0_Driver.name +
                                &quot;, age is: &quot; + v0_Driver.age);
                                retract(v0_Driver);
                        }
                    }
                }
            </rl-text>
        </rule-source>
        <ruleset-stack>
            <ruleset-name>vehicleRent</ruleset-name>
        </ruleset-stack>
    </rule-execution-set>

 

  • Das konfigurierte Springbean “testRule” laden und dann mit den individuellen “Facts” (hier Class Driver) ausführen. Achtung der Name (hier MyTestOracleRules) muss mit dem Attribut bindUri des konfigurierten SpringBean RuleSource im applicationContext.xml übereinstimmen.

        public static void main(String[] args) {

          ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext("/applicationContext.xml");
          Jsr94Template rule = (Jsr94Template)ctx.getBean("testRule");

          rule.executeStateless("MyTestOracleRules", Collections.emptyMap(), new StatelessRuleSessionCallback() {
                public Object execute(StatelessRuleSession session) throws InvalidRuleSessionException, RemoteException {
                    List result;
                    List input = new ArrayList();

                    Driver d = new Driver();
                    d.setAge(25);
                    d.setName("Dave");
                    input.add(d);
                    d = new Driver();
                    d.setAge(8);
                    d.setName("John");
                    input.add(d);

                    result = session.executeRules(input);
                    return result;
                }

            });
        }

    … dann noch die Java Klasse Driver, die im Beispiel verwendet wurde:

    package de.bamier.rules.test;

    public class Driver {
        int age = 18;
        String name = "Luis";
        public Driver() {
            super();
        }

        public void setAge(int age) {
            this.age = age;
        }

        public int getAge() {
            return age;
        }

        public void setName(String name) {
            this.name = name;
        }

        public String getName() {
            return name;
        }
    }

 

Und es funktioniert !!!

ADFFaces Features im Überblick

•9. Oktober 2010 • Kommentar verfassen

ADFFaces ist ein auf dem JEE Standard aufbauende JavaServer Faces (JSF) Komponentenbibliothek. Der Basissatz der ADFFaces UI-Elemente wurde u.a. als OpenSource der Apache Foundation übergeben und ist unter dem Name Trinidad im MyFaces Projekt verfügbar. Einstellungen und Konfigurationsfiles, die für MyFaces Trinidad gelten, sind somit auch für ADFFaces gültig.

ADFFaces liefert zu den JSF-Standardkomponenten und Trindidad-Basisklassen erweiterte Eigenschaften in folgenden Bereichen, die bei einer Architekturbewertung einzeln betrachtet werden müssen:

· Templates: Zentrale Layout-Gestaltung und dessen Wiederverwendung durch ADF-Templates.

· Skinning: Anpassung der JSF UI Komponenten an das vorgegebene Cooperate Design mit dem CSS basierten ADFSkinning Framework

· Erstellen von JSF Komponenten: Bauen von widerverwendbaren Composite JSF-UIKomponenten auf XML Basis ohne Programmierung mit dem ADF Declarative Components Framework.

· Leistungsfähige moderne RIA – AJAX Komponenten inkl. JavaScript-Abstraktion durch ADF-Rich Components. Anwendungsentwickler soll AJAX ohne JS verwenden können.

· Visuelle DVT Komponenten: Graphik-, Gantt-, Hierarchy– Chart-, Pivot-Table, GoeMap-Komponenten ,die dynamsich aus Businessdaten JSF-integrierte Graphiken erstellen und sich dynamsich bei Datenänderungen im Backend anpassen, werden durch ADF Visual RIA Components bereitgestellt. Sie interagieren mit den übrigen JSF-Komponenten und sind mit den anderen Komponenten in Bezug zu setzen – z.B. Einblenden eines Kontextmenü und starten eines JSF Dialogs beim Mouse eins Charts.

· Barrierefreiheit, zur Unterstützung von eingeschränkten Anwendernwerden eigene JSF Renderer bereitgestellt und können rein konfigurativ zur Laufzeit

· I18N Unterstützung inkl. arabische Leserichtung, CSS Anpassung und Image-Generierung.

· Dialogframework, zur Umsetzung der von MS-Windows bekannten Popups oder Dialogfolgen.

· Active Data Service, zur asynchroner Kommunikation zwischen Server und Client (Server Side Push), um den Client vom Server mit Infos und aktualisierten Daten zu versorgen ohne erneutem User-Request – ist auch unter dem Namen Coment bekannt. Wird u.a. zur Umsetzung von BI-Dashboards zum Refresh der Charts verwendet.

· Maskenflusssteuerung mit Stausverwaltung (Statemachine) und Bildung von wiederverwendbaren UI-Flows ADFController/ADFFlow:.

· Portlet: Native Integration in Standard-Portale (Portlet Bridge) und ADFWebCenter zum Bau von Prozess Interations Portale

· ADFLibrary: Java Archiv mit wiederverwendbaren UI Komponenten, wie ADFFlows, UI Komponenten, Skinns oder Templates.

· Customization mit MDS: Zur Realisierung von Varianten nach der Fertigstellung der Anwendung. Varianten können zur Gestaltung der UI Elemente, des Maskenflusses, der Logik wie z.B. Validatoren verwendet werden.

· ADFSecurity: Integration der nativen Java unter Nutzung von JAAS, bzw. Java Permissions zur Absicherung von UI-Flows, UI Seiten oder Seiten-Bereiche (Create, Read, Update, Delete).

· ADF IDE: WISIWIG Designer in Jdeveloper (Eclipse geplant) für Masken, Skin, Controller/Flows und Konfigurationseinstellungen.

· Browserunabhängigkeit in Bezug auf CSS, JavaScript und HTML. Unterstützt u.a. IE, Firefox, Chrome.

· Contextual Framework Events: Integriertes Event Framework zur losen UI-Kopplung und Integration von technologisch unabhängigen Komponenten.

· ADFHelp: Auf dem Java Standard aufbauendes Web Hilfesystem, das mit den gängigen Autoringwerkzeuge wie z.B. RoboHelp versorgt werden kann.

· UI-Statusverwaltung mit integrierter Bookmark- und Savepoint-Support.

ADFFaces /JSF Templates zur Wiederverwendung

•9. Oktober 2010 • Kommentar verfassen

Oberflächen weisen traditionell einen hohen Grad an widerholenden Bereichen auf. Die Einbindung von Fragmenten mit Include-Tags haben hier einen sehr hohen Verbreitungsgrad. Dieser Mechanismus hat jedoch einen entscheidenden Nachteile: die Fragmente werden 1:1 ohne Anpassungsmöglichkeit in die aufrufende Seite eingebunden. Änderungen am Verhalten oder an der Gestaltung lassen sich damit kaum oder nur durch Umwege realisieren. ADF löst das Problem u.a. mit den genannten ADF-Templates bzw. ADF-Declarative Components (siehe auch AMIS und Andrejus), die Aufrufparameter wie als Funktionsargumente erhalten können. Unterschieden wird zwischen einfachen Attributen und komplexe Seitenfragmet-Argumenten. Attribute steuern das Verhalten, dagegen werden Seitenfragmente am gewünschten Bereich innerhalb der Template-Vorgabe positioniert. Für ein UI-Wizard/Dialog Template würden z.B. die Buttons übergeben und im Template unterhalb den Eingabefeldern positioniert. Trotz spezifischem Verhalten der übergebenen Buttons, ist somit die Ausrichtung bei allen Seiten identisch, ohne dass er Anwendungsentwickler sich letztlich um Position oder Ausrichtung kümmern muss.

Wiederverwendung gilt in ADF als wichtiges Designprinzip: alle Seiten werden als ADF-Fragmente mit der Endung .jsff erstellt und im Seiten-Controller (ADFFlow) orchestriert. Das Einbinden der erstellten Fragmente in die JSF Hauptseiten oder auch in das Portal erfolgt erst bei der konkreten Verwendung über das JSF-Elemente Region und Dynamic Region (<af:region>). Jede ADF-Region verwaltet den Maskenstatus autark womit mehrere unabhängige Anwendungsfälle (z.B. ausführen der Kundenauskunft während man in einer parallel angezeigten Region Auftragsdaten ändert) parallel in der selben Maske gestartet werden können.

Die Problematik, dass somit mehrere HTML-From Elemente geschachtelt in einer Seite vorhanden sein können – ist in HTML untersagt, wird in ADF mit dem Tag <ad:form> und <af:subform> gelöst. In Seitenfragmenten sollte deshalb stets <af:subform> anstatt af:form verwendet werden.

Widerverwendung bedeutet auch technologisch auch Upgradefähig zu sein. Die klassische JSP Entwicklung, bei der verschiedene Sprachen (HTML, Java, JavaScript, CSS, JSP-Tags), in einer Datei gebündelt verwendet wurden lassen sich bei einem Innovationsschub nur schwer in eine neue Technologie überführen..

ADFFaces & Facelets

Alternative zu den ADF-Templates existiert das Template-Framework Facelets, das u.a. in der JSF Version 2 mit im Standard enthalten sein wird. ADF unterstützt Facelet bereits seit der ersten Version. Dem Paradigma als Auszeichnungssprache XML (XHTML) anstatt, JSP Syntax zu folgen, wurde seit Beginn der ADF Entwicklung gefolgt. Die Verwendung von Facelet als Definitions-Struktur für Seiten ist deshalb einfach möglich und bringt den Vorteil der kurzen Turnaround-Zeiten bei der Entwicklung – JSP-Compile, Deploy, Class-Reload entfällt.

Derzeit wird jedoch Facelet in ADFFaces nicht in der Kombination mit ADF-Templates und ADF-Page-Fragmenten unterstützt, da der ADF-Template Mechanismus bereits seit 2002 im UIX Framework existieren und es damals noch keine Facelets gab. Mit einer nächsten ADF Version, die u.a. JSF 2.0 unterstützt, wird sich diese jedoch ändern.

ADF Projekt – Best Practice

•30. Juli 2010 • Kommentar verfassen

Immer wieder werde ich gefragt wie wir von Oracle Consultant ADF-Projekte richtig aufsetzen. Leider ist es bei ADF wie überall in der Softwareentwicklung: die Anforderungen legen die Architektur und das Vorgehen fest und nicht das Framework. Ich möchte deshalb in einer kleinen Blog-Folge eine paar Ansätze diskutieren, die den Interessierten eine kleine Orientierungshilfe geben. Dabei will ich nur auf rein architektonische und technische Aspekte und nicht auf die in unseren Projekten meist verwendete Methode OUM (Oracle Unified Method) eingehen.

Im IT-Umfeld setzt sich ja vermehrt die Erkenntnis durch, dass die traditionellen Monster-Anwendungen und ihre enge Kopplung langfristig einem Unternehmen mehr schaden als sie nützen. Betroffen sind dabei nicht nur alte Cobol oder PL-SQL Anwendungen, sonder vor allem auch J2EE Anwendungen, die traditionelle Aufgaben wie Master Data Management, Identity- und AccessManagement, Reporting usw. immer wieder monolithisch neu implementieren. Ich plädiere deshalb dafür sich bei einer Neuimplementierung nur auf die Kernaufgaben zu konzentrieren und klare fachliche und technische Domänen auf Grundlage des Domain Driven Developments (DDD) zu bilden.

Lose Kopplung klare Schnittstellen und übergreifende Zusammenarbeit (Collaboration) der Softwarebausteine (Building Blocks) ist also ein muss beim Design einer Anwendung.

Und nun zu ADF. ADF mit alle seinen Sub-Frameworks biete viele Möglichkeiten Digen richtig order auch falsch zu machen. Deshalb treffen wir zuerst ein paar Vorentscheidungen, bevor wir beginnen:

1.) Die Daten und deren Qualität sind oft das wertvollste einer Anwendung, weshalb die Datenbank nicht automatisiert aus den Java-Objekten (EntityObject) generiert werden, sondern von einem erfahrenen Datenbankdesigner erstellt werden. Der DB-Designer sollte natürlich auch das ER-Modell mit einem grafischen Tool wie z.B. MID-Innovator Data erstellen und beim Einsatz des MDA/MDSD-Generators die Templates mit angepassten Designentscheidungen (physisches DB Design) bereitstellen. 

1.1) In der Anwendungsdatenbank sollten keine Masterdaten (Bundesländer, Kunden, Organisationseinheiten) gehalten werden und diese alleinig über eindeutige Schlüssel (GUID) logisch referenziert werden – hier existiert kein DB-Constraint (Ausnahmen durch programmatische CheckConstraint z.B. in einer PLSQL-Funktion).

1.2) Als Objekt-Schlüssel (Primary-Key) werden stets nichtsprechende eindeutige IDs (GUID) verwendet.

1.3) Constraints außerhalb der Fachdomäne werden über die Business-Logik abgehandelt und nicht durch native Datenbankmittel wie CheckConstraints (ALTER TABLE table_name enable CONSTRAINT constraint_name;)

1.4) Die letzte Änderung eines Datensatzes wird je Tabelle durch zwei Change-Indikator Felder (Zeit + Benutzer aus LoginContext) gekennzeichnet.

1.5) Historisierung in einer relationalen OLTP-Anwendung lässt sich nur mit hohem Aufwand realisieren und ist soweit wie möglich vermeiden. Bei einer Anforderung zur Nachvollziehbarkeit wird das Prinzip der zentralen ChangeHistoryTabelle mit eingeführt. Notwendige Columns: Zeitpunkt, Benutzername, alter Wert, neuer Wert.  Aus Performanzgründen muss ein zyklischer Bereinigungslauf vorhanden sein und die angefallenen Alt-Daten archivieren. 

1.6) Die Datenbank sollte mindestens die Normalisierungsstufe  aufweisen, bevor man beginnt die Entity-Objekte zu erstellen. Ein Refactoring ist heute zwar per Jdeveloper möglich, verursacht jedoch einen riesen Aufwand.

1.7) Ein EntityObject basiert immer auf einer  Tabelle und nicht auf einer DB-View. Ausnahmen mit einer 1:1 View sind möglich; es ist jedoch zu Bedenken, dass hier oft Seiteneffekte mit dem ADF-Cache auftreten.   

 

Die Liste werde ich in dem Blog die nächsten Monate fortsetzen!

SOA & Cloud Symposium 2010 in Berlin (5.-6. Oktober)

•30. Juli 2010 • Kommentar verfassen

Unter dem Mott “Scaling Your Business and Infrastructure into the Cloud” findet die renommierte Veranstaltung rund um SOA und Cloud dieses Jahr am 5 und 6. Oktober in Berlin statt.

Zu den Sprechern zählen Thomas Erl, Dirk Krafzig, Stefan Tilkov, Mark Little, Brian Loesgen, John deVadoss, Nicolai Josuttis, Tony Shan, Toufic Boubez, Paul C. Brown, Clemens Utschig, Satadru Roy, David Chou, Torsten Winterberg, Berthold Maier, Hajo Normann und vielen anderen – sie alle bringen neue Ideen, praktische Projekterfahrung und exklusive Informationen aus allen Bereichen des SOA und Cloud Computings ein und freuen sich auf die Diskussion mit Ihnen.

Themen aus den folgenden Bereichen werden auf dem Symposium diskutiert:

    Scaling Your Business and Infrastructure into the Cloud
    • The Latest Cloud Technology Innovation
    • Building & Working with Cloud-Based Services
    • Cloud Computing Business Strategies
    • Case Studies & Business Models
    • Understanding SOA & Cloud Computing
    • Cloud-based Infrastructure & Products

    Exploring Modern Service Technologies & Practices
    • Service Architecture & Service Engineering
    • Service Governance & Scalability
    • SOA Case Studies & Strategic Planning
    • REST Service Design & RESTful SOA
    • Service Security & Policies
    • Semantic Services & Patterns
    • Service Modeling & BPM

 

Im direkten Anschluss an die Veranstaltung findet am 7. und 8. Oktober 2010 ein zusätzlicher Workshop rund um das Thema Cloud Computings statt.

Die Veranstaltung ist Pflicht, für alle die sich im SOA oder Cloud Umfeld bewegen. Wer sich beeilt, der kann über die Early Bird Registration noch ein paar Euro sparen. Bis zum 31.07.2010 gibt es 100 € Rabatt für Firmen und Organisationen. Studenten erhalten ohnehin einen 80%igen Rabatt. Oder man bucht über Firmen wie, Oracle, MID, IBM, SAG, usw. bei denen man einen Discount von 5% erhalten kann. Die offizielle Registrierung findet man hier.

ADF Strukturierung – Best Practices

•29. Juli 2010 • Kommentar verfassen

Immer und immer wieder sehe ich Kunden-Projekt in denen eine ADF-Projektstruktur erstellt wurde, die 1:1 aus dem  Jdeveloper Standard-Wizard generiert wurde.
Problematisch daran  ist, dass diese Struktur sich weder für Wiederverwendung noch konkurrierende Programmierung eignet. Als Regel gilt  in unseren  Projekten deshalb  immer:

  • Es es existiert auf oberster Ebene  immer ein ADF- Framework Projekt für das ADF-Model und die ADF-UI. Das ADFModeCommon Projekt enthält die  Basisfunktionalität des Modells wie Protokollierung, VPD Anmedlung usw.  des ADF Models. Das ADFUICommon Projekt enthält die Basisklassen der Oberfläche wie z.B. Internationalisierung, Help-Einbindung usw.
  • Die EntityObjekte und Associationen werden in einem eigenen Projekt, getrennt von AppModule und ViewObjects gespeichert. Die Strukturierung und Anzahl der Projekte erfolgt durch Vorgabe der  fachlichen Domänen.
    Beispiel: Entities der Versicherungsdomäne Vertrag oder Partner werden jeweils in eigenen Entity-Projekten verwaltet. Die Anlage von Association über die Grenze einer Fachdomäne sollte soweit wie möglich vermieden werden (Kopplungsgrad).
  • ViewObjects gelten als Objektschnittstellen zu den Fachanwendungen und sollten deshalb die identische  Projektgranularität aufweisen. Es wird jedoch erst ein ViewObjet angelegt, wenn es wirklich gebraucht wird und niemals der Wizard zur Default-Gernerierung (1:1 zu Entities)   verwendet werden – erzeugt zu viel Objekte, die danach verwaltet werden müssen. Die Funktion der View-Object Vererbung ist hier ein ganz wichtiges Feature, um tatsächlich Wiederverwendung zu gewährleisten und die  wiederholte Definition aller Attribute zu vermeiden.
  • Die Nameskonvention der  Wizards sind  sehr technisch und sollte immer überschrieben werden:
    • Entity Objekte werden immer wie das fachliche Geschäftsobjekt, ohne dem Anhang Entity, benannt und unter demSub- Package bo abgelegt  (Beispiel: de.mycompany.mode.bo.customer.Address)
    • View Objecte werden ebenfalls  fachliche getrieben , ohne dem Anhang View,  benannt und unter demSub- Package vo abgelegt  (Beispiel: de.mycompany.mode.vo.customer.CustomerAddress)
    • Bei der Namesvergabe der  Entity Associations sind verwende ich immer die Konvention BaseObject2DestinationObjectAccociation. Eine strikte Regel kann aufgrund der unterschiedlichen  Kardinalitätsmöglichkeiten und Eindutigkeit innerhalb einem Projekt  nicht geben.    Zudem müssen die Asscciationen nach der Anlage durch den Refactor-Wizard verschoben und umbenannt werden.
    • Für ViewLinks sind die identischen Regeln wie bei den Associations anzuwenden. einziger Unterschied ist, dass sie im Sub-Package der VO abgelegt und mit dem Nameszusatzs Link angelegt werden.
    • ApplicationsModules ist für die meisten ein nicht aussagekräftiger Begriff. Ich verwende deshalb stets den Begriff und Strukturierungsmerkmal Component oder Service. Zu Components(AppModule)  werden alle wiederverwendbare kleine Einheiten. Den Begriff Service verwende ich für AppModule dann, wenn ein Service nach außen sichtbar und damit öffentlich wird. Beispiel:  OrderManagementService, OrderComponent, CustomerComponent, usw.