Überblick über die wichtigsten Features der neuen JBF-Version

Präsentation zum Thema: "Überblick über die wichtigsten Features der neuen JBF-Version"—  Präsentation transkript:

1 Überblick über die wichtigsten Features der neuen JBF-Version
Inside Pallas Überblick über die wichtigsten Features der neuen JBF-Version R. Eichinger, O. Fischer, R. Koutny, Technische Architektur | JBFOne 2008

2 Ziel dieses Vortrags Sie sind mit den neuen Versionierungsregeln für die einzelnen Frameworkmodule von JBF vertraut und kennen die Auswirkungen auf Ihr Projekt oder Ihre Anwendung Sie haben einen Überblick über die wichtigsten Features der neuen Versionen von JBF Pallas Die Einsatz- und Anwendungsgebiete ausgewählter Features von JBF sind Ihnen bekannt

3 Agenda Versionierung von neuen JBF-Versionen
JBF Pallas - die wichtigsten Features im Überblick JBF ClientContext Erweiterte Steuerung von Application Services XBF Content-Integrator

4 Agenda Versionierung von neuen JBF-Versionen Einleitung
Definition Major-Version Definition Minor-Version Definition Fix-Version Systematik der Versionsnummernvergabe JBF Pallas - die wichtigsten Features im Überblick JBF ClientContext Erweiterte Steuerung von Application Services XBF Content-Integrator

5 JBF – Versionierung - Einleitung
Die nachfolgend beschriebene Systematik für die Vergabe von neuen Versionsnummern gilt für die Module von JBF (dam, jbf, jbf-modules, jdo, servicecontainer, wespe, xbf) und beschreibt die Auswirkungen, die sich daraus für die Entwickler im Frameworkteam und bei den Projekten ergeben. Die hier definierten Regelungen gelten je JBF-Modul und können deswegen hinsichtlich Major- oder Minorversion bei den einzelnen Modulen zu unterschiedlichen Ergebnissen innerhalb eines Releases führen. D.h. es kann z.B. eine Majorversion von DAM geben und nur eine Minorversion von JBF.

6 Definition Major-Version
Im Rahmen einer Major-Version sind Änderungen jeder Art erlaubt, also Bugfixing neue APIs geänderte APIs Wegfall von deprecated Klassen oder Methoden neue JDKs Die Auswirkungen für Framework-Nutzer können also entsprechend umfangreich sein, da es teilweise zu größerem Aufwand für Recompile, Codeanpassungen und Tests kommen kann.

7 Definition Minor-Version
Im Rahmen einer Minor-Version sind auf Nutzerseite Codeanpassungen und Testaufwand nur in geringem Umfang zu erwarten. Mit Bugfixing, neuen APIs und neuen Modulen ist zu rechnen. API-Änderungen erfolgen nur dann, wenn von geringem Aufwand für Codeanpassungen auf der Nutzerseite auszugehen ist. Klassen und Methoden, die zuvor als „deprecated“ gekennzeichnet waren, bleiben bestehen. Den Framework-Nutzern wird ein Recompile grundsätzlich immer empfohlen; bei entsprechender Eignung kann es sein, dass nicht alle Nutzer einen Recompile machen müssen. Dies wird durch das JBF-Team vor Beginn einer BAP-Stufe geprüft und über das BAP-JF entsprechend kommuniziert.

8 Definition Fix-Version
Mit einer Fix-Version werden grundsätzlich nur Fehler behoben, d.h. es handelt sich in diesem Fall um reines Bugfixing. Im Rahmen einer Fix-Version ist nicht mit funktionalen Erweiterungen sowie neuen oder geänderten APIs zu rechnen. Die Framework-Nutzer müssen weder einen Recompile noch Codeanpassungen vornehmen.

9 Versionsnummernsystematik
Pattern: MM.mm-ff MM = Major-Versionsnummer (ohne führende Null) mm = Minor-Versionsnummer (mit führender Null) ff = Fix-Versionsnummer (mit führender Null) Beispiele (Major-Version 6, noch keine Minor- oder Fixversion) (Fixversion 10 zu Major-Version 6) (Fixversion 7 zu Minor 05 der Major 6)

