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

Instituto Tecnolgico de Len

Materia: Ingeniera de Software Alumno:

Samno Paz Juan Soto Trujillo Luis Ricardo Trabajo Arquitecturas y ejemplos Profesor Ing. Sez de Nanclares Rodrguez Ruth

ORB
Misin del ORB Una parte fundamental de la arquitectura CORBA es el ORB, componente software cuyo fin es facilitar la comunicacin entre objetos. El ORB se encarga de enviar las peticiones a los objetos y retornar las respuestas a los clientes que invocan las peticiones. La principal caracterstica del ORB es la transparencia, cmo facilita la comunicacin cliente/servidor. Generalmente, el ORB oculta lo siguiente: Ubicacin de los objetos. El cliente no sabe dnde se encuentra el objeto destino. Puede residir en un proceso diferente en otra mquina a travs de la red, o dentro del mismo proceso Implementacin de los objetos. El cliente no sabe cmo esta implementado el objeto remoto, en qu lenguaje de programacin o de scripts est escrito, o el sistema operativo y el hardware, sobre el que se ejecuta. Estado de ejecucin del objeto. Cuando el cliente lanza una peticin sobre un objeto remoto, no necesita saber si el objeto est en ese momento en ejecucin, y listo para aceptar peticiones. El ORB de forma transparente inicializa el objeto en caso de ser necesario, antes de enviarle la peticin Mecanismos de comunicacin de los objetos. El cliente no sabe qu mecanismos de comunicacin (por ejemplo, TCP/IP, memoria compartida, llamada a mtodo local) utiliza el ORB para enviar la peticin al objeto y retorna la respuesta al cliente. Estas caractersticas del ORB permiten a los desarrolladores de aplicaciones preocuparse ms por las cuestiones propias del dominio de sus aplicaciones y desentenderse de las cuestiones de programacin a bajo nivel del sistema distribuido. La idea de un ORB es la siguiente, cuando un componente de aplicacin quiere utilizar un servicio proporcionado por otro componente, primero debe obtener una referencia para el objeto que proporciona ese servicio. Despus de obtenerla, el componente puede llamar a los mtodos en ese objeto, accediendo as a los servicios proporcionados por ste; evidentemente el programador del componente cliente debe saber en tiempo de compilacin que mtodos estn disponibles por un objeto servidor particular. La principal responsabilidad de ORB es resolver las peticiones por las referencias a objetos, posibilitando a los componentes de aplicacin establecer conectividad entre ellos. Cuando se crea un objeto CORBA tambin se crea una referencia para l. Cuando es utilizada por un cliente, la referencia siempre -durante toda la vida del objeto-, se refiere a dicho objeto para la que fue creada. En otras palabras, la referencia a un objeto siempre hace referencia a un nico objeto. Las referencias a objetos son inmutables y opacas, de esta forma un cliente no puede manipular una referencia y modificarla. Las referencias a objetos pueden tener un formato estndar o propietario. Los clientes pueden obtener las referencias a objetos de muy diversas formas:

En la creacin de objetos. El cliente puede crear un nuevo objeto y conseguir as una referencia al objeto. A travs del servicio de directorio. El cliente puede invocar a un servicio de bsqueda de cualquier tipo, con el fin de obtener referencias a objetos. Estos servicios no crean nuevos objetos, sino que almacenan referencias a objetos e informacin asociada (por ejemplo, nombres y propiedades) para los objetos existentes, y los proporcionan previa solicitud.

Convirtiendo la referencia al objeto en una cadena y recuperndola. Una aplicacin puede solicitar al ORB que convierta una referencia a un objeto en una cadena, y esta cadena almacenarla en un fichero o base de datos. Ms tarde, la cadena puede ser recuperada y transformada nuevamente en una referencia a un objeto por el ORB.

Marshaling Despus de que el componente de una aplicacin haya obtenido la referencia a un objeto, el componente puede invocar mtodos en dicho objeto. Generalmente, dichos mtodos tienen ciertos parmetros como entrada, y retornan otros parmetros como salida. El ORB es el encargado de clasificar esos parmetros; es decir, trasformar los parmetros procedentes del componente que invoca los mtodos remotos, a un formato estndar, denominado formato de red y despus al formato entendible por el componente que tiene dichos mtodos. El ORB se encarga as mismo de desclasificar los parmetros de salida retornados por el mtodo, convirtindolos de la representacin de la red al formato que entiende este componente invocador. El proceso total de clasificacin tiene lugar sin intervencin alguna por parte del programador. Una aplicacin cliente simplemente invoca el mtodo remoto deseado, que para l tiene la apariencia de un mtodo local, y el resultado es retornado o se lanza una excepcin, de nuevo, como si se tratase de un mtodo local.

