SEPGLA 2007 Migración a Ambientes de Arquitectura Orientada a Servicios (SOA) Grace Lewis

25 %
75 %
Information about SEPGLA 2007 Migración a Ambientes de Arquitectura Orientada a Servicios...

Published on November 26, 2007

Author: nopiedra

Source: slideshare.net

Description

SEPGLA 2007:
Migración a Ambientes de Arquitectura Orientada a Servicios (SOA)
Grace A. Lewis
Software Engineering Institute, USA
Noviembre 26, 2007
Fuente: CD Memorias SEGLA 2007

Migración a Ambientes de Arquitectura Orientada a Servicios (SOA) Grace A. Lewis Software Engineering Institute, USA Noviembre 26, 2007 © 2007 Carnegie Mellon University Contenido Introducción a SOA Desde los 50,000 Pies de Altura • Desde los 10,000 Pies de Altura • Desde los 1,000 Pies de Altura • Pilares del Desarrollo de Sistemas Basados en SOA Técnica para la Migración y Reutilización de Servicios (SMART) Implicaciones para los Procesos de Desarrollo de Sistemas Conclusiones Conceptos Básicos 2 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University 1

¿Qué es SOA? Arquitectura orientada a servicios es una manera de diseñar, desarrollar, desplegar y administrar sistemas en la cual Servicios proveen funcionalidad reutilizable. • Las definiciones de interfaces de servicios son artefactos • de primera clase. Una infraestructura SOA posibilita el descubrimiento, • composición e invocación de servicios. Protocolos son en su mayoría, pero no exclusivamente, • intercambios de documentos basados en mensaje. Consumidores de servicios son construidos utilizando la • funcionalidad brindada por los servicios disponibles. Conceptos Básicos 3 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University Servicios Servicios son componentes reutilizables que representan tareas del negocio. Consulta de clientes • Validación de tarjeta de crédito • Consulta del estado del tiempo • Reservación de hotel • Servicios pueden Estar distribuidos globalmente en múltiples organizaciones • Reconfigurados en nuevos procesos de negocio • Las definiciones de interfaces de servicios son artefactos de primera clase, bien definidos e idealmente disponibles en un registro de servicios Conceptos Básicos 4 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University 2

Infraestructura SOA Conjunto de tecnologías que conectan consumidores de servicios a servicios Productos, estándares y protocolos que soportan la comunicación— • Típicamente intercambio de documentos basado en mensajes Web Services (HTTP, SOAP, WSDL) — Message-oriented middleware (i.e. IBM Websphere MQ) — Publish/subscribe (i.e. Java Messaging Service — JMS) — CORBA … — Servicios de infraestructura disponibles para proveedores y/o consumidores • de servicios Seguridad, descubrimiento, transformación de datos, … — Herramientas y guías para desarrollo, despliegue y administración • Conceptos Básicos 5 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University Consumidores de Servicios Clientes de la funcionalidad brindada por los servicios Aplicaciones de usuario final • Sistemas internos • Sistemas externos • Servicios compuestos • Consumidores se conectan de forma programática a servicios. Conceptos Básicos 6 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University 3

Componentes de un Sistema Basado en SOA Aplicación Consumidor Sistema Usuario Portal Externo Interno Final Consumidores de Servicios Infraestructura SOA Internet Herramientas Seguridad Descubrimiento de Desarrollo Infraestructura Servicio Servicio Servicio Servicio A B C D Interfaces de Servicios Sistema de Código Nuevo o Sistema Información Implementación de Existente Externo Gerencial Servicios Usuarios Internos Conceptos Básicos 7 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University En Resumen … SOA es una manera de desarrollar sistemas en la cual Servicios contienen funcionalidad reutilizable con interfaces bien definidas. • Una infraestructura SOA permite el descubrimiento, composición e • invocación de servicios. Consumidores de servicios son construidos utilizando funcionalidad de los • servicios disponibles. Si es manejado bien, la adopción de SOA puede llevar a Eficiencia de costos • Agilidad de negocios • Adaptabilidad • Aprovechamiento de la inversión en sistemas existentes • Conceptos Básicos 8 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University 4