10 Versionsnummernsystematik – Vergabe
Major-Versionsnummer: lückenlos fortlaufend Minor-Versionsnummer in 5er-Schritten bei Avisierung neuer Versionen (sh. Erläuterung) fortlaufend für kurzfristig geplante Version Fix-Versionsnummer lückenlos fortlaufend Erläuterung: Das Hochzählen der Versionsnummer in 5er-Schritten dient dazu, für kurzfristig und nicht geplante funktionale Erweiterungen noch „freie“ Versionsnummern zur Verfügung zu haben. Beispiel: JBF 6.00 wird für BAP3.2 bereits produktiv eingesetzt, JBF 6.05 ist mit einem festgelegten funktionalen Umfang für BAP3.3 angekündigt Für BAP3.2 ist eine funktionale Erweiterung in JBF erforderlich (z.B. wegen Backport einer funktionalen Erweiterung aus BAP3.3), dann kann für diese BAP3.2-Version, die z.B. mit einem UG ausgebracht wird, die Nummer 6.01 verwendet werden.

11 Agenda Versionierung von neuen JBF-Versionen
JBF Pallas - die wichtigsten Features im Überblick JBF ClientContext Erweiterte Steuerung von Application Services XBF Content-Integrator

12 Pallas – die wichtigsten Features im Überblick
[2323] Erweiterte Batchsteuerung für Horizon (z.B. Suspend, kill, Commitparameter ändern) [2658] Java 6 Unterstützung in Entwicklung und Build Erweiterung der DB-Schnittstelle für HORIZON-1.1 um ein weiteres RDBMS (DB2 im integrierten Umfeld, zusätzlich zu Oracle) [3166] Integration Distributed Cache (Coherence) [2443] Tastatursteuerung zur Unterstützung bei Datenschnellerfassung [2776] Alternative Pflichtfelddarstellung möglich (* statt Schatten) [2471] Neuer ClientContext, berücksichtigt Horizon-Spezifika und löst JBFClientDescriptor ab [2286] Erweiterte Steuerung von Application Services XBF-Content-Integrator als Ablösung des eBanking-Content-Aggregator

13 Erweiterte Batchsteuerung für Horizon
Ziele der Erweiterung Bei laufenden BatchJobs ist es nun möglich, den Wert des P_COMMIT-Parameters herabzusetzen, damit im Tagesbetrieb innerhalb einer Transaktion (Restart- Transaktionsschleife) nicht zu viele Sätze gesperrt bleiben und der Dialogbetrieb damit gestört wird. Es ist möglich, laufende BatchJobs für eine vorgegebene Zeit anzuhalten. Diese „schlafen“ nach dem letzten Commit (damit alle gesperrten Sätze freigegeben sind) der Restartverarbeitung eine vorgebende Zeit lang. Über dieselbe Schnittstelle ist es auch möglich, einen BatchJob sofort zu stoppen.

14 Erweiterte Batchsteuerung für Horizon
Ablauf Die Steuerkommandos werden über eine zentrale DB Tabelle abgesetzt (JBF00_COMMANDS_T01). Auf diese greifen alle Jobs zu, die in einem PLEX laufen. Zum Startzeitpunkt fügt jeder Job - der auf JBF BatchBasis basiert - einen Satz mit den Informationen bzgl. CustomerId, Laufname, Laufzinfo, Status, Commit-Wert in diese Tabelle ein. Die JBF BatchBasis greift zentral auf diese Tabelle zu und steuert alle in der JASS- Instanz laufenden Jobs entsprechend den abgesetzten Kommandos.

15 Java 6 Unterstützung in Entwicklung und Build
Mit BAP 3.4 wird Java 6 auch in Entwicklung und Build unterstützt. Aus Kompatibilitätsgründen im Verbund erfolgt in noch eine Restriktion auf Sprachfeatures von Java 5. Der Compiler Compliance Level ist derzeit noch auf 1.4 eingestellt, d.h. die Sprachfeatures von Java 5 können derzeit noch nicht genutzt werden die Java-5-Bibliotheken dagegen schon Ziel ist es, ab Ende November auch die Nutzung der Sprachfeatures gemäß nebenstehender Tabelle freizugeben. Weitere Informationen dazu im Vortrag „Java 6 - es hat sich out-gecastet“ Sprachfeature Nutzungsempfehlung Generics Nutzung unbedingt empfohlen. In neuen APIs nutzen. Bestehende APIs nicht anpassen. Typesafe-Enums Nutzung empfohlen. Sind kein Ersatz für modellierte fachliche JBF-Enums beim API Design Standard Java Annotations Unbedingt empfohlen Weitere und neue Annotations Nur nach Rücksprache mit Architektur For-Each Schleifen Enhanced for-loops Vararg Parameter Nutzung von bestehenden Methoden erlaubt (z.B. printf). Design neuer Methoden nur in besonderen Fällen. Static import Auf wenige import Anweisungen pro Java-Datei begrenzen. Boxing/Unboxing Untersagt

