Technologie-Entscheidung JNI/Corba/Sockets/HTTP-Requests etc.

[sudsaat]

Hallo Community,

erstmal ein großes Lob an euch, das Forum ist klasse und bisher habe ich alles finden können, jetzt stehe ich allerdings ein wenig auf dem Schlauch und mache doch einen eigenen Thread auf :-)

Jetzt zu meinen Fragen, zum Verständnis werde ich ein wenig aushole :-) sorry..

Problem:
Wir setzen für ein Kundenprojekt bisher auf ODBC um Daten aus einem Schnittstellenprogramm (oder besser direkt aus der DB der Schnittstelle) zu beziehen. Das Produkt ist von Domino 6 - 8 im Einsatz. Da wir jetzt bei 2 Kunden immense Abstürze bedingt durch den ODBC haben und auch IBM direkt (Indien und USA) keine Lösung für uns haben (auch die alternativen ODBC-Treiber von IBM erzeugen die gleichen Abstürze) stehen wir vor der Entscheidung die Kommunikation mit der Schnittstelle grundlegend zu überarbeiten.


Angestrebtes Ziel (vereinfacht):
1. Aus dem Schnittstellenprogramm (Java) aktiv mit Notes-Dokumenten operieren.
konkreter Anwendungsfall: Import von Dokumenten aus Fremdsystemen (nicht Notes) in die Schnittstelle und direktes Anlegen von Notes-Dokumenten aus der Schnittstelle heraus)

2. Aus dem Notes-Clients aktiv Daten an die Schnittstelle senden und das Ergebnis in Notes verarbeiten.
konkretes Anwendungsfall: Benutzer drückt Button in Notes "Dokument aktualisieren" und sendet einen eindeutigen Schlüssel an die Schnittstelle und erhält entweder einen Fehler oder die neuen Feldwerte aus der Schnittstelle.


Zusammengefasst benötigen wir eine Möglichkeit, mittels Java mit Notes-Datenbanken zu interagieren und andererseits eine Möglichkeit, von Notes aktiv Daten an/von der Schnittstelle zu übermitteln/empfangen.


Für das erste Ziel steht im Raum, entweder über CORBA (remote) oder über JNI (local) zu kommunizieren. Ich habe für beide Arten ein paar Testklassen entwickelt um die Machbarkeit zu prüfen und die Performance zu testen. Beide Arten genügen unseren Anforderungen.
Kann mir jemand mit Erfahrungen mit beiden Arten eine Gegenüberstellung unter folgenden Aspekten liefern?
- Pro und Contra aus Erfahrungssicht
- Zuverlässigkeit (Gefahr von Serverabstürze, Memory-Leaks, etc.)
- Abhängigkeiten (z.B. http und diiop bei Corba)
- bekannte Probleme/Grenzen der Zugriffsarten


Für das zweite Ziel haben wir entweder eine standard-socket oder eine http-kommunikation ins Auge gefasst. Folgendes Szenario ist aktuell mein Favorit:
- Schnittstellenprogramm wird über einen Servlet-Container (tomcat) zur Verfügung gestellt.
- Notes-Client frägt über http-requests (WinInet.dll über LotusScript) an
- Schnittstellenprogramm liefert eine XML Datei mit Inhalt oder Fehler aus
- LotusScript SAXParser behandelt das XML

Hat jemand von euch bereits Entwicklungen ähnlicher Art (socket oder requests) gemacht und kann seine Erfahrungen weitergeben?

Ich freue mich auf euer Feedback.

Grüße Thomas :-)

[flaite]

zu1: Im Zweifel ist lokal immer besser. Ist performanter und v.a. stabiler.

zu 2: programmiers in Java und nimm apache jakarta httpClient. Sehr stabil, viele Beispiele im Netz, kommt mit allen Authentifizierungsarten und mit reverse proxies zurecht. Mein ich sehr ernst.
Insbesondere gibts in Java eine Menge sinnvoller alternativer xml Bibliotheken, die wesentlich zeiteffizienter zu programmieren sind als SAX. JDom oder v.a. auch StAX. Oder JAXB, wenn du magst. Ist aber oft overkill.

Wenn du einfach nur auf eine Relationale Datenbank zugreifen willst, nimm JDBC. Sinnvolle Architektur und steht für praktisch alle Relationalen Datenbanken stabil zur Verfügung.

 

 

[m3]

Lokal hat man halt mehr Support-Aufwand, ev. seltsame Konfigs, die zu Problemen führen, die ganze Deployament-Thematik, ....

[sudsaat]

Hallo zusammen,

vielen Dank für die Antworten.

Zu 1: Wenn ich die Doku richtig verstehe, muss für lokalen Zugriff der NotesClient auf dem PC der das Interface hostet installiert sein? Bei remote genügt es, die benötigten jars ins Projekt (oder den Classpath) aufzunehmen und im Path die entsprechende .id des Benutzers.

Ist das so korrekt?

@m3: Was meinst du mit deployment-Problematik? Kannst Du kurz ein wenig ausholen?

Zu 2: Java wäre auch die erste Wahl meinerseits, allerdings habe ich meines Wissens via Java keinen Zugriff auf die UI-Klassen von Notes, diese benötige ich aber zwingend? Oder gibt es da ebenfalls .jars die ich einbinden kann?

JDBC ist raus, wir möchten im neuen Konzept nicht mehr direkt mit der DB sondern über Schnittstellen kommunizieren, das spart ne Menge doppelten Code der Geschäftslogik und die Schnittstelle kann schnell für alternative Systeme portiert werden.