Contenido Introducción a SOA Desde los 50,000 Pies de Altura • Desde los 10,000 Pies de Altura • Operaciones Básicas — OASIS SOA Reference Model (SOA RM) — Web Services — Desde los 1,000 Pies de Altura • Pilares del Desarrollo de Sistemas Basados en SOA Técnica para la Migración y Reutilización de Servicios (SMART) Implicaciones para los Procesos de Desarrollo de Sistemas Conclusiones Desde los 10,000 Pies 9 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University Contexto Operacional de un Sistema Basado en SOA Nuevas aplicaciones pueden ser creadas Organización 2 reutilizando funcionalidad existente Organización 1 Sistema de Infraestructura SOA Validación de Aplicación Tarjetas de Crédito de Gestión Sistema de de Clientes Gestión de FedEx Pedidos Aplicaciones pueden Sistema Aplicación de Envíos de Proceso interactuar Internet Sistema de Pedidos con sistemas UPS Financiero de diferentes Firewall Sistema organizaciones de Envíos Aplicaciones a través de pueden interfaces DHL interactuar con Organizaciones estándar Organización sistemas externas Sistema Cliente de Envíos internos a través pueden acceder Aplicación de de interfaces a funcionalidad Pedidos Aplicaciones pueden automatizar sus estándar interna procesos utilizando funcionalidad externa Operaciones Básicas 10 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University 5

Tres Operaciones Básicas Para Soportar Sistemas Basados en SOA Descubrimiento de Servicios Repositorios de servicios son consultados buscando servicios con ciertas • características. Composición de Servicios Aplicaciones/Consumidores de servicios son construidos mediante la • integración de funcionalidad brindada por servicios. Invocación de Servicios Los consumidores invocan los servicios necesarios y el código • correspondiente a la implementación de los servicios es ejecutado. Operaciones Básicas 11 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University Estático vs. Dinámico Estático—Con la tecnología actual, el descubrimiento y la composición de servicios se hace durante diseño del sistema. El desarrollador descubre servicios y obtiene sus direcciones. • El desarrollador escribe código para invocar los servicios localizados en estas • direcciones. Dinámico—Hay una gran cantidad de investigación en el área de descubrimiento y composición de servicios en tiempo de ejecución. La aplicación descubre servicios y obtiene direcciones. • La aplicación contiene código para invocar el servicio descubierto y “sabe” que • información es necesaria para la ejecución del servicio. Hay muchas técnicas Intermedias. La aplicación descubre los servicios, pero se requiere intervención del usuario para • seleccionar servicios y proveer la información requerida. “Portals” son configurados del tal manera que sus “portlets” corresponden a servicios. • Operaciones Básicas 12 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University 6

Descubrimiento de Servicios Mayores retos: Descripción de servicios y Desarrolladores de mantenimiento del repositorio consumidores de servicios consultan el registro buscando Hay algún servicio que Aplicación Aplicación servicios que pueda devolver toda la de de Proceso contengan una Facturación información de un cliente de Pedidos funcionalidad deseada. dado un código de cliente? Servicios son Infraestructura SOA Descubrimiento registrados en un Registro de Herramientas Registro de Servicios Seguridad Servicios de Desarrollo que es parte de la infraestructura SOA. El Sistema de Gestión de Sistema de Sistema Sistema de Clientes registra sus dos Gestión de Financiero Gestión de servicios Pedidos Clientes - Búsqueda de Clientes - Directorio de Clientes Operaciones Básicas 13 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University Composición de Servicios Mayores retos: La aplicación de proceso de pedidos necesita producir un reporte impreso Incompatibilidad de Aplicación que para un cliente contenga de Proceso procesos/datos y manejo de de Pedidos información del cliente, estado transacciones financiero y pedidos pendientes. Infraestructura SOA Descubrimiento Registro de Herramientas Seguridad Servicios de Desarrollo El servicio de Búsqueda de Clientes es El servicio de utilizado para Sistema Sistema de Sistema de Pedidos obtener la Financiero Gestión de Gestión Pendientes es información del Clientes Pedidos invocado para cliente. obtener los El servicio de Estado Financiero pedidos Cliente es invocado para obtener pendientes. el saldo del cliente. Operaciones Básicas 14 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University 7

