ADF Projekt – Best Practice

•30. Juli 2010 • Schreibe einen Kommentar

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!

Advertisements

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

•30. Juli 2010 • Schreibe einen Kommentar

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 • Schreibe einen Kommentar

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.

SOA Literatur: Integration und Blueprint

•29. Juli 2010 • Schreibe einen Kommentar

bald wir eine sehr interessantes Integrations-Architekturbuch rund um SOA von meinem geschätzten Kollegen und exzellenten Architekten Guido Schmutz und seinen  Mitautoren Peter Welkenbach, Daniel Liebhart im PACKT Verlag  erscheinen.

Service Oriented Architecture: An Integration Blueprint

clip_image002

http://www.packtpub.com/service-oriented-architecture-an-integration-blueprint/book?utm_source=bmaier.wordpress.com&utm_medium=bookrev&utm_content=blog&utm_campaign=mdb_003972

ADFFaces und GoogleMaps

•29. April 2010 • Schreibe einen Kommentar

Heute wird oft die Anforderung gestellt, die Lokation einer Adresse zu prüfen und diese dann per GeoMap zu visualisieren.

Eine sehr einfache und auch interaktive Lösung stellt zwar OracleMaps mit der ADFFaces MapComponente dar, doch oft ist eine nicht interaktive Lösung mit GoogleMap gefordert. Dies in mit ADFFaces umzusetzen ist mit ein paar Handgriffen möglich. Bei diesem Beispiel habe ich mich entschieden ein ADF-Texteingabefeld zu verwenden, das am linken Rand eine kontextgestützten Aufruf ermöglicht und damit ein Popup-Dialog mit integrierte GoogleMap  aufzurufen.

image

Das eingebettete Element <af:contextInfo> blendet einen modernen AJAX ContextButton am linke Rand des Eingabefelds ein.

image

 

image

 

Mit dem Element <af:showPopupBehavior> kann ein AJAX-Aufruf initiiert werden, der ein Popup-Dialog aufruft und die GoggleMap mit Lokation zur Darstellung bringt.

image

Zur Darstellung des Dialogs sind nur eine paar wenige Zeilen Code erforderlich.

 

image

 

und hier der gesamte Code des Beispiels:

 

image

 

Die GoogleMaps-Adressierung erfolgt im Bespiel per Google-URL und deklarativer Übergabe der Lokation an den Dialog wie folgt:  

<af:clientAttribute name="searchText" value="#{pageFlowScope.tmp}" />

Das Auslesen des Parameters im PopupDialog wird mit dem <af:setPropertyListener>  Element erreicht.

<af:setPropertyListener from="#{source.attributes.searchText}"
                          to="#{pageFlowScope.searchText}" type="popupFetch"/>

Weder Java noch JavaScript-Programmierung ist für diese Lösung notwendig.  Sollte das InlineFrame stören, so sind auch alternative Lösungsansätze denkbar.

Zusammenfassung: Oracle ADF und SOA

•26. April 2010 • Schreibe einen Kommentar

ADF ist eine Komponentenframework das folgende Möglichkeiten einer SOA-Integration mit WebService bietet:

  1. ADF kann JAX WS-Konforme SOA Service der Kategorie Activity-Service bereitstellen (siehe SOA Referenzarchitektur). Hierbei wird in der Komponente ApplicationsModul die ServiceMethode als normale JavaMethode implementiert und dann als WebService per Dialog exponiert.
    Objekte, die als Übergabeparameter der ServiceMethoden dienen, müssen das Interface java.io.Serializable implementieren und als ClientInterfaces des ApplicationModule eingetragen werden, um im ServiceDialog überhaupt als WebService-Implementierung zur Verfügung zu stehen.

image

 

    • Auf Ebene der ApplicationModules "(Activity-Service) sind die drei Message Exchange Pattern (MEP) Synchrone, Asynchron Fire and Forget und Asynchron Request-Reply vorhanden. Beim MEP Asynchron-Request-Reply muss der Client einen Http-Server als Listener und eine CallbackMethode implementieren, damit der Server zeitverzöger das Ergebnis an den Client ausliefern kann. ADF generiert nach Auswahl der Option Asynchronous den zugehörige ServerCode inkl. der separaten asynchronen Methode mit dem Namenszusatz Async (z.B. MyMthodeNameAsync).

image

 

image    

    • Die dritte Art der SOA-Verwendung besteht in der Verwendung der SDO Remoting Option. Hier werden die ADF-EntityObjects  (EO) auf Basis der SDO ViewObject Webservice  eines unabhängigen Projekts erstellt. Damit kann ein ADF-Datenbank Model Projekt SDO WebService anbieten und diese wiederum als SOA-Datenmodell wie oben erläutert bereitstellen. Das zweite konsumierende Projekt kann somit das identische Programmiermodell anwenden und sehr einfach sogenannte “Service Based Business Applications (SOBA)“ auch mit SCA und BPEL ohne große Programmierung realisieren. Wichtig zu wissen ist, dass derzeit (11.1.1.2) die SDO ViewObjects basierende EntityObjects noch einige Einschränkungen gegenüber den üblichen EO’s auf Basis der DB-Tabellen haben.

image

 

    • EntityVariablen stellen spezielle SDO Variablen innerhalb der Oracle BPEL Orchstrierungsengine dar. Diese können direkt auf den oben genannten SDO ViewObjects basieren und somit eine schnelle Datenkommunikation zwischen BPEL und ADF-BC über Standard WebService herstellen. Mit dieser Lösung lässt sich ohne viel Overhead das SOA Programmiermodelle noch einfacher umsetzen.

 

Die Zusammenfassung listet lediglich die SOA ADF Möglichkeiten auf, ohne auf die BestPractices einzugehen. In folgenden Blogs werde ich unsere BestPractices und die konkrete Umsetzung einer SOA mit ADF diskutieren.

SOA funktioniert nur mit eindeutigen Objektschlüssel und nicht mit lokalen DB-Sequenzen

•5. April 2010 • 1 Kommentar

Architektonisch ist es ein muss jedes Objekt mit einem eindeutigen Identifier (Schlüssel/Key) zu versehen. Ich persönlich tendiere sogar zu sagen, dass Objektschlüssel und nicht zuletzt der PrimaryKey in der DB weltweit eindeutig sein muss und nicht mit einer einfachen DB-Sequenz erzeugt werden sollte. Alternative zur Sequenz sollte die GUID () Funktion (evtl. noch Versionsnummer) in der Oracle DB verwendet werden. Erst mit dem eindeutigen Objektschlüssel lässt sich eine erfolgreiche SOA mit dedizierten Domänen und Verantwortlichkeiten (Daten- bzw. Objekthoheit) etablieren. Auch das XRef Pattern mit einer Übersetzungstabelle in der Mitte sollte nur als letzter Lösungsansatz in Betracht gezogen werden. Das Verwenden von Datenbank Constraints zu externen Domänenobjekte sind in einer SOA gänzlich zu vermeiden – Domänenintern sind sie natürlich erlaubt. Ohne konsequentes anwenden dieser Prinzipien wird eine SOA von der Prozessorientierung zur Datenreplikation verkommen – leider sehe ich das schon heute allzu oft. Insbesondere DB-Designer und ad hoc Anwendungsentwickler müssen sich in einer SOA zu dem Grundsatz Divide et impera zurückbesinnen.