NDICE

RESUMEN. INTRODUCCIN.. 1. HISTORIA DE SOA. 1.1 Principios de SOA.. 2. SOA 2.1. Definicin de SOA. 2.2. Como Funciona.. 2.2.1. Qu es un servicio?.......................................................................... 2.2.2. Web Service.. 2.2.3. Como funciona SOA 2.2.3.1 Orquestacin y Coreografa de Web Services.. 2.2.4. Enterprise Service Bus 2.2.4.1. Manejo ESB 3. Actualmente quien usa SOA.. CONCLUSIONES. GLOSARIO BIBLIOGRAFA.

2 3 5 5 9 9 12 12 13 14 14 16 20 22 23 24 26

RESUMEN

La Arquitectura Orientada a Servicios es una herramienta que ha ido creciendo en los ltimos aos. De acuerdo a esto ha tomado un gran terreno en el mbito de las TI, es por eso que es de gran importancia conocer acerca de esta gran herramienta, la cual no solo ha ganado terreno sino que tambin es de gran utilidad ya que agiliza y agrupa todas las aplicaciones con las que cuenta una empresa. Como desarrolladores o conocedores de la tecnologa es necesario tener en cuenta que existen ciertas metodologas para poder cubrir algunas necesidades de alguna empresa u organizacin. En el presente se explicara en que consiste la Arquitectura Orientada a Servicios, SOA por sus siglas en ingls Service Oriented Architecture, su definicin su funcionamiento y cules son sus principales herramientas. Adems se abordara un poco de la historia de cmo es que surgi SOA

INTRODUCCIN

La infraestructura de TI de una empresa en la mayora de las ocasiones se compone de una gran diversidad de tecnologas. Es comn encontrar diferentes plataformas de hardware, lenguajes de programacin, sistemas operativos y enlaces de comunicacin. Esta infraestructura tecnolgica debe trabajar de manera conjunta para ofrecer al negocio los servicios requeridos para la operacin de la empresa, sin embargo, debido a esta diversidad de factores tecnolgicos, establecer mecanismos de comunicacin para el intercambio de informacin entre las aplicaciones de una empresa se vuelve una tarea compleja. Ya que la lgica de conectividad y mediacin quedan infiltradas en la aplicacin junto con la lgica de negocio original. Ya que para esto es necesario realizar desarrollo en ambos aplicativos que se requieran comunicar ya que se necesita implementar una lgica de comunicacin en ambas. Cuando se requiere realizar algn cambio en el intercambio de informacin es necesario realizar modificaciones en ambos aplicativos y esto conlleva a tener que realizar ms trabajo y llevara un mayor tiempo de desarrollo y costo. Es por todo esto que es necesario conocer una metodologa que nos permita realizar lo antes descrito de una manera mas eficiente y rpida, que no produzca un mayor tiempo de desarrollo ni costo, ya que el reducir el tiempo y costo mejorara el funcionamiento de una organizacin. Para esto se presentara la Arquitectura Orientada a Servicios la cual nos servir para llevar a cabo esta comunicacin entre las aplicaciones, pero no solo esto ademas de definir y conocer de que se trata la Arquitectura Orientada a Servicios, tambin veremos algunos de sus componentes importantes como lo son los

Enterprise Service Bus. Este es el que nos permite el intercambio de mensjaes entre aplicaciones sin importar la plataforma en que este desarrollada. El objetivo es presentar e informar acerca de esta tecnologa que actualmente esta tomando terreno en la TI y en grandes empresas en Mexico. Tambin presentaremos algunos ESB y como es el entorno grafico de uno (WebSphere Message Broker de IBM).

1. HISTORIA DE SOA

1.1 Principios de SOA