Invocación de Servicios 1 Service Request Mayor reto: Service Response Trabajar con servicios que 2 Consumidor de Servicios Service Query pueden no estar Discovery disponibles Service Location Service Request Service Response Servicio 3 Service Query Service Service Location Broker Service Location Service Query Discovery Discovery Discovery Service Request Service Response Operaciones Básicas 15 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University ¿Entonces Qué Es Diferente? Conceptualmente no hay nada nuevo, pero, finalmente se han integrado tecnologías y prácticas existentes en una manera que realmente funciona. Mayor alineamiento entre TI y el negocio • Servicios representan tareas/actividades del negocio — Gran apoyo por parte de la industria • Basado en estándares • Mayor rigor en la especificación de interfaces • Verdadero acoplamiento débil entre servicios y consumidores • Consumidores no tiene que instalar componentes específicos — Independencia de la plataforma de implementación — Lo que está detrás de la interface es irrelevante para el consumidor o del servicio Operaciones Básicas 16 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University 8

¿Entonces Cuál Es El Reto? ¡Crear Buenos Servicios! Representan tareas comunes de múltiples casos de uso o procesos del negocio Tienen (o pueden tener) múltiples consumidores Posibilitan la integración programática entre consumidores y servicios Corresponden a funcionalidad que no requiere mantener un estado (el servicio no conserva información acerca de pasadas invocaciones o el orden en que debe ser invocado) Las entradas y salidas de sus operaciones no requieren la construcción de consumidores muy complejos Miremos una definición Son de naturaleza “request-response” más formal de SOA … Aunque SOA 2.0 introduce el manejo de eventos • Operaciones Básicas 17 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University OASIS SOA RM Modelo de referencia para SOA Objetivo es “definir la esencia de la arquitectura orientada servicios, y construir un vocabulario y un entendimiento común acerca de SOA.” Independiente de la tecnología de implementación Versión 1.0 (Octubre 2006) disponible en http://www.oasis-open.org/specs/index.php#soa-rmv1.0 Fuente: OASIS SOA RM v1.0 OASIS SOA RM 18 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University 9

Definiciones Básicas “Arquitectura Orientada a Servicios es un paradigma para organizar y utilizar capacidades distribuidas que pueden estar bajo el control de diferentes dueños. Brinda una manera uniforme de ofrecer, descubrir, interactuar y utilizar capacidades para producir efectos deseados que son consistentes con precondiciones y expectativas medibles.” “Un servicio es la manera mediante la cual las necesidades de un consumidor son reunidas con las capacidades de un proveedor.” Fuente: OASIS SOA RM v1.0 OASIS SOA RM 19 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University Características de Sistemas Basados en SOA Tienen entidades que pueden ser identificadas como servicios de acuerdo con la definición del modelo Permiten identificar cómo se establece visibilidad entre proveedores y consumidores de servicios Ahora miremos Permiten identificar cómo es mediada la interacción Web Services Permiten identificar el efecto de utilizar servicios como una implementación Tienen descripciones asociadas a servicios específica de SOA Permiten la identificación del contexto de ejecución … requerido para soportar la interacción Puede ser posible identificar cómo son manejadas las políticas y cómo los contratos pueden ser modelados y obligar su cumplimiento Fuente: OASIS SOA RM v1.0 OASIS SOA RM 20 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University 10

Web Services Web Services es un mecanismo para la implementación de sistemas basados en SOA. Interfaces de servicios son descritas utilizando Web Services Description • Language (WSDL). Datos son transmitidos utilizando SOAP sobre HTTP. • UDDI es opcionalmente utilizado como el servicio de directorio. • Debido a que es el mecanismo más común, con frecuencia Web Services es utilizado como un equivalente de SOA. Web Services 21 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University Stack de Protocolos de Web Services • Los estándares en verde Orchestration and son los más utilizados y Choreography más estables, los WSCL, WSCI, BPEL, amarillos están WS-Coordination emergiendo como BPML, BPSS estándares de Quality of Service Discovery Management Transactions preferencia, y los rojos UDDI Security están desapareciendo. Description • La mayoría de estándares WSDL para Web Services están Message Format emergiendo y algunos Base SOAP, REST Stack incluso compiten. Encoding • Seguridad, QoS, XML Transacciones y Transport Administración tienen que HTTP manejarse en todos los Adapted from “XML and Web Services Unleashed”, SAMS Publishing niveles. Web Services 22 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University 11