16 Erweiterung DB-Schnittstelle für Horizon 1.1
In der SteuerAPI können jetzt DB- Verbindungsinformationen für mehrere unterschiedliche DB-Systeme konfiguriert werden. In der JBF00_CNALIAS_T01 Tabelle werden jetzt Aliasnamen für DB2 und ORACLE gespeichert. Die Festlegung, welches DB-System benutzt wird, wird durch die Zuordnung Komponentennamen zu DB-System oder per Default (ORACLE) definiert. Soll eine Komponente ein anderes DB-System als Default nutzen, wird in der Tabelle JBF00_COMPONENT_T01 eine entsprechende Zuordnung eingetragen. Im JBFDBTXManager sind neue Methoden definiert, die anhand des Klassennamens die entsprechende Connection aus JBF00_COMPONENT_T01 ermitteln.

17 Integration Distributed Cache
Mit JBF 6.05 und 7.01 steht für das Plex- weite Caching von Daten das Produkt Oracle Coherence zur Verfügung. In einem ersten Schritt wurden Quick Wins realisiert und die nachfolgenden Daten gecached: Organisationseinheiten BLZ- und BIC-Liste IKESA Alle über PSF (Property Storage Facility von JBF) abgelegten Daten Eine allgemein verfügbare API wird mit JBF Triton bereitgestellt werden. Weitere Informationen in den Vorträgen: Data Grid Patterns (26.11., 15:25 Uhr) Oracle Coherence – Einführung und Anwendungsfälle (26.11., 16:25 Uhr)

18 Datenschnellerfassung und alternative Pflichtfelddarstellung
Eine neu implementierte XBF FocusTraversalPolicy erlaubt die Definition einer Reihenfolge und das Überspringen einzelner Controls in einer Eingabemaske per Konfiguration. Diese Konfiguration der Reihenfolge wurde in den GUI-Builder JUICE integriert, kann aber auch direkt über eine neue API erfolgen. Alternative Pflichtfelddarstellung Die neue Pflichtfelddarstellung stellt links neben UI Controls mit Pflichtfeldeigenschaft ein Stern-Icon dar. In JBF 7.00 ist standardmäßig die alte Pflichtfelddarstellung mit einem verstärkten Rahmen aktiv. Die neue Darstellung kann durch Setzen eines System Property aktiviert werden. Fachprojekte können ab JBF 7.00 die für die neue Darstellung nötigen Ändernungen der Oberfläche durchführen. Wenn alle Oberflächen umgestellt sind, wird in einer noch zu bestimmenden späteren JBF-Version die neue Darstellung Standard.

19 Agenda Versionierung von neuen JBF-Versionen
JBF Pallas - die wichtigsten Features im Überblick JBF ClientContext Erweiterte Steuerung von Application Services XBF Content-Integrator

20 ClientContext: JBFClientDescriptor
Server User / Passwort ohne JBFClientDescriptor Logon Anmeldung OK / NOT OK mit Ticket + User-Daten JBFClientDescriptor und Request Führe Service aus Service- Call Erzeuge JBFClientDes. Aus UserDaten Response

21 ClientContext: JBFClientDescriptor Nachteile
Enthält noch die alte RZBK statt der neuen 10-stelligen Customer-Id für Horizon Es fehlen Client Properties für Sprache des Clients (deutsch, englisch…) Zeitzone des Clients IP-Adresse, die der Server sieht (Citrix, NAT) … Machine-UUID (identifiziert den Client eindeutig) wird separat transportiert Transport erfolgt ausschließlich über serialisierte Objekte In Zukunft soll der Kontext z.B. auch über XML / http erfolgen JBFClientDescriptor ist nicht flexibel schlecht erweiterbar umständlich, wenn am Server „per Hand“ ein eigener Kontext erstellt werden soll