En 1994 los sistemas se que se realizaban eran bajo una arquitectura clienteservidor, la cual consiste en que las tareas son distribuidas en los diferentes proveedores del servicio, tambin llamadas servidores y un demandante de alguna tarea, llamado cliente. Esto consiste en que el cliente realiza una peticin y el servidor da una respuesta. Esto tambin se puede aplicar sobre una sola computadora y no solo montado sobre un servidor. Estas aplicaciones solo se dedican a dar respuesta sobre una peticin o un servicio en especfico y por lo tanto no exista una comunicacin entre ellas o la comunicacin que haba solo era punto a punto y haba una gran logia inmersa en ellas para la realizacin de la comunicacin, por ello al cambiar algo en alguna de ellas, se tenia que cambiar en la otra con la cual tena una comunicacin. A continuacin se muestra una breve historia de cmo y porque apareci la Arquitectura Orientada a Servicios. En 1994, un importante banco de EE.UU. estaba tratando de resolver un problema con el servicio a clientes. Al igual que casi todos los bancos en ese momento, contaban con diferentes productos (Es decir, los diferentes tipos de cuentas) los cuales se guardaban en diferentes sistemas. (Rosen, Michael; Lublinsky, Boris; Smith, Kevin T.; Balcer, Marc J., 2007). Esto provocaba que cuando los clientes necesitaban informacin sobre sus cuentas, necesitaban ingresar a diferentes terminas, con diferentes sistemas, esto provoc el malestar de los clientes y no solo de ellos sino tambin de los empleados del banco ya que era todo una prdida de tiempo. Tenan que sacar el nmero de cuenta en una terminal y meterlo en otra y as. Es por esto que el

banco pens en unificar estas cuentas, al fin era un problema muy grande ya que como se mencion se usaban diferentes sistemas operativos. Una de las primeras soluciones fue poner todos los sistemas en una sola terminal, pero esto no ayudo de mucho ya que aun asi los usuarios tenan que acceder a diferentes partes. Esto no redujo el descontento de sus usuarios. Posterior a esto el banco intento con una nueva tecnologa llamada Request Broker Architecture o comunmente (CORBA). Lo que hicieron fue ver las cuentas como un objeto, esto proporcionaba una capa de abstraccin entre el usuario y la interfaz. A continuacin, se escribi una nueva interfaz de usuario, utilizando Visual Basic (VB), que proporcion la informacion de las diferentes cuentas mediante el acceso de diferentes sistemas a travs de los objetos CORBA. Con esta implementacin es decontento de los clientes desaparecio. Tenan esencialmente aplicado los principios de una arquitectura de aplicaciones de 3 niveles, separando la presentacin, lgica de negocio y los sistemas operativos, en la siguiente imagen se puede apreciar mejor esta arquitectura.

En la imagen se logra observar los tres niveles en lo que el banco dividi la arquitectura de sistemas para poder dar un mejor servicio sin importar el sistema en el que se encontrara la cuenta. Este banco logro reunir sus diferentes productos, que se encontraban en diferentes sistemas y dar un servicio a sus clientes. Los analistas de Gartner, Roy W. Schulte y Yefim Natis V., publicaron los primeros informes acerca de SOA en 1996. Gartner, una de las principales empresas de investigacin en TI y asesoramiento, fue una de las primeras empresas en usar el trmino SOA.

Rosen, Michael; Lublinsky, Boris; Smith, Kevin T.; Balcer, Marc J. Applied SOA: Service-Oriented Architecture and Design Strategies., 2007

El verdadero impulso para la SOA fue creado por Web Services, que, inicialmente fue impulsado por Microsoft, llegaron a un pblico ms amplio en 2000. Aunque los Servicios Web no necesariamente se traducen en SOA, y no todos SOA est basado en servicios web, la relacin entre los dos sentidos de la tecnologa es importante y que son mutuamente influyentes: el impulso de servicios web SOA traer a los usuarios comunes y la arquitectura de las mejores prcticas de SOA ayudar a que las iniciativas de servicios web con xito. (Josuttis, 2007) Como lo menciona Nicolai Josuttis en su libro, SOA tuvo un gran impulso con la aparicin de los Web Services, esto es porque esta tecnologa ayuda en la comunicacin con diferentes aplicaciones, pero bueno esto se explicara ms adelante, cuando se explique el funcionamiento de SOA. Aunque como se menciona arriba SOA no est basado solo en Web Services, tambin puede existir sin ellos. Esto es un poco de cmo es que se comenz el desarrollo de SOA, la pequea historia del banco nos apoy a visualizar mejor como es que comienza la Arquitectura Orientada a Servicios, del porque se piensa y comienza a trabajar sobre ella.

