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"
xxxprod
myCSharp.de - Experte

Avatar #avatar-2329.gif


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

beantworten | zitieren | melden

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



Dabei seit:
Beiträge: 8.746
Herkunft: Berlin

beantworten | zitieren | melden

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

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3.728
Herkunft: Mauer

Factories

beantworten | zitieren | melden

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



Dabei seit:
Beiträge: 8.746
Herkunft: Berlin

beantworten | zitieren | melden

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



Dabei seit:
Beiträge: 154
Herkunft: Schweiz

beantworten | zitieren | melden

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



Dabei seit:
Beiträge: 8.746
Herkunft: Berlin

beantworten | zitieren | melden

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



Dabei seit:
Beiträge: 154
Herkunft: Schweiz

beantworten | zitieren | melden

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



Dabei seit:
Beiträge: 8.746
Herkunft: Berlin

beantworten | zitieren | melden

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



Dabei seit:
Beiträge: 122

beantworten | zitieren | melden

Auch Ruby on Rails skaliert siehe XING
private Nachricht | Beiträge des Benutzers
HappyLil
myCSharp.de - Member



Dabei seit:
Beiträge: 154
Herkunft: Schweiz

beantworten | zitieren | melden

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

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3.728
Herkunft: Mauer

beantworten | zitieren | melden

Zitat von svenson
Viele Leute wissen nicht, wie sie die Mittelschicht und den Backend trennen und verbinden sollen. Das übernimmt alles die Factory, weil sie dir zumindest ein klares Modell an die Hand gibt, wie die Architektur aussehen kann.
Ich werde mir die Factories doch nochmal genauer ansehen. Der erste oberflächliche Eindruck war nur so ernüchternd.
Zitat von svenson
AppServer hin und her, aber du brauchst u.U. einen WebServer wenn du Web-Clients hast, du musst entscheiden, auf welchen Rechnern die Layer der Anwendung laufen, Clustering, etc.! Der AppServer ist nur ein Teil des Puzzles weil es nur die Mittelschicht adressiert (und sogar davon u.U. nur einen Teil).
Mir ist klar, dass der Applikationsserver nur die Mittelschicht abdeckt. Aber irgendwo muss eben die Mittelschicht laufen. Da liegt bei .NET (trotz WCF) das Problem. Ich will nicht für jedes Projekt einen neuen Host schreiben. WAS (Windows Activation Service) kommt erst mit Windows Server 2008. Wird für mich also noch eine ganze Weile zukunftsmusik bleiben.
Was die Web-Anwendungen angeht, sehe ich da nicht das Problem. Ich kann doch ASP.NET Seiten schreiben, die Dienste meinenes Applikationsservers konsumieren. Das einzige was ich dabei machen muss, ist den Sitzungsschlüssel meiner Applikationsserver-Sitzung in den Sitzungsstatus der Webseite zu schreiben. Wenn Webserver und Applikationsserver auf der selben Maschine laufen, kann ich auch IPC-Kanäle für die Kommunikation verwenden.

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

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3.728
Herkunft: Mauer

beantworten | zitieren | melden

Zitat von HappyLil
Jetzt verstehe ich dich wirklich nicht mehr - sorry :-). aber, wer app-server selber bauen will, sich um kommunikation, failover, XA etc.. selber kümmern muss, DER bring enorme komplexität in seine applikation, DER braucht teure + erfahrene Mitarbeiter. Gerade Deshalb gibts ja die App-Server damit man sich auf die kernaufgabe - das schreiben von Geschäftslogik konzentrieren kann..
Das kann man so nicht sehen. Man muss sich nicht wirklich selber darum kümmern. Das .NET Framework hat für fast alles fertige Lösungen. Diese Lösungen sind aber nicht in einem Applikationsserver integriert.

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

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

Für Persistenz gibts ADO.NET.

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

Avatar #avatar-1696.jpg


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

beantworten | zitieren | melden

Diese Threat ist äußerst interessant.

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

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

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

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

