“…deve usare il nostro web service che come da standard si autodocumenta attraverso il wsdl e le permette di interagire con i nostri sistemi…”

io penso…”…fico, sarà uno scherzo, grazie soap…”

download wsdl…..diamo un’occhiata…eeeeeeeeeee!?!??!!?!?

public string FintaOperazioneAltrimentiNonLavoroPiù(string auth,string parametriRicerca);

…e tonnellate di carta a spiegare come deve essere formattato l’xml dei parametri di ingresso e dei parametri di ritorno…allora ripenso ai capisaldi di SOAP…

Contracts should be designed to be as explicit as possible to minimize misinterpretation. Additionally, contracts should be designed to accommodate future versioning of the service via the extensibility of both the XML syntax and the SOAP processing model.

…cavolo almeno quell’auth…mettetelo in un custom soap header se non vi va bene niente di WS-Security…vabbè proviamo a chiamare e vediamo che succede…

eccezione dal servizio, cosa dice il soap fault?…Object not set to an instance….eeeeeeeee!?!?!?!?e ripenso ai capisaldi di SOAP

Internal (private) implementation details should not be leaked outside of a service boundary

…vabbè almeno usano .net…la classe XXX ha sollevato un'eccezione…spetta che mando la riga dell’errore allo sviluppatore, è nell’errore….

…ho capito l’errore…ho sbagliato il case di un elemento del parametro string da passare come xml…se fosse stato un contratto fatto con criterio questo errore me lo evitavo…

morale: sono stufo di “String XML HTTP POST Services”(POX services) spacciati per "Web Services SOA", per quello c'è REST ;-)

A marzo avevo scritto questo blogin relazione al fatto che un’applicazione RESTful scritta con WCF aveva il difetto che gli URL erano “sporcati” dall’estensione “.svc” richiesta dall’infrastruttura di attivazione.

Ora nel framework 4.0, WCF ha sistemato questo problema con la possibilità di definire un “virtual service activation endpoint”  potendo così attivare servizi senza avere per forza bisogno di un file svc.

Tutto questo chiaramente per un miglior supporto alla programmazione RESTful.

Vi lascio il link con una spiegazione più dettagliata di come si dovrebbe fare(è una beta1), la sezione è intitolata “File-less Activation (no .svc)”.

Buona lettura.

Una delle caratteristiche principali dell'architettura "REST style" consiste nel fatto che ogni risorsa sulla quale possiamo effettuare delle operazioni (HTTP verbs) viene univocamente identificata attraverso una URI. Avere delle URIs “ben progettate” diventa quindi molto importante.

Quando creiamo un servizio REST con WCF ci rendiamo conto che le URIs che ne risultano potrebbero essere “disturbate” dall’estensione .svc, la quale permette all’infrastruttura IIS/ASP.NET di processare correttamente le richieste.

Le URIs risultanti sono simili a questa: http://www.domain.com/ServiceName.svc/Resource
Le URIs che noi vorremmo poter utilizzare dovrebbero essere invece strutturate in questo modo : http://www.domain.com/ServiceName/Resource

Come fare in modo che il tutto funzioni con le URIs "REST style"?

Una delle strade possibili consiste nello scrivere un HttpModule che ci permetterà di mappare l'URI "REST style" con l'URI originaria(con l'estensione .svc). Per implementare questa tecnica di url rewrite, dobbiamo creare una classe che implementi l'interfaccia IHttpModule che consta di 2 metodi Init e Dispose. Nel metodo Init ci viene passato dall'infrastruttura di ASP.NET l'oggetto HttpApplication che utilizzeremo per abbonarci all'evento BeginRequest, nel quale gestore attraverso uno degli overload del metodo RewritePath dell'oggetto di contesto HttpContext (HttpContext.Current) possiamo eseguire il "re-write" dell'URI "REST style" all' URI originaria, utilizzata dall'infrastruttura di IIS/ASP.NET/WCF per attivare l'oggetto che implementa la logica del nostro servizio.
Una volta scritto il nostro HttpModule, basterà registrare lo stesso nella sezione <httpModules> della configurazione di ASP.NET.

Chiaramente rimuovere l’estensione .svc rende la URI molto più “elegante” e “significativa”. Utilizzare una URI “non-elegante” non va comunque contro i principi fondamentali dell'architettura "REST style", però qualche purista potrebbe storcere il naso :-) .

Se a qualcuno interessa una implementazione dell'HttpModule fatemelo sapere che ve la mando o la pubblico.

Un pò di tempo fa mi è stato chiesto se era possibile conoscere quale binding venisse utilizzato per il dispatch di una determinata Operation con WCF.
La soluzione più elegante IMHO è quella di utilizzare l'oggetto OperationContext che porta con se tutto il contesto di chiamata e ci permette di ispezionarne tutte le caratteristiche, comprese quelle del channel su cui è stata effettuata.
Precisamente per conoscere il tipo di binding possiamo affidarci alla proprietà Scheme del Listener che ha ricevuto la chiamata:

 OperationContext.Current.EndpointDispatcher.ChannelDispatcher.Listener.Uri.Scheme

la proprietà Scheme è di tipo string, ad esempio se stiamo ricevendo una chiamata su un binding di tipo http troveremo che la proprietà sarà "http".
Detto questo spetta a noi decidere dove controllare questa proprietà a seconda dell'utilizzo che ne vogliamo fare, potrebbe essere in uno dei tanti punti di estensione di WCF come direttamente nel corpo della chiamata al servizio (che non mi piace molto, ma dipende dal problema da risolvere)

Lascio lo snippet del codice completo creato con il tempate di VS 2008:

public class Service : IService

{

    public string GetScheme(){

                  return OperationContext.Current.EndpointDispatcher.ChannelDispatcher.Listener.Uri.Scheme; 

         }  

}

Ho chiaramente modificato il contratto.