3. SOA en la prctica | PensandoEnSOA.

com - Andrs Hevia

http://pensandoensoa.com/category/3-soa-en-la-practica/

ARCHIVO DE LA CATEGORA: 3. SOA EN LA PRCTICA

El problema de la transaccionalidad distribuida en SOA

Publicado el 24/09/2013| 3 comentarios

Uno de los fundamentos de SOA es la composicin de servicios. Es decir, crear servicios de ms alto nivel a partir de otros servicios ms sencillos. Hasta aqu todo bien, pero que pasa con el servicio compuesto si uno de esos servicios ms sencillo falla!. Si "acemos un servicio compuesto que llama a un primer servicio que modifica el estado de los datos # lue$o llamamos al se$undo, # este falla que ocurre!. Si consideramos este servicio compuesto como un %todo&,

1 de 19

06/11/2013 22:32

3. SOA en la prctica | PensandoEnSOA.com - Andrs Hevia

http://pensandoensoa.com/category/3-soa-en-la-practica/

tendramos que des"acer tambi'n lo que "a "ec"o el primer servicio no!. (radicionalmente, este des"acer o rollbac) de varias l$icas de ne$ocio se "a dele$ado al protocolo de transaccionalidad distribuida *(+o ,"ase -ommit. que implementan la ma#ora de las bases de datos # servidores de aplicaciones empresariales. /e esta manera, los dos servicios e %inclu#en& dentro de una transaccin *aunque se e0ecute en dos mquinas diferentes. # cuando se produce un error, al "acer rollbac), automticamente se des"acen los cambios que "a#an "ec"o estos dos servicios. ,ero que pasa en SOA! decimos que los servicios deben tener ba0o o nin$1n acoplamiento entre s. -omo se lleva eso con el "ec"o de que los dos sistemas implicados en este caso deben entender un protocolo com1n de transaccionalidad distribuida!. 2o parece que "a#a muc"o desacoplamiento. El stac) 3S45 define un estndar para reali6ar esto a nivel del +eb services. ,or des$racia, no "a# uno si no dos *al menos de estos estndares.. 7 si no tenemos muc"a suerte, cada fabricante usar uno distinto. Esto es lo que pasa por e0emplo con el servidor de 89: # el de Soft+are A;. <u' solucin tenemos a esto! pues se$1n los patrones de SOA, la compensacin. El concepto es mu# simple, por cada servicio de ne$ocio que "a$a al$o, tendremos otro servicio para des"acerlo *una especie de -ontrol4= o undo a nivel de servicio.. ,or des$racia, esto no es un des"acer directo a nivel de tabla de base de datos como lo es un rollbac), implica e0ecutar l$icas de ne$ocio # por lo tanto, los servicios para des"acer o para %compensar& necesitan dise>arse e implementarse de la misma manera que sus contrapartes. As pues, # como conclusin, cuando dise>emos un sistema SOA, "abra que tener en cuenta estos dos puntos? 2o podemos confiar en que todos los sistemas *servidores de aplicaciones, bases de datos. soporten el protocolo de transaccionalidad distribuida e incluso, si lo "acen, que implementen el mismo @a transaccionalidad distribuida va en contra del desacoplamiento que deben tener los serviiocs (enemos que pensar desde el mismo dise>o que muc"os de los servicios de ne$ocio que "a$amos deben tener su servicio de des"acer. <ui6s esto implique duplicar el n1mero de servicios a implementar. Aqu puedes ver un artculo *en in$l's. mu# eAtenso sobre este tema.

Tu voto:

te gusta esto?

,ublicado en B. SOA en la prctica

3 comentarios

Poltica de seguridad a aplicar en nuestro proyecto SOA

Publicado el 01/09/2013| Deja un comentario

2 de 19

06/11/2013 22:32

3. SOA en la prctica | PensandoEnSOA.com - Andrs Hevia

http://pensandoensoa.com/category/3-soa-en-la-practica/

Una de las posibles opciones que tenemos para implementar la se$uridad en una arquitectura SOA es la de propagar las credenciales del cliente o del usuario final a trav's de todos los servicios por lo que pase esta invocacin, tpicamente desde la pantalla "asta la base de datos. Ha# que tener en cuenta que en SOA, "a# servicios compuestos # flu0os de inte$racin. ,or lo tanto, un usuario final *un empleado por e0emplo. desde su aplicacin de frontal *"ec"a por e0emplo en Cisual 9asic. puede desencadenar la invocacin a un servicio +eb *al pulsar un botn de un formulario por e0emplo.. ,ara "acer esto, necesita enviar las credenciales del usuario *que puede ser su nombre de usuario. con una contrase>a o un to)en de se$uridad. Estas credenciales lle$arn al primer servicio, # tal ve6, desde este servicio se llame a otro o a otros. ,or lo tanto, las credenciales del usuario pueden via0ar de servicio en servicio, que siempre e0ecutarn la l$ica de ne$ocio en nombre de ese usuario. ,or supuesto, este enfoque tiene varias venta0as en cuanto a la se$uridad # auditora del sistema. ,rimeramente los servicios se securi6an # se de0a pasar a o no a un usuario concreto *con nombre # apellidos.. Adems todas las acciones que se "a$an en el servicio, se podrn $uardar tra6as con el username del usuario final que est pidiendo su e0ecucin. ,or el contrario, esto tiene una desventa0a mu# importante? es necesario dar acceso a ese usuario *o rol que a$lutine a varios usuarios. a todos # cada uno de los servicios por los que puede pasar la invocacin, que pueden ser uno, dos o decenas. As que el dise>o de una arquitectura SOA debemos estudiar nuestro caso en particular # ver si nos compensa el ma#or $rado de se$uridad los muc"os inconvenientes de la propa$acin de las credenciales del usuario. Dealmente, si la se$uridad # auditora de los servicios no es un requisito principal de nuestra empresa ,en mi opinin, no merece la pena. As pues, establecera siguiente poltica de securizacin ? @os frontales se securi6arn mediante roles # se autori6ar a cada rol con unos flu0os de nave$acin determinados *con0untos de pantallas. @os servicios estarn securi6ados con un usuario de aplicacin. Es decir, no es de un usuario *como un empleado.. /e esta manera lo$ramos securi6ar todos los servicios sin tener que $estionar el acceso de todos los roles con todos los usuarios de la empresa. En su lu$ar, slo "abr que "acerlo con los usuarios de aplicacin que sern muc"os menos.

3 de 19

06/11/2013 22:32

3. SOA en la prctica | PensandoEnSOA.com - Andrs Hevia

http://pensandoensoa.com/category/3-soa-en-la-practica/

Esto tiene como principal desventa0a que #a no se tiene la identidad del usuario final cuando se e0ecuta un servicio. ,or lo tanto, no podemos $enerar tra6as de auditora para de0a constancia que cierto usuario est e0ecutando ciertas acciones. Una forma de miti$ar esto sera enviar una cabecera de control en la invocacin a los servicios donde se transmita el usuario *username. del cliente final que est invocado. Es decir, la se$uridad se "ar con usuarios de aplicacin pero se transmitir, adems, este username. -omo conclusin, en este tema como en casi todos, debemos "acer lo 0usto para nuestra necesidad, ni menos pero tampoco ms. Hacer de ms, no tiene que ser bueno, al contrario. ,uede representar un $asto de tiempo # de dinero a medio # lar$o pla6o que nos pasar factura.

Tu voto:

te gusta esto?

,ublicado en B. SOA en la prctica

Deja un comentario

noSOAP o no slo de SOAP vive el SOA

Publicado el 02/05/2013| 1 comentario

#noSOAP
Uno de los primeros conceptos que se aprenden cuando se estudia SOA es que no es lo mismo +eb services *SOA,. que SOA. SOA es un estilo de dise>o de soft+are diri$ido a las necesidades de ne$ocio, que si$ue unos principios bsicos. @a me0or prueba de esto es que "a# bastantes empresas que tienen decenas o qui6s cientos de servicio +eb *con una implementacin estndar de SOA,, 3S/@, etc. etc.. # no es SOA en absoluto. ,or qu' puede ser esto! lo ms tpico es que tienen una integracin punto a punto. Es decir, aunque la comunicacin se estable6ca mediante el servicio +eb, # por tanto en remoto, "a# una relacin directa entre el cliente # el consumidor. ,or lo tanto, se establece un acoplamiento *si bien es cierto que muc"o menor que con otras alternativas #a que es slo en runtime. entre todos los consumidores # proveedores de los servicios. 8ma$inaros por e0emplo EFF clientes contra BFF endpoints. ,otencialmente desde cada cliente se podra llamar a los BFF endpoints, # no solo, si "acemos un servicio compuesto, desde cada endpoint de los proveedores se podra llamar *potencialmete. a los otros GHH. Es fcil de ima$inarse la mara>a de coneAiones que se establecen # la pesadilla de su $estin. que pasa si cambiamos un endpoint de sitio *de servidor.! cuntos cambios deberamos tener! En definitiva, est claro que no por tener servicios +eb perfectamente estndar, se ten$a SOA. ,ara ello es neceario al$o ms? como el desacoplamiento del punto a punto # que el cliente no sepa dnde se e0ecuta el servicio. (ambi'n puede ocurrir al rev's. ,uedo tener SOA sin tener SOA,. El e0emplo ms palmario es DES(. DES( es ms li$ero # por tanto ms fcil de utili6ar *aunque tambi'n es verdad que tiene menos funcionalidades que SOA, # 3S45 relacionados.. ,ero incluso no es necesario ir tan le0os como con DES(. Se puede tener SOA con otras tecnolo$as # forma de comunicarse que en un principio no identificamos como SOA.

4 de 19

06/11/2013 22:32

3. SOA en la prctica | PensandoEnSOA.com - Andrs Hevia

http://pensandoensoa.com/category/3-soa-en-la-practica/

,or e0emplo, puede un sistema que se basa en el intercambio # transformacin de fic"eros de teAto considerarse como SOA! ,ues aunque nos c"oque en un principio, en mi opinin s, siempre # cuando cumpla con los principios de SOA por supuesto. -ules seran estos principios aplicados a un sistema de este tipo! veamos dos de los ms importantes brevemente? Desacoplamiento: es necesario evitar la inte$racin punto a punto. ,or eso es necesario tener una capa intermedia entre el cliente # el servidor que act1e de intermediario # evite que el consumidor # el proveedor dialo$uen directamente. En una arquitectura clsica esto se implementa mediante un ES9. Sin embar$o, no "a# que olvidar que un %bus& antes de nada es un patrn de dise>o que persi$ue precisamente esto. Es posible implementar el patrn de dise>o 9us sin un ES9. Contrato bien definido? aunque estemos "ablando de intercambiar fic"eros, podemos tener una definicin de interfa6 o metadatos del tipo de fic"ero que estamos tratando. ,or e0emplo, podra ser un fic"ero I:@ que describa los campos que contiene el fic"ero *de lon$itud fi0a, con separador de campos, etc. etc.. En conclusin? ,or lo tanto, creo que de la misma manera que se est populari6ando el concepto de noS<@ en relacin a los $estores de persistencia. O0o, que no si$nifica 2O S<@, si no 2ot Onl# S<@. Es decir, tener en cuenta que en determinadas ocasiones es me0or un repositorio no relacional *como el usado por Ama6on, ;oo$le, Jaceboo), etc.. que uno relacional *como Oracle o /9G.. ,ues bien, creo que tendramos que pensar en el noSOA,, es decir, not onl# SOA,. Ha# ocasiones en que por la naturale6a # casustica del problema es me0or implementar SOA *por supuesto. pero no con SOA,, si no con otras aproAimaciones *# no me refiero solo a DES(..

Tu voto:

te gusta esto?

,ublicado en B. SOA en la prctica, SOA

1 comentario

Desacoplamiento versus integracin?

Publicado el 31/03/2013| Deja un comentario

5 de 19

06/11/2013 22:32

3. SOA en la prctica | PensandoEnSOA.com - Andrs Hevia

http://pensandoensoa.com/category/3-soa-en-la-practica/

-uando nos enfrentamos por primera ve6 a los principios de SOA, una de las impresiones que nos podemos formar es que el desacoplamiento es enemi$o de la integracin. A fin de cuentas, el desacoplamiento abo$a por la separacin de los mdulos o servicios de ne$ocio # la mnima dependencia con el resto de activos de nuestra empresa. ,or su parte, la inte$racin busca la siner$ia, la asociacin o combinacin con otros elementos soft+are para formar un nuevo activo soft+are compuesto por otros ms simples para dar ms valor a la empresa *lo que conocemos como servicio compuesto.. As pues, parece que el desacoplamiento # la inte$racin son dos t'rminos puestos pues nada ms le0os de la realidad. (al como #o lo veo, el desacoplamiento es el primer paso para lograr una verdadera integracin segn los principios de SO . ,or e0emplo, en una aplicacin silo que se comunica con el resto de la empresa $racias a mil # una triqui>uelas improvisadas? fic"eros, J(,, tablas, colas, etc. 7 di$o improvisadas porque cuando se dise> la aplicacin no se pens siquiera en que en un futuro no podra se$uir estando aislada del mundo # que tendra que colaborar con el resto de aplicaciones de la empresa. ,ues bien, cuando tenemos una aplicacin de este tipo, lo primero sera partirla en tro6os funcionales *mdulos soft+are.. -mo se "ace esto! esa es la pre$unta del milln Al menos no deberamos perder de vista aquella frase que nos repetan una # mil veces en la universidad? un mdulo soft!are debe tener la m"#ima co$esin interna % el mnimo acoplamieno e#terno. <u' si$nifica esto # cmo se traduce en la prctica! Co$esin es la caracterstica de que al$o es "omo$'neo # es mu# i$ual entre s *al menos esa es la definicin intuitiva que a m se me ocurre.. As que lo primero que tenemos que ver en un mdulo para ver que realmente merece ese nombre es lo que "ace. ,or una elemental separacin de cometidos *separation of concerns. un mdulo no puede, por e0emplo, ocuparse de las cuentas corrientes de un banco # de los clientes por qu'! porque no tienen nada que ver uno con otro, no tendra nin$una co"esin.

6 de 19

06/11/2013 22:32

3. SOA en la prctica | PensandoEnSOA.com - Andrs Hevia

http://pensandoensoa.com/category/3-soa-en-la-practica/

Otra forma practica es ver las llamadas que se "acen desde los diferentes elementos del mdulo # a dnde las "acen. Si resulta que un elemento de un mdulo "ace ms llamadas fuera del mdulo que "acia dentro del mdulo mismo debemos sospec"ar. (iene sentido que un elemento de un mdulo, si tiene co"esin, se relacione ms con el resto del mundo que con sus %compa>eros& de mdulo! pues no. ,ues bien, una vez &ue $emos descompuesto un programa en sus mdulos de soft!are' es el momento de integrarlo. ,ero esta ve6, de manera correcta, si$uiendo los principios de SOA # su desacoplamiento. -mo se "ace esto! -reo que con unas pocas re$las bsicas, si se si$uen con disciplina, podemos salir del paso de la ma#ora de los casos que se nos presenten? E.4 @os bac)ends no se llaman entre s. Se entiende bac)end, el mdulo o mdulos donde se e0ecuta la l$ica de ne$ocio de la compa>a, lo que se llama tambi'n el %core& de la empresa G.4 Un bac)end, por no llamar, no llama a nadie fuera del mismo bac)end. B.4 /os mdulos, incluso en el mismo bac)end, no se llaman directamente. Son llamados por un tercero que coordina u orquesta las llamadas entre s. En conclusin, antes de reali6ar la inte$racin de un sistema #a eAistente, el primer paso para ello es el desacoplamiento.

