Taller de Sistemas de Información 1

Transcripción

1 Taller de Sistemas de Información 1 Aplicaciones Empresariales, Arquitectura de Software y Web Services 12 de Marzo de 2012 Instituto de Computación Facultad de Ingeniería Universidad de la República de Uruguay

2 Aplicaciones Empresariales Agenda Definición Características y Roles Integración de Aplicaciones Plataformas de Desarrollo Empresarial Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 2

3 Aplicaciones Empresariales Definición Una Aplicación Empresarial es una aplicación de software desarrollada para administrar las operaciones, activos y recursos de una empresa Algunos ejemplos: o Contabilidad o Seguimiento de envíos o Servicio al cliente o Nómina de empleados Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 3

4 Aplicaciones Empresariales Características Las aplicaciones empresariales tienen en general las siguientes características: o Involucran persistencia de datos o Se manejan grandes cantidades de datos o Existen varias interfaces de usuario, para distintos tipos de usuario o En general se deben integrar con otras aplicaciones o Se accede a los datos de forma concurrente Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 4

5 Aplicaciones Empresariales Roles El proceso de desarrollo de una aplicación empresarial involucra al menos: o Programadores de aplicaciones o Administradores de base de datos o Diseñadores de interfaz de usuario o Integradores de aplicaciones Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 5

6 Aplicaciones Empresariales Desafíos La creación y mantenimiento de las aplicaciones presenta varias complejidades: o Administración o Mantenibilidad o Escalabilidad o Interoperabilidad o Seguridad o Confiabilidad o Accesibilidad y Usabilidad o Internacionalización Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 6

7 Aplicaciones Empresariales Integración de Aplicaciones Integración de Aplicaciones Empresariales (EAI) es la tarea de hacer que aplicaciones desarrolladas de forma independiente trabajen de forma conjunta con el fin de compartir datos y procesos de negocio Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 7

8 Aplicaciones Empresariales Integración de Aplicaciones Al integrar Aplicaciones Empresariales surgen varios desafíos: o Las redes no son confiables o Las redes son lentas o Las aplicaciones son diferentes a nivel de lenguajes de programación, formato de datos, etc o El cambio en las aplicaciones es inevitable Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 8

9 Aplicaciones Empresariales Integración de Aplicaciones Históricamente se han utilizado distintos enfoques para la integración: o Transferencia de archivos o Base de datos compartida o Invocación de procedimientos remotos Comunicación sincrónica o Mensajería Comunicación asincrónica Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 9

10 Aplicaciones Empresariales Plataformas de Desarrollo Empresarial Existen plataformas que facilitan el desarrollo e integración de aplicaciones empresariales, brindando solución a los problemas presentados Ejemplos o.net (la que se utilizará en este curso) o Java EE Permiten que el desarrollador se concentre en los aspectos relevantes para el negocio Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 10

11 Agenda Definiciones Importancia y Objetivos Lineamientos y Principios Estilos Arquitectónicos Representación de la Arquitectura Microsoft Patterns & Practices. Microsoft Application Architecture Guide v2.0 Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 11

12 Una Definición Una de las definiciones más aceptadas es la del Software Engineering Institute (SEI) de la Universidad de Carnegie-Mellon La arquitectura de un sistema de software es la estructura o estructurasdel sistema, que comprende elementos de software, las propiedades visibles externamentede dichos elementos y la relación entre ellos Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 12

13 Por qué es importante? Como cualquier otra estructura compleja, el SW debe ser construido sobre una base sólida Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 13

14 Por qué es importante? Bien definida, la arquitectura permite guiar el proceso de construcción de la aplicación Una arquitectura pobre atenta contra: o la simpleza, extensibilidad y mantenibilidad de la aplicación Si bien las plataformas y herramientas modernas simplifican la construcción de aplicaciones, sigue siendo necesario un diseño cuidadoso basado en escenarios y requerimientos específicos. Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 14

15 Por qué es importante? Los sistemas deben ser diseñados teniendo en cuenta: o El usuario del mismo o La infraestructura tecnológica existente o Las metas del negocio Existe un trade off entre todos estos participantes... Usuario Negocio Sistema Microsoft Patterns & Practices. Microsoft Application Architecture Guide v2.0 Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 15