Web Services en Tiempo de Diseño—Estático Bob (proveedor Alice Alice utiliza el Alice adiciona de servicios) (consumidor de documento código a su expone servicios) WSDL como aplicación que funcionalidad en obtiene el entrada para ejecuta el código su sistema como documento herramientas de construcción un Web Service WSDL que que generan de mensajes (o crea un Web corresponde al todo el código para conectarse Service Web Service de para al Web Service específico) y Bob (e.g. busca construcción de de Bob y código coloca un en el repositorio mensajes (e.g. adicional que documento UDDI). WSDL2Java). utiliza la WSDL en un respuesta del “lugar accesible” Web Service de (e.g. repositorio Bob. UDDI). Web Services 23 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University Web Services en Tiempo de Diseño—Dinámico Bob (proveedor Alice Alice escribe Alice escribe de servicios) crea (consumidor de código en su código en su un Web Service, servicios) aplicación que aplicación que lo describe escribe código selecciona un invoca el utilizando WSDL, en su aplicación servicio de la servicio y lo registra en un que consulta el lista retornada seleccionado repositorio de repositorio de por la consulta. con los servicios (e.g. servicios en parámetros UDDI). tiempo de apropiados. ejecución. Para que esto sea completamente transparente, Alice y Bob tienen que compartir una ontología utilizada para describir la semántica del servicio. Web Services 24 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University 12

Web Services en Tiempo de Ejecución HTTP Request Call Return HTTP Usuario de la Servidor HTTP Sistema de Bob Response Aplicación de Alice 1. Usuario ejecuta 3. Cuando el servidor 5. El sistema de Bob la aplicación de HTTP de Bob ve un ejecuta la operación Alice. mensaje SOAP, lo invocada. envía al SOAP 2. Aplicación engine. 6. El sistema de Bob construye un retorna los mensaje SOAP 4. El SOAP engine resultados de la y lo envía al interpreta el mensaje y operación. servicio de Bob construye el llamado al vía HTTP. sistema de Bob. 8. La aplicación de 7. El SOAP engine Alice interpreta construye el mensaje la respuesta y de respuesta y lo muestra retorna vía HTTP. resultados al usuario. Web Services 25 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University En Resumen … • Ambientes SOA tienen que soportar tres operaciones básicas. Descubrimiento de servicios • Composición de servicios • Invocación de servicios • • Conceptualmente, no hay nada diferente en SOA Lo que pasa es que las tecnologías y las prácticas que soportan la • integración de sistemas se están utilizando en una manera que funciona. • El OASIS SOA RM presenta una definición muy abstracta de SOA, servicio y sistema basado en SOA que está abierta a múltiples interpretaciones • Web Services es el mecanismo más utilizado para la implementación de SOA—pero no el único Desde los 10,000 Pies 26 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University 13

Contenido Introducción a SOA Desde los 50,000 Pies de Altura • Desde los 10,000 Pies de Altura • Desde los 1,000 Pies de Altura • Pilares del Desarrollo de Sistemas Basados en SOA Técnica para la Migración y Reutilización de Servicios (SMART) Implicaciones para los Procesos de Desarrollo de Sistemas Conclusiones Desde los 1,000 Pies de Altura 27 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University Un Potencial Problema Si servicios, consumidores de servicios e infraestructura SOA son desarrollados por la misma organización, los retos son menores. La comunicación es más simple entre desarrolladores (o quizás son los • mismos desarrolladores) Sin embargo, es cada vez más común encontrar que los tres tipos de componentes son desarrollados por diferentes organizaciones de manera independiente—es un nuevo modelo de negocios. Las decisiones tomadas localmente por cada uno de estos grupos de • desarrollo puede tener un efecto sobre los demás grupos. Desde los 1,000 Pies de Altura 28 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University 14