Tu voto:

te gusta esto?

,ublicado en B. SOA en la prctica

Deja un comentario

Es hora de hacer una revisin de la implantacin SOA en la empresa

Publicado el 10/03/2013| Deja un comentario

7 de 19

06/11/2013 22:32

3. SOA en la prctica | PensandoEnSOA.com - Andrs Hevia

http://pensandoensoa.com/category/3-soa-en-la-practica/

/espu's de varios meses o a>os implantando SOA, es necesario "acer una revisin de lo que estamos "aciendo. ,or supuesto no es necesario esperar tanto tiempo para "acerlo, ms bien es recomendable "acerlo cada poco tiempo *qui6s no ms de dos meses.. ,ero si no "emos "ec"o una revisin de la aplicacin de SOA en la empresa "asta a"ora es cuando menos preocupante. SOA implica la mediacin de determinados parmetros que son vitales para constatar el 'Aito o el fracaso de su implantacin. (Cmo podemos saber si SO tiene )#ito si no sabemos' por ejemplo' cual es el grado de reutilizacin de los servicios*. El ob0etivo de esta revisin es ver primero donde $emos llegado % despu)s $acia donde vamos. Es bastante com1n en un pro#ecto de $ran enver$adura los desvos # cambios de rumbo respecto al previamente tra6ado. /ebemos tener claro "acia donde vamos, pero antes, "a# que ver donde estamos # si estamos en el camino correcto para lle$ar al ob0etivo. 2os vemos en la situacin de que #a tenemos decenas, o incluso cientos de servicios construidos, "emos implantado la reutili6acin de los servicios, la multicanalidad, del desacoplamiento # otros tantos principios de SOA pero se$uro que los "emos implantado! Es "ora de "acer una revisin. Ceo en esta entrada un $uin interesante para reali6ar esta revisin del pro#ecto SOA, lo que llama el %SOA ,ortfolio Devie+&. Entre los ob0etivos de esta revisin estn el determinar si la metodolo$a, los lmites de los contratos estn bien definidos # adems ase$urar que "emos lle$ado el mnimo de redundancia, duplicacin de servicios mientras maAimi6amos la reutili6acin de los mismos.

