Laden...

WCF-REST Service: Endpunkt nicht gefunden

Erstellt von Jacyrio vor 8 Jahren Letzter Beitrag vor 8 Jahren 12.557 Views
J
Jacyrio Themenstarter:in
197 Beiträge seit 2006
vor 8 Jahren
WCF-REST Service: Endpunkt nicht gefunden

Guten Tag,

ich versuche mich aktuell wieder an einem WCF-Service. Wie damals habe ich immernoch Probleme bei der Endpoint-Konfiguration.. steige da irgendwie noch nicht ganz so durch 😦

Jetzt habe ich einen WCF-Service (REST) gebaut und kann über eine URL auf den Service zugreifen und bekomme auch eine Rückmeldung.

Sobald ich den Service in meine Client-Anwendung einbinde und folgenden Code ausführe


            TestServiceClient client = new TestServiceClient();
            MessageBox.Show(client.Test().ToString());

bekomme ich folgende Fehlermeldung:

Fehlermeldung:
Zusätzliche Informationen: Es war kein an
>
lauschender Endpunkt vorhanden, der die Nachricht annehmen konnte. Dies wird häufig durch eine fehlerhafte Adresse oder SOAP-Aktion verursacht. Weitere Details finden Sie unter "InnerException", sofern vorhanden.

Die Inner Exception

{"Der Remoteserver hat einen Fehler zurückgegeben: (404) Nicht gefunden."}

Meine Endpoint-Config im Client:


  <system.serviceModel>
    <bindings>
      <basicHttpBinding>
        <binding name="BasicHttpBinding_ITestService" />
      </basicHttpBinding>
    </bindings>
    <client>
      <endpoint address="http://localhost:52841/TestService.svc" binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_ITestService"
                contract="TestReference.ITestService" name="BasicHttpBinding_ITestService" />
    </client>
  </system.serviceModel>

Woher kommt der Fehler? Kann mir das einer sagen? Zusätzlich dazu noch ein paar andere Fragen:

  1. Habt ihr vielleicht irgendeinen Link, wo das mit der Konfiguration vernünftig erklärt wird, damit ich da mal selbst durchsteige? Ich habe im Internet gesucht, finde aber leider nichts vernünftiges / verständliches für mich.

  2. Ich vermute mal man kann diese Endpoint-Configuration auch in der Programmierung machen anstatt in den Config-Dateien oder? MAcht das vielleicht mehr Sinn die Endpoints in der Programmierung zu erstellen?

Vielen Dank schon mal..

16.807 Beiträge seit 2008
vor 8 Jahren

Alles kann ohne Config umgesetzt werden und ist teilweise auch einfacher.
Persönlich halte ich recht wenig von der Config, siehe
Einfaches WCF-Beispiel ohne komplizierte Config

J
Jacyrio Themenstarter:in
197 Beiträge seit 2006
vor 8 Jahren

@Abt: Danke.. das hast du mir gestern schon in einem anderen Thread gezeigt (aber aus einem anderen Grund). Ich bräuchte das aber für einen WebService.. und falls du hast, wäre eine Erklärung für die einzelnen Punkte die ich dort machen muss ganz gut.. Wofür muss ich zB den Behavoir-Bereich definieren?

Ich probiere das mal ohne Config aus..

Aber der Fehler scheint ja trotzdem woanders her zu kommen oder?

16.807 Beiträge seit 2008
vor 8 Jahren

Achso, das wusste ich nicht (mehr) 😉

Naja; WCF als reine REST Schnittstelle zu verwenden ist ehrlich gesagt - meine Meinung - nicht die beste Idee.
Da wäre ASP.NET WebAPI deutlich besser gewesen und ich bin auch der Meinung, dass das keine Zukunft hat. Mir fällt selbst auch schwer einzuschätzen, ob REST überhaupt noch in der Form für WCF in der Zukunft Relevanz hat.

Wenn Du gerade also am Anfang bist:
Wieso verwendest Du das oft sehr schwer zu handhabende WCF für eine einfache REST Schnittstelle? Hast Du evaluiert, oder einfach mal WCF genommen?

