Instituto Tecnológico de León

Materia:

Ingeniería de Software

Alumno:

Samáno Paz Juan

Soto Trujillo Luis Ricardo

Trabajo

Arquitecturas y ejemplos

Profesor

Ing. Sáez de Nanclares Rodríguez Ruth

ORBMisión del ORB

Una parte fundamental de la arquitectura CORBA es el ORB, componente software cuyo fin es facilitar la comunicación 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 característica del ORB es la transparencia, cómo facilita la comunicación cliente/servidor. Generalmente, el ORB oculta lo siguiente: Ubicación de los objetos. El cliente no sabe dónde se encuentra el objeto destino.

Puede residir en un proceso diferente en otra máquina a través de la red, o dentro del mismo proceso

Implementación de los objetos. El cliente no sabe cómo esta implementado el objeto remoto, en qué lenguaje de programación o de scripts está escrito, o el sistema operativo y el hardware, sobre el que se ejecuta.

Estado de ejecución del objeto. Cuando el cliente lanza una petición sobre un objeto remoto, no necesita saber si el objeto está en ese momento en ejecución, y listo para aceptar peticiones. El ORB de forma transparente inicializa el objeto en caso de ser necesario, antes de enviarle la petición

Mecanismos de comunicación de los objetos. El cliente no sabe qué mecanismos de comunicación (por ejemplo, TCP/IP, memoria compartida, llamada a método local) utiliza el ORB para enviar la petición al objeto y retorna la respuesta al cliente.

Estas características del ORB permiten a los desarrolladores de aplicaciones preocuparse más por las cuestiones propias del dominio de sus aplicaciones y desentenderse de las cuestiones de programación a bajo nivel del sistema distribuido.La idea de un ORB es la siguiente, cuando un componente de aplicación quiere utilizar un servicio proporcionado por otro componente, primero debe obtener una referencia para el objeto que proporciona ese servicio. Después de obtenerla, el componente puede llamar a los métodos en ese objeto, accediendo así a los servicios proporcionados por éste; evidentemente el programador del componente cliente debe saber en tiempo de compilación que métodos están 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 aplicación establecer conectividad entre ellos.Cuando se crea un objeto CORBA también 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 estándar o propietario. Los clientes pueden obtener las referencias a objetos de muy diversas formas:

En la creación de objetos. El cliente puede crear un nuevo objeto y conseguir así una referencia al objeto.

A través del servicio de directorio. El cliente puede invocar a un servicio de búsqueda de cualquier tipo, con el fin de obtener referencias a objetos. Estos servicios no crean nuevos objetos, sino que almacenan referencias a objetos e información asociada (por ejemplo, nombres y propiedades) para los objetos existentes, y los proporcionan previa solicitud.

Convirtiendo la referencia al objeto en una cadena y recuperándola. Una aplicación 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. Más tarde, la cadena puede ser recuperada y transformada nuevamente en una referencia a un objeto por el ORB.

Marshaling

Después de que el componente de una aplicación haya obtenido la referencia a un objeto, el componente puede invocar métodos en dicho objeto. Generalmente, dichos métodos tienen ciertos parámetros como entrada, y retornan otros parámetros como salida. El ORB es el encargado de clasificar esos parámetros; es decir, trasformar los parámetros procedentes del componente que invoca los métodos remotos, a un formato estándar, denominado formato de red y después al formato entendible por el componente que tiene dichos métodos. El ORB se encarga así mismo de desclasificar los parámetros de salida retornados por el método, convirtiéndolos de la representación de la red al formato que entiende este componente invocador.El proceso total de clasificación tiene lugar sin intervención alguna por parte del programador. Una aplicación cliente simplemente invoca el método remoto deseado, que para él tiene la apariencia de un método local, y el resultado es retornado o se lanza una excepción, de nuevo, como si se tratase de un método local.