16 Metas de la Arquitectura La arquitectura debe: o Exponer la estructura del sistema pero esconder los detalles de implementación o Realizar todos los casos de uso y escenarios de negocio o Cumplir con los requerimientos de los involucrados en el sistema o Manejar requerimientos funcionales y no funcionales Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 16

17 Algunos Lineamientos Construir para cambiar, en vez de para durar Modelar para analizar y reducir riesgos Utilizar modelos y visualizaciones como una herramienta de comunicación y colaboración Identificar las decisiones arquitectónicas principales Considerar el utilizar un enfoque iterativo incremental para refinar la arquitectura Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 17

18 Principios Clave La Arquitectura de SW se describe usualmente como la organización o estructura de un sistema, donde el sistema representa una colección de componentes que realiza una función específica. La Arquitectura se enfoca entonces en organizar componentes para dar soporte a una funcionalidad específica. A esta organización de funcionalidad se la conoce en general como agrupación de componentes en areas de concern Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 18

19 Arquitectura Típica Microsoft Patterns & Practices. Microsoft Application Architecture Guide v2.0 Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 19

20 Principios Clave Separation of concerns o Dividir la aplicación en diferentes bloques, con el mínimo de solapamiento funcional posible o Lograr alta cohesión, bajo acoplamiento Single responsability o Cada componente debe ser responsable de una única funcionalidad, o ser agregador de funcionalidad cohesiva Least knownledge (Law of Demeter) o Un componente no debe conocer detalles internos de otro componente Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 20

21 Principios Clave Don't Repeat Yourself (DRY) o La funcionalidad no debe ser duplicada en diferentes componentes You ain't gona need it (YAGNI) o Evitar realizar un esfuerzo excesivo en el diseño, sobre todo si los requerimientos no están claros, o si pueden haber posibilidades de evolución Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 21

22 Patrones / Estilos Arquitectónicos Un patrón ofrece soluciones a problemas conocidos o Permiten clasificar y re-aprovechar el conocimiento o Generan vocabulario Patrones arquitectónicos dado un contexto de aplicación o proponen la organización estructural y de comportamiento del software o especifican las propiedades que tendrá el sistema al incorporarlos o provee un marco abstracto para una familia de sistemas Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 22

23 Patrones / Estilos Arquitectónicos (ejemplos) Cliente / Servidor Arquitectura Basada en Componentes Diseño Dirigido por Modelos Arquitectura en Capas 3-Tier / N-Tier Arquitectura Orientada a Servicios (SOA) Message Bus La arquitectura de un sistema de software es a menudo una combinación de estilos para formar el sistema completo. Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 23

24 Arquitectura en Capas (Layers) Layers es un estilo arquitectónico que comúnmente se utiliza para las Aplicaciones Empresariales En este esquema las capas más altas utilizan servicios definidos por las capas más bajas Esta división lógica entre capas de funcionalidad pueda basarse en distintas responsabilidades Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 24

25 Arquitectura en Capas Microsoft Patterns & Practices. Microsoft Application Architecture Guide v2.0 Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 25

26 Arquitectura en Capas Capa de presentación o Contiene la funcionalidad responsable de gestionar la interacción del usuario con el sistema o Actúa como puente entre el usuario y la lógica de negocio Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 26

27 Arquitectura en Capas Capa de negocio o Implementa la funcionalidad central de la aplicación o Encapsula la lógica de negocio relevante para la aplicación o Consiste en componentes, los cuales exponen (en algunos casos) interfaces para que otros utilicen Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 27

28 Arquitectura en Capas Capa de acceso a datos o Provee acceso a los datos almacenados en las fronteras de la aplicación, así como a los datos expuestos por otros sistemas de información a los que se tiene conexión o Los componentes en la capa de negocio hacen uso de los datos provistos por estos componentes Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 28

29 Deployment Las capas antes presentadas pueden estar ubicadas en la misma locación física (tier) o en diferentes locaciones físicas Si se encuentran en locaciones físicas diferentes, existen fronteras físicas que deben ser tomadas en cuenta en el diseño Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 29

