Architectures (II)

This post is part of the Architecture series of articles, but I don’t know how many more there will be.
When doing an architecture, Togaf states that the outcome should include a description on how the architecture could or will, if we are sure that will happen, evolve.
I think it is very important to reflect the possible future requirements and sketch how the architecture can overcame them. For example, in case more power is required for a certain solution, how this can be achieved or if some non-abstract future security requirements finally have to be applied, how this will be solved.
By showing how this changes can be done in the current architecture, we will achieve 3 goals:
1 – Be prepared for the changes.
2 – Validate the solution.
3 – Show that not only current requirements have been used to design it.

Architectures (I)

When an IT architect designs a new architecture, it has to favor some aspects among others: performance over administration simplicity, administration simplicity over installation simplicity or etc. Depending on the situation and the architect criteria, it’s better to favor one or another. It’s a price that we have to pay, because it’s nearly impossible to get it all.
Once the design has been created, if other IT guys see it, they could think it’s not the best design because everybody has different personal criteria: some people are stability fanatics and they could choose even very old but stable releases. Other could prefer state of the art architectures, etc. And the main problem is that under their personal criteria, they all are right and the rest of the world is wrong.
At this time, I’m reading “Togaf 9: Pocket guide” which has been inspiring for me. Togaf states that there is an initial phase during the design of an IT architecture, where the principles and guidelines of the design have to be set. That means that the Architect has to discuss with the customer or the IT department, which will be the principles and guidelines that will drive the design, and the most import issue, they should be included at the beginning of the design document. By doing that, the architect is setting the rules for the architecture and giving fewer margins for personal criteria.
Many people could think that this is only valid for big architecture projects, but I think it’s not true, even if the architect delivers a sample architecture, that design should also include a chapter with the sample principles and guidelines that are behind it

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.

¿Importa el rendiment?

Recentment estava comparant dos productes SOA amb un col·lega de la meva feina. Un dels productes era el de la nostra empresa: la SOA Suite d'Oracle contra un producte d'una altra empresa. Sense voler ser corporatiu, jo deia que l'altre producte no estava a l'alçada de la SOA Suite per una serie d'arguments com que no treballava amb XPATH, XMLs, no estava basat en estàndars oberts, l'interfície gràfica era poc eficient pel desenvolupament, etc. El meu company que és extranger em va respondre "Performance is all that matters to me". A partir d'aquí poc podíem discutir perque no teníem una comparativa de rendiment entre els productes i ell va afegir que per posicionar-se amb un o altre producte, li agradaria fer una comparació entre el nostre ESB i l'altre producte, veient el número de missatges que ambdós eren capaços de processar.
Llavors a partir d'aquí va continuar comparant SOAP contra REST, dient que el segon és molt més eficient perque no afegeix capçaleres innecessàries, etc.
La meva resposta va ser clara: no m'interessa un protocol d'ús general que no cobreixi el 100% dels casos. REST és més eficient que SOAP en el 90% dels usos, però no admet coses com la correlació, gestió de transaccions, asíncronía (ja només per aixó queda descartat ;-), etc. d'una manera estandaritzada.
Crec que en la història de la informàtica, quasi sempre han triomfat les solucions menys eficients en el rendiment però més estándars i capaces d'abordar un major nombre de problemes.

Compra d'empreses

Recentment he sentit un parell de rumors sobre la compra d'una empresa d'informàtica per part d'una altra i no es tracta de la compra de BEA per part d'Oracle (que sembla un fet). Segur que hi ha alguna cosa del cert ja que ho he sentit de persones que estan en totes dues empreses i els ha arribat de fonts internes i fiables, vamos de "radio macuto".
La persona de l'empresa comprada em deia que era una bona adquisició perque els productes bla, bla, bla, ...
Tinc molt clar que en aquests moments, en les compres del nostre sector, els productes són el de menys, ja que quan hi ha molta diferència de tamanys d'empresa, la gran podria construir amb poca dificultat un producte igual o superior. El que es valora en aquests casos és la imatge de l'empresa comprada en el sector en que es mou i el grau d'implantació en clients, que pot ajudar a:
1) Colocar productes actuals en els clients de l'empresa comprada aprofitant els contactes.
2) Adquirir una posició dominant en el sector que ni una ni l'altra ho podien fer: l'una per massa petita i l'altra per poca implantació.

To be asynchronous or not to be

Segurament el meu primer missatge a un blog hauria de ser sobre un tema genèric com SOA, els frameworks de programació, etc. Prometo dedicar comentaris a aquests temes però de moment començo per un tema que em té apassionat dintre del món SOA: Asincronia. Segurament molta gent pot pensar que és una qüestió banal o fins i tot alguna cosa indesitjable, però en aquests moments estic tant enlluernat pel concepte, que no seria capaç de dissenyar cap sistema sense introduir el patró asíncron d'alguna manera.
Tot va començar quan vaig assistir al simposium que TheServerSide va fer a Barcelona. En una de les sessions en Martin Fowler va fer una afirmació similar a: "l'única manera d'integrar sistemes és mitjançant missatgeria assíncrona". A mi em va semblar una frase dita perque si i a més a més, portava un temps realitzant desenvolupaments d'integració i trobava que el model síncron, si es podia aplicar, era molt millor per l'inmediatesa dels resultats, la no necessitat de correlacionar la resposta amb la pregunta, etc o sigui, la simplicitat. No soc gaire entusiaste dels gurus, però en aquell moment encara ho era menys.
Setmanes més tard vaig tenir uns problemes de rendiment en una infraestructura d'integració mal dimensionada i vaig començar a apreciar que els processos asíncrons eren molt més fàcils de recuperar que els síncrons, ja que els productes d'integració em donaven eines per fer-ho. Tot era molt evident, els processos sincrons acaben o fallen en el mateix moment i en el desenvolupament dels consumidors no sempre hi havia la previsió sobre que fer en cas de fallar.
Volent extreure conclusions sobre el que es podria haver millorat:
1) No sempre es preveu que les coses fallin i els que ens dediquem a la integració hauríem de reponsabilitzar-nos de que les diferents parts pensin en que les coses poden fallar.
2)Vaig veure casos en que es podia haver optat per síncron o asíncron (només calia haver-ho justificat) i vam tirar per síncron i aquí les paraules de Martin Fowler van venir a la meva ment.

Un cop convençut de les bondats de l'assíncronia, m'he dedicat a evangelitzar sobre aquest tema a tothom amb qui he pogut parlar (i no semblar un friki). Finalment vaig trobar una frase lapidaria que resumeix el meu pensament actual:
Many of the benefits of web services can't be realized until asynchronous interaction becomes well understood and widely practiced, and some high-value applications can't be deployed properly or at all without it.
Està escrita al llibre "Loosely coupled: the missing pieces of web services" de Doug Kaye.