Independencia de la plataforma Un resultado del proceso de clasificacin y desclasificacin es, que debido a que los parmetros se convierten en la transmisin a un formato independiente de la plataforma, la comunicacin entre componentes es independiente de la plataforma. Esto significa que, por ejemplo, un cliente ejecutndose en un sistema Macintosh puede invocar mtodos en un servidor ejecutndose en un sistema Unix. Adems de la independencia del sistema operativo utilizado, las diferencias de hardware, como puede ser el orden de los bytes ms significativos o el tamao de una palabra, son as mismo irrelevantes, ya que el ORB hace automticamente la conversin necesaria.

Arquitectura CORBA
La especificacin CORBA detalla las interfaces y caractersticas del componente ORB de la OMA. La ltima actualizacin hasta el momento es CORBA 2.2. En la Figura 2, se muestra la arquitectura CORBA y como se relacionan sus distintos componentes.

La arquitectura CORBA est orientada a objetos. Los objetos CORBA presentan muchas caractersticas de otros sistemas orientados a objetos, incluyendo la herencia de interfaces y el polimorfismo. Lo que hace a CORBA ms interesante es que proporciona estas capacidades, incluso cuando es utilizado en lenguajes no orientados a objeto como C o COBOL, aunque CORBA trabaja particularmente bien con los lenguajes orientados a objeto como C++ y Java. Dentro de las nuevas tcnicas y lenguajes de modelado de objetos, cabe destacar la notacin estndar UML (Unified Modeling Language), cuya ltima actualizacin es UML 1.2 a mediados de 1998. UML es una evolucin de las metodologas orientadas a objeto anteriores, como Booch, OMT, y OOSE, tratando de unificar lo mejor de cada una de ellas. UML ha dado lugar un potente lenguaje visual, para expresar diseos orientados a objetos, consistente en palabras, textos, grficos y smbolos. Cabe destacar, sin embargo, que UML es slo un estndar de notacin. Esencialmente, define un cierto nmero de diagramas que se pueden dibujar para describir un sistema y el significado de dichos diagramas. UML no describe el proceso a seguir al desarrollar el software, tambin considerado en la metodologa formal tradicional.

Middleware

El middleware es un software o conjunto de componentes desarrollados que sirven para integrar aplicaciones, como lo es un Servidor de Transacciones o Servidor de Aplicaciones, el cual en un ambiente donde interacten distintas tecnologas(heterogneo) se encargue de comunicar e integrar los datos de diversa ndole, y hacindolo de forma conectada o desconectada(asncrona o sncrono), facilitando la integracin de aplicaciones y plataformas. Eso sera bsicamente la definicin que tambin puedes haber escuchado el termino Middle Tier que es lo mismo, pero mejor quiero compartirles que tipo de software puede ser considerado Middleware. Por ejemplo existe un servicio de Windows que se llama Enterprise Services, en cual permite poner componentes .net, componentes COM, mensajeria en colas(MSMQ), todo esto permitiendo el uso de Pool de Conexiones a multiples bases de datos, transacciones a nivel de componente (no importando la interaccion de multiples RDBMS). Existen softwares como JBOSS, IBM WebSphere, Sybase EAServer, que proporcionan similares servicios a los mencionados de Enterprise Servicesm, la diferencia es que la administracin y/o configuracin se vuelve mas fcil en estos productos dependiendo de la complejidad de las caracteristicas de las aplicaciones a integrar. El uso de determinado software o implementacin depender de la arquitectura que se decida utilizar o la cual sea mas factible a la empresa, economica y funcionalmente hablando. Microsoft tambien ofrece BizTalk Server para poder hacer uso a un nivel superior de las bondades de Enterprise Services y hacer las integraciones de sistemas mas facilmente.

SOA
La ruta que se ha definido en Arquitectura de Sistemas para el desarrollo de soluciones o sistemas informticos es SOA (Arquitectura Orientada a Servicios), la cual esta basada en la implementacin de Servicios de Negocio, esto es; bloques funcionales de negocio que se pueden integrar, y compartir en distintas aplicaciones. La principal tecnologa para implementar servicios SOA es WebServices, y es la que se recomienda, se promueve y exige, pero hay que tener cuidado, porque fcilmente se puede cometer errores, sino se asumen los siguientes principios.

Un Webservice no necesariamente es un Servicio SOA. Un Servicio SOA no necesariamente tiene que ser implementado como WebService.