2. SOA

2.1. Definicin de SOA

En los inicios de la informtica, la programacin se consideraba un arte y se desarrollaba como tal, debido a la dificultad que contena para la mayora de las personas, pero con el tiempo se han ido descubriendo y desarrollando formas y guas generales, con base a las cuales se puedan resolver los problemas. A estas guas, se les ha denominado Arquitectura de Software, porque, a semejanza de los planos de un edificio o construccin, estas indican la estructura, funcionamiento e interaccin entre las partes del software. Es por esto que es tan importante comprender la definicin de arquitectura de software, para as asimilar mejor lo que es SOA (Arquitectura Orientada a Servicios), ya que como su nombre lo dice es una arquitectura. SOA es un paradigma (o concepto, o la filosofa) que conduce a un sistema de valores para los grandes sistemas distribuidos con diferentes propietarios. (Josuttis, 2007). Como lo vemos en esta definicin, que es concreta e intenta definir a SOA, es un paradigma y no se debe de ver como un software o un lenguaje de programacin. SOA no es una herramienta que se pueda comprar, es un enfoque o una forma de pensar. En la siguiente definicin podemos visualizar ms lo que es SOA. SOA es una arquitectura para la construccin de soluciones empresariales basadas en servicios. Ms especficamente, SOA se refiere a la construccin independiente de los servicios de negocio-alineados que se pueden combinar, los procesos de negocio de alto nivel y soluciones en el contexto de la empresa.

Cualquiera puede crear un servicio, ese no es el reto de SOA. El valor real de SOA viene cuando los servicios reutilizables se combinan para ser ms agiles, los procesos de negocio ms flexibles. Por desgracia, eso no sucede por s mismo. El logro podra ser ms fcil de controlar si una organizacin fuera la creacin de todos los servicios, pero que no es el caso en la mayora de las grandes organizaciones. Por lo tanto, parte de la arquitectura de SOA es responsable de crear el entorno necesario para crear y utilizar servicios ya creados en toda la empresa. En otras palabras, la arquitectura permite que diferentes organizaciones de forma independiente implementen servicios que satisfagan sus necesidades inmediatas, pero tambin se pueden combinar en los procesos de negocio de alto nivel y soluciones empresariales. (Rosen, Michael; Lublinsky, Boris; Smith, Kevin T.; Balcer, Marc J., 2007) El trmino arquitectura orientada a servicios (SOA) expresa el punto de vista de arquitectura de software, que define el uso de servicios de apoyo a los requisitos de los usuarios de software. En un ambiente de SOA, los recursos de una red se hacen disponibles como servicios independientes que pueden ser accedidos sin el conocimiento de su implementacin de la plataforma. En esta definicin, ms enfocada a lo que es SOA, nos enfoca ms hacia las empresas y agilizacin de sus servicios. Con esto podemos dar una definicin. El trmino arquitectura orientada a servicios (SOA) expresa el punto de vista de arquitectura de software, que define el uso de servicios de apoyo a los requisitos de los usuarios de software. En un ambiente de SOA, los recursos de una red se hacen disponibles como servicios independientes que pueden ser accedidos sin el conocimiento de su implementacin de la plataforma. La arquitectura orientada a servicios es tanto un marco de trabajo para el desarrollo de software como un marco de trabajo de implementacin. Para que un

10

proyecto SOA tenga xito los desarrolladores de software deben orientarse ellos mismos a esta mentalidad de crear servicios comunes que son orquestados por clientes o middleware para implementar los procesos de negocio. SOA permite la creacin de sistemas de informacin altamente escalables que reflejan el negocio de la organizacin, a su vez brinda una forma bien definida de exposicin e invocacin de servicios (comnmente pero no exclusivamente servicios web), lo cual facilita la interaccin entre diferentes sistemas propios o de terceros. Por lo tanto permite que diferentes empresas u organizaciones implementen de forma independiente, servicios que satisfagan sus necesidades inmediatas, pero para esto se necesita que los servicios tengan similar tamao, forma, figura, funcin y otras caractersticas como son: Se ajusten a los estndares de la empresa Comunicacin a nivel tcnico Comunicacin a nivel semntico

