Soa 2

PUNTOS CLAVE EN SOA
MI.LIC. Jos Manuel Fuentes

Info.manuel.fuentes@gmail.com
SOA SERVICIOS- PRINCIPIOS BSICOS.
problema
Un
con el que nos podemos encontrar a la hora de
construir una aplicacin SOA es si la aplicacin construida realmente es una
aplicacin "SOA Compliant, para comprobar si una aplicacin lo es, la mejor
forma de hacerlo es chequeando que la
los
aplicacin cumpla con
Principios de la Orientacin a Servicios.
Segn Thomas
Erl estos principios son:
1.- Los Servicios deben ser reusables.

2.- Los Servicios deben proporcionar un contrato formal.
3.- Los Servicios deben tener bajo acoplamiento.
4.- Los Servicios deben permitir la composicin.
5.- Los Servicios deben de ser autnomos.
6.- Los Servicios no deben tener estado.
7.- Los Servicios deben poder ser descubiertos.
1.- Los Servicios deben ser reusables.

Todo
servicio debe ser
reutilizacin
diseado y construido
pensando en su
dentro de la misma aplicacin, dentro del dominio de

aplicaciones de la empresa o incluso dentro del dominio pblico para su uso masivo.
2.- Los Servicios deben proporcionar un contrato formal.

Todo servicio desarrollado, debe proporcionar un contrato
en el cual figuren, el
nombre del servicio, su forma de acceso, las funcionales que ofrece, los datos de entrada
de cada una de las funcionalidades y los datos de salida, de esta manera, todo
consumidor del servicio, acceder a este mediante el contrato, logrando as

la independencia entre el consumidor y la implementacin del propio servicio.
3.- Los Servicios deben tener bajo acoplamiento.

Es decir, que los servicios tienen que ser
independientes
los unos de
los otros, para lograr ese bajo acoplamiento, lo que se har es que cada vez que se
vaya a ejecutar un servicio, se acceder a l a travs del contrato, logrando
as la independencia entre el servicio que se va a ejecutar y el que lo llama.
4.- Los Servicios deben permitir la composicin.

Todo
servicio debe ser
construido
de tal manera que pueda ser utilizado
servicios genricos
para construir
de ms alto nivel, el cual estar
compuesto de servicios de ms bajo nivel, los Servicios Web, esto se lograr mediante
el uso de los
protocolos para orquestacin(WS-BPEL) y coreografa (WS-CDL)
5.- Los Servicios deben de ser autnomos.

Todo Servicio debe tener su propio
entorno
de ejecucin, de esta manera el
servicio es totalmente independiente y nos podemos asegurar que as

podr ser reutilizable desde el punto de vista de la plataforma de ejecucin.
6.- Los Servicios no deben tener estado.

Un servicio no debe guardar ningn tipo de informacin, esto es
as porque una aplicacin est formada por un
implica que
si un servicio
conjunto de servicios,
lo que
almacena algn tipo de informacin, se pueden
producir problemas de inconsistencia de datos, la solucin, es que un servicio

slo contenga lgica, y que toda informacin est almacenada en algn sistema de
informacin sea del tipo que sea.
7.- Los Servicios deben poder ser descubiertos.

Todo servicio debe poder
ser descubierto de alguna forma para que
pueda ser utilizado, consiguiendo as evitar la creacin accidental de servicios que

proporcionen las mismas funcionalidades, en el caso de los Servicios Web, el
descubrimiento se lograr publicando los interfaces de los servicios en registros UDDI.
Cuando se desarrollan
aplicaciones SOA es muy til y necesario
tener en cuenta siempre estos principios, ya que nos van a dar las pautas
necesarias para tomar ciertas decisiones de diseo complejas y como se habr
una caracterstica
podido observar,
muy importante de los
Principios de la Orientacin a Servicios, es que todos tiene un algo degrado de
interrelacin.

Independencia con terceros
Contrato Formal
Evita Duplicacin
Genera escalabilidad
Descubrimiento
Bajo Acoplamiento
Reusabilidad
Sin Estado
Composicin
Evita Inconsistencia
Crear nuevo servicios
Autonoma
Independencia entorno
Modelo Genrico de SOA

