Laden...

Architektur von Web-Services bestehend aus mehreren Projekten

Erstellt von mosspower vor 16 Jahren Letzter Beitrag vor 16 Jahren 1.736 Views
mosspower Themenstarter:in
456 Beiträge seit 2007
vor 16 Jahren
Architektur von Web-Services bestehend aus mehreren Projekten

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ürde.

  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.

49.485 Beiträge seit 2005
vor 16 Jahren

Hallo mosspower,

beachte bitte [Hinweis] Wie poste ich richtig? Punkt 1.2 und Punkt 3.

herbivore

S
8.746 Beiträge seit 2005
vor 16 Jahren

Original von mosspower

  1. [...] oder kann ich auch einer Windows- oder Consolenanwendung einen Web Service hinzufügen.

Ja.

Alles andere hab ich nicht verstanden. "Projekte" rufen sich auf und fahren runter... keine Ahnung was du meinst. Meinst du Services?

mosspower Themenstarter:in
456 Beiträge seit 2007
vor 16 Jahren

Original von svenson

Alles andere hab ich nicht verstanden. "Projekte" rufen sich auf und fahren runter... keine Ahnung was du meinst. Meinst du Services?

Ich kann also jeder Anwendung (z.B. Console- oder Windowsanwendung) einen Web-Service Server, nicht Client, hinzufügen?

Was ich meine ist folgendes. Nehmen wir mal an, ich programmiere ein Projekt (egal ob Console, Windowsanwendung ect.). Dieses Programm läuft nun 24 Stunden 365 Tage. Wie kann ich mit einem anderen Projekt auf dieses Programm zugreifen? Nehmen wir an, das Programm führt eine statische Collection mit aktuellen Ereignissen. Wie komme ich (von außen) an diese Liste ohne das Programm "zwingen zu müssen", die Liste immer wieder zu persistieren (Datenbank, XML-File ect.). Wie kann hier eine Kommunikation über Projekte hinweg stattfinden? Bedenke, dass das aufrufende Projekt u. U. nicht 24 Stunden/Tag läuft, so dass ein "simples" hinzufügen des Zielprojektes zur Folge hätte, dass das auch das Zielprojekt "runterfährt", wenn das aufrufene beendet wird. Wie kann ich das umgehen, oder besser gefragt, wie ist hier die Vorgehensweise? Wie würdet ihr das machen? Was meinst Du mit Service? Kann man diese mit anderen Projekten ansprechen?

S
8.746 Beiträge seit 2005
vor 16 Jahren

Ich verstehe einfach nicht, was du mit "Projekten" meinst, und warum die "runterfahren" wenn man andere hinzufügt (wo hinzufügt?).

Aber ich will mal versuchen zu beantworten, was ich verstanden hab.

  1. Ja, man kann in jeder beliebigen Anwendung WebServices "hosten"
  2. Das setzt .NET 3.0, Win XP SP2 bzw. Win2003 Server bzw. Vista vorraus.
  3. Wenn das Programm nicht immer laufen soll, muss es entweder die Daten ständig z.B. aus einer DB laden oder sich aus dem Speicher bestücken, der natürlich geladen und gespeichert werden will. Insofern besteht da natürlich "Zwang". Wie soll es auch anders gehen?

Und wenn du eine Aufrufkette über mehrere Service hast, so ist es natürlich ein Problem, wenn ein Glied in der Kette nicht läuft. Entweder hälst du die Verfügbarkeit hoch, oder du musst - falls möglich - dir eine Offline-Funktionalität aufbauen. Das geht natürlich nicht bei allen Diensten (eher bei den wenigsten).

mosspower Themenstarter:in
456 Beiträge seit 2007
vor 16 Jahren

Original von svenson
Ich verstehe einfach nicht, was du mit "Projekten" meinst, und warum die "runterfahren" wenn man andere hinzufügt (wo hinzufügt?).