Considerando lo anterior hay que mencionar que SOA tiene algunas partes importantes que debe considerarse al implementar esta arquitectura, las cuales son: Procesos: Que son las funciones de negocios de alto nivel. Servicios: La unidad modular de funcionalidad empresarial. Integracin: Conexin y la exposicin de las aplicaciones existentes y / o los datos como servicios. Sistemas Existentes: sistemas heredados existentes, aplicaciones y datos que la empresa que se quiere aprovechar. Documentos: Unidades de alto nivel de informacin de negocios o como una orden de compra. Transformacin: La conversin de la informacin de un formato o semntica a otro. Comunicaciones: La capacidad de los servicios para comunicarse con otro.

11

2.2. Como Funciona

Una vez comprendido que SOA no es un lenguaje o software si no una metodologa, podemos comenzar a describir cmo es que funciona esta arquitectura. Como bien se describi anteriormente SOA utiliza servicios para poder integrar los sistemas, aplicaciones o como tal las TI de una empresa u organizacin. Para ello comenzaremos con la definicin de lo que es un servicio y un Web Service. Tambin abordaremos las diferentes capas que utiliza SOA para su desarrollo e implementacin.

2.2.1. Qu es un servicio? Es una relacin de contrato entre personas y/o empresas que se comprometen a cumplir un acuerdo: la prestacin del servicio, en plazo y forma acordados, y el cliente, que recibe la prestacin del servicio y cancela en la fecha establecida . (Gonzlez Faras, 2013) Como lo dice Gonzalez Farias, un servicio se puede ver como un contrata entre personas o empresas, el cual garantiza el cumplimiento de alguna actividad. Tomando encuanta la definicin anterior podemos abordar lo que son los web service, que como mencionamos tambin es una parte fundamental de SOA.

12

2.2.2. Web Service. El trmino Web Services describe una forma estandarizada de integrar aplicaciones WEB mediante el uso de XML, SOAP, WSDL y UDDI sobre los protocolos de la Internet. XML es usado para describir los datos, SOAP se ocupa para la transferencia de los datos, WSDL se emplea para describir los servicios disponibles y UDDI se ocupa para conocer cuales son los servicios disponibles. Uno de los usos principales es permitir la comunicacin entre las empresas y entre las empresas y sus clientes. Los Web Services permiten a las organizaciones intercambiar datos sin necesidad de conocer los detalles de sus respectivos Sistemas de Informacin. A diferencia de los modelos Cliente/Servidor, tales como un servidor de pginas Web, los Web Services no proveen al usuario una interfaz grfica (GUI). En vez de ello, los Web Services comparten la lgica del negocio, los datos y los procesos, por medio de una interfaz de programas a travs de la red. Es decir conectan programas, por tanto son programas que no interactan directamente con los usuarios. Los desarrolladores pueden por consiguiente agregar a los Web Services la interfaz para usuarios, por ejemplo mediante una pagina Web o un programa ejecutable, tal de entregarle a los usuarios un funcionalidad especfica que provee un determinado Web Service. Los Web Services permiten a distintas aplicaciones, de diferentes orgenes, comunicarse entre ellos sin necesidad de escribir programas costosos, esto porque la comunicacin se hace con XML. Los Web Services no estn ligados a ningn Sistema Operativo o Lenguaje de Programacin. Por ejemplo, un programa escrito en Java puede conversar con otro escrito en Pearl; Aplicaciones Windows puede conversar con aplicaciones Unix. Por otra parte los Web Services no necesitan usar browsers (Explorer) ni el lenguaje de especificacin HTML. Los Web Services estn construidos con varias tecnologas que trabajan

conjuntamente con los estndares que estn emergiendo para asegurar la seguridad y operatividad, de modo de hacer realidad que el uso combinado de

13