Para que un WebService se considere un Servicio SOA, debe cumplir con los estndares SOA, a grandes rasgos: debe corresponder a una funcionalidad del Negocio bien acotada

(self cointained), independiente de la implementacin tecnolgica e independiente de los sistemas operacionales que lo soportan (loose coupling), y adems debe poder ser compartido y reutilizado por otros procesos o sistemas (reuse). Por otro lado, un servicio SOA podra ser implementado con otras tecnologas, como HttpService, Mensajera, Ajax (DWR), etc, pero nuevamente para ser considerado como tal, debe cumplir los estndares SOA. SOA es una tecnologa madura, y respaldada por los principales expertos y empresas, por ejemplo Gartner dentro de su HypeCycle (diagrama de madurez) ya el 2009 lo tiene entrando al nivel de plena productividad Los servicios SOA sirven para integrar sistemas, para construir procesos de negocio (orquestacin de servicios), pero principalmente sirven para implementar aplicaciones Web. IBM lo ha promovido en el desarrollo de aplicaciones Web, en combinacin con frameworks como Struts, Spring, lo ha promovido para el desarrollo de aplicaciones web rich (Build rich Java Web applications with Apache Wink and Ajax Febrero 2010) , y para el desarrollo de aplicaciones Web dinmicas (Build RESTful Web services and dynamic Web applications with the multi-tier architecture Junio 2009). Oracle lo contempla en su Arquitectura de aplicaciones; Oracle ADF.

Pero como toda tecnologa, los WebServices pueden ser mal implementados, si no se siguen los estndares y buenas prcticas, que existen para el desarrollo de Servicios. Uno de los problemas ms comunes es pretender que toda funcionalidad de un sistema se puede convertir en un servicio (WebService), y la verdad es que el enfoque es otro, las funcionalidades de Negocio, que pueden involucrar ms de un sistema, son las que se deben convertir en Servicios.

Modelo OSI
La descripcin esquemtica de las diversas capas que componen este modelo es como sigue: Capa fsica -1("Physical layer"); es la encargada de transmitir los bits de informacin por la lnea o medio utilizado para la transmisin. Se ocupa de las propiedades fsicas y caractersticas elctricas de los diversos componentes; de la velocidad de transmisin, si esta es uni o bidireccional (simplex, duplex o flull-duplex). Tambin de aspectos mecnicos de las conexiones y terminales, incluyendo la interpretacin de las seales elctricas. Como resumen de los cometidos de esta capa, podemos decir que se encarga de transformar un paquete de informacin binaria ("Frame") en una sucesin de impulsos adecuados al medio fsico utilizado en la transmisin. Estos impulsos pueden ser elctricos (transmisin por cable); electromagnticos (transmisin Wireless) o luminosos (transmisin ptica). Cuando acta en modo recepcin el trabajo es inverso; se encarga de transformar estos impulsos en paquetes de datos binarios que sern entregados a la capa de enlace (ver a continuacin).

Por ejemplo: este nivel define la medidas del cable coaxial Ethernet y de los conectores BNC utilizados. Otro ejemplo de estndares relativos a esta capa son RS-232 para comunicaciones serie y X.21 Capa de enlace -2("Data Link layer"). Puede decirse que esta capa traslada los mensajes hacia/desde la capa fsica a la capa de red (que veremos a continuacin). Especifica como se organizan los datos cuando se transmiten en un medio particular. P.E. esta capa define como son los cuadros ("Frames"), las direcciones y las sumas de control ("Checksum") de los paquetes Ethernet. Adems del direccionamiento local, se ocupa de la deteccin y control de errores ocurridos en la capa fsica, del control del acceso a dicha capa y de la integridad de los datos y fiabilidad de la transmisin. Para esto agrupa la informacin a transmitir en bloques ("Frames"), e incluye a cada uno una suma de control que permitir al receptor comprobar su integridad. Los datagramas recibidos son comprobados por el receptor. Si algn datagrama se ha corrompido se enva un mensaje de control al remitente solicitando su reenvo. El protocolo PPP es ejemplo de esta capa. La capa de enlace puede considerarse dividida en dos subcapas:

Control lgico de enlace LLC("Logical Link Control") define la forma en que los datos son transferidos sobre el medio fsico, proporcionando servicio a las capas superiores. Control de acceso al medio MAC ("Medium Access Control"). Esta subcapa acta como controladora del hardware subyacente (el adaptador de red). De hecho el controlador de la tarjeta de red es denominado a veces "MAC driver", y la direccin fsica contenida en el hardware de la tarjeta es conocida como direccin MAC. Su principal tarea (que le proporciona el nombre -control de acceso-) consiste en arbitrar la utilizacin del medio fsico para facilitar que varios equipos puedan competir simultneamente por la utilizacin de un mismo medio de transporte. El mecanismo CSMA/CD ("Carrier Sense Multiple Access with Collision Detection") utilizado en Ethernet es un tpico ejemplo de esta subcapa.

