Architekturfrage zur Weiterentwicklung einer Lösung

[Cogito]

Hallo zusammen,

ich habe eine Anwendung entwickelt, die auf der Basis von selbst erstellbarer Report-Templates recht hochwertige Reports in verschiedenste Formate konvertiert und auch mehrsprachig ausgeben kann. Das ganze ist bisher eine reine Client-Server Lösung, wobei die gesamte Konvertierungs- und Drucklogik im Client lag. Dieser Ansatz war für den Anfang ganz praktikabel, erweist sich aber bei steigenden Ansprüchen hinsichtlich Skalierbarkeit und auch Leistungsfähigkeit (hier besonders die Anzahl der erzeugten Reports) als nicht ausreichend. Meine Frage ist, wie könnte man eine solche Lösung von der Architektur und /oder Design besser gestalten (ist eine Delphi-Entwicklung)?
Ich hatte mir schon mal überlegt, die ganzen Druckroutinen in einen Windows Service auf einen Server auszulagern, das Problem scheint mir aber hier zu sein, das ich zur Erzeugung eines Reports relativ viele Komponenten brauche (z.B. sämtliche Zugriffe auf die Datenbank und falls ein Chart verwendet wird die TChart-Komponente usw.). Auch weiß ich nicht wie man dann mit diesem Service auf einem Rechner kommunizieren kann um ihm mitzuteilen wann er was zu erzeugen hat. Andererseits wäre aber auf diese Art das Erstellen der ganzen Drucktemplates von dem Erzeugungsprozess auf dem Server vollkommen getrennt und sollte jemand keinen Server benötigen könnte der Service auch auf der gleichen Maschine wie die GUI laufen. Eine andere Idee war alles von der Architektur zu belassen, aber die einzelnen Druckjobs in jeweils eigene Threads auszulagern.
Hat hier jemand schon mal was vergleichbares entwickelt und kann mir Tipps und Anregungen geben?

[hoika]

Hallo,

Zitat:

Dieser Ansatz war für den Anfang ganz praktikabel, erweist sich aber bei steigenden Ansprüchen hinsichtlich Skalierbarkeit und auch Leistungsfähigkeit (hier besonders die Anzahl der erzeugten Reports) als nicht ausreichend.

Mit dem Auslagern der Arbeit von 10 Clients (Bsp.) auf einen Server
wird es sich hinsichtlich der Skalierbarkeit aber eher zum Schlechteren wenden
(1 Rechner macht das, was bis jetzt 10 machen).

Threads sind eine gute Idde,
gerade weil heutzutage jeder mindestens einen Dual-Core hat.

Ich würde aber auch erst mal versuchen, herauszubekommen,
wo der Flaschenhals ist (Profiler).


Heiko

[mjustin]

Zitat von Cogito:

Hat hier jemand schon mal was vergleichbares entwickelt und kann mir Tipps und Anregungen geben?

Vorteil eines eigenen Printservers: alle Reports können zentral administriert werden. Wenn man mehrere Anwendungen hat, die den gleichen Report drucken können sollen, wird es damit einfacher, neue Layouts zu installieren - es gibt nur eine Stelle, an der das Layout hinterlegt werden muss.

Nachteil eines Printerservers der als Service läuft: wenn man eine neue Version installieren will, muss man den Service stoppen - in dieser Zeit kann keiner den Service ansprechen. Es gibt natürlich jede Menge Lösungsmöglichkeiten, ich will da aber die Kreativität nicht einschränken

Vorteile: der Printserver entlastet die Clients. Man kann kostengünstige Thin Clients verwenden, da die dicke Rechenlast ausgelagert ist. Auch auf einem Terminalserver ist die Last aller Clients insgesamt niedriger. Der Printserver kann mit entsprechend stärkerer Hardware aufgesetzt werden, und bei entsprechendem Design kann bei Bedarf ein zweiter dazugeschaltet werden.

Die Parameterübergabe kann im einfachsten Fall per INI-ähnlicher Datei erfolgen. Rückgabe als PDF - die Weiterverarbeitung (zum Beispiel Druckvorschau, Versand als Mail oder Fax) sollte dann aber wieder innerhalb der aufrufenden Anwendung erfolgen, wenn man maximale Kontrolle dort benötigt.

Viele Grüße,