El modelo genrico de SOA est compuesto por
Funcionalidades.
Transporte
Protocolo de Comunicacin
Descripcin del Servicio
Los Servicio
Proceso de Negocio
Registro de Servicios
2 grandes rubros:
Calidad de Servicio.
Polticas
Seguridad
Transacciones
Gestin
Funcionalidades.
Transporte
Mecanismo utilizado para trasladar
el proveedor del servicio, y viceversa.
las peticiones desde el cliente, hasta
Protocolo de comunicacin
Es el sistema
de comunicacin entre el cliente y el proveedor de servicios.
Funcionalidades.
Descripcin del servicio
describir qu servicio
Es un esquema utilizado para

es, como se le
puede invocar, y cules son los datos necesarios para realizar su invocacin.
Servicio
Es la
implementacin del servicio.
Funcionalidades.
Proceso de negocio
coleccin de servicios
Es una
, invocados en una determinada secuencia,
con un conjunto particular de reglas para satisfaces un requisito de negocio.
Registro de servicios
repositorio de servicios
Es un
y datos, usado por los proveedores de
servicio, para publicar los servicios, y para los clientes, donde buscarlos.
Polticas
conjunto de reglas
Son un
bajo las cuales, un proveedor de servicio hace
que el servicio est disponible para los clientes (WS-Policy)
Seguridad
conjunto de reglas
Son un
que podran ser aplicadas en la identificacin,
autorizacin y control de acceso a los servicios, por parte del cliente (WS-Security).
Transaccin
Conjunto de atributos
que podran ser aplicados sobre un grupo de

servicios para devolver un conjunto de datos consistentes (WS-Transaction, WSCoordination).
Gestin
Conjunto de atributos
que podran ser aplicados para gestionar los

servicios proporcionados (WS-Manageability).
Service Cummunication Protocol

SOAP
Transport
HTTP JMS SMTP - WSMessaging
Management
WS-Manageability
Service Description
WSDL - XML
Transaction
WS Coordination Transaction
Service
Policy
WS-Policy
Servicie Registry
UDDI-WS Inspection
Busines Process
BPEL - BPM - WS
Securuty
WS Security WS Trust
Quality of Service
Function
SOA SERVICIOS- Tipos.
Qu tipos de servicios existen en SOA?
todo desarrollador a la hora
Esta pregunta se la hace

de enfrentarse a una aplicacin SOA.
varias clasificaciones
Existen
dependiendo de su autor, las ms
simples y las ms prctica para tener una visin general de una aplicacin SOA
son.
Existen bsicamente tres tipos de servicios, divididos en

base a sus funcionalidades:
Servicios controladores.
Servicios de negocio.
Servicios de utilidad.
Servicios Controladores.
Son los encargados de recibir las peticiones de los clientes y
realizar las llamadas necesarias a otros servicios en la secuencia adecuada
para devolver una respuesta, es decir, son los servicios encargados de coordinar al
resto de servicios.
Servicios Controladores.
Si analizamos bien este tipo de servicios, nos daremos cuenta de que
procesos de negocio que queremos implementar, ya que
un proceso de negocio no es ms que un conjunto de tareas ejecutadas
representan a los
en una determinada secuencia para obtener un objetivo.
Servicios de Negocio.
Son los servicios que representan una tarea de negocio, y que forman
parte de un proceso de negocio, este tipo de servicios suelen ser poco
reutilizables porque estn orientados a resolver una tarea muy puntual.
Servicios de Utilidad.
Son aquellos servicios que se caracterizan por representar
una
tarea
altamente reutilizable,
tecnolgicos
se les denominan servicios

encargados de encapsular una determinada tecnologa y por tanto
altamente reutilizables como lo pueden ser servicios de acceso a bases de

datos relacionales.

Clientes
Peticiones/Respuestas
Servicios
Controladores
Servicios de
Negocio
Servicios de
Utilidad
SOA SERVICIOS- Contratos WSDL.
Al utilizar un
Servicio Web
nacen algunas interrogantes, Cmo utilizarlo?
Qu datos deben enviarse? Qu datos va a

