Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Look up keyword
Like this
6Activity
0 of .
Results for:
No results containing your search query
P. 1
EDA y SOA

EDA y SOA

Ratings: (0)|Views: 395|Likes:
Published by Carlos Ramos Cruz
Resumenes de lectura de articulos acerca de EDA y SOA
Resumenes de lectura de articulos acerca de EDA y SOA

More info:

Published by: Carlos Ramos Cruz on Nov 24, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOCX, PDF, TXT or read online from Scribd
See more
See less

11/18/2013

pdf

text

original

 
EVENT-DRIVEN ARCHITECTURE OVERVIEW
La interacción de SOA y EDA puede darse de dos diferentes formas. La primera se da cuando un eventode interés para el negocio sucede, y esto dispara la invocación de diferentes servicios, de los más simples alos más complejos. Esto describe una interacción a menudo denominada como SOA conducido poreventos. Para otros es solo una variante de SOA.En la segunda variedad de interacción, un servicio puede generar un evento. Un evento puede ser unproblema, un problema inminente, una desviación etc. Después de generado, el evento es inmediatamentedistribuido a todas las partes interesadas en él, humanas o autómatas. Estas partes evalúan el evento y,opcionalmente, toman una acción. Esta acción conducida por evento puede implicar la invocación de unservicio, de un proceso de negocio, o cualquier otra acción de acción respecto a la información.El interés por la relación SOA-EDA se ha venido incrementando, tanto del sector empresarial, como dela comunidad que provee la tecnología. Se están considerando posibilidades para usar esta tecnología enTecnologías de la información y para agilizar los negocios. Esas parecen ser excelentes noticias.Sin embargo se debe proceder con precaución. Muchos defensores de SOA solo cuentan una parte de lahistoria, la parte de conducido por eventos. Esto podría acarrear implementaciones de arquitecturaconducida por eventos limitadas. Las empresas pueden perder oportunidades en cuanto a flujo y análisisde información en tiempo real, y procesamiento complejo de eventos.Es considerablemente prudente conocer algunos de los conceptos de básicos de eventos en medio deesta agitación provocada por la relación SOA-EDA.
Evento
es un suceso notable que acontece dentro ofuera de un negocio. Frecuentemente se utiliza el término
evento
para referirse tanto a la especificacióndel evento (
definición
), como cada ocurrencia individual del mismo (
instancia
). Para que el evento seamanipulable tanto para los suscriptores humanos y automatizados, el evento debe ser descrito (tanto ennombre y cuerpo) en términos del negocio, no en términos de datos o aplicación.Cada instancia de evento esta compuesta por una cabecera (
header 
) y un cuerpo (
body 
). Dentro del
header 
están contenidos datos que describen la instancia del evento, tales como un ID de la instancia, tipode evento, nombre de evento, numero de instancia de evento, generador de evento etc.El cuerpo del evento describe que esta pasando. Por ejemplo, si un minorista especifica un evento deumbral de inventario mínimo (mínimas existencias permitidas en un inventario), el cuerpo del eventodebe contener la información para comunicar que productos están por debajo del umbral de mínimasexistencias permitidas. El cuerpo de evento debe describir completamente el evento, de tal manera quecada parte pueda usar la información si tener que regresar a la fuente original del sistema.En una arquitectura conducida por eventos, cada suceso notable que acontece dentro o fuera delnegocio, es inmediatamente diseminado a todas las partes interesadas en ese suceso (humanas oautomatizadas). Las partes interesadas evalúan el evento y opcionalmente ejecutan una acción. Por sunaturaleza una arquitectura EDA, es bajamente acoplada y altamente distribuida. El creador (o fuente) delevento solo conoce el evento generado, no conoce los subprocesamientos del evento o las partesinteresadas.En EDA existen tres estilos generales de procesamiento de eventos, simple,
stream
y complejo. Estosestilos son comúnmente utilizados en conjunto en aplicaciones EDA maduras.Dentro del procesamiento de eventos podemos distinguir un flujo de eventos. Este inicia con lacreación del evento y culmina con la ejecución de alguna actividad por parte la capa inferior del flujo. Elflujo eventos puede ser divido en cuatro capas lógicas, el generadores de evento, canal de evento,procesamiento de evento y actividades finales conducidas por evento.
 
HOW EDA EXTENDS SOA AND WHY IT IS IMPORTANT
Existe la opinión de que EDA es SOA. También se piensa que SOA 2.0 contiene la combinación de lo mejorde SOA y EDA. Sin embargo, existe una clara diferencia entre un patrón de consulta y respuesta y el patrónde publicación-suscripción.La tendencia empresarial actual apunta a estructuras de negocio orientadas a red, con consumidores yproveedores independientes y autónomos de servicios. Todo se encamina a los negocios bajo demanda,donde los proveedores de servicios reaccionan a impulsos (eventos) del entorno.Todo esto requiere de componentes bajamente acoplados dentro de las aplicaciones, que puedan serrecortados dentro de la organización sin que esto perturbe los sistemas de apoyo de TI (Tecnologías dela Información). La naturaleza de SOA puede llegar a obstruir esta idea.Aunque claro, el uso de SOA trae beneficios, como el uso de componentes reutilizables en unadescomposición estructural bien definida, que trae consigo ahorro de tiempo en el desarrollo deaplicaciones.EDA provee flexibilidad directamente a la organización en si. Con EDA una organización puedereorganizar si afectar la construcción de aplicaciones. Cambiar la estructura de la organización sincambiar las aplicaciones es una promesa de EDA.En contraste con SOA, EDA provee un medio para obtener un bajo acoplamiento. EDA no es un patrónsíncrono de petición-respuesta, todo lo contrario, es un patrón asíncrono de publicación-suscripción. Elpublicador es completamente inconsciente de los suscriptores y viceversa.SOA es la mejor opción si se busca dar soporte a procesos de negocia con una fuerte cohesión, situacionesdonde todos los procesos se ejecutan bajo control. En cambio, si lo que se pretende es soportar unaindependencia entre fases del proceso de negocio, EDA es la mejor opción.Esforzarse en perder acoplamiento siempre es una buena idea en cada nivel de granularidad. Entoncesuna posible regla a aplicar seria: perder acoplamiento cuando sea posible, y solo usar el estilo comando-control si es requerido. Esto aplica a las dimensiones funcionales tanto de EDA como de SOA.Si se esta usando tecnologías de Servicios Web, y se combinan los puntos de desacoplamiento con unainfraestructura común, es posible conectar fácilmente sistemas heterogéneos. Los componentes de laaplicación ya no están directamente acoplados, pero están conectadas por puntos de desacoplamiento (loseventos).Para implementar EDA con tecnologías de Servicios Web, una infraestructura de mensajes de consultaSOAP es requerida. Esto no sucede en una implementación de Servicios Web basados en SOAP. Lasimplementaciones de EDA y SOA deben ser consideradas en el contexto de la Gestión de Proceso deNegocio (BPM).Lo mas importante en cuanto a SOA y EDA es distinguir entre ambos patrones y pensar sobre lo que esmas apropiado y eficiente en un contexto especifico.

Activity (6)

You've already reviewed this. Edit your review.
1 thousand reads
1 hundred reads
Gladys Hada liked this
Sabrina Villa liked this

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->