Arquitecturas de Desarrollo

8/7/2019 Arquitecturas de Desarrollo

1/10

1 | P g i n a

ARQUITECTURAS DE DESARROLLO

ABSTRACT

Existen 3 arquitecturas que se especializan en los servicios para una aplicacin: SOA, EDA y ESB.Cada una tiene sus ventajas y sus desventajas. SOA define la utilizacin de los servicios para darsoporte al negocio. EDA ofrece varias caractersticas pero es ms un complemento paraarquitecturas como SOA que una arquitectura independiente. ESB combina la arquitectura desoftware a travs de un sistema de mensajes de bus y que puede responder a eventos. De estostres, el mejor es el SOA.

Por Ramos Hernndez Rosa Mara

INTRODUCCIN

Es la vista conceptual de la estructura de laarquitectura de una aplicacin. Todaaplicacin contiene cdigo de presentacin,cdigo de procesamiento de datos y cdigode almacenamiento de datos.

La arquitectura de las aplicaciones difieresegn como est distribuido este cdigo. Lameta es unificar las aplicaciones para PC, lasaplicaciones cliente / servidor y lasaplicaciones basadas en la Web, lo cual esposible para aplicaciones de cualquier

tamao.

En nuestros das mucha informacinimportante est almacenada en aplicacionescomo sistemas de correo electrnico y comouna serie de manejadores e interfacesdiseadas para poder de alguna formaconseguir acceder a este tipo dealmacenamientos y ms an a datos comoarchivos de formato especiales, datos deposicin geo-espacial, datos cientficos no

estndar, etc. Los servicios son puestos en lared y operan de manera cooperativa paradar soporte a uno o ms procesos denegocios. En este modelo, una aplicacin seconvierte en un conjunto de servicios deusuario, negocios y datos que satisface las

necesidades de los procesos de negocios oprocesa su soporte.

Como los servicios estn diseados para eluso general y siguen lineamientos de interfazpublicados, pueden ser reutilizados ycompartidos entre mltiples aplicaciones.

Podemos puntualizar las siguientescaractersticas que traen consigo esta formade arquitectura:

Utilizacin de esquemas ms complejos.

Los datos y los servicios web aparecenseparados.

Facilidad para separar datos de lalgica de negocio.

Mayor seguridad en los datoscorporativos.

El cliente recibe los datos y lainformacin de forma indirecta travsservidor

Diagrama de arquitectura en tres capas

Seguidamente detallaremos la funcionalidadde cada capa:

Capa de Presentacin o Interfaz deUsuario: Esta capa, esta formada porlos formularios y los controles que se


2/10

2 | P g i n a

encuentran en los formularios. Capacon la que interacta el usuario

Capa de Negocio: Esta capa estaformada por las entidades, querepresentan objetos que van a sermanejados o utilizados por toda laaplicacin. En este caso, estnrepresentados por clases yDataTables que se crean

Capa de Acceso a Datos: Contieneclases que interactan con la base dedatos, stas clases altamenteespecializadas se encuentran en laarquitectura del sistema y permiten,utilizando los procedimientosalmacenados generados, realizar todaslas operaciones con la base de datos

de forma transparente para la capa denegocio

SOA

La Arquitectura Orientada a Servicios decliente (en ingls Service OrientedArchitecture), es un concepto dearquitectura de software que define la

utilizacin de servicios para dar soporte a losrequisitos del negocio.

Permite la creacin de sistemas altamenteescalables que reflejan el negocio de laorganizacin, a su vez brinda una forma biendefinida de exposicin e invocacin deservicios (comnmente pero noexclusivamente servicios web), lo cual facilitala interaccin entre diferentes sistemaspropios o de terceros.

SOA define las siguientes capas de software:

Aplicaciones bsicas - Sistemasdesarrollados bajo cualquierarquitectura o tecnologa,

geogrficamente dispersos y bajocualquier figura de propiedad;

