Вы находитесь на странице: 1из 89

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.

SOA SERVICIOS- PRINCIPIOS BSICOS.

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.

SOA SERVICIOS- PRINCIPIOS BSICOS.

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.

SOA SERVICIOS- PRINCIPIOS BSICOS.

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.

SOA SERVICIOS- PRINCIPIOS BSICOS.

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.

SOA SERVICIOS- PRINCIPIOS BSICOS.

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)

SOA SERVICIOS- PRINCIPIOS BSICOS.

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.

SOA SERVICIOS- PRINCIPIOS BSICOS.

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.

SOA SERVICIOS- PRINCIPIOS BSICOS.

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.

SOA SERVICIOS- PRINCIPIOS BSICOS.

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.

SOA SERVICIOS- PRINCIPIOS BSICOS.


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

Modelo Genrico de SOA

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.

Modelo Genrico de SOA

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.

Modelo Genrico de SOA

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.

Modelo Genrico de SOA

Calidad de Servicio.
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).

Modelo Genrico de SOA

Calidad de Servicio.
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).

Modelo Genrico de SOA

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.

SOA SERVICIOS- Tipos.

Existen bsicamente tres tipos de servicios, divididos en


base a sus funcionalidades:
Servicios controladores.
Servicios de negocio.
Servicios de utilidad.

SOA SERVICIOS- Tipos.

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.

SOA SERVICIOS- Tipos.

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.

SOA SERVICIOS- Tipos.

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.

SOA SERVICIOS- Tipos.

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.

SOA SERVICIOS- Tipos.


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.

SOA SERVICIOS- Contratos WSDL.

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.

SOA SERVICIOS- Contratos WSDL.

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.

SOA SERVICIOS- Contratos WSDL.

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.

SOA SERVICIOS- Contratos WSDL.

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

SOA SERVICIOS- Contratos WSDL.


<definitions>

WSDL

1.1
Descripcin
Abstracta

Descripcin
Concreta

<types>

</types>

<message>

</message>

<portTypes>

</portTypes>

<binding>

</binding>
</definitions>

<service>
<port
</service>

SOA SERVICIOS- Contratos WSDL.

<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

SOA SERVICIOS- Contratos WSDL.

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.

SOA SERVICIOS- Contratos WSDL.

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.

SOA SERVICIOS- Contratos WSDL.

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.

SOA SERVICIOS- Contratos WSDL.

Parte Abstracta.
portType
Define de

4 operaciones de intercambio:

Unidireccional
Peticin / Respuesta
Solicitud / Respuesta
Notificacin

SOA SERVICIOS- Contratos WSDL.

Parte Abstracta.
portType
Unidireccional, El servicio recibe un mensaje y no genera
ninguna respuesta.

SOA SERVICIOS- Contratos WSDL.

Parte Abstracta.
portType
Peticin/Respuesta,
responde con otro.

El Servicio recibe un mensaje y

SOA SERVICIOS- Contratos WSDL.

Parte Abstracta.
portType
Solicitud/Respuesta, El
recibe una respuesta.
No soportada

Servicio enva un mensaje y

SOA SERVICIOS- Contratos WSDL.

Parte Abstracta.
portType
Notificacin, El
respuesta.
No soportada

Servicio enva un mensaje, y no recibe

SOA SERVICIOS- Contratos WSDL.

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.

SOA SERVICIOS- Contratos WSDL.

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.

SOA SERVICIOS- Contratos WSDL.


WSDL Ejemplo

SOA SERVICIOS- Contratos WSDL.


<description>

WSDL

2.0
Descripcin
Abstracta

Descripcin
Concreta

<types>

</types>

<interface>

</ interface >

<binding>

</binding>
</description>

<service>
<endpoint
</service>

SOA SERVICIOS- Contratos WSDL.

<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

SOA SERVICIOS- Contratos WSDL.

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.

SOA SERVICIOS- Contratos WSDL.

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.

SOA Elementos Necesarios.

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.

SOA Elementos Necesarios.

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

SOA Elementos Necesarios.

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

SOA Elementos Necesarios.

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.

SOA Elementos Necesarios.


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

SOA Elementos Necesarios.

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

SOA ESB, Bus de Servicios Empresariales.


Estructura.

SOA ESB, Bus de Servicios Empresariales.

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.

SOA ESB, Bus de Servicios Empresariales.

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.

SOA ESB, Bus de Servicios Empresariales.

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

SOA ESB, Bus de Servicios Empresariales.

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.

SOA ESB, Bus de Servicios Empresariales.

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.

SOA ESB, Bus de Servicios Empresariales.

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.

SOA Estrategia de Adopcin.

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

SOA Estrategia de Adopcin.

1Fase, Organizacin y estrategia.


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.

SOA Estrategia de Adopcin.

1Fase, Organizacin y estrategia.


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.

SOA Estrategia de Adopcin.

1Fase, Organizacin y estrategia.


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

SOA Estrategia de Adopcin.

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.

SOA Estrategia de Adopcin.

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.

SOA Estrategia de Adopcin.

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.

SOA Estrategia de Adopcin.

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.

SOA Estrategia de Adopcin.


4Fase Implantacin SOA.

SOA Estrategia de Adopcin.

SOA Estrategia de Adopcin.

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.

SOA Recomendaciones Generales.

Abordar la implantacin SOA por fases y de forma


iterativa para ajustar la nueva tecnologa, organizacin y
procedimientos de trabajo.

SOA Recomendaciones Generales.

Definir y poner en marcha la funcin de gobierno

al inicio

de la adopcin y en especial el catlogo de servicios y


procesos.

SOA Recomendaciones Generales.

No todos los problemas sern resueltos va SOA, se


deben seleccionar las oportunidades adecuadas para demostrar
como SOA puede mejorar el negocio.

SOA Recomendaciones Generales.

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.

SOA Recomendaciones Generales.

Tener en cuenta los desarrollos


posibilidad de

actuales y analizar la

reutilizar los desarrollos existentes, para


orientarlos a servicios.

SOA Recomendaciones Generales.

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.

SOA Recomendaciones Tecnolgicas.

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.

SOA Recomendaciones Tecnolgicas.

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.

SOA Recomendaciones Tecnolgicas.

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)