# Architektur-Problem? 2 Servlets, ein Objekt



## Sekundentakt (29. Dez 2010)

Hallo Gemeinde,

bisher sieht meine Architektur so aus:

In der init-Methode eines Servlets wird meine Applikation gestartet.


```
Application app = new Application();
```
Das ist alles.

Ich möchte jetzt aber, dass die Applikation außerhalb des Servlets lebt, weil ich über verschiedene Servlets die Applikation ansprechen möchte.

Ein Servlet ist für Reads zuständig, das nächste für Updates, ein anderer für das Erzeugen neuer Einträge etc.
Ich könnte das alles auch in einem Servlet unterbringen, möchte diese Logiken aber voneinander trennen.

Was mich auch schon immer gestört hat, war, das die Applikation erst dann startet, wenn tatsächlich auch jemand eine Anfrage an das Servlet sendet (könnte ich umgehen, in dem ich die Application im Servlet-Konstruktor initialisiere).

Meine Vorstellung von der Architektur des Ganzen sah auch immer wie eine Pyramide aus:

Die Spitze ist die Schnittstelle nach Außen hin (View). In diesem View wird die Applikation initialisiert.
Der View bereitet dann die Daten so auf, dass die Applikation sie verarbeiten kann. Der Rest der Business-Logik findet in der App statt. 
Die App gab dann einen Response in Form eines Strings zurück, den der View dann ausgeben konnte bzw. weiterverarbeiten kann.

Zielsetzung war, dass die App in einer Desktopumgebung, aber auch in einem Webservice sinnvoll einsetzbar ist.

Das Problem an diesem pyramidenhaften Aufbau ist nun, dass ich nicht nur einen View haben will, sondern den View aufsplitten will (einen für Updates, einen für Reads etc.).

Mir fehlt jetzt ein Lösungsansatz oder Stichwort unter dem ich mich mal informieren kann, wie ich ein und das selbe Objekt mit mehreren Servlets parallel ansprechen kann.

Btw.: Ich denke das "View" das falsche Wort ist, weil der "View" in meinem Modell auch Aufgaben des Controllers übernimmt. Ich hoffe das schadet dem Verständnis aber nicht.

Danke!

Beste Grüße

EDIT:
Folgende Idee kam mir gerade: 
Ich könnte ja ein Servlet erzeugen, dass die Applikation initialisiert. 
Das Servlet beantwortet jedoch keine HTTP-Requests.
Stattdessen wird es über den ServletContext von anderen Servlets (z.b. dem Update-Servlet) aufgerufen und man holt sich dann über die Methode getApp() die App-Instanz.

Was haltet ihr davon?


----------



## maki (29. Dez 2010)

Deine WebApp startet wenn sie deployed wird, oder der Server gestartet wird,, nicht erst beim 1. Request. Servlets "starten" spätestens bveim 1. request, kommt auch auf die Konfig in der web.xml an.

Ansonsten hört sich das alles sehr umständlich/wirr an, denke du hast dich mit den Grundlagen noch nicht ausreichend auseinandergesetzt, sonst würdest du einfach den ServletContext nehmen und da per setAttibute dein Objekt setzen 

Dann bist du aber immer noch ziemlich an Servlets gekoppelt, nix mit DesktopApp.
Solltest dich frage ob du das wirklich willst, ist nämlich recht komplex und aufwändig, Eclipse RAP macht das von Haus aus, oder du machst dir selber was, IoC hilft dabei, zB. Spring.


----------



## Sekundentakt (29. Dez 2010)

Hi Maki,

danke für Deinen Beitrag!

Die App wird zurzeit in der init()-Methode des Servlets gestartet. Und die wird erst dann aufgerufen, wenn ein Request reinkommt, vorher nicht. Das geht zumindest aus meinen Beobachtungen hervor.

Die App selbst kapselt auch die gesamte Business-Logic.
Was sie nicht kapselt und auch nicht kapseln soll, ist, wie auf die App zugegriffen wird (Webservice oder Desktop-Interface).

Im Moment orientiere ich mich sehr an Servlets, weil der Usecase Webservice heißt.
Das Design ist aber modular genug, um die Business-Logic auch in eine Desktop-App zu implementieren.

Dein Stichwort mit setAttribute erscheint mir sinnvoller, als mein Vorschlag den ich im EDIT geäußert habe.

Ich würde jetzt in jedem Servlet erfragen, ob das Objekt bereits im Context existiert, oder nicht.
Wenn nicht, wird es erzeugt, ansonsten wird es einfach via .getAttribute() zurückgegeben.

Gibt es Garantien bezüglich der Sichtbarkeit der im ServletContext abgelegten Objekte?

Ich denke hier an eine Race-Condition: Update- und Read-Servlet erhalten zeitgleich eine Anfrage und wollen beide an das App-Object, stellen fest es ist nicht da, und erstellen sie.
Damit nur ein Servlet von beiden die App-Instanz erstellt, müsste ich ein Flag im Context setzen. 

Hälst Du das für sinnvoll?


----------



## maki (29. Dez 2010)

> Die App wird zurzeit in der init()-Methode des Servlets gestartet. Und die wird erst dann aufgerufen, wenn ein Request reinkommt, vorher nicht. Das geht zumindest aus meinen Beobachtungen hervor.


Wenn du "die App" sagst meinst du also nicht die WebApp die man meint wenn man von Servlets spricht sondern etwas eigenes und für mich unbekanntes 
Anstatt WebApp könnte man auch "Context" sagen.

Dein Einwand mit den Raceconditions ist richtig, aber diese können immer WebApp Bereich auftreten.
Da währe wohl ein ServletContextListener angebracht: : Interface ServletContextListener
Damit sollte klar sein wer & wo "die App" erzeugt.

Garantien, Konventioenen etc. entnimmst du am besten der Spec


----------



## Sekundentakt (29. Dez 2010)

Okay, hier treten ein paar Missverständnisse auf 

Ich habe eine komplexe Applikation geschrieben, die ich so instantiieren kann:


```
MyApplication app = new MyApplication("config.xml");
```

Das kann ich im Konstruktor eines Servlets oder sonstwo machen.

Wenn ich "App" sage, meine ich MyApplication.

Die MyApplication ist EIN Bestandteil der WebApp, das ist mir klar 

Ich schaue mir mal besagtes Interface an und studiere mal die Specs.
Eventuell klären sich da einige Fragen.

Danke Dir!


----------

