myCSharp.de - DIE C# und .NET Community
Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 
 | Suche | FAQ

» Hauptmenü
myCSharp.de
» Startseite
» Forum
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Suche
» Regeln
» Wie poste ich richtig?
» Forum-FAQ

Mitglieder
» Liste / Suche
» Wer ist wo online?

Ressourcen
» openbook: Visual C#
» openbook: OO
» Microsoft Docs

Team
» Kontakt
» Übersicht
» Wir über uns

» myCSharp.de Diskussionsforum
Du befindest Dich hier: Community-Index » Diskussionsforum » Entwicklung » Rund um die Programmierung » Fragen, Diskussion, Kritik zu Projekt ".NET Applikationsserver"
Letzter Beitrag | Erster ungelesener Beitrag Druckvorschau | Thema zu Favoriten hinzufügen

Seiten (5): [1] 2 3 4 5 nächste » Antwort erstellen
Zum Ende der Seite springen  

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

 
Autor
Beitrag « Vorheriges Thema | Nächstes Thema »
wdb.lizardking wdb.lizardking ist männlich
myCSharp.de-Mitglied

avatar-2010.jpg


Dabei seit: 28.08.2006
Beiträge: 100
Entwicklungsumgebung: Visual Studio .NET 2008
Herkunft: Niederbayern


wdb.lizardking ist offline Füge wdb.lizardking Deiner Kontaktliste hinzu

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

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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? smile
20.12.2007 08:53 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Rainbird Rainbird ist männlich
myCSharp.de-Poweruser/ Experte

avatar-2834.jpg


Dabei seit: 28.05.2005
Beiträge: 3.723
Entwicklungsumgebung: Visual Studio 2012
Herkunft: Mauer


Rainbird ist offline

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

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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.
20.12.2007 19:27 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
xxxprod xxxprod ist männlich
myCSharp.de-Poweruser/ Experte

avatar-2329.gif


Dabei seit: 13.04.2006
Beiträge: 1.375
Herkunft: Österreich\Wien


xxxprod ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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

C#-Code:
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?
20.12.2007 23:16 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Rainbird Rainbird ist männlich
myCSharp.de-Poweruser/ Experte

avatar-2834.jpg


Dabei seit: 28.05.2005
Beiträge: 3.723
Entwicklungsumgebung: Visual Studio 2012
Herkunft: Mauer


Rainbird ist offline

Abhängigkeiten

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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.

C#-Code:
// 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.

C#-Code:
// 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).
21.12.2007 01:23 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
xxxprod xxxprod ist männlich
myCSharp.de-Poweruser/ Experte

avatar-2329.gif


Dabei seit: 13.04.2006
Beiträge: 1.375
Herkunft: Österreich\Wien


xxxprod ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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
21.12.2007 11:25 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Rainbird Rainbird ist männlich
myCSharp.de-Poweruser/ Experte

avatar-2834.jpg


Dabei seit: 28.05.2005
Beiträge: 3.723
Entwicklungsumgebung: Visual Studio 2012
Herkunft: Mauer


Rainbird ist offline

Remoting erweitern

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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/asptodayarch...t-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.
21.12.2007 13:38 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
xxxprod xxxprod ist männlich
myCSharp.de-Poweruser/ Experte

avatar-2329.gif


Dabei seit: 13.04.2006
Beiträge: 1.375
Herkunft: Österreich\Wien


xxxprod ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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
21.12.2007 14:05 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Rainbird Rainbird ist männlich
myCSharp.de-Poweruser/ Experte

avatar-2834.jpg


Dabei seit: 28.05.2005
Beiträge: 3.723
Entwicklungsumgebung: Visual Studio 2012
Herkunft: Mauer


Rainbird ist offline

Client/Server

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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.
21.12.2007 14:30 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
xxxprod xxxprod ist männlich
myCSharp.de-Poweruser/ Experte

avatar-2329.gif


Dabei seit: 13.04.2006
Beiträge: 1.375
Herkunft: Österreich\Wien


