ESCUELA POLITÉCNICA NACIONAL

Transcripción

1 ESCUELA POLITÉCNICA NACIONAL FACULTAD DE INGENIERÍA DE SISTEMAS INFORMÁTICOS DISEÑO DE LA SOA PARA ANDES PETROLEUM LTD. PROYECTO PREVIO A LA OBTENCIÓN DEL TITULO DE INGENIERO EN SISTEMAS INFORMÁTICOS AUTOR: DANNY ROLANDO SAGAL PAZMIÑO dansp7_sp1@yahoo.com DIRECTOR: JAIME NARANJO jaime.naranjo@epn.edu.ec

2 DECLARACIÓN Yo Danny Rolando Sagal Pazmiño, declaro bajo juramento que el trabajo aquí descrito es de mi autoría; que no ha sido previamente presentada para ningún grado o calificación profesional; y, que he consultado las referencias bibliográficas que se incluyen en este documento. A través de la presente declaración cedo mis derechos de propiedad intelectual correspondientes a este trabajo, a la Escuela Politécnica Nacional, según lo establecido por la Ley de Propiedad Intelectual, por su Reglamento y por la normatividad institucional vigente. Danny Rolando Sagal Pazmiño 2

3 CERTIFICACIÓN Certifico que el presente trabajo fue desarrollado por Danny Rolando Sagal Pazmiño, bajo mi supervisión. Ing. Jaime Naranjo DIRECTOR DE PROYECTO 3

4 AGRADECIMIENTOS Mi más sincero agradecimiento, al Ing. Iván Pazmiño Jefe del departamento de IT de la organización en la que se baso este proyecto, por el apoyo prestado en el transcurso del desarrollo de todo el trabajo. De igual manera al Ing. Jaime Naranjo Director de Tesis, sin el cual este trabajo hubiese sido imposible realizar. Agradezco profundamente a todos los docentes de la facultad de ingeniería de sistemas de la EPN, por su dedicación y esmero día con día para formar ingenieros que puedan desenvolverse en el ámbito profesional, y aportar al desarrollo del país. 4

5 DEDICATORIA A mi Abuelita y a mi Madre, ejemplos de fortaleza y amor, por todo el sacrificio y esmero en mi formación y las de mis hermanos, espero que con este pequeño reconocimiento pueda agradecerles en una pequeña parte todo lo que han hecho por nosotros. Gracias y dios te de vida Mamita para que sigas iluminando mi camino aquí en la tierra, que estoy seguro que mi Abuelita desde el cielo nos cuida. 5

6 Contenido: CAPITULO I EVALUAR LA MADUREZ DE SOA EN LA ORGANIZACIÓN PLANIFICACION DE LA EVALUACION DE SOA EN LA ORGANIZACION Objetivos de la Evaluación Planificación de taller para evaluar la madurez de SOA en la organización Descripción de la herramienta a utilizar (IBM SOA Self- Assessment) DESARROLLO DE LA EVALUACION DESCRIPCIÓN DE LA SITUACION ACTUAL DE IT ANÁLISIS DE HARDWARE ANÁLISIS DE SOFTWARE Descripción de la Arquitectura actual de la Organización ANÁLISIS DE LOS RESULTADOS DE LA EVALUACIÓN Evaluación cuestionario de Procesos de la herramienta Evaluación cuestionario de Arquitectura de la herramienta Evaluación cuestionario de Aplicaciones de la herramienta Evaluación cuestionario de infraestructura de la herramienta ESTABLECIMIENTO DEL NIVEL DE MADUREZ DE SOA EN LA EMPRESA...45 NIVEL DE MADUREZ DE SOA EN LA ORGANIZACIÓN...50 CAPITULO II DISEÑO DE LA SOA (BUS DE SERVICIOS CORPORATIVOS) PARA LA COMPAÑÍA Metodología a utilizar ANALISIS DE LA GESTION DE SERVICIOS (MODELAJE)

7 2.2.1 Análisis de Requerimientos del negocio...54 Requerimientos funcionales Identificación de Servicios (Análisis Top-Down) Cuadro de servicios identificados después del análisis DISEÑO LOGICO DEL BUS DE SERVICIOS CORPORATIVOS(ENSAMBLAJE) Requerimientos de la organización para el Enterprise service bus Diseño de los componentes del ESB VISTA DEL DISEÑO LÓGICO DEL ESB PARA LA ORGANIZACIÓN COMO LA IMPLEMENTACIÓN DE LA ARQUITECTURA MEJORARÍA LA GESTIÓN DE SERVICIOS EN LA ORGANIZACIÓN Descripción de ventajas al implementar el enterprise service bus en la organización MEJORA CONTINUA DE SOA EN LA ORGANIZACIÓN Crear un centro de competencias de integración de aplicaciones Desarrollar un mapa de integración para su empresa Documentar las interfaces de aplicación Comenzar pequeño y crecer incrementalmente Valor para el Negocio dado por la Integración CAPITULO III CONCLUSIONES RECOMENDACIONES Glosario de términos BIBLIOGRAFÍA ANEXOS 7

8 CAPITULO I EVALUAR LA MADUREZ DE SOA EN LA ORGANIZACIÓN EVALUAR LA MADUREZ DE SOA EN LA ORGANIZACIÓN PLANIFICACION DE LA EVALUACION DE SOA EN LA ORGANIZACION Objetivos de la Evaluación Planificación de taller para evaluar la madurez de SOA en la organización Descripción de la herramienta a utilizar (IBM SOA Self-Assessment) DESARROLLO DE LA EVALUACION DESCRIPCIÓN DE LA SITUACION ACTUAL DE IT ANÁLISIS DE HARDWARE

9 ANÁLISIS DE SOFTWARE Descripción de la Arquitectura actual de la Organización ANÁLISIS DE LOS RESULTADOS DE LA EVALUACIÓN Evaluación cuestionario de Procesos de la herramienta Evaluación cuestionario de Arquitectura de la herramienta Evaluación cuestionario de Aplicaciones de la herramienta Evaluación cuestionario de infraestructura de la herramienta ESTABLECIMIENTO DEL NIVEL DE MADUREZ DE SOA EN LA EMPRESA NIVEL DE MADUREZ DE SOA EN LA ORGANIZACIÓN PLANIFICACIÓN DE LA EVALUACIÓN DE SOA EN LA ORGANIZACIÓN Objetivos de la Evaluación La evaluación tiene como objetivo principal describir la situación actual de las tecnologías de información en la organización con el fin de determinar el nivel de madurez de SOA en la misma Introducir al personal de IT de la organización acerca de las ventajas de implementar una arquitectura orientada a servicios en la empresa 9

10 Aprovechar la arquitectura existente como punto de partida para poder diseñar una arquitectura orientada a servicios Planificación de taller para evaluar la madurez de SOA en la organización Se desarrollara un taller de SOA en la organización con el fin de realizar la evaluación de la madurez de SOA en Andes Petroleum ltd. El cual contara con la presencia de representantes de los diferentes segmentos que componen el departamento de IT. Atreves de este taller el autor puede interactuar con el equipo de IT y se analizara la documentación y los aspectos fundamentales de la arquitectura actual de la organización con el equipo de ANDES PETROLEUM responsable de la misma. La información recolectada servirá como pilar para comprender la lógica del negocio y la madurez de SOA en la organización. También al final del taller utilizaremos una herramienta propuesta por IBM la cual nos permitirá interactuar con ella para proponer un grado de madurez de SOA a ALTO NIVEL. La constitución del taller, aprobado por andes Petroleum se encuentra detallado en el documento que describe el contenido del taller, su duración las concesiones que realiza la organización para su desarrollo (Ver anexo 1). 10

11 Al Final del taller se definirá el nivel de madures de SOA en la organización de igual forma se, tendrá sentada las bases para poder proponer un diseño lógico a alto nivel de un enterprise service bus Descripción de la herramienta a utilizar (IBM SOA Self- Assessment) Para dar soporte a la evaluación del taller de SOA descrito en la parte anterior se utilizara una herramienta desarrollada por IBM, a la cual se tiene acceso a través de la dirección: En la cual primero es necesario registrarse para poder tener acceso a este o más productos de IBM Las datos que han sido registrados para tener acceso a la herramienta es User : Danrsp777@hotmail.com Password: dannysagal IBM SOA Self-Assessment Esta herramienta ha sido desarrollada por IBM para poder extraer el nivel de una organización en SOA. A través de dar solución a cuestionarios divididos en cuatro puntos importantes de los que depende la implementación de SOA en una organización los cuales son Procesos Arquitectura Aplicación Infraestructura 11

12 Análisis de madurez Una vez desarrollado los cuestionarios de los temas propuestos la herramienta muestra una conclusión del nivel de SOA en la organización A lo cual se le realizara un Análisis de madurez exhaustivo para realizar las conclusiones correspondientes Visión La herramienta también proporciona una visión de los posibles caminos para poder continuar con la evolución de SOA en su organización Ciclo de Vida Proporciona un punto de referencia para continuar con la evolución de SOA en la organización DESARROLLO DE LA EVALUACIÓN DESCRIPCIÓN DE LA SITUACION ACTUAL DE IT IT en la organización Andes Petroleum es una empresa dedicada a la extracción y producción de petróleo la cual maneja un sin número de procesos los cuales tienen relación al manejo de reservas y el manejo de los flujos de hidrocarburos a través de sus facilidades de producción hacia los puntos de almacenamiento y entrega. La gestión de procesos en una empresa con estas características es compleja, ya que existe una marcada dependencia de factores internos y externos a la compañía, entre los que se pueden mencionar la participación de múltiples proveedores, con una variedad de tecnologías y servicios de la industria, por lo que generalmente muchos de los procesos tienen interactúan entre sí y con otras variables del negocio. Para atender esta dinámica cambiante, las aplicaciones y sistemas básicos de la compañía se someten a continuos requerimientos por intercambiar información y servicios. Esto hace que sea requerido programar interfaces entre múltiples aplicaciones y repositorios de información, mientras los tiempos de respuesta esperados por el negocio son una de las restricciones más importantes. Es por tanto indispensable implementar una Arquitectura orientada a Servicios que permita flexibilizar la comunicación entre estos procesos para mejorar la función clave de apoyo del área de Tecnologías de Información en la prestación de servicios a la empresa. Estructura del departamento de IT 12

13 En Andes Petroleum el departamento de IT se encuentra en un nivel asesor, aunque no se encuentra en medio de la cadena de valor de la organización, da soporte a todo el proceso del negocio. Infraestructura Redes Telecomunicaciones Soluciones de negocios Servicio al cliente 13

14 ESTRUCTURA DEL DEPARTAMENTO DE IT I T S e r v i c e s M a n a g e r I v á n P a z m i ñ o T e c h n & A d m i n A s s i s t a n t N a t a l i a F r e i r e S e n i o r A d m i n i s t r a t o r P a n Q i a n g S y s t e m s A n a l y s t L i W e n k e I T I n f r a s t r u c t u r e S u p e r v i s o r J a v i e r A g u i r r e I T N e t w o r k & T e l e c o m m s S u p e r v i s o r R o d r i g o M e r l o I T B u s i n e s s S o l u t i o n s S u p e r v i s o r F r a n k l i n R o d r i g u e z I T C l i e n t S e r v i c e s S u p e r v i s o r A l v a r o A n d r a d e S y s t e m s A n a l y s t K l e v e r C a s t e l l a n o s S y s t e m s A n a l y s t L u i s L e m a N e t w o r k i n g E n g i n e e r J u a n G u e v a r a C o m m u n i c a t i o n s E n g i n e e r F r a n c i s c o M o r a S y s t e m s A n a l y s t M a x B r a v o W e b C o n t e n t A d m i n. M a y r a R e v e l o J D E S u p p o r t A s s e t M g m t R e n a t o A v i l é s D B A & C N C G u i l l e r m o d e l C a s t i l l o S y s t e m s A n a l y s t A l e x E s t r e l l a P e r i m e t e r a n d I n f o r m a t i o n S e c u r i t y A n a l y s t E d g a r C o r a l I T F i e l d C o o r d i n a t o r s Coordination B. T a f u r / J C V i n t i m i l l a J D E S u p p o r t F i n a n c e M i g u e l A. A g u i r r e J D E S u p p o r t H R / I T P a u l V a l d i v i e s o M a i n S e r v i c e P r o v i d e r s A n d e s e m p l o y e e ( 2 0 ) L e g e n d A n d e s E x p a t ( 2 ) D e s k t o p H a r d w a r e A n a l y s t M i g u e l E s p i n o s a F i e l d H e l p D e s k L e a d M a r í a J o s é J o f r e S y s t e m s A n a l y s t S i m e G r z u n o v L i v e l i n k A d m i n J a v i e r P a r e d e s U n i x P l a t f o r m A d m i n i s t r a t i o n D a v i d R a m í r e z S e r v i c e P r o v i d e r s ( 2 1 ) 6 F i e l d T e l e c o m m s S u p p o r t 8 H e l p D e s k A n a l y s t s S c h l u m b e r g e r A c c o u n t L e a d F r a n c i s c o E n d a r a S y s t e m s A n a l y s t J a i m e V i n u e z a T o t a l : 2 0 e m p l o y e e s, 2 1 O u t s o u r c i n g, 2 e x p a t s FIGURA 1. Estructura organizacional del departamento de IT de la organización Figura. Esquema provisto por la organización 14

15 Descripción de los segmentos que conforman el departamento de IT Como se menciono anteriormente debido a la importancia del departamento de IT y el sinnúmero de competencias que dependen de su administración se lo ha dividido en 4 segmentos los cuales son los encargados de administrar las funciones que se explicaran a continuación con el fin de brindar el soporte necesario para la ejecución y éxito del negocio, podemos observar esta división en el diagrama anterior donde se muestra también la estructura de IT (Figura 1) Infraestructura El departamento de infraestructura se encarga de administrar la LAN, storage architecture, platform, administración de servidores y escritorios Redes y telecomunicaciones Este segmento de IT es el encargado de gestionar la comunicación de VOS y DATOS, wireles, telefonía, microonda, comunicaciones satelitales perímetros de seguridad, VHF Radios Business solution Este segmento administra las aplicaciones de negocio (LiveLink), business inteligent, e-learning, service center entre sus principales dependencias Client services Este segmento es el más importante para poder establecer la madurez de SOA en la organización esta maneja el ERP de la organización JD Edwards, plataformas de Unix & Linux, administración de base de datos ORACLE 15

