Hallo Experten,

ich versuche gerade unsere VS6.0 Anwendung auf VS.net 2008 umzuschreiben, und {habe aktuell|werde in naher Zukunft immer wieder} ein paar Dinge die ich noch nicht recht verstanden habe.

Umfeld: VS.net 2008 pro, C#, MS SQL 2005. Verteilte Anwendung, Frontend (C# Windows Programm) läuft an vielen Standorten, Backend läuft an einem zentralen Rechner. Dazwischen liegt eine C# Middleware. Physisches drei Schichten Modell, also Mitarbeiter PC, Middleware Server und Datenbankserver sind drei verschiedene Rechner.

Für die Übertragung von EDI Dateien zu den Kundenservern habe ich einen Windows Dienst geschrieben, der von der Datenbank Informationen über die zu versendenden Dateien holt und diese dann per FTP versendet.

1) Ich habe es nicht geschafft, diesen Dienst als Teil der Solution unterzubringen. Ist es korrekt dass einzelne Projekte einer Solution nicht Dienste sein können, wenn die Solution an sich kein Dienst ist?

2) Im Dienst habe ich per Referenz und using die Datenklassen der Haupt-Solution eingebunden. Diese funktionieren innerhalb des Hauptprojektes innerhalb der Hauptsolution einwandfrei. Der Dienst bleibt allerdings beim ersten Aufruf der Datenklasse.WasAuchImmer() hängen. Darf ich davon ausgehen dass ich komplexe Methodenrückgabewerte vergessen darf, sobald ich Projektgrenzen und damit exe/dll Grenzen überschreite?

3) Falls meine Vermutung unter 2) zutrifft: Was wäre der empfohlene Weg komplexere Informationen aus einer DLL zurück zu geben?

Und wie immer die allgemeine Frage: An welcher Ecke soll ich nachlesen um meine Wissenslücken zu schliessen?

Beste Grüße
Jörg

Hallo,

zu 1) Es ist problemlos möglich in einer Solution ein Projekt als Windows Dienst zu implementieren. Jedes Projekt erzeugt seine eigene Ausgabe Datei.

zu 2) Nein. Natürlich kannst du komplexe Objekte zurück geben. In .NET ist ja "Alles" ein Objekt, selbst primitive Datentypen. Was meinst du mit

Zitat:

Darf ich davon ausgehen dass ich komplexe Methodenrückgabewerte vergessen darf, sobald ich Projektgrenzen und damit exe/dll Grenzen überschreite?

Wenn du ein .NET Assembly (dll/exe) einbindest, dann ist die Verwendung im selben Prozess.

Also wenn dein Projekt sich komplett im CLR abläuft kannst du mit WCF-Services bequem den Transport übernehmen. Zu der FTP Übertragung rate ich dir absolut ab!

Vlt. wäre es sinnvoller die grundlegende Architektur auf WCF-Service zumzustellen und nur logische Teile von der alten Anwendung zu übernehmen. Ich denke der Aufwand bleibt ähnlich und du hast viele Vorteile.

Gruß

Danke für die schnelle Antwort!

Das Dienst Projekt in die Solution mit rein zu bringen schaue ich mir gleich noch einmal an.

zu 2) / komplexe Rückgabewerte: Der Dienst ist ja stehen geblieben sobald ich Klasse_aus_anderer_Solution.IrgendetwasEinfaches() aufgerufen habe. IrgendetwasEinfaches() gibt ein DataSet zurück. Daher war meine Vermutung dass so etwas komplexes wie ein DataSet eben nicht zurückgegeben werden kann wenn die Datenklassen aus einer komplett anderen Anwendung aufgerufen wird.

FTP ist schon das Mass aller Dinge, denn das ist nun mal der Weg wie EDI Nachrichten international ausgetauscht werden. Ich schaue allerdings mal ob ich nicht WCF benutze um FTP zu senden, denn das geht ja wohl auch.

Grundsätzlich hat bei dieser Anwendung Geschwindigkeit absoluten Vorrang vor bequemer Programmierung. Ist eine Kundenanforderung, kann ich wenig dran ändern. Die wollen halt tausende von Transaktionen pro Minute durchführen, da kommt es auf jede 10 ms an. Das spricht eventuell gegen WCF, aber ich würde schon lieber Standards benutzen.

