Il capitolo 12 affronta l’accesso ai dati ed i web services (sia SOAP style che REST).
I post precedenti sono: ASP.NET, system administration, WPF, protocolli e metaprogrammazione, testing, proprietà, dialog e Visual Studio, first class functions e xml, applicazioni e design pattern, oggetti .NET e IronPython, introduzione a Python, introduzione al libro e il preambolo.
L’esempio sviluppato dal libro in questo capitolo sfrutta ADO.NET, il database opensource PostgreSQL e il data provider Npgsql.
Personalmente mi sento di consigliarvi PostgreSQL che non ha nulla da invidiare a SQL Server e se lavorate con GIS è decisamente una figata. Quì dove lavoor io lo usiamo felicemente per applicazioni di produzione (usiamo anche SQL Server 2000, SQL Server 2005, SQLite e credo anche MySQL).
L’esempio è, prevedibilmente, un programma che sfrutta il provider per fare query, usare bind variables, transazioni e sfruttare i data adapters.
La parte sui web services invece comincia mostrando un esempio che consuma un feed Atom per poi buttarsi sul consumo di un servizio SOAP, MathService.
Sfrutta tool come wsdl.exe per creare una dll proxy del servizio remoto e la usa da Python normalmente:
>>> import clr
>>> clr.AddReference('MathService.dll')
>>> from MathService import MathService
>>> service = MathService()
>>> service.Add(3, 4)
7.0
Data la dinamicità di Python i proxy possono essere creati anche a runtime, ovviamente. Purtroppo però, dato che IronPython non supporta direttamente gli attributi, non è possibile creare un webservice SOAP.
Fortuna vuole che per REST e HTTP le cose siano più semplici. L’autore a questo punto sviluppa un intero servizio REST in IronPython per gestire delle note (composte da titolo, corpo e id). Sostanzialmente oltre ai vari verbi HTTP fa uso di WebRequest, HttpListener, HttpUtility e un po’ di XML.
Una delle applicazioni che abbiamo sviluppato è una web application che espone anche un REST web service consumabile in vari linguaggi in maniera molto intuitiva. Purtroppo, secondo la mia esperienza, devo dare ragione a chi si lamenta della poca interoperabilità di SOAP tra vari ambienti. Mi è capitato di sputare parecchio sangue per interfacciarmi a web service esposti da Java che si comportano in modo diverso da quelli SOAP esposti da .NET (direttamente da SQL Server).