J
Jacyrio Themenstarter:in
197 Beiträge seit 2006
vor 8 Jahren

Also einfach so genommen habe ich das nicht.. ich wollte nur vorerst mal mit dem RESTService anfangen.. also übers WEB gehen.

Meine Idee ist zukünftig die Software intern über TCP zu verwenden und extern (also über eine App) über einen REST-Service.

Für sowas fand ich WCF ganz gut geeignet.. Da ich aber nicht mal hin bekomme den Client mit dem Rest Service kommunizieren lassen, weil ich dann diesen Endpointfehler bekomme, habe ich es mit netTcpBindinig schon gar nicht versucht..

3.003 Beiträge seit 2006
vor 8 Jahren

Es existiert ein uraltes, unveröffentlichtes Artikelfragment von mir hier im Forum (auf das Du keinen Zugriff hast 😉 ) zum Thema Restful service mit WCF, das leider nie veröffentlicht wurde.

Ich habe da seit Jahren nicht drübergeschaut, aber eventuell hilft dir das diesem Posting anhängende Beispielprojekt weiter.

Erwarte bitte nicht, dass ich aus dem Hut dazu Erläuterungen geben kann, der Artikel ist von August 2009 😉. Wenn ich richtig geschaut habe, wird der Service im Beispiell IIS-gehostet, was für einen RESTful service ja auch Sinn ergibt.

Vielleicht hilft es dir trotzdem. Der Hinweis auf WebApi ist generell richtig, meiner Meinung nach lernt man mehr mit WCF. Aber ich bin vorbelastet.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

16.807 Beiträge seit 2008
vor 8 Jahren

Welchen Grund hat das, dass Du direkt über TCP gehen willst?
Das macht die Sache eigentlich unnötig kompliziert. Ausser es gibt Vorgaben, die hier nicht ersichtlich sind.

NetPipe und NetTcp haben einige wenige Vorteile, weswegen man sie manchmal doch nimmt, aber riesige Nachteile, weshalb man in 95% der Fälle http empfiehlt und verwendet, da auch die Vorteile von Net(Pipe|Tcp) nur sehr sehr sehr selten zum Tragen kommen.
Geht ja hier offensichtlich eher nicht ums Lernen, sondern um die Realisierung eines Services.

T
314 Beiträge seit 2013
vor 8 Jahren

WCF + Rest gibt es ja. In dem Fall dann eben aber auch entsprechend über das webHttpBinding. Allerdings solltest Du wenn möglich eben wie bereits erwähnt ggf. nicht WCF wählen, wenn Du eine RESTful API haben möchtest. Dafür gibt es mittlerweile einfach bessere alternativen.

Aber dein Grundsätzliches Problem ist ja auch nicht REST sondern die Verbindung zum Endpoint.
Wie ist der Service denn gehostet? IIS? Self?

Dein Endpoint muss ja auch immer einfach per Browser erreichbar sein (zumindestens beim httpBinding 😃).

J
Jacyrio Themenstarter:in
197 Beiträge seit 2006
vor 8 Jahren

Jetzt bin ich etwas verwirrt...

Also..

@Abt: Es geht vorerst ums lernen.. aber ich lerne ja, um es dann hinterher in einem Projekt umsetzen zu können. Ich möchte ein Programm bauen, dass (in weiter Zukunft) mal intern in einem Netzwerk benutzt wird, aber auch von außen per App erreichbar ist. Die Clients sollen dann unabhängig sein und Daten bzw. Befehle nur auf einem Service ausführen. Dafür wollte ich einen WCF-Service verwenden (was anderes kenne ich aktuell über .NET noch nicht).

Wenn ich den WCF-Service nicht für REST verwenden sollte und auch nicht über TCP, weil das auch nicht die schöne Art ist. Wofür verwende ich dann überhaupt einen WCF-Service? Oder mit was realisiere ich meine Idee besser? Wenn ich im Moment an einer falschen Stelle bastel und mir eher was anderes anschauen sollte, würde ich das tun.

