Parte 3.- SOA, SODA, XO, quien es primero, el güevo o la ghayina?....

Y el mejor al final...

De verdad si alguien tiene interés en este asunto es un Thread de un grupo de Yahoo, no podría decir otra cosa ("sino en mi muy particular formade expresión") este si ta POCA MADRE


Creo que me voy dando cuenta que en esta platica que hemos venido
desarrollando hay enfoques distintos de lo que es o debe ser SOA.
Fiel a mi constumbre de echarme primero la culpa les comento que
quiza la pregunta inicial con la que empece el topico estaba mal
planteada. Sin embargo hay que reconocer que esto ha llamado la
atencion de algunos miembros del foro por lo que este tema se ha
enriquecido bastante, mas alla incluso de mis espectativas mezquinas
de "analizar" algunas ideas a la comunidad open source (por cierto vi
hoy el sitio del mantaray y me parecen buenas muchas de las ideas,
pero no todas, en fin eso lo comento despues) para integrarlas a la
base de codigo que tengo.

El caso es que por lo que hemos platicado varias personas tenemos
diferentes enfoques de lo que es SOA, aunque creo que lo que he
platicado con javier (y que que jesus, quien ha estado muy calladito)
se acerca mucho a la idea que con la que vengo trabajando hace
algunos añitos: middleware + desacoplamiento + transparencia de
locacion + servicios out-of-the-box + adaptadores + servicios.

Creo que Javier (asumo que por la experiencia en su trabajo y por lo
que le ha tocado hacer) pone mucho enfasis en el tema del BUS
(entiendase transporte, transformacion y traduccion y supongo que se
debe a los ambientes que el comenta),lo cual lejos de ser malo
le "inyecta" (ahora que esta de moda ese termino) versatilidad a la
arquitectura a cambio de complejidad, repito esto no debe entenderse
como una critica ni mucho menos, sino como un enfasis a un aspecto
super interesante de SOA - La integracion (que no los web services).