30 Deployment Al definir la estrategia de deployment hay que optar por un esquema distribuido o no distribuido Si se trata de una aplicación para una Intranet, accedida por un conjunto pequeño de usuarios, en general es conveniente considerar un enfoque no distribuido Si la aplicación es mas compleja, la cual debe se mantenible y escalable, un enfoque distribuido debería ser la elección Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 30

31 Deployment No Distribuido Este enfoque minimiza el número de servidores requeridos Minimiza el impacto en performance inherente a la comunicación entre capas de diferentes lugares físicos Sin embargo, compartir el mismo hardware, puede impactar la performance, por ejemplo, al acceder a recursos compartidos Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 31

32 Deployment Distribuido Este enfoque permite configurar el hardware según las necesidades de cada capa Esto permite ajustar las necesidades de escalabilidad según cada capa de la aplicación Sin embargo, el uso de componentes distribuidos, impacta la performance a la hora de realizar llamadas remotas entre diferentes locaciones físicas Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 32

33 Patrones de Deployment Distribuido (N-Tier) Cliente / Servidor 2-Tier 3-Tier N-Tier Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 33

34 Patrones de Deployment Distribuido (N-Tier) Cliente / Servidor Microsoft Patterns & Practices. Microsoft Application Architecture Guide v2.0 Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 34

35 Patrones de Deployment Distribuido (N-Tier) 3-Tier Microsoft Patterns & Practices. Microsoft Application Architecture Guide v2.0 Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 35

36 Patrones de Deployment Distribuido (N-Tier) 4-Tier Microsoft Patterns & Practices. Microsoft Application Architecture Guide v2.0 Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 36

37 Arquitectura Orientada a Servicios (SOA) Una Arquitectura Orientada a Servicios (Service Oriented Architecture, SOA) es una forma lógica de diseñar un sistema de software para proveer servicios, a aplicaciones u otros servicios distribuidos en la red, a través de interfaces que son publicadas y puede ser descubiertas (Papazoglou and Heuvel 2007) Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 37

38 Roles en una SOA Los tres roles principales en una SOA son: o Proveedor de Servicios o Registro de Servicios o Consumidor de Servicios (Endrei et al. 2004) Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 38

39 Beneficios SOA Una SOA facilita varias tareas del desarrollo de aplicaciones empresariales distribuidas: o la integración, la implementación de procesos de negocios y el aprovechamiento de sistemas legados Una SOA provee la flexibilidad y agilidad que requieren los usuarios de negocio: o les permite definir servicios de alta granularidad que pueden ser combinados y reutilizados para abordar necesidades de negocio actuales y futuras (Papazoglou and Heuvel 2007) Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 39

40 Capas de una SOA Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 40

41 SOA y Arquitectura en Capas Microsoft Patterns & Practices. Microsoft Application Architecture Guide v2.0 Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 41

42 Representación Modelos La arquitectura es un concepto abstracto por lo que se necesita un mecanismo de representación Un modelo es una simplificación de la realidad, creada con el objetivo de abstraer una porción del sistema, de forma de simplificar su comprensión Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 42

43 Representación Vistas Una vista es una representación de uno o más aspectos estructurales de una arquitectura que ilustra cómo la arquitectura lleva adelante uno o más concerns de uno o más stakeholders o stakeholders persona, grupo o entidad con un interés sobre la realización de la arquitectura o concern (preocupación) de la arquitectura es un requerimiento, objetivo o intención que pueda tener un stakeholder respecto a la arquitectura Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 43

44 Representación Vistas Modelo 4+1 vistas para la arquitectura de software o Propuesto por Phillipe Kruchten (1995) o Impulsa fuertemente la noción de vistas como modelo de representación de arquitecturas de software Sugiere o 4 vistas del sistema o 1 vista de casos de uso Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 44

45 Representación vocabulario funcionalidad ensamblado del sistema gestión de configuración comportamiento Logical View Process View Implementation View Use-Case View Deployment View performance escalabilidad topología distribución instalación Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 45

46 Representación Cada vista está más alineada al punto de vista de un stakeholder o Lógica: usuario final o Proceso: integrador, desarrollador o Implementación: desarrollador, project manager o Deployment: administrador del sistema Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 46

47 4 + 1: Vista de Casos de Uso La descripción de la funcionalidad provista por el sistema, desde el punto de vista de un actor externo o Selección de escenarios relevantes para la arquitectura Se usa para ilustrar las otras vistas de la arquitectura Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 47