Consumidores de Servicios 4. Diseñar la aplicación de tal manera que pueda fácilmente acomodar cambios en los servicios 2. Entender la infraestructura y las Organización 2 interfaces de servicios en términos de funcionalidad y calidad de servicios Sistema de Organización 1 Validación de Infraestructura SOA Tarjetas de Crédito Aplicación de Gestión Sistema de de Clientes FedEx Gestión de Pedidos Sistema de Envíos Aplicación Internet de Proceso 1. Identificar Sistema de Pedidos servicios UPS Financiero apropiados Firewall Sistema (internos y de Envíos 3. Crear la nueva externos) que aplicación utilizando puedan ser tantos servicios Organización DHL reutilizados como sea posible Cliente Sistema Un consumidor de servicios de Envíos Aplicación de necesita crear una nueva aplicación Pedidos 5. ¡¡Pruebas!! basada en SOA. Desde los 1,000 Pies de Altura 29 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University Retos para Consumidores de Servicios Servicios disponibles pueden no satisfacer requerimientos funcionales y no funcionales. Servicios pueden cambiar o desaparecer sin notificación. Herramientas y programas que hacen parte de la infraestructura pueden ser incompatibles con el ambiente de desarrollo. Servicios pueden ser semánticamente incompatibles desde el punto de vista del consumidor. Servicios provenientes de diferentes organizaciones pueden ser inconsistentes. La prueba total del sistema requiere que instancias de prueba de todos los servicios estén disponibles. Desde los 1,000 Pies de Altura 30 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University 15

Desarrolladores de Servicios 3. Anticipar requerimientos de futuros consumidores Organización 2 Organización 1 Sistema de Infraestructura SOA Validación de Aplicación Tarjetas de de Gestión Sistema de Crédito de Clientes Gestión de FedEx Pedidos Sistema Aplicación de Envíos de Proceso Internet Sistema de Pedidos Financiero UPS Sistema de Envíos 2. Analizar 1. Identificar 4. Diseñar, crear y requerimientos de la funcionalidad de DHL publicar servicios infraestructura, negocios que pueda para consumidores interfaces, Sistema ser expuesta como internos y/o de Envíos funcionalidad y QoS de un servicio externos consumidores Desde los 1,000 Pies de Altura 31 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University Retos para Desarrolladores de Servicios Si requerimientos de consumidores no son entendidos, los servicios podrían nunca ser utilizados. El esfuerzo de transformación de tipos de datos podría ser mayor de lo esperado. En ambientes SOA propietarios podrían existir Múltiples restricciones sobre los servicios desarrollados • Dependencias en herramientas y programas de la infraestructura que están • en conflicto con el ambiente de desarrollo Aún no existen guías claras para el desarrollo de Acuerdos de Nivel de Servicios (SLAs). Desde los 1,000 Pies de Altura 32 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University 16

Desarrolladores de Infraestructura Herramientas para Selección de desarrolladores de productos y servicios y consumidores Organización 2 estándares Organización 1 Sistema de Infraestructura SOA Validación de Aplicación Tarjetas de Seguridad de Gestión Sistema de Crédito de Clientes Gestión de FedEx Herramientas Pedidos de Desarrollo Sistema Aplicación de Envíos de Proceso Sistema Descubrimiento Internet de Pedidos Financiero UPS Registro de Servicios Sistema de Envíos Servicios de Mecanismos de DHL Infraestructura Documentación conexión Sistema y soporte de Envíos Desde los 1,000 Pies de Altura 33 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University Retos para Desarrolladores de Infraestructura Minimizar el efecto de cambios en estándares y productos utilizados por la infraestructura sobre sus usuarios. Especialmente estándares emergentes • Estimar correctamente el esfuerzo para el desarrollo, soporte y entrenamiento a usuarios. Desde los 1,000 Pies de Altura 34 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University 17