auf DevX gibt es eine kliene übersicht LINK
"Das Problem kennen ist wichtiger, als die Lösung zu finden, denn die genaue Darstellung des Problems führt automatisch zur richtigen Lösung." Albert Einstein
private Nachricht | Beiträge des Benutzers
HappyLil
myCSharp.de - Member



Dabei seit:
Beiträge: 154
Herkunft: Schweiz

beantworten | zitieren | melden

@LASTGentleman:
versuch mal folgendes:

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

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

UND: der thread ist wirklich interessant, ich sollte mir auch gedanken über die neue architektur hier machen. bin deshalb sehr gespannt wo es hingeht....
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von HappyLil am .
private Nachricht | Beiträge des Benutzers
svenson
myCSharp.de - Member



Dabei seit:
Beiträge: 8.746
Herkunft: Berlin

beantworten | zitieren | melden

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

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

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

Nur deswegen kommt überhaupt SOA auf, das - rein technisch gesehen eher ein Rückschritt zu sein scheint, aber eben "leichtgewichtig" daherkommt und nur versucht neue Antworten auf die wirklich entscheidenden Fragen zu geben.
Dieser Beitrag wurde 9 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,

Hat den wer den Artikel gelesen?

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

MFG
private Nachricht | Beiträge des Benutzers
HappyLil
myCSharp.de - Member



Dabei seit:
Beiträge: 154
Herkunft: Schweiz

beantworten | zitieren | melden

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

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

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

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



Dabei seit:
Beiträge: 8.746
Herkunft: Berlin

beantworten | zitieren | melden

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

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

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

An der SOA Analyse ist sicher wenig zu zweifeln, der Fokus (und der Mehrwert) hat sich einfach vom Intranet ins Internet verlagert. Homogenität ist dort einfach völlig unrealistisch. Ob die Rezepte von SOA aufgehen, wird die Zukunft zeigen. Man kann nur sicher davon ausgehen, dass die Komplexität wieder mal steigen wird. Man schaue sich nur die Anzahl der WS-* Standards an. Und mit REST steigt wieder mal ein leichtgewichtiger Konkurrent in den Ring, allerdings wohl nur im Customer-Bereich. Dort aber mit aller Macht...
Dieser Beitrag wurde 5 mal editiert, zum letzten Mal von svenson am .
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3.728
Herkunft: Mauer

Hermine

beantworten | zitieren | melden

Zitat von boonkerz
Hat den wer den Artikel gelesen?

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

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

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



Dabei seit:
Beiträge: 122

beantworten | zitieren | melden

Hallo,

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

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

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

MFG
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3.728
Herkunft: Mauer

Rollenbasierte Sicherheit

beantworten | zitieren | melden

Hallo boonkerz,

Rollenbasierte Sicherheit ist bereits in meinem Applikationsserver integriert. Ich ordne jeder logischen Rolle eine Windows-Sicherheitsgruppe zu. Praktisch dabei ist, dass man die Standard-Windows-Tools (Lokale Benutzer und Gruppen, Active Directory Benutzer und Computer) verwenden kann, um Rollen der Anwendung zu verwalten. Durch die Verwendung des Windows-Sicherheitssystems wird Single-Sign-On an Active Directory automatisch unterstützt.

Es spricht nichts dagegen, die Rollen auch zur (de)Aktivierung von Oberflächenelementen zu verwenden. Bei intensiver Nutzung sollte man die Rollen des Benutzers allerdings clientseitig cachen.
private Nachricht | Beiträge des Benutzers
boonkerz
myCSharp.de - Member



Dabei seit:
Beiträge: 122

beantworten | zitieren | melden

Hallo,

Nun ja ich muß ja die rollen bzw. gruppen im appserver bestimmte Rechte geben. z.b. du darfst kunden anlegen.

Hast du dazu eine idee? einfach uuid der gruppe mit dem recht in der db speichern?
Ich habe mich damit noch nicht so intensiv beschäftigt da es dazu auch irgendwie wenig infos gibt.
Bei mir wird der User in der Anwendung z.b. immer gehalten quasi mit nem singleton. da wäre es ja nun so das mann bei z.b. buttons die disabled eigenschaft per user.hasRole(this.button.id)
die id wäre dann z.b. CustomerAdd oder sowas.