48 4 + 1: Vista de Casos de Uso Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 48

49 4 + 1: Vista lógica Focalizada en los requerimientos funcionales fundamentalmente Presenta las abstracciones lógicas más importantes potencialmente varios refinamientos definición de las interfaces que ofrecen los componentes Generalmente se utilizan patrones o estilos arquitectónicos para organizar Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 49

50 4 + 1: Vista lógica Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 50

51 4 + 1: Vista de Procesos Presenta los procesos o threads de ejecución presentes en el sistema Presenta la estrategia de sincronización y comunicación entre procesos Considera requerimientos no funcionales como performance, tolerancia a fallas, disponibilidad, escalabilidad, etc Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 51

52 4 + 1: Vista de Deployment Describe la organización del sistema en el ambiente donde va a ser instalado o nodos que conforman la topología física del ambiente o hardware y/o software que soporta la ejecución en estos nodos o particularidades de configuración o mecanismos de comunicaciones entre dichos nodos Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 52

53 4 + 1: Vista de Deployment Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 53

54 4 + 1: Vista de Implementación Se focaliza en los módulos en que está organizado el ambiente de desarrollo o Incorpora restricciones particulares de la plataforma, lenguaje de programación o herramientas que se estén utilizando Presenta los componentes run-time que conforman el sistema Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 54

55 4 + 1: Vista de Implementación Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 55

56 Documento de Arquitectura Plantilla para el curso o oratorio/guia-sad-2012.odt Andrés Vignaga, Daniel Perovich. SAD del subsistema de reservas del sistema de gestión hotelera. o c/tr0314.pdf Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 56

57 Web Services Agenda Definición Primera Generación (SOAP, WSDL, UDDI) Segunda Generación (WS-*) Web Services REST Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 57

58 Web Services El término Web Service nace aproximadamente en el año 2000 Surgen como una necesidad de la industria en las áreas: o Business to Business (B2B) o Enterprise Application Integration (EAI) Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 58

59 Web Services Un Web Service es una aplicación de software identificada por una URI, cuyas interfaces y formas de acceso pueden ser definidas, descriptas y descubiertas como artefactos XML, y soporta la interacción directa con otros componentes de software utilizando mensajes basados en XML, intercambiados a través de protocolos basados en internet Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 59

60 Web Services Primera Generación Universal Description, Discovery and Integration (UDDI) Web Services Description Language (WSDL) Find Publish WSDL FTP, SMTP, etc. HTTP SOAP Simple Object Access Protocol (SOAP) Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 60

61 Web Services Simple Object Access Protocol (SOAP) Provee una forma estándar de estructurar mensajes utilizando XML Define mecanismos para utilizar distintos protocolos de transporte para el envío de mensajes Especifica un modelo de procesamiento que indica cómo se deben procesar los mensajes Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 61

62 Web Services Mensaje SOAP <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:header>... </soap:header> <soap:body>... </soap:body> </soap:envelope> <soap:fault>... </soap:fault> Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 62

63 Web Services Web Service Description Language (WSDL) Lenguaje basado en XML que permite describir la interfaz y otras características de un Web Service Un documento WSDL puede dividirse en dos partes: o descripción abstracta o descripción concreta Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 63

64 Web Services Web Service Description Language (WSDL) La descripción abstracta describe de forma general la estructura de la interfaz del Web Service, que incluye operaciones, parámetros y tipos de datos abstractos La descripción concreta asocia a una descripción abstracta una dirección de red concreta, un protocolo de comunicación y estructuras de datos concretas Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 64

65 Web Services Universal Description Discovery & Integration (UDDI) Especificación que provee una forma estándar de publicar y descubrir Web Services UDDI define o un modelo de datos para almacenar información de servicios y negocios o dos interfaces para utilizar el registro UDDI Inquiry Publish Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 65

66 Web Services Segunda Generación Surgen como forma de abordar problemáticas comunes en contextos empresariales Se les conoce como WS-* Cada una aborda una problemática específica: o Seguridad, Transacciones, Mensajería, etc Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 66

