Vaya, que interesante es estar donde te agrada, y hablar con quien te entiende, es como disfrutar de una buena comida, o una buena pelicula, o un buen libro, diablos, he hablado hoy por phone con un gran amigo, además "paisano" no creo que se pueda pedir mas, el muy k, se largo a Seattle mes y medio para aprender sobre SOA, mira nomás, es un wey bien chingón, me cae que si, si aterriza quiensabe hasta donde pueda llegar, hablar sobre SOA es divertido, es un razón interesante, pero quedan muchas dudas.... muchas, iré a capacitación el Lunes al respecto, espero poder entender una sola cosa, las demás vendrán de forma natural...
¿Por donde empiezo para hacer SOA?
Seguimos!
jueves, 24 de mayo de 2007
jueves, 26 de abril de 2007
10 consejos para NO adoptar SOA
Este artículo que encontré en esta revista es excelente, lo resumiré en los pasos nada mas, el artículo completo ta en el link.
1. Diseñe un modelo de adopción en el que defina que todos los procesos de la organización participarán en el proyecto, inclúyalos a todos, no deje ninguno fuera. Si usted es un CIO, enlístelos y diseñe usted mismo los servicios que llevará a cabo otra unidad del negocio.
2. Es necesario incluir en el proyecto de adopción a todos los servicios, independientemente de su aportación al valor del negocio. Jerarquizarlos por ese parámetro podría ahorrarle mucho dinero y tiempo.
3. Si generará servicios y/o webservices, que no es lo recomendable, no los conecte entre sí en una plataforma que les proporcione esa capa de interconexión, no es necesario. Aunque, si puede conectarlas a una aplicación integral (del tipo de las monolíticas) en las que añadir un módulo es un dolor de cabeza, mejor.
4. Todos los lenguajes de programación soportan webservices, no se requiere verificar cuál es el más idóneo, si se trata de un estándar o cuál proporcionará flexibilidad y más ventajas a la larga.
5. Abandone todo lo que ha hecho. Aunque la mayoría de las tecnologías existentes en la organización son reutilizables, la recomendación es desecharlas, en especial si son legacy. Es más adquiera una aplicación integral que garantice la integración desde el principio, aunque después sea imposible añadir nuevos módulos. La flexibilidad no es necesaria.
6. Piense en el corto plazo cuando construya su plataforma tecnológica, el futuro es incierto y sería ocioso pensar en lo que mañana tendrá que soportar su negocio (clientes, tecnología, nuevos servicios, capacidad de respuesta, expansión, etc).
7. Concéntrese en la tecnología que tendrá que adquirir, no en las personas o en modelar como servicios los procesos que su organización lleva a cabo.
8. No construya su plataforma tecnológica sobre estándares abiertos, entre menos se comuniquen tendrá mejores resultados.
9. La gobernabilidad de los servicios es un lujo. No es necesario definir las etapas de los procesos ni distinguir quiénes participan en ellos o quiénes son los responsables. Eso daría mucho control.
10. Si está haciendo todo bien, asegúrese de poner en práctica alguno de los anteriores consejos.
Jejejeje, yo sé de algunos que lo aplican a la perfección.
Me quiero volver chango!!!
Ummh porque decir como Homero Simpson, ¡Me quiero volver chango!, bueno pues que quizé ponerle también "el daño está hecho" demonios, yo me acabo de enterar de cosas como SOA, SOBA, Mashups, o al menos la última no sabía que existía, y las otras dos las terminé de aterrizar y me encuentro con definiciones y hasta sitios de donde se puede ahondar sobre los condenados mashups, y pues me gusta la definición donde dice que los mashups están revolucionando el desarrollo web.....
Integración, eso me lleva a una frase que dijo ayer el chango presidente del senado, en la conferencia de la reforma del estado ("trinche nombrecito", siempre me he preguntado quién se ocupa de su publicidad y denominaciones, se la rifan, jejejejeje) que "nadie puede construir nada solo", que bueno, suena a frase de politerco, pero tomandolo por el sentido real, sin la basura, es correcto, nadie puede construir nada solo, tengo ideas, muchas en realidad, pero o de plano no las vendo bien, o de plano nadie me pela, tal es este blog, que parecía "aburrido", pobre mono...
Excelente, a decir de los CIO's ( Changos Infundados en la Organización ) la Web 2.0 no es una moda pasajera, sino a largo plazo, o sease, llegó para quedarse, por eso prefieren a proveedores de soluciones web 2.0 con peso, a pequeños proveedores, por el asunto del soporte y el largo plazo... interesante no...
seguimos, claro que si....
Integración, eso me lleva a una frase que dijo ayer el chango presidente del senado, en la conferencia de la reforma del estado ("trinche nombrecito", siempre me he preguntado quién se ocupa de su publicidad y denominaciones, se la rifan, jejejejeje) que "nadie puede construir nada solo", que bueno, suena a frase de politerco, pero tomandolo por el sentido real, sin la basura, es correcto, nadie puede construir nada solo, tengo ideas, muchas en realidad, pero o de plano no las vendo bien, o de plano nadie me pela, tal es este blog, que parecía "aburrido", pobre mono...
Excelente, a decir de los CIO's ( Changos Infundados en la Organización ) la Web 2.0 no es una moda pasajera, sino a largo plazo, o sease, llegó para quedarse, por eso prefieren a proveedores de soluciones web 2.0 con peso, a pequeños proveedores, por el asunto del soporte y el largo plazo... interesante no...
seguimos, claro que si....
miércoles, 25 de abril de 2007
Ajax & Comet
Jejejeje, no quería terminar el día sin escribir la parte que me gusta mas:
Ajax = css + xml + java script pos procesos asíncronos del lado del cliente, donde las peticiones se dejan para la máquina que está ejecutando la página
Se dice que Comet es la evolución de Ajax, jejeje, ni siquiera tenemos un buen "know-how" de esta cosa cuando ya tienen evolución que basicamente es lo mismo, con la diferencia que los componentes asíncronos también se crean del lado del servidor no del cliente, y viajan a través de la red para el cliente
Loco no?
En fin, espero que si leen sepan ya que cosa es web 2.0 y otras madres.... jajajajajajaa
Haber si seguimos...
Ajax = css + xml + java script pos procesos asíncronos del lado del cliente, donde las peticiones se dejan para la máquina que está ejecutando la página
Se dice que Comet es la evolución de Ajax, jejeje, ni siquiera tenemos un buen "know-how" de esta cosa cuando ya tienen evolución que basicamente es lo mismo, con la diferencia que los componentes asíncronos también se crean del lado del servidor no del cliente, y viajan a través de la red para el cliente
Loco no?
En fin, espero que si leen sepan ya que cosa es web 2.0 y otras madres.... jajajajajajaa
Haber si seguimos...
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??
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??
Parte 2.- SOA, SODA, XO, quien es primero, el güevo o la ghayina?
continuación del thread de yahoo..
Yo pienso que eso depende de la vision que se tenga de SOA, si por
SOA entiendes la adquisicion de un service bus, implementar el modelo
de 6 dominios que propone BEA y ademas el conjunto de aplicaciones
legadas es lo suficientemente grande y dispar como para intimidarte y
lo quieres hacer en un proyecto "de tajo" pues creo que si.
Sin embargo creo que si se tiene una vision "practica", con
metas "mesurables" (como les gustan a los tecnocratas de sedesol) y
sobre todo, que el alcance de la implementacion inicial de SOA este
acotada y no requieras integrar cosas demasiado complejas o dispares
(por ejemplo servicios que requieren archivos de texto procesados en
un mainframe vs servicios asincronos que involucren una comunicacion
host-to-host con otro sistema) creo que se puede tener un "EZ-SOA".
El enfoque que a mi me gusta abordar es iniciar con el desarrollo de
aplicaciones orientadas a servicios (SODA) a traves de un framework
que permita apegarte a SODA sin tanto trabajo de evangelizacion (no
se que es peor, si un fan de win32 y su vision practica de las cosas
o un fundamentalista "capas-patrones-frameworks" de java)
Generalmente para hacer una aplicacion SODA no se necesita un ESB (un
tema super complejo), pero este tipo de aplicaciones es compatible a
la integracion de un ESB conforme se requiera en fases posteriores.
En resumen, mi respuesta a que si SOA es complejo seria "NO" y con
letras chiquitas "tanto"
Es un fragmento que en realidad me parece de lo mas interesante como primero aprender a hacer SODA y luego SOA, había pensado que era al revés, creo que cada vez que busco mas, toy mas confundido... en fin, vamos a ver otro fragmento
A ver una para los de sexto año:
¿Que tan necesarios son los tipos en SOA? ¿Realmente no tener tipos
lo hace inutil para un proyecto serio?
Retomando el ejemplo de Javier: ¿Queremos convertir un VARIANT
(cliente VB) a un SSD (EStructura de RPG segun comentaron)? ¿como
hacer? ¿que debe pasar por el BUS? ¿XML? suena bien, pero ¿el
performance?
Yo creo que si, los tipos son buenos y necesarios (aunque yo los uso
de cierta manera poco ortodoxa) sobre todo para servicios "legados",
pero de plano "inutil" ... creo que aqui si discrepo contigo. Quiza
el mundo mapa me hace pasar malos ratos...
Yo pienso que eso depende de la vision que se tenga de SOA, si por
SOA entiendes la adquisicion de un service bus, implementar el modelo
de 6 dominios que propone BEA y ademas el conjunto de aplicaciones
legadas es lo suficientemente grande y dispar como para intimidarte y
lo quieres hacer en un proyecto "de tajo" pues creo que si.
Sin embargo creo que si se tiene una vision "practica", con
metas "mesurables" (como les gustan a los tecnocratas de sedesol) y
sobre todo, que el alcance de la implementacion inicial de SOA este
acotada y no requieras integrar cosas demasiado complejas o dispares
(por ejemplo servicios que requieren archivos de texto procesados en
un mainframe vs servicios asincronos que involucren una comunicacion
host-to-host con otro sistema) creo que se puede tener un "EZ-SOA".
El enfoque que a mi me gusta abordar es iniciar con el desarrollo de
aplicaciones orientadas a servicios (SODA) a traves de un framework
que permita apegarte a SODA sin tanto trabajo de evangelizacion (no
se que es peor, si un fan de win32 y su vision practica de las cosas
o un fundamentalista "capas-patrones-frameworks" de java)
Generalmente para hacer una aplicacion SODA no se necesita un ESB (un
tema super complejo), pero este tipo de aplicaciones es compatible a
la integracion de un ESB conforme se requiera en fases posteriores.
En resumen, mi respuesta a que si SOA es complejo seria "NO" y con
letras chiquitas "tanto"
Es un fragmento que en realidad me parece de lo mas interesante como primero aprender a hacer SODA y luego SOA, había pensado que era al revés, creo que cada vez que busco mas, toy mas confundido... en fin, vamos a ver otro fragmento
A ver una para los de sexto año:
¿Que tan necesarios son los tipos en SOA? ¿Realmente no tener tipos
lo hace inutil para un proyecto serio?
Retomando el ejemplo de Javier: ¿Queremos convertir un VARIANT
(cliente VB) a un SSD (EStructura de RPG segun comentaron)? ¿como
hacer? ¿que debe pasar por el BUS? ¿XML? suena bien, pero ¿el
performance?
Yo creo que si, los tipos son buenos y necesarios (aunque yo los uso
de cierta manera poco ortodoxa) sobre todo para servicios "legados",
pero de plano "inutil" ... creo que aqui si discrepo contigo. Quiza
el mundo mapa me hace pasar malos ratos...
SOA, SODA, XO, quien es primero, el güevo o la ghayina?
Vamos a ver, creo que en este asunto de la tecnología hay mucho que aprender, sería interesante publicar algo y recibir comentarios, para entablar un desafío, hay cosas que sinceramente no me quedan claro de SOA, sobre todo el asunto del ESB, en un grupo de yahoo vi una discusión por demás interesante al respecto, me tomaré la libertad y un poco el tiempo de sacar fragmentos, y pues habrá que seguir investigando, esto es mas mi documentación que afán de que se entere el mundo de que existe este blog....
Ummhta cada vez ta' mas loco este asunto, en fin, antes de seguir con el dato que andaba buscando veamos (Filosofía XO), sopas, me acabo de enterar me late de entrada en concepto, porque claro es como SODA....
Será parte de otro punto, veamos en asunto del ESB, como dijeron, luego de explicarlo tantas veces "hasta yo me entiendo"
(Ah por cierto un buen ejemplo de comet ya lo encontré ta aquí)
jejeje, este me gusto bastante creo que varias personas podemos entenderlo
SODA soa = (SODA)soa;
Me lleva la chin.... puse como 5 bloques realmente grandes y no caben, lo partimos entonces ... ni modo ...
Ummhta cada vez ta' mas loco este asunto, en fin, antes de seguir con el dato que andaba buscando veamos (Filosofía XO), sopas, me acabo de enterar me late de entrada en concepto, porque claro es como SODA....
Será parte de otro punto, veamos en asunto del ESB, como dijeron, luego de explicarlo tantas veces "hasta yo me entiendo"
(Ah por cierto un buen ejemplo de comet ya lo encontré ta aquí)
jejeje, este me gusto bastante creo que varias personas podemos entenderlo
SODA soa = (SODA)soa;
Me lleva la chin.... puse como 5 bloques realmente grandes y no caben, lo partimos entonces ... ni modo ...
Reflection
Ja, mas bien reflexión, al parecer este trinche blog no le interesa a nadie mas que a mí, y bueno como buenos mexicamos que somos, he recibido un solo comentario, mas shingativo que otra cosa, que cosas no, en fin, sin mas choro, segurié poniendo cosas, por el puro gusto de tener un blog de tecnología....
martes, 24 de abril de 2007
Web 2.0
Güeno al parecer no es muy común como había creído el témino web 2.o
Sucede que no es una tecnología sino un conjunto de tecnologías, es mas un avance y retroceso en cuanto a conceptos, es decir, no hay avance porque se usa lo que antes ya había, basado en lo que antes se hacía, dejar todo del lado del cliente, y no del servidor, así la web 2.0 habla de cosas como
Este demo me pareció interesante....
seguimos....
Sucede que no es una tecnología sino un conjunto de tecnologías, es mas un avance y retroceso en cuanto a conceptos, es decir, no hay avance porque se usa lo que antes ya había, basado en lo que antes se hacía, dejar todo del lado del cliente, y no del servidor, así la web 2.0 habla de cosas como
- RIA (Ajax)
- RSS
- Wikis
- Blogs
- Comet
- google maps (magnifico)
- google suggest ( vientos )
- sitios como el universal y otros con rss
- wikipedia
- blogs como este
- flickr (excelente)
- del.icio.us (raro creo)
- y a mi gusto uno espectacular, muy stand-alone
- meebo (cool)
- La evolución natural de ajax Comet
Este demo me pareció interesante....
seguimos....
Recomendaciones SOA
Ummmh, a mi parecer los mas importante, quizá sea importante saber que es un concepto, como se desarrolla para no decir "Donde descargo el SOA", pero asimismo es de vital importancia saber que no se debe hacer, y que si se debe hacer, o como dicen los gringolandicos "The Best Practices"
Tons vamos con las recomendaciones claro según Gartner para un proyecto basado en SOA
BEST PRACTICES
Para empezar con SOA recomiendan
Considero que una buena practica es ver la evolución de los grandes consorcios, así que el caso de estudio es SAP, quién en su principio ofrecía una plataforma SOA denominada MySAPR3 luego lo migraron basandose en interfaces para los servicios, esta concepto de arquitectura en lo particular me parece interesante, agregando quizá un poco de IoC, jejejeje
Tons vamos con las recomendaciones claro según Gartner para un proyecto basado en SOA
BEST PRACTICES
- Los servicios no deben ser tan granulares
- Según gartner lo mas importante es el BackPlane que es un ESB
- Evitar la proliferación de servicios
- SOA NO es la solución para todo
- # services / # Consumers >> 20 (El número de servicios dividido entre el número de consumidores que lo usan, no debe sobrepasar de 20 , para evitar que se tengan demasiados servicios)
- # of reused services <>
- Too fine service granurality
- Duplicate Service
- Over-specified SOA
Para empezar con SOA recomiendan
- Crear pocos servicios
- Proyecto pequeño para la prueba de concepto
Considero que una buena practica es ver la evolución de los grandes consorcios, así que el caso de estudio es SAP, quién en su principio ofrecía una plataforma SOA denominada MySAPR3 luego lo migraron basandose en interfaces para los servicios, esta concepto de arquitectura en lo particular me parece interesante, agregando quizá un poco de IoC, jejejeje
Suscribirse a:
Entradas (Atom)