Laden...

Fragen, Diskussion, Kritik zu Projekt ".NET Applikationsserver"

Erstellt von wdb.lizardking vor 16 Jahren Letzter Beitrag vor 9 Jahren 142.222 Views
wdb.lizardking Themenstarter:in
100 Beiträge seit 2006
vor 16 Jahren
Fragen, Diskussion, Kritik zu Projekt ".NET Applikationsserver"

Also ich freue mich auf den bestimmt gut dokumentierten Programmcode, auch wenn mir persönlich eine Umsetzung mit WCF sympathischer gewesen wäre.

Da du Lager- und Artikelverwaltung als Beispiele angibst, wirst du bestimmt auch eine datenbankneutrale Datenhaltung zur Verfügung stellen.
Welche Methodik/Vorgehensweise wirst du dafür benutzen, weil bei dem Thema scheiden sich ja die Geister? 🙂

3.728 Beiträge seit 2005
vor 16 Jahren
Fragen, Diskussion, Kritik zu Projekt ".NET Applikationsserver"

Hallo Community,

dieser Thread wurde für Fragen, Diskussionen und konstruktive Kritik speziell zum Projekt .NET Applikationsserver erstellt.

@lizardking: Ich habe mit WCF nicht wirklich Projekterfahrung. Außerdem ist die Technologie noch ziemlich neu und setzt das .NET Framework 3.0 vorraus. Die Kapselung der kompletten Kommunikation über die API des Applikationsservers macht es aber mit vertretbarem Aufwand möglich, auf WCF zu migrieren. Remoting ist für dieses Beispielprojekt genau das richtige, da es so simpel ist.

Was den Datenzugriff angeht, werde ich folgende Komponente einsetzen: Providerunabhängige Datenzugriffskomponente
Der SQL-Code des Beispiels wird allerdings nicht datenbankneutral angelegt, sondern ist auf SQL Server 2005 zugeschnitten. Natürlich kann man das Projekt später auch einmal hernehmen und damit demonstrieren, was alles zu ändern ist, wenn man verschiedene RDBMS unterstützen will/muss.

1.378 Beiträge seit 2006
vor 16 Jahren

Hallo Rainbird,

ich habe bei meiner Applikation einen ApplikationsServer. Dieser hat bis vor kurzem nur die Aufgabe gehabt Tasks auszuführen die auch in Schedules stecken können die nach Ablauf einer Zeit die Tasks ausführen.
Also ein Scheduler der selbst definierte Tasks ausführen kann.

Nun hatte ich den Auftrag den Server um einen LizenzierungsServer zu erweitern. Das heißt der Server soll irgendwie die sich anmeldenden Clients identifizieren können und anhand von gespeicherten ClientInformationen entscheiden können, ob der Client anmeldeberechtigt ist oder nicht.

Wie stelle ich die verschiedensten Dienste den Clients zur Verfügung?

Im Moment habe ich es folgendermaßen implementiert:

1)Der Server startet
2)Es wird ein RemotingObjekt veröffentlicht, über das sich die Clients zu Server verbinden können.
3)Beim Verbindungsaufbau übergibt der Client dem Server sein ClientObjekt. Wenn dies erfolgreich durchläuft, wird ein Event ausgelöst, das ein Client sich angemeldet hat.
4)In diesem Event wird dem Client der LizenzManager übermittelt
5)Der Client versucht sich am LizenzManager zu registrieren. Dazu ruft er CanRegister, Register und IsRegistered auf
6)Läuft die Registrierung glatt, wird das CLientRegistered Event ausgelöst, indem der Client dann die restlichen Services bekommt(auch den ConnectionString bekommt der Client nach erfolgreicher registrierung). Konnte der Client nicht erfolgreich registriert werden, bekommt er folglich keinen ConnectionString und keine weiteren Services(ScheduleServer).

Die Übergabe dieser Objekt erfolgt Sequentiell. Der Client hat eine SendObject Methode, die einfach für jedes Object aufgerufen wird. Beim Client wird dann mit


if(obj is AType)
{
}  

geprüft welches Object versendet wurde und wird dann weiter bearbeitet.

Dieses Kommunikationsschema habe ich aus meinen ersten Remotingerfahrungen(Chat) wo das Observer Patern eingesetzt wurde.

Es funktioniert zwar doch kann ich mir vorstellen das es nicht gerade optimal ist.

Was hälst du davon?

3.728 Beiträge seit 2005
vor 16 Jahren
Abhängigkeiten

Hallo xxxprod,

Deine Vorgehensweise schafft unnötig Abhängigkeiten zwischen Server und Client. Man sollte es wenn möglich vermeiden, Verweise auf MarshalByRef-Objekte des Clients an den Server zu senden. Da ist der Server dann nicht mehr der Boss und wird plötzlich selbst zum Client.

Du könntest die Lizenzen über die Sitzungen verwalten.

Ich habe die Sitzungsverwaltung bei meinem Applikationsserver so gelöst:

Bevor ein Client einen Dienst auf dem Applikationsserver benutzer kann, muss er sich anmelden.


// Beim Server anmelden
ApplicationServer.Logon("tcp://server:7000/NTierExample/");

Bei der Anmeldung prüft der Server zuerst, ob der Aufrufer eine vertrauenswürdige Identität hat. Wenn der Knabe sauber ist, bekommt er ein Ticket (Session ID) zurück (Dafür eignet sich ein Guid sehr gut, da man den nicht erraten kann). Dieses Ticket legt sich der Client in den Aufrufkontext und kann dann ganz unbeschwert die Dienste des Servers konsumieren. Da das Ticket im Aufrufkontext liegt, wird es bei jedem Methodenaufruf automatisch und "unsichtbar" vom Client zum Server übertragen.

Wenn ein ausgebuffter Benutzer nun veruscht einen Dienst zu konsumieren (Indem er sich viellicht sogar selber ein kleines Programm mit Activator.GetObject schreibt) ohne sich vorher anzumelden, wird er mit Sicherheit kein gültiges Ticket (das auch dem Applikationsserver bekannt ist) im Aufrufkontext stehen haben. Der konsumierte Dienst wird nach einer kurzen Rückfrage an die Applikationsserver-Infrastruktur den Schwindel bemerken und dem Bösen Buben eine SecurityException verpassen.


// Wenn der Aufrufer vertrauenswürdig ist ...
if (ApplicationServer.IsCallerTrustworthy)
{
    ...
}
else
    // Ausnahme werfen
    throw new SecurityException("Du kommsch hier net rein!");

Nun zum Vorschlag für die Lizenzverwaltung:

Die Lizenzprüfung könntest Du beim Anmelden einhängen. Für jede Sitzung wird eine Lizenz verbraten. Wenn ein Aufrufer ein gültiges Ticket im Aufrufkontext mitführt, können sich die Dienste sicher sein, dass die Sitzung korrekt lizenziert ist. Meldet sich ein Benutzer ab, wird die Lizenz zurück in den Pool der freien Lizenzen gelegt (Bzw. der Zähler "Benutzte Lizenzen" um eins verringert).

Bei der Logon-Methode auf dem Server müsste man so nur einen Funktionsaufruf einbauen, der prüft ob noch freie Lizenzen da sind, sich um den Zähler kümmert, und eingehende Anmeldungen abbricht, wenn alle Lizenzen verbraucht sind.
Wichtig wäre noch ein Arbeitsthread auf dem Server, der z.B. alle 5 Minuten nach abgelaufenen Sitzungen sucht, diese entsorgt und ihre Lizenzen freigibt. Damit keine Lizenzen gesperrt bleiben, nur weil sich ein Client nicht richtig abgemeldet hat (z.B. wenn jemand kurz das Netzwerkkabel rauszieht).

1.378 Beiträge seit 2006
vor 16 Jahren

Das klingt ja wiedereinmal höchst interessant.
Vor allem mit dem Aufrufer Context möchte ich mich jetzt ein wenig auseinander setzten, da ich vorher noch nie damit zu tun hatte.

Wenn meine Lizenzierung nun aber so aussieht, das meine Clients an einen Rechner gebunden sind und nur von dort sich am Server anmelden können sollen, welche Möglichkeiten habe ich, um beim Server herausfinden zu können, ob der Client registriert ist?
Wie vorher erwähnt, speichere ich im Moment eine kombination aus domain+computernamen um den Computer zu identifizieren. Dies kann aber denke ich sehr leicht umgangen werden.

Lg XXX

3.728 Beiträge seit 2005
vor 16 Jahren
Remoting erweitern

Dazu müsstest Du die IP-Adresse oder den DNS-Namen des Clients zuverlässig ermitteln können. Leider behütet die Remoting Infrastruktur diese Informationen nur in ihrem Innern. Rankommen könntest Du über eine selbstgeschriebene Kanalsenke. Diese Senke muss dann per App.config in den TCP-Kanal auf dem Server eingebettet werden. Mit so einer Kanal-Senke kannst Du die interne Kommunikation von Remoting direkt beeinflussen und hast auch Zugriff auf Verbindungsdaten, wie z.B. die Client-IP-Adresse. Diese lässt sich per DNS-Lookup dann leicht in einen DNS-Namen auflösen, welchen Du für die Lizenzprüfung hernehmen kannst.
Ich habe allerdings noch nie selber eine solche Senke geschrieben. Hier findest Du aber ein Beispiel wie man das macht: http://microsoft.apress.com/asptodayarchive/73800/creating-a-custom-net-remoting-sink
Hört sich auf jeden Fall nicht schwer an.