varios Web Services, independiente de la o las empresas que los proveen, este garantizado.

2.2.3. Como funciona SOA

SOA est basada en cuatro abstracciones bsicas: servicios, application frontend repositorio de servicios. Atrs pudimos ver que son los servicios y los web service. Ahora sigamos con las otras 3 abstracciones. Las application frontend consumen los servicios formando procesos de negocios. Un repositorio de servicios almacena los contratos de servicios y el bus de servicios interconecta las application frontend y los servicios. Los servicios representan grupos lgicos de operaciones relacionadas con algn concepto del negocio. Por su parte, los procesos del negocio se realizan en servicios orientados a procesos que se componen de secuencias definidas de invocaciones a servicios, mediante una orquestacin de los mismos en lo que se conoce como coreografas de servicios.

2.2.3.1 Orquestacin y Coreografa de Web Services

La integracin se debe llevar a cabo mediante un mecanismo que permita que los servicios cooperen entre ellos. Para ello comnmente se utilizan dos trminos: La orquestacin y la coreografa. Hablamos de orquestacin de servicios cuando es controlado por una nica unidad, es decir un cliente y un servicio establecen un acuerdo con respecto al transporte de mensajes y al contenido, este acuerdo se realiza con el WSDL, quien especifica la sintaxis de los mensajes y los

14

mecanismos de intercambio utilizados. Un proceso es una coreografa de servicios cuando las colaboraciones son definidas entre cualquier tipo de aplicaciones. Cuando hablamos de coreografa de Servicios Web se debe mencionar a WSCDL. Este lenguaje, basado en XML, permite lograr interaccin entre servicios Web. Dicha interaccin es independiente del lenguaje o de la plataforma utilizada. La coreografa brinda reglas que revelan como mltiples componentes pueden colaborar entre pares, lo que denominamos peer-to-peer, y de qu forma o en que secuencia. Esta colaboracin se realiza mediante el intercambio de mensajes. Principales caractersticas de los sistemas de coreografa: Los sistemas de coreografa utilizan XML. Los lenguajes basados en XML definen desde un punto de vista global su comportamiento comn y complementario observable. Reusabilidad: La definicin coreogrfica es utilizable por diferentes participantes operando en diferentes plataformas y con diferente software. Cooperativismo: Las coreografas definen la secuencia de intercambio de mensajes entre dos o ms procesos o participantes independientes describiendo como deberan cooperar. Multi-party: Las coreografas pueden ser definidas envolviendo cualquier nmero de participantes o procesos. Semntica: Las coreografas pueden incluir documentacin legible por los humanos y semntica para todos los componentes en la coreografa. Componibilidad: Las coreografas existentes pueden ser combinadas para formar nuevas coreografas que pueden ser rehusadas en diferentes contextos. Modularidad: Las coreografas pueden ser definidas usando la facilidad Import que permite a una coreografa ser creada por componentes contenidos en diversas coreografas diferentes.

15

Informacin impulsada: Las coreografas describen la forma en que los participantes toman parte de ellas. Los participantes mantienen por su intercambio de informacin, su posicin en la que estn en el registro de Coreografa. Alineacin de Informacin: Las coreografas permiten a los participantes que toman parte de ella, comunicarse y sincronizar sus cambios observables de estado y los valores reales de la informacin intercambiada. Gestin de excepciones: Las coreografas pueden definir la forma en la que se producen condiciones excepcionales o inusuales mientras se realiza la coreografa. Transaccionabilidad: Los procesos o los participantes que tomen parte en una coreografa pueden trabajar de forma "transaccional" con la capacidad de coordinar los resultados de las colaboraciones de largo plazo, que incluyen mltiples, y a menudo recursivas unidades de colaboracin, cada una con sus propias reglas de negocio y objetivos.

Sistemas de orquestacin.- Es el control de invocacin de los servicios, maneja o como su nombre lo dice orquest la invocacin de los servicios. Para llevar a cabo esta orquestacin, es importante utilizar un ESB el cual se detallara adelante. El ESB, por sus siglas Enterprise Service Bus, es el canal por el cua se conectan todas las aplicaciones.