Cules son las funcionalidades que ofrece el Servicio?
esta informacin
recibir?
Toda
que se necesita para utilizar el servicio,
debera estar en algn lugar, ya que es imprescindible para acceder al Servicio.
Desde el
punto de vista de los negocios, todas las respuestas a
las preguntas anteriores se definen en
cliente
el contrato, que se establece entre el
que es el que usara el servicio y el
implementa, ya que indica las pautas
proveedor que es quien lo
a seguir por cada una de las partes.
Service Description Language WSDL

es el lenguaje estndar definido por el W3C para describir un Servicio
Tcnicamente es un, Web
Web y crear ese contrato, No es un documento obligatorio, pero es muy importante

que sea estndar ya que as se podr acceder de manera dinmica a los Servicios.
Es muy
importante entender los WSDL porque es la parte fundamental
para desarrollar Servicios Web, No es necesario saber construir un documento

WSDL ya que lo construyen automticamente las herramientas de desarrollo, pero
s entenderlo.
WSDL es un
lenguaje basado en XML
interfaz
de los servicios, un
claramente diferenciadas:
Parte Abstracta.
Parte Concreta.
documento WSDL
creado para definir el
est divido en dos partes

<definitions>
WSDL
1.1
Descripcin
Abstracta
Descripcin
Concreta
<types>
</types>
<message>
</message>
<portTypes>
</portTypes>
<binding>
</binding>
</definitions>
<service>
<port
</service>
<definitions></definitions>
Especifica los espacios de nombres para el documento WSDL , en XML, SOAP,
etc un espacio de nombres nico ser capturado de la definicin de servicio , que se utiliza
para definir los espacios de nombres WSDL, El formato de este espacio de nombres es la
siguiente:
Ejemplo.
http://xmlns.oracle.com/Enterprise/<App nombre> / < Nombre de servicio >
distinguir entre elementos
Esto permite
que tienen el mismo nombre,
pero diferentes propsitos y tal vez diferentes orgenes, XML hace referencia a un espacio de
nombres mediante un identificador URI
Parte Abstracta.
types
estructuras de datos
Esta etiqueta define las

que se utilizarn para
construir los mensajes de peticin, como de respuesta, estas estructuras de datos
pueden construirse con
XML
cualquier lenguaje, pero lo ms normal es hacerlo
con
, este apartado es el ms complicado sobre todo cuando tengamos que
construir estructuras de datos muy complejas.
Parte Abstracta.
message
Describe
los mensajes que se van a intercambiar entre el
Cliente y el
Servicio Web, un mensaje puede estar dividido en varias partes, por ejemplo,
si en un mensaje queremos enviar datos y archivos.
Parte Abstracta.
portType
Define el
conjunto de operaciones
que soporta el Servicio Web, una
grupo de mensajes
operacin no es ms que un
que sern
intercambiados, cada operacin puede enviar o recibir al menos un mensaje cada
vez.
Parte Abstracta.
portType
Define de
4 operaciones de intercambio:
Unidireccional
Peticin / Respuesta
Solicitud / Respuesta
Notificacin
Parte Abstracta.
portType
Unidireccional, El servicio recibe un mensaje y no genera
ninguna respuesta.
Parte Abstracta.
portType
Peticin/Respuesta,
responde con otro.
El Servicio recibe un mensaje y
Parte Abstracta.
portType
Solicitud/Respuesta, El
recibe una respuesta.
No soportada
Servicio enva un mensaje y
Parte Abstracta.
portType
Notificacin, El
respuesta.
No soportada
Servicio enva un mensaje, y no recibe
Parte Concreta.
binding
Describe como
formatear los mensajes
Servicio determinado,
WSDL no define
para ello utilizan estndares para
para interactuar con un
un estndar para formatear mensajes,
el intercambiar SOAP, HTTP, MIME, etc.
Parte Concreta.
services
Este elemento indica
donde se encuentra el Servicio
usando
una etiqueta, cada etiqueta define el formato de los mensajes, y la direccin

donde se encuentra el servicio que acepta mensajes en ese formato.

