Tra il codice e la realtà

In un ottimo articolo Kyle Brown, elenca tre “comuni” problemi che affliggono i Web Services basati su XML (SOAP o meno). Merita una lettura attenta perché non mette in evidenza  le meravigliose capacità di un qualche tool, libreria o linguaggio, ma collega a errori di principio nel design i disastri che si riesce a produrre anche in contesti abbastanza semplici e con strumenti tutto sommato ben conosciuti.

Il primo errore è davvero banale e non mette in evidenza nulla di “profondo”: gestire messaggi da parecchi megabyte, magari con dati binari (senza forse neppure accorgersene) è semplicemente una scelta da incapaci; non è certo un problema dell’XML.

Il secondo è invece molto più interessante, perché è davvero una forza che guida spesso il design: definire i servizi ad un livello esremamente basso (ad esempio a livello di ogni singola operazione SQL). Perché (come dice Brown) “[…]such low-level data services often fail.” ? A mio parere il discorso è molto generale: Un Web Service dovrebbe rappresentare un’interfaccia che maschera la complessità che si trova a monte, semplificandone l’utilizzo in base alle esigenze di chi si trova a valle. Purtroppo invece scrivere un XML o richiamare un servizio non è più facile che accedere direttamente ad un DB e scrivere l’SQL relativo, né maschera alcuna complessità o dettaglio implementativo se il contenuto informativo necessario a richiamarlo è in relazione biunivoca con l’SQL utilizzato. Introdurre un layer (o un’interfaccia per l’accesso di una qualche risorsa/servizio) deve essere motivato da concreti vantaggi nel contesto specifico e non è certo buono in astratto e in generale.

Il terzo problema è paradossale e viene fuori soprattutto con SOAP: siccome non è comodo né banale definire gli schema in modo completo e soprattutto non è facile modificarli, spesso alcuni servizi sono solo semi-definiti con una parte (spesso predominate) magari ancora in XML, ma non parte dello schema della richiesta. Questa situazione è spesso solo la spia del fatto che si è sbagliato nel definire le interfacce, che risultano complesse ed devono essere cambiate molto spesso, perché sono poste al livello sbagliato.

Ultima nota a livello generale: in programmazione qualcosa di inutile è quasi sempre dannoso, specie un’astrazione.