Java Klassen in XPages + Agenten gleichzeitig verwenden

[pram]

Hallo,

hab schon wieder eine Verständnisfrage:

Ist es möglich eine Java-Klasse in einer XPage UND in einem (peroidisch laufenden*) Notes-Agenten gleichzeitig zu verwenden?

Angenommen ich habe eine Java-Klasse, welche Businesslogic implementiert und z.B. aus einem Eingabestring einen Ausgabestring berechnet (z.B. eine Verschlüsselung: String enc = EncryptClass.encrypt("plain")  )

Wenn ich einen Java-Notes-Agenten erstelle und versuche mittels "import my.package.EncryptClass" die Klasse zu importieren meckert er immer, dass der Import nicht aufgelöst werden kann. (Ist mir irgendwie auch klar, da XPages ganz anders "ticken" als Notes-Java Agenten)

Ich möchte den Code aber ungern 2x in der DB haben (Notes / XPages Seite). Es ist mir klar, dass der gemeinsam genutze Code keine JSF-spezifischen Sachen machen darf.



* oder gibt es bei XPages einen anderen Mechanismus, dass man periodisch auszuführende Aktionen startet?

Gruß
Roland

[koehlerbv]

Hallo Roland,

zu Deiner Frage (insofern ich hier hinreichend aussagekräftig bin): Das wird wirklich nicht gehen, da beide Modelle ganz andere Wege gehen.

Meine Gegenfrage:
Was verstehst Du unter "business logic"?  Was hat das mit "aus einem Eingabestring wird ein Ausgabestring berechnet" zu tun?

Bernhard

[flaite]

Hallo Roland,

entsprechende Klasse, die keine Abhängigkeiten zu Agenten- oder XPages spezifischen Klassen haben, kannst Du natürlich in Agenten UND in XPages nutzen. Eine Klasse, die Encryption Dienste leistet, ist dafür ein möglicher Kandidat. Ist halt beides Java. Auf einer konzeptionellen Ebene rein eine Frage der Abhängigkeiten der Klasse.

Vielleicht kannst Du den Agenten in eine Java   Skript-Bibliothek einbinden (nicht zu verwechseln mit JavaScript Skript Bibliothek). Weiss allerdings auch nicht, ob XPages darauf zugreifen können. Im Agenten kannst Du sowas jedenfalls einbinden.
Wie hast Du die Klasse in XPages eingebunden? In Notes Agenten hat sogar jeder Agent seinen eigenen ClassLoading Bereich. Nicht überraschend also, dass der Agent eine Klasse nicht findet, die Du irgendwie in eine XPage eingebunden hast. Wie hast Du das gemacht? Ich selbst hab mich bisher nicht mit XPages beschäftigt. Nur mit JSF 1.1 bis 2.0, JavaScript, Css, Dojo und Domino. Meine XPages Ignoranz wird langsam schon ein bischen skuril, wobei ich z.Zt. dazu einfach keine Zeit habe.  

In meinen Augen ist das nicht business Logik. Ich würds der Service Schicht zurechnen. Gibt natürlich eine gewisse Neigung, alles als Business Logik zu bezeichen, das nicht Persistence oder Presentation ist.  

liebe Grüße

Axel

[pram]

Hallo Bernhard, hallo Axel,

das mit der Encryption-Klasse sollte nur ein Beispiel sein. Im Endstadium sollte die Business-Logic ein IWrapper-Objekt annehmen, was entweder ein Xpages-DominoDocument oder ein "echtes" Notesdokument enthalten kann.
Die Logik soll dann eben bestimmte Berechnungen (=Felder setzen) durchführen.
(Mir ist klar dass ich das auch mit "computeWithForm" und/oder einen WebQuerySave-Agenten für XPages erreichen könnte, ich möchte mich aber lieber in die Events des Xpages-Dokuments einklinken, weil ich die ersten beiden Lösungen irgenwie als "aufgepfropft" empfinde.)

Die Java-Klasse hab ich im XPages-Bereich unter Code/Data in der Java-Perspective eingebunden (und erscheint im 8.5.3er Designer auch im neuen Bereich "Java" in der Designer-Perspective) und sie wird über eine managed-Bean & SSJS von der Xpage aus angesprochen. (das hab ich inzwischen auch hinbekommen dass es funktioniert  )
Vielleicht muss ich aber wirklich nochmal den umgekehrten Weg gehen, und die Businesslogic als Java ScriptLib abspeichern.

Das nimmt mir aber wieder die Hoffnung:
http://www-10.lotus.com/ldd/ddwiki.nsf/dx/reuse_java_xpage.htm
soweit ich das verstehe, habe ich den Code dann doppelt in der NSF, was ich, wenn möglich, vermeiden möchte, da der Codestand sehr wahrscheinlich auseinanderlaufen wird (Mal schnell einen Fehler in der Java-Klasse gefixed und vergessen das JAR upzudaten...)
Muss mir das am Montag mal genauer ansehen.