2.2.4. Enterprise Service Bus

Un ESB ocupa la capa de Middleware entre los sistemas de una organizacin, proporcionando la comunicacin a travs de mensajera. El ESB debe de ser capaz de reemplazar el contacto directo entre las aplicaciones, consiguiendo que se comuniquen a travs del bus.

16

El ESB recibe y transmite mensajes basados en estndares, pero deben de ser capaces de transformar mensajes a formatos que sean reconocidos por las distintas aplicaciones, esto se realiza a travs de adaptadores. El intercambio debe de ser independiente a la plataforma, por tanto, esto permite al ESB integrar aplicaciones que se encuentren en diferentes sistemas operativos. A continuacin se describen algunos ESB que sirven para la orquestacin de servicios ademas de otras que actan como middleware, el cual nos permite una mejor comunicacin con los ESB. ActiveBPEL: Es una implementacin de cdigo abierto del estndar BPEL (Business Process Execution Language). Es la herramienta de aprendizaje personal ideal para familiarizarse con estos estndares de desarrollo de aplicaciones. AgilaBPEL: Solucin Java orientada al flujo de trabajo. Sus principales componentes son Agila BPEL y Agila BPM. El primero realiza la orquestacin basada en las especificaciones WS-BPEL y el segundo es orientado a los usuarios finales del flujo de trabajo Apache ODE: Soporte para el estndar WS-BPEL 2.0 OASIS y el legado BPEL4WS 1.1 Soporta 2 capas de comunicacin: una basada en Axis2 (Web Services http transport) y otra en el estndar JBI (ServiceMix). Alto nivel de API que permite integrar el ncleo con la capa virtual de comunicacin. BEA Aqualogic: Posibilita la creacin de servicios sobre diferentes plataformas como ser J2EE, .NET, SAP, Oracle, IBM, etc, de forma que sean descubiertos, asegurados, gestionados y ensamblados en procesos y aplicaciones compuestas. Bexee BPEL Execution Engine: Es una implementacin de cdigo abierto. El proyecto bexee fue iniciado en Berne University of Applied Sciences, escuela de ingeniera y tecnologa de informacin, como diploma de proyecto. Microsoft BizTalk Server (BTS): contiene un motor que se utiliza en la administracin de procesos de negocio y permite a los desarrolladores

17

rpidamente orquestar complejos procesos de negocio que involucran sistemas muy diferentes. Es un producto del tipo middleware que facilita la colaboracin e integracin entre aplicaciones. Tiene la capacidad de ejecutar procesos de negocio que implementen escenarios de integracin o workflows complejos, transformar datos de un formato a otro, enrutar mensajes, comunicarse con mltiples protocolos y mecanismos, entre otras. BTS realiza orquestacin de servicios Web. La orquestacin recibe solicitudes y enva respuestas utilizando un puerto lgico de dos vas que se encuentra fsicamente enlazado al momento de poner en funcionamiento a dicha orquestacin. Adems, gracias al conjunto de adaptadores ofrecidos con el producto o por terceros, BTS puede conectarse con un sin nmero de sistemas heterogneos tales como SAP, PeopleSoft, Siebel y otros. Oracle Fusion Middleware: Plataforma SOA de fcil uso que integra un

ambiente de desarrollo y administracin. Utiliza una grilla de arquitectura con avanzada escalabilidad y performance para servicios con gran disponibilidad y fiabilidad [9]. SAP XI: Se utiliza para una integracin robusta y de alta performance. SAP provee todos los adaptadores que se necesitan para acceder a otras aplicaciones, archivos, base de datos, y la conexin usando varios protocolos y estndares de la industria. TIBCO - iProcess Suite: Provee una herramienta intuitiva para anlisis de negocio usando el mismo nivel de habilidad que un usuario de hoja de calculo para modelar, analizar, testear y administrar reglas de negocio. Permite la gestin para establecer y medir continuamente con indicadores clave de rendimiento

(KPI) para procesos en curso de ejecucin y mejora.

18