Independencia de la plataformaUn resultado del proceso de clasificación y desclasificación es, que debido a que los parámetros se convierten en la transmisión a un formato independiente de la plataforma, la comunicación entre componentes es independiente de la plataforma. Esto significa que, por ejemplo, un cliente ejecutándose en un sistema Macintosh puede invocar métodos en un servidor ejecutándose en un sistema Unix. Además de la independencia del sistema operativo utilizado, las diferencias de hardware, como puede ser el orden de los bytes más significativos o el tamaño de una palabra, son así mismo irrelevantes, ya que el ORB hace automáticamente la conversión necesaria.

Arquitectura CORBALa especificación CORBA detalla las interfaces y características del componente ORB de la OMA. La última actualización 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 características de otros sistemas orientados a objetos, incluyendo la herencia de interfaces y el polimorfismo. Lo que hace a CORBA más 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 técnicas y lenguajes de modelado de objetos, cabe destacar la notación estándar UML (Unified Modeling Language), cuya última actualización es UML 1.2 a mediados de 1998. UML es una evolución de las metodologías 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 diseños orientados a objetos, consistente en palabras, textos, gráficos y símbolos.Cabe destacar, sin embargo, que UML es sólo un estándar de notación. Esencialmente, define un cierto número 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, también considerado en la metodología 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 interactúen distintas tecnologías(heterogéneo) se encargue de comunicar e integrar los datos de diversa índole, y haciéndolo de forma conectada o desconectada(asíncrona o síncrono), facilitando la integración de aplicaciones y plataformas.”

Eso sería básicamente la definición que también 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 administración y/o configuración se vuelve mas fácil en estos productos dependiendo de la complejidad de las caracteristicas de las aplicaciones a integrar. El uso de determinado software o implementación 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.

SOALa ruta que se ha definido en Arquitectura de Sistemas para el desarrollo de soluciones o sistemas informáticos es SOA (Arquitectura Orientada a Servicios), la cual esta basada en la implementación de Servicios de Negocio, esto es; bloques funcionales de negocio que se pueden integrar, y compartir en distintas aplicaciones. La principal tecnología para implementar servicios SOA es WebServices, y es la que se recomienda, se promueve y exige, pero hay que tener cuidado, porque fácilmente 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 estándares SOA, a grandes rasgos: debe corresponder a una funcionalidad del Negocio bien acotada

(self cointained), independiente de la implementación tecnológica e independiente de los sistemas operacionales que lo soportan (loose coupling), y además debe poder ser compartido y reutilizado por otros procesos o sistemas (reuse). Por otro lado, un servicio SOA podría ser implementado con otras tecnologías, como HttpService, Mensajería, Ajax (DWR), etc, pero nuevamente para ser considerado como tal, debe cumplir los estándares SOA.