Sobre los contratos y el impacto sobre el consumo y orquestacin de los servicios

<u' tenemos que revisar! Entre otras cosas *pon$o en cursiva los puntos ori$inales # en normal mis comentarios al respecto.? Acoplamiento entre el diseo del servicio, su descripcin y la lgica de negocio para determinar la agilidad, el coste de desarrollo y mantenimiento Se$1n el principio de Abstraccin, el servicio debe ser una ca0a ne$ra para el consumidor, que ve

8 de 19

06/11/2013 22:32

3. SOA en la prctica | PensandoEnSOA.com - Andrs Hevia

http://pensandoensoa.com/category/3-soa-en-la-practica/

1nicamente el contrato del mismo. ,or lo tanto no puede estar acoplado el servicio con su dise>o e implementacin Guas de diseo de los servicios, definicin del contrato y polticas asociadas Ests $uas son conocidas # entendidas en la empresa! son realmente 1tiles! se estn usando! Consumo esperado y combinacin de los servicios Si los servicios no se reutili6acin, mediante su invocacin por diferentes consumidores o mediante su combinacin para crear servicios de ms alto nivel, SOA es un fracaso. Estamos fracasando entonces! no lo sabremos si no medimos el $rado de reutili6acin. Proceso usado por los desarrolladores para descubrir, acceder, evaluar e integrar los servicios. ,ara reutili6ar un servicio, lo primero que debemos conocer es este servicio #a eAiste # se a0usta a nuestras necesidades. ,ara ello, necesitamos poder %descubrirlo&, es decir, reali6ar una consulta con determinados criterios en una "erramienta que nos localice el servicio que necesitamos *ver El papel fundamental del re$istro de servicios en este blo$.. Cmo el equipo construye y despliega artefactos y como el equipo desarrolla servicios. -mo se estn desarrollando los servicios! se cumple con la normativa de desarrollo! se estn alcan6ando los ob0etivos de productividad fi0ados! Si no tenemos respuesta a esas pre$untas estamos en un aprieto. Esta revisin debe determinar? E. Permite el diseo conseguir las metas de modularidad, configuracin y fle!ibilidad" #ay que tener en cuenta los principios de desacoplamiento, abstraccin, granularidad, interoperabilidad y separacin de cometidos. -laro que lo primero que tenemos que saber es cmo vamos a medir esto. -mo sabemos si un servicio o con0unto de servicios son modulares!. Una forma de saberlo seran las relaciones con el resto de servicios por supuesto no puede "aber referencias circulares o sea, las dependencias deberan ir siempre en un slo sentido? A depende de 9, # 9 de - pero no a su ve6 - de A G. Pueden los consumidores descubrir realmente los servicios relevantes, y pueden los consumidores entender f$cilmente como los servicios corresponden con los requerimientos funcionales y no funcionales. Un elemento vital en la implantacin de SOA es el catlo$o de servicios utili6able por los %"umanos& en tiempo de dise>o.