De exposicin de funcionalidades -Donde las funcionalidades de la capaaplicativa son expuestas en forma deservicios (generalmente como serviciosweb);

De integracin de servicios - Facilitan elintercambio de datos entre elementosde la capa aplicativa orientada aprocesos empresariales internos o encolaboracin;

De composicin de procesos - Quedefine el proceso en trminos delnegocio y sus necesidades, y que varaen funcin del negocio;

De entrega - donde los servicios sondesplegados a los usuarios finales.

SOA proporciona una metodologa y unmarco de trabajo para documentar lascapacidades de negocio y puede dar soportea las actividades de integracin yconsolidacin.

Terminologa

Servicio Una funcin sin estado, auto-contenida, que acepta una(s) llamada(s) ydevuelve una(s) respuesta(s) mediante unainterfaz bien definida. Los servicios puedentambin ejecutar unidades discretas detrabajo como seran editar y procesar unatransaccin. Los servicios no dependen delestado de otras funciones o procesos. Latecnologa concreta utilizada para prestar elservicio no es parte de esta definicin.Existen servicios asncronos en los que unasolicitud a un servicio crea, por ejemplo, un

archivo, y en una segunda solicitud seobtiene ese archivo

Orquestacin Secuenciar los servicios yproveer la lgica adicional para procesardatos. No incluye la presentacin de losdatos. Coordinacin.


3/10

3 | P g i n a

Sin estado No mantiene ni depende decondicin pre-existente alguna. En una SOAlos servicios no son dependientes de lacondicin de ningn otro servicio. Recibenen la llamada toda la informacin quenecesitan para dar una respuesta. Debido aque los servicios son "sin estado", puedenser secuenciados (orquestados) ennumerosas secuencias (algunas vecesllamadas tuberas o pipelines) para realizar lalgica del negocio.

Proveedor La funcin que brinda unservicio en respuesta a una llamada opeticin desde un consumidor.

Consumidor La funcin que consume elresultado del servicio provisto por unproveedor

Diseo y desarrollo de SOA

La metodologa de modelado y diseo paraaplicaciones SOA se conoce como anlisis ydiseo orientado a servicios. La arquitecturaorientada a servicios es tanto un marco detrabajo para el desarrollo de software comoun marco de trabajo de implementacin.

Para que un proyecto SOA tenga xito losdesarrolladores de software debenorientarse ellos mismos a esta mentalidad decrear servicios comunes que sonorquestados por clientes o middleware paraimplementar los procesos de negocio. Eldesarrollo de sistemas usando SOA requiereun compromiso con este modelo entrminos de planificacin, herramientas einfraestructura.

Cuando la mayora de la gente habla de unaarquitectura orientada a servicios estnhablando de un juego de servicios residentesen Internet o en una intranet, usandoservicios web. Existen diversos estndaresrelacionados a los servicios web. Incluyen lossiguientes:

XML HTTP SOAP WSDL UDDI

Hay que considerar, sin embargo, que unsistema SOA no necesariamente necesitautilizar estos estndares para ser "orientadoa servicios" pero es altamente recomendablesu uso.

En un ambiente SOA, los nodos de la redhacen disponibles sus recursos a otrosparticipantes en la red como serviciosindependientes a los que tienen acceso deun modo estandarizado. La mayora de lasdefiniciones de SOA identifican la utilizacinde Servicios Web (empleando SOAP y WSDL)en su implementacin, no obstante se puedeimplementar SOA utilizando cualquiertecnologa basada en servicios.

Lenguajes de alto nivel

Los lenguajes de alto nivel como BPEL o WS-Coordination llevan el concepto de servicioun paso adelante al proporcionar mtodos

de definicin y soporte para flujos de trabajoy procesos de negocio.

Diferencias con otras arquitecturas

Al contrario de las arquitecturas orientado aobjetos, las SOAs estn formadas porservicios de aplicacin dbilmente acopladosy altamente interoperables. Paracomunicarse entre s, estos servicios sebasan en una definicin formal