Irgendwie befürchte ich aber dass es (noch) nicht anders geht und ich mir ggf. ein paar Agenten schreiben muss, welche mir diese Arbeit abnehmen

Gruß
Roland

[flaite]

Roland,

Wie Hani Suleiman letztens zum Anlaß seiner Kündigung bei google postete

First of all, engineering is king here, so if you have any kind of good idea, you can expect it to be shot down because we all know engineers are all universally stupid and have no appreciation whatsoever for the genius of their fellow engineers. I mean, I once had an idea for a shit stirring machine that people would defecate into that would then combine all their turds together and automatically post pictures of it online, but I just couldn’t get it past the red tape.

http://www.bileblog.org/2011/07/worship-me-for-i-am-a-xoogler/

any kind of good idea, you can expect it to be shot down 

In diesem Sinne und in völliger Unkenntnis, welche konkreten Gründe Du eventuell hast, dein System so zu entwickeln, wie Du es hier schilderst.

Bist Du sicher, dass es wirklich Sinn macht, eine gemeinsame Schnittstelle von Domino Objekten für XPages und Notes Agenten zu bauen
Wie oft wirst Du diese mühsam zusammengebauten und vermutlich ständig zu erweiternden Adapter wirklich nutzen. Und macht es nicht die Entwicklung komplexer? Und ist es nicht deutlich einfacher, die Notes Objekte mit Server Side JavaScript anzusprechen anstatt über den Umweg eines JSF Managed Bean, das btw. immer auch starke Auswirkungen auf den Speicherbedarf der Anwendung hat, sobald Du es in den session-scope hängst?

Die beiden Versionen konstant zu halten, ist sicher organisatorisch möglich. Tu sie in Subversion oder Verwandtes, setze entsprechend tags, bau branches wo nötig, etc. So kannst Du relativ leicht die Übersicht behalten, welcher Stand wo gerade deployed ist.
Toll wäre natürlich eine Testsuite mit Integrationstests und Junit-Tests (mit Weg-Mocking von Domino-Spezifika), die Du bei Bedarf als Test des neuen Codes gegen beide Umgebungen XPages und Domino Agent losfeuern kannst.

liebe Grüße

Axel    

[pram]

Also ich möcht schon irgendwie eine gemeinsame Schnittstelle für XPages + Agenten weil ich periodische Aktionen ausführen muss, aber du hast recht, dass die Schnittstelle ggf. nicht zu komplex werden sollte.

Ich möchte halt Code nicht doppelt schreiben (dass der Code evtl doppelt in der DB sein muss, damit XPages + Agenten zugreifen können, damit könnte ich mich abfinden)

In jedem Fall sollten Berechnungen sowohl in der XPage als auch periodisch am Server durchgeführt werden können. (z.B. periodische Imports/Datenaufbereitungen)
Und genau um das "periodisch" geht es mir. Falls es einen Weg gibt in einer der 1000 JSF-Config Files eine periodische Aktion zu verankern, wär mir das 1000x lieber als dass ich einen herkömmlichen Notes-Agent verwende.
(Einer meiner Gedanken war, dass ein Notes-Agent periodisch einen XSP-Webservice konsumiert...  aber da muss ich wieder Authentifizierungsinfos hinterlegen etc. )
Also mir gehts primär um die periodischen Aktionen, sekundär dass ich die XPages-Java-Klassen in Notes verwenden kann.

Gruß
Roland

[flaite]

Gibts in JSF einfach nicht. Das Zeugs ist ja als Frontend für EJB oder Java-Web Anwendungen gedacht. Und die haben beide ihre eigenen Schedulingen Mechanismen (Quartz, Quartz in Spring oder in EJB).
Ansonsten würd ich mir keine Sorgen drüber machen, eine JAR doppelt zu deployen. Halte sie möglich kohäsiv auf die gemeinsamen Aufgaben. Versionierung sollte kein Problem sein, zumal man wirklich mit Subversion, Git oder (schlechter) verwandtes arbeiten sollte. Falls Du sowas nicht nutzt, Subversion ist echt sehr einfach aufzusetzen. Ich habs inzwischen auch lokal laufen und da commite wirklich nur ich rein.
Design/Architektur immer so einfach wie möglich halten und nicht wegen eingebildeter zukünftiger Probleme einen Elefanten bauen!
Hab vor 2 Wochen 3rd party lucene Zeugs eingebunden, in der man 2x dasselbe war deployen mußte, jeweils mit anderer web.xml für indexer und suche. So ungewöhnlich ist das nicht.

Gruß Axel