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

klassischer Artikel für Domino/Websphere Integration von B. Balaban

(1/2) > >>

Axel_Janssen:
Hi,

schon ein wenig älter, aber Bob Balaban ist wirklich ein sorgfältiger Autor.
Grundsätzlich hat sich nicht viel geändert.
Natürlich würde ich in der Praxis niemals von einem Servlet auf Domino-Backend Klassen zugreifen. Dafür ist schließlich der Business Layer da  ;)
Grundsätzlich anders ist das dann aber auch nicht.
Vieles erinnert an die Diskussionen hier in den letzten Tagen.

Erinnert mich an gestern.

--- Zitat ---Actually, the fact that you have to do this init/term sequence on all threads turns out to affect the entire coding pattern for using Domino objects. The reason for this is that you can't cache any Domino objects across the init/term boundary. As a result, you have to re-acquire a Session and all other object instances each time your servlet or EJB entry point is called. This requirement (which I hope IBM will fix in a future release of WebSphere Application Server) might severely limit the scalability of your application.

--- Ende Zitat ---

Ketzerische Frage: Hat Bob das 2-Domino-Threads pattern, das wir gestern hier erarbeitet haben gesehen?
Theoretisch kann man nämlich sehr wohl Domino-Objekte in Servlet Instanzvariablen speichern (wenn man nämlich einfach in Servlet.init() kein stermTread() macht und das in Servlet.destroy() verlagert . Servlet init() wird einmal beim allerersten Aufruf des Servlets durchlaufen und Servelt.destroy genau einmal beim runterfahren.
Da die doGet() und doPost() Methoden des Servlets nur lesend auf die (Domino-)Instanzvariablen zugreifen ist das auch Thread-Safe.  :-X

hab den Artikel-Link vergessen: http://www.advisor.com/article/balab03

Glombi:
Hallo Axel,
kannst Du das mit dem
"Natürlich würde ich in der Praxis niemals von einem Servlet auf Domino-Backend Klassen zugreifen. Dafür ist schließlich der Business Layer da "
näher erläutern? Wie sähe das in der Praxis aus?

Aber nur wenn's nicht zuviel Mühe macht (und ich kein Projekt auf's Auge gedrückt bekomme  ;D  )

Andreas

Axel_Janssen:
Das vermutlichste OO-design-Prinzip ist wohl separation of concern. Jede Klasse/Komponente einer Anwendung soll sich auf einen speziellen Aufgabenbereich konzentrieren (hohe Kohäsion).

In J2EE Anwendungen hat man die 3 klassischen Schichten: Präsentation, Business-Logik (komisches Wort: das was die Anwendung eigentlich macht (auch komisch)) und Persistenz.
Zugriff auf Lotus gehört eigentlich in den Persistenz-Layer (Datenbank). Deshalb hat es im Servlet (Präsentation) nichts zu suchen.
Servlets haben dabei im Präsentations-Layer nur eine Teilfunktion (entgegennahme von User-Requests, aber das nur am Rande und bei bestimmten Web-Frameworks stimmt das so nicht).

In einer normal designten Anwendung würde das Servlet die User-Eingaben entgegennehmen und diese Ergebnisse dann irgendwelchen Business-Objekte weiterleiten, die dann Persistenz-Objekten sagen, was sie wie in LoNo abspeichern sollen. Die Business-Methoden würden dann Ergebnisse an JSPs weitergeben, die die Ergebnisse dem User präsentieren.

Ein solches Separation-of-concerns Konzept ist nicht irgendein akademischer Schwachsinn, sondern bringt wirkliche Vorteile:
- bessere Übersichtlichkeit (Veränderung, Erweiterung, Fehlersuche leichter).
- Testbarkeit von Einzelmodulen.

In meinen Swing-Applets sind z.B. alle Notes-Zugriffe in einer Klasse NotesConnection. Falls irgendwas mit der LoNo Kommunikation aus dem Applet nicht läuft, weiß ich immer wo ich suchen muß.
Außerdem kann ich diese Klasse leicht testen und debuggen, ohne extra das Applet anschmeissen zu müssen.
Ein weiterer Vorteil ist, daß ich so leichter LotusNotes durch ein anderes Persistenz-Systeml wie RDBMS oder xml ersetzen kann.  (Persistenz ist dauerhaftes Abspeichern von Daten in ein Medium. Ein Programm erzeugt ja auch dauernd Daten, jedoch sind die futsch, wenn das Programm stoppt.)

... Martin Fowler hat mal sinngemäß gesagt: :
debuggen in nicht OO-Systemen besteht zeitmäßig 95% aus Fehlersuche und 5% aus Fehlerbehebung. OO ist auch dazu da, um diese 95% zu verringern.

Ralf_M_Petter:
Hallo Axel!

Sei vorsichtig mit den was du da über die Servlets sagst, ich habe es probiert, und du kommst mit dem recyceln in Teufelsküche wenn du es so machst.  Ein einfaches Beispiel. Wir haben ein Servlet, dass im Hintergrund egal jetzt ob direkt oder über  einen Business Layer  auf ein und das selbe Notesdokument zugreift. Sprich nach jedem Webzugriff wird das Dokument recycelt. Session und Database bleiben bestehen. Das funktioniert super solange du ein Servlet mit nur einem Thread hast. Aber sobald die Last am Server steigt werden vom Application Server mehr Threads für das Servlet generiert. Thread1 holt das Dokument z.B aus einer View. Thread2 macht kurz darauf das selbe und bekommt exakt das selbe Objekt. Thread1 ist fertig und recycelt das Objekt. Thread 2 crasht dann wenn er auf das Objekt zugreifen will, da es ja bereits recycelt ist. Ausserdem ist  der Performancegewinn im wirklichen Leben nicht so schlimm. Wenn du Zeit hast teste mal unsere Webseite www.artweger.at Sie ist komplett mit JSP aufgebaut, die sämtliche Daten aus einer Domino Datenbank zieht. Das heisst es gibt kein Bild und keinen Text, der nicht im Hintergrund von Domino kommt. Ausnahme manche Daten werden direkt aus dem ERP System besorgt. Wenn ich lokal auf die Seiten zugreife, habe ich Seitenaufbauzeiten von unter 1 Sekunde.  Bei Zugriffen über das Netz ist die Zeit die für das Erstellen der Session und der Database benötigt wird minimal im Vergleich wie lange das Übertragen der Bilder dauert.

Grüße

Ralf

Axel_Janssen:
Hallo Ralf,

d.h. du erzeugst bei jedem Servlet-Zugriff ein neues (Notes-)Session und ein neues (Notes-)Database-Objekt (sowie neue View Objekte, Collections, Docs, etc)?

D.h. das bei Servlets Domino-Objekt-Caching über mehrere Zugriffe nicht möglich ist? Warum auch immer.
Ist es dann vielleicht nicht doch sinnvoller evtl. drüber nachzudenken, ob die Corba-Klassen nicht doch der sinnvollere Weg sind? Da ist das nämlich möglich. Müßte man sich natürlich in der realen Umgebung messen und ich habe auch grundsätzlich Performance-mässige Bedenken bzgl. aller Remote-Frameworks (EJB, WebServices, CORBA).

Gruß Axel

Navigation

[0] Themen-Index

[#] Nächste Seite