[Dresden-pm] Re: Ein Programm, viele Schnittstellen

[Jens Puruckherr]

dresden-pm at mail.pm.org writes:
>
>Muß es unbedingt *ein* Script sein?

Ne, muss es nicht.
>
>Ich würde vermutlich 4 Scripte machen und eine gemeinsame Bibliothek,
>die allen zugrunde liegt. Oder OO-technisch alle von einer Klasse
>ableiten. Ggf. noch bissel Locking, um sie vor konkurrierendem
>Zugriff auf gemeinsame Resourcen zu schützen. 
>
>Du kannst natürlich auch forken oder Threads nehmen, aber am
>Ende tut's auch ein einfache gemeinsames Startscript. Keep it
>simple. Vielleicht gibt's auch Gründe für Threads, aber da müßtest Du
>evtl. konkreter werden.

Mein Gedanke war die einfachere Verwaltung des ganzen. So muss ich
dann halt 4 + x Anwendungen starten und kontrollieren.
OK, den Start kann ja ein Wrapper machen. Argument > /dev/null
Ausserdem ist möglicherweise die Kommunikation zwischen den versch.
Scripts etwas komplizierter. Mit eigenen Childs habe ich mich schon
mal unterhalten. 
Konkret erwarte ich künftig (zusätzlich) bis 3000 Requests / Stunde.
Die kommen entweder per XML und FTP (schlecht) oder per SOAP (besser)
oder noch was leichgewichtigeres (was ist denn das optimale für 3
Parameter/Request (wenig Overhead)
Die Bearbeitung sei mal  dahingestellt, aber alle müssen sauber
erfasst, gespoolt und geloggt werden. Nebenbei kommen noch die
jetzigen "dicken" Anfragen. Das Script muss alles sauber validieren
und ablegen, so dass der Arbeiter dahinter sich auf ordentliche Daten
verlassen kann.
Naja, muss wohl noch etwas denken ....
>
>
>Unabhängige Programme haben den Vorteil, daß ein Problem in einem
>nicht die anderen ausfallen läßt.

Stimmt auch wieder, dann geht eben nur die Hälfte nicht ....
Wie wird sowas eigentlich bei professionelleren Anwendungen
gehandhabt? (ftp-client, http-server, SOAP-Client, SOAP-Server ...
all in one?)

>
>
   Mit freundlichen Grüßen

Jens Puruckherr