independiente de la plataforma subyacente ydel lenguaje de programacin (p.ej., WSDL).La definicin de la interfaz encapsula (oculta)las particularidades de una implementacin,lo que la hace independiente del fabricante,del lenguaje de programacin o de latecnologa de desarrollo (como Plataforma


4/10

4 | P g i n a

Java o Microsoft .NET). Con esta arquitectura,se pretende que los componentes desoftware desarrollados sean muyreutilizables, ya que la interfaz se definesiguiendo un estndar; as, un servicio C#podra ser usado por una aplicacin Java. Eneste sentido, ciertos autores definen SOAcomo una Sper-Abstraccin.

Beneficios

Los beneficios que puede obtener unaorganizacin que adopte SOA son:

Mejora en los tiempos de realizacinde cambios en procesos.

Facilidad para evolucionar a modelosde negocios basados en tercerizacin.

Facilidad para abordar modelos denegocios basados en colaboracin conotros entes (socios, proveedores).

Poder para reemplazar elementos dela capa aplicativa SOA sin disrupcin enel proceso de negocio

Facilidad para la integracin detecnologas dismiles

EDA

La Arquitectura dirigida por eventos, Event-driven architecture o EDA, es un patrn dearquitectura software que promueve laproduccin, deteccin, consumo y reaccin aeventos.

Un evento puede ser definido como uncambio significativo en el estado . Porejemplo, cuando un consumidor compra uncoche, los cambios en el coche del estado de"en venta" a "vender". La arquitectura de unconcesionario de automviles de sistemapuede tratar este cambio de estado como unevento para ser producidos, publicados,

detecta y consumida por diversasaplicaciones dentro de la arquitectura.

Este patrn de arquitectura puede seraplicada por el diseo e implementacin deaplicaciones y sistemas que transmiteneventos entre los componentes de softwareligeramente acopladas y servicios. Unsistema orientado a eventos tpicamenteconsiste de los emisores de eventos (oagentes) y los consumidores de eventos (osumideros). Los fregaderos tienen laresponsabilidad de la aplicacin de unareaccin tan pronto como un evento sepresenta. La reaccin puede o no estarcompletamente proporcionada por el propiofregadero. Por ejemplo, el receptor slo

puede tener la responsabilidad de filtrar,transformar y remitir el caso a otrocomponente o puede proporcionar unareaccin auto contenida, a tal evento. Laprimera categora de los sumideros puedenbasarse en los componentes tradicionales,como el middleware orientado a mensajes,mientras que la segunda categora de lossumideros (auto reaccin contenidos enlnea) pueden requerir un marco msapropiado ejecutivo transaccional.

Creando de aplicaciones y sistemas en tornoa una arquitectura basada en eventospermite que estas aplicaciones y sistemasque se construir en una manera que facilitams la capacidad de respuesta, porqueimpulsado sistemas de eventos son, pordiseo, ms normalizado y asincrnicaambientes impredecibles.

Impulsado por la arquitectura de eventospueden complementar la arquitecturaorientada a servicios (SOA) ya que losservicios pueden ser activados por factoresdesencadenantes disparados contra loseventos entrantes. Este paradigma esparticularmente til cuando el fregadero noproporciona ningn ejecutivo autnomo.


5/10

5 | P g i n a

SOA 2.0 desarrolla las implicaciones de lasarquitecturas SOA y EDA proporciona a unrico, robusto nivel ms mediante elaprovechamiento de las relaciones causalesdesconocidas previamente para formar unpatrn nuevo evento. Esta nueva inteligenciade negocios patrn desencadenantes detratamiento automatizado de autonomahumana o, adems, que agrega valorexponencial de la empresa mediante lainyeccin de informacin de valor aadidoen el patrn reconoci que no se podrahaber logrado con anterioridad.

Las mquinas de computacin y dispositivosde deteccin (como sensores, actuadores,controladores) pueden detectar cambios de

