Miercoles 17, con algunas caras cansadas, sobre todo la gente de Uruguay y Venezuela, ya que estuvimos tomando unas cervezas el día anterior y para cuando yo me volví todavía quedaban algunos tirando tiros en la cigale.
Durante la primera hora Ali estuvo hablando sobre algunos SOA Patterns, básicamente todos los que se desccriben en el "Design SOA Solutions and Apply Project, Technical, and Operational Governance (SW718)", Proxy Interaction Patterns, Remote Strategy Pattern, Enterprise Service Bus pattern y Service Registry pattern. Digamos que los más interesantes son los úlimos dos. Los primeros si bien son muy usados son un sub-conjunto del ESB Pattern. Una de las cosas que comentó Ali, fue que IBM fue la primer empresa en hablar de un ESB como un estilo arquitectónico, yo lo recuerdo, esto era por el 2004, pero tambien sabia que en algún momento iba a salir el Websphere ESB, y obviamente ese producto llegó ;)
El segundo tema fue, SOA Architectural Reference (S3), este es uno de los temas más interesantes del curso, básicamente es la arquitectura de referencia de todo proyecto de integración implementando SOA. Esto ya lo habia leido en un paper que me llegó hace un tiempo y realmente es muy interesan, muestra con lujo de detalle todas las capas, elementos, componentes e interacciones que pueden aparecer en una integración con SOA. Para describir un poco esta arquitectura de referencia, transcribo la explicación "literalmente" de un post del blog de Ali en DeveloperWorks (se pueden ayudar de la imagen):
These layers are:
1. Consumer layer - any consumer of a service would reside in this layer
2. Business process layer (choreography and composition)-- a process uses a set of loosely coupled services in a choreography or composite application
3. Services layers -- a layer of service descriptions and policies, implemented through
4. Service Components -- (e.g., EJB's or .NET components) who privide the actual realization of the service operation, or the service directly uses or exposes
5. Operational Systems and Data -- which include packaged applications like SAP, Siebel, PeopleSoft (Oracle), Legacy systems, and of course the data bases that support the applications.
Cross cutting these functional layers are the operational layers that support and intersect the above:
6. Integration Layer -- if you need/have an ESB it's here
7. Quality of Service layer -- all, aspects of security, monitoring, management and all other quality of service aspects are implemented and ensure through this layer
8. Data Architecture, Business Intelligence and meta-data layer -- provides data models, star cshemas or meta-data relating to and supporting the SOA
9. Governance Layer -- includes the procedures, processes, registry , repository and run-time governance needed to servce as support for the entire life-cycle
Durante la tarde estuvimos viendo las capas "cross-cutting" que se ven en la figura, de la 6 a la 9:
El tercer tema del día fue SOA Governance, si bien fue un poco abstracto y generalista, se pudo entender que significa el tema. Básicamente apunta de dictar las normas a nivel organizacional de como se van a integrar las aplicaciones, es como el gobierno en una ciudad, bueno pero esto es en un empresa, buenas normas de IT Governance aseguran una correcta implementación de los sistemas, obviamente si se siguen. Esta sería la herramienta fundamental para el Enterprise Architect.
Seguimos con SOI (Service Oriented Integration) y ESB (Enterprise Service Bus), si bien fue bastante corta, se pudo revisar en detalle cada uno de los temas, más adelante voy a explicar un poco más estos conceptos.
El siguiente tema fue QoS (Quality of Service), digamos que para mi gusto no fue lo esperado, solo explicaron un poco de Monitoreo, Logs y algunos productos que soportan. Faltaron conceptos un poco más arquitectónicos como tácticas para lograr performance, disponibilidad, tolerancia a fallos, etc...
Creo que habló un poco de Data Architecture, aunque no estoy muy seguro, si encuentro algo de info la voy a compartir.
Lo más interesante de este día, obviamente, fue el SOA Architectural Reference, ya que es el template que tendríamos que seguir para construir arquitecturas de integración SOA.
Suscribirse a:
Comentarios de la entrada (Atom)
No hay comentarios.:
Publicar un comentario