Los Siete Puntos que Debe Considerar para Lograr una SOA

1. Los Siete Puntos que Debe Considerar para Lograr una SOA David Millman Arquitecto Principal

2. Agenda • La Arquitectura Accidental • Los siete puntos de Mediación a considerar • El Servicio Puro

3. Key: Internal data flow External data flow Pending data flow NAME System appears twice Planned systems CCPL CCSN SSI PBRIMS IPMS TAN MP/F Common Interface Layer NOR Network AT&T Corp Books AA PBCC FIMS RIMS PRECISE MI PARIS PR AIM JOUR SUMMIT 4.0 GL Billstar 3 COR SBIR C/CA Bill Day RAP TAPS PCDB Billstar 1 POS Billing CARTS PDS SOFE POS-R EC PDS-ERA AUTS Data Svc MRDB ORBITS BOSS ESS COR Athena Advantage CABS REMS Sales Agency EmFiSys TRAINS TOPS RCRMS PB Awards LIDB Data OSMOP 3rd Pty CPNI Warehse BRIS PaSS Pay by EARS Bill Print ATR E911 NRSS Phone WTS MAPS MP TWIST CL USAGE CONF COIN Customer RM MTR EM EXCH REVE Profile IFS CCP CESAR Listing Svc Bill Format DOMS SORD DCN DRS ERMIS AOG TCMS APTOS TOR MLT Directory Delivery Tech PDP LSD&C PDR ISCP SCP SOCS PB1 STP APTOS ATC SMS SDDL-POF PMIS SDID Sales Comp ORGIS NSDM IRSS SORD IS ASOS PBOD CIAS MI Starwriter Exch Plus BAIF CRMS Customizer ANS IP GIR COSMOS 800 ALRU Network AP PBITS Electronic LMOS Service Custom CUR/CAR SOAC Bonding TSA 800 DB Manager SPACE NTAS DFG MTAS TESS ISIS LATIS PREMIS PVI WFA/C CRAS CMTS MP/F AMOS IPMS CID/SAM FTDM LMOS OPAS NSDB PBVS /Loopview SARTS Paging LOC CNR Mech Eng NAA INPLANS FLEXCOM CSTAR TIRKS CSFT LFACS FIRST NI Predictor LEIS CLONES TMM PVS | PMI CMS SOAC MARCH OPS/INE (CCRS) REACT MOBE 2001 MOPICS PMM JOB TNDS/TK FWS SABR INA Network Network TNM NMA-F Transport PAWS COSMOS DCOS-2000 LOMS WM NOR NOR NDS-TIDE NetPilot EADAS DSC AT&T AT&T TIRKS PICS Separation SEAS /DPCR FEPS EDIIS SCS FDOC ConnectVu TAGS CIDB ComnLang Taskmate La Arquitectura Accidental :¿Por qué es tan mala?

4. Una Interacción Típica Transporte Transporte FTP Destino Destino Semántica Semántica Secuencia Secuencia COBOL MF Java UNIX Error/Recuperar Error/Recuperar QoS/QoP QoS/QoP Modelo Interacc. Modelo Interacc. Lógica de Neg. Lógica de Neg. Servicio 2 Servicio 1

5. Transporte Transporte Transporte Destino Destino Destino Semántica Semántica Semántica Secuencia Secuencia Secuencia Error/Recup. Error/Recup. Error/Recup. QoS/QoP QoS/QoP QoS/QoP Modelo Inter. Modelo Inter. Modelo Inter. Servicio 1 Servicio 2 Service 3 ¿Qué necesito para cambiar entre Servicios 1 & 2? FTP HTTP FTP

6. Retos para la Integración de Punto a Punto • El cambio tiene que suceder en todos lados, para que se vuelva un N2 • Cada punto de mediación puede ser cambiado, entonces es un problema del tipo 7*N2 • Cualquier lado de la relación puede ser de tecnología diferente, por eso, se propone agregar más staff para coordinar juntas, acordar el trabajo • Las pruebas se realizan en Producción debido por no haber pruebas de pre-producción de punto a punto

7. Agenda • La Arquitectura Accidental • Los siete puntos de Mediación a considerar • El Servicio Puro

8. The Seven points of mediation • Transporte • Destino • Semántica • Secuecia • Recuperación de Errores • QoS/QoP (Protección de calidad de servicio) • Modelo de Interacción

9. Point 1 : Transporte • El diseño SOA de cualquier servicio debe ser capaz de soportar cualquier protocoloy ser implementado utilizando nuevos protocolos según sea necesario. • PERO: La implementación debe permanecer igual y ser reutilizada • Muchos protocolos son utilizados en los ambientes de hoy, incluyendo: • HTTP/WS/CORBA/RMI…… • ¿Protocolos emergentes? • Descanse…