WSDL Ejemplo

<description>
WSDL
2.0
Descripcin
Abstracta
Descripcin
Concreta
<types>
</types>
<interface>
</ interface >
<binding>
</binding>
</description>
<service>
<endpoint
</service>
<description></description>
Especifica los espacios de nombres para el documento WSDL , en XML, SOAP,
etc un espacio de nombres nico ser capturado de la definicin de servicio , que se utiliza
para definir los espacios de nombres WSDL, El formato de este espacio de nombres es la
siguiente:
Ejemplo.
http://xmlns.oracle.com/Enterprise/<App nombre> / < Nombre de servicio >
distinguir entre elementos
Esto permite
que tienen el mismo nombre,
pero diferentes propsitos y tal vez diferentes orgenes, XML hace referencia a un espacio de
nombres mediante un identificador URI
Parte Abstracta.
types
estructuras de datos
Esta etiqueta define las

que se utilizarn para
construir los mensajes de peticin, como de respuesta, estas estructuras de datos
pueden construirse con
XML
cualquier lenguaje, pero lo ms normal es hacerlo
con
, este apartado es el ms complicado sobre todo cuando tengamos que
construir estructuras de datos muy complejas.
Parte Abstracta.
interface
WSDL 2.0 cuenta con una <interface> elemento que reemplaza el <portType> en WSDL
1.1, a diferencia del <portType> en WSDL 1.1 , las operaciones dentro de la
<interface> no apuntan a los mensajes , sino que apuntan a los elementos
de esquema contenidos en el <types>.
Para ms Referencia.
http://www.ibm.com/developerworks/ssa/webservices/tutorials/ws-understand-web-services2/
https://docs.oracle.com/cd/E41633_01/pt853pbh1/eng/pt/tibr/concept_UnderstandingProvidingWSDLDoc
uments-076201.html
SOA Elementos Necesarios.

En las Arquitecturas
servicio. pero
arquitectura SOA.
Orientadas a Servicios, el elemento bsico es el

nicamente con este concepto, no podramos disear una
4Son los elementos esenciales y necesarios para la construccin de

una Arquitectura Orientada a Servicios:
Operacin.
Servicio.
Mensaje.
Proceso de negocio.
1Elemento, Operacin.
Es la unidad
de trabajo o procesamiento en una arquitectura SOA.
2Elemento, Servicio.
Es un contenedor de lgica, estar compuesto por un conjunto de
operaciones, las cuales las ofrecer a sus usuarios.
3Elemento, Mensaje.
Para poder ejecutar una determinada operacin, es necesario un
conjunto de datos de entrada, a su vez, una vez ejecutada la operacin, esta
devolver un resultado.
mensajes
Los
de salida.
son los encargados de
encapsular esos datos de entrada y
4Elemento, Proceso de negocio.

Son un
conjunto de operaciones ejecutadas en una determinada
secuencia intercambiando
una determinada tarea.
mensajes entre ellas con el objetivo de realizar
Actividad.
Esquematice los 4 elementos esenciales para SOA
4Son los elementos esenciales y necesarios para la construccin de

una Arquitectura Orientada a Servicios:
Operacin.
Servicio.
Mensaje.
Proceso de negocio.

Aplicacin SOA
Proceso de Negocio 1
Servicio
Operacin
Mensajes
Operacin N
Servicio
Operacin
Mensajes
Operacin N
Servicio
Operacin
Operacin N
Proceso de Negocio 2
Servicio
Operacin
Servicio
Operacin
Mensajes
Operacin N
Operacin N
Proceso de Negocio N
Servicio
Operacin
Operacin N
Mensajes
Servicio
Operacin
Operacin N
Mensajes
Servicio
Operacin
Operacin N
En Resumen
Una aplicacin SOA estar formada por un conjunto de procesos de
negocio, a su vez esos procesos de negocio estarn compuestos por aquellos
que son servicios que proporcionan las operaciones que se necesitan
ejecutar para que
el proceso de negocio llegue a buen trmino.
Por ltimo para ejecutar esas operaciones es necesario el

