OERA OpenEdge Reference Architecture. Mike Fechner PUG Infotag 19. Mai 05 Frankfurt

Transkript

1 OERA OpenEdge Reference Architecture Mike Fechner PUG Infotag 19. Mai 05 Frankfurt

2 Überblick OERA Separated presentation and integration layers Common business logic with advanced models Data access abstracted from storage Users Users Presentation Layer Managed Managed Data Data Stores Stores Business Servicing Layer Data Access Layer Enterprise Enterprise Services Services Integration Layer Unmanaged Unmanaged Data Data Stores Stores Environment Managers and Utilities API layers and event systems for flexibility

3 OpenEdge Reference Architecture Benutzt/benötigt Features der Version 10 Maßstab für weitere Entwicklungen ab Progress Version Maßstab für weitere Entwicklungen der Progress Version Konzepte nicht sinnvoll mit Progress 9 realisierbar (kein ProDataset)

4 OpenEdge Reference Architecture Beispiel für den Einsatz der aktuellen Progress Produkte Kein zwingender Maßstab für Applikationen Beispiel Code erhebt keinen Anspruch auf Vollständigkeit bzw. Adaption von Progress Entwicklern Einsetzbarkeit so wie vorgestellt fragwürdig

5 OpenEdge Reference Architecture Zeigt eine Architektur für typische Anforderungen von SOA/N-Tier basierenden Anwendungen auf Kein Framework! Somit auch keine Alternative zu Dynamics Wegweiser für zukünftige Progress Entwicklungen (z.b. in der 4GL) Konzepte vergleichbar mit Forte oder J2EE

6 OpenEdge Reference Architecture Vorgestellt vor ca. 1 Jahr auf der Exchange in Las Vegas Whitepapers/Beispiele seit Jan `05 Zielgruppe sind Architekten/Projektverantwortliche

7 OpenEdge Reference Architecture Einführung Business Entities Service Interface Layers Advanced ProDataset Features Unmanaged Data Stores Alternatives UI (.NET/C#) Beispiel Code

8 Kerntechnologien Progress 4GL ProDatasets Application Server OO Konzepte

9 Business Entities Business Logic aus Prozesssicht, unabhängig von Maskendesign Weit mehr als nur Daten lesen und validieren Nutzbar über ein Standard-Interface Können/sollen miteinander kommunizieren

10 Business Entities Aufteilung von Business Logic und Datenzugriff Datenzugriffsobjekte pro Tabelle Datenzugriffsobjekt pro Dataset Business Rules Objekt(e) Datenzugriffsobjekte benötigen i.d.r. keinen Zugriff auf Session Informationen

11 Business Entities Weitreichende Folgen für bestehende Business Logic Vergangenheit: Erst Trennung UI und Logic Jetzt: Zusätzlich Trennung Logic und Datenzugriff Trennung u.u. im Übergang nicht erforderlich (Business Entity und Data Access kombinierbar)

12 Business Entities Wie sieht die Performance aus, wenn eine Business Entity mit einer anderen kommuniziert? Instanzierung Initialisierung Benötigten Daten bereit stellen

13 Business Entities Eine Funktion in der Kunden BE benötigt eine Information aus der Auftrags BE Diese Funktion benötigt eine Buchhaltungs BE Performanter wäre in jedem Fall: FIND Customer FIND Order OF Customer WHERE Status FIND Payment OF Order WHERE Status

14 .NET Beispiele Noch sehr stark unvollständig Mischung Controls/Klassen Service Interface bietet keine Unterstützung für Batching Keine Unterstützung für Fehler/Nachrichten Datasets werden über XSD definiert (statt aus dem ProxyGen)

15 .NET Beispiele

16 Was fehlt? Konzepte zur Reduktion des Netzwerktraffics Clientseitiger Framework Fehlerbehandlung Umgebungs-Services (Manager)

17 Ist die 4GL reif für die OERA 10.0B bedingt 10.1A eher 10.1A+ noch eher Zurzeit kein Tool Support (Wizards, Designer, etc.), vielleicht besser in Beta 1 ab 13. Juni Kein Depot für Business Logic/Datenzugriffs Komponenten

18 Ist der AppServer reif Es fehlen wesentliche Konzepte zur Verwendung der Business Entities oder Service Komponenten über mehrere AppServer Calls oder Sessions hinweg State-Less oder State-Free am Ende? Über persistente ProDatasets wird vorsichtig und unverbindlich diskutiert Weitere Session-Modelle erforderlich? Transaktionsmanagement

19 Vielen Dank für f r Ihre Aufmerksamkeit! Mike Fechner mike.fechner@fechnerschneider.de