Por ahi tambien hay algunos que comentaron haber desarrollado un ESB
basado en Spring (¿mr davalos?) de lo cual me interesaria mucho ver
que ventajas les ha dado spring en este tipo de arquitecturas (ademas
de "no necesitar singletons", el "IoC" y el dependency injection (a
cambio de unos super "fashion" archivos de configuracion XML y que
ademas utilizan unos Factorys que ni a los de GoF se les hubieran
ocurrido tales nombres-- el sarcasmo es mio, favor de NO asociarlo al
ESB del Sr Davalos), para ver si puedo aplicarlas o no.


Mas aun, yo creo que las soluciones SODA pudieran ser una manera mas
efectiva de desarrollar las aplicaciones comunes de hoy en dia, pues
permitiria una reutilización de codigo mas transparente, pues en
lugar de reutilizar frameworks, se reutilizan componentes (o
servicios, claro a partir de un framework).

¿Cuantas veces para diferentes proyectos se hacen los servicios de
infraestructura, de datos, de seguridad, etc, etc? y segun yo
(creanme que si he leido dos paginas de spring son muchos) esto sigue
pasando aun y en los proyectos que utilizan spring....¿cierto? por
ahi una vez me enseñaron un "proyectazo" en donde la mayor virtud
arquitectonica era la de "poder desacoplar la capa de
persistencia...mira si ya no te gusta hibernate, la cambias por la
que sea..." ese tipo de afirmaciones son las que hacen daño a las
aplicaciones java empresariales, pregunta ¿el enfoque principal del
sistema era hacer transacciones de negocio o poder utilizar EJB3 en
lugar de hibernate?, amen del tiempo que les tomo hacer eso (creanme
que no fue hacer click derecho->seleccionar framework de persistencia-
>hibernate). Por ahi conoci a un par de programadores, uno era VB y
el otro era de java, el caso es que uno de ellos (VB)le decia al
otro "que onda mi entity bean", burlandose del otro (java) y de
entrada pues a mi no me parecia esta situacion, ya despues entendi
que el tipo de VB se iba a casa a las 6:30 pm, hora que el
programador java seguia divagando entre struts , JSF o spring...¿para
llegar a donde?, creo que por eso el Mr VB le tenia poco respecto
a "Entity Bean"

En alguna ocasion el Sr Alan Williamson (que fue editor del Java
Developers Journal y que en alguna ocasion la comunidad java pidio su
cabeza porque hizo algunos buenos comentarios sobre .NET) escribio
algo asi como ¿DONDE ESTAN LOS COMPONENTES? y hacia el simil que en
java, a diferencia de VB (aunque nos duela) hay pocos componentes que
son realmente reutilizables (claro guardando las distancias). Y es
ahi donde creo que un SODA puede ayudar mas que un "tipico" proyecto
STRUTS+SPRING+HIBERNATE, al menos lo veo para cuestiones mas alla de
las tecnicas (como por ejemplo un SOA roadmap, el Time to Value, el
governance, la "agilidad" para adaptarse a los requerimientos de
negocio, etc.) por favor no quiero empezar una "guerra santa" en
contra de esos frameworks (Claro que no!) pero si me gustaria
escuchar opiniones a este respecto. ¿cuanto codigo se reutiliza con
la manera tradicional de hacer aplicaciones J2EE? (struts|jsf) +
spring + hibernate. ¿Alguien me puede pasar una clase que enforce las
reglas de negocio para un request? ¿out-of the-box? ¿que no requeria
conceptos de AOP? ¿que mi usuario pueda "facilmente" modificar?
¿servicios de reporteo? ¿envio de email desde por ejemplo una
terminal symbol? ¿actulizacion de catalgos en diferentes bases de
datos (replicacion)?

SODA es un cambio de paradigma que valdria la pena explorar, de mi
parte les comento algunos buenos resultados (se escucha la rechila
del respetable ;) aunque en cierto modo me siento un tanto
cuanto "solo" en este tema y por ello repito recurro a la vox-populi
y siempre con una de las premisas de brooks: "no silver bullet"

Ahora algunas respuestas a los comentarios de Javier (para los que no
se han aburrido):

> El problema con la palabra "servicio" es que la mayoría de la gente
> lo asocia con una cuestión técnica, y muchas veces reducida a una
> invocación RPC hecha de una forma ineficiente (SOAP).

como diria el peje "io no ffffjui" (tambien queda esa de "lo que diga
mi dedito")

> ....
> Como se puede observar, nunca se hizo una petición a un sistema en
> particular. Varios de ellos tuvieron que "platicar" entre sí para
> solventar la petición. La petición entonces se hizo a lo que llamaré
> el "servicio de actualización de precios".

Claro y en la medida que puedas "orquestar" esos servicios se pueden
ofrecer servicios de grano mas grueso y ademas es bien importante que
el middleware permita a los servicios, consumir otros servicios.

>
> En una arquitectura SOA el cliente NO SABE el DESTINO FINAL de su
> petición, es decir, no sabe qué sistema o sistemas la resuelven, en
> otras palabras, los sistemas no están acoplados entre sí.
>

ESATO!, pero creo que SOA es un poquitico mas alla de la mensajeria
de transporte, transparencia de localidad, etcet, y tiene que ver con
una estrategia de mas alto nivel para habilitar este tipo de
conversaciones entre los servicios aplicativos para dar "valor al
negocio"

>
> > El tema de la traduccion de los SSD te lo dejo pendiente ya que
> > desconozco como puede hacerse una traudccion, pero a simple vista
te
> > diria que con "otro servicio RPG".
> >
>
> Con adaptadores. Los programas que acceden a los archivos SSD deben
> caminarse para extraer las estructuras de datos, al no existir un
> catálogo por no tratarse de una base de datos relacional.

Asi es precisamente la manera como estoy resolviendo los temas de
traduccion "con adaptadores", y el servicio que me referia seria uno
que "traduzca" cualquier SSD a un formato (aunque repito que todavia
no entiendo bien que es un SSD)

> > tienes razon aparte del mundo java esta el mundo struts, el mundo
DAO
> > el mundo spring-bean, el mundo JSF el mundo entity bean, el
stateless
> > el stateful y todos esos mundos en los que habitan los server-
sides.

Ese comentario pretendia ser sarcastico, no te lo tomes tan a
pecho... a los server-sides me referia a aquellos que su biblia es lo
que otros hacen, no importa si esta bien o mal (si es open source y
lo nombran en el server side "debe ser bueno", si lo bajan del sitio
de apache entonces estan utilizando tecnologia "state-of-the-art").
NOTA: Muchos de los proyectos de apache son EXCELENTES, pero yo creo
que tampoco hay que llegar a ser fanaticos de cuanta cosa se pone
ahi...

> >
>
> ..... me aterra pensar en que un
> programador contratado para construir aplicaciones de negocio, se
> dedique a desarrollar software de infraestructura, cuando la empresa
> para la que trabaja no es una empresa de desarrollo de software.

Queda aqui el caso de "la capa de persistencia desacoplable?"
jajajaa. Efectivamente ¿cuantos de nosotros no tuvimos que escribir
el "service locator", los daos, los Value Objects, etc, etc, etc.

>
> Me he topado con programadores y arquitectos que no tienen el menor
> empacho en admitir que si se les solicita para una aplicación,
¡hasta
> el compilador escriben!

Bueno pana, aqui dejame decirte que hay un dicho en el medio en el
que me desenvuelvo "mientras no sea ilegal o inmoral, pues lo
hacemos" (entiendase mientras nos paguen hasta lavamos baños ;) o
tambien queda esa de chente que dice "mientras aplaudan yo sigo
cantando" (o algo asi). jajajajaja

>
> Son programadores que inclusive no saben qué es REPEATABLE_READ o
> READ_COMMITED porque jamás en su vida lo han tenido que usar.
>

Efectivamente, yo creo que el tema de los niveles de aislamiento de
la transaccion los debe definir el arquitecto, aunque unos buenos
programadores (SCBCD) deben saberlo. una ventaja del data-tier es que
este tipo de temas los vas aislando y "en teoria" la gente que sabe
de eso son las que deben trabajarlo o ¿esperas que un programer sepa
todo? mmm creo que entre el mundo DAO y el service locator hay varias
animas perdidas...jajaja.


>
> > Pero tambien me han servido tus comentarios para mirar el mundo
> > AS/400 y su "cultura".
> >
>
> Más que la "cultura" AS/400 (o más bien dicho iSeries), mi punto va
> dirigido a que Java no es el ombligo del mundo, a pesar de lo que
> muchos quisieran creer. :-O

Claro, claro claro...por eso te comento que tambien esta el mundo
dao, el mundo struts, el mundo JSF, el mundo spring jajajaja. Ya en
serio creo que java es una buena apuesta en el mundo empresarial
(mejor que .NET -rechifla del respetable ;) pero no puede ser la bala
de plata que mate a todos los vampiros, completamente de acuerdo.


>
> (Mala frase para una lista Java, *flame shields enabled*)

No te creas tambien habemos quienes conocimos "otros mundos" ...


Pos pa reflexionar que nos queda sino seguir poniendo cara de what??