Architektur/Design Patterns eines ERP/CRM Systems

[Sir Rufo]

Zitat von mjustin:

Zitat von vagtler:

Wo war denn die Rede von Java?

Indirekt schon im ersten Beitrag:

Zitat:

- Für das Zeitmess-System werden alle Sensoren über TCP direkt im LAN oder über ein Internet-Proxy (über ein UMTS/LTE-Modem) an einem Node.JS Server angebunden

Das 'js' in 'Node.js' steht für 'JavaScript' (... ja, ich weiss: "Javascript" <> "Java")

Er sprach auch nicht von Java sondern Javaumfeld und da gehört JavaScript nun mal rein.

[mjustin]

Zitat von Namenloser:

Gibt es einen bestimmten Grund für Node.JS, außer dass es gerade hip ist?

Node.JS ist besonders geeignet für Anwendungen die eine grosse Zahl gleichzeitiger Verbindungen ressourcenschonend erlauben. Natürlich kann man auch andere Server einsetzen - man braucht dann aber eventuell eine signifikant größere Serverfarm, wenn gleichzeitig zehntausende Benutzer Webseiten besuchen, die mit Ajax oder Websocket arbeiten.

Aber es muss nicht Node.JS sein. Java Application Server unterstützen seit einiger Zeit auch Websocket und asynchrone Requestverarbeitung (Servlet 3.0 API) mit deutlich geringerem Resourcenverbrauch.

Vergleichstests einiger Serverframeworks: http://www.techempower.com/benchmarks/

[Dejan Vu]

Nee nee, das ist für mich nun mal eine Soße, weil ich mich in dem Feld nicht bewege. So wie eben Javaskriptentwickler den Unterschied zwischen C-ohne-kreuze und C-mit-Kreuzen nicht kennen. Es soll sogar Leute geben, für die ist C++ = C#, denn wenn man zwei Plus-Zeichen leicht versetzt übereinander packt, sieht das ja aus wie ein #

[vagtler]

Zitat von Dejan Vu:

Nee nee, das ist für mich nun mal eine Soße, weil ich mich in dem Feld nicht bewege. [...]

Java aufs Webumfeld zu reduzieren halte ich für sehr gewagt. Selbst JavaScript ist nicht mehr ausschließlich dort zuhause.

Zitat:

[...]*So wie eben Javaskriptentwickler den Unterschied zwischen C-ohne-kreuze und C-mit-Kreuzen nicht kennen. [...]

Das ist eine sehr gewagte Verallgemeinerung.

Schubladendenken?

[Dejan Vu]

Zitat von vagtler:

Das ist eine sehr gewagte Verallgemeinerung.
Schubladendenken?

Erfahrung gewürzt mit Polemik. Leg mal nicht immer jede Bemerkung auf die Goldwaage. So ernst ist das Leben ja nicht.

[mquadrat]

Zitat von datasportdev:

Mein Vorschlag:
- Eine Social-Plattform, welche nach dem MVVM Pattern aufgebaut ist, ein HTML5/JS UI hat, das über Websocket mit einem event-driven async Applikation-Backend Server verbindet.
- In der Social-Plattform soll auch ein eingeschränktes E-Commerce System vorhanden sein.
- Für das CRM auch eine MVVM Applikation mit HTML/JS im UI und RESTful Verbindungen zu einem "CRUD"-Backend-Server (aufgebrochen in einem Service-Layer, einem Business-Logic-Layer, einem Data-Access-Layer und einer DB)
- Für das Zeitmess-System werden alle Sensoren über TCP direkt im LAN oder über ein Internet-Proxy (über ein UMTS/LTE-Modem) an einem Node.JS Server angebunden, welches die async verarbeitet und auch über ein HTML/JS UI diese Daten bearbeitet werden können.
- Die verschiedene Systeme kommunizieren über eine Message-Queue untereinander und tauschen somit Daten async aus

Möchtest du mit dem Websocket das Long-Polling umgehen? Für meinen Geschmack sind es - wenn es schon als Gesamtanwendung konzipiert ist - zu viele unterschiedliche Vorgehensweisen und Technologien.

Bei der Zeitmessung: Von wievielen Sensoren reden wir hier denn? Hier würde sich ja auch ein ganz klassischer eigener TCP-Server mit persistenten Verbindungen anbieten. Spart den Verbindungsaufbau und du merkst auf der Server-Seite sofort, wenn dir der Port zugeht weil ein Besucher übers Kabel gefallen ist

[mjustin]

Zitat von mquadrat:

Hier würde sich ja auch ein ganz klassischer eigener TCP-Server mit persistenten Verbindungen anbieten.

Persistente Verbindungen führt dann aber zu höherem Resourcenverbrauch auf dem Server, wenn man "klassisch" mit einem Thread je Verbindung arbeitet. Mit Indy zum Beispiel wird es nicht leicht, wenn zehntausende Clients gleichzeitig versorgt werden wollen, selbst wenn diese nur "gelegentlich" Daten senden.

Die Verbindungen ad-hoc (wenn es etwas zu senden gbt) neu aufzubauen und danach sofort wieder zu trennen ist auch keine Lösung. Der Server hat dann nach einiger Zeit keine verfügbaren TCP Ports mehr (getrennte Verbindungen stehen für einige Zeit noch auf TIME_WAIT).

Vor die Wahl gestellt, sind dann persistente Verbindungen kombiniert mit einem asynchron arbeitenden Server und Workerthreads resourcenschonender (auch für Delphi gibt es asynchron arbeitende TCP Server, es muss nicht Node.JS sein).