En camino a SOA Jordi Rambla Director Certia – rambla informàtica.

Presentación del tema: "En camino a SOA Jordi Rambla Director Certia – rambla informàtica."— Transcripción de la presentación:

1

2 En camino a SOA Jordi Rambla Director Certia – rambla informàtica

3 Certia Es la marca de servicios de rambla informàtica Consultoría, formación y aplicaciones en.NET Trabajando en informática empresarial desde 1985 Consultores de XML y WS en Master UOC Regional Director (RD) Program Profesionales independientes con experiencia en tecnologías Microsoft para soluciones en entornos empresariales Sufren y gozan y sufren como los demás mortales

4 ASB BLT HDL AFTTGI FRY DRW SWG QYDDLY BST WIU ASB ZISXOICUI RMO DLY XPS KYF KFC WHR JIA GEX FQAVUH HCO WKD ECP SKD MFP WCP DKEAJT Una arquitectura típica …o la típica falta de ella

5 El problema de este modelo Tenemos un SIMO Las 3 capas no han paliado el problema Problemas derivados del modelo Difícil de mantener y modificar Frágil en explotación, pues es rígido Muy dependiente de los RRHH Funcionalidades y datos duplicados Alto coste en integración Y ahora es aún más difícil hacerlo nuevo

6 Una posible solución Emular las actuales relaciones entre los departamentos. Canales uniformes y claramente establecidos Muchas veces asíncronos Reducir los puntos de interrelación Menos puntos de fallo y menos puntos a mantener Disminuir la entropía. Mucho más fácil de monitorizar ¿con tecnología web? No necesariamente, aunque: Directamente abierto a la reubicación y su externalización (flexibilidad) Potencia adecuadamente la in-dependencia

7 ServicioServicioServicio ServicioServicioServicio Bus La arquitectura …y una posible solución SOA

8 ¿Qué opina la industria hoy? Many in the technology industry believe SOAs will overcome interoperability and inflexibility barriers needed to finally fulfill a promise IT has been making for decades. A Service-Oriented Architecture (SOA) framework can enable financial companies to achieve their business goals by providing a service-based platform to integrate new and existing applications and systems… Service-Oriented Architecture (SOA) is the next wave of application development WSWSWS WSWSWS Bus

9 …disminuir el time-to-market y el TCO de los sistemas …aprovechar……aprovechar… ¿Qué beneficios me aporta SOA? …promotes reuse within the enterprise, decreasing time-to-market and system TCO. … primary intentions are business-level software modularity and rapid, nonintrusive reuse of business software in new runtime contexts. …no intrusivo…

10 ¿Qué beneficios me aporta SOA? SOA brings these benefits to enterprise IT: Incremental development and deployment of business software Reuse of business components in multiple business experiences Low-cost assembly of some new business processes Clarity of application topology Reworking existing brittle, high-cost IT infrastructures into flexible, Service oriented architectures promises substantial long-term cost savings and revenue opportunities through increased business agility. mayor agilidad… bajo coste… ahorro de costes…

11 ¿En qué consiste SOA? a set of independently running services loosely bound to each other via event-driven messages. SOA is the aggregation of components satisfying a business driver. …servicios……servicios… …loosely coupled…

12 ¿En qué consiste SOA? A service architecture consists of three primary components…the service provider…the service requestor...the service agency provides registration and discovery services A service architecture consists of three primary components…the service provider…the service requestor...the service agency provides registration and discovery services Service-oriented architecture (SOA) is a client/server software design approach in which an application consists of software services and software service consumers (also known as clients or service requesters). SOA differs from the more general client/server model in its definitive emphasis on loose coupling between software components, and in its use of separately standing interfaces. …mensajes……mensajes… …interfaces……interfaces…

13 Los retos para el desarrollo Un servicio no es una función remota Es más parecido a una llamada a una URL Se comporta como un sistema de colas de mensajes El contrato es ley (aún más que ahora) El flujo es más explícito La asincronía es la norma Transacciones por caducidad, anulación y compensación No hay instancias, o si WSWSWS WSWSWS Bus

14 Compra portale-Commerce Servicio de atención al cliente (CRM) Servicios de logística Servicio de identificación y autorización Autorización de créditos Servicios de facturación SOA en casa

15 Proceso de mensajes Infraestructura implicada Infraestructura de proceso de mensajes Servicio Servicio serializar encriptar firmar deserializar identificar auditar archivar mensajeríafiable eventing monitorizar encaminar autorizar