necesarios mediante los correspondientes mensajes.
envo de los datos
SOA ESB, Bus de Servicios Empresariales.
La
adopcin
de una arquitectura basada en servicios
requiere
de una
comunicaciones escalable y segura entre los

componentes, esto es lo que se conoce como Enterprise Service Bus.
infraestructura de

Estructura.
El
Bus de Servicios Empresariales
a la infraestructura de transporte de
y los servicios de los que dispone la empresa.
es el concepto que se refiere
mensajes
entre el motor de procesos
El bus requiere una infraestructura slida que ofrezca a los desarrolladores

la seguridad de que los mensajes sean entregados siempre, independientemente de los
problemas que puedan afectar a un servicio determinado en un momento
dado.
seguridad total
El bus debe ofrecer

de infraestructura de la empresa.
El bus debe ser
y conectividad hacia todo el software
totalmente monitoreadle
porque se convierte en la
columna vertebral de todos los sistemas de la empresa.
El
objetivo primordial
entre los dos
del BUS es lograr el
desacoplamiento
extremos de la comunicacin. Cmo se logra esto? Pues
interponiendo otro elemento un
tercero
partes, como si fuera un intermediario.
entre la comunicacin de las dos
Cundo necesitamos un ESB?

Cuando tenemos numerosos puntos de integracin.
Necesidad de crecimiento
de la arquitectura.
Existe ms de un protocolo de comunicacin.
Requerimientos de mediacin entre dos extremos, transformacin de los datos
por ejemplo, escalabilidad, gestin, monitoreo, transformacin y seguridad.
Requerimientos que apuntan al uso de un ESB:
Procesamiento de mensajes
Complejidad de transformacin.
Ruteo de mensaje basado en contenido.
Transformacin o mediacin de protocolo.
Alto Rendimiento. Grandes volmenes de mensajes.
Mensajes de gran tamao.
Doscientos mil mensajes por da.
Requerimientos orientados a datos.
Para consultar ms patrones como:

Entity Endpoint
Uniform Contract
Endpoint Redirection
Content Negotiation
Idempotent Capability
En el portal les deje los libros de diseo de patrones.
SOA Estrategia de Adopcin.
4Fases para una Adopcin de SOA. Depende de

cada Autor.
Fase 1, Organizacin y estrategia.
Fase 2, Implantaciones tcticas.
Fase 3, Plataforma SOA.
Fase 4. SOA industrializado.
1Fase, Organizacin y estrategia.

Esta es la fase de toma de contacto con SOA, donde la compaa
se centrar en la evaluacin de la situacin actual y en el plan para definir el
alcance de la transformacin hacia SOA, asegurando una

base slida de servicios y una
beneficios de SOA.
hoja de ruta
para obtener todos los

Tradicionalmente, esta fase se compone de cuatro
tareas secuenciales:
Comprensin de la estrategia de negocio y procesos.
Anlisis de la situacin actual de los sistemas.
Definicin del modelo objetivo de referencia SOA.
Creacin de la hoja de ruta SOA.

Tradicionalmente, esta fase se compone de cuatro
tareas secuenciales:
Comprensin de la estrategia de negocio y procesos.
Anlisis de la situacin actual de los sistemas.
Definicin del modelo objetivo de referencia SOA.
Creacin de la hoja de ruta SOA.

Adicionalmente, en esta fase se pueden realizar
algunos pilotos con los proveedores de infraestructura
y software.
2Fase, Implantaciones tcticas.

En esta fase se realizarn las primeras implantaciones tcticas de
SOA, con el objetivo de que sirva tambin para familiarizarse tanto con la
tecnologa
usada como con los procedimientos de gobierno y
organizacin.
Adems, durante la fase 2 se crear la infraestructura base de SOA y se
iniciar el
catlogo de procesos y servicios.
2Fase, Implantaciones tcticas.

Es recomendable que en la fase 2 se elijan las aplicaciones con un alto
componente de workflow orientadas a alcanzar las polticas del negocio para
obtener el mximo beneficio de la tecnologa SOA y permitir probar
dicha tecnologa en su mxima extensin.
Tambin en esta fase se suele iniciar el proceso de
identificacin y
reutilizacin de los servicios existentes, as como su publicacin en el

