Dentro de mi trayectoria profesional he visto diversos tipos de sistemas, así como diversos tipos de arquitecturas que los envuelven, y debo reconocer que no me simpatizan ni me gustan las arquitecturas web cliente/servidor que no esconden el core de la información exponiéndolo directamente a la capa de presentación (web o stand-alone de ventanas). Básicamente por un tema de practicidad en la mantención, seguridad y rendimiento.

En este caso caen la mayoría de aplicaciones web escritas en lenguajes de scripting como PHP o ASP, las cuales no pasan por algún motor o core que gestione las tareas más habituales, recargando código extra en la presentación (páginas que pesan más de 1 MB) o exponiendo directamente el motor de base de datos para que sea atacado con alguna técnica de exploit.

Hoy hablaré de Tuxedo, uno de los primeros servidores transaccionales para los sistemas de backoffice.

Tuxedo (Transactions for Unix Extended and Distributed Operations) fue desarrollado en 1984 por la AT&T para atender peticiones online de transacciones remotas, lo que en informática se conoce como OLTP. Posteriormente fue comprado por Bea Systems, hasta que Oracle se lo comió, y lo potenció.

Tuxedo básicamente es un servidor de aplicaciones para lenguajes no Java. Provee un puñado de funcionalidades que ayudan a sus clientes a desarrollar y desplegar aplicaciones empresariales escritas en lenguajes como C, C++, COBOL y Python (este último mediante la tecnología SALT). Como buen servidor de aplicaciones que es, provee contenedores para hostear la lógica de negocios siempre y cuando esté escrita en dichos lenguajes.

Tambien provee facilidades para distribuir de manera transparente las aplicaciones en un cluster de máquinas y balancear la carga de las peticiones. En caso que falle una máquina o la red falle, Tuxedo automáticamente derivará las peticiones a cualquier servidor que se encuentre disponible en el cluster, entregando una alta disponibilidad. Cuando dichos recursos son retornados al servidor habitual, Tuxedo automáticamente los reutilizará, así se tiene un sistema de failover y failback.

Tuxedo tiende a seguir el paradigma RASP (Reliability, Availability, Scalability, and Performance) el cual provee una uptime entre un 99.9 y un 99.999% para sus aplicaciones corriendo de manera contínua por años, sin caídas (Salvo claro, los típicos errores de capa 8 por parte del programador). Independiente de ello el tiempo de respuesta promedio es de 35 microsegundos, y en ambiente cluster, puede atender tranquilamente 100.000 peticiones por segundo.

Todo en Tuxedo es un servicio que puede ser accedido por su nombre. Un cliente simplemente "llama" a un servicio por su nombre pasándole un buffer de información (donde se encuentra la chorrera de parámetros) lo que se denomina el TPCall. Al recibir cada TPCall Tuxedo enruta la petición al servidor más capaz de atender la petición y la despacha. El servidor atiende y retorna un buffer conteniendo la respuesta del servicio (con su chorrera de parámetros). 

Las peticiones pueden ser sincrónicas, asincrónicas, encoladas o uno a uno.

Otros servicios provistos por Tuxedo incluye la monitorización de transacciones (de tipo XA), mensajería de tipo "store and forward", mensajería según paradigma "pub/sub", calidad de servicio (QoS), puertas de enlace a colas MQ, pasarelas TCP para conectarse a sistemas CICS y conectores Java para servidores de aplicación (El conector JATMI).

Los clientes Tuxedo pueden estar escritos en C, C++, COBOL, Dot Net, PHP y por supuesto, Java.

Con la nueva característica SALT, Tuxedo soporta webservices SOAP/HTTP(S) de manera bidireccional, permitiendo enchufarse en ambientes SOA. Con SALT, los servicios Tuxedo ya existentes se pueden disponibilizar como webservices sin cambiar la plataforma mediante lo que se denomina "wrappers" que empaquetan las lógicas de transformación permitiendo una integración más transparente entre sistemas de tipo legacy.

Tuxedo también provee extensivas capacidades de administración y monitoreo mediante el Monitor de Tuxedo (TSAM), que permite mirar de extremo a extremo la performance del servidor y sus servicios asociados.