16 Service Service façade Capa de negocio Capa de datos Acceso a datos datos Entidad de negocio negocio Servicio de proceso ¿Cómo IN-dependizar sistemas dependientes? Servicio de negocio Business Service Servicio de proceso Servicio de proceso Service Façade Business Entity Layer Data Representation Layer DataAccessorsDataAccessors BusinessEntitiesBusinessEntities Process Service

17 La obcecada realidad: un problema Tenemos aplicaciones que abarcan varias tecnologías Los servicios han de estar disponibles para varios canales Las aplicaciones se han diseñado para soportar varios tipos de transporte y métodos de invocación Queremos separar la lógica de la aplicación de los aspectos transversales como auditoria, seguimiento, instrumentación, gestión de excepciones, autorización, etc. Queremos un nivel de indirección entre la invocación del servicio y la implementación del servicio para protegernos de los cambios en la aplicación

18 La realidad: escenarios multicanal La lógica de negocio ha de estar disponible: Una implementación de Siebel muy personalizada que sólo admite llamadas DCOM Un dispositivo WinCE que ejecuta una aplicación escrita con Embedded Visual C++ que utiliza un protocolo propio basado en sockets Un mainframe con un protocolo diseñado hace 20 años para TCP / IP Un sistema J2EE que utiliza SOAP sobre HTTP

19 La realidad: Un patrón recurrente Las soluciones creadas han desarrollado / adoptado frameworks para estandarizar el desarrollo de los servicios Típicamente, la funcionalidad incluye Soporte para distintos transportes incluyendo SOAP, COM+, Remoting y colas de mensajes Aplicación declarativa de los aspectos transversales Modelo estándar de programación para gestionar la carga (payload) de la petición, las transacciones, las excepciones, los time-outs… Ejemplos MCS LatAm MBI instalado en más de 30 empresas financieras Avanade ACA.Net instalado en más de 150 clientes MCS Australia ATO (Australian Tax Office) Todos ellos incluyen BizTalk en la solución

20 Proyecto Shadowfax

21 Historia del proyecto A la aplicación de ejemplo Duwamish books se le notan los años (circa 1999) El equipo PAG (Platform Architecture Guidance) quiere crear un nuevo ejemplo que contemple las guías (guidance) y bloques (blocks) aparecidos Factores de éxito (las tres C) Correct (correcta) Compelling (urgente, convicente) Credible (verosímil)

