3. Komplette Facility Management Software in HTML oder C++ ?

Komplette Facility Management Software in HTML oder C++ ?

  • M

    Ein passives Frontend für alle Eingabe/Ausgaben mit HTML? Klar. Wenn dann noch AJAX&Co dazukommen, eine Supersache (für partiellen Refresh von Zuständen im Bild, etc). Habe sowas ähnliches vor 2 Wochen im Betrieb gesehen, sehr elegant, vor allem einfach zu verteilen, und sehr schnell.

    Aber auf dem Backend hast Du natürlich nach wie vor eine Hochsprache sitzen, irgendjemand muß ja die Business Logik ausführen. D.h. also irgendwas a la Webserver mit C++-CGIs, PHP, ASP.NET, J2EE...

    [Bißchen JavaScript auf dem Client wäre zusätzlich zum HTML auch nicht dumm.]

    Ist also schon ein Mix aus verschiedenen Tools.

    0
  • B

    Aloha,

    vielen Dank für die Antworten.

    Java Applets und PHP sehe ich nicht so als potentielle Konkurrenz für die C++ - Geschichte mit RDP.

    PHP ist eher mit den Anforderungen an eine moderne GUI und in puncto Geschwindigkeit eher überfordert.

    Java Applets bedeutet, sofern ich mich an meine Webseiten - Erstellen Zeiten dunkel erinnere, dass alles komplett auf den Client übertragen werden muß. Dann der Zugriff auf eine zentrale Datenbank wieder übers Internet vollzogen wird. Zudem wird Java auch noch interpretiert. Ich denke auch um einiges langsamer. Allerdings schon bessere Guis möglich.

    Dann ist da noch ASP.NET 2.0. Klingt schon irgendwie mehr nach Konkurrenz, wenn ich so google...

    Hier zieht nur noch die Geschwindigkeitsschiene. Da glaube ich, dass eine Anwendung hinter einer RDP - Verbindung mit nem schnellen Server effizienter ist, als ASP.NET in Verbindung mit C# oder VB.Net.

    Es müssen imho auch deutlich weniger Daten transferiert werden, sowohl beim Request, als auch beim Empfang der Daten auf dem Browser.

    Liege ich damit falsch ?

    Grüße

    BOA

    0
  • B

    Marc++us schrieb:

    Ein passives Frontend für alle Eingabe/Ausgaben mit HTML? Klar. Wenn dann noch AJAX&Co dazukommen, eine Supersache (für partiellen Refresh von Zuständen im Bild, etc). Habe sowas ähnliches vor 2 Wochen im Betrieb gesehen, sehr elegant, vor allem einfach zu verteilen, und sehr schnell.

    Aber auf dem Backend hast Du natürlich nach wie vor eine Hochsprache sitzen, irgendjemand muß ja die Business Logik ausführen. D.h. also irgendwas a la Webserver mit C++-CGIs, PHP, ASP.NET, J2EE...

    [Bißchen JavaScript auf dem Client wäre zusätzlich zum HTML auch nicht dumm.]

    Ist also schon ein Mix aus verschiedenen Tools.

    Ich hatte meine Antwort noch offen, bevor ich sie gesendet habe, deswegen geht sie nicht auf Deine Antwort ein.

    Genau da sehe ich auch ein kleineres Problem. Dieser Mix aus den verschiedenen Tools, wie Du das so schön nennst.

    Verschiedene Tools, verschiedene Schnittstellen, potentielle Problematiken.

    So ne C++ Anwendung vereint einfach alles in einem.

    Zudem besteht die Anforderung, dass Prüfgeräte an die serielle Schnittstelle ( oder moderner meinetwegen auch USB ) angeschlossen werden, und ein Abgleich zwischen der Software und den Prüfgeräten erfolgen muß.
    Da habe ich ja gar keine Idee, wie man eine serielle Schnittestelle vom Browser aus abfragen kann. Das geht wahrscheinlich eh nur wieder über ein separates Programm, dass dann wieder in C++ geschrieben werden muß.

    Grüße

    BOA

    0
  • M

    Ich sehe Deine Punkte überhaupt nicht, bzw sehe ich einige Defizite bei Dir in Kenntnis vom Systemdesign/Webserver/Tools.

    Dieses "C++ vereint alles in einem" ist doch auch nicht wahr - oder mußt Du für den RDP nicht auch ein Protokoll bzw Schnittstellen festlegen? Natürlich mußt Du das!

    Daher ist ein Toolmix eine sehr gute Lösung, wenn die Toolgrenzen auch mit den Grenzen der Schnittstellen übereinstimmen. Vorteile: getrennte Testbarkeit, schönes Design ohne Überschneidung, und Optimierung des jeweiligen Tools auf das Aufgabengebiet.

    D.h. mit HTML modelliert man ja nur die Ausgabe, da steckt keine Businesslogik dahinter, auch keine serielle Schnittstellenabfrage. HTML ist ein Transportformat der grafischen Darstellung, und kann von jeder Serverlogik erzeugt werden (wieso ich z.B. Deinen Einwand mit PHP nicht sehe, wieso sollte PHP Schwächen in der Darstellung haben, PHP erzeugt ja HTML). HTML erzeugst Du mit ASP.NET, mit J2EE, mit PHP, oder einem C++-CGI.

    Im Backend läuft dann der Server, der sich um solche Sachen wie serielle Schnittstellen kümmert - aber das wirst Du ja wohl nicht in einen Monoblock hämmern, der sowohl Darstellung als auch Kommunikation gleichzeitig macht? Die Abfrage der seriellen Schnittstelle realisiert man zweckmäßig mit C++, und verpasst diesem Modul eine Schnittstelle wie mit einem COM-Server, oder von mir aus noch eine DLL, oder CORBA. Und das wiederum bindest Du in Deinem Serverbackend ein, wo dann nur noch der Datenlieferant angesprochen wird - daß die Daten von der seriellen Schnittstelle kommen sieht man nicht mehr. Diese Integration gelingt dann schön in ASP.NET, J2EE oder direkt in einem C++-CGI. Diese erzeugen dann mit Schablonen die Viewing-Daten in HTML, und senden diese an den Client.

    Der Client fordert nur Daten an, und erhält erneut die Ausgaben in HTML. Und wenn's eleganter werden soll, kommunizieren Client und Server via AJAX.

    Natürlich ist das ein Toolmix, aber das kommt eigentlich bei jedem komplexeren System raus.

    0
  • B

    Aloha Marcus,

    das hat mir sehr geholfen. Hast Du sehr anschaulich erläutert, vielen Dank.

    Vorab hast Du völlig Recht, dass ich im Bereich des HTML/Webserver/ASP.NET etc. nicht die vielseitigen Möglichkeiten kenne, aber deswegen starte ich ja auch diesen Thread 😕 ?!?!

    Ich glaube Du hast einen wichtigen Aufbau nicht richtig verstanden. Bei einer Terminal Server Session läuft nur das Bild von meiner Session über die RDP Verbindung, also wozu sollte das Programm zum RDP eine Schnittstelle erzeugen ? Alles andere wird in die TS Session gemapped vom Client :
    serielle Schnittstelle(n), Druckerspooler, etc....😕 😕

    Nun aber zu der ASP.NET/Web - Variante.
    Das klingt ja alles spannend, was Du schreibst, nur dass bedeutet, wie ich es schon schreibe, dass Du ein Extra Tool, neben dem IE, auf dem Client benötigst, der die Daten von der seriellen Schnittstelle absammelt und verschickt. In C++ kann ich auf dem Terminal Server EIN Programm laufen lassen, und Ausgabe, Eingabe, Programmlogik und serielle Schnittstellenabfrage zusammenfassen ( eventuell alles auch in einen Monoblock, wenn es platz spart 😉 )

    Was die daraus resultierende Wartbarkeit angeht, kann ich auch nicht nachvollziehen, wie Du darauf kommst das viele Tools eine bessere Wartbarkeit ergeben ?!?!
    Habe ich 10 verschiedene Versicherungen von einer Gesellschaft, sind die auch besser aufeinander abgestimmt und die Verwaltung ist einfacher für mich, als wenn ich für jede Versicherung eine Gesellschaft hätte.

    Aber auf einen Punkt gehst Du gar nicht ein, und der interessiert mich am meisten.
    Was denkst Du ist performanter ? Dieser Toolmix mit den ganzen Schnittstellen, den Du beschreibst ( Ein-Ausgabe HTML, Programmlogik C#, Schnittstelle in C++ etc. ) oder eine RDP Verbindung mit einer exe auf dem Terminal Server ?
    Bei gleichen Hardware Voraussetzungen natürlich.

    Beste Grüße

    BOA

    0
  • M

    Performance:

    Die Webserverlösung wird weniger performant sein, ganz klar. Man muß allerdings auch die Frage nach der Perfomanceanforderung stellen - was wird durch den Webserver verlangsamt? Die Bilddarstellung. Das Backend läuft davon unabhängig. Und was ist die Anforderung der Bilddarstellung, nun, einige Bildschirmteile müssen maximal 10mal pro Sekunde aufgefrischt werden. Ich würde das Thema also nicht als Primärziel betrachten.

    Deployment:

    Unschlagbarer Vorteil von Webserverlösungen ist das einfache Deployment auf diversen Plattformen. Man muß ja nicht immer nur über die klassische Schiene Windows und Linux nachdenken, sondern auch an mobile Geräte denken: man kann die Oberfläche auch auf einem MDA oder einem Smartphone ansehen. Ideal für einen Servicetechniker, der mit UMTS und MDA auf dem Gelände oder im Gebäude unterwegs ist - das ist ja oftmals ebenfalls Teil des Facility Managements. Außerdem ist das Protokoll (HTML über http) routbar! Ein großer Vorteil, da man hier problemlose Freischaltungen über Firewalls oder VPNs vornehmen kann, das wird mit RDP bißchen kniffliger.

    Wartbarkeit:

    Im Umfeld von Facility Management ist in der Entwicklung und im Betrieb die Stabilität ein Primärziel. Wen interessiert denn bei diesen Systemen Speicherplatz auf dem Server, oder die Performance, solange man alle Systeme bedienen kann? Aber wenn es Probleme mit dem FM-System gibt, muß man schnell den Fehler finden. Dies wird vereinfacht durch eine gute Modularisierung, durch klare Systemgrenzen. "Scharfe" Komponenten lassen sich durch Simulationen austauschen, z.B. kann man den Com-Server für die serielle Schnittstelle durch einen blinden Simulator austauschen, und damit das Gesamtsystem testen. Dafür ist für jedes Modul das ideale Tool ausgewählt, das diesen Einsatzbereich am besten abdecken kann - wodurch weniger Fehler entstehen, und die Wartbarkeit besser wird.

    Ein solches wie von Dir dargestelltes System würde bei mir ungefähr diese Layer haben:

    - Hardwarelayer, Anbindung der Hardware über Schnittstellen (z.B. seriell, oder OPC bei SPSen, etc), für jede Hardware ein eigener COM-Server, implementiert in C++

    - Datalayer, quasi das Prozessabbild der Eingänge und Ausgänge, also eine Baumstruktur, die zu allen Zuständen/Werten den aktuellen Istwert enthält. Wird periodisch refresht, und hat eine Schnittstelle, mit der die Istwerte gelesen werden können. Implementiert in C++ oder C#.

    - Halbautomaten, ein Layer, der einfache Zustandssteuerungen realisiert, zum Beispiel für Meßoperationen, Prüfungen, Initialisierungen, die oberhalb der Hardwareebene zum Beispiel geräteübergreifend Abläufe durchführen. Diese Halbautomaten kommunizieren mit dem Datalayer. Implementierung C++ oder C#.

    - Visuallayer, der aus den Infos im Datalayer die Ausgaben erstellt, und via Webserver das an die Clients schickt. Transportlayer HTML, auf dem Webserver z.B. ASP.NET, würde sich anbieten wenn man in Windows bleibt.

    Wohlgemerkt: alle diese Layer sind auf dem Server stationiert und implementiert.

    Normalerweise kann man auch noch andere Sprachen/Tools wählen für diese Zerlegung, aber ich wollte hier ein konkretes Beispiel nennen.

    Du mußt Dich aber mal von einer falschen Grundvorstellung lösen: mit HTML fragst Du keine seriellen Schnittstellen ab. HTML ist nur ein Transportformat für Daten, das kann von allen möglichen Dingen erzeugt werden.

    Und Deine Vorliebe für Monoblocks... hm... akzeptabel bei einer Hardwareinsel, also ein oder zwei Geräte mit serieller Schnittstelle, und einer daran hängenden Visualisierung. Da lasse ich mir das einleuchten. Aber Du sprichst von Facility - das heißt für mich N Geräte, wobei N bißchen größer werden kann. Da hat ein Monoblock nichts mehr verloren. Was ist Performance schon gegen Wartbarkeit? Wartungskosten und Fehlersuche verschlingen bis zu 50% der Projektgesamtkosten. Selbst eine leistungsstärkere Hardware ist in diesem Umfeld billiger als höhere Entwicklungskosten/Wartungskosten.

    0
  • B

    Aloha Marcus,

    vielen Dank für die ausführliche Antwort.

    Die Frage nach der Performance hat einen bestimmten Hintergrund. Ist-Zustand : nicht performant. Soll-Zustand : Performance, Performance, Performance...
    bei gleichzeitiger Stabilität, of course. 🕶
    Aber ich habe Deine Argumente in mich aufgenommen....

    Bei einer Sache muß ich noch einmal nachhaken, damit wir nicht wirklich aneinander vorbei reden.

    Definier mal Monoblock, bitte.

    Grüße

    BOA

    0
  • M

    Monoblock:

    a) eine große Exe
    b) diverse Com-Server/Clients, die aber so miteinander verknüpft sind, daß man einen nicht ohne den anderen starten kann, weil jeder jeden aufruft

    Bzgl Performance, behalte doch da im Hinterkopf, daß meistens eine schlechte Systemleistung durch einige wenige entscheidende Stellen verursacht wird, die die ganze Leistung verbraten, sei es wegen einer ungeschickten Implementierung, oder wegen ungünstigen Datenstrukturen. Bei der Masse des Codes ist Stabilität doch wichtiger als Performance.

    0
  • B

    Marc++us schrieb:

    Monoblock:

    a) eine große Exe
    b) diverse Com-Server/Clients, die aber so miteinander verknüpft sind, daß man einen nicht ohne den anderen starten kann, weil jeder jeden aufruft

    Bzgl Performance, behalte doch da im Hinterkopf, daß meistens eine schlechte Systemleistung durch einige wenige entscheidende Stellen verursacht wird, die die ganze Leistung verbraten, sei es wegen einer ungeschickten Implementierung, oder wegen ungünstigen Datenstrukturen. Bei der Masse des Codes ist Stabilität doch wichtiger als Performance.

    Es heißt ja auch in der Formel 1 :
    Es ist leichter ein zuverlässiges Auto schneller zu bekommen, als ein schnelles zuverlässig.

    Zitat : Norbert Haug oder irgendein andere Spezi..

    Ich denk dann noch einmal.

    Grüße

    BOA

    0

  • @BOA: Nur weil du hier mal "Schnittstellen in C++" geschrieben hast: IMHO wäre das ein riesen riesen Fehler. Als Schnittstelle würde ich auf jeden Fall etwas einsetzen wo ich ein wenig Flexibilität habe was die Sprache die ich verwende um das zu Implementieren angeht, und was vor allem den Ort angeht wo das laufen soll. Also wohl entweder DCOM oder CORBA. Ggf. noch .NET Remoting. Gegen DCOM spricht natürlich dass man viele viele Ports aufmachen muss, was allerdings wieder kein so grosses Problem ist wenn man VPN Tunnels einsetzen kann, bzw. wenn sowieso alles innerhalb einer Zone läuft.

    Alternativ dazu könnte man sich ganz auf Java festlegen, dann sind eben auch alle Schnittstellen in Java (bis vielleicht auf die Schnittstellen des Hardwarelayer). Das Web Frontend würde dann mittels JSP angebunden.

    0
  • T

    Ich stehe mit meiner Meinung zwar entgegen den geläufigen Meinungen der IT, aber ich möchte dennoch meinen Senf dazu geben.

    Die IT verschlingt heutzutage zu viel Geld. Das liegt daran, daß jede Anwendung auf biegen und brechen mit J2EE, Corba, DCOM, SOAP oder sonstigen verteilten Technologien daher kommt. Die klassische EDV verwendet Monoblocks (wenn wir diese Begriff jetzt schon eingeführt haben). Komischerweise hat das früher auch auf den schalbrünstigen Kisten gereicht. Heutzutage scheint sich die EDV mehr mit sich selbst zu beschäftigen und unnötigen Kommunikations- und Verwaltungaufwand der Komponenten zu haben.

    Das bedeutet nicht, daß meine Software monolitisch ist, aber die Zusammenstellung der Komponenten sollte meiner Ansicht nach beim Entwickler liegen, die sich mit der Applikation auskennen und nicht bei den Administratoren. Das realisiert man durch wiederverwendbare Bibliotheken. So realsiert man Bibliotheken für die verschiedenen Aspekte der Businesslogik und die Applikationen bedienen sich dieser Module. Die Kommunikation der Komponenten untereinander verläuft dann innerhalb des Prozesses und eine häufige Serialisierung und Deserialisierung der Parameter entfällt.

    Man sollte sich gut überlegen, ob diese Technik nicht ausreicht. Die Verwaltung wird viel einfacher und im Zeitalter der Gigaherz-Multicore-Rechner für wenig Geld kann eine einzige leistungsfähige Kiste doch enorme Leistung bringen.

    Ein Technologiemix mit einem halben Duzend Programmiersprachen erzeugt auch höhere Kosten. Daher empfehle ich, die Festlegung auf eine Sprache, die alles leistet.

    Ich empfehle C++, da es alles aus der Maschine raus holen kann, was technisch machbar ist. Es bietet auf der einen Seite die Möglichkeit, Hardwarenahe zugriffe beispielsweise für Sensorzugriffe zu realisieren und auf der anderen Seite leistungefähige Features für die Strukturierung grosser Programme, wie Klassen, Templates, Exceptionhandling, Namespaces usw.

    Webapplikationen erleichtern das Deployment der Applikationen und bieten eine sehr gute Skalierbarkeit. Ajax (oder Ajaj oder Ahah oder was auch immer) sind interessante Technologien, die die Möglichkeiten der Webapplikationen weit verbessern.

    Tntnet

    0
  • M

    Und wie lange brauchst Du, um ein Backend für Ajax unter C++ auf dem Server zu realisieren?

    0
  • T

    Einfach mal auf meine Signatur schauen 😉

    0
  • A

    Marc++us schrieb:

    Und wie lange brauchst Du, um ein Backend für Ajax unter C++ auf dem Server zu realisieren?

    EIgentlich geht das super einfach: Witty!
    http://witty.sf.net/

    Einfach mal die Online-Demos (Examples) ausprobieren und den Code dazu anschauen. Man programmiert so, als wenn man ne normale GUI programmiert. Die Lib sorgt dann dafür, das AJAX bei raus kommt. Die witty-Website selbst ist auch mit Witty programmiert. 👍

    0
  • A

    tntnet schrieb:

    Einfach mal auf meine Signatur schauen 😉

    tntnet kann auch Ajax? Haste aber ne schlechte Werbung. Das tntnet für die Web-Programmierung ist, habe ich gewusst, aber Ajax? Würde ich mich mal ran halten und auf der Website mal besser vermarkten. 😉 Online-Examples wie bei Witty wären auch nicht schlecht, damit man es ausprobieren kann.

    0
  • T

    Artchi schrieb:

    tntnet schrieb:

    Einfach mal auf meine Signatur schauen 😉

    tntnet kann auch Ajax? Haste aber ne schlechte Werbung. Das tntnet für die Web-Programmierung ist, habe ich gewusst, aber Ajax? Würde ich mich mal ran halten und auf der Website mal besser vermarkten. 😉 Online-Examples wie bei Witty wären auch nicht schlecht, damit man es ausprobieren kann.

    Ja Du hast recht. Wäre eine Idee. Danke für den Hinweis.

    Tntnet ist im Gegensatz zu Witty nicht auf Ajax spezialisiert. Witty ist ein Ajax-Framework und da geht die Entwicklung von Ajax-Applikationen natürlich einfacher. Ich hatte den Witty-Leuten schon mal vorgeschlagen, Tntnet als Server zu benutzen, aber denen hat die GPL nicht gepasst. Ich habe vor Tntnet auf LGPL zu lizensieren. Vielleicht kommen wir ja dann zusammen.

    Tntnet kann im prinzip alles, was HTTP ist. Neben herkömmlichen Webseiten natürlich auch Ajax, XML-RPC oder SOAP. Allerdings gibt es dafür noch keine Frameworks. Aber vielleicht wird ja mal was daraus.

    Tntnet

    0
Anmelden zum Antworten