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.
diumenge, 1 de juny del 2008
dimarts, 26 de febrer del 2008
¿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.
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.
dimarts, 29 de gener del 2008
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ó.
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ó.
Subscriure's a:
Missatges (Atom)