22 Resultado objetivo Orientación sobre como gestionar consistentemente las peticiones recibidas desde varios canales Orientación sobre como separar la implementación de la lógica de otros requerimientos Orientación sobre como gestionar los distintos tipos de carga (payloads) de las peticiones (desde un blob hasta estructuras categorizadas (typed) Demostración completa de la integración de los building blocks

23 Implementación de referencia Global Bank Banco internacional Ha crecido mediante adquisiciones Iniciativa Banca online La experiencia del cliente está fragmentada Varios sistemas backend sin conexión entre si El objetivo es ofrecer un conjunto de servicios que abarquen los distintos sistemas y ofrezcan una experiencia de usuario consistente, independientemente del canal de acceso

24 Use Cases Transferencia de fondos Transferencia de fondos Posición consolidada de cuentas Posición consolidada de cuentas Domiciliación bancaria de recibos Emisión de recibos Pago de recibos Solicitud de créditos Comisiones de estudio Gestión de los datos de los clientes Identificación en el sistema Identificación en el sistema

25 Arquitectura recurrente Componente negocio Canales Filtros de intercepción y entrega Llamada a operación de negocio

26 Arquitectura de Shadowfax Proxy Adap Especificación Pipeline Proxy Adap Proxy Adap Proxy Adap Serv.Web MSMQ Remoting … Especificación Pipeline Componente de Acción Pipeline de interfaz del servicio Pipeline de implementación del servicio Canales Interfaz Servicio Llamada Servicio Implementación servicio DCOM In-proc ASMX MSMQ Agente Servicio

27 Shadowfax: el código fuente

28 Funcionalidades críticas ConfigurabilidadPipelinesDespliegue Llamadas a los componentes de negocio Estructura de las peticiones Representación de los datos de negocio InstrumentaciónTransacciones Gestión de excepciones Eventing Llamadas a las acciones de negocio IdempotenciaTimeouts Validación de las fechas de los mensajes Transformación de las fechas de los mensajes Devolución de los resultados al cliente Correlación de mensajes

29 Aspectos transversales Aclaración terminológica: Cross-Cutting, Aspects, vertical/horiz. Registrar (log) las llamadas a un servicio Comprimir los mensajes que superen un tamaño determinado si se van a enviar mediante una WAN Firmar y encriptar los mensajes Ofrecer métricas sobre el cumplimiento del ANS (SLA – Service level agreement) Permitir encaminar (en función de los datos o del QoS) Transformar mensajes

30 Aspectos transversales Se pueden resolver en la aplicación Es mejor construir una infraestructura que ofrezca una vía para adherirse (hook) al proceso de los mensajes El patrón Pipes & Filters permite crear un pipeline de proceso de los mensajes Ajustar los aspectos transversales acorde al servicio o al mensaje

31 Arquitectura recurrente Componente negocio Canales Filtros de intercepción y entrega Llamada a operación de negocio Compresión Transformación Encaminamiento

32 Shadowfax: Elementos de desarrollo

33 Roadmap Shadowfax v1 – para.NET 1.1 aparecerá en marzo de 2004 Entregas de código de diciembre a febrero Shadowfax v2 -.NET Whidbey aparecerá cuando aparezca Whidbey Modificado para aprovechar las nuevas funcionalidades de Whidbey Distribución online durante la fase Beta 1 de Whidbey Incluido en el CD de la Beta 2 de Whidbey y en las siguientes entregas hasta el lanzamiento

34 Categorías de Servicios Clientes y Agentes ServiciosEntidad ServiciosActividad ServiciosProceso BBDD BBDD Componente Partner Host Servicios Infraestructura

35 Categorías de Servicios Clientes y Agentes ServiciosEntidad ServiciosActividad ServiciosProceso BBDD BBDD Componente Partner Host Servicios Infraestructura Los Servicios de entidad representan operaciones sencillas y atómicas sobre una entidad tal que pedidos, cuentas, clientes, etc. Pueden escribir directamente sobre un almacén o componente, partner externo o host

36 Categorías de Servicios Clientes y Agentes ServiciosEntidad ServiciosActividad ServiciosProceso BBDD BBDD Componente Partner Host Servicios Infraestructura Los Servicios de actividad coordinan las operaciones de varios Servicios de Entidad en una sola operación atómica (ActualizarCliente, AceptarPedido)

37 Categorías de Servicios Clientes y Agentes ServiciosEntidad ServiciosActividad ServiciosProceso BBDD BBDD Componente Partner Host Servicios Infraestructura Los Servicios de Proceso representan procesos de negocio de larga duración, quizá con flujos complejos e interacción con usuarios

38 Categorías de Servicios Clientes y Agentes ServiciosEntidad ServiciosActividad ServiciosProceso BBDD BBDD Componente Partner Host Servicios Infraestructura los BizTalk Adapters facilitan la integración

39 Categorías de Servicios Clientes y Agentes ServiciosEntidad ServiciosActividad ServiciosProceso BBDD BBDD Componente Partner Host Servicios Infraestructura la Orchestration de BizTalk permite crear actividades muy dinámicas

40 Categorías de Servicios Clientes y Agentes ServiciosEntidad ServiciosActividad ServiciosProceso BBDD BBDD Componente Partner Host Servicios Infraestructura el Workflow de BizTalk (BPEL) y la compensación facilitán los procesos de negocio

41 Referencias Shadowfax en GotDotNet http://workspaces.gotdotnet.com/shadowfxSOAhttp://www.webservices.org/http://www.collaxa.com/developer.welcome.htmlhttp://www-136.ibm.com/developerworks/webservices/Arquitecturahttp://msdn.microsoft.com/architecturehttp://www.thearchitectexchange.comhttp://jakarta.apache.org/struts/

42 Referencias Patterns Analysis Patterns. Martin Fowler http://www.martinfowler.comhttp://java.sun.com/blueprints/corej2eepatternsAspectshttp://www.eclipse.org/aspectjhttp://aosd.nethttp://www.codeproject.com/gen/design/aop.asp

43 Conclusiones provisionales ¿SOA elimina el problema de la disparidad de sistemas? No, al contrario, admite que existe y que persistirá Mejora la posibilidad de gestionar esa complejidad Abre el camino a una sustitución no/menos traumática Los clientes empiezan a andar el camino Están de acuerdo en las ventajas de SOA Existen herramientas como Biztalk, que aportan infraestructura madura como Shadowfax, que supone un punto de partida Sabemos más sobre Soria y su cultura Cómo parecer atractivo a las vacas

44 © 2003 Microsoft Corporation. Todos los derechos reservados. Esta presentación es con fines informativos únicamente. Microsoft no ofrece garantías, expresas o implícitas, sobre este contenido. jordi@ramblainf.com http://certia.ramblainf.com/ppt/caminoSOA.zip