Hasta ahora Tuxedo ha sido usado por muchos clientes para migrar sus aplicaciones COBOL desde entornos legacy tales como IBM en costosos refrigeradores a infraestructuras más minimalistas y económicas. Para este tipo de usuarios, tuxedo provee un producto denominado "ART Workbench" que permite realizar de manera automatizada la migración de los ambientes y las aplicaciones al paradigma mediante transformación de código con APIs compatibles para Tuxedo. Así, la lógica de negocio sigue tal cual y sólo las API's de bajo nivel se modifican, haciendo que el cliente reduzca costos y ofrezca mejor calidad de servicio. 

El año pasado sugerí a mi empleador que comenzaramos a compartir los hints, trucos, tips y otras yerbas relativas a nuestra labor diaria en algún repositorio tipo Wiki, hasta que hace poco muy tiempo se me encargó dicha honorable misión de poner de pie nuestro Wiki interno, con el objetivo de centralizar y difundir el conocimiento en temas del día a día. No he realizado mediciones estadísticas de cuánto ha aumentado la productividad pero sí empíricamente reconozco que el tener todo nuestro know-how al día nos ha permitido sacar de dudas rápidas, inducir en menos tiempos a nuevos integrantes y corregirnos dudas que quizá, a lo mejor siempre teníamos.

Quise poner una ilustración de la película Tangled (Enredados) de Disney para hacer la analogía sobre un problema que aún persiste en organizaciones o fábricas de software que contratan a arquitectos tecnológicos. La leyenda dice que la "Torre de Marfil" era un lugar muy alto donde un estudioso se dedicaba a perfeccionar sus técnicas aislándose del mundo, de las personas, de la tierra y de lo mundano.
Este fenómeno afecta en los equipos de desarrollo de líneas de software debido a que se producen los siguientes problemas:

a. Un arquitecto divo no necesariamente sigue las líneas o estrategias de la fábrica de aplicaciones manteniendo dobles estrategias que favorecen al entorpecimiento de planes a corto y mediano plazo.

b. Un arquitecto estudioso es necesario para poder sugerir la adopción de nuevas tecnologías u herramientas pero al estar fuera de contacto con el día a día de los desarrollos puede generar grandes roces, sobretodo al personal renuente a los cambios. Por ejemplo el arquitecto implanta la introducción de un patrón de diseño diferente a los ya aplicados previamente. Eso puede hacer incrementar los costos de hora/hombre en los teams junto con generar discrepancias, roces y sobrecarga extra.
c. Un arquitecto que fue sólo ingeniero de software de cartas Gantt sólo generará un tremendo divorcio entre los desarrolladores y la plana administrativa. Lamentablemente a veces las mejores decisiones son las que toman los obreros, y no el capataz por mucha obstinación que exista. Le llamo el "tiempo de trajin".
d. Un arquitecto que crea una definición paralela a la que ya existe porque se le dio la gana no sólo puede causar discrepancias internas, sino que también genera costos extra por poder hacer el parchado de los desarrollos ya existentes (o el rehacerlos).
e. Un arquitecto que no baje de la torre a compartir y enseñar conocimientos o supervisar a los teams no será un gran aporte, sólo pagar por pagar.

Siempre cualquier apreciación será bienvenida.

JAD corresponde a la sigla "joint application development" propuesta por Drake Josh y Tony Crawford de IBM. Su objetivo consta de brindar a los desarrolladores de sistemas y a sus usuarios una sinergía de opiniones y respuestas promoviendo un ambiente altamente creativo a la hora de conocer los requerimientos funcionales para desarrollar un sistema de información.
Se basa en mantener reuniones, en las cuales se capturan toneladas de requerimientos y especificaciones.

- El Sponsor ejecutivo: Personaje de confianza de la empresa, que se encarga de supervisar y tener a cargo al proyecto. Debe ser un ingeniero de software.

- Expertos de la materia: Son los usuarios de la empresa interesados, los trabajadores que podrían utilizar la aplicación junto con expertos que puedan ayudar a un buen entendimiento. Se entiende que cuando se habla de expertos externos pueden ser analistas funcionales, como psicólogos con conocimientos de informática a nivel de analista o periodistas con conocimientos de informática para hacer las preguntas indicadas.

- Facilitador o líder de sesión: Dirige la minuta, dirige la reunión, identifica los puntos pendientes y asigna los turnos para hablar, pero no contribuye en la solución final.