10. Punto 2 : Destino / Transparencia de Localización • Internet ofrece transparencia de localización, pero • ¿Por qué un SOA/ESB necesita proveerlo? • Los servicios deben proveer: • Balanceo de carga automático • Pueden implementarse en cualquier sitio • Inicializados y detenidos a voluntad

11. Punto 3: Semántica La habilidad de hablar el mismo lenguaje • Demostrado aquí por las traductoras • Yo hablo inglés, las traductoras lo convierten a Español y ustedes tienene capacidad de esucharme en “Español”. Modelo Canóico. • SOA, el ESB y los Services hacen lo mismo • Cada servicio se comunica con el ESB/SOA en su lenguaje • El ESB es responsable de convertir la información a la del servicio al que va dirigida

12. Punto 4: Secuencia • Comúnmente • Los servicios se escriben con mucho conocimiento de cómo serán utilizados • Condiciones pre/post estipulan el orden de ejecución • Incluso las llamadas de servicios dependen de los servicios directamente • Mala concepción: Esto es más rápido que utilizar un intermediario • ESB provee SOL (Service Orchestration Language) e.g. WS-BPEL y algunos Procesos ESB

13. Punto 5: Recuperación de Errores ¿Cómo enfrenta SOA a los errores? • Los servicios individuales sólo saben acerca de su misión • i.e. Un servicio de Base de Datos puede maejar errores de conexión etc. • No entiende el proceso/secuencia y la topología t • No siempre puede hacer una decisión acertada en el manejo de errores • ¿Cómo podría proveer un “reconnect” para respaldar una base de datos en una localidad distinta?

14. Punto 6 : QoS/QoP • QoS se compone de: • Alta Disponibilidad • Distibución Cargada • Optimización de rutas • Queuing (Entrega Asíncrona) • Publicar y suscribir (distribución 1:N)

15. Request/Reply Pub/Sub Fire & Forget Fire & Forget Bulk Transfer Pub/Sub Request/Reply Bulk Transfer Punto 7 : Modelo de Interacción • Uso de Servicios • Request/Reply • Lance y Olvide • Pub/Sub • Almacene y Reenvíe • Aún existen incompatibilidades de Webservices • WS-RM <->WS-Eventing

16. Agenda • La Arquitectura Accidental • Los siete puntos de Mediación a considerar • El Servicio Puro

17. Implementación de punto a punto Transporte Transporte FTP Destino Destino Semántica Semántica Sequencing Sequencing Error/Recuperar Error/Recuperar QoS/QoP QoS/QoP Modelo Interacc. Modelo Interacc. Lógica de Neg. Lógica de Neg. Servicio 2 Servicio 1

18. El Servicio Puro y ESB QoS/QoP, se configura dentro del proceos e.g. Exactamente una vez, el Mejor Esfuerzo etc. El QoP basado en canal puede ser realizado al instalar SSL.Actional también puede configurarse para configured realizar encriptación de canal o de base en los mensajes El balanceo automático de cargas ocurre en todos los servicios del ESB. Nuevas instancias de un servicio pueden ser implementadas en runtime Todos los servicios y procesos tienene Fault y RME (Rejected Message Endpoint) en un error el contexto completo del mismo es enviado al Fault/RME. Esto permite el manejo de errores de contexo. Las instrucciones complejas de contexto incluyen: Rastreo de Stack, Paso de Servicio de la Ejecución actual y estructura y valores de mensajes entrantes de Nombre de Máquina. ESB desconecta todos los servicios conectados y a tráves de servicios de conexión esconde el modelo de interacción e.g. Batch, Lance y Olvide, Etc. Un proceso único del ESB se puede exponer utilizando múltiples modelos de interacción dependiendo de la manera en que se llame. ESB permite que cualquier Servicio/Proceso sea expuesto utilizando cualquier transporte disponible e.g. HTTP/WS/REST independiente de la implementación El Servicio de Transformación XML integrado provee la capacidad de convertir cualquier XML a cualquier dialecto del Bus. La capacidad DXSI agregada para administrar la transformación y COBOL <->XML más otros motores permite que EDI,CSV sea convertido en código listo para el destino apropiado ESB provee la secuencia a través de los procesos ESB y BPEL. Los servicios individuales de negocios sólo deben conectarse al ESB Transporte Destino Semántica Secuencia Error/Recuperación QoS/QoP Modelo de Interacción

19. Conclusión • Migre hacia el Servicio Puro • Las mediaciones se colocan en el ESB no en el servicio • La mediación se hace una vez no dos • Agregar nuevos servicios ofrece un solo punto de cambio de mediación, utilizando tecnología común • El Cambio Organizacional tendrá impacto mínimo en los servicios implementados • Los “End Services” se vuelven “Black-Box Services”

20. ? Preguntas

21. Gracias