Natürlich kannst Du auch den Client einfach seinen DNS-Namen in den Aufrufkontext hängen lassen, aber da besteht das Risiko, dass ein manipulierter Client sich für einen anderen ausgibt.

1.378 Beiträge seit 2006
vor 16 Jahren

Da hab ich ja schon einen vorteil, da jeder Client sich in erster Linie beim Server per TCP-Connection melden muss, damit der wiederum dem Client seine eigene IP-Adresse zurück senden kann(Notwendig für Remoting über VPN). Naja vielleicht könnt ich das nutzen.

Witzig ist nur, dass die einzige Methode in System.Net.Dns die nicht "obsolete" ist(GetHostAddresses), den Namen einer IP die über VPN verbunden ist nicht auflöst währenddessen alle anderen "obsoleten" Methoden das können :S

3.728 Beiträge seit 2005
vor 16 Jahren
Client/Server

Dann hast Du aber wieder das Problem, dass der Server Client der Clients ist. Für so grundlegende Dinge wie die Anwendung, würde ich das unbedingt vermeiden. Für die Clients muss gelten:

"Der Server braucht uns nicht, aber wir brauchen den Server."

P.S.: Warum muss die Lizenz denn ausgerechnet an einem bestimmten Rechner hängen? Ich finde dass solche Lizenzmodelle kontraproduktiv sind und den Kunden in der freien Planung seiner Infrastruktur behindern. Da ich aber nicht weiss, was das für eine Anwendung ist, kann das aber durchaus so nötig sein.

1.378 Beiträge seit 2006
vor 16 Jahren

Vielleicht wird später eh ein anderes Lizenzmodell angewendet. Zur Zeit jedoch meine Chefs diese Variante für am sinnvollsten.

3.728 Beiträge seit 2005
vor 16 Jahren
Download

Die n-Tier Beispiel-Projektmappe steht ab jetzt unter .NET Applikationsserver zum Download bereit.

T
108 Beiträge seit 2005
vor 16 Jahren

Vielen Dank Rainbird!

Ich finde es super klasse, dass Du ein derartiges Beispiel für uns gemacht hast!!

Danke 🙂

Gruß & guten Rutsch

Was einmal war, wird nie wieder sein...

354 Beiträge seit 2004
vor 16 Jahren

angeregt durch
>
, habe ich einen leichtgewichtigen aber vollwertigen Applikationsserver geschrieben.

Ich will dir nicht zu nahe treten, aber vollwertig kann man dein Beispiel nicht nennen. Es ist zwar ein nettes Beispiel für einen Application-Host. Zum Application-Server fehlt aber noch ein wenig. Session-State-Handling, Verteilbarkeit, usw.

Nichts desto trotz: Tolle Arbeit.

.NET GUI - Die Community für grafische Oberflächen unter .NET
Jetzt kostenlos besorgen: .NET BlogBook
Norbert Eder
DasBackup

3.728 Beiträge seit 2005
vor 16 Jahren

Hallo nitronic,

Session-State-Handling ist kein Feature, welches ein Applikationsserver zwingend benötigt. Bei COM+ (Enterprise Services) - und das ist ja auf jeden Fall ein vollwertiger Applikationsserver - gibt es auch kein Session-State-Handling (Bitte um verbesserung, falls es das dort doch in irgendeiner Form geben sollte). Sitzungsstatus wird eigentlich nur von Web-Anwendungen benötigt und ist damit Sache des Webservers. Der Webserver ist bei einer Web-Anwendung für das Front-End zuständig, der Applikationsserver für die Geschäftslogik. Die Geschäftslogik sollte, wegen der Skalierbarkeit, möglichst statuslos implementiert sein. Der Status wird vom Client gehalten. Bei einem Web-Client muss der Webserver eben den Status halten (HTTP ist ja statuslos). Bei einem Windows-Client wird der Status vom jedem Client-Computer selber verwaltet. Deshalb brauchen Web-Clients eine Sitzungsstatus-Verwaltung und Windows-Clients nicht.

Einige Applikationsserver können zwar auch direkt als Webserver eingesetzt werden, deshalb ist Session-State-Handling aber kein erforderliches Feature, damit sich ein Prozess "Applikationsserver" nennen darf.

Was den angesprochenen Punkt "Verteilbarkeit" angeht, hast Du natürlich recht. Mein kleiner Beispiel-Applikationsserver lässt sich momentan nicht ohne Umbauten auf verschiedene Rechner verteilen. Clusterfähig ist er auch nicht. Das Projekt wurde aber auch nicht mit dem Ziel entworfen, den großen Applikationsservern am Markt den Rang abzulaufen (Wobei es da im .NET-Umfeld gar nicht so viel gibt), sondern um einen praxisnahen Einstieg in die Entwicklung von verteilten mehrschichtigen Anwendungen zu geben. Selbst bei 200 Benutzern ist eine Verteiltung der Geschäftsdienste auf mehrere Maschinen in den meisten Fällen nicht nötig (ist pauschal aber nicht zu sagen, da es von der Anwendung abhängig ist). Für den Anfang kommt man selbst mit diesem kleinen Applikationsserverchen recht weit. Durch die Kapselung der Kommunikation durch die API, steht auch nichts im Wege, die Verteilbarkeit nachzurüsten (oder vielleicht auch von Remoting auf WCF zu wechseln). Besonders Session-State-Handling lässt sich mit ein paar Handgriffen einbauen (wenn man es wirklich braucht).

Obwohl ich mein Projekt zunächst mal verteidige, freue ich mich sehr über solche kritischen Meinungen. Das Projekt ist eben erst geboren und muss erst noch reifen und gedeien. Mit Hilfe der Community wird es das hoffentlich auch recht schnell 😉.
Ich möchte auch noch einen Web-Client nachlegen. Da wird sich zeigen, ob eine Sitzungsverwaltung im Applikationsserver sinnvoll ist, oder ob ich das nicht besser auf den IIS abwälze.

1.274 Beiträge seit 2005
vor 16 Jahren

Hallo Rainbird,

lieben Dank für die viele Arbeit die dort reingesteckt hast, ich bin gerade deinen Server ein bisschen anzusehen und mir sind ein paar Dinge aufgefallen.

  1. Warum gibt deine Business-Schicht in der Funktion FindProductsByName() nur ein Datatable zurück, liegt dies am overhead den dein typed Dataset erzeugen würde?

  2. Ein Problem welches noch besteht, wenn eine Client durch einen Aufruf eine Fehler am Server erzeugt, stürzt der komplette Server Prozess ab. Sollte es nicht im Fehlerfall eine Exception an der Client gesendet werden, statt das Sie auf dem Server auftritt.

  3. Ein kleiner Bug in dein MVC Modell, ist mir auch aufgefallen. Wenn man den Client öffnet und den Artikelstamm mehrmals anklickt passiert soweit nichts, nur 1 Fenster mit der suche, aber wenn man nun auf neu klickt öffnet er das Artikel Formular sooft man geklickt hat.

Obwohl zu einem richtigen App-Server noch einige Dinge fehlen, finde ich es ein wirklich gelungenes Konzept. Ich falle zwar jedes mal wieder drüber das die Client Schnittstelle im Namespace Appserver.API liegt, aber das ist nicht weiter tragisch.

Liebe Grüße
LastGentleman

"Das Problem kennen ist wichtiger, als die Lösung zu finden, denn die genaue Darstellung des Problems führt automatisch zur richtigen Lösung." Albert Einstein

354 Beiträge seit 2004
vor 16 Jahren

Session-State-Handling ist kein Feature, welches ein Applikationsserver zwingend benötigt. Bei COM+ (Enterprise Services) - und das ist ja auf jeden Fall ein vollwertiger Applikationsserver - gibt es auch kein Session-State-Handling (Bitte um verbesserung, falls es das dort doch in irgendeiner Form geben sollte). Sitzungsstatus wird eigentlich nur von Web-Anwendungen benötigt und ist damit Sache des Webservers. Der Webserver ist bei einer Web-Anwendung für das Front-End zuständig, der Applikationsserver für die Geschäftslogik. Die Geschäftslogik sollte, wegen der Skalierbarkeit, möglichst statuslos implementiert sein. Der Status wird vom Client gehalten. Bei einem Web-Client muss der Webserver eben den Status halten (HTTP ist ja statuslos). Bei einem Windows-Client wird der Status vom jedem Client-Computer selber verwaltet. Deshalb brauchen Web-Clients eine Sitzungsstatus-Verwaltung und Windows-Clients nicht.

Was COM+ / .NET Enterprise Services anbieten sind grundsätzlich nicht vordergründig, da durchaus schon ein paar Jahre auf dem Rücken. Ich sehe Sessionhandling es definitiv als Feature. Sessionhandling jedoch nicht im herkömmlichen Sinne für Web-Appications gedacht. Schließlich muss auf dem Application Server nicht unbedingt ein Webserver aufsetzen (wobei der Webserver selbst auch für mehr als nur das Front-End zuständig ist).
Es besteht die Möglichkeit, dass es mehrere Applicationserver gibt, um Lasten zu teilen. Jede Anwendung die im Context des Applicationserver läuft, kann nun Statusinformationen halten, die garantieren, dass Requests in der korrekten Reihenfolge ablaufen, dass sonstige Manipulationen nicht stattfinden können. Diese müssen von Applicationserver zu Applicationserver weitergereicht werden, sollte einer ausfallen, wobei wir auch schon beim Thema Ausfallssicherheit und Verteilbarkeit wären.