- Escribano, modelador, documentador: Guarda y publica los procedimientos de la reunión pero no contribuye con informacíón útil al contenido. Puede ser un periodista como un escribano con conocimientos de informática.`

- Observadores: Miembros del team de desarrollo asignados al proyecto. Se sientan detrás de los participantes y observan, pasando las observaciones al facilitador.

Con dos semanas de rondas JAD es más que suficiente para capturar todos los requerimientos funcionales y no funcionales para levantar la arquitectura de una gran aplicación. Por otra parte, cabe mencionar que antes de las rondas JAD se deben seguir los siguientes pasos que no dejan de ser clave:

Tipos de arquitectos de software y el grado de importancia en una organización.

Me encontré de casualidad navegando por Wikipedia con un artículo en inglés acerca de los software architects, y creo que es interesante destacar una parte del escrito, que habla mediante una tabla comparativa acerca de los tipos de SA (sigla utilizada para software architects).

Por supuesto que traté de no traducir, sino que de interpretar lo que se decía adaptándolo a nuestra realidad. En síntesis, se pueden distinguir tres tipos de arquitectos enfocados a software. Por una parte, los de enfoque empresarial. También se les puede decir "arquitecto tecnológico" ya que es como se busca en los avisos de empleo. Deben tener una gran capacidad de comunicación entre las personas, manejo de conflictos, pensamiento lateral y estratégico, debido a que sus labores oscilan entre los diversos proyectos que se estén desarrollando, y como quien mucho abarca poco aprieta, el nivel de preocupación por desgracia al momento de validar un diseño no es el que un ingeniero de software o un programador puede esperar. ¿Necesitamos en las organizaciones personas dedicadas a mirar informes y decir "Si" o "No" cual pulgar romano en un coliseo? .... Posiblemente, pero cuando se requieren evitar aberraciones o "arrancadas de tarros" en los desarrollos deben existir otros tipos de arquitectos como los de soluciones, y los de aplicaciones. Los segundos miran de manera más minuciosa el diseño, evitando desbordes innecesarios. Necesitan un alto grado de imaginación, junto con un pragmático criterio y profundos conocimientos para atender todas las dudas que surjan en los teams, y es el enfoque ideal para una gran organización puesto que nunca habrá sólo un proyecto en desarrollo, y siempre hay que estar atendiendo inquietudes, validando diseños, cotejando arquitecturas, frenando pecadillos de programadores, etc.
Para el último, es la simplificación del segundo, pero para un sólo equipo. Pero como eso en la realidad no ocurre... Entonces, ¿Cuál es el indicado? ¿Quién tomará las decisiones respecto a las compras de hardware y aplicativos? ¿Quién se alineará mejor con los objetivos estratégicos de cada organización?
Ese es un cuestionamiento muy relativo, que depende de cada realidad.

Cualquier observación o apreciación, siempre atento a escuchar sus inquietudes.

Al oido: Can't fight this feeling - Sophie Ellis Bextor

Como es clásico de todos los años, es hora de emitir mi balance, correspondiente al año 2010. Esta vez los dividí por tópico para que se vea más ordenado y compacto.

Comencé con el pie derecho este año, en una nueva empresa, realizando labores que ya se están comenzando a aspectar para donde quiero orientar mi carrera profesional, al menos en lo que es informática. La empresa es pequeñita pero con un gran grupo humano, y con muchísimo por hacer (y entregar) en temas relativos a SOA. Al ser estable, me ha permitido crecer aún más como profesional.
Además, puedo decir que "al fin" pude sacar la certificación profesional SCJP (Programador Java 5), para reforzar un poquito más lo que sé hacer y puedo dar.

Salud

La salud a pesar de que me ha traicionado unas cuantas veces, pude sobrevivir este 2010 sin grandes contratiempos, pero sí con unos cuantos sustos que me hicieron pegar un gran replanteo de vida, por algo decidí migrar de región y ciudad, viviendo en mi propio hogar.
Muy pocos resfríos, bien acotados gracias a la vacunación y mis extremos cuidados.
Sustos por el lado de una gran posibilidad de una diabetes, pero si se tiene bajo control, no tendré grandes problemas... Aunque reconozco que soy MUY goloso, y los dulces son mi tentación.
Se podría decir, que terminé el año física y mentalmente muy cansado y espero con ansias las vacaciones.

Afectivo

Éste fue un año de refuerzo en el aspecto familiar, lo cual me ha servido como soporte y apoyo para tanta presión durante el año, no puedo estar más en calma por ello. Una que otra discrepancia, pero nada complicado. Independiente de ello, actúo sólo contra el mundo, y ya me he habituado a eso, por lo tanto para cualquier actividad o espacio que precisa de la individualidad me siento en total control. En pocas palabras, la autosuficiencia me viene bien. El problema ocurre cuando ocurren cosas como eventos donde te dicen "Venga acompañado"... Simplemente ¡Plop! 
Par de reencuentros con el pasado. ¡Ouch! Mejor dar una vuelta a la página para evitar nuevos malos entendidos con sus respectivos malos ratos. 

Finalizado el balance, procederé a emitir mi lista de objetivos para este 2011 que se viene interesante. Esta vez son más más acotados, y realistas, pero en realidad, mientras menos cantidad de objetivos, entonces las podré cumplir. Tales como:

- Aprovechar algunos tiempos muertos para estudiar, repasar, leer en calma y comprar un lector de e-books (Realmente me hace mucha falta).
- Buscar un par de nuevas actividades para después del trabajo dentro del poco tiempo que dispongo. Esto sí que me es importante, ya que quiero romper el esquema (de la casa a la pega, de la pega a la casa). Tengo claro que acá hay mucho por hacer :)
- Comprar una cámara, porque la mía falleció. Le tengo que hacer sepultura.
- Decorar aún más el departamento.
- Preparar más cosas ricas (pero que sean sanas).
- Seguir cumpliendo con buena disposición los proyectos que se vengan a nivel laboral.
- Tomar un par de cursos que me pueden potenciar mi área laboral, ahí tendré que negociar sobre mi horario de salida pero me es muy importante. 
- Seguir ahorrando pragmáticamente para mi segundo gran objetivo, el departamento propio. Y en eso, sin duda que estoy trabajando.

En fin, a quien se digne a leer esto, que tenga un fructífero año 2011.

Sí, ni yo aún creo que esto esté sucediendo. Pero, ha llegado el momento de la mudanza. Dejando de lado muchas cosas, pero iniciando muchas nuevas. Así como cuando se dice "Casa nueva, vida nueva".

De todos modos se veía venir. Tantos años viajando diariamente entre Rengo y Santiago era algo que ya me estaba empezando a pasar la cuenta por toda mi salud, tanto mental como física. Realmente ya no era necesario estar levantándose tan ultra mega temprano y llegar súper duper mega tarde sin hacer nada más hasta el día siguiente. Esta oportunidad de lograr la independencia, dando el gran golpe de cátedra incluso a mi familia con el tradicional "te vas de la casa sólo cuando te cases" definitivamente no la desperdiciaré. Se que se viene un montón de nuevos desafíos, pero al menos me siento totalmente capaz de asumirlos, y crecer. 

Dicen que para una relación de pareja exitosa, cosa que a pesar que no está dentro de mis prioridades nunca se deja de lado, es mejor vivir solo por un buen tiempo, para entender qué significa valerse por sí mismo en cosas tan domésticas, como cocinar, hacer aseo, limpiar un baño, mantener un orden, lavar y planchar (eso no es problema :) ), pagar las cuentas y un sinnúmero de etcéteras. Aunque creo que después uno se pone mañoso por no poder tolerar las diferencias, pero... eso me da lo mismo.

Además, los que me conocen de verdad saben que valoro el silencio, la poca bulla, leer un buen libro ante una taza de té y en un ambiente tranquilo. 

Este es el momento de creer en mis capacidades, de que en realidad Rengo se me había quedado chico hace tiempo y esa paz la estoy comenzando a encontrar.

Por lo tanto, el proceso de mudanza ha comenzado, transitorio hasta que reuna el dinero suficiente para comprarme un departamento definitivo. Según mis proyecciones no será tanto tiempo. Sólo debo seguir haciendo todo como hasta ahora, y ser muy responsable.

Todo este proceso de mudanza y sobrevivencia, obviamente lo comentaré por aquí. Total, nadie me lee ;-)