Aber ich will mal versuchen zu beantworten, was ich verstanden hab.

  1. Ja, man kann in jeder beliebigen Anwendung WebServices "hosten"
  2. Das setzt .NET 3.0, Win XP SP2 bzw. Win2003 Server bzw. Vista vorraus.
  3. Wenn das Programm nicht immer laufen soll, muss es entweder die Daten ständig z.B. aus einer DB laden oder sich aus dem Speicher bestücken, der natürlich geladen und gespeichert werden will. Insofern besteht da natürlich "Zwang". Wie soll es auch anders gehen?

Und wenn du eine Aufrufkette über mehrere Service hast, so ist es natürlich ein Problem, wenn ein Glied in der Kette nicht läuft. Entweder hälst du die Verfügbarkeit hoch, oder du musst - falls möglich - dir eine Offline-Funktionalität aufbauen. Das geht natürlich nicht bei allen Diensten (eher bei den wenigsten).

OK, ich erkläre es noch einmal kurz. Nehmen wir an, ich habe ein Library-Prjekt mit dem Namen A. Erstelle ich jetzt ein Projekt B (von mir aus Consoleanwendung) und füge diesem Projekt A hinzu (VS mit add existing project), dann wird immer beim Starten von B auch eine (neue!) Instanz von A geladen. Frage ist, wie komme ich auf eine laufende Instanz von A (die ich vorher, wie auch immer, gestartet habe)? Mit herunter fahren meinte ich, dass bei diesem Beispiel die Instanz von Projekt A "gekilled" wird, wenn ich Projekt B beende. Nehmen wir einmal an, ich schreibe ein Programm A, welches ich hochfahre für wie schon gesagt 24 Stunden / 365 Tage. Jetzt soll es die Möglichkeit geben über andere (und mehrere!) Schnittstellen (Webservice, Windowsanwendung ect.) auf Programm A (oder besser auf die gestartete Instanz, oder noch besser, auf öffentliche noch nicht persistierte Daten der Instanz) zuzugreifen. Wie macht ihr das, wie löst man dies, ohne Zwischenpersistenz (Datenbank, XML) durchführen zu müssen? Geht das überhaupt? Wenn Programm A natürlich hin und wieder die Daten in die Datenbank "kloppt" oder in eine (oder mehrere XML-Files) schreibt, dann könnten so natürlich alle Schnittstellen "bedient" werden, jedoch möchte ich dies nicht, da es Änderrungen im Sekundenbereich geben kann, was dann die Anwendung langsam macht, bzw. die Aktuallität der Daten hinterherhinkt, wegen dem schreiben und lesen der Persistenzschicht. Natürlich persistiert Programm A auch hin und wieder Daten, aber es ist vorgesehen, die erst dann zu persistieren, wenn ein Ergebnis feststeht und sich bei einem Objekt nichts mehr ändert. Wie würdet Ihr das machen?

871 Beiträge seit 2005
vor 16 Jahren

Hallo,

Wenn Du nur über andere .NET Anwendungen auf deine Applikation zugreifen willst, könnte Remoting das mittel deiner Wahl sein. Sollte es platformunabhängig sein, so verwende ein vorgeschaltetes Webservice welches dann mittels Remoting mit deiner Applikation kommuniziert.

Grüsse,
Egon

49.485 Beiträge seit 2005
vor 16 Jahren

Hallo mosspower,

was du willst klingt nicht nach Library, sondern nach Diensten (im weiteren Sinne). Zumindest jedoch nach eigenständigen Prozessen, die dann per IPC kommunizieren (z.B. TCP/IP, NamedPipes). Wenn du als IPC-Mechanismus Remoting oder Web-Services verwendest, dann kannst du über Prozessgrenzen hinweg Methoden aufrufen, quasi so als hättest du A als Referenz zu B hinzugefügt. Da du sowieso Web-Services implementieren willst, dann liegt es Nahe deine Libraries auch als Web-Services zu implementieren.

herbivore

mosspower Themenstarter:in
456 Beiträge seit 2007
vor 16 Jahren