Einige Applikationsserver können zwar auch direkt als Webserver eingesetzt werden, deshalb ist Session-State-Handling aber kein erforderliches Feature, damit sich ein Prozess "Applikationsserver" nennen darf.

Natürlich ist es kein erforderliches Feature, aber durchaus ein sehr sinnvolles und nützliches Feature, wenn größere Anwendungen darauf laufen sollen.

Was den angesprochenen Punkt "Verteilbarkeit" angeht, hast Du natürlich recht. Mein kleiner Beispiel-Applikationsserver lässt sich momentan nicht ohne Umbauten auf verschiedene Rechner verteilen. Clusterfähig ist er auch nicht. Das Projekt wurde aber auch nicht mit dem Ziel entworfen, den großen Applikationsservern am Markt den Rang abzulaufen (Wobei es da im .NET-Umfeld gar nicht so viel gibt), sondern um einen praxisnahen Einstieg in die Entwicklung von verteilten mehrschichtigen Anwendungen zu geben. Selbst bei 200 Benutzern ist eine Verteiltung der Geschäftsdienste auf mehrere Maschinen in den meisten Fällen nicht nötig (ist pauschal aber nicht zu sagen, da es von der Anwendung abhängig ist). Für den Anfang kommt man selbst mit diesem kleinen Applikationsserverchen recht weit. Durch die Kapselung der Kommunikation durch die API, steht auch nichts im Wege, die Verteilbarkeit nachzurüsten (oder vielleicht auch von Remoting auf WCF zu wechseln). Besonders Session-State-Handling lässt sich mit ein paar Handgriffen einbauen (wenn man es wirklich braucht).

Da hast du natürlich vollkommen recht. Ich wollte ja auch nicht dein Projekt/Beispiel schlecht machen, sondern vielmehr habe ich mich an dem Wort vollständig gestoßen. Das ist auch schon der gesamte Hintergrund.

In der Tat gibt es im .NET Bereich kaum einen Applicationserver (die Enterprise Services zähle ich nicht, da diese lediglich COM+ kapseln). Aus diesem Grund habe ich dazu auch eine Diplomarbeit geschrieben und einen .NET Application Server gebaut 😉 (hier schließt sich ein Kreis).

Obwohl ich mein Projekt zunächst mal verteidige, freue ich mich sehr über solche kritischen Meinungen. Das Projekt ist eben erst geboren und muss erst noch reifen und gedeien. Mit Hilfe der Community wird es das hoffentlich auch recht schnell 😉.
Ich möchte auch noch einen Web-Client nachlegen. Da wird sich zeigen, ob eine Sitzungsverwaltung im Applikationsserver sinnvoll ist, oder ob ich das nicht besser auf den IIS abwälze.

Eventuell können wir uns hier ja einmal unterhalten und ein paar Modelle durchgehen, schließlich könnten eventuell beide Seiten daraus profitieren.

.NET GUI - Die Community für grafische Oberflächen unter .NET
Jetzt kostenlos besorgen: .NET BlogBook
Norbert Eder
DasBackup

3.728 Beiträge seit 2005
vor 16 Jahren
  1. Warum gibt deine Business-Schicht in der Funktion FindProductsByName() nur ein Datatable zurück, liegt dies am overhead den dein typed Dataset erzeugen würde?

Genau! Eine typisierte DataTable gibt immer alle Spalten der Tabelle zurück. Für die Trefferliste braucht man aber selten alle Spalten, sondern nur solche, die für die Identifizierung eines Datensatzes benötigt werden. Deshalb verwende ich hier eine schlanke nicht typisierte DataTable. Ich will ja Datenbank, Netzwerk und Applikationsserver nicht unnötig belasten und übertrage darum immer nur die kleinsmögliche Menge an Daten. Das ist auch eine Schwachstelle von vielen OR-Mappern: Man kann nur ganze Objekte übertragen.

  1. Ein Problem welches noch besteht, wenn eine Client durch einen Aufruf eine Fehler am Server erzeugt, stürzt der komplette Server Prozess ab. Sollte es nicht im Fehlerfall eine Exception an der Client gesendet werden, statt das Sie auf dem Server auftritt.

Das ist nur so, wenn Du die gesamte Projekt-Umgebung in Visual Studio laufen lässt. Bei unbehandelten Außnahmen springt da der Debugger an. Wenn Du Server- und Client-Prozesse mal direkt ausführst, wirst Du sehen, dass die Ausnahmen an die Clients weitergegeben werden (So läuft das zumindest bei mir ab).

  1. Ein kleiner Bug in dein MVC Modell, ist mir auch aufgefallen. Wenn man den Client öffnet und den Artikelstamm mehrmals anklickt passiert soweit nichts, nur 1 Fenster mit der suche, aber wenn man nun auf neu klickt öffnet er das Artikel Formular sooft man geklickt hat.

In meinem Beispiel ist keine richtige MVC-Implementierung eingebaut (Es gibt ja keine Model-Klassen).
Das Verhalten ist aber so beabsichtigt. Wenn man auch das Modul "Artikelstamm" klickt, öffnicht sich der Such-Dialog. Dort kann man vorhandene Artikel suchen und öffnen (Doppelklick auf einen Eintrag in der Trefferliste). Ich habe die Beispieldatenbank aber nicht mit Testdaten ausgestattet. Deshalb musst Du zuerst neue Artikel anlegen, bevor Du welche suchen kannst (Symbolleistenbefehl "Neu" im Such-Dialog). Der eigentliche Artikeleditor (wird zum anlegen und zum anzeigen, sowie ändern von Artikeln verwendet) ist aber mehrinstanzfähig. Du kannst also mehrere Artikel gleichzeitig öffnen, erstellen und bearbeiten.

Obwohl zu einem richtigen App-Server noch einige Dinge fehlen, finde ich es ein wirklich gelungenes Konzept. Ich falle zwar jedes mal wieder drüber das die Client Schnittstelle im Namespace Appserver.API liegt, aber das ist nicht weiter tragisch.

Was fehlt Dir denn genau? nitronic hat bereits angemerkt, dass Session-State-Handling und Verteilbarkeit fehlen. Was fehlt noch? Je mehr Feedback ich bekomme, desto besser kann ich das Beispiel erweitern.
Ich habe lange hin und her überlegt, ob ich eine getrennte Service- und Client-API machen soll, habe mich aber für eine API entschieden, die alles kann. Das Deployment ist so einfacher. Außerdem konsumieren sich die verschiedenen Dienste ja auch untereinander und benötigen deshalb auch Client-Funktionen. Die Namensgebung ist wohl überlegt. Der Namensraum Rainbird.AppServer.API enthält Klassen, der API des Applikationsservers. Die Infrastruktur des Applikationsservers ist über diese API zugänglich. Damit die Kapselung wirksam ist, sollte ausschließlich die API verwendet werden, um die Infrastruktur zu nutzen. Da Services und Clients die Infrastruktur gleichermaßen verwenden, fand ich eine zentrale API praktischer. Vor allem weil diese (bis jetzt zumindest) noch sehr übersichtlich ist. Missbrauch ist eigentlich ausgeschlossen. Auch wenn der Client die Klasse DataAccess sieht, kann er damit nichts anfangen, da nur das Dienstkonto des Applikationsservers zugriff auf den SQL Server bekommt (Das muss der Administrator natürlich auch so konfigurieren!).

Ich arbeite gerade an einem zweiten Dienst für Lagerverwaltung. Da wird man dann gut sehen können, wie die Lagerverwaltung auf die Stammdaten zugreift, ohne direkt die BusinessLogic-Assembly zu verwenden.

Eventuell können wir uns hier ja einmal unterhalten und ein paar Modelle durchgehen, schließlich könnten eventuell beide Seiten daraus profitieren. .

Gerne. Am besten gleich hier im diesem Thread (Wenn Dir das nicht zu unübersichtlich ist). Wie sieht die Architektur des Applikationsservers aus, den Du als Diplomarbeit entwickelt hast?

1.274 Beiträge seit 2005
vor 16 Jahren

Zitat von LastGentleman:
2. Ein Problem welches noch besteht, wenn eine Client durch einen Aufruf eine Fehler am Server erzeugt, stürzt der komplette Server Prozess ab. Sollte es nicht im Fehlerfall eine Exception an der Client gesendet werden, statt das Sie auf dem Server auftritt.
Das ist nur so, wenn Du die gesamte Projekt-Umgebung in Visual Studio laufen lässt. Bei unbehandelten Außnahmen springt da der Debugger an. Wenn Du Server- und Client-Prozesse mal direkt ausführst, wirst Du sehen, dass die Ausnahmen an die Clients weitergegeben werden (So läuft das zumindest bei mir ab).

Ok, das habe ich nicht ausprobiert, ich bin nichts so tief drinnen in dot.Net Remoting. Es wäre natürlich auch interessant, die Fehler die auftreten, in einer Datenbank zu speichern damit man sie später auswerten kann um so Angriffe auf den Server festzustellen.

Der nächste Schritt wäre nicht richtige Fehlermeldungen zurückzuliefern, da die normalen Exceptions einen zu tiefen Einblick in die Struktur des Programmes geben.

