Serializzare un Expression Tree e spedirlo al server per deserializzarlo e aspettarsi dei risultati è tutto quello che volete ma non è di certo qualcosa che ha a che fare con SOA :-)
SOA: 4 tenets
  1. Boundaries are explicit;
  2. Services are autonomous;
  3. Services share schema and contract, not class;
  4. Service compatibility is based upon policy;
Mindmapping… aka elucubrazioni :-)
Diciamo che avete questo scenario, per noi a oggi decisamente concreto:
  • A prima vista la necessità sembrava quella di dover realizzare una “becera” applicazione client-server;
  • poi scoprite che l’utilizzatore finale avrà qualche “decinaia” di installazioni sparse per i nostro piccolo mondo… uno piccolino insomma :-)
è lecito secondo voi farsi queste domande?
  1. è ipotizzabile che gli aggiornamenti dei client, dei server o di entrambi non siano contemporanei? quindi è uno scenario plausibile che ci siano in esecuzione contemporaneamente versioni diverse del client o del server senza che questi lo sappiano?
  2. è sensato pensare che il repository dei dati sia uno ed uno solo per tutto il mondo?
  3. è sensato pensare che 2 richieste consecutive, verso lo strato dei servizi, vengano evase dallo stesso server?
  4. è sensato pensare che ci possa essere una richiesta che viene evasa con successo ma che non da una risposta nonostante il chiamante se la aspetti?
  5. e… di conseguenza è sensato pensare che il client possa riprovare “all’infinito” finchè non ottiene la risposta che gli interessa senza che questo “sminchi” (termine molto tecnico) tutto?
Se vi fate queste domande e se rispondete “si, no, no, si, si” allora probabilmente un’architettura basata su principi SOA è la vostra “soluzione”.
Un contratto è per sempre…
Dicamo che i punti 2, 3, 4 e 5 sono probabilmente “seghe mentali”, ma vanno analizzati a fondo e soprattutto qualcuno mi deve mettere nero su bianco le risposte (ciò che non è scritto non è mai stato detto ), il primo punto però in un’applicazione geograficamente distributia è decisamente plausibile.
Come possiamo gestire il fatto che in un determinato momento t un client in America Latina faccia una chiamata ad un “metodo” di un servzio in Europa e che la firma di questo metodo sia radicalmente diversa da come il client si aspetta?
Problemi…
Mixxando il mio modo di vedere le cose e le fantastiche uscite di Giorgio ,collega in Gaia e compagno di banco, direi:
i problemi sono come il cucchiaio, non esistono… :-)
Se ci pensiamo stiamo affrontando il problema dalla parte sbagliata, lo stiamo affrontando con la “vision” (in questo caso ottusa) dello sviluppatore che è fossilizzato sul chiamare un metodo di un’istanza.
E’ Visual Studio che ci trae in inganno, o meglio svcutil.exe, generando un “robo” che ci permette di invocare metodi e aspettarci eventuali valori di ritorno, in realtà sotto sotto un servizio ragiona solo ed esclusivamente a “messaggi”:
  • Un messaggio viaggia dal client verso il server;
  • Un messaggio viaggia dal server verso il client;
Nulla di più ne nulla di meno, cosa ci limita nell’usare lo stesso approccio? o meglio, nell’usare il servzio con chiamate a basso livello? nulla, se non la nostra sanissima abitudine alla tipizzazione forte, e magari un po’ di pigrizia… ;-)
Se però ci pensiamo è proprio quello che ci serve:
  • il client prepara un messaggio di un certo tipo;
  • qualcosa serializza quel messaggio di un certo tipo in qualcosa di un certo tipo che però è spedibile “on the wire”;
  • un server riceve il blobbone e delega a qualcuno di deserializzare il tutto in un messaggio di un certo tipo;
  • il server analizza il messaggio e la versione e decide se, e come, farne routing verso un altro server;
  • il ricevente delega a qualcuno l’onere di processare il messaggio;
  • il tutto procede in senso inverso se c’è un’eventuale risposta;
Provate a condire questa cosa con un bel po’ di sano IoC e di DI e ottenete una cosa che almeno sulla carta è decisamente figosa. Vantaggi:
  1. Avete comunque una tipizzazione molto forte;
  2. Avete controllo totale sul versioning, sul routing e sul dispatching in maniera totalmente trasparente;
  3. potete atomicizzare/serializzare un set di messaggi;
Svantaggi:
  1. Se lo dovete dare in mano ad un rookie dovete sbattarvi non poco per rendere rookie-developer-firendly il tutto, ma i gioco, imho, vale decisamente la candela;
  2. … nonzo :-)
Live!
voci di corridoio mi dicono che ne parleremo dal vivo, Giorgio ed Io, probabilmente in 2 occasioni una prima dell’estate e una in autunno, stay tuned ;-)
.m