Software Fortresses (podríamos traducirlo Fortalezas de Software), es el libro más conocido de Roger Sessions, del que pueden conocer más visitando su sitio:
en especial sus “white papers”
http://www.objectwatch.com/white_papers.htm
(el de junio de 2003 es el más cercano al libro que vamos a discutir). Publica la ObjecWatch Newsletter, que en el tiempo de publicación del libro (año 2003) era recibida por correo electrónico por más de 20000 suscriptores.
Roger Sessions es un experto en arquitecturas de software de empresa, y el creador del modelo presentado en el libro, el modelo Software Fortress. Veamos un resumen de lo que quiere presentarnos.
Es interesante el prefacio, donde Sessions le pregunta al lector, presunto arquitecto, cuál es la arquitectura del software que tiene armada en la empresa. Se imagina que recibe como respuesta una arquitectura en 3 o n-capas, totalmente ordenada y pensada. Contesta: “Mientes, yo sé cuál es tu arquitectura”. Y pasa a imaginar un “mess”, una mezcla de servidores, bases de datos, aplicaciones web, atadas con alambre diríamos en Argentina, que apenas se sostiene, y que fue creciendo con el tiempo, de forma caótica.
De ahí en más, se dedica presentarnos su modelo.
Un cuestionario que presenta en el capítulo 1, hace un relevo de la situación del lector:
1. Su compañía tiene docenas de sistemas desarrollados independientemente, algunos armados, otros comprados, otros adquiridos por fusiones con otras empresa. Y algunos, no sabe de dónde vinieron.
2. Sus sistemas están interrelacionados de una forma tan compleja, que no puede predecir las consecuencias de un cambio o las ramificaciones de una posible falla.
3. Tiene discusiones “religiosas” sobre tecnología. Que Java sí, que .NET no. Ninguna de las dos partes se comunica bien con la otra.
4. Los departamentos de su compañía no confían en los datos del otro, así que duplican esfuerzo y trabajo.
5. Las bases de datos están hechas una mezcolanza de datos. Cada departamento tiene sus propios datos, sus propios administradores de bases de datos, y sus propias ideas de cómo manejar la seguridad de esos datos.
6. Su compañía tiene miedo de conectarse a Internet. Tienen información de misión crítica y privada que no quieren exponer o comprometer hacia afuera.
7. Tiene sistemas “legacy” de los que dependen, pero tiene miedo de cambiarlos. Algunos no los cambia por lo frágiles que son, otros porque fueron construídos por empresas que ya no están en el mercado, o porque el desarrollador original pasó a mejor vida, y hasta de algunos no tiene el código fuente.
Si contesta SI a por lo menos 5 de estas preguntas, felicitaciones, no está solo, y éste es su libro.
Algunas definiciones
Definition: Software Fortress
A software fortress is a conglomerate of software systems serving a common purpose and typically owned by a cohesive group of individuals. These software systems work together in a tight trust relantionship to provide consistent and meaninful functionality to a hostile outside world.
Esto incluye detalles técnicos y organizacionales. Desde el punto de vista técnico, una fortaleza de software es un conjunto de sistemas, que pueden ser procesos, servicios, componentes de lógica de negocio, bases de datos.
Desde el punto de vista organizacional, la fortaleza de software agrupa a las personas que trabajan juntas, que tienen un razonable conocimiento de qué está trabajando cada uno, tienen confianza en los sistemas que arman y operan. Es un pequeño departamento de IT dentro de la empresa.
Sessions comienza entonces a desarrollar la idea que el software de una empresa debe organizarse conectando estas fortalezas de software. Adopta una serie de íconos para representar a las fortalezas, y los elementos que pueden adosárseles, para tener un dibujo, una diagrama entendible que describa cada fortaleza.
El libro se dedica a la parte técnica de esos elementos, y lo que Sessions y cía, han descubierto o proponen, como elementos de las distintas fortalezas.
Definition: Software Fortress Architecture
A software fortress architecture is an enterprise architecture consisting of a series of self-contained, mutually suspicios, marginally cooperating software fortresses interacting through carefully crafted and meticulously managed treaty relantionships.
Definition: Software Fortress Model
The software fortress model is a methodology consisting of specific algorithms, categories of technologies, and documentation techniques that together can be used to model and build enterprise systems as software fortress architectures.
Un diagrama de ejemplo de fortaleza:
Algunos de los elementos propuestos, cada uno de los cuales tiene su ícono:
– Las paredes (walls) de una fortaleza están diseñadas para prevenir cualquier comunicación con el exterior, a menos que pase por los canales aprobados
– Los canales apropiados son los puentes levadizos (drawbridges) y son vigilados por guardias (guards).
– Los diplomáticos (envoys) preparan la comunicación entre fortalezas.
– Un baúl de datos (data strongbox) representa la colección de datos persistidos que se usan dentro de la fortaleza.
De ahí en más, Sessions va describiendo cada uno de estos elementos, metafóricos, trasladados a tecnologías, explicando las implementaciones y la razón de ser de cada elemento.
Los íconos que se colocan dentro de cada fortaleza, los llama trabajadores (workers). Utiliza una librería de gráficos:
http://www.novadevelopment.com/Products/us/aqw/default.aspx
donde aparecen vikingos, guardias, hadas, dinosaurios (representan sistemas “legacy”), brujos, y directores de orquesta, cada uno de los cuales va adosado a un concepto de Sessions.
Algunos tipos de fortalezas
Business application fortress (BAF), donde corre el negocio. Por ejemplo, el control de inventario.
Treaty management fortress (TMF) que maneja la relación con otras fortalezas
Legacy fortress (LF) con un dinosaurio dentro, representando alguna aplicación antigua.
Presentation fortress (PF) representadas por un caballete de pintor, típica para un servidor o granja de servidores web.
Web service fortress (WSF) representadas por un mago, son responsables de atender pedidos de funciones vía Internet.
Service fortress (SF) es una de sus últimas adiciones al modelo, representadas por un hada, provee servicios a otras fortalezas.
Algunas fortalezas pueden tener varios íconos dentro.
Lo nuevo de Sessions, es presentar todos estos elementos en fortalezas. Propone que todos los sistemas, en vez de estar conectados de forma difuso, se organicen en fortalezas, donde los puntos de entrada, la seguridad, lo que exponen y consumen, está específicamente determinado por los puntos de entradas (puentes levadizos), guardias, y demás elementos. Esa es la “vuelta de tuerca” que propone. Pueden ver más detalle en el libro o en “paper” mencionado más arriba.
Resumen de los capítulos
Capítulo 2: Diagramming Software Fortresses
Presenta en más detalle los diagramas, algunos instrumentos de texto como la declaración de un tratado, y los tipos de fortaleza más frecuentes y sus documentos asociados.
Capítulo 3: Transactions
Explicita el tema tan importante de transacciones, explica qué son los recursos “trancsactionally aware”, que participan de transacciones. Si los recursos a participar de una trasacción se encuentran separados, aparece la figura del Distributed Transaction Coordinator (DTC).
Capítulo 4: Drawbridges
Son las tuberías por las que fluye la información de fortaleza a fortaleza. Es un punto de entrada definido a una fortaleza. Intervienen los diplomáticos para preparar el mensaje, los guardias para ver de dejar entrar un mensaje o no. Luego discute distintas tecnologías, como sobres SOAP, COM+, Enterprise JavaBeans, que pueden usarse como base de estos puentes de comunicación. Como tema importante, lo subdivide en los dos siguientes capítulos.
Capítulo 5: Synchronous Drawbridges
Es un canal donde el que llama espera una respuesta inmediata, como si fuera un llamada a función. Sessions destaca que la tecnología de puentes sincrónicos se basa en componentes. Hay un “objeto” (no necesariamente un objeto, pero es frecuente) remoto que expone una interfaz, y se ve opaco desde el cliente. Plantea el problema de que históricamente, surgieron tecnologías homogéneas, que sólo permiten comunicar dos partes de la misma tecnología, pero en los últimos años surgieron, ante la necesidad de interoperabilidad, las tecnologías heterogéneas. Se deben resolver problemas como la seguridad automática (el cliente debe “aparecer” de alguna forma en el servidor llamado), manejo de instancias (cuándo un componente nace, y cuándo se libera) y el flujo de transacciones (cuándo una transacción aparece, y se expande, y cuándo viene distribuida).
Capítulo 6: Asynchronous Drawbridges
En situaciones donde el mensaje enviado no necesita una respuesta inmediata, se pueden usar puentes asincrónicos, donde la respuesta puede venir mucho más adelante en el tiempo. Acá, históricamente se han implementado con colas de mensajería. Se discute el tema transacciones en las colas, la persistencia de los mensajes, y la posibilidad de que el mensaje tenga varios destinatarios. De nuevo aparece el problema de puentes homogéneos y heterogéneos.
Capítulo 7: Guards and Walls
Las paredes impiden el acceso a la fortaleza. Los guardias lo permiten. El arquitecto de la fortaleza es responsable de ver cuán selectivo será un guardia y qué tecnologías se usarán para implementar esa selectividad. Se discuten los temas de: fortificación, validación, auditoría, autenticación, privacía, integridad, no repudiación, autorización.
Fortificación se refiere a la habilidad de la fortaleza de prevenir la entrada a la misma, excepto a través de los puentes.
Validación es el control y recontrol de las entradas provistas por el exterior o el usuario.
Auditoría es la habilidad de trazar todos los cambios al estado interno de la fortaleza.
Autenticación es el procedimiento que se usa para convencer al guardia de quién está tratando de acceder.
Privacía es la capacidad de enviar información de tal manera que no pueda ser leída por usuarios no autorizados.
Integridad se asegura que la información en ruta no sea cambiada.
No repudiación se refiere a la capacidad de probar más adelante en el tiempo que tal informacion vino de tal origen.
Autorización es la habilidad de determinar, en base a la información que viene en el pedido (no según la fortaleza que lo pide) si su ejecución pedido puede ser permitida.
Capítulo 8: Treaties
Son los tratados, acuerdos formales entre fortalezas que definen cómo trabajaran entre ellas.
Capítulo 9: General Fortress Issues
Se tratan temas como escalabilidad. Una fortaleza es escalable si su unidad de costo de atender un pedido, es lo suficientemente baja para no perder una ganancia. Si cada pedido implica una pérdida, debería acotarse la cantidad de pedidos a atender. Otra condición para la escalabilidad es que podamos incrementar la carga de trabajo de un proceso, ya sea con mejores servidores (scale-up) o agregando servidores (scale-out).
Otro tema es la “reliability”, la confianza que tenemos en poder contar con la fortaleza cuando la necesitemos. Y finalmente, la integridad. Una fortaleza es diseñada para proveer una alta integridad si no hay nada que la dañe o la deje en un estado incompleto, aún ante el fallo de otras fortalezas.
Capítulo 10: Internet Fortresses
El tema Internet merece un capítulo aparte. Las fortalezas de presentación y de servicios web pueden ser expuestas, por ejemplo, en una zona desmilitarizada, y comunicarse de formas específicas con el resto de la empresa. Se discuten tecnologías como ASP, JSP, ASP.NET, el tema de la escalibidad (con un cluster, por ejemplo, scale-out), seguridad, como el uso de firewalls, zonas desmilitarizadas, usar servidores de presentación con sólo algunas características activadas; disponibilidad, integridad, y las tecnologías de servicios web, con los mismos temas.
Capítulo 11: Business Application Fortresses
Son el pan y manteca de la empresa. Son los que “hacen el dinero”. Son los procesos de contabilidad, las compras, ventas. Merecen nuestro respeto y gratitud. Se discuten componentes, manejo de estado, fronteras de transacciones y su manejo, el apalancamiento de “clusters”, Java vs .NET, y hasta el costo.
Capítulo 12: Legacy, Service, and Treaty Management Fortresses
Un capítulo con varios temas. Por un lado, los sistemas “legacy”. Aparecen los servicios, como por ejemplo, el “broadcast service”, cómo un “publisher” envía un mensaje a varios suscriptores. Las fortalezas de manejo de tratados manejan las relaciones complejas entre tres o más fortalezas.
Capítulo 13: Software Fortress Design Review
Presenta 25 preguntas que se deben realizar durante el diseño de una solución de fortalezas de software. Son tres grupos: para gerentes de nivel empresarial, para arquitectos de nivel empresarial, y para arquitectos y diseñadores de fortalezas individuales.
Capítulo 14: Case Study
Finalmente, se presenta un caso de estudio, una empresa que vende por Internet. Se plantea el uso de iteraciones en el desarrollo, en este caso se usan dos. Se usan documentos para analizar la complejidad de la arquitectura a armar.
Capítulo 15: Postlude
Presenta diez puntos importantes sobre fortalezas de software, y diez puntos para adoptar el modelo Sessions, más diez reglas para su diseño, y diez ideas controversiales del modelo (como poner en segundo lugar el rendimiento, y que los guardias son los encargados de la seguridad, y luego en la fortaleza se puede hacer lo que se quiera). Aparecen diez consideraciones para evaluar J2EE vs .NET, como si necesita o no ejecutar en un ambiente no Windows. Y diez observaciones sobre el estado de la industria del software, notablemente una: la industria del software no tiene un modelo conceptual para construir sistemas empresariales.
Se agradece al final la presencia de un glosario, que nos permite entender cada término presentado.
Conclusión
Es un libro para leer, y sacar algunas ideas. No todos tenemos que lidiar con todos los problemas presentados, pero me gusta el libro porque presenta eso: problemas. Luego, abstraidos de las soluciones tecnológicas, son mejor entendidos. Creo que muchos estudiamos tecnologías, sin tener en claro cuáles son los problemas que solucionan, y las razones, las causas de la aparición de esos problemas. Los conceptos de Sessions permiten tener claro esos temas, y luego, como adicional, menciona y describe las capacidades de las tecnologías disponibles para resolver esos problemas. Es un libro para aclarar la mente.
Gracias a la biblioteca de SouthWorks, pude leerlo y comentarlo acá.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com/