estado de los objetos o las condiciones ycrear eventos que luego pueden serprocesados por un servicio o sistema.Desencadenadores de eventos son lascondiciones que dan lugar a la creacin deun evento.

Estructura del suceso

Un evento puede ser de dos partes, elencabezado del suceso y el cuerpo del

evento. El encabezado del suceso podraincluir informacin como el nombre delevento, fecha y hora para el evento, y el tipode evento. El cuerpo de eventos es la parteque describe el hecho de que ha ocurrido enrealidad. Un organismo de evento no debeconfundirse con el patrn o la lgica que sepuede aplicar en reaccin al propio evento.

Capas de flujo de eventos

Un evento desencadena la arquitectura sebasa en cuatro capas lgicas. Se inicia con ladeteccin de un hecho, la representacintcnica en la forma de un evento y terminacon un conjunto no vaco de las reacciones aeste caso.

Generador de eventos

La capa lgica primero es el generador deeventos, que detecta un hecho y representael hecho en un evento. Dado que un hechopuede ser casi cualquier cosa que pueda serdetectado, por lo que puede un generadorde eventos. A modo de ejemplo, ungenerador de eventos podra ser un clientede correo electrnico, un sistema decomercio electrnico o algn tipo de sensor.La conversin de los diferentes datosrecogidos de los sensores de una formanormalizada de los datos que se puedeevaluar es un problema importante en eldiseo e implementacin de esta capa. Sinembargo, teniendo en cuenta que un evento

es un marco muy declarativa, las operacionesde transformacin se puede de fcilaplicacin, eliminando as la necesidad de unalto nivel de estandarizacin.

Canal de eventos

Un canal de eventos es un mecanismomediante el cual la informacin de ungenerador de eventos se transfiere a loseventos de motor o un lavabo. Esto podra

ser una conexin TCP / IP o cualquier tipo dearchivo de entrada (formato plano, XML, e-mail, etc). Varios canales de eventos sepueden abrir al mismo tiempo. Por lo general,porque el motor de procesamiento deeventos tiene que procesar en tiempo casireal, los canales de evento se puede leer deforma asincrnica. Los eventos se almacenanen una cola, en espera de ser procesadosposteriormente por el motor deprocesamiento de eventos.

Motor de procesamiento de sucesos

El motor de procesamiento de eventos esdonde se identifique el caso, y la reaccinapropiada es seleccionada y ejecutada. Estotambin puede dar lugar a una serie de


6/10

6 | P g i n a

afirmaciones que se producen. Es decir, si elcaso de que entre en el motor deprocesamiento de eventos es un"identificador de producto de baja en laaccin", esto puede desencadenarreacciones tales como, "Identificacin deproductos" y "Aviso de personal".

Por eventos de actividad intermedios

Aqu es donde las consecuencias del eventose muestran. Esto se puede hacer de muchasmaneras y formas diversas, por ejemplo, uncorreo electrnico se enva a alguien y unaaplicacin puede mostrar algn tipo deadvertencia en la pantalla. Dependiendo delnivel de automatizacin proporcionada por

el fregadero (caso del motor deprocesamiento) de la actividad aguas abajopodra no ser necesaria.

Estilos de procesamiento de sucesos

Hay tres estilos generales de procesamientode eventos: flujo simple y complejo. Los tresestilos se usan a menudo juntos en unevento impulsado por la arquitecturamadura.

Procesamiento de eventos simples

Simple se refiere a los eventos deprocesamiento de eventos que estndirectamente relacionados con los cambiosespecficos y medibles de la condicin. En elprocesamiento de eventos simples, unacontecimiento notable que inicia la accinocurre aguas abajo. El procesamiento deeventos simples que comnmente se utiliza

para conducir el caudal en tiempo real detrabajo, reduciendo el tiempo de retraso y elcosto.

Por ejemplo, eventos simples pueden sercreados por un sensor que detecta cambios