22 ClientContext: Neu in Pallas
JBFClientDescriptor existiert weiterhin, ist aber deprecated Der neue ClientContext ist über Properties Konzept erweiterbar Beinhaltet neue Felder für Sprache, Zeitzone etc. ContextProvider liefert nicht änderbare (immutable) Interfaces zurück EndpointInformation Name (bei Bank-APs der ‚FW’-Name) Type (unterscheidet JASS, JBF-Client u.a.) Identifier (bei Clients die ehemalige Machine-UUID) isCitrixFAG (true bei JBF-Anw. auf Citrix-Server) EndpointProperties ClientContext AddressInformation (DestinationAddress – Defaultzieladresse des Client) EndpointInformation (Endpunktinformationen des Clients) AddressInformation (z.B.). IP-Adresse des Endpunktes) CustomerInformation (Mandanteninformationen) LocaleInformation (z.B. Zeitzone, Zeichensatz) IdentityInformation (Informationen über die angemeldete Identität) PlatformInformation (z.B. Betriebsystem, Java/JBF-Version) SessionInformation (Sessionbezogene Informationen)

23 ClientContext: MutableContextProvider
Die Klasse MutableContextProvider ermöglicht die Erzeugung eines MutableClientContext Objekts Bietet Zugriff auf das MutableEndpointInformation Interface den MutableClientContext Wird für die Erzeugung eines Default-ClientContexts benötigt und das Setzen an dem aktuellen Thread public final class MutableContextProvider { public static MutableEndpointInformation getEndpointContext(); public static MutableClientContext getClientContext(); public static void setClientContext(MutableClientContext ctx); public static MutableClientContext newClientContext(); }

24 ClientContext JBFClientDescriptor und die Zugriffe darauf über SystemProperties.getJBFClientDescriptor() / setJBFClientDescriptor() sind noch verfügbar aber deprecated Für die Erzeugung eigener Sessions (z.B. in Cronlets) existiert die Hilfsklasse SessionUtils. Diese nimmt dem Entwickler die Arbeit mit dem ClientContext etc. ab. Weitere Informationen finden sich in der ClientContext Dokumentation zu Pallas

25 Agenda Versionierung von neuen JBF-Versionen
JBF Pallas - die wichtigsten Features im Überblick JBF Client Context Erweiterte Steuerung von Application Services XBF Content-Integrator

26 Erweiterte Steuerung von Application Services
Aufruf eines Service vom Client aus Service Request erstellen Environment erzeugen ClientContext erzeugen TCP/IP – http Verbindung aufbauen Daten serialisieren/komprimieren und ggf. verschlüsseln Daten versenden Service Response empfangen, dekomprimieren / deserialisieren Service Response auswerten Nächsten Service vorbereiten usw.  Sind hier Einsparungen / Performanceverbesserungen möglich?

27 Erweiterte Steuerung von Application Services
Für voneinander unabhängige Services besteht nun die Möglichkeit, diese gesammelt zu senden ( Sub-Services) und im JASS parallel ausführen zu lassen. JASS besitzt ab Pallas hierfür einen Pool an Threads, in denen die Sub-Services (im korrekten Bank-Kontext) ausgeführt werden. Service Responses bzw. Exceptions werden von JASS gesammelt und sobald alle Sub- Services eines Aufrufs abgearbeitet wurden, en bloc an den Client zurückgesandt Performance Verbesserungen Der ClientContext wird nur einmal erstellt Es wird nur einmal eine TCP/IP – http Verbindung aufgebaut Es wird nur einmal serialisiert / komprimiert Es wird nur einmal dekomprimiert / deserialisiert

28 Erweiterte Steuerung von Application Services
Erweiterungen: Neue Module bootstrap/scheduledservices am Server und servicecontainer/scheduledservices am Client&Server Konfiguration am Server Jbf.xml: executor.threads.number maximale Anzahl an Threads im Pool Die Erweiterte Steuerung von Application Services wird z.B. im Versicherungsprojekt verwendet, um die Gesamtausführungszeit eines zusammengesetzten Serviceaufrufs zu optimieren Dokumentation: „Erweiterte Steuerung Application Services“ / Pallas

29 Erweiterte Steuerung von Application Services / JASS Ablauf
3 JBF / Bootstrap ExecutorThread run() Executor putTask() enqueue(Task) 4 2 ClassLoaderUtilities getClassLoaderForBank(RZBK) Pro Sub-Service/Task 8 return Task Response/Exception 5 loadClass() newInstance() ExecutorServiceCaller execute(Task) ServiceEnvelopeService Service-Call lokaler 7 Für alle Sub-Services: Task erzeugen Sub-Service {Projekt-Code} execute(ServiceCommandEnv.) 6 1 9 JBF / ClassLoader Kontext Request Response Client