IBM. WebSphere Message Broker: Permite que la informacin del negocio, fluya entre aplicaciones dispares a travs de mltiple hardware y plataformas de software. Las reglas pueden ser aplicadas a los datos que fluyen a travs del intermediario de mensajes para encaminar y transformar la informacin. El WMB es un Enterprise Service Bus que proporciona conectividad entre las aplicaciones y servicios en una arquitectura orientada a servicios. IBM. WebSphere Integration Developer: Es una herramienta basada en tecnologa Eclipse que permite combinar soluciones empresariales con el lenguaje BPEL y Microsoft BizTalk Server. IBM. Webphere Process Server: Viene incluido en esta herramienta y proporciona una base de tiempo de ejecucin integrada y nica para implementar una arquitectura orientada a servicios o SOA basada en procesos de negocios. IBM. Websphere MQ: Surge en el mercado precisamente como un Middleware para facilitar la comunicacin entre las aplicaciones de una empresa sin importar: La tecnologa bajo la cual estn desarrolladas La plataforma sobre la cual se ejecutan Los protocolos de comunicacin utilizados en la infraestructura de comunicaciones En este caso, MQ se sita como una capa entre las aplicaciones con el objetivo de abstraer de las mismas la complejidad relacionada al establecimiento de lneas de comunicacin entre los sistemas. Esto facilitando la creacin de servicios en los aplicativos que sean accesibles por otros sistemas/aplicativos.

19

2.2.4.1. Manejo ESB.

Al llegar una peticin al ESB lo que es que tiene las propiedades para poder divir esta informacin, dependiendo del servicio que se va a solicitar. En el caso de WebSphere Message Broker (que es el que se utilizara para dar un ejemplo), recibe la peticin y la puede divir en cuantas partes sea necesaria, las ventajas que tiene es que tiene una gran variedad de salidas como: xml, texto plano, separado por comas, etc. Esto nos ofrece una gran herramienta, bastante completa y que adems cuenta con una gran documentacin. A continuacin se mostrara unas imgenes que nos mostraran como es que funciona WMB. Se comienza con la instalacin de WebSphere Message Broker. Para comenzar a trabajar se levanta la instancia del Broker y tambin se necesita utilizar un queue manager para poder manejar las queues(colas, mensajes envidos a un servicio).

Una vez ejecutado el queue manager se puede comenzar a trabajar con el Broker, con el WebSphere Message Broker Toolkit, que nos permite realizar el flujo de un mensaje que no es que el flujo que va a llevar al recibir un mensaje, adems de

20

que Toolkit nos da una visin mas visual, con tan solo jalar y soltar para realizar el flujo.

Y aqu ya tenemos un entorno de trabajo para realizar el flujo de mensaje y nos da una gran variedad de tipos de entrada, de diferentes tipos de lenguajes. Tambien vemos un elemento que es un compute el cual nos permite realizar un cambio de formato de salida del mensaje.

21

3. Actualmente quien usa SOA

La creciente demanda de intercomunicar las diferentes aplicaciones con las que cuenta una empresa u organizacin, actualmente es enorme, esto ha provocado que las empresas apuesten por una nueva tecnologa, en este caso es SOA ya que como se mencion nos ayuda a realizar esto de una forma sencilla. Algunas empresas que estn apostando actualmente a la arquitectura orientada a servicios son las siguientes: Bimbo Grupo Modelo Gnp Axxa Banamex Bancomer Ixe banco Banorte

Estas son algunas que estn apostando en esta no tan nueva tecnologa, tambien existe IBM, la que no solo est apostando por ella sino que tambin esta ingresando nuevos productos que ayudan a mejorar esta metodologa. Nortel es otra empresa que tembien se encuentra bajo el marco conceptual de SOA.

22

CONCLUSIONES

La arquitectura orientada a servicio es un marco conceptual que nos permite la integracin de las aplicaciones o sistemas con las que cuenta una organizacin.

No es un tecnologa tan nueva pero gracias a los Web Service tuvo un gran empuje. SOA nos permite una mayor flexibilidad del negocio una mejor distribucin, un fcil matenimiento ya que no es necesario darle matenimiento a todos los sistemas si modificamos alguna con la que tengan comunicacin directa.