damit könnte mann sein eigenes button control nutzen und hätte immer gleich die rechte verwaltung.
Nur ist das die beste Lösung

MFG
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3.728
Herkunft: Mauer

Rollenprüfungen

beantworten | zitieren | melden

Hallo boonkerz,

Die Rechte machst Du an den logischen Rollen fest (z.B. dürfen alle Benutzer Artikeldaten lesen und anzeigen, die direkt oder indirekt Mitglied der Rolle "Product Reader" sind). Diese logischen Rollen kannst Du als Entwickler frei festlegen und auch im Quellcode hart-codiert verwenden.
In meiner Lösung wird jeder logischen Rolle eine physikalische Windows-Sicherheitsgruppe zugeordnet (In der Datei roles.xml). Alle Windows-Benutzer, die Mitglied dieser zugeordneten Sicherheitsgruppe sind, erhalten damit automatisch die Privillegien der verknüpften logischen Rolle.
Es gibt verschiedene Ansätze, wie man seine Rollen strukturieren kann. Man könnte z.B. auch Akteure aus Anwendungsfällen als Rollen abbilden. Wenn ein Button z.B. nur von Mitarbeitern der Buchhaltungsabteilung gedrückt werden können soll, muss das Formular nur auf die entsprechende Rolle prüfen und das Prüfergebnis der Enabled-Eigenschaft des Buttons zuweisen.

Wenn Rollen aus irgendeinem Grund zu grobkörnig sind, muss man statt dessen ACLs (Access Control Lists) verwenden (Wie das NTFS-Dateisystem). Aber auch dafpr gibt es fertige Klassen im .NET Framework 2.0.
private Nachricht | Beiträge des Benutzers
boonkerz
myCSharp.de - Member



Dabei seit:
Beiträge: 122

beantworten | zitieren | melden

Hallo,

Jup nur genau für sowas gibts keine Beispiele z.b. wie ich Forms möglichst flexibel mache damit ich nicht in jedem Form jeden Button anfassen muß.

Na mal sehen werde ich mir mal was ausdenken

MFG
private Nachricht | Beiträge des Benutzers
da5id_
myCSharp.de - Member



Dabei seit:
Beiträge: 2
Herkunft: Düsseldorf

AppServer

beantworten | zitieren | melden

Hi Rainbird,

ich habe mir den AppServer angesehen.
Es gibt einige Fragen, die ich habe, vielleicht kannst (oder magst) Du sie mir beantworten

1. Warum wird die Kommunikation der Daten über DataSets gehandhabt? Wäre eine generische Schnittstelle, die den tatsächlichen Träger der Daten "versteckt" nicht eine bessere Variante?->SOAP o. Generics Interfaces?
2. Du hast einige Komponente "BusinessLogic" genannt, wenn ich es richtig interpretiere, garantieren diese Komponenten die Datenkonsistenz der zu schreibenden Daten. Ich hatte mit letzterem ein Objektmodell assoziiert. Den BusinessLayer schreibe ich eher höhere Funktionen zu, z.B. Abarbeitung von Rechenprozessen, etc.
3. In Deinem Code gibt es mehrere Stellen, die generiert wurden. Mit welchem Tool machst Du das?

Da5id

P.S.: Für mich ein sehr hilfreiches Sample, da ich gerade eine FatClient-basierte Software in eine multi-tier software umbauen muß.
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3.728
Herkunft: Mauer

beantworten | zitieren | melden

Hallo da5id_,