%os entregables en la evaluacin

En esta revisin que estamos "aciendo, deberamos $enerar unos documentos o entre$ables que de0en constancia tanto de la situacin actual como de las recomendaciones o lneas a se$uir para mantenernos en el camino correcto al ob0etivo. En esta revisin se debera utlili6ar muc"a de la documentacin que debemos tener #a reali6ada para la implantacin de SOA en la empresa. El ob0etivo es "acer "acer una revisin crtica de los mismos para ver su $rado de aplicacin # sobre todo reco$er m'tricas sobre la marc"a de SOA en la compa>a. Entre esta documentacin, est la si$uiente? &odelos de diseo Casos de uso de alto nivel, requerimientos, y descripciones para los servicios e!istentes y futuros Procesos de negocio implantados en 'P& &odelos de servicio y descripciones de los interfaces Artefactos de revisin de cdigo y artefactos maven generados durante la implementacin Practicas del desarrollo de la gobernanta

9 de 19

06/11/2013 22:32

3. SOA en la prctica | PensandoEnSOA.com - Andrs Hevia

http://pensandoensoa.com/category/3-soa-en-la-practica/

Guas de diseo de los servicios #erramientas y frame(or)s de desarrollo Procesos de implementacin de servicios Guas para administracin, monitori*acin, seguridad, etc. Polticas de tiempo de e+ecucin Polticas de seguridad S%A ,Acuerdos de nivel de servicio.structura organi*acional de la empresa &apa de portafolio de servicios Aplicaciones / proyectos Servicios / AP0s Capacidades de negocio y dominio de negocio 1so 2evisin del portafolio S3A .strategias Gobernan*a S3A .st$ndares a utili*ar Procesos de desarrollo

