soa/oracle osbcommitea.es/wp-content/uploads/2019/02/osb12_d1.pdfcontenidos soa/oracle osb...
TRANSCRIPT
SOA/ORACLE OSBM á l a g a – 0 2 / 2 0 1 9
A. Ramón MolinaJefe de ProyectoConexiones & IT
Axesor
0. Requisitos previosSOA/ORACLE OSB
Máquina virtual, Oracle OSB 12C
Descargada, instalada y funcionando correctamente
Acceso a los documentos y archivos del curso
http://commitea.es/osb120.2
0.1
Comunicación
@commitea
http://commitea.es
0.3
A. Ramón Molina Milla (commitea)
A. Ramón Molina Milla (commitea)
0.1 Máquina virtual Oracle OSB 12cRequisitos previos
Máquina virtual Oracle OSB 12.2.1
- Enlace de la descarga: link
- Instalación Oracle Virtual Box 6.0: link
- Configuración
- CPU: 2/4 Cores
- RAM: 8046/10924 MB
- Límite de ejecución 100%
- Red tipo bridge con el conector usado por la maquina host
- Reubicación de los discos duros virtuales
- Posibilidad de usar Jdeveloper de forma nativa: link
- SoapUI-5.5.0: link
- Notepad++: link
- XMLTools
CONTENIDOSSOA/ORACLE OSB
DEPURACIÓN Y CONTROL OSB
Identificar y corregir los posibles errores dentro de
un pipeline.
ADAPTADORES Y TRANSPORTE EN OSB
Componentes que nos permiten el acceso a ciertos
orígenes y la comunicación entre origen y destino.
SEGURIDAD EN SOA/OSB
Métodos y aplicación de patrones definidos por
SOA y aplicados sobre Oracle OSB.5
6
4
FLUJO DE MENSAJES
Herramientas y funcionalidad que nos permite usar
la arquitectura SOA sobre la información tratada.
INTRODUCCIÓN ARQUITECTURA SOA
Comprender que es soa y las principales
herramientas y formatos que lo conforman.
INTRODUCCIÓN ORACLE OSB
Principios básicos de como funciona la herramienta
de Oracle para el intercambio de datos con SOA.2
3
1
L M X J V
18 19 20 21 22
25 26 27 28 29
4 5 6 7 8
PlanificaciónDía 18/02/2019
BienvenidaPresentacionesRevisión/Instalación de software en equipos
Introducción a Arquitectura SOA- ¿Qué es SOA?- SOA Governance- Niveles de abstracción- Patrones de diseño- ETL y ESB- SOAP- XML, XSD
- Ejercicios: - Diseño arquitectura integración real- Validación xml simple- Validación xml complejo.
Horario:09:00 – 14:00
Duración:25 horas
Lunes 18
A. Ramón Molina Milla (commitea)
1. INTRODUCCIÓN SOASOA/ORACLE OSB
Patrones de diseño SOA
Patrones en el mundo real
¿Qué es SOA y que necesidades cubre?
Identificar la necesidad de implantar SOA dentro de un proyecto.
SOA Governance
monitorización y control de alto nivel para procesos de negocio 1.2
1.4
1.1
Niveles de abstracción SOA
Indicador de nivel madurez SOA1.3
A. Ramón Molina Milla (commitea)
1. INTRODUCCIÓN SOASOA/ORACLE OSB
ESB
Enterprise Service Bus1.5
ETL
Extract, Transport and Loading1.6
A. Ramón Molina Milla (commitea)
XML y XSD
Extensible Markup Language / schema1.8
SOAP
1.7 Simple Object Access Protocol
1. INTRODUCCIÓN SOASOA/ORACLE OSB
REST
Enterprise Service Bus1.9
ODATA
Extract, Transport and Loading1.10
A. Ramón Molina Milla (commitea)
1.1 ¿Qué es SOA y que necesidades cubre?Introducción SOA
A. Ramón Molina Milla (commitea)
1.1 ¿Qué es SOA y que necesidades cubre?Introducción SOA
“Una arquitectura orientada a servicios (SOA) es una arquitectura para
construir aplicaciones empresariales como un conjunto de componentes de caja negra, sin acoplar, orquestados
para ofrecer un nivel bien definido de servicio mediante la vinculación de los procesos de negocio.”
SOA es un paradigma software
- Busca crear o modificar sistemas con un enfoque en la escalabilidad y la flexibilidad
- La base para la escalabilidad/flexibilidad es la descentralización
SOA es un paradigma definido en el año 2000.
- No tiene un marco teórico totalmente establecido
- Muy flexible, si no se supervisa activamente puede terminar siendo difuso
CRM ERP
A. Ramón Molina Milla (commitea)
1.1 ¿Qué es SOA y que necesidades cubre?Introducción SOA
“SOA es un estilo de arquitectura de TI que se apoya en la orientación a servicios”
- El cambio de paradigma que establece SOA respecto a la POO se basa en los mismo principios pero con la idea
de mejorarlos ampliando su aplicación a servicios.
- Ejemplo:
- Dentro de nuestra compañía tenemos dos servidores:
- El primero contiene un aplicativo encargado de gestionar los datos de nuestros clientes.
- El segundo servidor gestiona la facturación que hacemos a nuestros clientes.
- ¿Cómo podemos realizar una integración de los dos sistemas sin recurrir a ninguna herramienta
específica de SOA?
A. Ramón Molina Milla (commitea)
CRM ERP
1.1 ¿Qué es SOA y que necesidades cubre?Introducción SOA
Posibles soluciones fuera de la arquitectura de SOA
- Generando una base de datos intermedia (stagin area)
- Intercambiando ficheros con datos en una carpeta de red compartida.
- Mediante la creación de un aplicativo que exponga y consuma los datos de cada uno de los sistemas
involucrados.
- Generando una herramienta intermedia que se encargue de leer los datos de cada uno de los sistemas
involucrados y haga de puente entre la comunicación.
A. Ramón Molina Milla (commitea)
CRM ERP
A. Ramón Molina Milla (commitea)
Ejercicio: 0Diseño de arquitectura de integración real
Ejercicio: 0Diseño de arquitectura de integración real.
Diseño de arquitectura de integración real.
Diseñar una arquitectura de integración real entre SAP y nuestro CRM:
- Usaremos SAP RFC para poder acceder a los datos.
- La RFC usada será RFC Read Table.
- Los datos han de viajar en un canal seguro.
- En caso de caída de uno de los dos servidores deberá de reintentarse la carga.
A. Ramón Molina Milla (commitea)
1.1 ¿Qué es SOA y que necesidades cubre?Introducción SOA
- Para identificar el aporte de SOA, revisemos el ejemplo con las herramientas que proporciona SOA
A. Ramón Molina Milla (commitea)
1.1 ¿Qué es SOA y que necesidades cubre?Introducción SOA
La importancia de la arquitectura SOA es que otorga la posibilidad de convertir las tecnologías en auténticos
habilitadores de negocio, aspecto que sin duda resulta fundamental para las empresas que buscan alcanzar el éxito en
un mercado cada vez más competitivo.
La arquitectura SOA permite alinear y acercar las áreas de tecnología y negocio
SOA permite el desarrollo de aplicaciones manejables y más seguras, ya que proporciona una infraestructura y
documentación común para desarrollar servicios con la posibilidad de añadir nuevas funcionalidades.
Gracias a SOA es posible minimizar la pérdida de datos, ya que ofrece seguridad y alta disponibilidad.
La arquitectura SOA permite el desarrollo de aplicación en menor tiempo y más económicas, gracias a la integración de
todos los datos de manera flexible.
SOA ayuda a mejorar la agilidad y flexibilidad de las organizaciones
CRM ERP
SOA Server
A. Ramón Molina Milla (commitea)
1.1 ¿Qué es SOA y que necesidades cubre?Introducción SOA
Desde el punto de vista corporativo:
- Mejora los procesos de toma de decisiones, debido a que los directivos podrían disponen de mayor información en menor
tiempo.
- Aumenta la productividad de los empleados.
- Se potencian las relaciones con clientes y proveedores.
Desde el punto de vista de los departamentos de TI:
- Aplicaciones más productivas y flexibles.
- Aceleración en el desarrollo de aplicaciones.
- Disminución de costes de mantenimiento de aplicaciones.
- Aplicaciones más seguras y manejables.
- Minimización del riesgo de tiempo de inactividad o pérdidas de datos.
- Mejora de la capacidad para innovar y diferenciarse.
CRM ERP
SOA Server
A. Ramón Molina Milla (commitea)
1.1 ¿Qué es SOA y que necesidades cubre?Simple Object Access Protocol
Procesos soportados: OnLine y Batch.
- Proceso Online:
Es un tipo de procesamiento que facilita y administra aplicaciones transaccionales, usualmente para entrada de datos y recuperación y procesamiento de transacciones.
Requiere un control de la transacción en curso para poder recuperar desde un punto de salvado.
Alta velocidad en la obtención de los datos.
No es recomendable usar este tipo de procesamiento si vamos a traspasar grandes cantidades de datos.
Ejemplo integración SAP mediante acceso RFC.
- Proceso Batch:
Batch processing («procesamiento por lotes»), la ejecución de una serie de programas en un computador sin la interacción humana.
Normalmente requiere desarrollo de software para instalar en la máquina origen.
Alta velocidad en el procesamiento de ficheros.
No es recomendable este tipo de procesamiento para datos en tiempo real.
Ejemplo integración SAP mediante desarrollo intermedio de generación de ficheros.
A. Ramón Molina Milla (commitea)
A. Ramón Molina Milla (commitea)
1.2 SOA Governancemonitorización y control de alto nivel para procesos de negocio
1.2 SOA Governancemonitorización y control de alto nivel para procesos de negocio
SOA Governance
- SOA Governance se compone de tres elementos indispensables:
- Registro: se trata de un catálogo con carácter evolutivo que recoge con detalle toda la información sobre los servicios disponibles en la implementación de SOA.
Este registro hace posible una mejor comunicación entre procesos de negocio y es la base para el descubrimiento de oportunidades.
- Política: más que una única norma, consiste en un conjunto de restricciones de comportamiento cuya función es garantizar que los servicios no pierden la
coherencia necesaria. Además otro de sus principales objetivos es el evitar que se produzcan conflictos entre ellos. Estas limitaciones también aseguran que se
siguen las mejores prácticas de ingeniería, se observa la normativa legal y se aplica el sentido común en las relaciones con los clientes. La aplicación de la
política que rige SOA governance ha de ser invariable, sin embargo, se pueden habilitar excepciones, cuando las circunstancias así lo requieran y se obtenga la
autorización para ello.
- Procedimiento de pruebas: su misión es garantizar la eficiencia, seguridad y rentabilidad de la solución SOA en conjunto. Para lograrlo, cuenta con un completo
programa que, desde una perspectiva integral, se ocupa de la planificación de auditorías y el diseño de técnicas para el control y seguimiento del desempeño en
base a procedimientos preestablecidos.
A. Ramón Molina Milla (commitea)
Marco de trabajo:
- Sienta las bases para que cualquier empresa pueda definir e implementar su propio modelo de forma totalmente personalizada. Hay que tener en cuenta que
no debe plantearse como una acción, sino como un proceso gradual, ya que requiere un cambio en la cultura de empresa que se ha de planificar de forma
incremental.
- No existe un único modelo único de gobierno en el ámbito de la arquitectura orientada a servicios, ya que la combinación de política, registro y procedimiento
de pruebas responde a variables como la madurez, tamaño o características del entorno de la organización.
- En cualquier caso, las siguientes cuestiones pueden servir como guía para determinar los puntos fuertes de la definición de SOA Governance que aplicará en el
negocio:
- Qué es necesario para garantizar la eficacia de SOA en la organización.
- Quién o quiénes se harán responsables de la toma de decisiones relativas a la gobernabilidad de la arquitectura.
- Cómo se emplearán los medios para realizar las tareas de seguimiento de la evolución de las decisiones de gobierno de SOA tras su aplicación.
A. Ramón Molina Milla (commitea)
1.2 SOA Governancemonitorización y control de alto nivel para procesos de negocio
SOA Governance
- Políticas (Qué):
Arquitectura de referencia
Metas y objetivos
Activos
Estándares
Administración de la configuración
A. Ramón Molina Milla (commitea)
1.2 SOA Governancemonitorización y control de alto nivel para procesos de negocio
SOA Governance
- Decisiones (Quién):
Unidades organizativas.
Partes interesadas.
Funciones y responsabilidades.
A. Ramón Molina Milla (commitea)
1.2 SOA Governancemonitorización y control de alto nivel para procesos de negocio
SOA Governance
- Procesos (Cómo):
Ciclo de vida del desarrollo de software
Diseño y tiempo de ejecución
Oracle SOA 12c
Subversion/Git/BitBucket
Sourcetree
A. Ramón Molina Milla (commitea)
1.2 SOA Governancemonitorización y control de alto nivel para procesos de negocio
A. Ramón Molina Milla (commitea)
1.3 Niveles de abstracción SOAIndicador de nivel madurez SOA
1.3 Niveles de abstracción SOAIndicador de nivel madurez SOA
Servicios Iníciales
fase en la que aun no se ha producido un alineamiento con las necesidades de negocio, simplemente se introduce SOA para cubrir algunas necesidades puntuales.
Servicios con Arquitectura
Se definen los límites que evitan un crecimiento descontrolado de los servicios de negocio implementados en la fase anterior del modelo. En esta fase crecen la
consistencia, la fiabilidad y el control de los servicios.
Servicios de Negocio y Colaborativos
Se produce una consolidación de los procesos de negocio en forma de servicios, en esta fase la tecnología converge con las necesidades de negocio. Existen dos
tipos de servicios:
Servicios de negocio donde el mundo tecnológico se pone al servicio del negocio.
Servicios colaborativos donde se definen servicios que sirven de interacción entre entidades compuestas colaboradores, partners o los mismos departamentos de
la organización.
A. Ramón Molina Milla (commitea)
Medición de los Servicios de Negocio
Se analizan los resultados de los servicios mediante el uso de métricas definidas y analizadas por usuarios de negocio y tecnológicos.
Optimización de los Servicios de Negocio
Fase en la que los servicios son analizados para encontrar puntos de mejora continua. Esta fase se lleva a cabo dentro de un ciclo que tiene como final la retirada
del servicio de negocio analizado. Es importante considerar que los servicios no sólo se analizan de manera individual sino también de forma conjunta analizando
las interacciones entre ellos.
A. Ramón Molina Milla (commitea)
1.3 Niveles de abstracción SOAIndicador de nivel madurez SOA
A. Ramón Molina Milla (commitea)
1.4 Patrones de diseño SOAPatrones en el mundo real
1.4 Patrones de diseño en SOAPatrones en el mundo real
Service Bus pattern
- Problema:
Entramos a trabajar en una nueva empresa sin ninguna tecnología definida y tras
analizar el proyecto nos decantamos por una solución basada en WS o API.
- Una vez todo está configurado de forma correcta y tenemos funcionando la
integración de todos nuestros servidores: CRM, ERP, Web, etc. Pero llega un día
donde tenemos que conectarnos con un cliente externo:
- Nuestro parque instalado se va complicando, nuevo servicios con nuevas
tecnologías, vulnerabilidades y el crecimiento de la complejidad de nuestro código
será muy alto.
json
MQ
Stagingarea
xml
A. Ramón Molina Milla (commitea)
Service Bus pattern
- Opción 1:
Cada uno de los servicios tenga expuestas diferentes interfaces para conseguir que se
puedan utilizar desde otros servicios.
Pero no podríamos controlar todos los servicios y en el mejor de los casos solamente
solventaríamos la mitad del problema, tendríamos expuestos los servicios de
múltiples formas pero seguimos necesitando desarrollar o usar extensiones para
consumir los datos expuestos. Esto es lo que SOA debe evitar.
- Opción 2:
Usar un software central (ESB) que nos asegure obtener los datos en “real time” o en
su defecto en “near real time” e implementar una solución bajo el patrón de Service
Bus y usar una infraestructura de mensajería unificada.
Nos permitiría reducir complejidad y costes desde la arquitectura y definir una
herramienta adaptativa para futuras iteraciones de nuestra compañía.
A. Ramón Molina Milla (commitea)
1.4 Patrones de diseño en SOAPatrones en el mundo real
Service Bus pattern
El patrón nos brinda las siguientes herramientas:
- Message Bus: Encargado de conectar los diferentes servicios.
- Message Router: Determina que mensajes son hay que enviar y quién es su
destinatario.
- Channer adaptor: Convierte formatos y protocolos
- Service registration: El Bus debe saber dónde encontrar los servicios para saber
cómo realizar el descubrimiento de la información.
- Message handling: Proporciona la capacidad de invocar los servicios registrados.
Usando el endpoint además de transformar los mensajes para asegurar que el
destino puede consumir la información.
- Publish/subscribe: Permite que los servicios sean notificados de nuevos mensajes
sin necesidad de estar constantemente preguntado al emisor. Y cuando
generamos un nuevo mensaje no sea necesario informar de forma única a cada
uno de los destinos.
A. Ramón Molina Milla (commitea)
1.4 Patrones de diseño en SOAPatrones en el mundo real
Secured Message pattern
- Patrón orientado al componente más fundamental de SOA.
- Los sistemas SOA por definición son:
- Abiertos
- Distribuidos
- Conectado
- Esto significa que existen muchos mensajes viajando entre el origen y el destino.
Podemos mantener el control de los mensajes dentro de los servicios y algo sobre
los consumidores, pero qué pasa con el espacio entre medias o “tierra de nadie”.
- Esta zona es muy propensa a ciberataques y la mayoría son del tipo “man in the
middle”.
- Normalmente una empresa intenta:
- Proteger la privacidad
- Proteger la integridad
- Proteger la suplantación
A. Ramón Molina Milla (commitea)
1.4 Patrones de diseño en SOAPatrones en el mundo real
Secured Message pattern
- Proteger la privacidad:
Proteger los detalles personales de los clientes cuando envía un mensaje de pedido a
un proveedor.
- Proteger la integridad:
Proteger el contenido de los mensajes para no se pueda modificar el contenido, por
ejemplo si indicamos que una factura tiene un importe de 20.000€ no se pueda
cambiar por 200€.
- Proteger la suplantación:
Proteger la identidad de la entidad que originó el mensaje, por ejemplo no queremos
que nadie pueda retirar dinero en nuestro nombre.
A. Ramón Molina Milla (commitea)
1.4 Patrones de diseño en SOAPatrones en el mundo real
Secured Message pattern
- Patrón orientado al componente más fundamental de SOA.
- Los sistemas SOA por definición son:
- Abiertos
- Distribuidos
- Conectado
- Esto significa que existen muchos mensajes viajando entre el origen y el destino.
Podemos mantener el control de los mensajes dentro de los servicios y algo sobre
los consumidores, pero qué pasa con el espacio entre medias o “tierra de nadie”.
- Esta zona es muy propensa a ciberataques y la mayoría son del tipo “man in the
middle”.
- Normalmente una empresa intenta:
- Proteger la privacidad
- Proteger la integridad
- Proteger la suplantación
A. Ramón Molina Milla (commitea)
1.4 Patrones de diseño en SOAPatrones en el mundo real
1.5 ESBEnterprise Service Bus
A. Ramón Molina Milla (commitea)
¿Qué es un ESB?
Un ESB se ocupa la capa de abstracción intermedia (middleware) entre los distintos
sistemas de una o varias organizaciones, proporcionando mecanismos de
comunicación y transformación a través de mensajería basada en estándares.
En definitiva, un ESB debe ser capaz de reemplazar todo el contacto directo entre
aplicaciones, consiguiendo que todas ellas se comuniquen a través del bus.
Los ESB transmiten y reciben mensajes basados en estándares, pero deben ser
capaces de transformar mensajes a formatos que sean reconocidos por las distintas
aplicaciones en el caso de que sea necesario, lo que se realiza a través de
adaptadores.
Además, el intercambio de mensajes debe ser independiente de la plataforma. Esto
permite al ESB integrar aplicaciones que se ejecutan en diversos sistemas operativos
o mainframes.
1.5 ESBEnterprise Service Bus
Características de un ESB
- Independiente respecto a sistemas operativos y lenguajes de programación.
- Uso de formatos reconocidos (Xml, Json, csv) como lenguaje estándar de
comunicación.
- Soporte de estándares de Servicios Web.
- Adaptadores para realizar la integración con aplicaciones.
- Sap
- LifeRay
- Modelo de seguridad estándar para autorizar, autentificar y auditar el uso del ESB.
- Transformación de mensajes mediante códigos fuente reconocidos o propios:
- ESQL
- Java
- PHP
- Validación de mensajes.
A. Ramón Molina Milla (commitea)
1.5 ESBEnterprise Service Bus
Características de un ESB
- Enrutamiento de mensajes aplicando reglas de negocio y en función del contenido
del mensaje.
- Manipulación de excepciones.
- Soporte a encolado y mantenimiento de mensajes, si las aplicaciones no están
disponibles.
- Monitorización del sistema y de la actividad de negocio (BAM).
A. Ramón Molina Milla (commitea)
1.6 ETLExtract, Transform and Loading
-
A. Ramón Molina Milla (commitea)
¿Qué es una ETL?
- Extraer, Transformar y Cargar y se refiere a los datos en una
empresa.
- ETL es el proceso que organiza el flujo de los datos entre diferentes
sistemas en una organización y aporta los métodos y herramientas
necesarias para mover datos desde múltiples fuentes a un almacén
de datos, estandarizarlos y cargarlos en otra base de datos.
- ETL forma parte de la Inteligencia Empresarial (Business
Intelligence), también llamado “Gestión de los Datos” (Data
Management).
- La idea es que una aplicación ETL lea los datos primarios de unas
bases de datos de sistemas principales, realice transformación,
validación, el proceso cualitativo, filtración y al final escriba datos en
el almacén y en este momento los datos son disponibles para
analizar por los usuarios.
Características de una ETL
- Conectividad / capacidades de Adaptación (con soporte a orígenes y destinos de
datos):
- Capacidades de entrega de datos
- Capacidades de transformación de datos
- Capacidades de Metadatos y Modelado de Datos
- Capacidades de diseño y entorno de desarrollo
- Capacidades de gestión de datos
- Adaptación a las diferentes plataformas hardware y sistemas operativos existentes
- Las operaciones y capacidades de administración
- La arquitectura y la integración
- Capacidades SOA
1.6 ETLExtract, Transform and Loading
A. Ramón Molina Milla (commitea)
A. Ramón Molina Milla (commitea)
Ejercicio: 1Diseño de estructura estándar de mensaje.
Ejercicio: 1Diseño de estructura estándar de mensaje.
Diseño de estructura estándar de mensaje.
Pensando en la reutilización y estandarización de mensajes dentro de nuestra compañía, realizar un diseño de estructura de mensaje que:
- Nos permita identificar rápidamente los datos asociados al mensaje.
- A la hora de recorrerlo pueda acceder rápido a los datos de origen.
- Pueda añadir datos relativos a la lógica de reintentos sin impactar en el contenido original del mensaje.
A. Ramón Molina Milla (commitea)
1.7 SOAPSimple Object Access Protocol
“SOAP es un formato de mensaje XML utilizado en interacciones de servicios web. Los mensajes SOAP habitualmente se envían sobre HTTP o JMS, pero se
pueden utilizar otros protocolos.”
- El uso de SOAP en un servicio web específico se describe mediante la definición WSDL.
- SOAP fue creado, entre otros, por: Microsoft, IBM Es uno de los protocolos utilizados en los servicios Web.
- Hay dos versiones de SOAP en uso común: SOAP 1.1 y SOAP 1.2.
Un mensaje SOAP DEBE codificarse utilizando XML
Un mensaje SOAP DEBE usar el namespace de SOAP Envelope
Un mensaje SOAP DEBE usar el namespace de codificación SOAP
Un mensaje SOAP NO debe contener una referencia DTD
Un mensaje SOAP NO debe contener instrucciones de procesamiento XML
A. Ramón Molina Milla (commitea)
1.7 SOAPSimple Object Access Protocol
Estructura mensaje SOAP
A. Ramón Molina Milla (commitea)
1.7 SOAPSimple Object Access Protocol
SOAP Envelope
Este envelope es requerido y define el documento XML como un mensaje SOAP.
- xmlns:soap Namespace
Siempre debe tener el valor de: "http://www.w3.org/2003/05/soap-envelope/".
Si se utiliza un espacio de nombres diferente, la aplicación genera un error y descarta el mensaje.
A. Ramón Molina Milla (commitea)
1.7 SOAPSimple Object Access Protocol
SOAP Header
El elemento de header SOAP es opcional opcional.
Contiene información específica de la aplicación (como autenticación, pago, etc.)
sobre el mensaje SOAP.
Si el elemento Header está presente, debe ser el primer hijo del elemento Envelope.
Todos los elementos hijos del elemento de encabezado deben estar
calificados para el namespace.
A. Ramón Molina Milla (commitea)
1.7 SOAPSimple Object Access Protocol
mustUnderstand
Si contiene los siguientes valores:
“0 - 1” (SOAP 1.1)
“true – false” (SOAP 1.2)
Indicará que que el receptor que procesa el Header debe reconocer el elemento.
Si el receptor no reconoce el elemento, fallará al procesar el encabezado.
A. Ramón Molina Milla (commitea)
1.7 SOAPSimple Object Access Protocol
actor (SOAP 1.1)
role (SOAP 1.2)
no todas las partes de un mensaje SOAP pueden estar destinadas al punto final,
sino que pueden estar destinadas a uno o más de los puntos finales en la ruta del mensaje.
El atributo de actor/role se utiliza para dirigir el elemento de encabezado a
un punto final específico.
Los roles pueden ser definidos por la aplicación y son designados por un URI.
Por ejemplo, http://example.com/Log podría designar la función de un nodo que realiza el registro
La especificación SOAP 1.2 define tres roles estándar además de los definidos por la aplicación:
http://www.w3.org/2003/05/soap-envelope/none
Ninguno de los nodos SOAP en la ruta del mensaje procesará el bloque de encabezado directamente.
http://www.w3.org/2003/05/soap-envelope/next
Se espera que todos los nodos SOAP en la ruta del mensaje examinen el bloque de encabezado, siempre que un nodo no haya eliminado el encabezado en la ruta del mensaje.
http://www.w3.org/2003/05/soap-envelope/ultimateReceiver
Solo se espera que el nodo receptor final examine el bloque de encabezado.
A. Ramón Molina Milla (commitea)
1.7 SOAPSimple Object Access Protocol
encodingStyle (SOAP 1.1 y SOAP 1.2)
Se utiliza para definir los tipos de datos utilizados en el documento.
Este atributo puede aparecer en cualquier elemento SOAP y se aplica al contenido
del elemento y a todos los elementos hijos.
Un mensaje SOAP no tiene codificación predeterminada.
A. Ramón Molina Milla (commitea)
1.7 SOAPSimple Object Access Protocol
relay (SOAP 1.2)
Especifica si este encabezado será retransmitido a los nodos descendentes.
A. Ramón Molina Milla (commitea)
1.7 SOAPSimple Object Access Protocol
SOAP Body
El elemento de cuerpo SOAP requerido contiene el mensaje SOAP real destinado
al punto final del mensaje.
Los elementos secundarios inmediatos del elemento Cuerpo de SOAP
pueden estar calificados para el espacio de nombres.
A. Ramón Molina Milla (commitea)
1.7 SOAPSimple Object Access Protocol
SOAP Fault
El elemento SOAP Fault opcional se usa para indicar mensajes de error.
El elemento de falla SOAP contiene errores e información de estado para un mensaje SOAP.
Si un elemento Fault está presente, debe aparecer como un elemento hijo del elemento Body.
Un elemento de fallo solo puede aparecer una vez en un mensaje SOAP.
El elemento de falla SOAP tiene los siguientes subelementos:
A. Ramón Molina Milla (commitea)
<faultcode> Un Código para identificar el error.
<faultstring> Una explicación corta humanizable del error
<faultactor> Información del causante del error.
<detail> Contiene infomración específica del error de la aplicación
1.7 SOAPSimple Object Access Protocol
SOAP ejemplo
A. Ramón Molina Milla (commitea)