67 Web Services WS-BPEL Web Services Business Process Execution Language es un lenguaje para orquestar Web Services WS-BPEL es un lenguaje de flujo basado en XML para la especificación formal de procesos de negocio y protocolos de interacción de negocio Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 67

68 Web Services WS-Addressing WS-Addressing (WS-A) provee un mecanismo estándar para direccionar mensajes y Web Services Define dos construcciones básicas o endpoint reference Address, Reference Parameters, Metadata o addressing properties To, From, ReplyTo, FaultTo, Action, MessageID, RelatesTo ReferenceParameters Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 68

69 Web Services WS-Policy Define un modelo abstracto, independiente del dominio, que permite describir características, requerimientos y capacidades de un Web Service Delega a otras especificaciones la definición de políticas particulares a un dominio. o WS-SecurityPolicy o WS-ReliableMessagingPolicy Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 69

70 Web Services WS-Atomic Transaction / WS-BusinessActivity Transacción Atómica: WS-AtomicTransaction o Propiedades ACID o Corta Duración o Ambiente seguro o Diseñado principalmente para dar soporte a la interoperabilidad Actividad de Negocio: WS-BusinessActivity o Larga Duración o Se define un mecanismo de compensación Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 70

71 Web Services WS-Security Define un conjunto de extensiones SOAP para brindar seguridad a nivel de mensaje Se especifica cómo: o utilizar XML Signature en mensajes SOAP o utilizar XML Encryption en mensajes SOAP o incluir Tokens de Seguridad en mensajes SOAP Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 71

72 Web Services WS-Trust WS-Trust es una especificación que extiende WS- Security y provee: o métodos para la expedición, renovación y validación de tokens de seguridad o formas para establecer, evaluar y administrar relaciones de confianza Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 72

73 WS-Trust Microsoft Corporation. Web Service Security Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 73

74 Web Services REST REST (REpresentational State Transfer) Estilo arquitectónico para sistemas de hipermedia distribuidos Todo es tratado como recursos que se identifican por URIs Toma ventaja de los verbos HTTP o GET, POST, PUT, DELETE Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 74

75 Web Services REST (REpresentational State Transfer) La intención de una llamada a un RESTful Service, se obtiene del verbo HTTP o GET (recuperar), DELETE (eliminar) Verbo HTTP Significado en términos de CRUD (Create, Read, Update, Delete) POST GET PUT DELETE Crear un nuevo recurso a partir de los datos de la solicitud. Leer un recurso. Actualizar un recurso a partir de los datos de la solicitud. Eliminar un recurso. Java Web Services: Up and Running, 1st Edition. Martin Kalin. O'Reilly Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 75

76 Web Services REST (REpresentational State Transfer) De este modo las URIs actúan como identificadores de recursos y los métodos HTTP como verbos que especifican operaciones sobre los mismos Verbo HTTP / URI POST emps GET emps Significado en términos de CRUD Crear un nuevo empleado a partir de los datos de la solicitud. Leer una lista de todos los empleados. GET emps?id=27 Leer el empleado 27. PUT emps DELETE emps Actualizar la lista de empleados con los datos de la solicitud. Eliminar la lista de empleados. DELETE emps?id=27 Eliminar el empleado 27. Java Web Services: Up and Running, 1st Edition. Martin Kalin. O'Reilly Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 76

77 Referencias Microsoft Patterns & Practices. Microsoft Application Architecture Guide v2.0 Martin Fowler. Patterns of Enterprise Application Architecture. Addison-Wesley Professional, G. Hohpe and B. Woolf, Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley Professional, October Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 77

78 Referencias Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives. N. Rozanski, E. Woods. Addison-Wesley, 2005 Software Architecture in practice, Second Edition. L. Bass, P. Clemens, R. Kazman. Addison-Wesley, 2003 Architectural Blueprints The 4+1 View Model of Software Architecture. Kruchten, Philippe Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 78

79 Referencias M. Papazoglou, Web Services: Principles and Technology, 1st ed. Prentice Hall, Web Services Concepts, Architectures and Applications. Gustavo Alonso, Fabio Casati, Harumi Kuno, Vijay Machiraju. Springer Understanding Web Services Specifications. IBM developersworks. Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 79

80 PREGUNTAS Instituto de Computación Facultad de Ingeniería Universidad de la República de Uruguay