Lotus Notes / Domino Sonstiges > Java und .NET mit Notes/Domino

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

(1/2) > >>

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.


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

--- Ende Zitat ---
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.

Navigation

[0] Themen-Index

[#] Nächste Seite