gerne will ich Deine Fragen beantworten.
Zitat von da5id_
1. Warum wird die Kommunikation der Daten über DataSets gehandhabt? Wäre eine generische Schnittstelle, die den tatsächlichen Träger der Daten "versteckt" nicht eine bessere Variante?->SOAP o. Generics Interfaces?
Ich verstehe die Frage nicht richtig. DataSets sind Datentransferobjekte (DTOs) und SOAP ist ein XML-basiertes Kommunikationsprotokoll um entfernte Methodenaufrufe und Datenübertragung. Die Frage ist also nicht SOAP oder DataSets, sondern SOAP (meistens HTTP + XML) oder Binärer Datenstrom. Für Anwendungen die im LAN laufen, hat SOAP zu viel Protokoll-Overhead und ist damit unnötig langsam. Hinzu kommt, dass keine vernünftige Authentifizierung über SOAP möglich ist. Dazu müsste man wieder WS-* Protokolle implementieren und wäre damit bei WCF. WS-* würde bei einer abgeschlossenen n-Tier-Anwendung aber keinen Sinn machen. SOAP ist okay bei Datenübertragung übers Internet und für Anwendungen, die plattformübergreifend Kommunizieren müssen. Auch wenn momantan viel über Webservices, SOAP, SOA und EAI geredet wird, sind diese Kriterien für viele Anwendungen gar nicht relevant. Wenn ich Interoperabilität bei meiner Lösung haben will/muss, würde ich einen C#-Webservice schreiben, der die DataSets entsprechend aufbereitet und die Kommunikation nach außen kapselt.

Ich verwende schnelle binäre aber properitäre Kommunikation. Alle Aufrufe werden verschlüsselt und es wird Windows-Authentifizierung eingesetzt. Deshalb unterstützt die Lösung in einer Active Directory-Umgebung standardmäßig Single-Sign-On.
Zitat von da5id_
2. Du hast einige Komponente "BusinessLogic" genannt, wenn ich es richtig interpretiere, garantieren diese Komponenten die Datenkonsistenz der zu schreibenden Daten. Ich hatte mit letzterem ein Objektmodell assoziiert. Den BusinessLayer schreibe ich eher höhere Funktionen zu, z.B. Abarbeitung von Rechenprozessen, etc.
Ich werde bald eine neue Version des Beispielprojekt veröffentlichen, welche zusätzlich zur Artikelverwaltung noch eine Lagerverwaltung enthält. Dort wird dann die gesamte Buchungslogik in den Geschäftskomponenten liegen. Beim Artikelstamm gibt es leider keine Rechenprozesse. Da werden lediglich Stammdaten angelegt, die von anderen Modulen (z.B. der Lagerverwaltung) verwendet werden können. Wenn es in der Artikelverwaltung Rechenprozesse etc. geben würde, wären diese natülich auch in der BusinessLogic implementiert.
Zitat von da5id_
3. In Deinem Code gibt es mehrere Stellen, die generiert wurden. Mit welchem Tool machst Du das?
Was meisnt Du? Ich habe ein Visual Studio 2005 Standard Edition und einen SQL Server 2005 Express Edition für die Entwicklung eingesetzt. Sonst nichts.
private Nachricht | Beiträge des Benutzers
da5id_
myCSharp.de - Member



Dabei seit:
Beiträge: 2
Herkunft: Düsseldorf

beantworten | zitieren | melden

Hi,

Bei 1. mir ging es um eine Abstraktion der Kommunikation möglichst ohne .Net Objekte, da meine Firma plant, weitläufig multiplattform Unterstützung zu gewährleisten, -> Java. Ein Großteil der UI auf dem Client wird weiterhin auf .net basieren. Dementsprechend wäre SOAP eine Alternative. DataTables werden nicht mehr möglich sein. Gibt es noch eine andere Alternative?

Vergiß 3. hab mich verguckt.

Freu mich schon auf den erweiterten Business Layer :-)

da5id
private Nachricht | Beiträge des Benutzers
xxxprod
myCSharp.de - Experte

Avatar #avatar-2329.gif


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

beantworten | zitieren | melden

Hallo Rainbird,

ich habe mir jetzt etwas Zeit genommen mich durch die Klassen und Methoden durchzuarbeiten um deren Bedeutung zu verstehen und muss zugeben das ich sehr begeistert bin

In der kürze, habe ich bestimmt nicht alle rafinessen entdeckt, die du hier eingebaut hast.
Stellen die mir extrem gut gefallen haben sind die ServiceFactory(einfach das Prinzip wie die Services generisch zur Verfügung gestellt werden) und darüber hinaus die DataAcces Klasse.(Vermutlich ist das alles nicht soooo besonders, aber wenn ich das mit meiner bisherigen Programmierweise vergleiche ein Traum )