xxxprod ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Vielleicht wird später eh ein anderes Lizenzmodell angewendet. Zur Zeit jedoch meine Chefs diese Variante für am sinnvollsten.
21.12.2007 16:20 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Rainbird Rainbird ist männlich
myCSharp.de-Poweruser/ Experte

avatar-2834.jpg


Dabei seit: 28.05.2005
Beiträge: 3.723
Entwicklungsumgebung: Visual Studio 2012
Herkunft: Mauer


Rainbird ist offline

Download

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Die n-Tier Beispiel-Projektmappe steht ab jetzt unter  .NET Applikationsserver zum Download bereit.
24.12.2007 01:51 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Tokka Tokka ist männlich
myCSharp.de-Mitglied

Dabei seit: 20.04.2005
Beiträge: 108
Entwicklungsumgebung: VS 2010
Herkunft: Hamburg


Tokka ist offline Füge Tokka Deiner Kontaktliste hinzu

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Vielen Dank Rainbird!

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


Danke smile

Gruß & guten Rutsch
26.12.2007 18:08 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
nitronic nitronic ist männlich
myCSharp.de-Mitglied

avatar-1597.jpg


Dabei seit: 14.03.2004
Beiträge: 354
Entwicklungsumgebung: VS 2008 / 2005 / Eclipse
Herkunft: Österreich


nitronic ist offline Füge nitronic Deiner Kontaktliste hinzu MSN-Passport-Profil von nitronic anzeigen

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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.
27.12.2007 21:09 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Rainbird Rainbird ist männlich
myCSharp.de-Poweruser/ Experte

avatar-2834.jpg


Dabei seit: 28.05.2005
Beiträge: 3.723
Entwicklungsumgebung: Visual Studio 2012
Herkunft: Mauer


Rainbird ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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 Augenzwinkern .
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.
28.12.2007 11:15 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
LastGentleman LastGentleman ist männlich
myCSharp.de-Mitglied

avatar-1696.jpg


Dabei seit: 13.03.2005
Beiträge: 1.274
Entwicklungsumgebung: VS 2017/2019, MS Access
Herkunft: Österreich


LastGentleman ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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
28.12.2007 11:52 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
nitronic nitronic ist männlich
myCSharp.de-Mitglied

avatar-1597.jpg


Dabei seit: 14.03.2004
Beiträge: 354
Entwicklungsumgebung: VS 2008 / 2005 / Eclipse
Herkunft: Österreich


nitronic ist offline Füge nitronic Deiner Kontaktliste hinzu MSN-Passport-Profil von nitronic anzeigen

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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 Augenzwinkern .
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.
28.12.2007 12:05 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Rainbird Rainbird ist männlich
myCSharp.de-Poweruser/ Experte

avatar-2834.jpg


Dabei seit: 28.05.2005
Beiträge: 3.723
Entwicklungsumgebung: Visual Studio 2012
Herkunft: Mauer


Rainbird ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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?
28.12.2007 13:21 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
LastGentleman LastGentleman ist männlich
myCSharp.de-Mitglied

avatar-1696.jpg


Dabei seit: 13.03.2005
Beiträge: 1.274
Entwicklungsumgebung: VS 2017/2019, MS Access
Herkunft: Österreich


LastGentleman ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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
28.12.2007 14:07 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
nitronic nitronic ist männlich
myCSharp.de-Mitglied

avatar-1597.jpg


Dabei seit: 14.03.2004
Beiträge: 354
Entwicklungsumgebung: VS 2008 / 2005 / Eclipse
Herkunft: Österreich


nitronic ist offline Füge nitronic Deiner Kontaktliste hinzu MSN-Passport-Profil von nitronic anzeigen

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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).
28.12.2007 14:26 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Rainbird Rainbird ist männlich
myCSharp.de-Poweruser/ Experte

avatar-2834.jpg


Dabei seit: 28.05.2005
Beiträge: 3.723
Entwicklungsumgebung: Visual Studio 2012
Herkunft: Mauer