Grüße Thomas :-)

[flaite]

Ich hab 2 oder 3 Projekte erlebt, in denen von corba auf lokal geändert wurde. Kein einziges in die umgekehrte Richtung. Ich hab immer lokal genommen.
mit Corba mir berichtetete Probleme aus produktiv genutzten Anwendungen
- Stabilität (memory leak zumindest in älteren Notes Versionen)
- sehr langsam

Zu 1) ja.
zu 2) Du kannst etwa mit LS2J arbeiten. Da kannst du aus LotusScript Code eine Java Klasse aufrufen.
Den UI code schreibst du in den LotusScript code und den Java code in die Anwendung für die die Facade Klasse über LS2J aufgerufen wird. LS2J benutz ich allerdings auf dem Server (zeitgesteuerte Agents, etc.) auch nicht wg. Memory Leak Problematiken. Für code, der im Client läuft, ist das prima.
Eine weiter Möglichkeit besteht darin, den Java Code in einen Agenten zu packen, der über agent.runOnServer aufgerufen wird. Da hast du dann wieder einen LotusScript Teil und einen Java Teil.

JDBC ist raus, wir möchten im neuen Konzept nicht mehr direkt mit der DB sondern über Schnittstellen kommunizieren

Versteh ich nicht. JDBC ist zwar recht low level, aber eben auch sehr gut. EJB3, Hibernate, Spring-JDBC verwenden ALLE JDBC. Das hat einen GRUND. UND BTW IST JDBC EINE STANDARDISIERTE SCHNITTSTELLE an der eine Menge schlauer Leute gearbeitet haben... für die in praktisch jedem RDBMS & einigen anderen Systeme eine Implementierung bereitstellt. In JDBC kommunizierst du nicht "direkt mit der Datenbank".
 
Ich hab eine Menge Integrationen zwischen Domino und meist SAP aber auch anderem geschrieben, der über den Austausch von xml Dokumenten läuft. Ich weiss wie das geht, hab fertige Projekte auf die ich aufbauen kann. Ich würde es aber den Geldgebern eines Projekts nie zumuten das zu benutzen, um JDBC zu ersetzen.
Du kannst ja alternativ code schreiben mit gemeinsamen Interface für JDBC und XML-Austausch.

[sudsaat]

Hallo Pitiyankee,

danke für dein Feedback, dann fällt die Wahl bzgl. Zugriffsmethoden von der externen Java-Schnittstelle nach Notes auf "lokal" mit der kleinen Unschönheit des installierten NotesClient.

Zu 1 - Danke, dann habe ich das richtig verstanden.

Zu 2 - Die Methode aus LotusScript eine Java-Klasse zu rufen ist mir bekannt, darüber habe ich die Barcode4J-Portierung zu Notes entwickelt. Dazu habe ich einen Viewer in LotusScript und einen Generator in Java, der über den Viewer angestoßen wird, geschrieben.
Allerdings ist der Austausch von Informationen von Java-Agenten nach LotusScript-Agenten ein ganz schönes Gefummel (oder gibt es da einen einfachen Weg, den ich bisher nicht kenne)?


Zu JDBC - da habe ich mich ein wenig falsch ausgedrückt:
JDBC ist raus, da wir aus Notes nicht direkt mit der Datenbank sondern über unser Schnittstellenprogramm kommunizieren möchten. Hintergrund: Das Schnittstellen-Programm ist ein Komponentenbasiertes Java-Projekt nach MVC²-Paradigma entwickelt, das über den Servlet-Container (Tomcat) gehostet wird und die http-requests empfängt und XML zurück liefert.

Der direkten Zugriff von Notes auf die Datenbank via JDBC würde die Business-Logik (Controller) des Schnittstellenprogramms bewusst umgehen - was in unserem Falle fatal ist und ein Nachprogrammieren der Business-Logik in Notes erfordern würde

Daher ist JDBC in diesem Kontext raus. Ansonsten natürlich beide Daumen hoch für JDBC!


Aber zurück zu 2: Gibt es eine Möglichkeit, aus Java-Agenten direkt mit LotusScript Agenten zu kommunizieren? Ich habe bisher nur den Weg in die andere Richtung gesehen (LotusScript übergibt Informationen an Java-Agenten) oder halt den Umweg über NotesDokumente.

Ich freue mich auf Feedback.

Grüße Thomas :-)

[flaite]

Du kannst aus Java-Agenten keine Daten unmittelbar an Lotus Script Agenten senden und auch keine von Ihnen empfangen.
Fällt mir grad ein: Neben den von dir genannten Möglichkeiten könnte man ja aus Java Notes Agenten zumindest auf dem Server per HTTP aufrufen. Da liessen sich Parameter übergeben. GET und POST Parameter lassen sich in LotusScript auslesen.
Ist aber fraglich, ob sich das lohnt. Wär eine nette Idee für ein openNTF Projekt.

[sudsaat]

Hallo Pitiyankee,

danke für dein Feedback - ich werde noch ein wenig testen.

Nach bisherigem Wissensstand wede ich die Kommunikation von Notes heraus über http-requests und XML-Rückgaben realisieren - diese werden über Struts mittels xslt result-type über die javax.xml.parsers.DocumentBuilderFactory erzeugt.

Schade das es keine Möglichkeit gibt um Daten direkt auszutauschen, würde das Leben immens vereinfachen :-)

Ich gebe Bescheid, sobald die Wahl der Architektur steht, falls jemand noch gute Vorschläge hat: Her damit! Bin über jede Meinung/Erfahrung dankbar.

Grüße Thomas :-)