Il .NET Framework è certamente più che un'idea vincente, ma non è per niente ?affidabile? come ambiente di sviluppo.

Passatemi questo termine, con il quale voglio semplicemente dire che è una pazzia sviluppare applicazioni di produzione con una beta 1, a pochi giorni dal lancio della beta 2, fissato per il 17 giugno, al TechEd americano di Microsoft. E lo è ancora di più se si pensa che ci saranno molte differenze, annunciate, tra queste due versioni: come dire, un bel passo indietro verso una compatibilità maggiore con i prodotti che hanno fatto il successo di una famiglia di applicazioni per lo sviluppo, prime tra tutte Visual Basic.

In questo momento, dunque, conviene di più investire in applicazioni classiche, le cosiddette, Classical ASP Application, le buone, vecchie e care applicazioni ASP, senza nessun dot net di mezzo.

L'obbiettivo di questa serie di due articoli è quella di analizzare le attuali e future tecniche per lo scambio di dati multipiattaforma e tra server distanti anche migliaia di chilometri tra di loro.

SOAP

Se potessi scegliere (ovvero, se potessi installare su tutti i server il SOAP Toolkit e se potessimo tutti sviluppare COM component, ed ovviamente registrarli sui nostri server) la soluzione migliore sarebbe SOAP.

Cos'è SOAP? Simple Object Access Protocol è uno standard, appoggiato da quasi tutte le grosse aziende impegnate nel settore, tra cui Microsoft, IBM e compagnia bella, basato su XML come formato per lo scambio di dati e HTTP come veicolo preferenziale per lo scambio tra gli stessi.

In parole povere SOAP è il presente, è una tecnologia che, con il toolkit di Microsoft o senza, permette di sviluppare applicazioni che scambino i dati, adesso, subito, senza investire una lira né in nuovi programmi né tantomeno perdendo tempo ad imparare qualcosa di nuovo. Per chi conosce un po' di HTML, XML non è niente di trascendentale.

Per trovare le specifiche complete di SOAP, si veda http://www.w3.org/TR/2000/NOTE-SOAP-20000508/

SOAP, per funzionare, si basa sul modello vincente client-server. Dovranno esistere due script (o due applicazioni), ciascuna con compiti propri. Al client spetterà effettuare le richieste, in un formato comprensibile al server, che provvederà, qualora fosse in grado di farlo, a fornire risposte.

Questo comportamento, dunque, non è altro che una macchina a stati finiti, ovvero un particolare modello, usato in informatica, per descrivere un sistema che a fronte di una richiesta restituisce una ed una sola risposta, in modo non ambiguo.

Una macchina a stati finiti è ad esempio un'ascensore: premendo il pulsante 4 vi porterà sempre al quarto piano, mai al secondo.

Dunque, per progettare un'applicazione SOAP, senza usare il toolkit, è bene sedersi a tavolino ed iniziare a definire per bene quello che l'applicazione dovrà fare.

Due esempi che utilizzano SOAP, potete trovarli nell'archivio di unoscript@lgiorno .

SOAP è uno standard ed è perciò sicuramente molto semplice da implementare, ma in molti casi la sua rigidità è un plus che non da' benefici alla nostra applicazione. In tutti questi casi, quello che ci basta è un semplice sistema di scambio basato su XML.

Nel prossimo articolo, dunque, presenterò un sistema completo e funzionante, basato unicamente su XML.