catlogo.
3Fase, Plataforma SOA.

En la fase 3 se consolidar la
implantacin
de SOA, tanto desde el
tecnolgico como desde el punto de vista

organizativo y de gobierno, en esta fase, adems de consolidar
la infraestructura base de SOA, se profundizar en la monitorizacin
punto de vista
de procesos y se dispondr de un catlogo operativo de procesos y servicios,

desde el punto de vista de negocio se realizar la implantacin de los
servicios/procesos estructurales.
4Fase, SOA industrializado.

Durante la ltima fase se obtendrn
todos los beneficios
de la
filosofa SOA, se alcanzar un alto grado de reutilizacin de

servicios y se impondr el modelo de factora SOA, donde la organizacin
se centrar en disear los procesos, y tanto la construccin de los
mismos como los servicios requeridos que no existan en el catlogo se
externalizarn en factoras.

4Fase Implantacin SOA.
Ejercicio SOA
Realizar un diagrama en el cual exponga, componga y consuma servicios para
alcanzar los objetivos del negocio, teniendo en cuenta la granularidad de los
servicios y teniendo en cuenta la progresividad en los servicios.
Una empresa que se dedica a la prestacin de servicios legales, desea crear canales de servicios
para poder realizar servicios legales en lnea y arrendar sus canales a bufet de abogados, la
dificultad que enfrenta es que depende de 4 aplicaciones legadas y 1 por arrendamiento
internacional, como lo son manejo de clientes y expedientes, manejo de servicios legales, manejo
de sentencias, logstica de notificaciones y asistencias a tribunales, el servicio de arrendamiento lo
utiliza para la consulta de extradiciones, notificaciones y asistencias a ciudadanos en el extranjero.
Disee 5 funciones de negocio desacopladas para poder implementar este el servicio en la web y
como prestar los servicios a terceros y acplelas en 2 servicios generales y junto a los servicios
granulados para alcanzar los objetivos del negocio, tambin tenga en cuenta la generacin de
contratos de utilizacin y formas de cobro para los servicios de arrendamiento.
SOA Recomendaciones Generales.
Una adopcin SOA tiene un impacto en toda la organizacin,

por lo que todas las partes debern estar involucradas y
debe haber un alto grado de compromiso entre ellas.
Abordar la implantacin SOA por fases y de forma

iterativa para ajustar la nueva tecnologa, organizacin y
procedimientos de trabajo.
Definir y poner en marcha la funcin de gobierno
al inicio
de la adopcin y en especial el catlogo de servicios y

procesos.
No todos los problemas sern resueltos va SOA, se

deben seleccionar las oportunidades adecuadas para demostrar
como SOA puede mejorar el negocio.
Invertir esfuerzo y tiempo en explicar el nuevo modelo

de desarrollo orientado a procesos con cursos, ejemplos de
best practices, alta supervisin, etc. El equipo de implementacin
de SOA debe contar con personas que conozcan en
profundidad el negocio y sus procesos, as como las tcnicas y
capacidades de SOA que permitan definir procesos que
implementen la estrategia con mayor eficacia.
Tener en cuenta los desarrollos

posibilidad de
actuales y analizar la
reutilizar los desarrollos existentes, para

orientarlos a servicios.
mayor alineamiento
Fomentar un
entre el negocio y
la tecnologa, conseguir una colaboracin efectiva entre el
departamento de tecnologa y las unidades de negocio
siempre ha sido un reto, pero constituye un factor absolutamente
imprescindible para garantizar la eficacia de la arquitectura
SOA.
SOA Recomendaciones Tecnolgicas.
Mantenerse alineado con la evolucin de los estndares,

productos y herramientas SOA del mercado, No reinventar
creer
la rueda pero tampoco

estrictamente las
recomendaciones del proveedor.
Tener en cuenta que el acoplamiento ligero (loose coupling)

proporcionado por SOA, puede tener como contrapartida un coste
en el rendimiento global, durante las primeras fases es
fundamental una constante revisin de los niveles de rendimiento
para mantenerlo en niveles razonables.
Realizar un correcto uso de las herramientas
de BPM y de
los diferentes motores de orquestacin, como lo son