@t0ms3n: Mein WCF-Service funktionierte ja soweit schon. Ich habe den Service gestartet und bekam über die entsprechende URL den JSON-String angezeigt. Sobald ich aber den Service in meinem Client-Projekt einbinde und die Funktion aufrufe, bekomme ich die eingangs genannte Fehlermeldung (Der Service läuft aber noch). Ich habe jetzt mal versucht eine netTcpBinding einzurichten, aber auch da bin ich am verzweifeln... so schwierig kann das doch nicht sein 😦

Ich habe bisher IIS-Express verwendet.. habe mir jetzt mal den IIS lokal installiert. Kann das daran liegen? Werde das jetzt nochmal umbauen..

Aber generell noch mal die Frage: Wenn ich Clients habe die innerhalb und außerhalb des Netzwerks sind und auf einen Dienst zugreifen sollen um sich Daten zu holen oder hin zu senden.. bin ich dann mit WCF falsch unterwegs? Wenn ja.. was sollte ich mir dann alternativ anschauen?

Danke! 😃

16.807 Beiträge seit 2008
vor 8 Jahren

Niemand hat von sollte gesprochen, sondern davon, dass es eben viel viel bessere und einfachere Alternativen gibt, wenn es um REST geht (ASP.NET, NancyFx).
WCF hat in anderen vor allem bi-direktionalen oder Streaming-Szenarien riesen Vorteile - dort verwendet man es.

Und TCP ist eben die Sache, dass es einige Nachteile bezügliche Firewall hat, oder Du bei HTTP eben auch HTTPS geschenkt bekommst.
Vor allem, warum man im Intranet lieber TCP als HTTP benutzt: warum?
Woher diese Annahme? Das kann ich absolut nicht teilen 😃

Ich sehe jetzt hier absolut keinen Grund, weswegen man hier unbedingt WCF und TCP benötigt.
Rein von dem was Du beschreibst passt ASP.NET WebAPI via REST über HTTPS doch wie die Faust aufs Auge - mit weniger Aufwand und einfacher.

WCF ist _eigentlich _eine XML-Schnittstelle. Kann zwar auch Json aber halt umständlicher.
Im Web und besonders bei Apps hast Du aber aufgrund der geringeren Datenoverheads und der vielen verfügbaren Bibliotheken sowie eben aufgrund von JavaScript eher Json als Schema; kein XML.

Du kommst auch mit WCF ans Ziel.
Aber ich bin hier der Meinung, dass Du Dir sehr viel Aufwand machst, die Du mit anderen Technologien teilweise gar nicht hast, viel mehr geschenkt bekommst und die Einstiegshürde auch um ein Vielfaches geringer ist.
Kernfeatures, bei denen WCF echt gut ist; die brauchst Du hier gar nicht.

2.207 Beiträge seit 2011
vor 8 Jahren

Hallo Jacyrio,

Oder mit was realisiere ich meine Idee besser? Wenn ich im Moment an einer falschen Stelle bastel und mir eher was anderes anschauen sollte, würde ich das tun.

Da wäre ASP.NET WebAPI deutlich besser gewesen

Learn About ASP.NET Web API

Im Prinzip sind der Anwendungsfall und die Probleme, die du gerade hast, genau der Grund warum man eine WebAPI vorzieht 😃

Gruss

Coffeebean

J
Jacyrio Themenstarter:in
197 Beiträge seit 2006
vor 8 Jahren

@Abt: Ehrlich gesagt kann ich dir keinen genauen Grund nennen wieso TCP und nicht HTTP 😄 Ich bin davon ausgegangen, dass es evtl Performance-Vorteile hat wenn ich eine TCP statt HTTP Kommunikation verwende..

@Coffeebean: Danke für den Link..

Also drei Tage an WCF rumgebaut.. dann schaue ich mir jetzt mal ASP WebApi an 😦 naja.. man lernt ja nie aus 😃