Tu voto:

te gusta esto?

,ublicado en B. SOA en la prctica

Deja un comentario

Qu debemos exigir al constructor de los servicios

Publicado el 01/11/2012| Deja un comentario

10 de 19

06/11/2013 22:32

3. SOA en la prctica | PensandoEnSOA.com - Andrs Hevia

http://pensandoensoa.com/category/3-soa-en-la-practica/

En una empresa $rande, es "abitual encar$ar la construccin de servicios +eb a un proveedor eAterno. En este caso, deberamos establecer al menos, un con0unto de requisitos mnimos que deben cumplir estos servicios. Si$ue le#endo

Tu voto:

te gusta esto?

,ublicado en B. SOA en la prctica Etiquetado 9asic ,rofile, buenas prcticas, $artner, re$istro

Deja un comentario

Crisis de confianza en SOA

Publicado el 09/09/2012| 2 comentarios

-omo es sabido, la implantacin una arquitectura orientada a servicios *que en definitiva no es ms que otra forma de ver el soft+are. no es nada fcil. 7 sobre todo no es una cosa trivial en una $ran empresa. 7 cuanto ms $rande es la compa>a ms se da esta curiosa parado0a? E. (iene muc"os ms dinero para "acerse con todo tipo de recursos t'cnicos # "umanos? t'cnicos cualificados, middle+are, "erramientas, licencias, etc. G. :s difcil implantar el cambio # que la informacin flu#a por todas las personas de la or$ani6acin. (ambi'n en ms difcil el cambio de mentalidad respecto a la arquitectura clsica # tambi'n, por supuesto, ms difcil implantar una nueva forma de "acer las cosas cuando "a# que lidiar con todo tipo de aplicaciones le$ac#. -omo todo cambio, 'ste empie6a por las personas. 7 es difcil de vencer una inercia que "emos llevado durante muc"os a>os de una forma de "acer las cosas. As que dificultades para implantar SO

11 de 19

06/11/2013 22:32

3. SOA en la prctica | PensandoEnSOA.com - Andrs Hevia

http://pensandoensoa.com/category/3-soa-en-la-practica/

aparecen por todas partes. Ha# personas que no quieren cambiar para nada, dara i$ual que fuese SOA que otra cosa, # que no quieren or ni "ablar del asunto, as que no tenemos muc"o que "acer con ellas. Sin embar$o, para las que s estn abiertas al cambio, tambi'n la implantacin de SOA tiene su problemtica. En esta entrada del blo$ sobre los %"andicaps de SOA& #a cit' al$unas de ellas? E. el cortoplacismo imperante G. la comple0idad de la tecnolo$a B. la falta de conocimientos en esta tecnolo$a ,or supuesto tambi'n se podra a>adir la falta de tiempo, # es que muc"as veces el da a da no nos de0a levantar la cabe6a # ver ms all de lo que estamos "aciendo en este momento. Sin embar$o, a mi modo de ver, el peor de todos estos $andicaps es la falta de fe en &ue SO funcione en la pr"ctica, en que compense el sobresfuer6o *# tambi'n sobrecoste. que ello supone. Una especie de desilusin o %falta de confian6a& en este modo de dise>ar # usar el soft+are. As que visto lo visto, me $ustara a mi modesta manera, dar ar$umentos para tratar de convencer a estos profesionales %SOA4EAc'pticos&. Al fin # al cabo 'sta "a sido una de las ra6ones para crear este blo$. ,ero lo me0or es citar a otra persona que sabe muc"o ms que #o de esto. :e refiero a :assimo ,e66ini *Analista en ;artner. que en el prlo$o del libro %SOA ;obernance&nos de0a este par de frases sobre sus principales ob0etivos? 2educir los costes de desarrollo y mantenimiento de las aplicaciones, a trav4s de la reutili*acin de servicios en tiempo de e+ecucin en m5ltiples aplicaciones. 0ncrementar la agilidad del negocio gestionando de manera efectiva el ciclo de vida del servicio ,descubrimiento, definicin, diseo, implementacin, pruebas, despliegue, gestin, mantenimiento y retiro-.

Al menos, merece la pena que pon$amos todo de nuestra parte para adoptar SOA no!.

+n ,ensando +n SO -magen K Dic"ard Asia

K @os "andicaps de SOA -mo 0ustificar el DO8 en SOA

Tu voto:

te gusta esto?

,ublicado en B. SOA en la prctica Etiquetado adopcin SOA, principios

. comentarios

12 de 19

06/11/2013 22:32

3. SOA en la prctica | PensandoEnSOA.com - Andrs Hevia

http://pensandoensoa.com/category/3-soa-en-la-practica/

Los problemas en el desarrollo web empresarial

Publicado el 02/09/2012| 5 comentarios

@levo metido en el desarrollo profesional de aplicaciones para $randes empresas ms de EB a>os, siempre en el mundo 0ava, # en todo este tiempo creo que puedo sacar una conclusin? cada vez es m"s complejo desarrollar una aplicacin o servicio de negocio. 7 por qu' es as! Evidentemente no se debe a una 1nica causa # supon$o que cada uno de nosotros tendr una idea diferente sobre las mismas. En realidad creo que "a# muc"as causas, tantas que no van a caber en este post, as que "ar' una se$unda parte ms adelante. A" van unas cuantas causas?

.l legacy.
Ha# una le# no escrita en la informtica? Cuesta muc6o que na*ca un nuevo sistema o aplicacin, pero cuesta muc6o m$s que se muera

13 de 19

06/11/2013 22:32

3. SOA en la prctica | PensandoEnSOA.com - Andrs Hevia

http://pensandoensoa.com/category/3-soa-en-la-practica/

A poco que escarbemos en la superficie de una $ran empresa, empe6arn a aparecer todo tipo de tecnolo$as, productos, len$ua0es, sistemas operativos, "ard+are (odos ellos diferentes # a menudo incompatibles entre s. -ada uno de ellos de una 'poca "istrica distinta # dise>ado con una mentalidad diferente. -ada uno de ellos $uarda una parte del patrimonio de soft+are de la empresa. ,atrimonio que "a# que se$uir utili6ando # eAplotando #a que su sustitucin por una nueva solucin tendra un coste pro"ibitivo *entre otras cosas porque es mu# comple0o construirlo.. Evidentemente cuantas m"s tecnologas tengamos &ue usar % cuanto m"s $eterog)neas' mas complejo es trabajar con ellas /% m"s caro01

%a intercone!in de sistemas
En este momento #a no nos podemos conformar con un montn de aplicaciones silo aisladas, que no se comunican entre s. (enemos que buscar la colaboracin entre todas ellas para proporcionar a la empresa nuevas funcionalidades de ms alto valor a>adido. En definitiva, tenemos que "acer que decenas de aplicaciones, cada una construida de manera diferente, se "ablen entre s. (Cmo conectamos todo esto e intentamos &ue todas las piezas $eterog)neas trabajen entre s* Este es uno de los ma#ores dolores se cabe6a de un arquitecto (.8. Afortunadamente, a"ora tenemos mecanismos como los servicios +eb # los servicios DES( que son estndar aunque no tienen por qu' ser sencillos precisamente. ,ero todava persisten pro$ramas reali6ados con tecnolo$a de "ace BF # ms a>os que ni siquiera pueden invocar o ser invocados por servicios +eb. Se imponen entonces un enca0e de bolillos difcil de "acer # sobre todo difcil de mantener.

.l paso de aplicaciones silo a orientadas a Servicio

8ndudablemente cuando slo tenas que preocuparte de tu propia aplicacin, # t1 te lo $uisabas # te lo comas, todo era ms sencillo. 2o dependas de nadie aparte de tu equipo. Lnicamente necesitabas saber como construir las pantallas, codificar la l$ica de ne$ocio # acceder a bases de datos. 2ada de acceso a sistemas eAternos, inte$racin con otras aplicaciones, # por supuesto nada de multi dispositivo ,ara aplicar SOA es necesario un cambio de mentalidad en la concepcin # dise>o mismo de las aplicaciones, transformndolas en verdaderos servicios. (ransmitir este cambio en una or$ani6acin $rande es mu# comple0o # costoso, puede suponer meses o incluso a>os.

.!cesiva comple+idad y mala calidad de los entornos de desarrollo

El entorno inte$rado de desarrollo estrella de 89: por poner un e0emplo, # #a "ace M a>os de esto, pesaba 123b % necesitaba 4 3b de 5 6 para funcionar A donde vamos a parar!. 7 no solo eso, tanto 'l como el eclipse sobre el que se basa est pla$ado de bu$s que "acen que la eAperiencia del desarrollo sea una pesadilla. Hemos lle$ado al punto de no creernos nada de lo que dice la documentacin. 2o se puede dar nada por cierto "asta que lo pruebas por t1 mismo. (Se puede ser productivo as*

1n cambio en un solo fic6ero puede ocasionar que no funcione nada

Una de las cosas que cuesta entender, sobre todo para las personas que vienen de entornos tradicionales

14 de 19

06/11/2013 22:32

3. SOA en la prctica | PensandoEnSOA.com - Andrs Hevia

http://pensandoensoa.com/category/3-soa-en-la-practica/

como el Host es que (cmo es posible &ue con un slo cambio en un fic$ero deje de funcionar toda la aplicacin*. En todas las $uas de buenas prcticas, se repite una # otra ve6 aquello de /D7 */onNt repeat #ourself., es decir, no ten$as el cdi$o *ni los fic"eros de propiedades. duplicados, tenlos en un slo sitio # referenciarlos desde donde lo quieras usar. Esto est" mu% bien para mejorar la mantenibilidad de la aplicacin pero es un peligro para la estabilidad de la misma. En este artculo del blo$ ten'is una refleAin sobre esto "aciendo una comparacin *salvando las distancias. del cdi$o con los seres vivos? por qu' los seres vivos no se cuel$an!. 8niciativas como OS;8 tratan de paliar este problema "aciendo posible construir una aplicacin de forma modular de forma que se pueden arrancar, parar # actuali6ad el cdi$o de estos mdulos sin afectar al resto de la aplicacin. Sin embar$o es posible que la adopcin en un entorno productivo en una $ran empresa puede representar muc"os meses sino muc"os a>os. -reo que "abra que revisar esta prctica del /D7, # ver aquellos sitios en los que es conveniente duplicar artefactos para me0orar la estabilidad # el desacoplamiemto aunque empeoremos la mantenibilidad.

Aumento del n5mero de artefactos desplegables y mayor coordinacin necesaria entre ellos
-uanto ms desacoplada est' una aplicacin # ma#or uso "a$a de la orientacin a servicios ms artefactos ser necesario desple$ar. En una aplicacin silo por e0emplo, pude valer con un 1nico desple$able *pantallas, l$ica de ne$ocio # l$ica de acceso a datos.. En SOA sin embar$o la cosa se complica, podemos tener la aplicacin *o aplicaciones. de frontal en un desple$able, los servicios compuestos en otro desple$able para el ES9, la l$ica de ne$ocio en forma de servicios de ba0o nivel en otro. A su ve6 estos servicios # pantallas dependern de otros servicios que ni siquiera son de nuestra aplicacin # viceversa, otras pantallas # servicios de otras aplicaciones dependern de nuestros servicios. Esta claro que es necesario un gran esfuerzo de coordinacin para desplegar la solucin1 7 cuando m"s se complica una cosa' m"s posibilidad $a% de errores. Se$uro que tu "as pasado por estos problemas # por muc"os otros (8ue a9adiras a la lista* ( lguna propuesta para evitar caer en estos problemas*

Tu voto:

te gusta esto?

,ublicado en B. SOA en la prctica Etiquetado adopcin SOA, buenas prcticas, desarrollo +eb

: comentarios

La regla del 20%

Publicado el 04/08/2012| Deja un comentario

15 de 19

06/11/2013 22:32

3. SOA en la prctica | PensandoEnSOA.com - Andrs Hevia

http://pensandoensoa.com/category/3-soa-en-la-practica/

El bueno de Cilfredo nos de0 una re$la basada en la eAperiencia que "a pasado a la "istoria con su apellido? ,areto. Esta re$la de ,areto o la del OF4GF se puede aplicar a muc"os mbitos de la vida, incluida la informtica. 2os dice por e0emplo, que el OFP de los errores en el soft+are estn en el GFP del mismo o que el OFP del coste del desarrollo produce 1nicamente el GFP del soft+are. Aqu lo ten'is en la +i)ipedia 7 puestos a ser ori$inales, durante esta semana, "e "ec"o una refleAin sobre esta famosa re$la # SOA, como no podra ser de otra manera llamndose este blo$ %pensando en SOA&. ,ues bien, esta es mi versin de la re$la de ,areto aplicada a la arquitectura orientada a servicios? 2egla de Pareto en 7S3A8 conociendo el 9:; de los conceptos resuelves el <:; de los casos 7pensando.nS3A 7 cuales son estos conceptos a los que me refiero! @os "e ido t+itteando a lo lar$o de esta semana. Si los le'is, ver'is que no descubren la plvora, #a que son bastante conocidos. Sin embar$o, como suele ocurrir en estos casos no por ser evidentes # de sentido com1n se aplican en los casos reales con la asiduidad que sera recomendable.

16 de 19

06/11/2013 22:32

3. SOA en la prctica | PensandoEnSOA.com - Andrs Hevia

http://pensandoensoa.com/category/3-soa-en-la-practica/

@a primera es saber dnde va cada cosa. Si tenemos una arquitectura de referencia ms o menos estndar, como la propuesta por 89: *ver esta entrada en el blo$., tendremos tres $randes capas de aplicacin? E. El frontal que se encar$a de la interfa6 con el usuario G. @a capa de inte$racin que se dedica a combinar servicios de ne$ocio en servicios compuestos, transformar el protocolo de la informacin , enrutar, etc. *para esto 1ltimo se suele usar un ES9. B. @a capa de ne$ocio, bac)end o core de ne$ocio. ,ues bien, como deca una de las primeras cosas que tenemos que ver es dnde ponemos cada cosa. Al$unos e0emplos? E. Si tenemos que $estionar las preferencias visuales del usuario, como $uardar UD@ a p$inas favoritas, personali6acin del men1, o el tema visual *colores, estilos. de las p$inas se "ar en frontal. G. Una l$ica o servicio que conten$a l$ica de ne$ocio, como el clculo del precio de un servicio, ir en el 9ac)end. B. Un servicio compuesto, "ec"o a base de combinar servicios de diferentes bac)ends en la capa de inte$racin. M. Un nuevo servicio compuesto, "ec"o con la combinacin de servicios del mismo bac)end, en el propio bac)end. Aunque muc"as de estas cosas pare6can obvias no lo son tanto para las personas que no est'n un poco familiari6adas con esta arquitectura con clara separacin de responsabilidades.

.l frontal no tiene lgica de negocio

Uno de los errores en los que se puede caer es en colocar la l$ica de ne$ocio en el frontal. ,or qu' esto es una mala prctica!. En primer lu$ar porque una aplicacin de frontal estar diri$ida a un canal en concreto. ,uede ser una aplicacion +eb para el usuario final en internet, o puede ser una pesada aplicacion bancaria para el canal de oficinas # sucursales. Si ponemos la l$ica de ne$ocio a", tendremos que repetirla para cada nuevo canal, con el coste de desarrollo # mantenimiento que ello supone. Adems, debido al continuo avance de la tecnolo$a, las aplicaciones de frontal tienen una vida ms corta. Hace slo cuatro a>os no eAista el i,"one, # "ace dos no eAista el i,ad, por poner solo un par de e0emplos. Ho# en da, # slo para los smartp"ones # tablets tenemos aplicaciones nativas *iOS # Android 9sicamente., tenemos aplicaciones +eb basadas en H(:@ Q e incluso "bridos de ambos. Sin embar$o, la l$ica de ne$ocio se considera ms estable, con un ciclo de vida que puede superar el lustro fcilmente # que no es eAtra>o que supere los die6 a>os. Sobre todo teniendo en cuenta que en SOA podemos crear nueva l$ica de ne$ocio componiendo servicios de ms ba0o nivel *# muc"o ms estables en el tiempo..

Sin estado
Otra de los conceptos que debemos asumir es que los servicios no deben tener estado, es decir, su funcionamiento no depende de las invocaciones anteriores ni al orden en el que se "a$an estas. Adems de la $anancia en rendimiento, al no tener estado los servicios se pueden implementar con un soft+are ms sencillo # desacoplado.

17 de 19

06/11/2013 22:32

3. SOA en la prctica | PensandoEnSOA.com - Andrs Hevia

http://pensandoensoa.com/category/3-soa-en-la-practica/

Si quieres ver el resto de re$las busca el "as"ta$ 7regla=el9: en t+itter con ms fcil a1n, en la parte derec"a de la p$ina principal de mi blo$ "ttp?RRpensandoensoa.com qu' re$la a>adiras t1!

Tu voto:

te gusta esto?

,ublicado en B. SOA en la prctica Etiquetado buenas prcticas

Deja un comentario

Orientacin a objetos antes que SOA (II)

Publicado el 07/03/2012| Deja un comentario

Hace tiempo, en esta entrada en el blo$, abordaba un tema que creo que es de vital importancia si queremos implantar SOA con 'Aito en nuestra empresa? antes de aplicar SO orientacin a objetos1 Adems de por las ra6ones mencionadas en la anterior entrada del post, cncapsulacin de los datos % desacoplamiento, creo que es necesario "acer "incapi' en otra propiedad, que es natural en la orientacin a ob0etos # mu# necesaria en la orientacin a servicios? la visin de una entidad de negocio como un conjunto de atributos % un comportamiento asociado' que es ni ms ni menos que un ob0eto. debemos aplicar los conceptos de

18 de 19

06/11/2013 22:32

3. SOA en la prctica | PensandoEnSOA.com - Andrs Hevia

http://pensandoensoa.com/category/3-soa-en-la-practica/

-o0amos cualquier entidad de ne$ocio, por e0emplo la de %via0e& en una +eb de via0es por internet. /e forma natural, adems de asociar al via0e determinados atributos, como fec"a de partida, fec"a de vuelta, precio, etc. le asociamos ;comportamiento< o acciones &ue puedo $acer con esa entidad. ,or e0emplo, un via0e lo puedo reservar, lo puedo pa$ar # lo puedo anular. 7 esas son operaciones *en orientacin a ob0etos se llaman m'todos o mensa0es pero eso es lo de menos. que forma parte consustancial con la entidad. =o puedo tener los atributos por un lado % las operaciones por otro. <u' tiene que ver esto con la orientacin a servicios! pues a que si vemos as las entidades de nuestro negocio /atributos > comportamiento0 es casi natural identificar el servicio. Esto es, "abr un servicio de ne$ocio que podramos llamar %$estionar Cia0e& con tres operaciones? reservar *fec"aHasta, fec"a/esde, destino. pa$ar*locali6adorCia0e. anuar*locali6adorCia0e. Si no tenemos en cuenta este concepto, bastante sencillo e intuitivo, de que una entidad de ne$ocio est formada por atributos # comportamiento, en el paso a servicio lo pasaremos francamente mal. -omparte este artculo?

Tu voto:

te gusta esto?

,ublicado en B. SOA en la prctica Etiquetado orientacin a ob0etos

Deja un comentario

'log de >ordPress.com.

.l tema Coraline.

19 de 19

06/11/2013 22:32