Granularidad de Servicios 1 La granularidad de las interfaces de servicio puede afectar desempeño porque los servicios son ejecutados como el intercambio de una petición de servicio y una respuesta del servicio a través de una red. Si las interfaces de servicio son de alta granularidad, sus consumidores van a • recibir más datos de los necesarios en el mensaje de respuesta. Si las interfaces de servicio son de baja granularidad, sus consumidores van • a tener que hacer múltiples viajes al servicio para obtener los datos necesarios. Desde los 1,000 Pies de Altura 35 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University Granularidad de Servicios 2 … o el servicio puede ser más granular y tener tres operaciones diferentes para los tres tipos de información InfoCliente getInfoBasica( IdCliente ) Sistema de Gestión de HistPedidos getHistoriaPedidos( IdCliente) Pedidos Pedido[] getPedidosPendientes( IdCliente ) [Info Básica, Historia Pedidos, Pedidos Pendientes] getInfoCliente( IdCliente ) El Sistema de Gestión de Pedidos puede exponer la funcionalidad de obtener toda la información de un cliente como una sola operación … Desde los 1,000 Pies de Altura 36 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University 18

Manejo de Transacciones 1 La decisión de asignación de responsabilidad del manejo de transacciones tiene un efecto sobre el desarrollo de sistemas basados en SOA. Escenario La Aplicación de Proceso de Pedidos necesita colocar un pedido. • Tres sistemas están involucrados • El Sistema de Gestión de Pedidos controla la creación del pedido. — El Sistema Financiero contiene la información financiera del cliente. — El Sistema de Inventarios contiene información sobre partes y cantidad — en inventario. Un pedido se considera completo después de verificar el estado financiero • del cliente y las partes en inventario son marcadas para envío. Desde los 1,000 Pies de Altura 37 Versión 1.5 (SEPG-LA 2007) © 2007 Carnegie Mellon University Manejo de Transacciones 2 Responsabilidad: Proveedor de Servicios NOTA: El proveedor de 1. Aplicación servicio podría invoca el decidir hacer 2. Infraestructura Aplicación 6. Aplicación servicio llamados directos de Proceso localiza el servicio recibe el estado de colocarPedido. en vez de utilizar de Pedidos colocarPedido. la operación. las interfaces de ↓ colocarPedido servicio Infraestructura SOA ↓ colocarPedido ↓ marcarInventario ↓ getInfoFinanciera Sistema de Sistema Sistema Gestión de de Financiero Pedidos Inventario 4. Sistema de Gestión de Pedidos invoca 5. Sistema de Gestión de getInfoFinancera. 3. Sistema de Gestión Pedidos invoca de Pedidos inicia marcarInventario. transacción Desde los 1,000 Pies d

Add a comment

Related presentations

Related pages

Elementos esenciales de una arquitectura orientada a servicios

SEPGLA 2007 Migración a Ambientes de Arquitectura Orientada a Servicios (SOA) Grace Lewis SEPGLA 2007:Migración a Ambientes de Arquitectura Orientada a ...
Read more

Arquitectura Orientada a Servicios para investigación ...

Arquitectura Orientada a Servicios para Investigación(ejemplo de uso en Algoritmos Evolutivos)Pablo García Sánchezpgarcia@atc.ugr.es#CITICOFFEE18 de ...
Read more

Welcome Fortune City Customers | Dotster

Welcome Fortune City Customers. Fortune City is now Dotster. With this change, you now have 24x7 support. Don't hesitate to call our Support team toll free ...
Read more

Hostgator Coupon - Best Hosting for Wordpress and Joomla sites

Hostgator Coupon; Terms and Conditions; ... As far back as 2007, Hostgator has been receiving awards for the great service they provide to each customer.
Read more

Bal des Conscrits de Besse - EventsDiscovery.com - A ...

On vous propose de venir vous détendre avec nous le temps d'une soirée, que se soit pour faire une pause pendant vos révisions, de souffler après les ...
Read more

Search Results for '' | FreshNews.com

Search Results for '' 145337 results found in 0.086 seconds. Monday, September 7, 2015. Global Personal Emergency Response Systems (PERS) Industry ...
Read more

108GAME - Play Free Online Games

Free Online Games at 108GAME.com. Awesome action games, puzzle games, adventure games, multiplayer games, skill games & best action games.
Read more

Noticias - La Rocha

El blog de Arts&Crafts de La Rocha, con ideas creativas, descargables, DIY, técnicas y muchas sorpresas ¡entra a verlo!
Read more

Google

Advertising Programmes Business Solutions +Google About Google Google.com © 2015 - Privacy - Terms ...
Read more