16 ANÁLISIS DE HARDWARE La organización tiene funcionales tres locaciones en el país las cuales son TARAPOA, KUPI y QUITO esta última es la matriz ubicada en la ciudad de Quito y las otras dos en el Oriente ecuatoriano (ver Figura 2) El departamento de IT services tiene actualmente bajo su administración más de 700 ordenadores distribuidos entre más de 1100 clientes en todas sus locaciones (600 computadores y 100 laptops) Infraestructura de servidores La organización tiene una infraestructura de servidores Intel con sistema operativo Windows 2000 y 2003 con más de 10 terabytes de capacidad de almacenamiento para los siguientes servicios: Aplication server escaneo Seguridad FTP Web server Servidor de acceso a JDE Citrix Base de datos: SQL 2000,2005 Estadísticas: websense Servidor de Archivos Gestión de conocimiento: Live link Controladores de dominio Microsoft Gestión de IT: SMS,MOM, monitoreo Servidores de impresoras Correo (acceso vía web y servidor de correo Exchange) Aplicaciones.net Y otros servicios varios conocidos como de multipropósito 16

17 Estos servidores se encuentran en la matriz como en los campamentos donde la infraestructura es menor y tiene lo básico como un servidor de dominio, correo, seguridad y un server multipropósito Adicionalmente en Quito se dispone de un sitio de testing donde se tienen los siguientes servidores: De pruebas de aplicaciones De pruebas de aplicaciones.net Servidores de maquinas virtuales Bases de datos de pruebas Sql Server 7, 2000 Web server INTERNET INBOUND FILTERING SPAM, ANTIVIRUS, CONTENT MANAGMENT QUITO AD SMS EXCH AV FTP BACKUPS 43 SERVERS 370 COMPUTERS TARAPOA KUPI AD SMS EXCH AV BACKUPS AD SMS AV 11 SERVERS 200 COMPUTERS 5 SERVERS 130 COMPUTERS FIGURA 2 Infraestructura de la Organización FIGURA 2 Provista por la organización 17

18 Infraestructura de Servidores UNIX La organización cuenta también con un esquema centralizado para las aplicaciones de misión crítica basados en servidores Unix con un sistema de respaldo redundante (Ver figura 4) para los siguientes servicios: Base de datos: Oracle. Aplicación: JDE (ERP JD Edwards). Aplicaciones del negocio: Landmark y Petrosys. Servidor de pruebas Servidor de aplicaciones: Live Link, A continuación se presenta los servidores UNIX como se muestran en el siguientes grafico (Ver figura 3). FIGURA 3 Infraestructura servidores Unix. FIGURA 3. Provista por la organización 18

19 Sistema de almacenamiento Servers connected to our m ain storage system 1. File Server 2. Exchange Server 3. Server for Backups 4. Backup Library 5. Landm ark Server 6. JDE App Server 7. Livelink Server Capacity ready to use: 13.0 TB Capacity used: 9.0 TB RACK 10 R AC K 5 R ACK 9 RACK SW ITC H SW ITC H 2 R EDU ND AN T LIN KS BETW EEN EAC H SER VER AN D EVA 3000 FIGURA 4 Sistema de almacenamiento. El Sistema de almacenamiento de la organización se caracteriza por tener una conexión redundante entre sus diferentes servidores, consta de un servidor de archivos, un servidor de Exchange, un servidor que realiza backups automáticos un servidor para la aplicaciones landmark en UNIX, un servidor para el ERP JDE y otro servidor para livelink el cual es su sistema de manejo de inventarios. Se puede afirmar que el sistema en cuestión de almacenamiento consta de de aproximadamente 20 Tb de las cuales tiene disponible unas 13 Tb es decir un 65% del espacio disponible FIGURA 4. Provista por la organización. 19

20 ANÁLISIS DE SOFTWARE A continuación se va a describir las aplicaciones más importantes que dan soporte al negocio en la organización las cuales son: Aplicaciones principales o de CORE: Contabilidad de producción (ver figura 6) BI de producción Perforación y terminados (drilling) Aplicaciones técnicas de ingeniería: Landmark, GeoQuest, Geographix, PVR, Petrosys (ver figura 5) Sistema Integrado ERP: J. D. Edwards (JDE) Gestión de documentos: Soluciones Livelink Otros sistemas de apoyo: Intranet e Internet de servicios web Sistema de Nómina Transporte y sistema de aviación Sistemas EHS-CA y GIS Aplicaciones legales Aplicaciones de Finanzas 20

21 Core Applications Son las aplicaciones principales de la compañía. Como es de entender el objetivo primordial de una Petrolera es la exploración, perforación extracción y venta del petróleo, para lo que han sido desarrolladas las aplicaciones descritas a continuación Landmark, GeoQuest, Geographix, PVR, Petrosys, Este paquete de software en el que se encarga de gestionar la Exploración, Perforación, competición y producción de los posos, parte fundamental de la industria de OIL and GAS en Ecuador (ver figura 5) Work flow de las aplicaciones CORE.- podemos ver a continuación el funcionamiento de las Aplicaciones técnicas de ingeniería que consiste en el análisis geofísico y sísmico para proceder a la perforación en el lugar adecuado, la data que se extrae al aplicar las diferentes herramientas de campo son procesadas por estas aplicaciones para apoyar al proceso de producción EXPLO RATION CORPORATE DATA REPOSITORY GEOPHYSIC AL D A TA MAPS W ELLS GEOLOGICAL DATA AND LOGS Read / Write Interpretations Read Only Interpreted Data SEISW O RKS SEISVISIO N Read / Write Interpretations O pwnworks WRITE Final Official Interpretations Read / Write Temporary Interpretations GGX GeoAtlas READ Final Official Interpretations PETROPHYSIC M APS AL DATA Read / Write Interpretations GGX Prizm LANDMARK OPENW ORKS / GEOGRAPHIX Figura 5 Flujo de aplicaciones CORE Figura 5. Provista por la organización. 21

22 Producción.- flujo de información a) DATOS CARGADOS EN EXCEL PRIMERAMENTE EN CAMPO d) GENERAR REPORTES Y ENVIARLOS VÍA O IMPRESOS POR PARTE DE EL GOBIERNO, INGENIEROS, PERSONAL DE CAMPO b) ESTIMADO DE PRODUCCION DISTRIBUIDA POR POZOS c) REVISAR Y REPORTAR DATOS FUERA DE LOS LÍMITES ESTIMADOS FIGURA 6 Flujo de datos de producción. a) Primeramente se registra todos los datos referente al campo en producción en general estos son acerca de la producción del campo b) Una vez que se tiene estos valores se procede a distribuirlo por el numero de posos perforados en dicho campo, sabemos que en un campo está compuesto por un sin número de posos c) Se procede a revisar la información para encontrar posibles valores que pueden exceder lo planificado o principalmente no cumplir las expectativas de producción d) Se genera un reporte final por parte del los Ingenieros encargados del campo, del Gobierno nacional, y del personal de campo para ser enviado y proceder con el ciclo de producción FIGURA 6. Desarrollado por el autor. 22

23 SISTEMA INTEGRADO ERP (J.D. Edwards) J.D. Edwards suite.- Este ERP desarrollado por ORACLE e implementado por el antecesor de Andes Petroleum, la compañía canadiense ENCANA S.A., es el sistema encargado de relacionar los principales procesos del negocio en Andes Petroleum. Este software de integración se basa en centralizar los procesos de Finanzas, RR-HH, contabilidad, herramientas, Inventarios, Manejo de Recursos entre los principales segmentos manejados por JD Edwards (Ver Figura 7 y 8) Funciones de negocio de J.D. Edwards Asset Management HR Financial Accounting Oil & Gas Accounting System Tools FIGURA 7 Funciones de JDEdwards. FIGURA 7. Provisto por la organización. 23

24 QUE MANEJA JDEDWARDS AREA FUNCIONES FINANZAS El Libreto de direcciones Las Cuentas a pagar Las Cuentas a cobrar Los Activos fijos Los impuestos RR-HH Información del Empleado LOGÍSTICA Y DISTRIBUCIÓN Administración de Almacén e inventarios Proceso de aprobación Materiales & Contratos MANEJO DE RECURSOS Seguimiento del recurso Equipo & el Mantenimiento de la Planta Figura 8. Cuadro de funciones de JDEdwards. FIGURA 8. Cuadro desarrollado por el Autor. 24

25 Arquitectura de interconexión de JDEdwards La arquitectura de interconexión de JDE se maneja en la capa de aplicación y de presentación entre sus componentes tiene un servidor Web un servidor de terminal y el de aplicaciones (ver figura 9) FIGURA 9 JDEdwards Arquitectura FIGURA 9. Provista por la organización 25

26 GESTIÓN DE DOCUMENTOS Livelink Solutions Livelink es un sistema de gestión documental que se encarga de todo el manejo de inventario físico como lógico de la organización, este sistema funciona vía Intranet dando la facilidad a los usuarios del mismo de poder acceder a él en las diferentes locaciones de la empresa. Esta herramienta también maneja el inventario de software de la organización al igual que las licencias del software que es adquirido por la compañía. OTROS SISTEMAS DE APOYO Transport and Aviation System Este sistema se encuentra en etapa de desarrollo en la compañía, monitorea el trasporte terrestre y las diferentes clases de transporte aéreo que existe en la compañía como son: Vuelos de Campo Vuelos Charter Vuelos Internacionales Vuelos Locales Intranet e Internet de servicios web Sistema de Nómina Transporte y sistema de aviación Sistemas EHS-CA y GIS Aplicaciones legales Aplicaciones de Finanzas 26

27 Descripción de la Arquitectura actual de la Organización Actualmente la interconexión de las aplicaciones del negocio en la organización, se podrían definir como punto a punto en la figura 10 podremos observar de mejor manera la situación actual de las aplicaciones de la organización (Ver figura 10). Topología de Arquitectura Hardware Cliente Hardware Servidor Aplicaciones principales Red Estándares Número de Usuarios Implantación usando arquitectura de cliente servidor con aplicaciones de 2 capas con presentación en ambiente web y algunas aplicaciones n capas usando.net Estaciones de trabajo cliente típicamente son computadores personales Sistemas UNIX bajo plataforma SUN Servidores Intel varios Aplicaciones de negocio petrolero ERP Aplicaciones de apoyo Basada en LAN o WAN Típicamente tecnología propietaria Microsoft 1100 aproximadamente. Figura 10. Cuadro Arquitectura actual de la organización. FIGURA 10. Cuadro desarrollado por el autor. 27

28 ARQUITECTURA ACTUAL JD EDWARDS GEOFRAME LANDMARK OPENWORKS OTROS APPs Repositorio de datos servicio corporativos Repositorio de datos de Operación Repositorio de datos De exploración Otros FIGURA 11. Arquitectura actual de la organización. FIGURA 11. Desarrollada por el autor. 28

29 1.3.- ANÁLISIS DE LOS RESULTADOS DE LA EVALUACIÓN Evaluación cuestionario de Procesos de la herramienta (Ver anexos 2) Descripción de la evaluación Para la parte de Procesos la evaluación se centra en cuatro puntos fundamentales los cuales sean analizados uno por uno en la evaluación correspondiente con el fin de obtener el nivel respecto a procesos de la organización en SOA: EXPERIENCIA DE LA ORGANIZACIÓN EN SOA Después de realizar el taller y proponer un cuestionario el cual se encuentra en la parte de anexos referente a este tema (anexos Cuestionarios Procesos) se ha llegado a las siguientes conclusiones: En el momento actual la empresa no posee un diseño ni implementación de SOA a nivel empresarial y muy poca en sus líneas de negocio La organización tiene en un nivel conceptual el diseño de un Bus de Servicios corporativos parte fundamental para la implementación de SOA, podemos agregar a esto que se ha realizado la compra de las herramientas necesarias para poder implementar un ESB Se ha realizado la implementación de conectores entre aplicaciones heterogenias de manera aislada No se ha podido realizar una integración completa entre aplicaciones de infraestructura base Después del análisis realizado podemos llegar a la conclusión: La organización tiene una experiencia en diseño e implementación de SOA para unos pocos y aislados procesos del negocio 29

30 NIVEL DE LA ORGANIZACIÓN PARA SOPORTAR SOA SOA permite el crecimiento de la flexibilidad y la integración a todo nivel en la organización, lo que es indispensable para enfrentar los cambios que hoy en día el mercado obliga a hacer a los negocios, de tal forma que nos permite reutilizar servicios para satisfacer nuevos servicios, es importante definir el nivel de flexibilidad e integración que la organización tiene en este momento para poder establecer el grado de madurez de SOA en la misma Se han obtenido las siguientes afirmaciones: Las aplicaciones orientadas a servicios presentes en la organización son muy escasas. No se ha definido los procesos de la organización orientados a servicios ni tampoco se posee una arquitectura de referencia que facilite la implementación de SOA. La mayoría de las aplicaciones en la organización se encuentran interconectadas a través de interfaces codificadas y especificas entre los diferentes componentes de infraestructura No se tiene implementado intercambio de información vía Web services en la organización Lo que nos lleva a la siguiente conclusión Existe una muy limitada capacidad para definir procesos orientados a servicios así como es necesario investigar i difundir el manejo de sistemas estándares y guías orientados a servicios 30

31 NIVEL DE PERCEPCIÓN DE SOA POR PARTE DE LOS STAKEHOLDERS EN LA ORGANIZACIÓN Para poder implementar SOA en la organización es necesario que los stakeholders tengan conocimiento del impacto en el negocio al aplicar SOA en la organización. Sabemos que en nuestro medio la resistencia al cambio es un fuerte obstáculo para la implementación de nuevas tecnologías por lo que trataremos de definir la posición de los involucrados con respecto a SOA Se han obtenido las siguientes afirmaciones: Lastimosamente los ejecutivos en la organización no han sido comunicados acerca de los nuevos conceptos de orientación a servicios. La posibilidad de desarrollo de SOA en la organización se maneja como un proyecto interno de IT. Los ejecutivos no entienden el impacto tecnológico y organizacional de la implementación de SOA en la organización. Al ser un proyecto manejado por IT, y al tener las herramienta principales para su implementación, se tiene luz verde para realizarla, y se está tomando la iniciativa de sobre la marcha, involucrar a los ejecutivos de la organización en las grandes ventajas de SOA Conclusión: Lastimosamente el conocimiento de SOA por parte de los stakeholders en la organización es casi nulo, sin embargo se está tratando involucrar a los stakeholders en el proceso de diseño e implementación de SOA en la organización 31