@egrath, @herbivore,

vielen Dank, jetzt klingelt es so langsam bei mir. Habe ja schon öfters von RPC, CORBA ect. gehört ... auch schon Jahre mit EJB gearbeitet, aber mich nicht näher darum gekümmert, da es einfach lieft, bzw. die Anwendungen stateless waren. Abschließend vielleicht dann doch noch eine Frage. Beide Technologien (Web Service oder Remoting) gehen ja "über die Leitung". Wie schaut dies mit der Performance aus? Mir scheint, dass der Vorschlag von egrath sehr gut ist (da ich auf jeden Fall auch ein plattformunabhängiges Web Service brauchen werde). Die Frage ist nun ob sich Remoting lohnt zu implementieren (aus Performancegründen), wenn ich lokal (oder im eigenen Netzwerk) auch auf den Service zugreifen möchte (mit C#). Verbraucht hier ein Webservice zu viele Resourcen? - oder würdet ihr gleich das Remoting weglassen und alles über Web Service machen? Stimmt doch eigentlich oder, dass beides über die Leitung läuft und somit in etwa von der Performance gleich sein sollten .. hm .. OK, wahrscheinlich ist Remoting von der Performance her schneller, da speziell für C# (.NET) entwickelt und ist dann doch schneller als Web Services. Könnt ihr mir hierzu noch kurz Statements geben - dafür wäre ich euch dankbar.

Gruß

49.485 Beiträge seit 2005
vor 16 Jahren

Hallo mosspower,

viele Fragen ein Antwort: Probier es aus. 🙂

Ich denke nicht, dass die Performance eine Rolle spielt, wenn es um Zugriff "im Sekundenbereich" geht. Auch der Ressourcenverbrauch dürfte keine Rolle spielen.

herbivore

S
8.746 Beiträge seit 2005
vor 16 Jahren

Original von mosspower
Nehmen wir an, ich habe ein Library-Prjekt mit dem Namen A. Erstelle ich jetzt ein Projekt B (von mir aus Consoleanwendung) und füge diesem Projekt A hinzu (VS mit add existing project), dann wird immer beim Starten von B auch eine (neue!) Instanz von A geladen.

Nein. Der Begriff "Instanz" ist hier fehl am Platz. Du hast eine Applikation (B), welche eine DLL (ProjektA) lädt.

Frage ist, wie komme ich auf eine laufende Instanz von A (die ich vorher, wie auch immer, gestartet habe)?

Du kannst A nicht starten, denn es ist eine Library. Man kann nur Applikationen starten.

Mit herunter fahren meinte ich, dass bei diesem Beispiel die Instanz von Projekt A "gekilled" wird, wenn ich Projekt B beende.

Man kann Libraries nicht starten und daher auch nicht beenden. Insofern macht dieses Beispiel ebenfalls keinen Sinn.

Nehmen wir einmal an, ich schreibe ein Programm A, welches ich hochfahre für wie schon gesagt 24 Stunden / 365 Tage. Jetzt soll es die Möglichkeit geben über andere (und mehrere!) Schnittstellen (Webservice, Windowsanwendung ect.) auf Programm A (oder besser auf die gestartete Instanz, oder noch besser, auf öffentliche noch nicht persistierte Daten der Instanz) zuzugreifen.

Dein Persistenzprobleme verstehe ich leider nicht. Natürlich muss man Daten speichern bzw. laden - schon um sich gegen Datenverlust bei Absturz oder Wartung zu schützen. Wann und nach welchem Prinzip hängt ganz von den Anforderungen an die Anwendung ab. Dazu stellen z.B. Datenbanken bestimmte Transaktion-Formen (z.B. SnapShot) bereit, die es erlauben Daten zu schreiben und gleichzeitig den alten (konsistenten) Stand zu lesen. Paralellisierungskonflikte löst hier somit die DB. Bei anderen Verfahren muss man ggf. eine eigene Sychronisierung schreiben.