No more IIS7 WCF REST 404 Error!

imagesRecently I’ve been trying to host a WCF REST .NET 4.0 service in IIS7. I downloaded the template for VS2010 used for creating REST services. Running the sample application found on that website worked fine from VS2012. I then switched to hosting the service in IIS7. The result however was a 404 error, not exactly what I was hoping for. I tried on other computer the same thing on his machine with complete success. I looked at the service configuration, IIS7 settings, among other obscure settings without success. Google wasn’t especially helpful since most of the results kept saying things like “add an *.svc file” (which is not required/used in .NET 4.0 REST services), others mentioned changing an IIS7 handler mapping so that the *.svc file would not be required, but none of these solutions helped. Tracing didn’t help me get any closer either.

Still the problem felt like a server issue, so I tried to narrow the search. I eventually came across this blog. There was a link to a question on the MSDN forums that mentions a handler mapping named “svc-Integrated-4.0″. When I looked at my handler mappings in IIS7 it did not contain that mapping. The last post on that question contained a link to the MSDN post One-Time Setup Procedure for the Windows Communication Foundation Samples explaining some steps that need to be taken in order to use the .NET 4.0 WCF services in IIS7.  I followed all procedure that I found on this last link and it’s run. The problem was a wrong installation of Asp.net.

That’s all!

Annunci

REST service – Introduzione

imagesHo avuto necessita’ di implementare alcuni servizi REST in un mio progetto. Ho pensato di scrivere un articolo per tenermi traccia di quello che ho fatto (purtroppo l’eta’ avanza e la memoria invece scompare poco alla volta)…. Quindi iniziamo. Prima di iniziare rispondiamo alla domanda: Ma cos’e’ un servizio REST? REST sta per REpresentional State Transfer ed indica uno stile architetturale (non una tecnologia o una specifica, tenetelo bene a mente) per la realizzazione di soluzioni distribuite.

In internet e’ possibile trovare un sacco di documentazione sui REST quindi ecco qualche link interessante:

Inizialmente REST venne descritto da Fielding nel contesto del protocollo HTTP e questo e il protocollo a livello Applicazione maggiormente utilizzato; ma un sistema RESTful si puo’ appoggiare ad un qualunque altro protocollo che fornisca unvocabolario altrettando ricco.
A di fferenza di altre speci che per Web Service (es. SOAP) REST sfrutta infatti a pieno la semantica e la ricchezza dei comandi HTTP e le sue funzionalita come, ad esempio, la negoziazione dei contenuti.

Abbiamo detto che REST non è un’architettura nè uno standard, ma un insieme di linee guida per la realizzazione di un’architettura di sistema. Ma quali sono questi principi che rendono il Web adatto a realizzare Web Service secondo l’approccio REST? Il tutto può essere riassunto nei seguenti cinque principi:

  • Identificazione delle risorse
  • Utilizzo esplicito dei metodi HTTP
  • Risorse autodescrittive
  • Collegamenti tra risorse
  • Comunicazione senza stato
GET Recupera una risorsa
E’ in sola lettura
Cacheable
PUT Aggiorna una risorsa
Utilizzato anche per creare le risorse se il client ne conosce l’indirizzo a priori
Idempotent
DELETE Cancella la risorsa specificata
Idempotent
POST Crea una nuova risorsa
Unsafe
Il vantaggio di utilizzare i metodi HTTP consiste nel fornire le nostre applicazioni di una interfaccia unica e condivisa.
l principio dell’uso esplicito dei metodi HTTP ci indica di sfruttare i metodi (o verbi) predefiniti di questo protocollo, e cioè GET, POST, PUT e DELETE che sono metodi universalmente conosciuti e ampiamente supportati da diversi framework.
In sostanza, quindi, l’utilizzo dell’HTTP, dei suoi metodi e più ampiamente anche dei suoi messaggi di risposta (Status Code) consente l’accesso alla nostra applicazione a qualsiasi client che li supporta, semplificandone l’utilizzo rispetto al più complesso sistema gestito in SOA.
Come detto questo e’ solo un piccolo memoriale per non perdere informazioni. Se qualcuno cercasse informazioni maggiori, su internet e’ possibile trovare tutorial ed articoli fantastici  che descrivono meglio l’argomento.

Chiamare un servizio java da un progetto .Net

Oggi un mio collega aveva un problema su come utilizzare un servizio java da un’applicazione .Net. La soluzione e’ semplice. Abbiamo due possibilita’ per fare questo:

Tramite WSDL Tool

Naturalmente prima di tutto bisogna creare il servizio in Java… e questo lo lasciamo ad i javaisti… (Io di Java non so proprio nulla…)..

In .Net abbiamo bisogno di una classe di proxy usando il comando Wsdl.exe

wsdl /language:CS /n:"Microsoft.SqlServer.ReportingServices2010" http://<Server Name>/reportserver/reportservice2010.asmx?wsdl

A questo punto bisogna aggiungere la classe proxy al nostro progetto.
Infine bastera’ richiamare il nostro servizio creando un’istanza della classe proxy

ReportingService2010 service = new ReportingService2010();

Tramite Web Reference in Visual Studio

Dalla solution explore selezionare il progetto e cliccare Add Web Reference

a questo punto si aprira’ la dialog box Add Web Reference

A questo punto bastera’ inserire il link dell’endpoint del web service, specificare un nome per la nostra Web Reference e poi cliccare sul pulsante Add Reference

Ora sara’ possibile utilizzare il nostro servizio importanto la direttiva prima

using myNamespace.myReferenceName;

e poi con le seguenti linee di codice:

myNamespace.myReferenceName.ReportExecutionService rs = new myNamespace.myReferenceName.ReportExecutionService();
rs.Url = "http://<Server Name>/reportserver/reportexecution2005.asmx?wsdl"
rs.Credentials = System.Net.CredentialCache.DefaultCredentials

Caricare la configurazione da file con WCF 4.0

Nelle versioni precedenti dovevamo fare realmente i salti mortali per poter leggere la configurazione del client da un file diverso dal web.config o dall’app.config. Tempo fa Pablo aveva proposto una soluzione funzionante ma con la controindicazione di doverci portare dietro molto codice che deve essere manutenuto.
Continua a leggere