Der Umgang mit dem CallContext gefällt mir auch sehr gut und habe ich mir bereits in meiner aktuellen Applikation abgeschaut.

Ein wenig verwirrend finde ich das SecurityService und dort speziell die Logon und IsTrustWorthy Methoden(oder statt verwirrend einfach nur unübersichtlich?).

Hätte sich für die Log funktionen nicht AOP angeboten? (Habe damit aber keinerlei Erfahrung)

Alles in allem find ich das Projekt sehr gelungen. Ich müsst jedoch ähnliches selbst nachprogrammieren, um es wirklich ins blut einfließen zu lassen.

Lg XXX
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von xxxprod am .
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3.728
Herkunft: Mauer

beantworten | zitieren | melden

Zitat von da5id_
... mir ging es um eine Abstraktion der Kommunikation möglichst ohne .Net Objekte, da meine Firma plant, weitläufig multiplattform Unterstützung zu gewährleisten, -> Java.... ...Gibt es noch eine andere Alternative?
Wenn Du wirklich plattformneutral sein willst, dann verwende überhaupt keine Objekte, sondern arbeite mit XML-Dokumenten. Mittels DOM, XPath, XQuery und XSLT kannst Du damit sehr komfortabel arbeiten und bist um Welten flexibler als mit Objekten. XLST verwandelt ein XML-Dokument außerdem im handumdrehen in ein schönes HTML oder PDF-Dokument. Oder auch in die Datenstruktur einer anderen Anwendung.
SOAP wird zwar immer an erster Stelle genannt, wenn es um Interoperabilität geht, aber in der Praxis gibt es viele Probleme. SOAP ist nicht gleich SOAP. Man kann z.B. dokumentorientiert arbeiten oder klassisch entfernte Methoden aufrufen.

Es gibt aber sehr gute Alternativen zu SOAP. Da wären z.B. die sogenannten REST-Webservices. Das ist direkte XML-Kommunikation über HTTP. Da XML-Dokumente sowieso selbstbeschreibend sind, braucht REST weder aufwändige Header, noch Metadaten. Client und Server kommunizieren über XML-Dokumente. Mittels XML-Schemas kann jede Seite prüfen, ob eine Anfrage oder ein Ergebnis auch valide ist. REST ist auch sehr Firewall freundlich und absolut plattformneutral. Alles was Bytes über HTTP senden und empfangen kann, ist in der Lage mit REST-Webdiensten zu kommunizieren. Details zu REST und ein Vergleich mit SOAP findest Du hier: http://www.oio.de/public/xml/rest-webservices.htm

Ich mag es gerne einfach, leichtgewichtig aber trotzdem leistungsfähig. Deshalb würde ich in REST den Vorzug geben. SOAP ist in meinem Augen ein komplizierter Krempel.
Zitat von xxxprod
Ein wenig verwirrend finde ich das SecurityService und dort speziell die Logon und IsTrustWorthy Methoden(oder statt verwirrend einfach nur unübersichtlich?).
Diese Funktionen sind deshalb etwas aufwändiger, da sie außer der Authentifizierung die komplette Sitzungsverwaltung implementieren. Ich habe auf Performanz Wert gelegt. Deshalb werden Sitzungen nach erfolgreicher Anmeldung gecached. Die Sitzungen sind nur für eine bestimmte Zeit lang gültig (Über App.config einstellbar). Während dieser Zeit vertraut der Applikationsserver dem aufrufenden Client, wenn er den korrekten Sitzungsschlüssel im Aufrufkontext mitführt. Ist die Sitzung aber abgelaufen, muss die Identität des Aufrufers erneut überprüft werden. Durch diesen Sitzungs-Cache muss die Identitätsprüfung nicht bei jedem Aufruf, sondern nur alle paar Minuten, durchgeführt werden. Aufrufe mit gültiger Sitzung werden praktisch "durchgewunken" und müssen nicht jedesmal den vollen Sicherheitscheck machen. Trotzdem ist das System sehr sicher (wenn man die Sitzungslebensdauer nicht zu lang einstellt), da ein Angreifer nur wenige Minuten Zeit hat, um eine Sitzung zu kapern und sich damit Rechte zu erschleichen. Das dürfte von Außen aber sehr schwer sein, da der Remoting TCP-Kanal alles verschlüsselt überträgt. Wenn beide Computer Teil einer Active Directory-Domäne sind, wird automatisch Kerberos verwendet, was nicht nur die Identität des Benutzers, sondern auch noch die des jeweils anderen Computers prüft.
Wenn die volle Identitätsprüfung bei jedem Aufruf einer Dienstmethode erfolgen müsste, würde das bei vielen Aufrufen die Leistung sehr negativ beeinträchtigen. Deshalb der Sitzungs-Cache.
Für das was der Sicherheitsdienst alles tut, finde ich nicht, dass es viel Code ist.