en la presin de los neumticos o latemperatura ambiente.

Evento de procesamiento de flujo

En el procesamiento de flujo de eventos(ESP), ambos eventos ordinarios y notablesuceder. Los eventos ordinarios (autos,transmisiones de RFID) son examinados paranotabilidad y en directo a los abonados de lainformacin. Caso de procesamiento de flujose utiliza comnmente para conducir elcaudal en tiempo real de informacin en yalrededor de la empresa, lo que permite entiempo en la toma de decisiones.

Procesamiento de eventos complejos

El procesamiento de eventos complejos(CEP) permite a los patrones de eventossimples y ordinarios que se considere queinferir que un acontecimiento complejo seha producido. El procesamiento de eventoscomplejos evala una confluencia de eventosy luego entra en accin. Los acontecimientos(notables u ordinarios) pueden cruzar lostipos de eventos y se producen durante unlargo perodo de tiempo. La correlacin de

eventos puede ser causal, temporal oespacial. El CEP exige el empleo deintrpretes de eventos complejos, ladefinicin de caso patrn y se pongan enventa, y las tcnicas de correlacin. El CEP seutiliza comnmente para detectar yresponder a las anomalas de negocio, lasamenazas y oportunidades.

Acoplamiento flexible etremo y biendistribuido

Una arquitectura orientada a eventos es muyimprecisa y bien distribuidas. La grandistribucin de esta arquitectura existeporque un evento puede ser casi cualquiercosa y existen en casi cualquier lugar. Laarquitectura es muy imprecisa porque el


7/10

7 | P g i n a

evento en s mismo no conoce sobre lasconsecuencias de su causa. Si por ejemplotenemos un sistema de alarma que registrainformacin cuando la puerta delantera seabre, la puerta s mismo no sabe que elsistema de alarma se agrega la informacincuando se abre la puerta, slo que la puertase ha abierto.

Implementaciones y ejemplos

Java Swing

Java Swing API se basa en una arquitecturaimpulsada evento. Esto funcionaespecialmente bien con la motivacin detrsde Swing para proporcionar los componentesde interfaz de usuario y funcionalidadesrelacionadas. La API utiliza una convencinde nomenclatura (por ejemplo,"ActionListener" y "ActionEvent") relacionary organizar las preocupaciones evento. Unaclase que tiene que ser consciente de unevento en particular, simplemente ejecuta eloyente su caso, reemplaza los mtodosheredados, y entonces se agrega al objetoque desencadena el evento. Un ejemplo muysimple puede ser:

public class FooPanel extends JPanelimplements ActionListener {

public FooPanel() {super();

JButton btn = newJButton("Click Me!");

btn.addActionListener(this);

this.add(btn);}

@Overridepublic void

actionPerformed(ActionEvent ae) {System.out.println("Button

has been clicked!");}

}

Como alternativa, otra opcin es laaplicacin para agregar al oyente al objetocomo una clase annima. A continuacin semuestra un ejemplo.

public class FooPanel extends JPanel

{public FooPanel() {

super();

JButton btn = newJButton("Click Me!");

btn.addActionListener(newActionListener() {

public voidactionPerformed(ActionEvent ae) {

System.out.println("Button has beenclicked!");

}});

}}

ESB

Un bus de servicios de empresa (BSE)consiste en un combinado de arquitectura desoftware que proporciona serviciosfundamentales para arquitecturas complejasa travs de un sistema de mensajes (el bus)

basado en las normas y que responde aeventos. Los desarrolladores normalmenteimplementan un BSE utilizando tecnologasde productos de infraestructura demiddleware que se basan en normasreconocidas.

Un BSE generalmente proporciona una capade abstraccin construida sobre unaimplementacin de un sistema de mensajesde empresa que permita a los expertos enintegracin explotar el valor del envo demensajes sin tener que escribir cdigo. Alcontrario que sucede con la clsicaintegracin de aplicaciones de empresa (IAE)que se basa en una pila monoltica sobre unaarquitectura hub and spoke, un bus deservicio de empresa se construye sobre unas


8/10

8 | P g i n a

funciones base que se dividen en sus partesconstituyentes, con una implantacindistribuida cuando se hace necesario, demodo que trabajen armoniosamente segnla demanda.

Un BSE no implementa en s mismo unaarquitectura orientada a servicios (AOS), sinoque proporciona las caractersticasmediantes las cuales s se puedeimplementar. Un BSE debera basarse [citarequerida] en normas y proporcionarflexibilidad, dando cobertura a distintosmedios de transporte que sean capaces deimplementar tanto patrones de AOStradicionales como arquitectura de negocioscon una AOS 2.0 enriquecida. El BSE trata de

aislar el acoplamiento entre el serviciosolicitado y el medio de transporte. Lamayora de los proveedores de BSEincorporan principios de AOS y permitenformatos de mensaje independientes.

Definiciones y alcance

No hay acuerdo sobre si se debe definir unbus de servicios de empresa como un estilo

de arquitectura, como un producto desoftware o como un grupo de productos desoftware. Si bien es cierto que la utilizacinde un BSE implica ciertamente ajustarse auna arquitectura determinada, el trmino"bus de servicios de empresa" casi siemprese refiere a la infraestructura de softwareque hace posible tal arquitectura y, enesencia, se considera al BSE como unaplataforma para realizar una arquitecturaorientada a los servicios.

Un Bus de Servicios de Empresa (BSE)conlleva conceptos relacionados con flujos,como la transformacin y el enrutamiento enuna Arquitectura Orientada a los Servicios.Un BSE tambin puede proporcionar una

abstraccin para endpoints. Con esto seconsigue flexibilidad en la capa deabstraccin y una fcil conexin entre losservicios.[cita requerida]

Arquitectura de BSE

El uso de la palabra "bus" viene del bus quetransporta los bits entre los distintosdispositivos de un ordenador. El bus deservicio de empresa proporciona una funcin

anloga a un nivel superior de abstraccin.En una arquitectura de empresa que haceuso de un BSE una aplicacin se comunicara travs del bus, que acta como "divisor demensajes" (message broker) entre lasaplicaciones. Este enfoque tiene la ventajade que reduce el nmero de conexin punto-a-punto que se necesitan para permitir quese comunique una aplicacin. Esto, a su vez,simplifica el "anlisis de impacto" (impactanalysis) de la mayor parte del software.Reduciendo el nmero de puntos decontacto de una aplicacin determinada, elproceso de adaptacin de un sistema a loscambios de uno de sus componentes se hacems sencillo.


9/10


10/10

10 | P g i n a

por un procesamiento de XML extra (elBSE normalmente utiliza XML comolenguaje de comunicacin).

El BSE se convierte en un elementonico de fallo.

Aunque los sistemas de BSE puedenrequerir un esfuerzo significativo paraser implementados, no producen unvalor comercial sin el consiguientedesarrollo de servicios AOS para el BSE.

CONCLUSIONES

De las tres arquitecturas de las que sehablaron, en mi opinin el que es msconveniente es el SOA. Tanto el SOA como elESB tienen ventajas parecidas e incluso elESB tiene algunas cosas que lo hacen superaral SOA, pero el ESB requiere de ms atencina la hora de configurar ya tambin almomento de trabajar que hacen que lasventajas que tena sobre el SOA no sirvanpara compensar las desventajas.

REFERENCIAS

http://www.areaordenadores.com/Arquitecturas-Software.html

http://es.wikipedia.org/wiki/Arquitectura_orientada_a_servicios

http://es.wikipedia.org/wiki/Arquitectura_dirigida_por_eventos

http://en.wikipedia.org/wiki/Event-driven_architecture

Arquitecturas de Desarrollo

Documents

Transcript of Arquitecturas de Desarrollo