Es importante no solo contar con un Enterprise Service Bus sino tambin contar con un Middleware que nos permita manejar queue, que son los mensajes que llegan a nuestra aplicacin.

23

GLOSARIO

Web Services: Un servicio web (en ingls, Web services) es una tecnologa que utiliza un conjunto de protocolos y estndares que sirven para intercambiar datos entre aplicaciones. UDDI: Sigla que corresponde a Universal Description , Discovery and Integration, un repositorio de Web Services. RMI: Invocacin de mtodos remotos (Remote Method Invocation), consiste en que un objeto acceda a un mtodo (una de las funcionalidades) de otro objeto remoto (que est situado en otro punto de una red). DCOM: Distributed Component Object Model, un sistema de Microsoft. Componentes de un software para comunicarse con computadoras en lnea IIOP : Es un protocolo de comunicacin de CORBA. Se define la forma en que los bits se envan a travs de un cable entre clientes y servidores CORBA. CORBA: Es una arquitectura de objetos distribuidos estndar desarrollado por el Object Management Group (OMG). HTTP: Hypertext Transfer Protocol o HTTP (en espaol protocolo de transferencia de hipertexto). Mtodo mediante el que se transfieren documentos desde el sistema host o servidor a los exploradores y usuarios individuales. XML: Xtensible Markup Language (lenguaje de marcas extensible), es un lenguaje de marcas desarrollado por el World Wide Web Consortium (W3C). Permite definir la gramtica de lenguajes especficos para estructurar documentos grandes. SOAP: Simple Object Access Protocol , es un protocolo de mensajera construido en XML que se usa para codificar informacin de los requerimientos de los Web Services

24

WSDL: Web Services Description Language, es un lenguaje especificado en XML que se ocupa para definir los Web Service como colecciones de punto de comunicacin capaces de intercambiar mensajes. WS-CDL: Lenguaje para la descripcin de Coreografas de Servicios Web (Web Services Choreography Description Language (WS-CDL) es un lenguaje basado en XML que describe la colaboracin entre pares peer-to-peer, mediante la definicin - desde un punto de vista global - de los comportamientos comunes y observables de cada participante de un proceso de negocio. PEER-TO-PEER: P2P, por sus siglas en ingls) es una red de computadoras en la que todos o algunos aspectos funcionan sin clientes ni servidores fijos, sino una serie de nodos que se comportan como iguales entre s. MIDDLEWARE: Es un software que asiste a una aplicacin para interactuar o comunicarse con otras aplicaciones, software, redes, hardware y/o sistemas operativos. ste simplifica el trabajo de los programadores en la compleja tarea de generar las conexiones que son necesarias en los sistemas distribuidos. QUEUE: Conjunto de paquetes en espera de ser procesados.

25

BIBLIOGRAFA
(s.f.). Recuperado el 16 de Mayo de 2013, de http://www.tecsisa.com/?item=1483 de Sybase, M. (16 de Mayo de 2007). Qu es SOA, la arquitectura orientada a servicios? Recuperado el 20 de Mayo de 2013, de iProfesiona.coml: http://www.iprofesional.com/notas/46399-Qu-es-SOA-la-arquitectura-orientada-aservicios Gonzlez Faras, S. (2013). DEFINICIN DE SEVICIOS. Recuperado el 28 de Abril de 2013, de Scribd Inc.: http://es.scribd.com/doc/14271268/definicion-de-servicios Josuttis, N. M. (2007). Soa in Practice: The Art of Distributed System Design. United States of America: O'Reilly. Rosen, Michael; Lublinsky, Boris; Smith, Kevin T.; Balcer, Marc J. (2007). Applied SOA: ServiceOriented Architecture and Design Strategies. Indianapolis, Indiana: Wiley Publishing, Inc. Tedeschi, N. (s.f.). Web Services, un ejemplo prctico. Recuperado el 25 de Abril de 2013, de msdn.microsoft: http://msdn.microsoft.com/es-es/library/bb972248.aspx

26