To be reliable or not to be

El títol d'aquesta entrada és "Ser fiable o no ser" que no significa "Ser fiable o no ser fiable". Per mi qualsevol implementació SOA passa per ser fiable, una altra cosa és que voluntariament, en cert casos, decidim sacrificar la fiabilitat però sempre hem de tenir una opció fàcil per activar-la, per exemple posant una propietat a cert o fals, etc.
La responsabilitat d'una integració fiable passa tant pel proveïdor del servei com pel consumidor. Estudiarem el cas de les interaccions asíncrones: primer, el consumidor lleça la petició d'operació al proveïdor i mentre que aquest últim no confirma la recepció de l'operació, és responsabilitat del consumidor gestionar els reintents, errors, etc.
Un cop el proveïdor ha confirmat la recepció és la seva responsabilitat completar l'operació passi el que passi durant l'execució de la mateixa, per tant, no ha de confirmar la recepció fins que ha guardat la petició en un suport d'altes garanties i que permeti ser recuperada en cas de problemes i així poder refer l'execució: implicaria un rollback de la feina anterior i una segona execució a posteriori. També la reexecució ha d'estar prevista detectant quan s'ha produït un problema i cal fer-ho. Per decidir l'estratègia és important les SLAs que s'hagin compromés.
Un cop s'ha executat l'operació, el servei proveïdor ha de retornar la resposta. Si aquesta arriba mitjançant polling del consumidor, llavors no hi haurà cap problema, en canvi si la resposta és enviada pel servidor també cal implementar una solució similar a la de la petició invertint els papers.
Per últim, ens podríem trobar amb el cas que el proveïdor ha confirmat la recepció de la petició però aquesta confirmació no arriba al consumidor, per lo que aquest tornarà a sol·licitar-ho. Llavors cal distingir peticions repetides i això ho podem fer amb l'element "MessageID" del header del missatge SOAP (regulat per WS-Addressing) que ha de ser únic per a peticions diferents però el mateix per a peticions repetides (responsabilitat del consumidor) i el proveïdor haurà de saber ignorar (reenviat confirmació i resposta) aquelles que ja s'hagin rebut.