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!

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:

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

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.

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!

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.

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

Service Oriented Architecture: An Integration Blueprint

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

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.

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

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

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

und hier der gesamte Code des Beispiels:

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.

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.

• 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).

• Service der Kategorie Data-Service werden in ADF ebenfalls angeboten. Hier werden jedoch die genannten ViewObjects (DataTransferObject DTO) als SDO (Service Data Object) WebService exponiert. Diese enthalten die üblich CRUD Methoden  (Create, Read, Update, Delete), sowie die Custom-Operationen der ViewObjects. Zudem können alle Find-Methoden mit den SuchCriterien als WebService Methoden dem Consumer zur Verfügung gestellt werden. U.a. wird SDO in ADF mit dem EclipseLink Framework Implementiert.

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

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