Rainbird ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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.

Rainbird hat dieses Bild (verkleinerte Version) angehängt:
trace.png
Volle Bildgröße

28.12.2007 15:01 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Rainbird Rainbird ist männlich
myCSharp.de-Poweruser/ Experte

avatar-2834.jpg


Dabei seit: 28.05.2005
Beiträge: 3.723
Entwicklungsumgebung: Visual Studio 2012
Herkunft: Mauer


Rainbird ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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 großes Grinsen . 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.
28.12.2007 15:26 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
HappyLil HappyLil ist männlich
myCSharp.de-Mitglied

Dabei seit: 03.07.2007
Beiträge: 154
Entwicklungsumgebung: VisualStudio2012
Herkunft: Schweiz


HappyLil ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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 03.01.2008 10:13.

03.01.2008 10:00 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Rainbird Rainbird ist männlich
myCSharp.de-Poweruser/ Experte

avatar-2834.jpg


Dabei seit: 28.05.2005
Beiträge: 3.723
Entwicklungsumgebung: Visual Studio 2012
Herkunft: Mauer


Rainbird ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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?
03.01.2008 18:28 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
boonkerz boonkerz ist männlich
myCSharp.de-Mitglied

Dabei seit: 02.01.2004
Beiträge: 122


boonkerz ist offline Füge boonkerz Deiner Kontaktliste hinzu

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Hallo,

Ich arbeite zur Zeit so:

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

Wobei bei Standartabfragen getyped wird smile

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
03.01.2008 22:54 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
svenson svenson ist männlich
myCSharp.de-Mitglied

Dabei seit: 15.04.2005
Beiträge: 8.746
Entwicklungsumgebung: Visual Studio .NET 2003
Herkunft: Berlin


svenson ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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. Augenzwinkern

Dieser Beitrag wurde 3 mal editiert, zum letzten Mal von svenson am 03.01.2008 23:28.

03.01.2008 23:21 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
boonkerz boonkerz ist männlich
myCSharp.de-Mitglied

Dabei seit: 02.01.2004
Beiträge: 122


boonkerz ist offline Füge boonkerz Deiner Kontaktliste hinzu

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Dinnernow und Stocktrader gibts
03.01.2008 23:28 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
svenson svenson ist männlich
myCSharp.de-Mitglied

Dabei seit: 15.04.2005
Beiträge: 8.746
Entwicklungsumgebung: Visual Studio .NET 2003
Herkunft: Berlin


svenson ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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 03.01.2008 23:29.

03.01.2008 23:29 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
boonkerz boonkerz ist männlich
myCSharp.de-Mitglied

Dabei seit: 02.01.2004
Beiträge: 122


boonkerz ist offline Füge boonkerz Deiner Kontaktliste hinzu

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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 smile
 http://www.mayflower.de/content/content2...wsID=73&lang=de

MFG

Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von boonkerz am 03.01.2008 23:42.

03.01.2008 23:41 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
svenson svenson ist männlich
myCSharp.de-Mitglied

Dabei seit: 15.04.2005
Beiträge: 8.746
Entwicklungsumgebung: Visual Studio .NET 2003
Herkunft: Berlin


svenson ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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. Augenzwinkern

Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von svenson am 03.01.2008 23:56.

03.01.2008 23:45 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
HappyLil HappyLil ist männlich
myCSharp.de-Mitglied

Dabei seit: 03.07.2007
Beiträge: 154
Entwicklungsumgebung: VisualStudio2012
Herkunft: Schweiz


HappyLil ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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 04.01.2008 09:35.

04.01.2008 09:24 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Rainbird Rainbird ist männlich
myCSharp.de-Poweruser/ Experte

avatar-2834.jpg


Dabei seit: 28.05.2005
Beiträge: 3.723
Entwicklungsumgebung: Visual Studio 2012
Herkunft: Mauer


Rainbird ist offline