32 LA ORGANIZACIÓN MANEJA TÉCNICAS O HERRAMIENTAS PARA DISEÑAR SERVICIOS SOA permite que los procesos en la organización sean optimizados a través de servicios, permitiendo más rapidez en el tiempo de respuesta y dando más flexibilidad al negocio, por lo que es importante tener claramente definido un mecanismo que permita encontrar definir y diseñar servicios, No existe ninguna herramienta para modelar servicios Existen aplicaciones con código orientado a objetos Se maneja el concepto de rehusar código Podemos concluir: En la organización lastimosamente no existe la noción todavía de división de unidades de negocio en unidades elementales llamadas servicios. Por lo que podemos concluir que no existe implementado métodos o herramientas que permitan diseñar servicios, sin embargo existe sistemas en los que se maneja codificación orientada a objetos, que sin duda facilita la adopción de el concepto de servicios. También podemos destacar que existe el concepto de rehusó de código en la organización, este es un punto clave del porque la organización desea implementar SOA debido a que el reutilizar código para resolver problemas es algo común en la organización 32

33 Evaluación cuestionario de Arquitectura de la herramienta (Ver anexo 3) EN QUE NIVEL SE ENCUENTRA LA ORGANIZACIÓN CON RESPECTO A LA HABILIDAD DE CREAR NUEVAS APLICACIONES DESDE SERVICIOS EXISTENTES Se ha desarrollado una interfaz que permite la interacción de dos aplicaciones heterogenias orientada a prestar un servicio local no ha nivel empresarial. No se ha desarrollado soluciones orientadas a servicios en la organización. La empresa está en una etapa inicial en el desarrollo de aplicaciones que involucren servicios en la organización. Conclusión: La organización se encuentra en un nivel inicial, en la creación de aplicaciones tomando como base servicios existentes sin embargo. Ya se ha comenzado a ensayar en casos pequeños y de testing con la creación de aplicaciones orientadas a servicios. 33

34 CAPACIDAD DE LA ORGANIZACIÓN PARA CREAR SERVICIOS RÁPIDA Y FÁCILMENTE. Para que una organización pueda disfrutar de todos los beneficios de SOA esta debe tener la habilidad de crear servicios rápida y fácilmente. Aspectos relevantes: No se tiene definidas técnicas para la creación de servicios en la organización. La arquitectura actual de la organización no permite fácilmente la identificación de servicios. Conclusión: La organización no tiene definida técnicas o herramientas que le permitan identificar servicios fácilmente. 34

35 HABILIDAD DE LA ORGANIZACIÓN DE CONECTARSE CON APLICACIONES HETEROGENIAS Un beneficio clave de una SOA es la facilidad de interconexión de aplicaciones heterogenias, por lo que definir el nivel de la arquitectura actual con respecto a este punto es indispensable. Aspectos relevantes: Se ha logrado conectar aplicaciones para resolver problemas aislados a nivel local. Se ha desarrollado un adaptador para ligar dos aplicaciones heterogenias no se tiene un nivel de arquitectura que conecte varias aplicaciones heterogenias Conclusión: A pesar de no tener una arquitectura que permita la interconexión total de aplicaciones heterogenias, se ha desarrollado soluciones pequeñas que han logrado integrar aplicaciones. Por lo que podemos concluir que la arquitectura de la organización permite un nivel todavía primitivo de interconexión entre aplicaciones heterogenias. 35

36 EL REUSO DE APLICACIONES EXISTENTES PERMITEN REDUCIR COSTOS Y TIEMPO EN LA ORGANIZACIÓN. EN QUE NIVEL PODRÍA COLOCAR A LA ORGANIZACIÓN RESPECTO A LO ANTERIOR. Aspectos relevantes: La reutilización de código es un punto fundamental por el cual la organización tomo la decisión de adoptar SOA. Es muy limitada la reutilización de funciones de aplicaciones para resolver problemas de otras Ha habido casos de rehusó de código, de manera aislada Conclusión: Es de suma importancia para la organización, el rehusó de código por lo que se decidió tomar la opción de SOA, sin embargo se encuentra en un nivel inicial 36

37 Evaluación cuestionario de Aplicaciones de la herramienta (Ver anexo 4) RELACIÓN ENTRE EL NEGOCIO E IT Una fuerte relación entre IT y el negocio y esto se lo consigue con un sistema orientado a servicios por lo que es importante determinar el grado de flexibilidad de la arquitectura asía la orientación a servicios computacionales. Aspectos relevantes: El nivel de unión de IT y el negocio es medio No se tiene totalmente definido el organización concepto de servicios en la La arquitectura actual es todavía muy estática Conclusión: La relación de IT y el negocio se encuentra en un nivel inicial con respecto a prestar las facilidades necesarias para orientarse a la prestación de servicios, se puede decir también que la organización está en un proceso de inducción hacia lo que es SOA. A nivel de IT, mas no a nivel empresarial. 37