30 Erweiterte Steuerung von Application Services / Beispielcode
// Erzeuge neuen Helper ServiceEnvelopeHelper helper = ServiceEnvelopeHelper.createServiceEnvelopeHelper(); // Füge einen neuen Service mit der ID MyID1 hinzu MyServiceRequest1 request1 = (MyServiceRequest1)helper.addService("MyID1","de.basisagree.my.service.api.MyService1"); request1.setProperty("irgendwas"); request1.setFlag(true); ... // Füge einen neuen Service mit der ID MyID2 hinzu MyServiceRequest2 request2 = (MyServiceRequest2)helper.addService("MyID2","de.basisagree.my.service.api.MyService2"); request2.setName("a name"); request2.setArgument(18); // Führe den ServiceEnvelope mitsamt seinen Sub-Services aus helper.executeSynchronous(); if(helper.isSuccessful()) { // alles OK // Response des ersten Service auswerten MyServiceResponse1 response1 = (MyServiceResponse1)helper.getResponse("MyID1"); …… // Response des zweiten Service auswerten MyServiceResponse2 response2 = (MyServiceResponse2)helper.getResponse("MyID2"); ….. } else { // Reagiere auf die Exception des 1.Service, falls vorhanden Exception ex = helper.getException("MyID1"); …

31 Agenda Versionierung von neuen JBF-Versionen
JBF Pallas - die wichtigsten Features im Überblick JBF Client Context Erweiterte Steuerung von Application Services XBF Content-Integrator

32 Content-Integrator (CI): Was ist das?
Der Content-Integrator (CI) ermöglicht das Einfügen von HTML-Fremdinhalten in eigene Webseiten (Container-Seiten) Diese Inhalte können statische HTML- Seiten aber auch komplexe Webanwendungen sein Die Funktionalität der integrierten Fremdanwendungen bleibt im Rahmen der Container-Seite erhalten Der Content-Integrator steht als eigene Web-Anwendung zur Verfügung und benötigt als Laufzeitumgebung Java 6 sowie einen Servlet-Container der Version 2.3

33 Content-Integrator (CI): Beispiel
Webcenter (wC): Integration der eBanking-Modellrechner in Banken-Homepages Integrierte Inhalte voll funktionsfähig: Links Formulare CSS …

34 Content-Integrator (CI): Funktionsweise
Webbrowser / Kunde Request Response Part 1 Part 2 Fremdinhalte Eigene Anwendung Provider „Part 1“ Part 1 xbf_ci_containerURL Part 2 Container-Seite Provider „Part 2“ Provider „Containerseite“ CI-Anwendung <html> … <xbf-ci:part url=„part1URL“/> … <xbf-ci:part url=„part2URL“/> … … </html>

35 Content-Integrator (CI): Download
Basisklassen seit XBF 2.06 Bestandteil von XBF: Modul „webutil“  Handbuch im JIVE ( unter: Informationsbereich - Produkte und Services (Produkthomepage) – XBF - … - Distribution - xbf-doc-….zip – webutil.pdf Auslieferung des CI als eigenständige (auf XBF basierende) Webanwendung: Web-Application-Archiv „xbf-ci.war“  Download unter: SEU-Portal > Build-Übergabe-Release > Download > Non Build > Echt-signiert > xbf-ci

36 Zusammenfassung JBF Pallas enthält viele neue und nützliche Features
Der neue ClientContext schafft wichtige Voraussetzungen für Horizon, bringt wichtige Properties mit, ist flexibel und erweiterbar Die erweiterte Steuerung von Application Services bringt erhebliche Performance- und Ressourcenvorteile Mit dem XBF Content-Integrator steht erstmals zentral eine Möglichkeit bereit, HTML- Fremdinhalte und Funktionalität in eigene Webseiten zu integrieren

37 Fragen? – Diskussion? Oliver Fischer Roman Koutny Ralf Eichinger
Anwendungsentwicklung Technische Architektur 089 / Roman Koutny 089 / 9943 – 33 57 Ralf Eichinger 089 / 9943 – 33 10

38 Ihr IT-Partner Vielen Dank