Schwergewichte

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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. Augenzwinkern

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)?
04.01.2008 11:08 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
xxxprod xxxprod ist männlich
myCSharp.de-Poweruser/ Experte

avatar-2329.gif


Dabei seit: 13.04.2006
Beiträge: 1.375
Herkunft: Österreich\Wien


xxxprod ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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
04.01.2008 11:33 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
svenson svenson ist männlich
myCSharp.de-Mitglied

Dabei seit: 15.04.2005
Beiträge: 8.746
Entwicklungsumgebung: Visual Studio .NET 2003
Herkunft: Berlin


svenson ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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.

Zitat:
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.

Dieser Beitrag wurde 3 mal editiert, zum letzten Mal von svenson am 04.01.2008 12:32.

04.01.2008 12:18 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Rainbird Rainbird ist männlich
myCSharp.de-Poweruser/ Experte

avatar-2834.jpg


Dabei seit: 28.05.2005
Beiträge: 3.723
Entwicklungsumgebung: Visual Studio 2012
Herkunft: Mauer


Rainbird ist offline

Factories

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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.
04.01.2008 12:43 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
svenson svenson ist männlich
myCSharp.de-Mitglied

Dabei seit: 15.04.2005
Beiträge: 8.746
Entwicklungsumgebung: Visual Studio .NET 2003
Herkunft: Berlin


svenson ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Zitat von Rainbird:
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).

Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von svenson am 04.01.2008 13:01.

04.01.2008 12:58 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
HappyLil HappyLil ist männlich
myCSharp.de-Mitglied

Dabei seit: 03.07.2007
Beiträge: 154
Entwicklungsumgebung: VisualStudio2012
Herkunft: Schweiz


HappyLil ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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.
04.01.2008 13:01 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
svenson svenson ist männlich
myCSharp.de-Mitglied

Dabei seit: 15.04.2005
Beiträge: 8.746
Entwicklungsumgebung: Visual Studio .NET 2003
Herkunft: Berlin


svenson ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Zitat von HappyLil:
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.

Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von svenson am 04.01.2008 13:09.

04.01.2008 13:08 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
HappyLil HappyLil ist männlich
myCSharp.de-Mitglied

Dabei seit: 03.07.2007
Beiträge: 154
Entwicklungsumgebung: VisualStudio2012
Herkunft: Schweiz


HappyLil ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Zitat von svenson:
Zitat von HappyLil:
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.
04.01.2008 13:31 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
svenson svenson ist männlich
myCSharp.de-Mitglied

Dabei seit: 15.04.2005
Beiträge: 8.746
Entwicklungsumgebung: Visual Studio .NET 2003
Herkunft: Berlin


svenson ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Zitat von HappyLil:
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.

Zitat:
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.

Dieser Beitrag wurde 3 mal editiert, zum letzten Mal von svenson am 04.01.2008 14:40.

04.01.2008 14:22 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
boonkerz boonkerz ist männlich
myCSharp.de-Mitglied

Dabei seit: 02.01.2004
Beiträge: 122


boonkerz ist offline Füge boonkerz Deiner Kontaktliste hinzu

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Auch Ruby on Rails skaliert siehe XING
04.01.2008 14:32 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
HappyLil HappyLil ist männlich
myCSharp.de-Mitglied

Dabei seit: 03.07.2007
Beiträge: 154
Entwicklungsumgebung: VisualStudio2012
Herkunft: Schweiz


HappyLil ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Zitat:
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.

Zitat:
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.
04.01.2008 15:39 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Seiten (5): [1] 2 3 4 5 nächste » Baumstruktur | Brettstruktur       | Top 
myCSharp.de | Forum Der Startbeitrag ist älter als 12 Jahre.
Der letzte Beitrag ist älter als 5 Jahre.
Antwort erstellen


© Copyright 2003-2020 myCSharp.de-Team | Impressum | Datenschutz | Alle Rechte vorbehalten. | Dieses Portal verwendet zum korrekten Betrieb Cookies. 15.08.2020 18:40