Capa de Red -3("Network layer"). Esta capa se ocupa de la transmisin de los datagramas (paquetes) y de encaminar cada uno en la direccin adecuada ("Routing"), tarea esta que puede ser complicada en redes grandes como Internet, pero no se ocupa para nada de los errores o prdidas de paquetes. Por ejemplo, define la estructura de direcciones y rutas de Internet. A este nivel se utilizan dos tipos de paquetes: paquetes de datos y paquetes de

actualizacin de ruta. Como consecuencia esta capa puede considerarse subdividida en dos:

Transporte. Encargada de encapsular los datos a transmitir (de usuario). Utiliza los paquetes de datos. En esta categora se encuentra el protocolo IP. Conmutacin ("Switching"): Esta parte es la encargada de intercambiar informacin de conectividad especfica de la red (su actividad es raramente percibida por el usuario). Los routers son dispositivos que trabajan en este nivel y se benefician de estos paquetes de actualizacin de ruta. En esta categora se encuentra el protocolo ICMP responsable de generar mensajes cuando ocurren errores en la transmisin y de un modo especial de eco que puede comprobarse mediante PING .

Capa de Transporte -4("Transport layer"). Esta capa se ocupa de garantizar la fiabilidad del servicio, describe la calidad y naturaleza del envo de datos. P.E. esta capa define cuando y como debe utilizarse la retransmisin para asegurar su llegada. Para ello divide el mensaje recibido de la capa de sesin en trozos (datagramas), los numera correlativamente y los entrega a la capa de red para su envo. Durante la recepcin, si la capa de Red utiliza el protocolo IP, la capa de Transporte es responsable de reordenar los paquetes recibidos fuera de secuencia. Tambin puede funcionar en sentido inverso multiplexando una conexin de transporte entre diversas conexiones de datos. Este permite que los datos provenientes de diversas aplicaciones compartan el mismo flujo hacia la capa de red. Un ejemplo tpico de protocolo usado en esta capa es TCP que con su homlogo IP de la capa de Red, configuran la suite TCP/IP utilizada en Internet, aunque existen otros como UDP ("Universal Datagram Protocol") una capa de transporte utilizada tambin en Internet por algunos programas de aplicacin. Capa de Sesin -5("Session Layer"). Es una extensin de la capa de transporte que ofrece control de dilogo y sincronizacin, aunque en realidad son pocas las aplicaciones que hacen uso de ella. Por ejemplo, las comunicaciones de Internet no la utilizan. Capa de Presentacin -6En teora esta capa "presenta" los datos a la capa de aplicacin cogiendo los datos recibidos y transformndolos en formatos como texto imgenes y sonido. Como veremos a continuacin, en realidad esta capa puede estar ausente, ya que son pocas las aplicaciones que hacen uso de ella.

Actualmente el panorama ha cambiado; solo existe una opcin para el formato de datos, a pesar de lo cual, el protocolo OSI sigue negociando un esquema de codificacin (el nico disponible). En Internet, el nico servicio que utiliza esta capa es TELNET, que precisamente es un servicio de acceso a servidores desde terminales remotos. En este caso, la capa de presentacin es la que se encarga de configurar el terminal para conectar a un servidor de caractersticas particulares.

Capa de Aplicacin -7("Application layer"). Esta capa describe como hacen su trabajo los programas de aplicacin (navegadores, clientes de correo, terminales remotos, transferencia de ficheros etc). Por ejemplo, esta capa implementa la operacin con ficheros del sistema. Por un lado interactan con la capa de presentacin; por otro representan la interfaz con el usuario, entregndole la informacin y recibiendo los comandos que dirigen la comunicacin. Ejemplos de protocolos utilizados son HTTP, SMTP, POP, IMAP etc. por los programas de esta capa

Estilos Arquitectnicos (Sist. Distribuidos / Arquitecturas Peer To Peer)

Cada uno de los pares descubre a sus otros pares y establecen conexiones al mismo nivel (no de forma jerrquica) cooperando para lograr un objetivo determinado

Bibliografia
http://www.ramonmillan.com/tutoriales/corba.php http://elmercarias.wordpress.com/2010/10/05/%C2%BFque-es-middleware/ http://www.soaagenda.com/journal/articulos/arquitectura-orientada-a-servicios/ http://www.zator.com/Hardware/H12_2.htm