Von der alten Anwendung werden eh nur Function Points übernommen, also weder Architektur noch Code.

Ich überlege nun auch für die Rechnerinterne Kommunikation zwischen FTP Dienst und Datenklassen(dienst) WCF zu benutzen, denn dann kann der Datenklassendienst auch auf einen (1) Middleware Server pro Niederlassung ausgelagert werden. Wäre schon ein architektonischer Vorteil...

Jörg

Zitat:

FTP ist schon das Mass aller Dinge, denn das ist nun mal der Weg wie EDI Nachrichten international ausgetauscht werden.

Also das sehe ich total anderst. FTP ist leider weit Verbreitet und wird für alles Mögliche missbraucht, hat aber in einer modernen SOA Architektur überhaupt nichts als Kommunikationsmedium zu suchen. Wenn man eine verteilte Anwendung programmieren will/braucht dann sollte man schon die dafür entwickelten Technologien zur Kommunikation verwenden. Gerade wenn du viele Transaktionen hast ist FTP sehr sehr ungeeignet. Du brauchst auf jeden Fall eine besser Kommunikationsmedium.

FTP ist keine Technologie, sondern nur ein Protokol welches auf Sockets aufbaut. Es ist dafür gedacht Daten Dateibasiert auszutauschen, nicht aber als Kommunikationsmiddleware. Dafür wurden WebServiecs konzipiert (Dienstbasiert). Allternativ andere Middlewares wie Rendezvous von Tibco (Nachrichtenbasiert).

Die Kommunikation zwischen deinem Server und dem DB-Server geschieht ja auch nicht mit FTP (von wegen Mass aller Dinge). Wenn du lokal Daten austauschen willst sind Pipes/Shared Memory das Mass der Dinge und wenn du über Rechnergrenzen hinweg schnell kommunizieren willst sind Sockets die Richtige Wahl ohen das FTP-Protokoll.

Nochmal wiederholend, wenn du einen Dienst programmieren willst (was du ja irgendwie machst) dann nehme auch eine dementsprechende Kommunikationsmedium à la WebService (bzw. .NET intern WCF) ggf. auch Sockets. Willst du Daten transportieren kannst du wiederum Sockets nehmen. FTP ist keine Technologie sondern nur ein Protokoll.

Gruß

Also ich will Dir ja nicht zu sehr widersprechen, aber wir reden hier von der Übermittlung von EDI Dateien an externe Geschäftspartner wie INTTRA oder GT Nexus. Und da ist neben FTP nur HTTP erlaubt. Wie ich schon versuchte anzudeuten: Im internationalen Warenverkehr ist EDI (EDIFACT/ANSI X.12) per FTP das Maß aller Dinge. Es ist auch davon auszugehen dass so gut wie keiner unser Geschäftspartner Windows benutzt.

Anwendungsintern werde ich FTP sicherlich nicht verwenden. Wäre komplett am Sinn vorbei. Aber der Dienst ist halt trotzdem ein FTP Versender, und das ist auch gut so

Aber zurück zum Subjet: FTP Versender Dienst und Datenbankanbindung würde ich gerne trennen. Beides macht meiner Meinung nach Sinn als Dienst implementiert zu werden, nachdem ich ja nun entschieden habe dass der Datenanbindungsdienst potentiell auf einem Niederlassungsserver laufen soll und damit auf einem anderen Rechner als der FTP Dienst.
Mein Problem ist also die Weitergabe von Daten, sagen wir mal DataSets, von einem Dienst zum anderen. Mir sagte mal jemand dass genau dass der Schwachpunkt einer Drei Schichten Anwendung wäre, und dass Serialisieren mein Freund sei. Ist das mit WCF 4.0 immer noch so, oder kann ich da schon ein DataSet von einer Anwendung auf PC 1 zu einer anderen Anwendung auf PC 2 ohne Serialisierung übergeben?

Beste Grüße
Jörg

Zitat:

Ist das mit WCF 4.0 immer noch so, oder kann ich da schon ein DataSet von einer Anwendung auf PC 1 zu einer anderen Anwendung auf PC 2 ohne Serialisierung übergeben?

Serialisierung muss schon noch verwendet werden.Das ist meiner Meinung nach gut so, führt aber zu einer höheren Komplexität.

Zitat:

Mir sagte mal jemand dass genau dass der Schwachpunkt einer Drei Schichten Anwendung wäre, und dass Serialisieren mein Freund sei

Ich würde dir wie mein Vorredner auch WCF empfehlen, es diktiert einem zwar bestimmte Technologien(SOA etc. ), aber was besseres für deinen Fall gibt es aus meiner Sicht nicht.

MfG

WCF und WebService nehmen dem Entwickler genau diese Schritte ab. Sprich der Entwickler definiert nur noch die Schnittstelle. Entwicklerwerkzeuge generieren den Rest, so dass die Anwendungen miteinandern kommunizieren können.

WebServices sind überhaupt nicht an Windows oder eine Programmiersprache gebunden, sondern komplett unabhängig. WCF kann man Services als WebService oder auch über HTTP kommunizieren lassen, so dass du da auch kein Problem hättest. Ich versuche das mal auszublenden und mich auf den hinteren Teil der ARchitektur zu konzentrieren.

Wieso willst du zwischen dem Sender und der Datenbank nochmal eine Schicht einziehen? Im Prinip ist das ja schon eine Schicht. Sprich die Datentransport von der DB zu deiner Anwendung übernehmen (wie vorhin angedeutet) andere Kommunikationswege. So dass egal wo der DB-Server steht deine Anwendung die Daten erhält.

DB Server --TCP/Pipe--> --> Anwendungsserver --FTP--> Clients

Aber generell kannst du DataSets in WCF Servies übertragen. Die Serialisierung wird die in den meisten Fällen vom .NET Framework abgenommen. Sollte also kein Problem darstellen. Falls es doch konkrete gibt, kannst ja du ja einen spezifischen Thread aufmachen.

Gruß

danielf hat folgendes geschrieben :

Wieso willst du zwischen dem Sender und der Datenbank nochmal eine Schicht einziehen? Im Prinip ist das ja schon eine Schicht. Sprich die Datentransport von der DB zu deiner Anwendung übernehmen (wie vorhin angedeutet) andere Kommunikationswege. So dass egal wo der DB-Server steht deine Anwendung die Daten erhält.

Da muss ich wohl noch Infos nachliefern: Die Datenbank ist 100 GB gross, die 150+ Niederlassungen mit 1000+ Benutzern auf der ganzen Welt verteilt, und wir wollen clientseitig immer noch hunderte Transaktionen pro Minute durchführen. Daher cachen die Datenzugriffklassen, und es macht Sinn diese Funktionen zentral zur Verfügung zu stellen. Die FTP Klasse sollte also demzufolge keine eigene Datenbankzugriffslogik enthalten, sondern die cachenden Datenzugriffklassen des Niederlassungsservers als Service benutzen.
Auf der anderen Seite halte ich es nicht für sinnvoll die FTP Scheduler Funktion in die Datenzugriffklassen oder den entsprechenden Dienst einzubauen. Das gehört getrennt.

danielf hat folgendes geschrieben :

DB Server --TCP/Pipe--> --> Anwendungsserver --FTP--> Clients

DB Server --ADO.Net--> --> Niederlassungsserver --WCF--> Clients --FTP--> Geschäftspartner

Nur um da mehr Klarheit rein zu bringen. Innerhalb unserer Anwendungssuite planen wir keinerlei FTP, zumindest nicht aktiv. FTP zum Geschäftspartner kann meinetwegen per WCF passieren, das ist eine andere Baustelle.

danielf hat folgendes geschrieben :

Aber generell kannst du DataSets in WCF Servies übertragen. Die Serialisierung wird die in den meisten Fällen vom .NET Framework abgenommen. Sollte also kein Problem darstellen. Falls es doch konkrete gibt, kannst ja du ja einen spezifischen Thread aufmachen.

Danke für die Erklärungen! Ich markiere die Frage dann mal als beantwortet

Jörg