In der Anwendung ist die Sache auch einfach. Ein Dienst kann seinen Host (also den Applikationsserver) jederzeit Fragen, ob der aufrufende Client denn auch wirkich vertrauenswürdig ist. Wenn der aufrufende Client eine gültige Sitzung hat, oder seine abgelaufene Sitzung im Zuge der Vertrauenswürdingskeitsprüfung erneuert werden konnte, ist er vertrauenswürdig. Hat er keine Sitzung (wenn ein Client z.B. versucht einen Dienst zu konsumieren, ohne sich vorher per Logon am Applikationsserver des Dienstes anzumelden) oder seine abglaufene Sitzung wurde nicht erfolgreich erneuert wurde (weil er z.B. plötzlich nicht mehr korrekt vom Betriebssystem authentifiziert werden konnte und er in Wirklichkeit ein ganz schlimmer Finger ist), ist der Client nicht vertrauenswürdig. IsTrustworthy ist der Grundpfeiler der Sicherheit des Systems.

Wenn man nicht nur prüfen will, ob ein Aufrufer grundsätzlich vertrauenswürdig ist, sonder auch gleich wissen will, ob er einen VIP-Ausweis für die Backstage-Zone hat, verwendet mann statt IsTrustworthy die Methode IsInRole("Rolle"). IsInRole prüft automatisch ob er vertrauenswürdig ist. Wenn ja, wird erst der Rollenprüfung durchgeführt. Da ausschließlich das Windows-Sicherheitssystem zum Einsatz kommt, werden die Logischen Rollen auf Windows-Sicherheitsgruppen gemappt. Die Rollenprüfung wird so einfach auf das Betriebssystem abgewälzt. Das ist auch gut so, denn eine Gruppe kann ja wieder Mitglied einer anderen Gruppe sein. Windows führt diese Rollenprüfungen sehr schnell und zuverlässig durch. Die Applikationsserver-API muss die logischen Rollennamen, welche hart-codiert im Code verwendet werden (z.B. "Product Reader") in die passenden Windows-Gruppen auflösen. Der Applikationsserver verwendet - so vorhanden - automatisch Active Directory für die Rollenbasierte Sicherheit. Single-Sign-On frei Haus!
Selbst wenn der Client eine ASP.NET Webseite ist, klappt das im Intranet super, da die ASP.NET-Seite impersonieren kann.

Ist die Funktion von Logon und IsThrustworthy nun etwas verständlicher?

Was das Logging angeht, wollte ich auch bei den .NET 2.0 Bordmitteln bleiben. Natürlich könnte man Logging und Transaktionalität als Aspekte implementieren. Aber eben nicht mit den Bordmitteln. Da müsste man schon PostSharp o.ä. einsetzen.
private Nachricht | Beiträge des Benutzers
Tokka
myCSharp.de - Member



Dabei seit:
Beiträge: 108
Herkunft: Hamburg

beantworten | zitieren | melden

Hi Rainbird!

An dieser Stelle noch mal ein große Dankeschön!!

Ich habe anhand deines Beispiels mal angefangen eine Anwendung zu erstellen. Es hilft mir sehr, immer wieder bei Dir "nachzusehen", wie Du das ein oder andere gelöst hast.

Freue mich schon, auf die von Dir gennanten Erweiterugen
Was einmal war, wird nie wieder sein...
private Nachricht | Beiträge des Benutzers