Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
Fragen, Diskussion, Kritik zu Projekt ".NET Applikationsserver"
wdb.lizardking
myCSharp.de - Member

Avatar #avatar-2010.jpg


Dabei seit:
Beiträge: 100
Herkunft: Niederbayern

Themenstarter:

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

beantworten | zitieren | melden

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?
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

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

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
xxxprod
myCSharp.de - Experte

Avatar #avatar-2329.gif


Dabei seit:
Beiträge: 1420
Herkunft: Österreich\Wien

beantworten | zitieren | melden

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?
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Abhängigkeiten

beantworten | zitieren | melden

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).
private Nachricht | Beiträge des Benutzers
xxxprod
myCSharp.de - Experte

Avatar #avatar-2329.gif


Dabei seit:
Beiträge: 1420
Herkunft: Österreich\Wien

beantworten | zitieren | melden

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
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Remoting erweitern

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
xxxprod
myCSharp.de - Experte

Avatar #avatar-2329.gif


Dabei seit:
Beiträge: 1420
Herkunft: Österreich\Wien

beantworten | zitieren | melden

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
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Client/Server

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
xxxprod
myCSharp.de - Experte

Avatar #avatar-2329.gif


Dabei seit:
Beiträge: 1420
Herkunft: Österreich\Wien

beantworten | zitieren | melden

Vielleicht wird später eh ein anderes Lizenzmodell angewendet. Zur Zeit jedoch meine Chefs diese Variante für am sinnvollsten.
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Download

beantworten | zitieren | melden

Die n-Tier Beispiel-Projektmappe steht ab jetzt unter .NET Applikationsserver zum Download bereit.
private Nachricht | Beiträge des Benutzers
Tokka
myCSharp.de - Member



Dabei seit:
Beiträge: 108
Herkunft: Hamburg

beantworten | zitieren | melden

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...
private Nachricht | Beiträge des Benutzers
nitronic
myCSharp.de - Member

Avatar #avatar-1597.jpg


Dabei seit:
Beiträge: 354
Herkunft: Österreich

beantworten | zitieren | melden

Zitat von Rainbird
angeregt durch Objektorientierte Datenzugriffsschicht, 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
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
LastGentleman
myCSharp.de - Member

Avatar #avatar-1696.jpg


Dabei seit:
Beiträge: 1274
Herkunft: Österreich

beantworten | zitieren | melden

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
private Nachricht | Beiträge des Benutzers
nitronic
myCSharp.de - Member

Avatar #avatar-1597.jpg


Dabei seit:
Beiträge: 354
Herkunft: Österreich

beantworten | zitieren | melden

Zitat von Rainbird
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.
Zitat von Rainbird
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.
Zitat von Rainbird
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).
Zitat von Rainbird
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
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

beantworten | zitieren | melden

Zitat von LastGentleman
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.
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).
Zitat von LastGentleman
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.
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.
Zitat von LastGentleman
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.
Zitat von nitronic
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?
private Nachricht | Beiträge des Benutzers
LastGentleman
myCSharp.de - Member

Avatar #avatar-1696.jpg


Dabei seit:
Beiträge: 1274
Herkunft: Österreich

beantworten | zitieren | melden

Zitat
Zitat
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.
Zitat
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
private Nachricht | Beiträge des Benutzers
nitronic
myCSharp.de - Member

Avatar #avatar-1597.jpg


Dabei seit:
Beiträge: 354
Herkunft: Österreich

beantworten | zitieren | melden

Zitat von Rainbird
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
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

beantworten | zitieren | melden

Zitat von LastGentleman
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.
Zitat von LastGentleman
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.
Zitat von LastGentleman

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.
Attachments
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

beantworten | zitieren | melden

Zitat von nitronic
Eher nicht öffentlich im Thread.
Okay. Das respektiere ich natürlich.
Zitat von nitronic
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 :D. 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.
Zitat von nitronic
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.
private Nachricht | Beiträge des Benutzers
HappyLil
myCSharp.de - Member



Dabei seit:
Beiträge: 159
Herkunft: Schweiz

beantworten | zitieren | melden

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.
Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von HappyLil am .
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

beantworten | zitieren | melden

Zitat von HappyLil
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?
private Nachricht | Beiträge des Benutzers
boonkerz
myCSharp.de - Member



Dabei seit:
Beiträge: 122

beantworten | zitieren | melden

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
private Nachricht | Beiträge des Benutzers
svenson
myCSharp.de - Member



Dabei seit:
Beiträge: 8775
Herkunft: Berlin

beantworten | zitieren | melden

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.
Dieser Beitrag wurde 3 mal editiert, zum letzten Mal von svenson am .
private Nachricht | Beiträge des Benutzers
boonkerz
myCSharp.de - Member



Dabei seit:
Beiträge: 122

beantworten | zitieren | melden

Dinnernow und Stocktrader gibts
private Nachricht | Beiträge des Benutzers
svenson
myCSharp.de - Member



Dabei seit:
Beiträge: 8775
Herkunft: Berlin

beantworten | zitieren | melden

Ich rede von echten Anwendungen wie Kreditkartenabrechnungssysteme und ähnliches. Millionen Clients, Serverfarmen, etc.!
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von svenson am .
private Nachricht | Beiträge des Benutzers
boonkerz
myCSharp.de - Member



Dabei seit:
Beiträge: 122

beantworten | zitieren | melden

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
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von boonkerz am .
private Nachricht | Beiträge des Benutzers
svenson
myCSharp.de - Member



Dabei seit:
Beiträge: 8775
Herkunft: Berlin

beantworten | zitieren | melden

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.
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von svenson am .
private Nachricht | Beiträge des Benutzers
HappyLil
myCSharp.de - Member



Dabei seit:
Beiträge: 159
Herkunft: Schweiz

beantworten | zitieren | melden

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
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von HappyLil am .
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Schwergewichte

beantworten | zitieren | melden

Zitat von svenson
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)?
private Nachricht | Beiträge des Benutzers