Aber zwei Sachen noch:

  1. Was wäre denn ein Beispiel wo man WCF besser verwenden sollte als Asp WebApi?

  2. Wenn mein Service in Zukunft noch weiter Aufgaben übernehmen soll.. wie zB Erstellung von Belegen in einem ERP-System (dafür gibts natürlich dementsprechend Verweise usw.) oder Generierung von Reports, die ausgedruckt werden sollen (mit einer Drittanbietersoftware). Bin ich dann mit ASP WebApi immernoch richtig? Also ich will damit sagen, mein Service soll nicht rein dazu dienen Daten von A nach B und von B nach A zu übertragen.. ich will den Service auch noch was verarbeiten lassen..

Oder wäre es dann die bessere Idee als WebApi einen Befehl entgegen zu nehmen, dann einen anderen Service anzusprechen, der dann wiederum die Verarbeitung übernimmt?

Ich möchte nur sicher gehen das ich bei Asp WebAPI richtig bin, bevor ich mir das anschaue und merke das ich doch noch was anderes lernen sollte 😃

2.207 Beiträge seit 2011
vor 8 Jahren

Hallo Jacyrio,

Ich möchte nur sicher gehen das ich bei Asp WebAPI richtig bin, bevor ich mir das anschaue und merke das ich doch noch was anderes lernen sollte 😃

Naja, eher andersrum: Schaus dir an und dann entscheide, obs für dich richtig ist 😉

Gruss

Coffeebean

3.003 Beiträge seit 2006
vor 8 Jahren

Ich möchte nur sicher gehen das ich bei Asp WebAPI richtig bin, bevor ich mir das anschaue und merke das ich doch noch was anderes lernen sollte 🙂

Oh, darf ich lösen? 😁 Du wirst IMMER noch etwas anderes lernen müssen.

Spass beiseite - für das, was du derzeit vorhast, reicht WebAPI und hat nebenbei den Vorteil, dass es eine flachere Lernkurve hat. Aus meiner sehr subjektiven Sicht, über die ich mich mit einigen Anwesenden hervorragend streiten könnte 😉, wirst du früher oder später sowieso auf WCF zurückkommen. Zum Beispiel, wenn du einen zweiten Service implementierst, der mit dem ERP-System zusammenarbeitet und komplexere Dinge können soll (und nein, du möchtest das nicht alles in einem Service machen, den du immer mehr erweiterst).

Erst einmal hetzt dich jetzt ja keiner, ein REST-Webprojekt ist auch relativ befriedigend, weil man schnell was "sieht", und du kriegst den Einstieg.

Die Zeit, die du in das WCF-Projekt gesteckt hast, ist jedenfalls nicht verschwendet, weil das erworbene Wissen nicht unnütz ist. Ich bin zwar der Meinung, dass man mit ein bisschen Schrauben an deiner Konfiguration dein Problem relativ schnell lösen könnte - aber wie gesagt, prinzipiell sieht es derzeit so aus, als solltest du erst einmal WebAPI kennenlernen.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

J
Jacyrio Themenstarter:in
197 Beiträge seit 2006
vor 8 Jahren

@LaTino: Bin gerade schon dabei mir ASP WebApi anzuschauen. Allerdings wäre es für mich aber doch ganz interessant an der Config rumzuschrauben um auf die richtige Lösung zu kommen. Sonst sprechen wir uns ansonsten in ein paar Wochen wegen dem selben Thema wieder..

Außerdem: Ich war ja mit dem WCF-Projekt und dem BasicHttpBinding schon soweit, dass ich per URL ein JSON-String zurück bekommen habe. Habe ich die URL mit RestSharp direkt im Client angesprochen, konnte ich auch mit Serialization bzw. Deserialization den JSON-String in mein Objekt umwandeln. Weil Abt aber in einem anderen Thread erwähnt hat, dass WCF die Umwandlung schon alleine macht, wollte ich ausprobieren den WCF Service in mein Client einzubinden.. und da hänge ich nun mit dem eingangs genannten Fehler..