SOA es una tecnología 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 (orquestación de servicios), pero principalmente sirven para implementar aplicaciones Web. IBM lo ha promovido en el desarrollo de aplicaciones Web, en combinación 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 dinámicas (“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 tecnología, los WebServices pueden ser mal implementados, si no se siguen los estándares y buenas prácticas, que existen para el desarrollo de Servicios. Uno de los problemas más 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 más de un sistema, son las que se deben convertir en Servicios.

Modelo OSILa descripción esquemática de las diversas capas que componen este modelo es como sigue:

Capa física -1-

("Physical layer"); es la encargada de transmitir los bits de información por la línea o medio utilizado para la transmisión. Se ocupa de las propiedades físicas y características eléctricas de los diversos componentes; de la velocidad de transmisión, si esta es uni o bidireccional (simplex, duplex o flull-duplex). También de aspectos mecánicos de las conexiones y terminales, incluyendo la interpretación de las señales eléctricas.

Como resumen de los cometidos de esta capa, podemos decir que se encarga de transformar un paquete de información binaria ("Frame") en una sucesión de impulsos adecuados al medio físico utilizado en la transmisión. Estos impulsos pueden ser eléctricos (transmisión por cable); electromagnéticos (transmisión Wireless) o luminosos (transmisión óptica). Cuando actúa en modo recepción el trabajo es inverso; se encarga de transformar estos impulsos en paquetes de datos binarios que serán entregados a la capa de enlace (ver a continuación).

Por ejemplo: este nivel define la medidas del cable coaxial Ethernet y de los conectores BNC utilizados. Otro ejemplo de estándares 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 física a la capa de red (que veremos a continuación). 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.

Además del direccionamiento local, se ocupa de la detección y control de errores ocurridos en la capa física, del control del acceso a dicha capa y de la integridad de los datos y fiabilidad de la transmisión. Para esto agrupa la información 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 algún datagrama se ha corrompido se envía un mensaje de control al remitente solicitando su reenvío. El protocolo PPP es ejemplo de esta capa.

La capa de enlace puede considerarse dividida en dos subcapas:

Control lógico de enlace LLC("Logical Link Control") define la forma en que los datos son transferidos sobre el medio físico, proporcionando servicio a las capas superiores.

Control de acceso al medio MAC ("Medium Access Control"). Esta subcapa actúa 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 dirección física contenida en el hardware de la tarjeta es conocida como dirección MAC. Su principal tarea (que le proporciona el nombre -control de acceso-) consiste en arbitrar la utilización del medio físico para facilitar que varios equipos puedan competir simultáneamente por la utilización de un mismo medio de transporte. El mecanismo CSMA/CD ("Carrier Sense Multiple Access with Collision Detection") utilizado en Ethernet es un típico ejemplo de esta subcapa.

Capa de Red -3-

("Network layer"). Esta capa se ocupa de la transmisión de los datagramas (paquetes) y de encaminar cada uno en la dirección adecuada ("Routing"), tarea esta que puede ser complicada en redes grandes como Internet, pero no se ocupa para nada de los errores o pérdidas 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

actualización 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 categoría se encuentra el protocolo IP.

Conmutación ("Switching"): Esta parte es la encargada de intercambiar información de conectividad específica 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 actualización de ruta. En esta categoría se encuentra el protocolo ICMP responsable de generar mensajes cuando ocurren errores en la transmisión 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 envío de datos. P.E. esta capa define cuando y como debe utilizarse la retransmisión para asegurar su llegada. Para ello divide el mensaje recibido de la capa de sesión en trozos (datagramas), los numera correlativamente y los entrega a la capa de red para su envío. Durante la recepción, si la capa de Red utiliza el protocolo IP, la capa de Transporte es responsable de reordenar los paquetes recibidos fuera de secuencia. También puede funcionar en sentido inverso multiplexando una conexión 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 típico de protocolo usado en esta capa es TCP que con su homólogo 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 también en Internet por algunos programas de aplicación.

Capa de Sesión -5-

("Session Layer"). Es una extensión de la capa de transporte que ofrece control de diálogo y sincronización, aunque en realidad son pocas las aplicaciones que hacen uso de ella. Por ejemplo, las comunicaciones de Internet no la utilizan.

Capa de Presentación -6-

En teoría esta capa "presenta" los datos a la capa de aplicación cogiendo los datos recibidos y transformándolos en formatos como texto imágenes y sonido. Como veremos a continuación, 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 opción para el formato de datos, a pesar de lo cual, el protocolo OSI sigue negociando un esquema de codificación (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 presentación es la que se encarga de configurar el terminal para conectar a un servidor de características particulares.

Capa de Aplicación -7-

("Application layer"). Esta capa describe como hacen su trabajo los programas de aplicación (navegadores, clientes de correo, terminales remotos, transferencia de ficheros etc). Por ejemplo, esta capa implementa la operación con ficheros del sistema. Por un lado interactúan con la capa de presentación; por otro representan la interfaz con el usuario, entregándole la información y recibiendo los comandos que dirigen la comunicación.

Ejemplos de protocolos utilizados por los programas de esta capa son HTTP, SMTP, POP, IMAP etc.

Estilos Arquitectónicos (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 jerárquica) 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