38 MODELO DE GOBERNANZA DE SOA Es necesario definir estándares de SOA para `poder tener un modelo de gobernanza claro en la organización Aspectos relevantes: No se ha definido estándares claros para el manejo de SOA en la organización. 38

39 COMPARTICIÓN DE SERVICIOS EN LA ORGANIZACIÓN A través de la creación de una capa de servicios se puede compartir servicios a través de toda la organización. Es importante definir la situación de la organización con respecto a la facilidad para compartir o relacionar servicios. Aspectos relevantes: No se tiene un concepto de servicios a nivel empresarial No se ha definido una capa de servicios Se tiene a nivel de línea de negocio un conocimiento empírico de servicio pero de manera aislada Conclusión: Como se ha visto anteriormente, la organización no tiene un concepto claro de servicios a nivel empresarial sin embarga a nivel de línea de negocio se puede decir que de una manera empírica se comparte funcionalidad de algunos servicios. 39

40 INTERCONEXIÓN ENTRE APLICACIONES Y MIDDLEWARE La orientación a servicios puede apoyar sustancialmente a evolucionar la interconexión de aplicaciones y la funcionalidad del middleware. Es necesario saber la habilidad de la organización. Aspectos relevantes: Actualmente se está implementando un middleware en la organización Se tiene adquirido el software necesario para implementar un ESB Se ha realizado testing para interconexión de aplicaciones heterogéneas con éxito Conclusiones: La organización actualmente está iniciando la implementación de un middleware que permita la interconexión de aplicaciones y que vaya de la mano con la implementación de SOA en la organización. 40

41 Evaluación cuestionario de infraestructura de la herramienta (Ver Anexo 5) NIVEL DE INFRAESTRUCTURA DE LA ORGANIZACIÓN PARA SOPORTAR SERVICIOS ORIENTADOS A LA COMPUTACIÓN Aspectos relevantes: La infraestructura de la organización es robusta y puede facilitar la implementación de SOA. Se realiza reuniones de calidad que abarcan la infraestructura de la organización y junto con los stakeholders se realiza planes para soportar servicios orientados a la computación Conclusiones: Las condiciones de infraestructura para soportar servicios orientados a la computación son muy buenas en la organización, a parte se realizan en la actualidad reuniones de calidad dentro de la organización para definir planes de implementación de una arquitectura más flexible. 41

42 CAPACIDAD PARA MEDIR LA ACTUACIÓN DE LOS PROCESOS DE NEGOCIO EN LA ORGANIZACIÓN Y LA REACCIÓN DE LA DATA. Aspectos relevantes: La organización tiene un buen monitoreo de los procesos de negocio El monitoreo se realiza en todo el ciclo de vida del proceso En varios casos el tiempo de respuesta de la información es demasiado lento Conclusión: La empresa tiene una buena visibilidad del ciclo d vida de negocio, sin embargo la data es recibida demasiado tarde para actuar. 42

43 MODELO DE SEGURIDAD PARA SOA El establecer un buen modelo de seguridad para SOA provee la protección necesaria a los recursos del negocio, por lo que es necesario determinar la capacidad de seguridad de la infraestructura de la organización. Aspectos relevantes: No se ha establecido un nivel de seguridad para SOA Se maneja seguridad en las aplicaciones e infraestructura pero no es centralizada. Conclusiones No se ha establecido un sistema central de seguridad para la infraestructura en la organización. 43

44 ESTRATEGIA DE LA ORGANIZACIÓN PARA DESARROLLAR SEGURIDAD ALREDEDOR DE UNA SOLUCIÓN ORIENTADA A SERVICIOS. Es necesario para la buena implementación y duración de una solución orientada a servicios desarrollar una infraestructura de seguridad a fin. Aspectos relevantes: No se ha desarrollado una estrategia de seguridad para SOA Conclusión: La seguridad no está al momento considerada en la implementación de una solución orientada a servicios, sin embargo esta en evaluación. 44

45 1.4.- ESTABLECIMIENTO DEL NIVEL DE MADUREZ DE SOA EN LA EMPRESA A continuación vamos a mostrar la madures de SOA de la organización dada por la herramienta en la que se apoyo esta evaluación tomando, en cuenta el análisis por separado que se ha hecho en la parte anterior a la misma. Análisis del nivel de madurez Este análisis de basa en cuatro puntos fundamentales que ya han sido analizados a detalle en la parte anterior, así que se tratara ser los más sintético posible en la evaluación de los cuatro puntos en los que se basa la evaluación. FIGURA 12. Análisis de madurez FIGURA 12. Grafica tomada de la herramienta de evaluación. 45

46 MADUREZ DE SOA CON RESPECTO A PROCESOS FIGURA 13. Análisis Procesos Podemos concluir que la organización con respecto a procesos no ha definido claramente el concepto de SOA, se recomienda que se involucre a todos los miembros de la organización en el manejo de procesos desde la perspectiva de SOA, para lo que se puede tomar en cuenta las recomendaciones dadas por la herramienta: (Ver figura 13) Revisar tutoría de SOA propuesto por IBM Desarrollar una Estrategia para el desarrollo de SOA en la organización. Promover los principios de SOA a través de los stakeholders FIGURA 13. Grafica tomada de la herramienta de evaluación. 46

47 MADUREZ DE SOA CON RESPECTO A LA ARQUITECTURA FIGURA 14. Nivel de Madurez Arquitectura La madurez de la arquitectura de SOA se ubica en NIVEL 1 (Ver figura 14) NIVEL 1.- el nivel uno de madurez nos muestra que está en un nivel de conectividad es decir que la conexión de las aplicaciones heterogenias en la organización están en una etapa inicial, para lo que es necesario aprender los estándares de SOA y de los modelos de servicios requeridos para soportar SOA. De esta forma se podrá interconectar las aplicaciones de forma que soporten la arquitectura deseada en la organización. Un ejemplo de esto es el diseño de un Enterprise service bus. FIGURA 14. Grafica tomada de la herramienta de evaluación. 47

48 MADUREZ DE SOA CON RESPECTO A LAS APLICACIONES FIGURA 15. Análisis de madurez Aplicaciones En cuanto a la dimensión de aplicaciones, se debe evaluar un caso de negocio SOA y considerar los nuevos desafíos del ciclo de vida de desarrollo de aplicaciones y actualizar los desarrolladores bajo este nuevo esquema. FIGURA 15. Grafica tomada de la herramienta de evaluación. 48

49 MADUREZ DE SOA CON RESPECTO A LA INFRAESTRUCTURA FIGURA 16. Análisis de Madurez Infraestructura Se encuentra en un nivel de desarrollo (Ver Figura 16) Nivel de Desarrollo.- Con respecto a la infraestructura la organización se encuentra en un nivel de Planeación Diseño y desarrollo, lo que es importante para poder definir una solución SOA que se ajuste de manera correcta a la organización, estudiando la mejor posibilidad de adoptarla También en este nivel es necesario definir una guía de seguridad que soporte las necesidades de las operaciones de negocio. FIGURA 16. Grafica tomada de la herramienta de evaluación. 49

50 NIVEL DE MADUREZ GENERAL DE LA ORGANIZACIÓN Con el apoyo de la herramienta y las evaluaciones desarrolladas se ha podido establecer el nivel de madurez de la organización el cual se define como SISTEMÁTICO el cual se va a describir a continuación NIVEL DE MADUREZ DE SOA EN LA ORGANIZACIÓN Se puede concluir que la organización se encuentra en una etapa de estandarización de servicios a través de conexiones robustas. A pesar que existen nichos de aplicaciones aisladas, lo que obstaculiza la integración de las mismas. Por otro lado los usuarios de IT, están comenzando a aprender sobre el concepto de servicios a partir de los recursos que maneja IT, y de esta forma conectarlos de una manera más eficiente Se da a conocer también la necesidad de desarrollar un ESB enterprise service bus que permita la interconexión de aplicaciones heterogenias en la organización, tomando en cuenta que la empresa ha adquirido ya el software necesario para su implementación, dejando en claro que de un buen diseño se asegurara en gran parte la implementación del ESB pilar de la Arquitectura orientada a servicios a ser adoptada por la organización 50

51 CAPITULO II DISEÑO DE LA SOA (BUS DE SERVICIOS CORPORATIVOS) PARA LA COMPAÑÍA DISEÑO DE LA SOA (BUS DE SERVICIOS CORPORATIVOS) PARA LA COMPAÑÍA Metodología a utilizar ANALISIS DE LA GESTION DE SERVICIOS (MODELAJE) Análisis de Requerimientos del negocio Requerimientos funcionales Identificación de Servicios (Análisis Top-Down) Cuadro de servicios identificados después del análisis DISEÑO LOGICO DEL BUS DE SERVICIOS CORPORATIVOS(ENSAMBLAJE) Requerimientos de la organización para el Enterprise service bus Diseño de los componentes del ESB VISTA DEL DISEÑO LÓGICO DEL ESB PARA LA ORGANIZACIÓN COMO LA IMPLEMENTACIÓN DE LA ARQUITECTURA MEJORARÍA LA GESTIÓN DE SERVICIOS EN LA ORGANIZACIÓN Descripción de ventajas al implementar el enterprise service bus en la organización MEJORA CONTINUA DE SOA EN LA ORGANIZACIÓN Crear un centro de competencias de integración de aplicaciones Desarrollar un mapa de integración para su empresa Documentar las interfaces de aplicación Comenzar pequeño y crecer incrementalmente Valor para el Negocio dado por la Integración

52 2.1.- Metodología a utilizar Para la propuesta de diseño de una SOA en esta organización, objetivo final de este documento. El autor se soporta de la metodología presentada por IBM con respecto a la implementación de SOA (Figura 16). En una organización de la cual este documento desarrollara las partes de modelado y ensamblaje que vendrían a constituir el diseño de SOA. IBM considera a SOA como un ciclo de vida. Comienzan en la fase del modelo reuniendo requisitos de los negocios y diseñando sus procesos de negocios. Una vez que los procesos son optimizados, los implementan ensamblando nuevos servicios y los existentes para formar estos procesos de negocios. Luego despliegan estos activos en un entorno de servicios altamente seguro e integrado. Una vez que los procesos de negocios han sido desplegados, los clientes IBM los administran y monitorean tanto desde la perspectiva de IT como la de negocios. La información reunida durante la fase de administración es alimentada nuevamente al ciclo de vida para posibilitar una mejora continua de los procesos. En sostén de todas estas etapas del ciclo de vida están el gobierno y los procesos, los que proporcionan guía y percepción para el proyecto de SOA. FIGURA 17. Ciclo de vida de SOA FIGURA 17. Provista por el sitio web de IBM señalado en la bibliografía 52

53 MODELADO 1.- Análisis de requerimientos del negocio. 2.- Identificación de servicios (Análisis Top Down). Identificar el proceso a analizar. Análisis de flujo de Procesos y sub Procesos de cada aplicación a integrar. Identificar los Casos de uso. Exponer los casos de uso como servicios del negocio. 3.- Cuadro de servicios identificados después del análisis ENSAMBLAJE 1.- Requerimientos de la organización para el Enterprise service bus 2.- Diseño de los componentes del ESB Capas Aplicativas Capa de presentación Capa de integración Capa de servicios de datos Conectores 3.- Diseño lógico del Enterprise service bus DESARROLLO ADMINISTRACIÓN Nota.- las partes de la metodología de DESARROLLO como de ADMINISTRACIÓN no están desarrolladas en el documento a continuación debido a que el objetivo del documento es presentar un diseño mas no implementarlo 53

54 MODELADO 2.2.-Análisis de la gestión de servicios que presta la empresa Análisis de Requerimientos del negocio La organización se describe como una empresa orientada a funciones, no ha procesos, es decir que los diferentes departamentos del negocio no tienen tareas comunes para realizar un proceso en la organización. Es decir cada uno cumple con su función. Sin que afecte de forma directa el desempeño de la función de otro departamento de la organización. Es decir el departamento de IT es el encargado de proporcionar y mantener los recursos necesarios de gestión de la información en la organización, independientemente si el departamento de exploración encuentra o no yacimientos de petróleo. El atender requerimientos tecnológicos por parte de las otras áreas de la organización, es la función primordial de IT, mas no es parte indispensable para el funcionamiento de otros departamentos como son, el de exploración, producción, finanzas o RR.-HH. La necesidad de optar por una Arquitectura orientada a servicios en la organización nace de la necesidad del departamento de IT de evolucionar tecnológicamente, hacia una arquitectura que le permita responder de mejor manera a los cambios inesperados de la industria petrolera en el Ecuador. En el momento actual existe un sinnúmero de aplicaciones que funcionan de manera aislada gastando recursos, y provocando que exista replica de información. Ya que la Empresa se dedica a la explotación de Petróleo, podemos concluir que el mercado es muy cambiante, cuando el precio del barril sube la empresa necesita mas recursos, de igual manera cuando el precio del crudo disminuye esta tiende a contraerse. Por lo que necesita una arquitectura capaz de responder inmediatamente a nuevos requerimientos del negocio. Podemos añadir que andes Petroleum se desacoplo de la empresa ENCANA la cual es una de las organizaciones más grandes en el mundo en este medio, por lo que se vio en la necesidad de ajustar sus necesidades tecnológicas, a las de una empresa de menor tamaño. 54

55 Requerimientos funcionales Integración de Sistemas: Proveer integración en tiempo real entre los sistemas utilizando el Bus de integración (ESB). Sistemas a Integrar La organización necesita integrar los siguientes sistemas atreves de un enterprise service bus: APLICACIONES A INTEGRAR JD EDWARDS GEOFRAME LANDMARK OPENWORKS OTROS APPs Repositorio de datos servicio corporativos Repositorio de datos de Operación Repositorio de datos De exploración Otros FIGURA 18. Aplicaciones a integrar Las aplicaciones de operación y exploración que se puede ver en la Figura 18 funcionan de manera independiente al resto de las aplicaciones del negocio, por lo que el análisis de servicios al igual que el diseño del Enterprise service bus. Se basa en las aplicaciones aisladas y el ERP entre las aplicaciones que formaran parte del análisis y el diseño están: o APTRAVEL.- software de gestión de viajes o AUSENCIAS.- Software de gestión de ausencias o HRPortal.- Software de consulta de Beneficios del Empleado o Colibrí.- Software de información (Noticiero empresarial). o APORTAL.- Software de Aprobación de solicitudes o EVERYONE.- Web Service de consulta de JDEdwards ERP FIGURA 18. Desarrollado por el autor. 55

56 Al integrar las aplicaciones mencionadas en la parte anterior anteriores utilizando un Enterprise service bus se busca solucionar los siguientes requerimientos: Modularidad: En SOA, las funciones de negocio son desacopladas, y son colocadas en servicios que son auto contenidos y auto descritos, dichos servicios a su vez pueden estar compuestos por otros servicios. Estos servicios de negocio pueden mezclarse y combinados para crear nuevos servicios compuestos. Encapsulamiento: Los datos y la lógica de negocio en un servicio SOA esta desacoplados de su interfaz que los describe. El encapsulamiento oculta la complejidad interna del servicio lo mismo que los detalles de la implementación mientras que la funcionalidad es expuesta para ser consumida por descubrimiento y acceso Desacoplamiento: El objetivo es minimizar las dependencias y si es posible eliminarlas en la forma de interacción entre las aplicaciones. El bajo acoplamiento es la salvaguarda de los servicios de SOA hacia el futuro con respecto al cambio de las implementaciones en los proveedores de los servicios. Además permite que un servicio se pueda descubrir e invocar dentro del dominio o fuera de los límites de la empresa, ya que se emplean estándares de servicio y de seguridad. Seguridad: El objetivo es poder contar con control de acceso a las redes de transporte de la información para controlar la seguridad del flujo de información y por otra parte, poder contar con control de ejecución de los servicios publicados en la solución. Aseguramiento de acceso a la conexión de la red de servicios. Aseguramiento de la transferencia de información entre las capas. Aseguramiento de la data entre las capas. Aseguramiento de capacidad de ejecución de servicios. Autenticación / Identificación Medidas diseñadas para prevenir transmisiones fraudulentas estableciendo la validación de la transmisión, mensajes, la estación o el individuo. Control de acceso Prevenir el uso no autorizado de un recurso, incluyendo el prevenir el uso de recursos de una manera no autorizada. Confidencialidad - La propiedad de la información no está disponible o mostrada a individuos, entidades o procesos no autorizados. 56

57 Identificación de Servicios (Análisis Top-Down) Análisis Top-Down es un análisis de arriba hacia abajo es decir de los procesos a los servicios. La descomposición describe una aproximación iterativa de tareas y piezas que se van desmembrando hacia abajo en pequeñas partes hasta llegar a un nivel de granularidad deseado. Para este caso la identificación del servicio parte desde el dominio del negocio y es descompuesto en áreas funcionales en subsistemas, procesos, subprocesos y en un alto nivel en casos de uso. El caso de negocio es expuesto como un servicio de negocio con una granularidad esperada para poder ser reutilizable por otras funciones de negocio. Ya que tenemos identificada las aplicaciones del negocio a integrar y el proceso principal que realiza cada una; debemos proceder a hacer un análisis TOP DOWN de cada una de ellas para poder identificar los servicios para lo que seguiremos los siguientes pasos Pasos de análisis TOP DOWN Identificar el proceso a analizar. Análisis de flujo de Procesos y sub Procesos de cada aplicación a integrar. Identificar los Casos de uso. Exponer los casos de uso como servicios del negocio. Para el análisis se tiene la ventaja de ya tener identificada las aplicaciones que formaran parte del diseño del ESB, por lo que a continuación se procederá a realizar el análisis TOP DOWN a cada aplicación identificando el o los procesos que realiza cada aplicación para el negocio. Para poder definir los servicios que serán implementados en el ESB. 57

58 Como se ha explicado anteriormente (ver página 49), el análisis se realizara partiendo de los procesos que manejan las aplicaciones que la organización necesita que se integren atreves del diseño del ESB. Estos procesos han sido definidos junto a los administradores de las herramientas que se van a integrar en el bus Aplicaciones a integrar y procesos a analizar: APLICACIONES PROCESOS APTRAVEL (Por Desarrollar) Gestionar viajes AUSENCIAS(Por Desarrollar) Gestionar ausencias COLIBRÍ Informar noticias de la organización HRPORTAL Consultar beneficios del empleado APORTAL Aprobar solicitud EVERYONE Consultar datos JDEdwards Figura 19. Aplicaciones y procesos. Para comprender los diagramas que se desarrollaran a continuación a continuación se expone un diccionario de las figuras a utilizar en los diagramas a continuación. Diccionario de colores de los diagramas de Proceso.- para el desarrollo de los diagramas de procesos se utilizara VISIO 2003 Entradas Y Salidas del proceso Pasos del proceso Documentos (Digitales o Físicos) FIGURA 20. Estándar de colores para diagramas de procesos. Diccionario de Formas diagramas de casos de uso.- para el diseño de casos de uso se utilizara la herramienta Power Designer Vrs 11. Case_5 Servicios Actores Actor_3 FIGURA 21. Formas utilizadas en diagramas de casos de uso expuestos como servicios. FIGURAS 19, 20, 21. Desarrolladas por el autor. 58

59 análisis del proceso gestionar viajes (APTRAVEL) Identificación de Procesos Esta aplicación (Aplicación a desarrollar) tiene como proceso central gestionar la solicitud de eventuales viajes solicitados por el personal. Esta recoge información de una base de datos propia de la misma, en la figura 22 y 23 (ver figura 17), se puede observar el flujo del proceso para solicitar y aprobar un trámite de viaje requerido por un empleado en cualquier locación. PROCESO: SITUACIÓN ACTUAL. DESCRIPCIÓN PROBLEMA SOLICITAR VIAJES Gestionado a través de software independiente llamado APTRAVEL. Al tener la compañía tres locaciones Quito, Kupi y Tarapoa, se necesita gestionar el traslado de Recursos entre las locaciones, los cuales son a través de vía aérea o terrestre, adicionalmente se gestiona las reservaciones para viajes internacionales Al ser un sistema aislado existe duplicación de la información de los empleados, a parte que se consume más recursos para su funcionamiento SERVICIOS Aprobación Viaje Solicitud de Viaje.- Servicio de aprobación o negación del viaje solicitado Servicio que permite solicitar viaje Figura 22. Proceso Gestión de Viajes. FIGURA 22. Desarrollado por el autor. 59

60 DIAGRAMA DE PROCESO GESTIÓN DE VIAJES FIGURA 23. Desarrollado por el autor. Figura 23. Proceso Gestionar Viaje. 60

61 Casos de uso expuestos como servicios Actores Empleado.- todo el personal ligado laboralmente con la empresa Gerente.- Supervisor capaz de aprobar la solicitud de viaje del empleado Servicios Solicitar viaje.- Este servicio consiste en la posibilidad de que cada empleado solicite viajes atreves de las locaciones de la organización (ver figura 24). Solicitar viaje Empleado Figura 24. Servicio solicitar viaje, realizado por el autor Aprobar viaje.- El gerente encargado del empleado tiene que aprobar la solicitud o negarla. Lo que brinda al gerente un servicio de aprobación de solicitudes (ver figura 25). Aprovar viaje Gerente Aprovacion de viaje desaprovar viaje Figura 25. Servicio aprobar viaje, realizado por el autor FIGURA 24 y 25. Desarrollado por el autor. 61

62 Análisis del proceso gestionar ausencias Identificar el proceso Actualmente la organización tiene muchos problemas para controlar las ausencias de RR-HH, ya sea por motivo de cursos, o posibles eventualidades de cada empleado, anteriormente la empresa ENCANA tenía un sistema para controlar dicho problema pero al desacoplarse de esta, la organización ha tenido que reportar estas ausencias, de manera manual utilizando Excel, a pesar de ser un proceso simple PROCESO: SITUACIÓN ACTUAL. DESCRIPCIÓN PROBLEMA GESTIONAR AUSENCIAS Gestionado en forma manual La empresa necesita tener un control de ausencias del personal para poder tomar acciones de prevención el momento que falte un recurso en algún área de la organización La organización no tiene un sistema automatizado para registro de ausencias. SERVICIOS Información del Empleado Este servicio permitirá obtener la información actualizada de la persona que la solicite. Aprobación de Solicitud Permite tramitar la aprobación o negación de la solicitud. Ingreso de Solicitud Permite tramitar una solicitud Autentificación de Usuario Seguridad de la información del usuario Figura 26. Proceso gestionar ausencias. FIGURA 26. Desarrollado por el autor. 62

63 PROCESO GESTIONAR AUSENCIAS FIGURA 27. Desarrollado por el autor. Figura 27. Proceso gestionar ausencias. 63

64 Casos de uso expuestos como servicios Actores Empleado.- todo el personal ligado laboralmente con la empresa. Gerente.- Supervisor capaz de aprobar la solicitud de viaje del empleado. Servicios Solicitar ausencia.- El empleado puede solicitar ausencia e ingresar la justificación para la aprobación de la misma. Ingresar Justificacion Imformar Ausencias Empleado Figura 28. Servicio Solicitar ausencia. Validar Usuario.- Da seguridad a la información del usuario exigiendo el ingreso de la clave del mismo. Información del Empleado.-Despliega información actualizada del empleado. Imformacion del Empleado Validar Usuario Empleado. Figura 29. Servicio Validar Usuario. Aprobar solicitud.- Permite que la solicitud del empleado sea analizada por su supervisor para aprobarla o no. Aprobar solicitud de ausencia Aprobar solicitud Gerente Denegar solictud de ausencia FIGURA 28, 29, 30. Desarrollado por el autor. Figura 30. Servicio Aprobar solicitud. 64

65 análisis de proceso revisar noticias de la organización (sistema COLIBRÍ) COLIBRÍ es una herramienta de escritorio presente en todas las maquinas de la organización que, permite al usuario mostrar las noticias de la organización, novedades, y demás, a pesar de su sencillez esto tiene mucha importancia para la organización ya que el difundir los cambios en las políticas, estándares, e informar a sus empleados es indispensable para la organización. PROCESO: SITUACIÓN ACTUAL. DESCRIPCIÓN PROBLEMA REVISAR NOTICIAS La empresa cuenta con una aplicación Colibrí que centraliza todas las noticias, acerca de la organización ej. Cursos, novedades tecnológicas, comunicados de gerencia etc. Cada computador tiene instalada la aplicaron colibrí la cual brinda la información requerida Al no ser una aplicación centralizada no está a la mano de la mayoría de empleados. Solo de los que tienen asignado una maquina de manera permanente SERVICIOS Información empresarial Desplegar información actual de la organización Figura 31. Proceso informe de noticias. FIGURA 31. Desarrollado por el autor. 65

66 PROCESO REVISAR NOTICIAS Figura 32. Proceso Revisión de noticias. FIGURA 32. Desarrollado por el autor. 66

67 Casos de uso expuestos como servicios Actores Empleado.- todo el personal ligado laboralmente con la empresa. Servicios Revisar Noticias.- permite al usuario revisar novedades de la organización Desplegar noticias Revisar Noticias Empleado. Figura 33. Proceso Revisión de noticias. FIGURA 33. Desarrollado por el autor. 67

68 Análisis proceso consultar beneficios del empleado (sistema HRPORTAL) La organización, brinda a sus empleados, un sinnúmero de beneficios, como son oportunidades de acenso, bonos, cursos, préstamos etc. La gestión de esta herramienta se realiza por el personal de RR-HH, a través de un Web service, que extrae información de una base de datos propia de RR-HH, la cual cuneta con la misma información de la BDD utilizada por el ERP. PROCESO: CONSULTAR BENEFICIOS SITUACIÓN ACTUAL. La organización ofrece un web service que le permite al empleado consultar a que beneficios puede acceder, ejemplo préstamos, vacaciones, bonos etc. Este servicio Web maneja una base DESCRIPCIÓN de datos aislada en SQL Server, la cual es actualizada por personal de RR-HH PROBLEMA Al ser una aplicación aislada, ocasiona el uso innecesario de recursos, provocando inconsistencias entre los diferentes repositorios de datos SERVICIOS Autentificación de Usuario Da seguridad al sistema y la información personal de cada empleado. Consultar Beneficios Permite estar enterado de los beneficios a los que el empleado puede acceder. Aprobación Aprobar solicitud de beneficio Listar beneficios Despliega los beneficios del empleado Figura 34. Proceso Consulta de Beneficios. FIGURA 34. Desarrollado por el autor. 68

69 PROCESO CONSULTAR BENEFICIOS DEL EMPLEADO Figura 35. Proceso Consulta de Beneficios. FIGURA 35. Desarrollado por el autor. 69

70 Casos de uso expuestos como servicios Actores Empleado.- todo el personal ligado laboralmente con la empresa.. Gerente.- Supervisor capaz de aprobar la solicitud de viaje del empleado. Servicios Validar Usuario.- Permite ingresar al sistema previo el ingreso de la clave de usuario Listar Beneficios.- Lista los beneficios que tiene el empleado desplegar beneficios del empleado Validar usuario Empleado. Figura 36. Servicios, validar usuario, Desplegar Beneficios Aprobar solicitud.- servicio que permite gestionar la aprobación de la solicitud de beneficio por parte del gerente Aprobar solicitud Gerente Aprobación de Solicitud Denegar solicitud Figura 37. Servicio Aprobar solicitud. FIGURA 36, 37. Desarrollado por el autor. 70

71 Consultar Beneficio.- permite consultar beneficios disponibles Ingresar Solicitud.- permite ingresar solicitud de beneficio seleccionado Seleccionar Beneficio Ingresar solicitud Empleado. Solo Consultar Figura 38. Servicio Consultar Beneficio. FIGURA 38. Desarrollado por el autor. 71

72 Análisis de proceso de aprobación (web service APORTAL) APORTAL es un Web Service, que permite dar aprobación por parte de las personas adecuadas a solicitudes, de compro o venta de suministros, sin embargo existe un sinnúmero de solicitudes que no pueden ser aprobadas por este medio de ahí la necesidad de integrar esta aplicación, para que interactué con otras aplicaciones para prestar un servicio eficiente de aprobación. PROCESO: APROBACIÓN SITUACIÓN ACTUAL. DESCRIPCIÓN PROBLEMA La organización tiene un portal que permite la aprobación de algunas solicitudes Para ciertas solicitudes como la adquisición de equipos el gerente a cargo revisa el portar APORTAL y revisa la solicitud Este portal no se conecta con todas las aplicaciones que están al servicio de los usuarios para el envió de solicitudes SERVICIOS Aprobación Revisión de solicitudes Permite aprobar o denegar, la solicitud de algún recurso o petición en general Permite revisar las solicitudes por parte del gerente Figura 39. Proceso de aprobación. FIGURA 39. Desarrollado por el autor. 72

73 PROCESO DE APROBACIÓN Figura 40. Proceso de aprobación. FIGURA 40. Desarrollado por el autor. 73

74 Casos de uso expuestos como servicios Actores. Gerente.- Supervisor capaz de aprobar la solicitud de viaje del empleado. Servicios Revisar solicitud.- permite revisar la solicitud por parte del gerente Gerente Revisar solicitud Figura 41. Servicio Revisar solicitud Aprobar solicitud.- permite aprobar o denegar la solicitud por parte del gerente Aprobar solicitud Gerente Aprobación de Solicitud Denegar solicitud Figura 42. Servicios, Aprobar solicitud. FIGURA. 41 y 42. Desarrollado por el autor. 74

75 Análisis de proceso de consulta de datos a la base de datos EVERYONE del ERP. La organización al darse cuenta, que estaba creando repositorios de datos aisladamente para cada aplicación y que estos repositorios tenían información que se encuentra en la base de datos del ERP, decidió, crear un Web Service que permita extraer esta información para abastecer a las aplicaciones eliminando la información redundante, sin duda este es un gran avance para poder implementar SOA con un ESB. PROCESO: CONSULTA A EVERYONE SITUACIÓN ACTUAL. DESCRIPCIÓN PROBLEMA EVERYONE es un Web Service, que permite interactuar con la base de datos de JD Edwards (ERP). EVERYONE es una tabla del ERP de la organización que contiene centralizada gran cantidad de información. Se encuentra en una etapa de Testing. No está en producción. SERVICIOS Servicio de Consulta a BDD Datos Finanzas Datos RR-HH Se puede consultar a la BDD del ERP Datos Financieros Datos RR-HH Figura 43. Proceso de Consulta BDD. FIGURA 43. Desarrollado por el autor. 75

76 PROCESO DE CONSULTA DE DATOS Figura 44. Proceso de Consulta BDD. FIGURA 44. Desarrollado por el autor. 76

77 Casos de uso expuestos como servicios Casos de uso expuestos como servicios Actores Empleado.- todo el personal ligado laboralmente con la empresa.. Gerente.- Supervisor capaz de aprobar la solicitud de viaje del empleado. Servicios Consulta de datos.- permite acceder a los datos del repositorio del ERP especialmente a los datos de RR-HH y Finanzas Solicitar datos de RR-HH Empleado Consultar Datos Solicitar datos de finanzas Gerente Figura 45 Servicios, Consultar Datos FIGURA 45. Desarrollado por el autor. 77

78 Cuadro de servicios identificados después del análisis Se ha presentado este cuadro(ver figura 46) como una matriz que muestra la participación de los servicios identificados dentro de las aplicaciones y sus procesos, que serán integrados en la siguiente fase del diseño dentro del Enterprise service bus Para la mejor comprensión del cuadro se propone los siguientes ejemplos. En la parte derecha de la grafica (Figura 39) podemos observar que el servicio validación de usuario, está involucrado en todas las aplicaciones, por lo que este puede definirse una sola vez en el ESB y de esta forma alimentar las necesidades de todas las aplicaciones. De esta manera podremos en la parte siguiente del diseño proponer un diseño de servicios eficiente. APLICACIÓN PROCESO SERVICIOS Ingresar solicitud Consulta de datos Información del Empleado Revisar solicitud Aprobar Revisar noticias Solicitar Ausencias Lista de Beneficios Consultar Beneficios Solicitar Viaje Validación de Usuario x x APTRAVEL Gestionar viajes x x x x AUSENCIAS COLIBRÍ HRPORTAL Gestionar ausencias Informar noticias de la organización Consultar beneficios del empleado x x x x x x x x x x x x x x APORTAL EVERYONE Aprobar solicitud Consultar datos JDEdwards x x x x x x Figura 46. Cuadro de servicios obtenidos. FIGURA 46. Desarrollado por el autor. 78

79 ENSAMBLAJE 2.3.-Diseño lógico del bus de servicios corporativos Un Bus de Servicios Corporativos es una solución de integración distribuida basada en estándares abiertos, que permite la comunicación de diferentes recursos de IT como son aplicaciones, plataformas y servicios. Que se encuentran repartidos en toda la organización. Un buen diseño del ESB permite fortalecer los cimientos para establecer una Arquitectura orientada a servicios con éxito. Evolución del ESB. El concepto de ESB nace con la necesidad de resolver el problema de la escalabilidad exponencial de las conexiones punto a punto entre aplicaciones (Ver figura 28. Problema de conexiones M * N). Al momento que se conectan nuevas aplicaciones entre sí. CONEXIÓN PUNTO A PUNTO S1 S2 S3 S1 S2 S3 Nuevas conexiones S4 S5 S6 S4 S5 S6 Figura 47. Problema de conexiones M * N FIGURA 47. Desarrollado por el autor. 79

80 De este problema se da la idea de una estructura centralizada que permita gestionar las conexiones entre aplicaciones, esta estructura es EAI (Enterprise application Integration). APLICACIONES ESTRUCTURA CENTRALIZADA FIGURA 48. EAI. De este punto el EAI evoluciona al ESB a través del manejo de servicios a través de una troncal centralizada llamada BUS. Service Requester Service Requester Service Requester ESB Service Provider Service Provider Service Provider FIGURA 49. Evolución EAI. FIGURA. 48 y 49. Desarrollado por el autor. 80

81 Requerimientos de la organización para el Enterprise service bus Un buen diseño de un ESB provee un sin número de ventajas al negocio, y coloca las bases para poder complementar una arquitectura orientada a servicios: Proveer un vehículo único de integración entre las plataformas cliente (canales), y las plataformas servidoras (back-end), que independice a cada una de ellas de las características de las otras. Es decir, independencia de sistemas operativos, protocolos de comunicaciones, topologías de redes, lenguajes de programación, y organizaciones de datos. Implementación simple, con componentes fáciles de construir y mantener. Minimización de los tiempos de desarrollo de nuevos servicios. Reducir al mínimo posible las modificaciones, tanto a las aplicaciones clientes como servidoras, a través del uso de conectores, que adapten las peculiaridades de cada plataforma a un estándar definido por el Framework ESB. Proveer un adecuado Nivel de Servicio, en términos de tiempos de respuesta, disponibilidad de servicios, oportunidad en el acceso a la información, y protección de la integridad de la misma. En una implementación de ESB se identifican 3 componentes: Componente de requerimiento, que es quien solicita un servicio. Componente de ESB, que es la que pública y negocia el requerimiento. Componente proveedora, que es quien resuelve el requerimiento inicial. En resumen, ESB es la infraestructura de servicios de las soluciones basadas en una Arquitectura Orientadas a Servicios. 81

82 Diseño de los componentes del ESB Para el diseño del ESB se debe identificar los siguientes componentes: Capas aplicativas Conectores CAPAS APLICATIVAS Este componente está formado por tres capas (ver figura 31) que son: Capa de presentación.- o también llamada de front-end, se define como la capa que provee al usuario la interfaz para interactuar con el bus. Capa de integración.- en esta capa se realiza la integración de las aplicaciones, así como expone los servicios. Que la capa de aplicación puede consumir. Capa de Servicios de Datos o Back-end.- es la capa de proveer los datos requeridos por la capa de integración para dar solución a las peticiones del front-end. Front End (Presentación) Service Requester Service Requester Service Requester Capa de Intermediación (Middleware) ESB Service Provider Service Provider Service Provider Back End (Servicio de Datos) Figura 50. Capas Aplicativas. FIGURA 50. Desarrollado por el autor. 82

83 CAPA DE PRESENTACIÓN FIGURA 51. Desarrollado por el autor. Figura 51. Capas de presentación. 83

84 Funcionalidad de la capa de presentación. Las aplicaciones analizadas anteriormente, prestaran las interfaces necesarias para interactuar con el bus mas no tendrán funcionalidad individual toda su funcionalidad será migrada dentro de la funcionalidad del bus convirtiendo al aplicativo en una puerta de acceso a requerimientos al bus, función primordial de la capa de presentación (ver figura 51). COMPONENTES.- funciones o métodos de la aplicación APLICACIÓN La funcionalidad de la aplicación es trasladada al bus y replanteada para ser reutilizada por otros servicios ESB Figura 52. Capas de presentación. Los componentes reusables de las aplicaciones que se conectan al bus, son organizados, por el bus para solucionar posibles requerimientos de servicios que para su cumplimiento necesiten la funcionalidad del componente donado por la aplicación y donado por el bus. FIGURA 52. Desarrollado por el autor 84

85 CAPA DE INTEGRACIÓN DISEÑO CAPA DE INTEGRACIÓN FIGURA 53. Capa intermedia Desarrollado por el autor. Message Oriented Middleware SERVICIOS ATÓMICOS FIGURA 54. Desarrollado por el autor FIGURA 53. Capa de integración. SERVICIOS COMPUESTOS 85

86 Funcionalidad de la capa de integración El diseño de la capa de integración se basa en la definición de los servicios de forma independiente a la plataforma, con el objetivo que dichos servicios puedan interactuar entre sí. Envió de petición FIGURA de 35. servicios - Gestión de petición de servicio requerido - Control de Seguridad - Ruteo Dinámico. - Llamada al servicio - Llamada al servidor de datos correspondiente - Devolver respuesta al cliente- Envió de datos solicitados FIGURA 54. Capa intermedia En el diseño podemos observar dos tipos de servicios Servicios atómicos.- (ver figura 53) Son los servicios indivisibles que cumplen una función específica y permiten cuando se agrupan crear servicios más complejos Servicios Compuestos.- (ver figura 53 Es el conjunto de servicios atómicos que se reúnen e interactúan para dar solución a un servicio en especial. Para la implementación de El ESB se recomienda utilizar JDeveloper de ORACLE, este software ya tiene definido los requerimientos funcionales que necesita la organización, al igual que los conectores. También hay que tener en cuenta que JDEdwards es un ERP desarrollado por Oracle, lo que garantiza la correcta integración de las aplicaciones Legadas a la estructura del ESB. FIGURA 54. Desarrollado por el autor 86

87 CAPA DE SERVICIOS DE DATOS FIGURA 55. Desarrollado por el autor. FIGURA 55. Capa de servicios de datos. 87

88 Funcionalidad de la capa de servicios de datos Esta capa es la encargada de responder a la petición de información de la capa de integración. El diseño de la figura 35. Se basa en las fuentes de datos que alimentan las aplicaciones descritas en el análisis de aplicaciones realizado anteriormente. La base de datos del ERP es fundamental, en la conexión ya que la tabla EVERYONE, maneja información que necesita la mayoría de los servicios que gestiona el BUS recuerdo al análisis de servicios realizados anteriormente. Sin embargo se muestra también en el diseño la apertura a fuentes de datos alternas ya que se podría necesitar datos de repositorios aislados que manejan las aplicaciones que se quiere integrar. A pesar que esta información se encuentre en la tabla EVERYONE. Al utilizar la base de datos del ERP podremos eliminar la redundancia de información que se manceba con base de datos aisladas, las cuales tenían la misma información que puede ser proporcionada por la tabla EVERYONE. Esta capa es también recomendable utilizar JDeveloper para implementarla los conectores necesarios para su acoplamiento a la estructura del bus son proporcionados por la herramienta. 88

89 CONECTORES Cuando ya se ha definido y diseñado las tres capas del ESB, aparece un muevo componente de la arquitectura los CONECTORES que son piezas de software encargadas de interconectar el FRONT-END con el bus y el BACK- END con el bus. Los conectores o adaptadores se pueden clasificar según el rol que cumplen en dos tipos: Conectores clientes y conectores servidores. Los conectores clientes.- son aquellos invocados por las aplicaciones de front-end para enviar requerimientos al ESB (ver figura 36). Los conectores servidores.- son aquellos que el ESB invoca para solicitar requerimientos al back-end. (Ver figura 36). Funcionamiento de los Conectores Cliente La función de los adoptadores o conectores se base en mensajes orientados al middleware (MOM) el cual es un tipo de Middleware que permite interconectar aplicaciones a través de mensajes, MOM es una clase específica de software, específicamente,, que opera en los principios de gestión de colas de mensajes o mensajería y es un método popular de la integración y de conexión de aplicaciones de negocio actuales y sistemas heredados en entornos heterogéneos. Flujo de ejecución del conector cliente El usuario ingresa al aplicativo que se encuentra en su forma nativa con el objeto de solicitar un servicio. 2 Al generar un requerimiento hacia el bus este lo hace sobre un mensaje en el formato que maneja la aplicación nativa El conector toma el mensaje del aplicativo y lo transforma en un mensaje MOM 4 La petición es resuelta en el ESB El conector recibe la respuesta del ESB y este lo envía a la aplicación en el formato de mensajes propio de la aplicación nativa La aplicación de negocio recibe el mensaje. 89

90 FIGURA 56. Desarrollado por el autor. FIGURA 56. Conectores. 90

91 Los conectores deben cumplir con la siguiente funcionalidad de SOA: Manejo dinámico de servicios, objetos, entorno, todo lo anterior basado en parámetros de ejecución y en archivos o variables de configuración. Operar en forma sincrónica asegurando la integridad transaccional, al utilizar los mecanismos de identificación propios de Mensaje ID. Generar registro de operación y transacciones. Las facilidades de registro de la operación permite configurar el nivel de detalle que se requiere, dependiendo del tipo de operación en que se está usando el conector (Desarrollo o Producción). Genera un mensaje de alerta al ESB/SOA cuando no puede acceder a los objetos o aplicaciones de Back End. Genera un mensaje de alerta en un archivo de LOG cuando no puede acceder a los objetos o aplicaciones de Back End o cuando detecta una excepción. Generación de Ping de monitoreo para la verificación de disponibilidad del conector y de los aplicativos que sirve para poder chequear la disponibilidad de la solución y sus componentes. Reusabilidad, los conectores no deben contener lógica de negocio asociada, con el objeto de poder ser ejecutados y utilizados en plataforma iguales en el resto de la instalación. Desacoplamiento, los conectores deben desacoplar a las funciones de negocio del cliente de la complejidad del manejo de comunicaciones o coordinación de comunicaciones o adecuación de tramas o datos. Encapsulamiento. los conectores deben encapsular los formatos de datos de las aplicaciones o funciones de negocio a formatos de mensajes o transacciones de SOA sin impactar los formatos o estructuras de datos de las aplicaciones o funciones de negocio del cliente. Request & Reply. Los conectores o Business Adapters deben mantener la integridad transaccional, por lo que todas las transacciones esperarán una respuesta con este modelo de integración. NOTA.- Jdeveloper posee conectores que prestan todos los requisitos de funcionalidad para los conectores descritos anteriormente. 91

92 CONECTOR SERVIDOR Los conectores servidores (Ver figura 57) proveen de un método variable que permite enviar requerimientos desde SOA a las aplicaciones o funciones de negocio en la capa de presentación y esperar por su respuesta desde el aplicativo. La aplicación debe permitir o estar preparada para ser ejecutada como una transacción desde sistemas externos, es decir, debe permitir su ejecución con base a parámetros y cada conector servidor o Business Adapters debe adecuarse a las peculiaridades de cada aplicación, aunque es recomendable estandarizar las aplicaciones ESB/SOA 1.- SOA solicita la ejecución en el ESB de una aplicación que es la representación atómica de un servicio. 8.- El conector responde a SOA en el formato MWAS para identificar el servicio ejecutado. 2.- Extrae del formato MWAS, la data para la aplicación 7.- El conector toma la data y la convierte en un mensaje MOM 3.- Identifica el aplicativo a ejecutar. Conector Servidor 6.- Entrega respuesta de la aplicación al conector servidor Parámetros LOG 4.- El aplicativo recibe los parámetros en forma nativa y ejecuta la f(x) de negocios 5.- El aplicativo responde en forma nativa a la ejecución de la f(x) de negocio FIGURA 57. Desarrollado por el autor Figura 57. Flujo de conector de servicios. 92

93 Servicio, Corresponde al nombre de Servicio asociado a la transacción, es un carácter de largo 48 como máximo. Esta referencia se usa como input para asignar en forma dinámica las colas de MQ a utilizar en la transacción e identificar en SOA el servicio o aplicación a ejecutar. En este punto se usan las características de MQ para la asociación de trigger de procesos a colas de mensajería. Esta relación permite ejecutar una aplicación específica en forma dinámica. BufferIn, corresponde a los datos que serán enviados a la aplicación, es decir, corresponde al requerimiento. Este campo es de entrada de largo variable y se forma de la data del aplicativo que está solicitando la ejecución. BufferOut, corresponde a los datos que son devueltos desde el aplicativo a SOA según el requerimiento. Este campo es de salida de largo variable y es recibido en el formato y estructura que el aplicativo responde. TimeOut, corresponde al tiempo máximo que esperará el Conector por una respuesta desde el aplicativo a SOA, este tiempo está asociado comúnmente al tipo de Servicio. Una vez que se cumpla el TimeOut y no haya llegado respuesta, el conector entregará un código de error y tomará el control. Eventualmente, por alguna contención o demora el mensaje de respuesta puede llegar más tarde, pero no habrá una aplicación esperando por esa transacción. Este campo es de entrada de tipo numeral. RetCode, corresponde al código de retorno generado por el conector, de ser 0 implica que la transacción termino con éxito, cualquier valor distinto de 0, debe ser analizado por el aplicativo y tomar la acción de negocios correspondiente. Este campo es de salida y de largo 6. GlosaCode, corresponde a la descripción del código de error reportado, en caso que existan descripciones disponibles. Este campo es de salida y de largo 255. MsgID, corresponde a la clave en hexadecimal que le asigna MQ a cada transacción y puede ser utilizada para seguimiento o análisis de errores. Este campo es de salida de largo 48. En este caso es la clave que tiene asociada la ejecución del servicio. Los conectores o Business Adapters pueden terminar en forma exitosa o anómala, esto lo podrá determinar el servicio o aplicación que ha invocado al Conector verificando el código de retorno del método invocado. En caso de que el código de retorno sea 0 (cero), se considera una ejecución exitosa, por lo que el código conector traerá consigo la información que ha retornado desde el aplicativo hacia SOA. En caso de que el código de retorno sea distinto de cero, corresponderá a una ejecución fallida a nivel de arquitectura, por lo que se retornará un código de error que debe evaluar el servicio o la aplicación. El servicio o aplicativo debe evaluar los códigos de error que genere la transacción de respuesta que están embebidos en la data. 93

94 VISTA DEL DISEÑO LÓGICO DEL ESB PARA LA ORGANIZACIÓN MIDDLEWARE ORIENTADO A MENSAJES Servicios Web FIGURA 58. Desarrollado por el autor. Figura 58. Vista de propuesta de diseño integrada. 94

95 Revisión y aprobación por parte de miembros del equipo de IT En el proceso de Evaluación y diseño de la madurez de SOA en la organización a la vez como el diseño del bus de servicios corporativos respectivamente. Se recibió la inspección revisión y aprobación de los siguientes miembros de IT de la organización. Que están detallados en el siguiente cuadro: Nombre del Miembro de IT Iván Pazmiño Álvaro Andrade Juan Del Castillo Cargo ROL Parte del Desarrollo del documento IT Manager Supervisor IT Client Services Analista de IT Revisión y aprobación Revisión, Asesoramiento, Consulta periódica durante todo el desarrollo Asesoramiento y consulta para el diseño de ESB Documento Final Todo el periodo de desarrollo Modelado y Ensamblaje Estado APROBADO REVISADO REVISADO 95

96 2.4.- COMO LA IMPLEMENTACIÓN DE LA ARQUITECTURA MEJORARÍA LA GESTIÓN DE SERVICIOS EN LA ORGANIZACIÓN Descripción de ventajas al implementar el enterprise service bus en la organización Integración Empresarial Usuarios y canales de atención Servicios de aplicación Integración Empresarial Si bien ANDESPETRO en la actualidad cuenta con mecanismos de comunicación con diferentes aplicaciones, esta infraestructura opera de una manera integrada parcialmente. El contar con una infraestructura de integración empresarial completa permite: Reducir el costo de migración a un nuevo ERPs. Permitir integrar a los sistemas del campo para que den información en tiempo real a los sistemas de información sin la necesidad de la intervención del ser humano. Monitorear puntos de falla claves en procesos del negocio. Eliminar los repositorios de datos redundantes. Mejorar la calidad de los servicios Los beneficios para el negocio de esta iniciativa serían: Permitir que ANDESPETRO la flexibilidad a los distintos cambios que enfrenta la organización SOA es un habilitador que permite que una organización reaccione sobre la demanda para responder a cambios en las condiciones de los procesos de negocio; esto sin duda tiene como consecuencia una tremenda ventaja competitiva en el mercado. Eliminar procesos manuales, permitiendo la consistencia de información entre aplicaciones y administrando la intervención humana para reducir errores. 96

97 Un mejor desempeño, administración de cambios, manejo de excepciones, seguridad y monitoreo, y; podría soportar los planes agresivos de crecimiento Usuarios y canales de atención El portal permitirá a los funcionarios el acceder a las funciones de aplicación a través de varios canales. Estos incluyen: A través de una Intranet mediante un computador personal equipado con un Browser Internet. Desde una aplicación de la empresa utilizando protocolos de comunicación establecido. Adicionalmente los usuarios de todas las locaciones podrán acceder a las diferentes funciones de aplicación mediante sus estaciones de trabajo o computadores portátiles equipados con un Browser Web. El acceso a estos servicios de aplicación será vía cliente Internet Servicios de aplicación Cada canal proveerá al usuario con una interface de usuario diferente que accede y presenta la misma información y funciones de negocio almacenadas en el ESB. Sin embargo se podría limitar la funcionalidad de acuerdo a consideraciones de utilización, limitaciones tecnológicas y consideraciones de seguridad. La aplicación debería soportar por lo menos los siguientes tipos de función de negocio. Estos son: Función de Autenticación y Autorización. Función de registros. Función Aprobación. Función de Beneficios. Función de Consulta datos personales. Función de Reportes. Función de Noticias.. Las funciones de Autenticación y Autorización permiten al usuario: Ingresar a la aplicación usando su identificación de usuario y clave y por lo tanto autenticarse. Una vez autentificado, se recaba las autorizaciones o capacidades propias del usuario y son asociadas a este. Típicamente estas incluyen 97

98 la relación de funciones que el usuario puede realizar, que información puede acceder el usuario, etc. La función de Registro provee al usuario con: La habilidad de administrar el directorio de usuarios, añadiendo nuevos usuarios o modificando la información de perfil de usuarios a ser usada luego por las funciones de autorización. La función Aprobación provee al usuario con las funciones de: Acceso, a solicitudes de beneficios así como solicitud de autorizaciones La función de Beneficios provee a los usuarios con: La función de beneficios: La habilidad de escoger y gestionar beneficios, empresariales La función de Consulta datos personales Visualización de documentos correspondientes a trámites presentados por su aprobación La función reportes: Reportes de datos solicitados por el usuario (beneficios, datos personales, solicitudes aprobadas, etc.) La función de NOTICIAS: La habilidad de estar al tanto de las novedades de la compañía, como por ejemplo cambio en las políticas situaciones de precaución, oportunidades para los empleados. 98

99 2.5.- MEJORA CONTINUA DE SOA EN LA ORGANIZACIÓN Una vez que la arquitectura sea implementada es necesario para su administracion pulir la arquitectura continuamente, hay que dejar muy en claro que el proceso de implementacion exitosa de una arquitectura de integracion, depende de desarrollar estrategias que permitan mejorar el rendimiento de dicha arquitectura para lo cual el el caso de la organizacion, y usando como punto de partida el nivel de madurez que tiene en SOA podemos exponer algunas clases de mejoras que pueden soportar la implementacion y administracion de la SOA. Crear un centro de competencias de integración de aplicaciones. Desarrollar un mapa de integración para su empresa. Documentar las interfaces de aplicación. Inicio pequeño y crecer progresivamnete. Valor para el Negocio dado por la Integración. 99

100 Crear un centro de competencias de integración de aplicaciones Es clave para ser exitosos en la integración de aplicaciones. Un equipo permanente de gente especializada debe estar a cargo de especificar, diseñar, adquirir, implementar, administrar y mantener, la infraestructura empresarial de integración. La integración de aplicaciones no es solamente una técnica compleja, es también un esfuerzo que nunca termina. Un centro de competencia puede desarrollar las habilidades técnicas y de aplicación preexistentes con los nuevos conocimientos. Se debe definir una política coherente de integración para que los proyectos se realicen frecuentemente. El centro de competencias debe abastecerse de unidades de negocio, de subsidiarios y de entidades externas (por ejemplo los proveedores y socios) un sistema coherente de servicios - tales como servicios de consultoría o la administración de un repositorio de interfaces - dirigidos a facilitar la puesta en práctica de los escenarios de integración que se necesitan. Es de anotar que el centro de competencias está a cargo de grupos de desarrollo proactivos que ayudan una manera práctica, no se limita solamente a definir estándares o fijar reglas. Se puede implementar con éxito y aprovechar completamente solamente si las unidades de negocio son concientes de las ventajas de usarlo Desarrollar un mapa de integración para su empresa El desarrollo de una infraestructura de integración empresarial no puede ser improvisado, este requiere de un diseño cuidadoso con un buen entendimiento de los objetivos específicos e indicadores de negocio explícitos, tanto técnicos como organizacionales. La fase de diseño de la infraestructura de integración empresarial se debe dirigir definiendo un modelo conceptual el tour de integración empresarial para la infraestructura misma. Este debe incluir: La infraestructura de integración empresarial o arquitectura de información, especificando los modelos de comunicación (almacenar y reenviar, publicar y suscribir o solicitar/contestar), esquema para los mensajes estandarizados, el volumen y la frecuencia del intercambio de mensajes, lógica de datos/flujo de mensajes, reglas de transformación y los esquemas lógicos para archivos, mensajes y documentos. La arquitectura de información debe también considerar la administración del sistema de la infraestructura de integración empresarial por sí misma. Es más barato y fácil planear la administración de la infraestructura que adaptar la misma cuando la integración ya exista. 100

101 Un sistema de reglas de gobierno es tener la definición formal de relaciones entre el centro de competencia, los grupos de aplicaciones en el cliente y los grupos operacionales del proveedor. Las reglas deben ser establecidas para negociar los acuerdos de nivel de servicio en la operación de la infraestructura de integración empresarial (ej., el rendimiento previsto). La lista aprobada de estándares de infraestructura, por ejemplo el middleware de integración y la administración, seguridad y herramientas de monitoreo Documentar las interfaces de aplicación El centro de competencias de integración de aplicaciones debe en cierto plazo construir un repositorio para almacenar las interfaces (ej., interfaces de programación de aplicaciones, formatos de archivos y formatos de pantalla) las aplicaciones empresariales deben estar disponibles para habilitar el intercambio de datos y mensajes. Fácilmente en una empresa pueden existir interfaces de aplicaciones con muchísimos usos, y hacerle el seguimiento a estas interfaces no es fácil para nada. Encontrar, desarrollar y entender las interfaces de aplicación es usualmente una de las áreas más difíciles en los proyectos de integración. Reusar las interfaces preexistentes es uno de los principales beneficios que se debe administrar y organizar en la integración y un repositorio de interfaces bien documentado es invaluable para habilitar el reuso de las mismas. Construir un repositorio de interfaces (o un modelo para la empresa) es una tarea larga que se debe realizar metódicamente para sentar las bases del proyecto. Necesita un esfuerzo sistemático que permita estar actualizado y más si los sistemas involucrados están en permanente cambio Inicio pequeño y crecer progresivamente Implementar una infraestructura de integración para toda la empresa desde cero es complejo, costoso y riesgoso. Requiere mucha inversión, el compromiso empresarial, una fuerte administración de proyectos y por supuesto, tiempo. Aunque no muchas empresas han completado este proceso, se ha probado que es muy complejo y riesgoso para muchas organizaciones, si este es el caso, sugerimos que las empresas adopten una aproximación puntual: 101

102 Implementar una infraestructura de integración que soporte efectivamente los dos o tres proyectos de integración más urgentes. Típicamente son proyectos que quieren establecer consistencia de datos entre aplicaciones. Reforsar la infraestructura en otros escenarios, adicionando nuevas capacidades cuando sea posible. Por ejemplo, puede adicionar la administración de los procesos de negocio en un proyecto parcial de integración de procesos. Esta aproximación es menos riesgosa, la introducción de nueva tecnología es de menos impacto, así no se obliga a la empresa a hacer un compromiso con determinado producto y hace más fácil la justificación de inversión en la tecnología de integración Valor para el Negocio dado por la Integración La integración entrega valor al negocio porque provee: Gran Retorno de Inversión (ROI) Funcionalidad que no puede ser entregada usando otras alternativas Mejora la línea de negocio al incrementar la agilidad y sensibilidad de la empresa. Alto retorno de inversión para la organización de IT Uno de los mayores desafíos está asociado con justificar el costo de las soluciones de software de integración, esto es porque muy pocas organizaciones saben los costos actuales de integración. Esos costos típicamente se pierden en costos de los diferentes proyectos o en el presupuesto de mantenimiento y no es sencillo seguirles la pista y aun más darle un número. Sin embargo, Gartner y otros han indicado que los costos de integración están alrededor del 40% del presupuesto anual de IT en una organización. Esto significa que para una compañía que gasta casi el 5% de la ganancia total en el área de Tecnología, los costos de integración podrían representar casi el 2% de las ganancias totales de una organización. Más allá de esto, la evidencia sugiere que los métodos tradicionales de integración son los mayores inhibidores para alcanzar ventajas para el negocio asociadas con un mayor número de iniciativas del área Tecnología. Muchos proyectos que exceden el presupuesto o que no cumplen los cronogramas son el resultado de costos no esperados y labores asociadas con las actividades de integración, que generalmente se estiman de menor esfuerzo al que realmente requieren. Muchos proyectos de integración a gran escala no cumplen con 102

103 todas las expectativas planteadas porque se vieron impactados por todas las labores que no planearon y tuvieron que realizar para la integración entre las aplicaciones y los sistemas El desarrollo más efectivo es otra ventaja, porque la integración no solamente acelera los beneficios del negocio asociados a las iniciativas de IT, también reduce el costo total de mantener la tecnología impactando directamente el margen. Un reporte de Gartner documenta el promedio de horas invertidas en diseñar, construir y probar integraciones utilizando métodos punto a punto y reporta un promedio de mejora en horas laborales que un broker de integración provee. Con la revisión de más de 20 proyectos grandes de integración, IBM ha encontrado estadísticas similares a las provistas por Gartner, y va unos pasos más allá documentando los ahorros adicionales en horas laborales. Definiciones de fácil, media y compleja: Interfaces fáciles: estructura de mensaje plana, menos de 50 campos, utilizados para integrar un par de aplicaciones. Interfaces de complejidad mediana: más de 50 campos o la transformación de datos que se deben mover de un formato jerárquico a otro formato jerárquico, usado para integrar un par de aplicaciones Interfaces complejas: más de 50 campos, envueltos en la transformación de datos que se deben mover desde un formato jerárquico a otro formato jerárquico, utilizado para integrar múltiples aplicaciones (cercano a una orquestación de procesos). Gartner y otros han hecho un caso para los dramáticos ahorros en costos y las reducción de horas laborales que el negocio alcanza cuando se implementa la integración de aplicaciones utilizando las herramientas de desarrollo y las metodologías, el contenido preconstruido y las ventajas arquitectónicas de tener una solución estructurada con un broker de integración. El uso de un servidor de integración de negocios reduce significativamente las horas laborales requeridas para diseñar, construir, y probar las conexiones entre diferentas aplicaciones, los cuales generalmente se desarrollan en diferentes momentos del tiempo, con tecnologías diferentes, residiendo en diferentes equipos o aún en diferentes empresas, y tienen variedad de representaciones de datos que necesitan ser compartidas. Una arquitectura basada en un servidor de integración habilita un alto grado de reuso vía la arquitectura de Hub de integración y el Modelo Común de Objetos de negocio. Esta arquitectura altamente modular separa las aplicaciones en capas, lo que mejora la habilidad de construir o habilitar lógica preconstruida de integración, permitiendo aislar el impacto del cambio. Estas soluciones reducen el trabajo requerido para aumentar las necesidades de integración (cuando las aplicaciones conectadas se crecen por nuevos 103

104 releases, nuevas versiones, etc.) por mucho a un 75%. Adicionalmente, las herramientas de administración e interfaz gráfica permiten que esta solución tenga un corto tiempo para mantener y habilitar el portafolio de integraciones a la mitad, lo que reduce el tiempo total de crecimiento en más de un 50%. Nota: Los servidores de integración reducen el tiempo de implementación y mantenimiento desde el diseño, construcción, implementación; mostrando excelentes resultados. Funcionalidad única Es importante ver más allá de las capacidades de integración, este tipo de servidores también entregan funcionalidad que de otra manera no se podría tener, adicionalmente es arduo y costoso comenzar desde ceros. Es difícil definir el beneficio o el ahorro económico, pero su funcionalidad incrementa dramáticamente el uso de las aplicaciones y la interacción en un ambiente complejo. Como: Secuencia de eventos: Se tiene una capacidad robusta para asegurar el procesamiento de inicio a fin de las actualizaciones dentro de un determinado orden o secuencia. Asegura la entrega y el procesamiento de actualizaciones entre múltiples aplicaciones y, mantiene el orden de los eventos que se disparan mediante un commit de transacción. Esta capacidad resuelve los problemas de pérdida de datos y en procesamientos multi tarea. Compensación de transacciones: Esta es una función de deshacer que devuelve el efecto de une transacción fallida mientras permite que otras actualizaciones continúen. Esta función provee una capacidad más rica que solamente reestablecer el estatus antes que fallara la transacción, lo que podría rechazar la mayoría de las transacciones subsiguientes. Aislar el evento: Se asegura que las múltiples instancias del evento no sean procesadas simultáneamente por diversos casos de colaboración. Esto permite que el servidor proporcione el aislamiento transaccional, entregando el máximo rendimiento de procesamiento. Adaptadores y transacciones manejados por eventos: Los adaptadores tienen la capacidad de detectar los eventos que se deben compartir con múltiples aplicaciones como cambios de dirección de un cliente. Los agentes de descubrimiento detectan un evento, lo comparten con el ICS para actualizar las aplicaciones y archivos que lo requieran. Esta capacidad permite dos versiones de la misma aplicación para coexistir durante una migración, reduciendo el riesgo y esfuerzo requerido para actualizar una nueva aplicación. 104

105 CAPITULO III CONCLUSIONES Y RECOMENDACIONES 105

106 3.1 CONCLUSIONES La organización se encuentra en un nivel inicial en el proceso de implementar SOA sin embargo tiene muy claro el porque involucrarse con SOA también ha adquirido el software necesario para su implementación, y sobre todo se están desarrollando grandes esfuerzos para difundir esta arquitectura entorno a la organización como por ejemplo en el desarrollo de este documento pude darme cuenta que gran parte del equipo de IT está muy comprometido con el desarrollo de la propuesta SOA Las arquitecturas de software están orientadas a satisfacer las necesidades de operación de los negocios, considerar su crecimiento y cubrir la totalidad de los procesos de negocio, de apoyo y administrativos de una institución. La implementación de una arquitectura en cualquier organización depende de cómo la arquitectura mejore las necesidades del negocio. Una Arquitectura SOA es una muy buena opción para la organización debido a que el medio donde se desenvuelve siempre esta propenso a cambios bruscos que obligan a la empresa en especial al departamento de IT a resolver requerimientos de una manera ágil y con el menor costo. La tendencia actual de la tecnología se orienta hacia resolver los sistemas informáticos utilizando arquitecturas distribuidas en Internet, Extranet, o Intranet basados en servicios que en los ambientes empresariales se denomina SOA y es lo que se ha sugerido en este documento con la implementación de un enterprise service bus. 106

107 3.2 RECOMENDACIONES Para realizar el análisis de servicios en la organización se recomienda hacerlo a través del análisis de procesos TOP DOWN, el cual ha sido utilizado para el desarrollo de este documento. También es recomendable que se realicen mediciones de la madures de SOA en la organización de manera continua para poder observar la evolución del proyecto de implementación. Para la implementación del Enterprise service bus. Se recomienda utilizar ORACLE JDEVELOPER herramienta que permite construir un bus de datos corporativos ya que tiene conectores predefinidos y cumple con los requerimientos de conectividad de la organización. Tanto para el ERP, como para las aplicaciones a integrar. Cabe señalar que personal del departamento de IT ya han trabajado con JDEVELOPER en pruebas de testing, lo que permitiría facilitar el trabajo de implementación. Formar un área que está encargada de monitorear el proceso de implementación de SOA en la organización, y que también pueda administrar la arquitectura después de la misma. Establecer políticas que permitan establecer una gobernanza correcta de la arquitectura a implementar en la organización, para lo que es necesario promover los conceptos de SOA atreves de todos los stakeholders de la organización. 107

108 3.3.- Glosario de términos SERVICIO Un Servicio es un recurso de software que se puede ubicar y que encapsula funcionalidad de negocio como por ejemplo, consulta de crédito, consulta datos de cliente, activación de línea, etc., el objetivo del encapsulamiento es separar la implementación de la funcionalidad del consumo del servicio, de esa forma el cliente del servicio no conoce la implementación, se puede cambiar la implementación pero el uso sigue sin alteración, el reto en la definición de los servicios es su granularidad y la forma de definición. Los servicios deben ser entregados al nivel de granularidad y abstracción con el cual le brinde mayor significado y valor agregado a quien solicita el servicio. Granularidad. Los servicios deben ser entregados al nivel de granularidad y abstracción con el cual le brinde mayor significado y valor agregado a quien solicita el servicio. En varias descripciones de SOA aconsejan el uso de servicios con una granularidad gruesa, sin embargo existen un sin número de ejemplos o casos exitosos haciendo uso de servicios reutilizables definidos con una granularidad fina. Un servicio puede ser cualquier función técnica o de negocio; sin embargo, en una arquitectura SOA lo más importante es que la función sea totalmente reutilizable. Cuando se diseñan los servicios es importante que estos se centren en una sola cosa en lo posible, en otras palabras los servicios deberían solamente proveer servicios relacionados con un único propósito de negocio (granularidad). La funcionalidad de un servicio se llama granularidad. Mientras su granularidad es más fuerte el objetos presta muchos servicios, mientras más débil es su granularidad menos servicios presta. Lo óptimo es que el objeto tenga granularidad débil y que sea re utilizable. Modularidad. Los servicios deben ser modulares para poder permitir la agregación de estos y el consumo por parte de las aplicaciones. Los servicios son auto contenidos y auto descritos, dichos servicios a su vez pueden estar compuestos por otros servicios. Estos servicios de negocio pueden mezclarse y combinados para crear nuevos servicios compuestos. Un servicio soporta una serie de interfaces. Estas interfaces deben ser cohesivas, que quiere decir que todas deben estar relacionadas entre sí en el concepto de módulo. Una modularidad apropiada en SOA permite la agregación de los servicios dentro de una aplicación con sólo unas pocas dependencias bien identificadas. Débil acoplamiento. 108

109 Los servicios son descritos como objetos débilmente acoplados. Los sistemas deben tener algún conocimiento común para poder interactuar entre sí. Para alcanzar los beneficios de débil acoplamiento, se deben considerar aspectos relacionados con la interacción entre servicios, como la plataforma y el lenguaje en el cual los servicios son implementados, los protocolos de comunicación usados para la invocación de los servicios, y los formatos de datos usados para el intercambio de los datos de entrada y salida entre los proveedores y consumidores de servicios. Independencia del lenguaje: Se refiere a la habilidad para comunicarse con otros servicios sin importar el lenguaje de programación en el que ambos están implementados. Transparencia del protocolo de transporte: Se refiere a la habilidad para comunicar con otros servicios independientemente del protocolo con el cual ambos están conectados. Desde la perspectiva del cliente o consumidor del servicio, el protocolo del transporte que esté usando el proveedor del servicio no tiene porque impactar la forma es que el requerimiento del servicio es hecho. Transparencia de ubicación: Se refiere a la habilidad para comunicar con otros servicios sin importar donde realmente reside la implementación de estos. Desde la perspectiva del cliente o consumidor del servicio, la ubicación física del servicio no tiene porque impactar la forma es que el requerimiento del servicio es hecho. Independencia del formato de datos: Se refiere a la habilidad para comunicar con otros servicios sin usar exactamente el mismo esquema (estructura, elementos, tipos) para la data que los servicios necesitan intercambiar. Desde la perspectiva del cliente o consumidor del servicio, el esquema que el proveedor del servicio no tiene porque impactar la forma es que el requerimiento del servicio es hecho. Independencia de plataforma: Se refiere a la habilidad para comunicar con otros servicios, independiente del tipo de plataforma en donde ellos estén localizados. Transparencia del modelo de comunicación: Se refiere a la habilidad para comunicar con otros servicios, independiente de si los servicios están conectados a través de mecanismos sincrónicos o asincrónicos. 109

110 SERVICE ORIENTED ARCHITECTURE (SOA). Una Arquitectura Orientada a Servicios (en inglés Service-oriented architecture o SOA), es un concepto de arquitectura de software que define la utilización de servicios para dar soporte a los requerimientos de software del usuario..en un ambiente SOA, los servidores de la red hacen disponibles sus recursos a otros participantes en la red como servicios independientes a los que tienen acceso de un modo estandarizado. Al contrario de las arquitecturas orientadas a objetos, las arquitecturas orientadas a servicios están formadas por servicios de aplicación débilmente acoplados y altamente ínter operables. Para comunicarse entre sí, estos servicios se basan en una definición formal independiente de la plataforma subyacente y del lenguaje de programación. La definición de la interfaz encapsula (oculta) las particularidades de una implementación, lo que la hace independiente del fabricante, del lenguaje de programación o de la tecnología de desarrollo (como Java o.net). Con esta arquitectura, se pretende que los componentes software desarrollados sean muy reusables, ya que la interfaz se define siguiendo un estándar. Desde el punto de vista de negocio, SOA puede ser expresado como un conjunto de servicios flexibles y procesos que una organización quiere exponer para sus clientes, socios de negocio, proveedores o bien internamente. Desde el punto de vista técnico, SOA define software en término de servicios distintos, los cuales son implementados usando componentes que pueden ser invocados para realizar una operación específica para una función específica de negocio. SOA es un habilitador que permite que una organización reaccione sobre la demanda para responder a cambios en las condiciones de los procesos de negocio; esto sin duda tiene como consecuencia una tremenda ventaja competitiva en el mercado. ARQUITECTURA DE SOFTWARE. Una arquitectura software consiste en un conjunto de patrones y abstracciones coherentes que proporcionan el marco de referencia necesario para guiar la construcción del software para un sistema de información. La arquitectura software establece los fundamentos para que analistas, diseñadores, programadores, etc. trabajen en una línea común que permita alcanzar los objetivos y necesidades del sistema de información. Una arquitectura software se selecciona y diseña con base a unos objetivos y restricciones. Los objetivos son aquellos prefijados para el sistema de información, pero no solamente los de tipo funcional, también otros objetivos como el mantenimiento, la capacidad de auditoría, flexibilidad e interacción con otros sistemas de información. Las restricciones son aquellas limitaciones derivadas de las tecnologías disponibles para implementar sistemas de información. La arquitectura software define, de manera abstracta, los componentes que llevan a cabo alguna tarea de computación, sus interfaces y la comunicación 110

111 ente ellos. Toda arquitectura software debe poder ser implementada en una arquitectura física, que consiste simplemente en determinar qué computadora tendrá asignada cada tarea de computación. Arquitectura: AS400: BPM: Core: EAI: ESB: ESQL: IT: JDE: Middleware: MOM: MWAS: PORTAL: seguridades y "diseñar algo considerándolo en su contexto superior" Sistema de computo basado en tecnología ORACLE Business Process Management, disciplina empresarial cuyo objetivo es mejorar la eficiencia a través de la gestión sistemática de los procesos de negocio (BPR), que se deben modelar, automatizar, integrar, monitorizar y optimizar de forma continua. Núcleo Enterprise Application Integration, es el proceso de integración de múltiples aplicaciones que han sido desarrolladas de manera independiente y que, a menudo, utilizan tecnologías incompatibles y por lo tanto no se gestionan de forma coordinada. Enterprise Service Bus, actúan como intermediarios entre varios consumidores y proveedores de servicios, los ESB proporcionan autenticación, transformación y encaminamiento de servicios. Extended Structured Query Language. Information Technology. ERP JDEDWARDS, perteneciente a la casa ORACLE. Término asociado con un software de conectividad que ofrece un conjunto de servicios que hacen posible el funcionamiento de aplicaciones distribuidas sobre plataformas heterogéneas. Middeware Oriented Message Middeware Application Services Personalización necesaria a todos los servicios de información y transaccionales en un solo punto de entrada Sitio web donde un usuario tiene acceso con las 111

112 Red LAN: Red WAN: Servidor: Local Área Network (en inglés «Red de Área Local»), se refiere a las redes locales de ordenadores. Wide Area Network que en español significa (red de área amplia). Es la Internet o cualquier red en que no esté en un mismo edificio. Equipo de computación que posee capacidades para atender a mas computadores conectados. SOA: Services oriented arquitecture, arquitectura orientada a servicios Switch: Es un dispositivo de interconexión de redes de ordenadores / computadoras. Un switch interconecta dos o más segmentos de red, funcionando de manera similar a los puentes (bridges), pasando datos de una red a otra. TIC / TI Tecnologias de información y comunicaciones Es un dispositivo Time to market: Expresión utilizada para denominar al periodo de tiempo de un nuevo producto o servicio que va desde la generación de la idea hasta que éste alcanza el mercado. 112

113 3.4.- BIBLIOGRAFÍA Sitio Web de IBM (IBM SOA Self-Assessment) CICLO DE VIDA DE SOA (METODOLOGÍA) ORACLE SOA SUITE ESSENTIALS Vol 1 student Guide Oracle University Edicion 1.0 Service-Oriented Architecture: Concepts, Technology, and Design THOMAS ERL ED. Prentice Hall PTR 2005 Enterprise SOA: Service-Oriented Architecture Best Practices Dirk Krafzig, Karl Banke, Dirk Slama ED. Prentice Hall PTR 2004 Enterprise SOA: Designing IT for Business Innovation Thomas Mattern, Dan Woods ED. O'Reilly 2006 Architecture framework TOGAF version Personal PDF Edition ESB for SOA TIBCO Tipo PDF 113

114 ANEXOS Anexo 1 TALLER DE SOA El taller de SOA será desarrollado durante 15 días ( 5 días de Talleres con equipo designado por ANDES PETROLEUM, 10 día de Presentación y reunión de Preguntas y Respuestas, con los objetivos generales señalados anteriormente. Inicialmente se realizará un diseño de la arquitectura actual de la organizacion y posteriormente analizar la gestión de los procesos de negocios y su relación con la plataforma de tecnología. Mediante este estudio el Arquitecto revisa y analiza la documentación y los aspectos fundamentales de la arquitectura actual de la organización con el equipo de ANDES PETROLEUM responsable de la misma en un taller interactivo con el personal de la organizacion. Con esta revisión el Arquitecto tendrá el conocimiento para hacer recomendaciones, ajustes y/o mejoras a la arquitectura actual de La organización con conceptos de SOA, facilitando por ende la creación de un plan general (de nivel alto) para el desarrollo y despliegue de la tecnología a ser implementada. En esta fase se examina y recomienda la arquitectura de referencia SOA para posteriormente obtener un acercamiento de la arquitectura que puede ser desarrollada y es la más apropiada para EL CLIENTE. El desarrollo de los servicios se regirá a una visualización macro de los mismos que será elaborada en conjunto con ANDES PETROLEUM al inicio de la misma, en base a los objetivos definidos, y a las prioridades del mismo. Este documento constituirá la base para la implantación de la solución de integración al interior de ANDES PETROLEUM 114

115 ENTREGABLES Documento de Arquitectura de los sistemas de información de ANDES PETROLEUM, especificaciones técnicas generales, la identificación del ambiente hardware y comunicaciones objetivo, recomendaciones para optimizar la seguridad en el ambiente tecnológico. SUPUESTOS ORGANIZACIONALES ANDES PETROLEUM deberá contar con un equipo de trabajo para colaborar como contraparte al desarrollo del Taller. ANDES PETROLEUM, deberá brindar el acceso necesario a la información y funcionarios requeridos para la comprensión, diseño, desarrollo de este Taller. 115

116 ANEXO 2 PROCESOS 1) Las organizaciones están realizando significativos valoraciones en su negocio cuando aplican SOA, por favor seleccione la opción que mejor describa la experiencia de su organización en SOA 116

117 CUESTIONARIO Se tiene experiencia en la implementación diseño de SOA por departamentos o en aplicaciones de líneas de negocio A Ninguna B Baja C Alta 2.- Se tiene experiencia en la implementación, diseño de arquitecturas SOA para aplicaciones a nivel empresarial A Ninguna B Baja C Alta 3.- Se tiene experiencia en arquitectura, diseño e implementación de SOA para unos pocos procesos aislados del negocio A Ninguna B Baja C Alta 4.- Se ha experimentado la integración de aplicaciones y componentes de infraestructura básica A Ninguna B Baja C Alta 5.- La organización tiene al momento una arquitectura que integra los procesos del negocio A Ninguna B Baja C Alta 117

118 6.- La organización cuenta con el concepto o implementación de un bus de servicios empresariales A Conceptual B Diseño C Implementación D Producción y soporte E Ninguna 7.- Existe herramientas de SW para implementar un ESB en su organización A SI b NO 118

119 2) Adoptando SOA se tiene un crecimiento en la flexibilidad de las TI y como resultado una mejora de la sensibilidad de la experiencia organizacional, Cual opción describe mejor el nivel actual de la organización para soportar SOA 119

120 CUESTIONARIO Como se comunican sus aplicaciones y componentes entre sí en su organización a Interfaces codificadas y especificas entre los diferentes elementos en su gran mayoría b Interfaces codificadas entre las cuales se pueda usar código c Intercambio de datos via Web Seviches en su gran mayoría d A través de un bus de servicios corporativos 2.- Maneja aplicaciones orientadas a servicios en algunas segmentos de su organización a Ninguna b Pocas c La mayoría d Todas 3.- Ha definido una arquitectura de referencia para poder implementar SOA a si b no 4.- Ha definido los procesos de su organización orientados a servicios a Ninguno b Algunos c Todos 5.- Si en la pregunta 4 su respuesta fue B o C conteste si se ha definido procesos orientados a servicios en que nivel de operación se encuentran a A nivel Empresarial b A nivel de línea de negocio o departamento c A todo nivel 120

121 3) La adopción de SOA está ganando un fuerte apoyo entre el stakeholders Quiénes entienden su impacto potencial en el negocio. Cómo podría describir la percepción actual de SOA de sus stakeholders 121

122 CUESTIONARIO Los sakeholders en su organización manejan por lo menos el concepto de orientación a servicios en la organización a Nada b Manejan el concepto c Tienen claro el proceso de implementación SI su respuesta anterior fue B o C continué con las siguientes preguntas 2.- Sus stakeholders han analizado el impacto tecnológico al aplicar SOA en su organización a si b no 3.- Se ha definido planes o actividades por parte de los stakeholders para ser aplicados en una línea de negocio a si b no 2.- Sus stakeholders han analizado el impacto organizacional al aplicar SOA en su organización a si b no 6.- El nivel de compromiso de los stakeholders en su organización con el diseño e implementación de SOA es a bajo b medio c Alto 4) los procesos de negocio de la organización pueden ser optimizados con servicios por favor escoja la mejor opción que describa la técnica de la organización para identificar servicios 122

123 123

124 CUESTIONARIO Existe implementación de servicios en su organización a No b Si aunque el negocio no lo conoce c Si y el negocio conoce y apoya el método 2.- Existe en el negocio la noción de división de actividades de negocio en unidades elementales llamadas servicios a Ninguno b Bajo c Intermedio d Alto 3- La organización tiene técnicas o métodos establecidos para identificar y diseñar servicios a Se maneja conceptos de rehusó de código por lo menos b Al menos en sistemas codificados Orientados a Servicios c Si existe un método especifico para identificar servicios 4.- Los stakeholders participan en la identificación de servicios a No b Poco c Continuamente 5.- Se tiene un método estructurado para establecer servicios en la organización a No b Si 6.- Cual es el nivel de participación de los stakeholders en la identificación de servicios a ninguna b baja c alta 124

125 ANEXO 2 ARQUITECTURA Reduciendo la necesidad para el cliente de construir nuevas aplicaciones desde el inicio ofrece muchas ventajas. Que opción describe mejor las habilidades de su organización para crear nuevas aplicaciones desde los servicios existentes 125

126 CUESTIONARIO 1) Su organización es capaz de crear aplicaciones desde los servicios existentes del negocio Si No 2) Su organización a desarrollado aplicaciones que combinen servicios para dar soporte a una línea de negocio Si No Si la respuesta es SI, describa rápidamente una de estas aplicaciones ) Su organización a desarrollado aplicaciones que combinen servicios para dar soporte a varias líneas de negocio y a nivel empresarial Si No Si la respuesta es SI, describa rápidamente una de estas aplicaciones ) Como calificaría su nivel de desarrollo de soluciones orientadas a servicios en su organización a) Ninguna b) Baja c) Media d) Alta 5.) En que Etapa esta la evolución de la experiencia de desarrollo de soluciones que involucren servicios en su organización a) Inicial b) Media c) Avanzada 126

127 2.2.- Para obtener todos los beneficios de SOA, las organizaciones necesitan la habilidad para crear servicios rápidamente y fácilmente, Cual seria la mejor manera de describir las técnicas de desarrollo utilizadas por su organización para exponer servicios. 127

128 CUESTIONARIO 1.- Describa las técnicas utilizadas por su organización para crear servicios Las funcionalidades del negocio en su organización están expuestos como servicios? SI NO 3.- En su organización existe algún modulo para diseñar servicios usando las funciones del negocio SI NO Si la respuesta es SI, describa rápidamente este modulo La Arquitectura actual de su organización permite localizar fácilmente servicios SI NO 5.- Describa brevemente los APIs en su organización 128

129 2.3 Otro mayor beneficio de SOA es la facilidad de acceder a sistemas heterogéneos, escoja la respuesta que mejor describa las habilidades de conexión entre aplicaciones en su organización 129