mOSSpOWER Geschrieben 24. September 2007 Teilen Geschrieben 24. September 2007 Hallo Kollegen, ich habe drei Fragen, wobei die letzten beiden die wichtigeren sind 1) Wenn ich einen Webservice erstellen möchte, MUSS! ich dies immer in einem VS-Webservice-Application-Projekt machen? ... oder kann ich auch einer Windows- oder Consolenanwendung einen Web Service hinzufügen. OK, ich will mich nur vergewissern, kann mir aber beim besten Willen nicht vorstellen, dass dies funktioniert. Warum eigentlich nicht, müsste doch nur im IIS ein virtuelles Verzeichnis einrichten? 2) Wie schaut eine Architektur aus, wenn ich ein STATEFUL-Projekt von mehreren anderen Programmen (z.B. Web-Service-Projekt und Console-Projekt) aufrufen möchte, brauche ich dann jeweils eine Instanz, also in diesem Beispiel zwei des STATEFUL-Projektes? Ich möchte keinen "persistenten Austausch", d.h. ich möchte nicht, dass das stateful Projekt dauernd die Daten "zwischenpersistiert" (Datenbank oder XML-File), da sich diese im Sekundentakt ändern können und daher die Anfragen wesentlich verlangsamen würden. 3) Wie können Projekte andere aufrufen, ohne dass das aufrufende Projekt herunterfährt, wenn ich das aufgerufene beende? Wie macht ihr das? Beispiel, wenn ich zu Projekt A noch B hinzufüge, dann fährt B erst dann hoch, wenn ich aus A, B aufrufe und B wird beendet, wenn ich A beende. Wie kann ich A aufrufen, und B ist schon hochgefahren, bzw. bleibt immer oben, bis ich es explizit kille oder mit einem Projekt C runterfahre? Vielen Dank für eure Antworten, gerne auch "nur" Teile davon. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Gast alexC++ Geschrieben 25. September 2007 Teilen Geschrieben 25. September 2007 Du kannst einer Windows- oder Konsolenanwendung einen WebService hinzufügen. Projektmappenexplorer --> Rechtsklick auf Projekt --> Webverweis hinzufügen --> Deinen WebService auswählen... --> Proxy wird erstellt Dann den Namespace in deiner Anwendung einbinden in C# --> using localhost; //Wenn dein Webservice lokal gehostet wird oder eben localhost.Webmethode(); Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
mOSSpOWER Geschrieben 25. September 2007 Autor Teilen Geschrieben 25. September 2007 Du kannst einer Windows- oder Konsolenanwendung einen WebService hinzufügen. Projektmappenexplorer --> Rechtsklick auf Projekt --> Webverweis hinzufügen --> Deinen WebService auswählen... --> Proxy wird erstellt Dann den Namespace in deiner Anwendung einbinden in C# --> using localhost; //Wenn dein Webservice lokal gehostet wird oder eben localhost.Webmethode(); OK, sorry, da habe ich mich wohl falsch ausgedrückt. Ich meinte Web Service hosten, also Server, nicht Client. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Argbeil Geschrieben 25. September 2007 Teilen Geschrieben 25. September 2007 Hallo Kollegen, ich habe drei Fragen, wobei die letzten beiden die wichtigeren sind 1) Wenn ich einen Webservice erstellen möchte, MUSS! ich dies immer in einem VS-Webservice-Application-Projekt machen? ... oder kann ich auch einer Windows- oder Consolenanwendung einen Web Service hinzufügen. OK, ich will mich nur vergewissern, kann mir aber beim besten Willen nicht vorstellen, dass dies funktioniert. Warum eigentlich nicht, müsste doch nur im IIS ein virtuelles Verzeichnis einrichten? 2) Wie schaut eine Architektur aus, wenn ich ein STATEFUL-Projekt von mehreren anderen Programmen (z.B. Web-Service-Projekt und Console-Projekt) aufrufen möchte, brauche ich dann jeweils eine Instanz, also in diesem Beispiel zwei des STATEFUL-Projektes? Ich möchte keinen "persistenten Austausch", d.h. ich möchte nicht, dass das stateful Projekt dauernd die Daten "zwischenpersistiert" (Datenbank oder XML-File), da sich diese im Sekundentakt ändern können und daher die Anfragen wesentlich verlangsamen würden. 3) Wie können Projekte andere aufrufen, ohne dass das aufrufende Projekt herunterfährt, wenn ich das aufgerufene beende? Wie macht ihr das? Beispiel, wenn ich zu Projekt A noch B hinzufüge, dann fährt B erst dann hoch, wenn ich aus A, B aufrufe und B wird beendet, wenn ich A beende. Wie kann ich A aufrufen, und B ist schon hochgefahren, bzw. bleibt immer oben, bis ich es explizit kille oder mit einem Projekt C runterfahre? Vielen Dank für eure Antworten, gerne auch "nur" Teile davon. 1. Meinst du das Hosten eines Webservices oder das konsumieren? Zum hosten brauchst nicht zwingend einen IIS, ich würde es aber sehr empfehlen. Wenn du dir z.B. mal den Cassini-Webserver runterlädst (ein Open-Source Webserver in C# geschrieben) siehst du das es relativ einfach ist WebAnwendungen zu hosten. 2. Was meinst du mit Statefull Projekt, einen Statefull Webservice? Eine Instanz des Services erstellst du sowieso nicht, das sieht nur so aus. VS erstellt ein Proxy Objekt das die gleiche Schnittstelle bietet wie der Webservice selbst und das mit new Instanziiert wird, beim Aufruf werden aber tatsächlich nur Soap-Requests zum Service erzeugt. Dein Session-Handling kannst du auch selber implementieren indem zu z.b. eine Logon Mehtode schreibst die eine GUID zurückliefert. Wenn ich mir deine Beschreibung so durchlese solltest du allerdings nochmal prüfen ob ein WS das richtige für dich ist. Deine Applikationen können natürlich auch mit einer Stored-Procedure reden, da würde die komplette WS Schicht wegfallen können. Im SQL Server 2005 kannst du auch .NET Assemblys als Stored-Procedure verwenden. 3. Das ist zu unpräzise, worum geht es? Um 3 Webservices? Die Lifetime kannst du über die Webconfig/machine.config steuern, dabei solltest du aber genau wissen was du tust. Der Service wird "heruntergefahren" wenn keine Session mehr aktiv ist (plus 20 Minuten glaube ich). Du kannst auch asynchrone Requests erstellen, so das du in der Zwischenzeit andere Dinge erledigen kannst. Generell ist das 20 Minuten Session Limit schon recht sinnvoll. Evtl. ist für dich aber wirklich ein Webservice nicht geeignet, was spricht z.B. gegen Remoting oder WCF ? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
mOSSpOWER Geschrieben 25. September 2007 Autor Teilen Geschrieben 25. September 2007 1. Meinst du das Hosten eines Webservices oder das konsumieren? Zum hosten brauchst nicht zwingend einen IIS, ich würde es aber sehr empfehlen. Wenn du dir z.B. mal den Cassini-Webserver runterlädst (ein Open-Source Webserver in C# geschrieben) siehst du das es relativ einfach ist WebAnwendungen zu hosten. 2. Was meinst du mit Statefull Projekt, einen Statefull Webservice? Eine Instanz des Services erstellst du sowieso nicht, das sieht nur so aus. VS erstellt ein Proxy Objekt das die gleiche Schnittstelle bietet wie der Webservice selbst und das mit new Instanziiert wird, beim Aufruf werden aber tatsächlich nur Soap-Requests zum Service erzeugt. Dein Session-Handling kannst du auch selber implementieren indem zu z.b. eine Logon Mehtode schreibst die eine GUID zurückliefert. Wenn ich mir deine Beschreibung so durchlese solltest du allerdings nochmal prüfen ob ein WS das richtige für dich ist. Deine Applikationen können natürlich auch mit einer Stored-Procedure reden, da würde die komplette WS Schicht wegfallen können. Im SQL Server 2005 kannst du auch .NET Assemblys als Stored-Procedure verwenden. 3. Das ist zu unpräzise, worum geht es? Um 3 Webservices? Die Lifetime kannst du über die Webconfig/machine.config steuern, dabei solltest du aber genau wissen was du tust. Der Service wird "heruntergefahren" wenn keine Session mehr aktiv ist (plus 20 Minuten glaube ich). Du kannst auch asynchrone Requests erstellen, so das du in der Zwischenzeit andere Dinge erledigen kannst. Generell ist das 20 Minuten Session Limit schon recht sinnvoll. Evtl. ist für dich aber wirklich ein Webservice nicht geeignet, was spricht z.B. gegen Remoting oder WCF ? 1) Ich meinte, ob man z.B. in einer Windows-Forms-Anwendung einfach ein paar Web Services Klassen hinzufügen kann, also nicht explizit in einem Webprojekt. 2) Mit stateful meinte ich, dass die Anwendung (als ganzes) weiterläuft, auch nachdem ein Request verarbeitet wurde, aber ich glaube das erledigt sich in ... 3) Eine stateful Anwendung bekomme ich nur mit Remoting hin (denke ich). Ich erkläre mal kurz, was ich möchte. Ich erstelle ein Programm (oder Projekt, wie auch immer). Dieses soll nonstop laufen. Nun soll man von anderen Programmen aus (C#-Anwendungen UND Web Services) auf Services (Methoden) von der stateful Anwendung zugreifen. Natürlich könnte ich in der stateful Anwendung veranlassen, dass Zwischenergebnisse in persistiert werden (DB oder XML), jedoch möchte ich dies aus Performancegründen und Zeitgründen nicht, da z.B. Änderrungen im Sekundentakt vorkommen können und ein permanentes schreiben auf die Performance drückt. Es geht wahrscheinlich nur mit Remoting. Die Frage ist, ob ich ein Webservice davorschalte und dann mittels Remoting auf die stateful Anwendung zugreife ODER ich alles IN EINEM Webservice mache, wobei ich hier nicht weiss, wie es mit der Performance aussieht, wenn ich z.B. lokal (von mir aus auch im eigenen Netzwerk) auf die stateful Anwendung zugreifen will. Was wäre der Nachteil, wenn ich gleich auf Remoting verzichte und immer über ein Web Service gehe .. oder bin ich mit Remoting schneller, wenn ich C#-Programme schreibe, die den Service nutzen wollen. Wie würdet Ihr das lösen? Danke schon mal für etwaige Antworten. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Argbeil Geschrieben 26. September 2007 Teilen Geschrieben 26. September 2007 1) Ich meinte, ob man z.B. in einer Windows-Forms-Anwendung einfach ein paar Web Services Klassen hinzufügen kann, also nicht explizit in einem Webprojekt. 2) Mit stateful meinte ich, dass die Anwendung (als ganzes) weiterläuft, auch nachdem ein Request verarbeitet wurde, aber ich glaube das erledigt sich in ... 3) Eine stateful Anwendung bekomme ich nur mit Remoting hin (denke ich). Ich erkläre mal kurz, was ich möchte. Ich erstelle ein Programm (oder Projekt, wie auch immer). Dieses soll nonstop laufen. Nun soll man von anderen Programmen aus (C#-Anwendungen UND Web Services) auf Services (Methoden) von der stateful Anwendung zugreifen. Natürlich könnte ich in der stateful Anwendung veranlassen, dass Zwischenergebnisse in persistiert werden (DB oder XML), jedoch möchte ich dies aus Performancegründen und Zeitgründen nicht, da z.B. Änderrungen im Sekundentakt vorkommen können und ein permanentes schreiben auf die Performance drückt. Es geht wahrscheinlich nur mit Remoting. Die Frage ist, ob ich ein Webservice davorschalte und dann mittels Remoting auf die stateful Anwendung zugreife ODER ich alles IN EINEM Webservice mache, wobei ich hier nicht weiss, wie es mit der Performance aussieht, wenn ich z.B. lokal (von mir aus auch im eigenen Netzwerk) auf die stateful Anwendung zugreifen will. Was wäre der Nachteil, wenn ich gleich auf Remoting verzichte und immer über ein Web Service gehe .. oder bin ich mit Remoting schneller, wenn ich C#-Programme schreibe, die den Service nutzen wollen. Wie würdet Ihr das lösen? Danke schon mal für etwaige Antworten. 1. Was meinst du damit? Um sie zu konsumieren - Natürlich, um sie zu hosten - nein. 2. Die Host-Anwendung (ja, natürlich) oder die konsumierende (ja, über die Konfiguration) 3. Die Lösung mit Webservice und Remoting ist natürlich langsamer weil der komplette Webservice verkehr nochmal Base64 kodiert werden muss und Overhead in der Datenübertragung erzeugt. Die Frage ist, ob du einen Webservice brauchst. Habt ihr Kunden die den Service nutzen? Soll der über das Internet verfügbar sein? Wenn beides mit nein beantwortet wird ist die Remoting-Lösung besser. Als Webservice sollte man keine permanent laufende Applikationen realisieren, das ist eher ein Windows-Service. Mit dem kann man z.B. über Remoting kommunizieren. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
mOSSpOWER Geschrieben 26. September 2007 Autor Teilen Geschrieben 26. September 2007 1. Was meinst du damit? Um sie zu konsumieren - Natürlich, um sie zu hosten - nein. 2. Die Host-Anwendung (ja, natürlich) oder die konsumierende (ja, über die Konfiguration) 3. Die Lösung mit Webservice und Remoting ist natürlich langsamer weil der komplette Webservice verkehr nochmal Base64 kodiert werden muss und Overhead in der Datenübertragung erzeugt. Die Frage ist, ob du einen Webservice brauchst. Habt ihr Kunden die den Service nutzen? Soll der über das Internet verfügbar sein? Wenn beides mit nein beantwortet wird ist die Remoting-Lösung besser. Als Webservice sollte man keine permanent laufende Applikationen realisieren, das ist eher ein Windows-Service. Mit dem kann man z.B. über Remoting kommunizieren. Hallo, Danke für die Antworten. Nun, heute bin ich schlauer, ich habe mich mal eingelesen in .NET-Remoting. Das Programm will ich privat erstellen. Ich werde es so lösen, dass ich beides implementiere. Ich werde den Service erstellen und über TCP-Channel kann man dann (im lokalen Netzwerk) remote auf den Service zugreifen. Für Zugriffe außerhalb des Netzwerkes (und von anderen Applikationen aus, z.B. Java) werde ich eine Web Service dazwischen schalten, der dann mittels IPC Channel (gleicher Rechner) auf das Service zugreift. Hier kann ich ja die Remoting-Objekte stateful machen, die ich brauche. Danke für eure Anregungen und Antworten. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Argbeil Geschrieben 26. September 2007 Teilen Geschrieben 26. September 2007 Gerne. Gute Idee, das ist genau die Architektur wie sie idealerweise aussehen sollte. Wenn du für dein Remotable-Objekt ein Interface erstellst kannst du das gleiche Interface später für den Webservice verwenden und die WebService-Request einfach an das Remote-Objekt weiterleiten ( Da spricht man dann von einer WebService-Fassade ). Wenn die beiden Komponenten auf der gleichen Maschine laufen kannst du auch zusätzlich zu TCP/IP über Shared-Memory anstelle von TCP/IP kommunizieren, das geht dann noch schneller. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.