Windows Communication Foundation
Nel precedente post ho parlato della lacuna della definizione del contratto nel mondo ROA rispetto al mondo SOA. E' bene che faccia qualche precisazione, ma prima di parlare di questo fatemi fare un escursus sul concetto di contratto e come questo si applichi oggi nel mondo SOA (Service Oriented Architecture).
Se chiediamo ad un avvocato di scrivere un contratto, garantendo un certo introito :-), ci innondera' sicuramente di domande e probabilmente scrivera' 40/50 pagine di documento dove ogni singola parola ha un suo peso specifico. In sostanza la regola e', ogni aspetto non 'normato' o definito rappresenta un threat.
In ambito IT...
ROA sta per Resource Oriented Architecture e si contrappone sotto molti punti di vista a SOA, cioe' Service Oriented Architecture.
In realta' non c'e' un modello migliore dell'altro e so potrebbe tranquillamente affermare che un 'servizio' e' necessario per creare una 'risorsa' ed una 'risorsa' e' necessaria per fornire un 'servizio'. Ciononostante possiamo altresi' affermare che il contesto delle risorse e' decisamente predominante.
Quali sono le caratteristiche di ROA:
Addressability: intesa come capacita' di identificare una risorsa addraverso uno URI ben definito
Statelessness: mancanza di supporto nativo per la gestione dello stato
Connectedness:...
WCF (Windows Communication Framework) e' un framework di messaggistica estremamente estendibile. Piu' di un anno fa, parlai della possibilita' di create un Diskette Trasport Channel. In pratica si inserisce un dischetto nel PC client, la richiesta viene salvata sul dischetto, si porta il dischetto sul server e la richiesta viene letta. Quindi si fa il processo inverso se il pattern di messaggistica e' request-reply. Se e' one-way ci possiamo riposare.
Il protocollo e' molto affidabile in quanto si puo' ridondare assumendo piu' personale. Gestendo ferie e malattie si mantiene il servizio sempre attivo. Il punto di fallimento e' potenzialmente l'hardware (qualcosa si...
WCF rappresenta senz'altro un salto in avanti molto importante per lo sviluppo di applicazioni enterprise. Infatti va tenuto presente che WCF porta con sè una innumerevole quantità di servizi che sino ad oggi sono implementati con ASP.NET web services, System.Messaging (MSMQ), .NET Remoting, Web Services Enhancement (WSE) e Enterprise Services (COM+).
Data la portata del 'cambiamento' abbiamo pensato bene di confezionare una 3 giorni full immersion su WCF illustrandone quelle che sono le potenzialità, come funziona, come si progetta con WCF, come si implementa con WCF, il porting dalle attuali tecnolgie e così via. Non vogliamo fare il ricettario (se...
Il 13 aprile dalle 15:30 alle 16:45 parlerò di servizi :-) In particolare parlerò di come progettare un contratto in modo che sia 'portabile' da ASP.NET 2.0, a WSE a WCF senza dover stravolgere il codice scritto.
Non si parlerà quindi di sicurezza, reliability, scalabilità, ecc. ecc.
Ci vediamo ai community days :-)
L'affidabilità nei web services vuol dire molte cose. Una delle più importanti è sicuramente la certezza della recapitazione del messaggio anche in caso questo messaggio sia partizionato in più parti.
Come consuetudine ogni cosa nel mondo "web services" deve essere regolamentato, per ovvi motivi di interoperabilità. Questo dell'affidabilità non fa eccezzione ed ecco quindi che abbiamo OASIS che si occupa del caso WS Reliable Exchange. Questa specifica nasce un pò da WS-ReliableMessaging e un pò da WS-Reliability e vede insieme sia SUN che Microsoft (fra gli altri).
Fatta questa doverosa premessa, volevo concentrarmi sull'implementazione. WCF implementa il protocollo WS-ReliableMessaging e ci...
Corrado lo ha già annunciato. Aggiungo solamente questo riferimento alle modifiche che trovaremo in WCF.
Chi sviluppa web services avrà riscontratto che sebbene le tecnologie di base (XML, HTTP, SOAP, WSDL, ecc.) siano nativamente interoperabili, è bene ricordare che le nostre scelte sul type system del messaggio si riflettono sul'interoperabilità. Mi viene in mente, ad esempio, l'uso del DataSet nel messaggio (poco interoperabile).
Un interessante punto di riferimento lo troviamo qui.
Tutti i web services implementati con ASP.NET (e/o WSE) adottano SOAP. Se però dobbiamo fare una critica a SOAP allora possiamo dire che è un protocollo a volte troppo 'pesante' per quello che deve fare. Perchè avere un header ed un body se mi server spedire solamente un'informazione banale ? Non basterebbe l'XML (per mantenere comunque l'interoperabilità) senza quegli elementi ed attributi SOAP ?
Questa domanda se la pongono in tanti, ed ecco il perchè di REST e POX. Ma allora perchè SOAP ?
E' bene definire che cosa si intenda per protocolli di integrazione. I protocolli di integrazione (inteso flusso di...
Uno dei nuovi (rispetto alla versione 2000) data source di Reporting Services 2005 è proprio l'XML. L'XML erogato sia attraverso web services ASP.NET (quindi stream SOAP) che su stream XML.
Ecco allora che mi è venuto in mente che in WCF è possibile implementare alcune estensioni che permattano di erogare facilmente servizi in modalità POX/REST. Come ? Beh, Clemens ha fatto molto (ma molto) di più. nelle prossime settimane scriverò un piccolo esempio di servizio per agevolare il lavoro a Reporting Services 2005.
Full Windows Communication Foundation Archive