Your SlideShare is downloading. ×
Soa Y Bpel
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Soa Y Bpel

4,186
views

Published on

Published in: Technology

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,186
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Introducción a Arquitecturas Orientada a Servicios y El Lenguaje de Ejecución de Procesos de Negocios (WS-BPEL) Carlos Rodríguez Fernández <carlosrodriguez@computer.org>
  • 2. Agenda
    • Introducción a SOA
    • Directivas de Análisis y Diseño para SOA
    • Estándares y Tecnologías
      • Mensajería
      • Seguridad
      • Descripción
      • Transacciones
      • Composición
  • 3. Agenda
    • Procesos de Negocio
    • WS-BPEL 2.0
      • El Lenguaje
      • Pros y Cons de WS-BPEL 2.0
    • Proceso: Reserva de Viajes
  • 4. Introducción a SOA
    • Servicio (ámbito del Software):
      • Función o prestación desempeñada por un Software para cuidar los intereses o satisfacer necesidades de Clientes que son Usuarios.
      • Implica un Contrato que describe:
        • Semántica (Funciones y sus significados, formas de uso de las mismas).
        • Garantías de Calidad (Tiempos de Respuesta, Disponibilidad, etc...).
        • Permisos y Obligaciones (Políticas de Seguridad).
  • 5. Introducción a SOA
    • Arquitectura Orientada a Servicio (SOA):
      • Aspectos técnicos que dirigen el diseño de la arquitectura de sistemas distribuidos que dan servicios.
      • Qué queremos: Desarrollar un Software que se venderá como un servicio, cuya arquitectura interna ha de ser distribuida.
      • Qué nos dan: Literatura SOA, Plataformas de Soporte a SOA (de desarrollo y ejecución).
  • 6. Introducción a SOA
    • Servicio:
      • Es un recurso computacional con un conjunto abstracto de operaciones.
      • Esta operaciones son implementadas por un agente software “proveedor” y son accesibles mediante el intercambio de mensajes.
      • En todo servicio hay un agente software “proveedor” y otro “cliente”.
      • Tiene una semántica.
      • Tiene una descripción que rige el uso.
  • 7. Introducción a SOA
    • Mensajes:
      • Tienen: Cuerpo , Cabecera , Envoltorio .
      • Hay una dirección de Origen y otra de Destino .
      • Hay un mecanismo de Transporte de Mensajes que lo hace llegar a su Destino (entiende el formato de las direcciones)
      • Hay un mecanismo de Correlación de mensajes que son de la misma Conversación .
  • 8. Introducción a SOA
    • Mensajes:
      • Mensaje es una Unidad Independiente de Comunicación.
      • Los mensajes deben ser auto-contenidos. Un mensaje tiene en si mismo toda la información de como debe ser interpretado y por tanto, procesado. Esto se describe en la Cabecera del mensaje.
  • 9. Introducción a SOA
    • Descripción de Servicio:
      • Documento procesable por software.
      • Describe:
        • Conjunto de operaciones disponibles (interfaz).
        • Intercambio de mensajes para acceder a dichas operaciones.
        • Políticas de Seguridad (Permisos y Obligaciones de los clientes)
        • Transporte de Mensajes: Tecnologías, Direcciones.
        • *Descripción semántica de las operaciones. Garantía de QoS. Información para Contratación.
  • 10. Introducción a SOA
  • 11. Directivas para SOA
    • Identificación de Servicios.
      • Servicios Agnósticos
      • Servicios Centrados en Entidades
      • Servicios Centrados en Tareas
      • Servicios de Orquestación
  • 12. Directivas para SOA
    • Servicios Agnósticos
      • e.g. FileManagerService, QueueService, SystemLogService, FormatTransformerService
      • Son altamente reutilizable en distintos dominios.
      • No deben manejar conceptos del dominio especifico
  • 13. Directivas para SOA
    • Servicios Centrados en Entidades
      • e.g. CustomerManagerService, TechnicianManagerService, ProductManagerService
      • Por cada entidad del dominio se podría crear un servicio que la gestiona.
      • Las operaciones serían:
        • AddEntidad, RemoveEntidad, UpdateEntidad, GetEntidad, GetBy...
  • 14. Directivas de SOA
    • Servicios Centrados en Tareas
      • e.g. OrderProcessingService (ValidateOrder), CommentsProcessingService (ModerateComment, EvaluateRelevanceOfComment).
      • Suelen ser agrupaciones de “step's” interpretados como tareas de procesos.
  • 15. Directivas para SOA
    • Servicios de Orquestación
      • e.g. TravelBookingService, OrderSubmissionService.
      • Procesos del dominio donde las operaciones del servicio son los eventos del proceso.
      • O pueden ser simplemente composiciones.
  • 16. Directivas para SOA
    • Los servicios debe ser sin estado.
      • En el documento de entrada debe estar todo lo necesario para reconstruir el “estado” de alguna base de datos si es que lo hay.
      • El estado de los procesos de larga duración debe ser persistente. Y se aplica lo anterior.
      • Usar patrón TransferObject, BusinessObject y DomainStore de J2EE para diseñar Servicios Centrados en Entidades y algunos Servicios Centrados en Tareas
  • 17. Directivas para SOA
    • Servicios de Orquestación
      • Usar servicios compuesto cuando se usen servicios de terceros en vez de usar adaptadores.
      • Tenga en cuenta la eficiencia. Muchos procesos son simplemente gestores de estados de una entidad. Ante tal caso use un Servicio Centrado en Tareas o un híbrido entre Centrado en Tareas y Entidades. (e.g. Estados de un documento propuesto)
  • 18. Estándares y Tecnologías
    • Transporte: HTTP, SMTP, JMS, Jabber, etc...
    • Formato: XML
    • Mensajería: SOAP, WS-Addressing
    • Seguridad: WS-Security
    • Descripción: WSDL, WS-Policy
    • Transacciones: WS-AtomicTransaction
    • Composición: WS-BPEL, WS-CDL
  • 19. Estándares y Tecnologías
    • La idea es no implementarse el estándar. Sino entender que hacen y usar herramientas e infraestructuras que lo implementen.
  • 20. Mensajería
    • Patrones de intercambio de mensajes:
      • Request-Response
      • Fire-and-forget
    • Una invocación a una operación corresponde a un intercambio de mensajes.
  • 21. Mensajería
    • SOAP: Simple Object Access Protocol. Estándar de la W3C
    • <soap:Envelop>
    • <soap:Header>
    • <!-- Cabecera del mensaje -->
    • </soap:Header>
    • <soap:Body>
    • <!-- Cuerpo del mensaje -->
    • </soap:Body>
    • </soap:Envelop>
  • 22. Mensajería
    • WS-Addressing añade la siguiente información a la cabecera del mensaje:
      • Destino del mensaje: a quien va dirigido
      • Dirección de origen: de donde proviene
      • Dirección de respuesta: “responder a”
      • Dirección en caso de fallo: “en caso de fallo enviárselo a”
      • Acción: información de la semántica del mensaje
      • Identificador único del mensaje
      • Relación con mensajes previos
  • 23. Mensajería
      • <S:Envelope xmlns:S=&quot;http://www.w3.org/2003/05/soap-envelope&quot;
      • xmlns:wsa=&quot;http://www.w3.org/2004/12/addressing&quot;>
      • <S:Header>
      • <wsa:MessageID>
      • http://example.com/SomeUniqueMessageIdString
      • </wsa:MessageID>
      • <wsa:ReplyTo>
      • <wsa:Address> http://myClient.example/someClientUser </wsa:Address>
      • </wsa:ReplyTo>
      • <wsa:FaultTo>
      • <wsa:Address> http://myserver.example/DemoErrorHandler </wsa:Address>
      • </wsa:FaultTo>
      • <wsa:To> http://myserver.example/DemoServiceURI </wsa:To>
      • <wsa:Action> http://myserver.example/DoSomething </wsa:Action>
      • </S:Header>
      • <S:Body>
      • <!-- The message body of the SOAP request appears here -->
      • </S:Body>
      • </S:Envelope>
  • 24. Seguridad
    • Hay distintos tipos niveles de seguridad en Web Services:
      • A nivel del Transporte: HTTPS (SSL)
      • A nivel de Mensajes: WS-Security
    • WS-Security es el estándar de OASIS que recoge todo lo referente a seguridad en los mensajes SOAP.
    • Recoge como incluir información de autenticación, confidencialidad e identificación en los mensajes SOAP
  • 25. Seguridad
    • Cómo poner una firma digital del contenido del mensaje
    • Cómo encriptar el cuerpo del mensaje
    • Cómo incluir información de identificación como Username/Password o SAML tokens, u otra clase de estos.
  • 26. Seguridad
      • <wsse:Security>
      • <wsse:BinarySecurityToken
      • ValueType=&quot;wsse:X509v3&quot;
      • EncodingType=&quot;wsse:Base64Binary&quot;
      • wsu:Id=&quot;MyTourOperatorCertificate&quot;>
      • LKSAJDFLKASJDlkjlkj243kj;lkjLKJ...
      • </wsse:BinarySecurityToken>
      • <ds:Signature>
      • <ds:SignedInfo>
      • <ds:CanonicalizationMethod
      • Algorithm=&quot;http://www.w3.org/2001/10/xml -exc-c14n# &quot;/>
      • <ds:SignatureMethod
      • Algorithm=&quot;http://www.w3.org/2000/09/xmldsig#rsa-sha1&quot;/>
      • <ds:Reference URI=&quot;#myDiscountRequestBody&quot;>
      • <ds:Transforms>
      • <ds:Transform
      • Algorithm=&quot;http://www.w3.org/2001/10/xml-exc-c14n#&quot;/>
      • </ds:Transforms>
      • <ds:DigestMethod
      • Algorithm=&quot;http://www.w3.org/2000/09/xmldsig#sha1&quot;/>
      • <ds:DigestValue>BSDFHJYK21f...</ds:DigestValue>
      • </ds:Reference>
      • </ds:SignedInfo>
      • <ds:SignatureValue>
      • GKLKAJFLASKJ52kjKJKLJ345KKKJ...
      • </ds:SignatureValue>
      • <ds:KeyInfo>
      • <wsse:SecurityTokenReference>
      • <wsse:Reference URI=&quot;#MyTourOperatorCertificate&quot;/>
      • </wsse:SecurityTokenReference>
      • </ds:KeyInfo>
      • </ds:Signature>
      • </wsse:Security>
  • 27. Descripción
    • La forma en que se describe los servicios es a través del estándar Web Services Description Language (WSDL) de W3C
    • Con WSDL se puede describir:
      • Interfaces
      • Implementación
      • Políticas (Obligaciones y Permisos)
  • 28. Descripción
    • La interfaz que el servicio implementa, es decir, las operaciones que ofrece se describen de la siguiente manera:
        • Se definen las estructuras de los documentos mediante XSD.
        • Se describen los mensajes indicando cual es el documento que contienen.
        • Se describen las operaciones indicando cual es el mensaje request y el mensaje response, o si es el caso, cual es el mensaje de fire-and-forget.
  • 29. Descripción
    • El Documento:
      • <types>
      • <schema targetNamespace=&quot;http://example.com/stockquote.xsd&quot;
      • xmlns=&quot;http://www.w3.org/2000/10/XMLSchema&quot;>
      • <element name=&quot;TradePriceRequest&quot;>
      • <complexType>
      • <all>
      • <element name=&quot;tickerSymbol&quot; type=&quot;string&quot;/>
      • </all>
      • </complexType>
      • </element>
      • <element name=&quot;TradePrice&quot;>
      • <complexType>
      • <all>
      • <element name=&quot;price&quot; type=&quot;float&quot;/>
      • </all>
      • </complexType>
      • </element>
      • </schema>
      • </types>
  • 30. Descripción
    • Los mensajes:
      • <message name=&quot;GetLastTradePriceInput&quot;>
      • <part name=&quot;body&quot; element=&quot;xsd1:TradePriceRequest&quot;/>
      • </message>
      • <message name=&quot;GetLastTradePriceOutput&quot;>
      • <part name=&quot;body&quot; element=&quot;xsd1:TradePrice&quot;/>
      • </message>
  • 31. Descripción
    • Las operaciones:
      • <portType name=&quot;StockQuotePortType&quot;>
      • <operation name=&quot;GetLastTradePrice&quot;>
      • <input message=&quot;tns:GetLastTradePriceInput&quot;/>
      • <output message=&quot;tns:GetLastTradePriceOutput&quot;/>
      • </operation>
      • </portType>
  • 32. Descripción
    • La implementación se define primeramente indicando un vínculo con una tecnología concreta y un punto de acceso al servicio:
      • <binding name=&quot;StockQuoteSoapBinding&quot; type=&quot;tns:StockQuotePortType&quot;>
      • <soap:binding style=&quot;document&quot; transport=&quot;http://schemas.xmlsoap.org/soap/http&quot;/>
      • <operation name=&quot;GetLastTradePrice&quot;>
      • <soap:operation soapAction=&quot;http://example.com/GetLastTradePrice&quot;/>
      • <input>
      • <soap:body use=&quot;literal&quot;/>
      • </input>
      • <output>
      • <soap:body use=&quot;literal&quot;/>
      • </output>
      • </operation>
      • </binding>
      • <service name=&quot;StockQuoteService&quot;>
      • <documentation>My first service</documentation>
      • <port name=&quot;StockQuotePort&quot; binding=&quot;tns:StockQuoteBinding&quot;>
      • <soap:address location=&quot;http://example.com/stockquote&quot;/>
      • </port>
      • </service>
  • 33. Descripción
    • Las políticas describen las obligaciones y los permisos de los clientes. El estándar que recoge como describirlas es el WS-Policy de W3C
    • Ejemplo de políticas concretas:
      • El cliente debe enviar los mensajes firmados y/o con la información encriptada.
      • El cliente debe incluir en los mensajes información de direccionamiento
      • El cliente puede soportar de manera opcional la fiabilidad en los mensajes.
  • 34. Descripción
      • <wsp:Policy
      • xmlns:sp=&quot;http://schemas.xmlsoap.org/ws/2005/07/securitypolicy&quot;
      • xmlns:wsp=&quot;http://schemas.xmlsoap.org/ws/2004/09/policy&quot; >
      • <wsp:ExactlyOne>
      • <wsp:All>
      • <sp:RequireDerivedKeys />
      • </wsp:All>
      • </wsp:ExactlyOne>
      • <wsp:ExactlyOne>
      • <wsp:All>
      • <sp:WssUsernameToken10 />
      • </wsp:All>
      • <wsp:All>
      • <sp:WssUsernameToken11 />
      • </wsp:All>
      • </wsp:ExactlyOne>
      • </wsp:Policy>
  • 35. Descripción
    • <description …>
    • <types> … </types>
    • <message>…</message> *
    • <portType>…</portType> *
    • <binding>…</binding> *
    • <service> … </service> *
    • <wsp:Policy>… </wsp:Policy> *
    • </description>
  • 36. Transacciones
    • Algoritmos de Transacciones en Web Services son heredados de Computación Distribuida.
      • WS-Coordination define como coordinar participantes en un protocolo.
      • WS-Transaction define la estructura de los mensajes.
      • WS-AtomicTransaction define los protocolos para Transacciones ACID, usando WS-Coord. para coordinar, y WS-Tx. para los mensajes.
  • 37. Transacciones
    • Algoritmo que define WS-ATx.
      • Two-Phase Commit.
    • Fases de una transacción WS.
      • 1) Creación del Contexto e intercambio de mensajes con el Contexto en la Cabecera
      • 2) Registro de los participantes y Coordinadores.
      • 3) Ejecución del Protocolo Two-Phase Commit entre los Coordinadores.
  • 38. Composición
    • Orquestación
      • Un servicio actúa como controlador de un proceso.
      • WS-BPEL
    • Coreografía
      • Varios servicios participan en un proceso que no es controlado por un servicio especifico.
      • WS-CDL
  • 39. Composición
  • 40. Composición
  • 41. Procesos de Negocio
    • Los procesos de negocios suelen definirse en los casos de usos de los sistemas.
    • Es un control lógico abstracto de ejecución de tareas con un objetivo de negocio.
    • Se suelen modelar haciendo uso de formalismos gráficos de UML 2 como son Diagramas de Actividad, Diagramas de Estados o BPMN (como extensión de UML 2).
  • 42. Procesos de Negocio
    • BPMN: Formalismo gráfico para el modelado de Procesos de Negocios en forma de Flujos de Trabajos (workflow).
    • De la OMG, versión actual 1.0.
    • Objetivo:
      • Dar una notación fácilmente comprensible por las personas que se dedican a modelar procesos de negocio que no son ingenieros IT.
      • Facilitar la transformación a WS-BPEL de los modelos
  • 43. Procesos de Negocio
    • Elementos de BPMN
      • Objetos de flujo: Eventos, Actividades, Gateways
      • Objetos de conexión: Flujo de secuencia, Flujo de mensaje, Asociación
      • Artefactos: Objeto de Datos, Anotaciones, Grupos
      • Swimlanes: Pool y Lane
  • 44. Procesos de Negocio
  • 45. Procesos de Negocio
    • Herramientas:
      • Eclipse 3.4 BPMN Modeler en el Soa Tool Platform (STP Update Site)
      • ActiveVOS Designer
      • Enterprise Architecture SPARX Systems
  • 46. WS-BPEL 2.0
    • Lenguaje basado en XML, estandarizado por el organismo OASIS.
    • Lenguaje Imperativo.
    • Primitivas que soportan el paralelismo.
  • 47. WS-BPEL 2.0
    • <process>
      • Elemento principal de una definición WS-BPEL
      • Atributo “name”: Nombre del proceso
      • Atributo “targetNamespace” y demás: Espacios de nombres relacionados con la definición.
      • <partnerLinks>
      • <variables>
      • <sequence>
      • ...
  • 48. WS-BPEL 2.0
    • <partnerLinks> {<partnerLink>}*
      • Define los PortType's de los servicios que participarán durante la ejecución del proceso.
      • Representa la comunicación entre dos “partner”. Uno es el proceso y otro es un servicio o un cliente.
      • Atributo “myRole”: Usado cuando el proceso es el que recibe los mensajes como proveedor del servicio.
      • Atributo “partnerRole”: Usado cuando el proceso es el cliente de un proveedor del servicio.
  • 49. WS-BPEL 2.0
    • <partnerLinks>
    • <partnerLink name=”Employee”
    • partnerLinkType=”emp:EmployeeType”
    • partnerRole=”EmployeeServiceProvider”
    • />
    • <partnerLink name=”client”
    • partnerLinkType=”tns:TimesheetSubmissionType”
    • myRole=”TimesheetSubmissionServiceProvider”
    • />
    • </partnerLinks>
  • 50. WS-BPEL 2.0
    • <partnerLinkType>
      • Es definido dentro del WSDL.
      • Referencia dentro del “partnerLink” al PortType del servicio.
    <definitions ... > ... <plnk:partnerLinkType name=”EmployeeServiceType” xmlns=”....”> <plnk:role name=”EmployeeServiceProvider”> <portType name=”emp:EmployeeInterface”/> </plnk:role> </plnk:partnerLinkType> </definitions
  • 51. WS-BPEL 2.0
    • <variables> {<variable>}*
      • Para definir variables dentro del proceso.
    <variables> <variable name=”EmployeeHoursRequest” messageType=”emp:getWeeklyHoursRequestMessage”/> <variable name=”EmployeeHoursResponse” messageType=”emp:getWeeklyHoursResponseMessage”/> </variables>
  • 52. WS-BPEL 2.0
    • <sequence>
      • Permite organizar una lista de actividades que se ejecutarán secuencialmente.
    • <switch>{<case condition=””>}*{<otherwise>}
      • Permite agregar control condicional lógico dentro del proceso
  • 53. WS-BPEL 2.0
    • <assign> {<copy>{ <from> <to>}}+
      • Permite copiar valores entre variables.
    <assign> <copy> <from variable=”TimesheetSubmissionFailedMessage”/> <to variable=”EmployeeNotificationMessage”/> </copy> </assign>
  • 54. WS-BPEL 2.0
    • <faultHandlers> {{<catch>}*<catchAll>}
      • Cada “catch” puede contener actividades para el tratamiento de alguna excepción.
      • Las excepciones pueden ser “Faults” de las invocaciones o las lanzadas por el mismo proceso usando la actividad “throw”
    <faultHandlers> <catch faultName=”SomethingBadHappened” faultVariable=”TimesheetFault”> ... </catch> </faultHandlers>
  • 55. WS-BPEL 2.0
    • <empty>: Actividad “NoOp”
    • <exit>: Terminar instancia
    • <flow>: Ejecución de todas las actividades que contiene en paralelo. No devuelve el control hasta que terminen todas.
    • <pick>: Para responder a eventos que tiene suspendido el proceso. De tiempo o de llegada de mensajes. (e.g. Esperar respuestas con TimeOut)
    • <eventHandlers>: Para responder a eventos en general de tiempo o de llegada de mensajes (e.g. Cancelaciones)
    • <scope>: Delimitar ámbitos.
    • <while>: Bucle
    • <wait>: Dormir la instancia por un tiempo.
  • 56. Pros y Con WS-BPEL 2.0
    • Pros
      • Programación Visual de Procesos.
      • Mecanismos de Correlación de mensajes, persistencia de procesos, etc... implementados ya de serie en la plataforma.
      • Mecanismos de control asíncronos, temporizadores, paralelismos fáciles de usar en el desarrollo.
    • Contras
      • Pobre integración con el resto de estándares.
      • Poca eficiencia.
      • Herramientas de calidad muy caras.
      • Muchas extensiones necesarias aportadas por plataformas pero no estandarizadas
  • 57. Proceso: Reserva de Viajes
  • 58. Proceso: Reserva de Viajes
  • 59. Preguntas ¡Gracias!
  • 60. Entorno Lab
    • ActiveVOS Designer
    • Apache Tomcat 5.5 con ActiveBPEL Open Source Engine
    • Apache Tomcat 6.0 con los Servicios del Tutorial que usará el proceso BPEL
    • SoapUI como cliente del Servicio Reserva de Viajes.