Prinzipiell bräuchte ich kein ASP.. wenn ich das Einbinden auf Client-Seite hinbekommen würde.. allerdings schaue ich mir ASP jetzt trotzdem mal an.

3.003 Beiträge seit 2006
vor 8 Jahren

Ich war ja mit dem WCF-Projekt und dem BasicHttpBinding schon soweit

Mohoment...was?

REST nur mit webHttpBinding, nicht mit basicHttpBinding.

Simple Zusammenfassung: REST / SOAP Endpoints (Stack Overflow)

LaTino
Edit: by the way etwas, das WebAPI nicht kann (und auch nicht können muss) - veröffentlichen ein und desselben Service mit verschiedenen Endpunkten. Was ich persönlich recht abgefahren finde.

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

J
Jacyrio Themenstarter:in
197 Beiträge seit 2006
vor 8 Jahren

Sorry.. webHttpBinding.. nicht basicHttpBinding 🙂
Allerdings würde ich stand jetzt ehrlicherweise keinen Unterschied sehen.. egal was ich benutzen würde X(

16.807 Beiträge seit 2008
vor 8 Jahren

Edit: by the way etwas, das WebAPI nicht kann (und auch nicht können muss) - veröffentlichen ein und desselben Service mit verschiedenen Endpunkten. Was ich persönlich recht abgefahren finde.

Öhm.. das geht schon. Entweder via IIS Bindings oder bei DNX via KESTREL.
Ist nicht 100% identisch aber mit sehr sehr sehr ähnlichem Effekt.

Ich bleib dabei: ich seh hier absolut keine Notwendigkeit WCF nutzen zu müssen.
Wird im Prinzip - meine Erfahrung - mehr Probleme machen als alles andere, mit dem man REST umsetzen kann.

WCF macht die Umwandlung alleine, wenn man WCF auf beiden Seiten hat, zB via bi-direktionaler Kommunikation.
In Deinem anderen Thread hast Du kein Wort von REST gesagt. Da kommt es auf die andere Seite an, ob sie diese Umwandlung automatisch in ein Objekt erledigen kann.
Bin auch nicht auf die Idee gekommen, dass Du REST machen willst; das macht einfach fast niemand via WCF - weil es umständlich ist 😉

J
Jacyrio Themenstarter:in
197 Beiträge seit 2006
vor 8 Jahren

Hab mein erstes Asp Test Projekt schon offen 😃

3.003 Beiträge seit 2006
vor 8 Jahren

Kleiner Nachtrag, falls jemand drüberstolpert. Konfigurationsloser (!) RESTful WCF-Service:


//Servicevertrag
namespace RestWcfService.Lib
{
    [ServiceContract]
    public interface IRestWcfService
    {
        [OperationContract]
        [WebInvoke(UriTemplate = "HelloWorld", Method = "GET", RequestFormat = WebMessageFormat.Json, ResponseFormat = WebMessageFormat.Json)]
        string GetData(); //für Objekt-Rückgaben wird JSON geliefert, s.a. DataContractAttribute.
    }
}

//Service-Implementierung
namespace RestWcfService.Lib
{
    public class RestWcfService : IRestWcfService
    {
        public string GetData()
        {
            return string.Format("Hello, world.");
        }
    }
}
//Konsolen-Hosted
    class Program
    {
        static void Main(string[] args)
        {
            WebHttpBinding binding = new WebHttpBinding();
            
            using(ServiceHost restService = new ServiceHost(typeof(Lib.RestWcfService), new Uri("http://localhost:7337/RestService/")))
            {
                var endpoint = restService.AddServiceEndpoint(typeof(IRestWcfService), binding, "");
                endpoint.Behaviors.Add(new WebHttpBehavior());
                restService.Open();
                Console.ReadLine();
            }
        }
    }

Minimaler Aufwand, keine Konfiguration notwendig. Analoge Umsetzung mit ASP.net WebApi sind entsprechend 3-5 Klicks, die ein bisschen overhead generieren, aber denselben Effekt haben. Webentwicklung ist mit letzterem im VS ein ziemliches Stück bequemer.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

J
Jacyrio Themenstarter:in
197 Beiträge seit 2006
vor 8 Jahren

Guten Abend nochmal,

ich eröffne dafür jetzt mal keinen neuen Thread, sondern verwende diesen hier. Das mit dem ASP WebApi hat gut funktioniert. Habe zwischendurch mal die Self Hosted Variante gefunden, aber schnell wieder der IIS-Variante gewechselt =D

Nun gehe ich einen Schritt weiter und bräuchte nochmal euern Tipp. Der WebApi-Dienst den ich nun Programmiert habe, soll (und nun sagt bitte nicht, dass WebApi dafür der falsche Ansatz ist 😄) als Hauptservice zwischen den Clients und anderen Services dienen.

Eine Aufgabe eines anderen Dienst wäre zB ein Objekt entgegen zu nehmen und das Objekt dann aufbereitet auf einem Drucker auszugeben. Ich könnte den Druck auch direkt in den Service bauen.. glaube aber, es ist besser, die Aufgabe von dem Hauptdienst zu trennen. Jetzt wäre meine frage: Wie würdet ihr das machen? Mache ich einen weiteren WebApi-Dienst und ich gebe das Objekt dahin weiter und beginne dort den Druck? Macht diesmal der WCF-Dienst mehr Sinn? Vielleicht was ganz anderes, was ich noch gar nicht kenne? 😃

Wäre wieder über ein paar Ideen / Tipps dankbar, bevor ich anfange was zu bauen und muss es hinterher wieder über den Haufen schmeißen..

Danke

16.807 Beiträge seit 2008
vor 8 Jahren

Dafür ist jede Art von Web-Service, egal ob WCF oder WebAPI kein geeigneter Weg.
Beide sollten keinen direkten Zugriff auf Systemressourcen wie Drucker haben. Das gilt für alle Elemente im IIS.

Schreib Dir einen Windows Service, der ebenfalls eine API bereit stellt (das kann zB durchaus eine Hosted WebAPI oder eben WCF sein).
Dieser nimmt dann über die Schnittstelle das Objekt entgegen und gibt es an den Drucker weiter.

Der weg wäre dann
Browser > WebAPI > Windows Service > Drucker

PS: das nächste mal ein anderes Thema 😉

J
Jacyrio Themenstarter:in
197 Beiträge seit 2006
vor 8 Jahren

OK danke..

Heißt dann wahrscheinlich auch, dass ich einen eigenen Service für den "Datenzugriff" schreiben sollte? Ich hab zwar ein eigenes Projekt als "Datenprojekt" ist aber in der Haupt-WebAPI eingebunden und greift also über dieses Projekt auf die Datenbank zu.

Wegen dem Thema: Sorry, dachte, dass passt noch zu meinem eigentlich Thema..

16.807 Beiträge seit 2008
vor 8 Jahren

Bei Daten auf Netzwerk-Shares würde ich in 50% der Fällen sagen ja. Bei Daten in Datenbanken oder direkt auf dem Server würde ich sagen nein.
Da reicht eine ordentliche [Artikel] Drei-Schichten-Architektur

Ein Drucker aber ist eine Ressource, der nicht an den Server gebunden ist. Der kann jederzeit ausgetauscht oder woanders hingestellt werden.
Es ist dann bei einem Umzug viel leichter einfach die URL des Windows Service zu ändern statt die ganze Kommunikation direkt zum Drucker.

Es hat auch was damit zutun, ob das ganze natürlich sicherheitsrelevant ist, oder im Kontext des IIS überhaupt funktioniert.
zB kannst Du in einem IIS Kontext nicht so einfach auf WMI zugreifen, weder das eigene noch eine fremde Schnittstelle - außer Du bohrst die Rechte des ausführenden Benutzers auf, was meist keine gute Lösung für Services im Internet ist 😉
Das muss oft unter anderen Rechten erfolgen und auch dafür bieten sich solche strukturellen Umsetzungen an.