Untergeordnete Seiten
  • Hinweise zur Migration auf jadice server 5.4
Zum Ende der Metadaten springen
Zum Anfang der Metadaten


Neue Features und Funktionen

Verbesserungen in der JMS-Übertragung

Bisher wurde pro Job, den eine Clientanwendung an jadice server geschickt hat, eine clientseitige Temp-Queue geöffnet, über die jobbezogen die Verarbeitungsergebnisse, Statusinformationen und Loginformationen übertragen wurden. Nach dem Ende eines Jobs wurde diese Temp-Queue gelöscht.

Um dem JMS-Message-Broker die Aufgabe abzunehmen, ständig kurzlebige Temp-Queues anzulegen und zu löschen, wurde der Lebenszyklus von Temp-Queues geändert: Statt nur für einen einzigen Job zuständig zu sein, können ab jadice server 5.4 beliebig viele Jobs, die vom selben Client aus geschickt werden, über diese Temp-Queue abgearbeitet werden.

Änderungen im Lebenszykus

Für den Lebenszyklus der Temp-Queue ist nun die Klasse JMSJobFactory verantwortlich. Er wird über die neu eingeführten Methoden connect() und close() gesteuert. Eigene Integrationen sind dahingehend anzupassen, dass die JMSJobFactory vor der ersten Verwendung mittels connect() initalisiert werden muss. Wenn keine weiteren Jobs mehr darüber an jadice server abgegeben werden sollen, ist die Methode close() aufzurufen. Dadurch werden alle verwendeten JMS-Ressourcen freigeben. Da die Klasse JMSJobFactory das Interface AutoCloseable implementiert, kann dies auch über das "try-with-resources"-Statement geschehen.

Aus Symmetriegründen implementiert die Klasse Job ab jadice server 5.4 ebenfalls AutoCloseable. Instanzen hiervon müssen nun ebenso nach Ende der Verarbeitung durch Aufruf der close()-Methode freigeben werden. Auch hier kann das "try-with-resources"-Statement eingesetzt werden.

Änderungen am Exception-Handling

Im Zuge der Verbesserungen in der JMS-Übertragung wurde das Exception-Handling überarbeitet. Dabei entfiel die JobCreationException und es wurde die ConnectionException neu geschaffen, die von der JobException erbt. Sie signalisiert, dass ein Problem mit der verwendeten JMS-Infrastruktur vorliegt. Zu erwarten ist diese Exception, wenn die JobFactory mit der connect()-Methode eine initiale Verbindung zum JMS-Broker aufnehmen möchte oder – falls die Verbindung zu einem späteren Zeitpunkt abbricht – beim Aufruf der Methode Job::submit().

Die Methode JMSJobFactory::createJob() folgt nun der Deklaration des Interfaces JobFactory  und kann nun eine JobException werfen.

Gegebenenfalls müssen Sie Ihr Exception-Handling auf dieses neue Verhalten anpassen.

Geänderte Semantik des failover-Protokolls (Apache ActiveMQ)

Wird Apache ActiveMQ als JMS-Broker verwendet, konnte das failover-Protokoll dazu verwendet werden, um eine Art Round-Robin-Lastverteilung auf mehrere jadice server-Instanzen zu implementieren. Da die JMS-Verbindung ab jadice server 5.4 "sticky" ist, wird das failover nun rein für den vorgesehenen Zweck genutzt, um die Ausfallsicherheit sicherzustellen. Um eine Lastverteilung zu erreichen, wird zukünftig empfohlen, die jadice server-Instanzen, die ein gemeinsames Konvertierungscluster bilden, über ein Network-of-Brokers zusammen zu schalten oder ggf. einen zentralen Message-Broker zu nutzen, den alle jadice server-Instanzen gemeinsam nutzen.

Authentisierung am JMS-Broker

Wie bereits oben beschrieben wird die Verbindung an den JMS-Broker bereits mit Aufruf der Methode JMSJobFactory::connect() aufgebaut. Benötigt diese Verbindung eine Authentisierung, so müssen die dazu notwendigen Credentials ab jadice server 5.4 zuvor über die neu eingeführte Methode JMSJobFactory::setCredentials(Credentials) übergeben werden. Die Methoden Job::setCredentials(Credentials) bzw. setJmsCredentials(Credentials) entfallen hingegen.

Einzig für die Verwendung der Sicherheits-Schnittstelle bleibt die Methode setServerCredentials(Credentials) in der Klasse Job weiterhin bestehen.

Entkopplung von Komponenten

Webservice-Schnittstelle

Die Klasse JobInvocationServiceImpl, die den Endpunkt der Webservice-Schnittstelle bereitstellt, war bisher direkt von der Verwendung von JMS abhängig und für die Verwaltung des Lebenszyklus einer JMSJobFactory verantwortlich. Ab jadice server 5.4 ist diese Abhängigkeit aufgelöst und es wird nur eine Instanz des Interfaces JobFactory in diese Klasse injiziert. Dies führt zur Änderungen in Konfigurationsdatei server-config/application/webservices.xml. Neu ist dort die Deklaration einer JMSJobFactory und der Verwaltung ihres Lebenszyklus über die Mittel des Spring Frameworks.

Falls Sie eigene Anpassungen an dieser Konfigurationsdatei vorgenommen haben, sind diese hierauf anzupassen.

Email-Agent

Ebenso wie die Webservice-Schnittstelle war der Email-Agent bisher direkt an JMS gekoppelt. Mit jadice server 5.4 wurde diese Kopplung aufgehoben. Folgende Änderungen ergeben sich dadurch:

  • In die Konfigurationsdatei server-config/emailagent/config.xml wird eine JMSJobFactory deklariert und deren Lebenszyklus verwaltet.
  • In alle groovy-Skripte, die jadice server standardmäßig unter server-config/emailagent/ beiliegen, wird diese Instanz als Skript-Parameter jobFactory injiziert.
  • Alle groovy-Skripte, die von der Klasse AgentRulebaseSupport erben, übergeben diese Instanz statt wie bisher einer QueueConnectionFactory als dritten Parameter in der Methode init(MessageTransaction, Logger, JobFactory).

Eigene Anpassungen der genannten Konfigurationsdatei sowie eigene groovy-Skripte zur Verarbeitung von E-Mails sind wie beschrieben anzupassen.

Sonstige API-Änderungen

  • Die Klassen Node und Job implementieren nicht mehr java.io.Serializable. Sollten Sie eigene Node-Klassen implementieren, so benötigen Sie das Feld serialVersionUID nicht mehr. Dies wird Ihnen üblicherweise durch eine Compiler-Warnung angezeigt.
  • Der Schreibfehler im Methodennamen NodeWorker::addOuputBundle(StreamBundle) wurde behoben. Ihr Name lautet nun korrekt addOutputBundle(StreamBundle).
  • Die Response der Webservice-Schnittstelle enthält im Element return das neue Attribut jobID. Um diese Information nutzen zu können, müssen bestehende Webservice-Stubs anhand der neuen WSDL generiert werden.