orquestador asncrono, orquestador sncrono y micro-orquestador.
Planificar
la seguridad y gobierno de los

servicios desde el inicio.
SOA Recomendaciones Del Negocio.
Se requiere un cambio de enfoque y considerar el proceso

como el foco principal del diseo y desarrollo de los sistemas, este
nuevo enfoque es ms complejo de lo que parece, por lo que
es recomendable trabajar sobre un framework de procesos (BPM,
COBIT, ITIL, SaaS) y servicios de la industria que gue el
desarrollo.
SOA Recomendaciones Del Negocio.
Es recomendable comenzar con una determinada rea,

identificando sus necesidades de servicios y disendolos de
forma que sean reutilizables por otras reas, pero sin incluir
inicialmente a toda la organizacin para evitar tener mltiples
requerimientos/responsables sobre un mismo servicio.
(evitar la parlisis del anlisis)

Soa 2

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Soa 2

Hochgeladen von

Copyright:

Verfügbare Formate

PUNTOS CLAVE EN SOA

MI.LIC. Jos Manuel Fuentes

SOA SERVICIOS- PRINCIPIOS BSICOS.

aplicacin cumpla con

Principios de la Orientacin a Servicios.

SOA SERVICIOS- PRINCIPIOS BSICOS.

Erl estos principios son:

1.- Los Servicios deben ser reusables.

SOA SERVICIOS- PRINCIPIOS BSICOS.

1.- Los Servicios deben ser reusables.

servicio debe ser

dentro de la misma aplicacin, dentro del dominio de

SOA SERVICIOS- PRINCIPIOS BSICOS.

2.- Los Servicios deben proporcionar un contrato formal.

consumidor del servicio, acceder a este mediante el contrato, logrando as

SOA SERVICIOS- PRINCIPIOS BSICOS.

3.- Los Servicios deben tener bajo acoplamiento.

SOA SERVICIOS- PRINCIPIOS BSICOS.

4.- Los Servicios deben permitir la composicin.

servicio debe ser

de tal manera que pueda ser utilizado

protocolos para orquestacin(WS-BPEL) y coreografa (WS-CDL)

SOA SERVICIOS- PRINCIPIOS BSICOS.

5.- Los Servicios deben de ser autnomos.

de ejecucin, de esta manera el

servicio es totalmente independiente y nos podemos asegurar que as

SOA SERVICIOS- PRINCIPIOS BSICOS.

6.- Los Servicios no deben tener estado.

almacena algn tipo de informacin, se pueden

producir problemas de inconsistencia de datos, la solucin, es que un servicio

SOA SERVICIOS- PRINCIPIOS BSICOS.

7.- Los Servicios deben poder ser descubiertos.

ser descubierto de alguna forma para que

pueda ser utilizado, consiguiendo as evitar la creacin accidental de servicios que

SOA SERVICIOS- PRINCIPIOS BSICOS.

aplicaciones SOA es muy til y necesario

SOA SERVICIOS- PRINCIPIOS BSICOS.

Crear nuevo servicios

Modelo Genrico de SOA

Modelo Genrico de SOA

las peticiones desde el cliente, hasta

de comunicacin entre el cliente y el proveedor de servicios.

Modelo Genrico de SOA

Es un esquema utilizado para

implementacin del servicio.

Modelo Genrico de SOA

Modelo Genrico de SOA

Modelo Genrico de SOA

que podran ser aplicados sobre un grupo de

que podran ser aplicados para gestionar los

Modelo Genrico de SOA

Service Cummunication Protocol

SOA SERVICIOS- Tipos.

Qu tipos de servicios existen en SOA?

todo desarrollador a la hora

Esta pregunta se la hace

SOA SERVICIOS- Tipos.

Existen bsicamente tres tipos de servicios, divididos en

SOA SERVICIOS- Tipos.

SOA SERVICIOS- Tipos.

en una determinada secuencia para obtener un objetivo.

SOA SERVICIOS- Tipos.

SOA SERVICIOS- Tipos.