Ich arbeite gerade an einem zweiten Dienst für Lagerverwaltung. Da wird man dann gut sehen, können wie die Lagerverwaltung auf die Stammdaten zugreift, ohne direkt die BusinessLogic-Assembly zu verwenden.

Darauf bin ich schon sehr gespannt, wie du die Lagerverwaltung implementierst ohne das andere Modul anzufassen.

Je mehr ich mir deinen Code ansehe, desto mehr stelle ich fest das ich noch viel zu lernen habe.
Darf ich fragen viel Zeit du für den aktuellen Stand, bis jetzt so gebraucht hast?

lg
LastGentleman

"Das Problem kennen ist wichtiger, als die Lösung zu finden, denn die genaue Darstellung des Problems führt automatisch zur richtigen Lösung." Albert Einstein

354 Beiträge seit 2004
vor 16 Jahren

Gerne. Am besten gleich hier im diesem Thread (Wenn Dir das nicht zu unübersichtlich ist). Wie sieht die Architektur des Applikationsservers aus, den Du als Diplomarbeit entwickelt hast?

Eher nicht öffentlich im Thread.

Zum .NET Remoting:
Ich hab mir den Source jetzt nicht angesehen, aber so am Rande mitbekommen, dass die Datenübertragung per .NET Remoting passiert? Hier würde ich beispielsweise eher WCF einsetzen, zumal diese "Technologie" von Microsoft weiterhin unterstützt wird, verbesserte Funktionalität bietet und .NET Remoting schon jetzt stiefmütterlich behandelt wird.

Zudem würde ich den Persistance-Layer wesentlich erweitern. Oder zumindest die Möglichkeit bieten, entsprechende O/R Mapper zu verwenden (siehe JBoss).

.NET GUI - Die Community für grafische Oberflächen unter .NET
Jetzt kostenlos besorgen: .NET BlogBook
Norbert Eder
DasBackup

3.728 Beiträge seit 2005
vor 16 Jahren

Es wäre natürlich auch interessant, die Fehler die auftreten, in einer Datenbank zu speichern damit man sie später auswerten kann um so Angriffe auf den Server festzustellen.

Sowas ähnliches ist schon eingebaut. Du kannst Dir dir Ablaufverfolgungsdaten in eine Log-Datei ausgeben lassen. Dazu musst Du nur die entsprechenden Auskommentierungen aus der App.config des Applikationsservers entfernen (Siehe Screenshot). Das eingesetzte Trace-System ist übrigens Standard-.NET 2.0 und liegt im Namensraum System.Diagnostics. Das ist ein Beispiel dafür, dass das .NET Framework für die meisten Probleme bereits fertige Lösungen bereithält.
Wenn Dir die Log-Datei zu einfach ist, kannst Du relativ einfach einen eigenen TraceListener schreiben, der die Logs in eine Datenbank schreibt.

Der nächste Schritt wäre nicht richtige Fehlermeldungen zurückzuliefern, da die normalen Exceptions einen zu tiefen Einblick in die Struktur des Programmes geben.

Ausnahmen sind eher für Entwickler interessant und die sollen einen möglichst tiefen Einblick in das System haben. Angenommen man entwickelt eine Anwendung in Teams. Einige Arbeiten an den Geschäftsdiensten und andere Kollegen arbeiten an der Benutzeroberfläche. Wenn der GUI-Entwickler beim entwickeln und testen seines Codes eine Ausnahme bekommt, soll er auf jeden Fall möglichst viele Informationen bekommen. Wie soll er sonst den Fehler schnell finden, ohne das andere Team auch noch einen halben Tag zu beschäftigen?
Ausnahmen, die z.B. aufgrund von Fehleingaben des Benutzers zu erwarten sind, muss man abfangen und den Benutzer (z.B. per MessageBox) informieren, dass er was falsch gemacht hat. In einigen Fällen kann man die ex.Message vom Applikationsserver verwenden, manchmal muss man am Client eigene Meldungen schreiben, die für den Endanwender besser verständlich sind.
Andere Ausnahmen treten aufrund von äußeren Einflüssen auf (wenn z.B. die SQL Server Maschine gerade aubgeraucht ist). Bei solchen Ausnahmen bringt es nichts, sie abzufangen und schön als Geschenk einzupacken, da die Anwendung eh nicht mehr weiterlaufen kann.

Darf ich fragen viel Zeit du für den aktuellen Stand, bis jetzt so gebraucht hast?

Darfs Du. Grob überschlagen dürften das ca. 25 Stunden auf 4 Abende verteilt gewesen sein. Das beinhaltet Konzept, Planung und Implementierung. Da ich schon Projekte mit Remoting und Enterprise Services gemacht habe, konnte ich einiges fast aus dem Kopf programmieren. Als Entwicklungs-PC wurde übrigens ein altes Acer Travelmate Notebook mit 768 MB RAM, Windows XP Professional und Visual Studio 2005 Standard Edition eingesetzt.

Die Datenzugriffsschicht war auch bereits vorher fertig (Providerunabhängige Datenzugriffskomponente). Ich musste den Code nur noch in die Rainbird.AppServer.API-Assembly kopieren und den Namensraum ändern. Für diese Datenzugriffs-Klasse kannst Du auch nochmal 8 Stunden rechnen.
In einem richtigen Projekt solltest Du ein paar Tage mehr einplanen. Wenn Du nicht alleine entwickelst, müssen sich die anderen Team-Mitglieder auch erst in das Konzept einarbeiten. Der anfängliche Mehraufwand lohnt isch aber, da man den Applikationsserver und dessen Infrastruktur für beliebige Projekte wiederverwenden kann. Innovationen aus Projekt B kann man z.B. per Update dann auch Kunden von Projekt A zugute kommen lassen, da beide Projekte den selben Applikationsserver verwenden.

Hätte ich das Ganze mit WCF gemacht, wären wohl wesentlich mehr Abende drauf gegangen. Ich spiele auch mit dem Gedanken, eine WCF-Version des Beispiels oder zumindest eine "Migrationsanleitung" zu machen. Wenn das ohne Änderungen an der API gelingt, habe ich gut gearbeitet. Dafür muss ich aber zuerst noch WCF-Erfahrung sammeln.

3.728 Beiträge seit 2005
vor 16 Jahren

Eher nicht öffentlich im Thread.

Okay. Das respektiere ich natürlich.

Hier würde ich beispielsweise eher WCF einsetzen, zumal diese "Technologie" von Microsoft weiterhin unterstützt wird, verbesserte Funktionalität bietet und .NET Remoting schon jetzt stiefmütterlich behandelt wird.

Das ist mir bewusst. Ich wollte aber zuerst einmal ein relativ überschaubares Beispiel erstellen. Da es sich dabei um meine Freizeit handelt, habe ich mich für eine Technologie entschieden, mit der ich sehr gut vertraut bin und die so einfach íst, dass auch Themen-Einsteiger gut damit zurecht kommen. Meine WCF-Kenntnisse waren mir selbst nicht gut genug, um ein Beispiel-Projekt zu schreiben, welches veröffentlicht wird. Ich will mich ja nicht blamieren 😄. Die Konzepte von verteilten Anwendungen sind immer die Selben. Da spielt die eingesetzte Technologie eine eher untergeordnete Rolle. WCF bietet zwar wesentlich mehr Möglichkeiten, ist aber auch viel aufwändiger zu konfigurieren (Bisheriger Eindruck von WCF). Hinzu kommt, dass ich die derzeit herrschende Technologie-Schemme im Microsoft-Umfeld mit gemischten Gefühlen sehe. Von daher hatte Remoting als "fertige" Kommunikationstechnologie auch Sinn gemacht. Es soll auch noch auf Windows 2000 laufen.

Zudem würde ich den Persistance-Layer wesentlich erweitern. Oder zumindest die Möglichkeit bieten, entsprechende O/R Mapper zu verwenden (siehe JBoss).

Ich bin kein großer Freund von OR-Mapping und habe bewusst auf typisierte DataSets und ADO.NET gesetzt. Das ist alles schon da und im .NET Framework eingebaut. In einem Projekt habe ich selbst einmal einen OR-Mapper eingesetzt, bin aber schnell wieder davon abgekommen. Der Aufwand ist viel höher als der Nutzen. Das ist mein persönliches Fazit zu OR-Mappern und soll nicht heißen, dass OR-Mapper generell schlecht sind. Mir konnte bisher noch niemand Vorteile nennen, die mich davon überzeugt hätten.

H
154 Beiträge seit 2007
vor 16 Jahren

kleine bemerkung zum thema dataset/o-r mapper.
wenn du es wichtig findest das zu verwenden was es gibt, nimm doch einen Java-AppServer 🙂

mir geht es in sachen dataset genau umgekehrt. Mir fehlt die möglichkeit der vererbung bzw das implementieren von interfaces enorm. dadurch meine ich, ist es schwierig, bzw mühsam generische businesslogik zu schreiben.

dein projekt finde ich interessant, eigentlich möchte ich auch schon länger an dem thema was machen - nur fehlt irgendwie die zeit und lust zuhause was zu machen. und beruflich hab ich keine zeit.

weiterhin viel spass.

3.728 Beiträge seit 2005
vor 16 Jahren

wenn du es wichtig findest das zu verwenden was es gibt, nimm doch einen Java-AppServer 🙂

Sorry, aber was soll mir ein Java-Applikationsserver für meine .NET Anwendungen nützen?

