En esta lección se presentan el concepto y los componentes de una arquitectura orientada a servicios.
Estilo de arquitectura de TI que se apoya en la orientación a servicios.
La orientación a servicios es una forma de pensar en servicios, su construcción y sus resultados.
Un servicio es una representación lógica de una actividad de negocio que tiene un resultado de negocio específico (ejemplo: comprobar el crédito de un cliente, obtener datos de clima, consolidar reportes de perforación).
Fuente: https://es.wikipedia.org/wiki/Arquitectura_orientada_a_servicios
Reduce el nivel de acoplamiento.
Clara definición de roles de desarrollo.
Definición de seguridad más clara.
Fácil de probar.
Mejora el mantenimiento.
Favorece la reutilización.
Favorece el desarrollo en paralelo.
Favorece la escalabilidad.
Permite un mapeo directo entre los procesos y los sistemas.
Permite un monitoreo preciso.
Permite la interoperabilidad.
Fuente: http://soa-fpuna.blogspot.com/2011/11/ventajas-y-desventajas.html
Definición clara y estandarizada mediante descriptores de servicio, donde se indique:
Nombre del Servicio.
Forma de accesos.
Funcionalidades que ofrece.
Descripción de los datos de entrada de cada funcionalidad que ofrece.
Descripción de los datos de salida de cada funcionalidad que ofrece.
Sin estado: no guardan valores para ser usados en otras llamadas. (es posible acceder a bases de datos.)
Pueden también ejecutar unidades discretas de trabajo como serían editar y procesar una transacción.
No dependen del estado de otras funciones o procesos.
Fuente: https://ederluisdsd.wordpress.com/2013/03/17/principios-de-diseno-soa/
Interfaz de usuario que invoca a los procesos de negocio.
Interfaces web, escritorio, móvil, etc.
Pueden ejecutarse en varios dispositivos.
Integración de uno o más servicios que resuelven un problema de negocio.
Componentes que se han desarrollado como servicios.
Recursos operacionales: CRM, ERP, HR, BD.
Tecnologías (Java, .NET, PHP).
Fuente: https://www.slideshare.net/imcinstitute/service-oriented-architecture-soa-15-introduction-to-soa
Puedes encontrar información sobre este tipo de diagramas en: https://www.uml-diagrams.org/component-diagrams.html.
A continuación se muestra como quedaría un sitio con bases de datos si se adaptara a SOA.
Siglas en inglés de eXtensible Markup Language, traducido como Lenguaje de Marcado Extensible o Lenguaje de Marcas Extensible.
Metalenguaje que permite definir lenguajes de marcas.
Desarrollado por el World Wide Web Consortium (W3C).
Utilizado para almacenar datos en forma legible.
Fuente: https://es.wikipedia.org/wiki/Extensible_Markup_Language
1 | <?xml version="1.0" encoding="UTF-8" ?> |
2 | <!DOCTYPE MiContacto SYSTEM "MiContacto.dtd"> |
3 | <Contacto> |
4 | <Nombre>Juan</Nombre> |
5 | <Email>juan@gm.com</Email> |
6 | <Telefonos> |
7 | <Telefono>5555555555</Telefono> |
8 | <Telefono>8888888888</Telefono> |
9 | </Telefonos> |
10 | </Contacto> |
1 | <?xml version="1.0" encoding="ISO-8859-1" ?> |
2 | <!-- Este es el DTD de Contacto --> |
3 | <!ELEMENT Contacto (Nombre, Email, Telefonos)> |
4 | <!ELEMENT Nombre (#PCDATA)> |
5 | <!ELEMENT Email (#PCDATA)> |
6 | <!ELEMENT Telefonos (Telefono)*> |
7 | <!ELEMENT Telefono (#PCDATA)> |
Originalmente siglas de Simple Object Access Protocol, Protocolo de Acceso Simple a Objetos.
Hoy en día solo es SOAP, sin un significado especial.
Protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML.
Es uno de los protocolos utilizados para implementar servicios web.
Fuente: https://es.wikipedia.org/wiki/Simple_Object_Access_Protocol
Usan formato XML.
3 elementos:
El elemento raíz.
Especificación de como procesar los datos.
El conenido del mensaje.
Fuente: https://es.wikipedia.org/wiki/Simple_Object_Access_Protocol
1 | <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> |
2 | <soap:Header> |
3 | <t:Transaction xmlns:t="alguna-URI" soap:mustUnderstand="1"> |
4 | 5 |
5 | </t:Transaction> |
6 | </soap:Header> |
7 | <soap:Body> |
8 | <getDetalleDeProducto xmlns="http://warehouse.example.com/ws"> |
9 | <productoId>827635</productoId> |
10 | </getDetalleDeProducto> |
11 | </soap:Body> |
12 | </soap:Envelope> |
1 | <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> |
2 | <soap:Body> |
3 | <getRespuestaDetalleDeProducto xmlns="http://warehouse.example.com/ws"> |
4 | <getResultadoDetalleDeProducto> |
5 | <productId>827635</productId> |
6 | <nombre>Balón de Futbol</nombre> |
7 | <descripcion>Balón de futbol de 11” de vinil.</descripcion> |
8 | <precio>300.0</precio> |
9 | </getResultadoDetalleDeProducto> |
10 | </getRespuestaDetalleDeProducto> |
11 | </soap:Body> |
12 | </soap:Envelope> |
Siglas de Web Services Description Language, es un formato de XML que se utiliza para describir servicios Web.
Describe los requisitos del protocolo y los formatos de los mensajes necesarios para interactuar con los servicios listados en su catálogo.
Las operaciones y mensajes que soporta se describen en abstracto y se ligan después al protocolo concreto de red y al formato del mensaje.
Se usa a menudo en combinación con SOAP y XML Schema.
Los tipos de datos especiales se incluyen en el archivo WSDL en forma de XML Schema.
El cliente puede usar SOAP para hacer la llamada a una de las funciones listadas en el WSDL.
Fuente: https://es.wikipedia.org/wiki/Simple_Object_Access_Protocol
Define los tipos de datos usados en los mensajes. Se utilizan los tipos definidos en la especificación XML Schema.
Define los elementos de mensaje. Cada mensaje puede consistir en una serie de partes lógicas. Las partes pueden ser de cualquiera de los tipos definidos en el elemento message.
Define las operaciones permitidas y los mensajes intercambiados en el Servicio.
Especifica los protocolos de comunicación usados.
Conjunto de puertos y dirección de los mismos. Esta parte final hace referencia a lo aportado por las secciones anteriores.
Con estos elementos no sabemos qué hace un servicio pero sí disponemos de la información necesaria para interactuar con él (funciones, mensajes de entrada/salida, protocolos, etcétera).
1 | <definitions name=“PrecioProd“ |
2 | targetNamespace="http://example.com/stockquote.wsdl" |
3 | xmlns:tns="http://example.com/stockquote.wsdl" |
4 | xmlns:xsd1="http://example.com/stockquote.xsd" |
5 | xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" |
6 | xmlns="http://schemas.xmlsoap.org/wsdl/"> |
7 | <types> |
8 | <schema targetNamespace="http://example.com/stockquote.xsd" |
9 | xmlns="http://www.w3.org/2000/10/XMLSchema"> |
10 | <element name="SolPrecioProd"> |
11 | <complexType> |
12 | <all> |
13 | <element name="productoId" type="decimal"/> |
14 | </all> |
15 | </complexType> |
16 | </element> |
17 | <element name="PrecioProd"> |
18 | <complexType> |
19 | <all> |
20 | <element name="precio" type="float"/> |
21 | </all> |
22 | </complexType> |
23 | </element> |
24 | </schema> |
25 | </types> |
26 | <message name="InputGetPrecioProd"> |
27 | <part name="body" element="xsd1:SolPrecioProd"/> |
28 | </message> |
29 | <message name="OutputGetPrecioProd"> |
30 | <part name="body" element="xsd1:PrecioProd"/> |
31 | </message> |
32 | <portType name="PortTypePrecioProd"> |
33 | <operation name="GetPrecioProd"> |
34 | <input message="tns:InputGetPrecioProd"/> |
35 | <output message="tns:OutputGetPrecioProd"/> |
36 | </operation> |
37 | </portType> |
38 | <binding name="BindPrecioProdSoap" type="tns:PortTypePrecioProd"> |
39 | <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> |
40 | <operation name="GetPrecioProd"> |
41 | <soap:operation soapAction="http://example.com/GetPrecioProd"/> |
42 | <input> |
43 | <soap:body use="literal"/> |
44 | </input> |
45 | <output> |
46 | <soap:body use="literal"/> |
47 | </output> |
48 | </operation> |
49 | </binding> |
50 | <service name="ServPrecioProd"> |
51 | <documentation>Devuelve el precio de un producto.</documentation> |
52 | <port name="PuertoPrecioProd" binding="tns:BindPrecioProdSoap"> |
53 | <soap:address location="http://example.com/precioprod"/> |
54 | </port> |
55 | </service> |
56 | </definitions> |
Este estándar no se usa.
Siglas del catálogo de negocios de Internet denominado Universal Description, Discovery and Integration.
El registro en el catálogo se hace en XML.
Es una iniciativa industrial abierta (sufragada por la OASIS) entroncada en el contexto de los servicios Web.
El registro de un negocio en UDDI tiene tres partes:
dirección, contacto y otros identificadores conocidos.
categorización industrial basada en taxonomías.
información técnica sobre los servicios que aportan las propias empresas.
Es uno de los estándares básicos de los servicios web, cuyo objetivo es ser accedido por los mensajes SOAP y dar paso a documentos WSDL, en los que se describen los requisitos del protocolo y los formatos del mensaje solicitado para interactuar con los servicios Web del catálogo de registros.
Siglas para Representational State Transfer o transferencia de estado representacional.
Estilo de arquitectura de software para sistemas distribuidos en la World Wide Web.
Fuentes: https://es.wikipedia.org/wiki/Transferencia_de_Estado_Representacional y https://bbvaopen4u.com/es/actualidad/api-rest-que-es-y-cuales-son-sus-ventajas-en-el-desarrollo-de-proyectos
Toda página web tiene una URL asociada, pero también puede representar una
entidad, que puede ser una colección de datos, por ejemplo,
https://mirest.com/contactos
, o un objeto, por ejemplo,
https://mirest.com/contactos/69
.
Para interactuar con la URL hay que enviarle una solicitud, que consta de:
Con parámetros opcionales que consisten en nombre y valor asociado, separados por & (como cuando buscas en Google).
Proporcionan información sobre la computadora y el programa que envían los datos, así como la informacion que esperan recibir.
Contiene datos adicionales,Pueden representarse en los siguientes formatos:
application/x-www-form-urlencoded
multipart/form-data
text/plain
XML
JSON
YAML
Indica la acción que debe realizarse sobre la URL, usando los datos adicionales.
Fuente: https://developer.mozilla.org/es/docs/Web/HTTP/Methods
Realiza una prueba de enviar un mensaje mensaje al servidor de la URL y recibirlo de regreso sin modificaciones.
Devuelve una descripción de las opciones de comunicación de laURL.
Establece un tunel bidireccional hacia el servidor.
Devuelve los datos de la colección u objeto asociados con la URL, sin modificar el estado del servidor.
Puede tomarse en cuenta los parámetros que lleva la URL, como si fueran las condiciones de una cláusula WHERE de SQL.
Devuelve una respuesta como la de GET, pero sin el cuerpo de la respuesta.
Envía una entidad a una URL.
Si la URL representa una lista que no contiene esa entidad, la agrega.
Los datos de la entidad se indican en el cuerpo de la solicitud.
A menudo causa un cambio o efectos secundarios en el servidor.
Reemplaza toda la entidad indicada en la URL con el contenido del cuerpo de la solicitud.
Modifica parcialmente la entidad de la URL, modificando solamente los datos enviados en el cuerpo de la solicitud.
Eliminar la entidad de la URL
Fuente: https://developer.mozilla.org/es/docs/Web/HTTP/Methods
En esta lección se introdujeron los siguientes temas:
Arquitectura orientada a servicios
Ventajas de una arquitectura orientada a servicios
Principios de diseño de un servici
Capas de una arquitectura orientada a servicios
Diagrama de Arquitectura
XML
SOAP
WSDL
UDDI
REST