B
122 Beiträge seit 2004
vor 16 Jahren

Hallo,

Ich arbeite zur Zeit so:

Server:
Datenbank -> Nhibernate -> Datalayer -> Business Layer -> Manager -> ServicePoint

Wobei bei Standartabfragen getyped wird 🙂

public static List<T> GetAll(IAppContext context) {

am Client gehts dann andersrum:

ServicePoint -> Datalayer -> BusinessLayer -> Präsentation

was dann völlig variabel und austauschbar ist.

Hier mal drei Screenshots:
http://www.thomas-peterson.de/tpwawi/screenshots.html

Das Problem bei WCF ist das es zwar ein Paar Beispiele gibt aber wie man z.b. Rolen/Group basierende Systeme entwickelt.
Mit der ganzen Sicherheits abfragen darf er Kunde editieren? Nein Button ausblenden und natürlich auch nochmal überprüfen, fals so eine Anfrage rein kommt per Service.

MFG

S
8.746 Beiträge seit 2005
vor 16 Jahren

Ich finde es eigentlich sehr schade, was MS an dieser Baustelle treibt. Im Prinzip hat MS schon lange alle Technologien und Funktionalitäten einsatzbereit, schafft es aber nicht daraus ein für den Entwickler durchschaubares Produkt zu schnüren.

Spätestens im Rahmen von .NET wäre die Chance gewesen, eine einheitliche Plattform und ein passables Komponentenmodell zu schustern. Aber noch muss man sich um COM+ Gedanken machen, auch wenn die Entwicklungswerkzeuge den Unterbau zu kaschieren versuchen. Transaktionen aus A, Persistenz aus B und Aktivierung von C. Was soll das?

Leider ist der Zug auf dem Server für .NET ziemlich abgefahren, zumindest was AppServer-Projekte in großem Stil angeht. Die Reife, die die großen Java-Server erreicht haben, wird wohl nicht mehr einzuholen sein.

Man mag einwenden, dass der AppServer-Hype zu Beginn des Jahrtausends durchaus Ernüchterung gewichen ist. Aber man muss sagen, dass es wohl kaum Anwendungen im Banken- und Versicherungsbereich gibt und geben wird.

.NET wird sich bestimmt seinen Platz für kleine bis mittelgroße Anwendungen erkämpfen (und vermutlich hier auch Java überholen), aber die High-End-Projekte werden wohl Java vorbehalten bleiben. Und das nur, weil es einfach keine passable Enterprise-Technologie gibt, die auch jemand wirklich beherrscht. Man muss einfach zu viele Technologien kennen.

Leider sind nichtmal Ansätze für eine Besserung zu erkennen. MS scheint sich der aussichtlosen Position bewußt zu sein und versucht das Feld wieder einmal vom Client her aufzurollen (Silverlight, Popfly und Co.). Frei nach dem Motto: Wen interessieren schon die paar Großanwendungen, wir wollen Millionen User, die Mashups basteln.

Wer wirklich "fette" Anwendungen bauen will, der sollte von .NET die Finger lassen und ins Java-Lager wechseln.

Das Problem, dass MS einfach keinen Fuß in die großen Rechenzentren kriegt, kommt verschärfend hinzu. Windows ist oftmal absolutes No-Go. Hier wurden einfach viel zu wenige Rechenzentrenleiter geschmiert. 😉

B
122 Beiträge seit 2004
vor 16 Jahren

Dinnernow und Stocktrader gibts

S
8.746 Beiträge seit 2005
vor 16 Jahren

Ich rede von echten Anwendungen wie Kreditkartenabrechnungssysteme und ähnliches. Millionen Clients, Serverfarmen, etc.!

B
122 Beiträge seit 2004
vor 16 Jahren

Hallo,

Sicherlich gibt es da welche aber ich denke da wird dann auch intern entwickelt.

Hypovereinsbank arbeitet z.b. auch mit PHP und mit vielen anderen Sprachen 🙂http://www.mayflower.de/content/content2.php?CatID=31&NewsID=73&lang=de

MFG

S
8.746 Beiträge seit 2005
vor 16 Jahren

Aber um das noch abzuschliessen: Vielleicht ist ja die Strategie von MS das AppServer-Ding einfach auszusitzen durchaus von Erfolg gekrönt. Ein schöner Artikel, der die Überfrachtung von Projekten aus Java-Sicht (z.B. mit J2EE) beschreibt mal hier:

http://www.stefanroock.de/downloads/Flow.html

Vielleicht sind die Super-Hobel wirklich eine so exotische Gattung, dass man doch lieber Webseiten mit ASP.NET basteln sollte... es soll ja sogar noch Leute geben, die PHP benutzen. 😉

H
154 Beiträge seit 2007
vor 16 Jahren

Hallo Svenson,

Komme selber aus dem java-enterprise umfeld. bin deiner meinung. ms verschläft das total und werfen tonnenweise technologien auf den markt. seit ich auf .net entwickle komme ich mir manchmal vor wie die mönche in der vergangenheit die seitenweise bücher abgetippt haben. alles muss man selber schreiben. ich meine, warum sonst dieser thread? mal ehrlich - wer in der java welt käme auf die idee einen app-server zu schreiben????
Wichtig im j2ee umfeld ist halt, das der entwickler eine entwicklungsumgebung hat, bei der er seine services nicht zu deployen braucht damit er nicht dauernd warten muss.
Bei meinem letzten arbeitgeber hatten wir so eine umgebung. kommerziell gibt es das wohl noch nicht.

wieso baut ms keine gescheiten app-server? keine ahnung, denn soviel können die nicht. ein bisschen service pooling etc.. aber so was von hexerei ist das nicht. aber vielleicht würde es für ms langsam aber sicher etwas peinlich werden, wenn sie schon wieder was abkupfern würden. solang sie das tun sind sie ja keine alternative. ich persönlich erwarte von ms mehr innovationen. echte alternativen im applikationsbau.

cheers

3.728 Beiträge seit 2005
vor 16 Jahren
Schwergewichte

Vielleicht sind die Super-Hobel wirklich eine so exotische Gattung, dass man doch lieber Webseiten mit ASP.NET basteln sollte... es soll ja sogar noch Leute geben, die PHP benutzen. 😉

Da möchte ich mich anschließen. Die großen Java-Applikationsserver sind stellenweise viel zu schwergewichtig. Viele Java-Entwickler vermeiden deshalb z.B. auch EJBs, wenn sie können.

Auch wenn MS nicht in den Mark der übergroßen Super-Anwendungen reinkommt, bleibt trotzdem noch genug übrig. Was ist mit den kleinen und mittelgroßen Anwendungen? Das sind Anwendungen des Mittelstandes (und damit meine ich nicht nur Firmen mit 500 Mitarbeitern). Die wollte bis vor kurzem fast niemand haben. Alle wollten sie die großen Fische. Da gibts aber nicht mehr viel zu holen und der Kuchen ist weitgehend aufgeteilt. Die Modelle und damit auch die schweren fetten Applikationserver passen aber nicht so recht zu diesen "kleinen" Anwendungen.
Deshalb denke ich, dass man einen leichtgewichtigen Applikationsserver für diesen Bereich sehr gut gebrauchen kann. Einen Applikationsserver, der dem Entwickler keine komplexen Container und Konfigurationsmodelle aufzwingt, sondern einfach in der Handhabung ist, aber trotzdem sicher und leistungsfähig.

Wo hängt ihr denn sonst die Geschäftslogik eurer .NET Anwendungen auf?*Im Client-Code (Windows.Forms, ASP.NET)? *Im SQL Server (Gespeicherte Prozeduren, CLR)? *Im Webserver (Webservices)? *In Enterprise Services (COM+)? *Oder doch in eigenen Host-Prozessen (Sockets, Remoting, WCF)?

1.378 Beiträge seit 2006
vor 16 Jahren

Bisher wars und ist es bei uns noch so, das 90% jeglicher Logik quer in den Formularen verstreut ist und die restlichen 10% im DB-Server.
Ich bin aber daran mich mit Architekturmodellen auseinander zu setzen damit ich später einmal die Entwicklung in eine andere Richtung leiten kann(Ordentliche Schichtentrennung und viell. App Server).

Lg XXX

S
8.746 Beiträge seit 2005
vor 16 Jahren

Vielleicht überholt auch ein anderer Zweig das Thema AppServer. Letztlich sind das nur Technologien. Und eigentlich will auch niemand damit was zu tun haben. Entscheidend ist die Architektur und gutes Design. Die Kernfragen dort sind immer die gleichen: Wie stelle ich Skalierbarkeit her, Remote vs. lokale Calls, Entkopplung, Wartbarkeit, etc.! Den Rest will ich eigentlich Tools überlassen. Insofern wird MDA und Co. das Thema vielleicht von der Seite aufrollen. Ein möglicher Weg, der sich bei MS abzeichnet, sind die Factories von MS oder Drittherstellern. Ich kann mich auf fachliche Aufgaben konzentrieren, habe Best Practices in Form von Codegeneratoren für architektonische (Layering) und funktionale Anforderungen (Transaktionen, Security), Konfigurationseditoren und eine Umgebung, die mir das ganze Deployment übernimmt und mich bei der Fehlersuche unterstützt.

MS hat ja kürzlich Oslo vorgestellt, was ja genau in die Richtung abzielt.

The Oslo vision also will be enabled in the short term by a greater commitment to modeling. "We're making our platform truly model driven," added Wahbe.

Ich vermute mal, Oslo wird nichts weiter als eine hochintegrierte MDA-Lösung für Studio sein mit ein paar Tools abgerundet.

Auf der Kommunikationsseite hat MS mit WCF die sicher zur Zeit modernste Lösung auf dem Markt im Portfolio.

Und auf der Frontend-Seite scheinen dazu auch Bemühungen zu laufen, ihn endlich vollständig von der Mittelschicht zu entkoppeln. Stichwort: Volta (sehr genial wie ich finde).

Der Backend ist heute schon iO und wird mit dem Entity Framework sicher nochmal zulegen.

3.728 Beiträge seit 2005
vor 16 Jahren
Factories

Ich weiss nicht so recht. Diese Factories sind nur Codegeneratoren. Was ich da bisher gesehen habe, hat mich nicht überzeugt. Einige Leute sind schon böse auf die Nase gefallen, mit "generierten" Anwendungen.

Wie soll man mit einem Drei-Mann-Team diese Dinge einsetzen. Es ist zu kompliziert und zu aufwändig. Einfache Sachen müssen her, die funktionieren.

Da bau ich mir lieber einen Applikationsserver, den ich für eine Vielzahl von Projekten einsetzen kann. Die Frage ist allerdings immer, wie viele Projekte ich tatsächlich damit machen kann, ohne dass ich an irgendwelche Grenzen stoße und dann dann doch wieder neue Infrastruktur entwickeln muss? Aber selbst wenn hat man eine Basis, auf die man aufbauen kann.

S
8.746 Beiträge seit 2005
vor 16 Jahren

Diese Factories sind nur Codegeneratoren.

Nein, durchaus mehr. Schau dir mal z.B. die Web Services Factory an. Viele Leute wissen nicht, wie sie die Mittelschicht und den Backend trennen und verbinden sollen. Das übernimmt alles die Factory, weil sie dir zumindest ein klares Modell an die Hand gibt, wie die Architektur aussehen kann.

Noch ein Schritt weiter: Eine Factory wird dir die Möglichkeit geben, per Einstellung zu entscheiden, wo welche Dienste laufen (IIS, Service, Biztalk, etc.). Das Teil generiert die notwendigen Klassen und deployed auch gleich korrekt.

Es ist doch so, dass der AppServer nur ein Teil der Gesamtanwendung ist. AppServer hin und her, aber du brauchst u.U. einen WebServer wenn du Web-Clients hast, du musst entscheiden, auf welchen Rechnern die Layer der Anwendung laufen, Clustering, etc.! Der AppServer ist nur ein Teil des Puzzles weil es nur die Mittelschicht adressiert (und sogar davon u.U. nur einen Teil).

H
154 Beiträge seit 2007
vor 16 Jahren

Die Architektur sollte vorallem so gewählt sein, dass meine Applikation skalierbar ist.
Eine Architektur die "nur" kleinen/mittleren Unternehmen genügt, kann für ein Softwareunternehmen fatale folgen haben, nähmlich dann, wenn die Architektur dem Wachstum des Unternehmens im Wege steht. Was dann folgt: Umbauen, entweder die alten kunden migrieren oder 2 Software Produkte pflegen (ihhhhhhhhh).
Wieso keinen fetten JBoss bei einem kleinen/mittleren Unternehmen einsetzen? Was tut da so weh? Ich nehm ja auch einen SqlServer, obwohl der für viel mehr Last designed ist als nötig.
Und sooooo schlimm kann und ist die parametrierung nicht - dafür sind doch schon viel zu viele im einsatz...

WCF gefällt mir ebenfalls sehr gut, überhaupt hat .net 3.0 so allerhand zu bieten. was mir noch fehlt ist eine wirklich fähiger Persistenzlayer. Die MS ansätze sind mir immer etwas zu fett.

S
8.746 Beiträge seit 2005
vor 16 Jahren

Wieso keinen fetten JBoss bei einem kleinen/mittleren Unternehmen einsetzen?

Weil schwergewichtige Lösungen (und dazu gehört J2EE ohne Frage) immer mehr Kosten verursachen, wenn sie ihr Gewicht nicht benötigen. Skalierbarkeit ist sicher ein Argument, aber kein Killer-Argument. Auch anderen Lösungen skalieren durchaus. Kosten muss _immer _ein ROI entgegen stehen. Wenn der überhaupt nicht absehbar oder völlig unwahrscheinlich ist (wird meine kleine Handwerkslösung mit 10 Clients wirklich jemals einem Großkonzern mit 300.000 Mitarbeitern laufen?), dann macht es oft mehr Sinn, die Architektur so zu gestalten, dass eine Migration auf eine Enterprise-Lösung wenigstens ohne völliges Neuschreiben der Business-Logik machbar ist. Denn hier steckt meist die Kernkompetenz der Anwendung. Der Rest ist Technik, und die wandelt sich eh.

Wenn vielleicht in 10 Jahren alle SOA machen dann ist EJB so kalt wie ein Teller Gazpacho. Wie Cobol-Mainframes das in Zeiten von C/S-Systemen wurden.

Bedenke: Weder Google noch Yahoo setzen J2EE ein. Und das Zeug skaliert durchaus.

H
154 Beiträge seit 2007
vor 16 Jahren

Wieso keinen fetten JBoss bei einem kleinen/mittleren Unternehmen einsetzen?

Weil schwergewichtige Lösungen (und dazu gehört J2EE ohne Frage) immer mehr Kosten verursachen, wenn sie ihr Gewicht nicht benötigen. Skalierbarkeit ist sicher ein Argument, aber kein Killer-Argument. Auch anderen Lösungen skalieren durchaus. Kosten muss _immer _ein ROI entgegen stehen. Wenn der überhaupt nicht absehbar oder völlig unwahrscheinlich ist (wird meine kleine Handwerkslösung mit 10 Clients wirklich jemals einem Großkonzern mit 300.000 Mitarbeitern laufen?), dann macht es oft mehr Sinn, die Architektur so zu gestalten, dass eine Migration auf eine Enterprise-Lösung wenigstens ohne völliges Neuschreiben der Business-Logik machbar ist. Denn hier steckt meist die Kernkompetenz der Anwendung. Der Rest ist Technik, und die wandelt sich eh.

Wenn vielleicht in 10 Jahren alle SOA machen dann ist EJB so kalt wie ein Teller Gazpacho. Wie Cobol-Mainframes das in Zeiten von C/S-Systemen wurden.

Bedenke: Weder Google noch Yahoo setzen J2EE ein. Und das Zeug skaliert durchaus.

Hallo,
was an J2EE ist denn so schwergewichtig? Und warum soll das kosten verursachen?
JBoss ist GRATIS!!
SessionBeans und EntityBeans - fertig.
OK - ob sich 10 Client einen Server teilen sollen ist sicher fraglich. Wie gesagt, die Architektur soll ein wachstum zulassen. Meine Erfahrung der letzten 8 Jahre hat folgendes gezeigt: Wir haben eine Lösung geschrieben die anfänglich 3 Sachbearbeiter nutzen und heute bei einem RZ läuft und beim grössten Kunden ca 1000 Sachbearbeiter bedient. Hätten wir damals so argumentiert wie du, wäre das nie möglich gewesen.

Wo ich dir hingegen 100% recht gebe ist, dass Businesslogik so geschrieben werden soll dass sie "Hype-Neutral" ist (SessionBean ruft Service auf etc..), so dass wir in 10 Jahren problemlos auf die modellgetriebeneserviceobjektworkflowkomponentenarchitektur migrieren können.

S
8.746 Beiträge seit 2005
vor 16 Jahren

was an J2EE ist denn so schwergewichtig? Und warum soll das kosten verursachen?

Komplexität verursachte Kosten. Komplexität braucht gute und erfahrene Mitarbeiter, die sich ihre Qualifikation teuer bezahlen lassen. Komplexität verursacht aber vor allem Kosten in der Wartungs- und Erweiterungsphase, wenn die Erstentwickler an neuen Projekten sitzen oder die Firma verlassen haben und Neulinge sich durch das System wühlen müssen.

Wir haben eine Lösung geschrieben die anfänglich 3 Sachbearbeiter nutzen und heute bei einem RZ läuft und beim grössten Kunden ca 1000 Sachbearbeiter bedient. Hätten wir damals so argumentiert wie du, wäre das nie möglich gewesen.

Ich glaube, du hast mich nicht verstanden. Man muss als Entwickler immer abwägen. Auf der einen Seite steht das eiserne Gesetz, die Dinge nicht unnötig kompliziert zu machen ("keep it stupid, keep it simple"). Auf der anderen Seite muss man das, um skalierbar und erweiterbar zu bleiben und damit neue Kunden zu erschließen zu können (ob mans tut ist unbekannt). Es ist letztlich eine Aufgabe des Produktmanagements ein Zukunftszenario zu entwerfen, das maximalen Profit bei minimalem Risiko verspricht. Ob es hält steht auf einem anderen Blatt. Beispiel sind daher nicht geeignet um irgendwas zu beweisen. Es gibt allerdings etliche Untersuichungen, die zeigen, dass Systeme oftmal viele Funktionalitäten besitzen die kaum oder nicht genutzt werden. System tendieren in der Praxis eher zum "Überdesign" - zumindest im professionellen Sektor. Bei Anfängern sieht das natürlich anders aus. Um es auf den Punkt zu treiben: Du wirst sicher nicht J2EE mit x Schichten einsetzen, wenn dich jemand mit einer Desktop-Lösung beauftragt. Oder noch anders: Ich kaufe mit als Paketzusteller auch keinen 18-Tonner, nur weil vielleicht irgendwann jemand eine 10-Tonnen-Lieferung aufgeben will.

Meiner Erfahrung nach sind Hypes immer gleichbedeutend mit schwergewichtigen Lösungen. Danach folgt die Ernüchterung und der Ruf nach "einfachen" - also leichtgewichtigen - Lösungen. Lösungen, die einen weniger "drücken". Das hat nix mit subjektiven Empfindungen zu tun ("J2E ist doch kinderleicht...") sondern mit messbaren Effekten (Produktivität * Kosten).

Unverkennbar sind Lösungen wie "Ruby on Rails", LAMP und Co. eine Antwort auf J2EE. Eben Lösungen, die in den meisten Fällen mit weniger Wissen, Arbeit und Risiko (und damit Kosten) zum Ziel führen. Das sie das nicht immer tun liegt in der Natur der Sache. Aber genau das ist ja u.a. die Aufgabe eines Architekten, die richtige Technologie auszuwählen. Und das anhand vieler Kriterien. Skalierbarkeit ist nur eine davon.

B
122 Beiträge seit 2004
vor 16 Jahren

Auch Ruby on Rails skaliert siehe XING

H
154 Beiträge seit 2007
vor 16 Jahren

Komplexität verursachte Kosten. Komplexität braucht gute und erfahrene Mitarbeiter, die sich ihre Qualifikation teuer bezahlen lassen. Komplexität verursacht aber vor allem Kosten in der Wartungs- und Erweiterungsphase, wenn die Erstentwickler an neuen Projekten sitzen oder die Firma verlassen haben und Neulinge sich durch das System wühlen müssen.

Jetzt verstehe ich dich wirklich nicht mehr - sorry 🙂. aber, wer app-server selber bauen will, sich um kommunikation, failover, XA etc.. selber kümmern muss, DER bring enorme komplexität in seine applikation, DER braucht teure + erfahrene Mitarbeiter. Gerade Deshalb gibts ja die App-Server damit man sich auf die kernaufgabe - das schreiben von Geschäftslogik konzentrieren kann.

Ich glaube, du hast mich nicht verstanden. Man muss als Entwickler immer abwägen. Auf der einen Seite steht das eiserne Gesetz, die Dinge nicht unnötig kompliziert zu machen ("keep it stupid, keep it simple"). Auf der anderen Seite muss man das, um skalierbar und erweiterbar zu bleiben und damit neue Kunden zu erschließen zu können (ob mans tut ist unbekannt). Es ist letztlich eine Aufgabe des Produktmanagements ein Zukunftszenario zu entwerfen, das maximalen Profit bei minimalem Risiko verspricht. Ob es hält steht auf einem anderen Blatt. Beispiel sind daher nicht geeignet um irgendwas zu beweisen. Es gibt allerdings etliche Untersuichungen, die zeigen, dass Systeme oftmal viele Funktionalitäten besitzen die kaum oder nicht genutzt werden. System tendieren in der Praxis eher zum "Überdesign" - zumindest im professionellen Sektor. Bei Anfängern sieht das natürlich anders aus. Um es auf den Punkt zu treiben: Du wirst sicher nicht J2EE mit x Schichten einsetzen, wenn dich jemand mit einer Desktop-Lösung beauftragt. Oder noch anders: Ich kaufe mit als Paketzusteller auch keinen 18-Tonner, nur weil vielleicht irgendwann jemand eine 10-Tonnen-Lieferung aufgeben will.

könnte ich alles unterschreiben - aber in DIESEM thread geht es ja um app-server. und darum das der kollege einen schreiben will - und ich sage: nimm doch einen.

3.728 Beiträge seit 2005
vor 16 Jahren

Viele Leute wissen nicht, wie sie die Mittelschicht und den Backend trennen und verbinden sollen. Das übernimmt alles die Factory, weil sie dir zumindest ein klares Modell an die Hand gibt, wie die Architektur aussehen kann.

Ich werde mir die Factories doch nochmal genauer ansehen. Der erste oberflächliche Eindruck war nur so ernüchternd.

AppServer hin und her, aber du brauchst u.U. einen WebServer wenn du Web-Clients hast, du musst entscheiden, auf welchen Rechnern die Layer der Anwendung laufen, Clustering, etc.! Der AppServer ist nur ein Teil des Puzzles weil es nur die Mittelschicht adressiert (und sogar davon u.U. nur einen Teil).

Mir ist klar, dass der Applikationsserver nur die Mittelschicht abdeckt. Aber irgendwo muss eben die Mittelschicht laufen. Da liegt bei .NET (trotz WCF) das Problem. Ich will nicht für jedes Projekt einen neuen Host schreiben. WAS (Windows Activation Service) kommt erst mit Windows Server 2008. Wird für mich also noch eine ganze Weile zukunftsmusik bleiben.
Was die Web-Anwendungen angeht, sehe ich da nicht das Problem. Ich kann doch ASP.NET Seiten schreiben, die Dienste meinenes Applikationsservers konsumieren. Das einzige was ich dabei machen muss, ist den Sitzungsschlüssel meiner Applikationsserver-Sitzung in den Sitzungsstatus der Webseite zu schreiben. Wenn Webserver und Applikationsserver auf der selben Maschine laufen, kann ich auch IPC-Kanäle für die Kommunikation verwenden.

Clustering interessiert mich zwar sehr, aber ich habe nicht die nötige Testumgebung daheim, um mich damit vertraut zu machen. Da müsste ich schon ein MSDN-Abo machen, aber privat rentiert sich das nicht. Mit Windows XP Pro und Visual Studio Standard ist nicht viel drin mit Cluster. Deshalb schiebe ich Clustering erstmal beiseite und versuche die Probleme "kleinerer" Umgebungen zu adressieren.

3.728 Beiträge seit 2005
vor 16 Jahren

Jetzt verstehe ich dich wirklich nicht mehr - sorry 🙂. aber, wer app-server selber bauen will, sich um kommunikation, failover, XA etc.. selber kümmern muss, DER bring enorme komplexität in seine applikation, DER braucht teure + erfahrene Mitarbeiter. Gerade Deshalb gibts ja die App-Server damit man sich auf die kernaufgabe - das schreiben von Geschäftslogik konzentrieren kann..

Das kann man so nicht sehen. Man muss sich nicht wirklich selber darum kümmern. Das .NET Framework hat für fast alles fertige Lösungen. Diese Lösungen sind aber nicht in einem Applikationsserver integriert.

Automatische verteilte Transaktionen bekommst Du frei Haus mit System.Transactions. Einfach Transaktionsklammer setzen, bei Erfolg Complete aufrufen und fertig. Funktioniert auch über Remoting wunderbar.

Kommunikation macht in meinem Fall Remoting. Darum muss man sich auch nicht selber kümmern. Ich habe nur eine Factory zur Proxyerzeugung geschrieben, damit ich nicht überall URIs reinkodieren muss, sondern die benötigten URIs zum entfernten Methodenaufruf aus dem Schnittstellennamen herleiten kann.
Statt Remoting könnte man auch WCF verwenden. Da ist auch schon alles fertig und man muss sich nicht merh direkt um die Kommunikation kümmern.

Für Persistenz gibts ADO.NET.

Bei Failover muss ich zwar zunächst mal passen, aber trotzdem bietet das .NET Framework für die meisten Problemstellungen die passenden Tools. Alles ist einfach und intuitiv einsetzbar und gut dokumentiert.
Deshalb habe ich nicht nur einen allgemeinen Host geschrieben, sondern gleich ein kleines Beispielprojekt, welches zeigen soll, wie man die einzelnen Werkzeuge des .NET Framework kombinieren kann, um leichtgewichtige aber effiziente Anwendungen zu schreiben.

1.274 Beiträge seit 2005
vor 16 Jahren

Diese Threat ist äußerst interessant.

@HappyLil:
Ich hab keine Ahnung über Java, wie lange braucht man Windows Server leer installation damit man ein lauffähige JBOSS hat. Und wie lange das die Module eingebunden sind.
Welche Einarbeitungszeit hast du gebraucht, dass du ihn soll halbwechs beehrst hast.

@Rainbird:
Ich kann dir nur empfehlen die Webservice Service Factory mal anzusehen, in der aktuellen Version ist zwar der Datenbank Zugriff rausgefallen, aber man sieht schön wie man am besten den Aufbau für Webdienste macht.

Wie oben schon erwähnt wurde generiert die Factory die notwendigen Klassen damit das Ding läuft und da ist es ja nur eine Kleinigkeit unterschiedliche Servertechnolgien (Webservice, WCF, ...) als Dienst bereitzustellen.

Ich glaube Microsoft wird sich stark auf die WAS (Windows Activation Service) konzentrieren. Die laufen mit dem IIS (was nicht bedeutet das Sie http gebunden sind), der stellt alles zur Verfügung LoadBalancing, Clustering, Failover, Prozessüberwachung, ...
Also alles was ein vollwertiger App-Server braucht. Nur das es aber Server 2008 ist tut weh. Die meisten Kunden werden keinen Grund sehen zu migriern.

auf DevX gibt es eine kliene übersicht LINK

"Das Problem kennen ist wichtiger, als die Lösung zu finden, denn die genaue Darstellung des Problems führt automatisch zur richtigen Lösung." Albert Einstein

H
154 Beiträge seit 2007
vor 16 Jahren

@LASTGentleman:
versuch mal folgendes:

  • geh zur jobss homepage
  • hohl dir den server runter
  • installier in
  • führ die start bat aus
    -> fertig: er wird laufen.
    dauer: 5min.

zum deployen etc..: einfaches beispiel mit hilfe eines buches, zB das jboss entwicklerheft von o'reilly denke ich mal kriegst du innert tagen was hin. keine monate oder so.
(interface schreiben, seassionbean implementiere, ear builden, deployen fertig, evtl. deskriptoren wenn nicht ejb 3.0)

UND: der thread ist wirklich interessant, ich sollte mir auch gedanken über die neue architektur hier machen. bin deshalb sehr gespannt wo es hingeht....

S
8.746 Beiträge seit 2005
vor 16 Jahren

Jetzt verstehe ich dich wirklich nicht mehr - sorry 🙂. aber, wer app-server selber bauen will, sich um kommunikation, failover, XA etc.. selber kümmern muss[...]

Wer muss, der nimmt einen. Aber was ich wenn ich eine Mittelschicht zwischen DB und Presentation-Layer brauche, aber KEIN Failover, KEINE verteilten Transaktionen, KEIN Clustering, KEIN IIOP oder einfach nur wenig Last habe? Ist dann J2EE immer die beste Lösung? Sicher nicht. Darum ging es. Vielleicht liest du nochmal den von mir geposteten Link zum Thema ("Flow"). Und vielleicht auch ein paar Artikel zum Thema "LAMP vs. J2EE" (und hier geht es nur am Rande um Open Source oder Lizenzkosten). Dieser "Konflikt" ist kein Heise-Getrolle sondern spiegelt recht schön den von mit vermuteten Verlauf fast jeder Technologie dar. Rainis Kritik an der Service Factory geht letztlich in die gleiche Richtung: Mächtige Lösungen aus einem Guß oder lieber Technologie-Ketten.

aber in DIESEM thread geht es ja um app-server. und darum das der kollege einen schreiben will - und ich sage: nimm doch einen.

Ja, es ging um AppServer, aber eben auch um die Frage: Warum hat MS keinen (oder hat ihn doch, aber verteilt über Windows, IIS und COM+) und warum braucht man vielleicht gar keinen (bzw. in welchen Fällen). Oder anders: Ist der monolithische AppServer (in Java ein zwingender Ansatz) eigentlich nur positiv zu bewerten, welche Nachteile ergeben sich und wie sieht die Zukunft in Zeiten von SOA aus? Dort haben Komponentenmodelle ja ausgedient, weil sie nicht die notwendige Uptime liefern. Die Kritik von SOA an Komponenten kommt ja nicht von ungefähr: Das Versprechen über Modellharmonisierung besser zu Integrieren konnte nicht eingelöst werden. Migration ist und bleibt ein Thema und konnte von keiner komponentenbasierten Technologie eingelöst werden. Man kann vermuten, dass J2EE ebentuell den Weg von CORBA gehen wird...

Nur deswegen kommt überhaupt SOA auf, das - rein technisch gesehen eher ein Rückschritt zu sein scheint, aber eben "leichtgewichtig" daherkommt und nur versucht neue Antworten auf die wirklich entscheidenden Fragen zu geben.

B
122 Beiträge seit 2004
vor 16 Jahren

Hallo,

Hat den wer den Artikel gelesen?

http://www.dotnetpro.de/articles/onlinearticle2507.aspx

MFG

H
154 Beiträge seit 2007
vor 16 Jahren

Ja, es ging um AppServer, aber eben auch um die Frage: Warum hat MS keinen (oder hat ihn doch, aber verteilt über Windows, IIS und COM+) und warum braucht man vielleicht gar keinen (bzw. in welchen Fällen). Oder anders: Ist der monolithische AppServer (in Java ein zwingender Ansatz) eigentlich nur positiv zu bewerten, welche Nachteile ergeben sich und wie sieht die Zukunft in Zeiten von SOA aus? Dort haben Komponentenmodelle ja ausgedient, weil sie nicht die notwendige Uptime liefern. Die Kritik von SOA an Komponenten kommt ja nicht von ungefähr: Das Versprechen über Modellharmonisierung besser zu Integrieren konnte nicht eingelöst werden. Migration ist und bleibt ein Thema und konnte von keiner komponentenbasierten Technologie eingelöst werden. Man kann vermuten, dass J2EE ebentuell den Weg von CORBA gehen wird...

Nur deswegen kommt überhaupt SOA auf, das - rein technisch gesehen eher ein Rückschritt zu sein scheint, aber eben "leichtgewichtig" daherkommt und nur versucht neue Antworten auf die wirklich entscheidenden Fragen zu geben.

zugegeben, sun beschreibt beans als software komponenten. in wirklilchkeit lässt sich doch nicht einfacher als mit einem j2ee container eine soa entwickeln.
was ist schon soa? services (sessionbeans) die über eine standardisierte technologie ( jndi), angesprochen werden können, die über einen contract (remote interface) verfügen, und zur laufzeit gebunden werden (container). ok - plattformunabhängig ist
er nicht, wenn man das als zwingendes kirterium für eine soa aufnehmen will.

Klar braucht nicht jeder einen app-server. dass meine ich nicht. aber für ein kleines fibu programm oder eine handwerker auftragsbearbeitungslösung oder ähnliches brauch ich auch kein wcf, wwf, wpf und service factory und und und.
ich glaube schon, dass ms in den highend markt rein will. sonst würden sie ja nicht all die wirklich gelungenen framworks (wwf,wcf,wpf etc...) entwickeln. mir fehlt jetzt nur noch das "Ding" drum-herum welches mir die komplexität wieder reduziert.

S
8.746 Beiträge seit 2005
vor 16 Jahren

plattformunabhängig ist
er nicht, wenn man das als zwingendes kirterium für eine soa aufnehmen will.

Ist es wohl. SOA tritt ja an um heterogene Systeme zu verbinden, und Java ist ja bekanntermaßen auch nur eine Insel. Zudem geht die lose Kopplung bei SOA noch um einiges weiter als nur Entkopplung auf Architekturebene a la Dependy Injection via Container. Der Killer ist die Recompilation bei Schnittstellenänderung (DI adressiert ja nur die Implementierung). Bei SOA sollte man nur das Datenmapping (Konfiguration) umschalten müssen. Das System bleibt up.

Das SOA-Prinzip postuliert: Harmonisierung und Homogenisierung ist gescheitert, flexible Vernetzung ist der neue Heilsbringer (schaun mer mal..). J2EE, Corba und COM schweben als Modell ja tatsächlich eher einige wenige dicke Datenzentren vor. SOA setzt auf kleinere Funktions-Einheiten, deren Vernetzung deutlich flexibler ist (und auch sei muss). Logischweise dezentralisieren sich damit einige Querschnittsaufgaben, anderen bleiben natürlich (Transaktionen).

An der SOA Analyse ist sicher wenig zu zweifeln, der Fokus (und der Mehrwert) hat sich einfach vom Intranet ins Internet verlagert. Homogenität ist dort einfach völlig unrealistisch. Ob die Rezepte von SOA aufgehen, wird die Zukunft zeigen. Man kann nur sicher davon ausgehen, dass die Komplexität wieder mal steigen wird. Man schaue sich nur die Anzahl der WS-* Standards an. Und mit REST steigt wieder mal ein leichtgewichtiger Konkurrent in den Ring, allerdings wohl nur im Customer-Bereich. Dort aber mit aller Macht...

3.728 Beiträge seit 2005
vor 16 Jahren
Hermine

Hat den wer den Artikel gelesen?


>

Der Hermine Server ist kein Applikationsserver, sondern eine Server Anwendung für Wissensmanagement (Link zum Hermine Projekt: http://hermine.sourceforge.net/). Der Autor des von Dir genannten Artikels erklärt anhand des Hermine Servers, wie man mit WCF Server-Anwendungen entwickeln kann.

Ein Applikationsserver soll verhindern, dass man den "Server" der Server-Anwendung für jedes Projekt (wie z.B. das Hermine Projekt) immer neu schreiben muss. Was im Hermine Projekt "hart-codiert" für ein einzelnes Projekt geschrieben wurde, möchte ich als wiederverwendbare Plattform (einen Applikationsserver eben) haben. Eine Server-Anwendung, mit der ich beliebige Dienste betrieben kann, ohne die Basis dafür anfassen zu müssen.

Für WCF kommt ein allgemeiner Host mit Windows Server 2008 (nennt sich dann WAS = Windows Activation Service). Da es aber noch Jahre dauern wird, bis dieser neue Windows-Server auch wirklich bei den Firmen flächendeckend produktiv eingesetzt wird, macht es durchaus noch Sinn, Alternativen zu entwickeln.

B
122 Beiträge seit 2004
vor 16 Jahren

Hallo,

Das wichtigste ist wohl das komplette Userhandling mit Groups Roles usw.

Wie das am besten implementiert und auch überprüft wird.

z.b. das der eine das Lager nur einsehen darf mehr nicht d.h. die Buttons werden ausgeblendet usw.

MFG