Computación Distribuida | 1

Computación Distribuida | 1

_____________________________________________________________________________________________ Derechos Reservados de TechEra e-Learning

Este producto solo puede ser usado para uso personal y no para otros fines.

Capítulo 1 Aplicaciones Distribuidas Este capítulo trata acerca de las aplicaciones distribuidas y los servidores de aplicaciones que trabajan con PowerBuilder. Contenido:

• Aplicaciones Distribuidas • La arquitectura two-tier o cliente/servidor • La arquitectura Distribuida • Servidores de Aplicaciones Soportados por PowerBuilder • Diseñando aplicaciones distribuidas




Aplicaciones Distribuidas Hoy en día, la amplia disponibilidad de computadores de bajo costo y el acceso a la conectividad global han impulsado la demanda por una nueva clase de aplicación, la aplicación empresarial distribuida. Las aplicaciones distribuidas son usadas por un gran número de personas alrededor del mundo que están conectadas a muchos servidores de aplicaciones y de datos a través de enlaces permanentes o no permanentes. Estas características determinan unos requerimientos de la aplicación que van más allá de las capacidades de las arquitecturas tradicionales de desarrollo de aplicaciones. Las aplicaciones distribuidas es la promesa del acceso universal y despliegue de la información en el internet y dentro de las áreas de la compañía, construyendo e integrando las aplicaciones comerciales, o poniendo las aplicaciones en la Web y el Internet, una arquitectura distribuida centrada en el medio logra hacer la información extensamente disponible y mantenible. La habilidad de desarrollar, desplegar, y manejar las aplicaciones comerciales capaz de apoyar transacciones de gran potencia que procesa en la Web y en la empresa, es de hecho más fácil con una arquitectura distribuida centrada en los servidores de aplicaciones. Los servidores de aplicaciones proporcionan las características robustas que aseguran la escalabilidad y la fiabilidad de los datos traídos y procesados. Hacer que el negocio sea competitivo en el mercado de hoy requiere que las corporaciones constantemente cambien y se adapten a las nuevas presiones y demandas. Estas demandas son debidas en parte a la globalización del mercado comercial, el número de compañías que están uniéndose (requiriendo una integración de procesos comerciales y sistemas), y el paso acelerado del negocio y cambios de tecnología. El negocio ya no puede enfocarse en la competición regional y los mercados locales porque las mejoras en la tecnología, las telecomunicaciones, y el Internet han hecho un mercado abierto al mundo. Los nuevos competidores pueden estar tan lejos como al otro lado del mundo, satisfaciendo las necesidades del mercado rápidamente. La habilidad de una compañía de identificar la necesidad por los cambios en el lugar del mercado y ser el primero en hacer esos cambios le permitirá que dé alcance a su competición. En el mundo comercial de hoy, para una compañía la información es un recurso estratégico. Distribuyendo esta información a los usuarios apropiados por la compañía, requiere integración de datos que se extienden actualmente por los sistemas individuales. Si no se usa la información dentro de la compañía para crear una ventaja competitiva, entonces no se está usándo su total potencial. En el mercado que exige más servicios y valora para afianzar el negocio, una compañía debe asegurar que más información se proporcione a los clientes y empleados, y que la información sea útil, completa, oportuna, y de una calidad alta. La Computación Distribuida Es una arquitectura dónde una aplicación se ejecuta en diferentes equipos conectadas sobre una red. La computación distribuida, es una arquitectura dividida en capas, en dos capas ó 3 capas. Un Tier es una capa o nivel en una arquitectura de computación que puede realizar un nivel particular de proceso. El ambiente del sistema informático mainframe se describe como una sola arquitectura de una capa porque todo el proceso tiene lugar en una solo lugar. Una vez que nosotros movemos el proceso de una sola capa, nosotros estamos tratando de la computación distribuida. Las soluciones del software son en cambio dividido en dos o más aplicaciones que trabajan juntos por los espacios del proceso y red. Estas aplicaciones trabajan en una relación dónde una aplicación(cliente) requiere los servicios de otra aplicación (el servidor). El cliente es el iniciador, mientras va pidiendo servicios y recursos de un servidor para completar sus tareas. El servidor espera pasivamente por estas demandas, mientras está realizando las tareas necesarias y devolviendo cualquier resultado al cliente. La computación distribuida es una arquitectura más compleja que requiere la gestión de redes, middleware, y software de comunicación, manejar los procesos separados y guardarlos trabajando juntos. En una arquitectura cliente/servidor típica qué también es conocido como two tiers (dos capas) la arquitectura se procesa en el puesto de trabajo del cliente y el servidor de la base de datos. En esta arquitectura, el cliente se ocupa de la




presentación y lógica de la aplicación mientras que el servidor de la base de datos se ocupa del almacenamiento y recuperación de los datos. La comunicación entre las dos capas que normalmente usa SQL se hace mientras que el cliente requiere los servicios del servidor. La arquitectura three tier (tres capas) agrega una capa intermedia, el servidor de aplicaciones, creando tres niveles: el cliente, el servidor de aplicaciones, y el servidor de la base de datos. El proceso de la aplicación se hace en el servidor de aplicaciones esto se ilustra en la figura 1.1. en este contexto nosotros usamos el término el servidor de aplicaciones, aplicándolo ampliamente a la capa media dónde se procesa la aplicación. Figura 1.1 Computación Distribuida

Las capas de la Aplicación En una arquitectura distribuida, las aplicaciones necesitan dividir la lógica de negocio de la interfaz, para que este pueda ser invocado por cualquier cliente. Distribuir la aplicación involucra dividir la lógica de la aplicación en objetos y ponerlos en una de tres capas, basado en su funcionalidad, esto consiste de lo siguiente:

• Interfaz de Usuario • Lógica de Negocio • Datos

Interfaz de Usuario La interfaz de usuario es donde el cliente interactúa con la aplicación. Esto incluye ingreso de datos, presentación de los datos, mantenimiento de los datos, y comienzo de los procesos. La interfaz de usuario puede ser tan simple como un sistema basado en caracteres manejado por opciones de menú, o tan complejo como un GUI (Interfaz Gráfica de usuario) manejado por eventos. La capa de la presentación no debe contener lógica de negocio o lógica de dirección de transacción. Debe contener sólo una cantidad mínima de aprobación de los datos para prevenir las modificaciones de la lógica de presentación debido a los cambios en otros servicios, a continuación se detallan algunas características de la interfaz:

• Presionar un botón • Ingresar datos • Buscar datos en una lista • Cambio de colores de los datos

Figura 1.2 Interfaz de usuario




La lógica de Negocio La capa de las reglas de negocio es donde las decisiones de negocios son resueltas, basado en un juego de funcionamiento diseñado para satisfacer las necesidades de negocio. Esto involucra validar la información, mientras va guardando la información, y buscando información que los usuarios piden. Algunos ejemplos de lógica de negocio incluyen:

• El cálculo del porcentaje impuesto. • El proceso de cálculo de una planilla. • Generación de código al empleado. • Validación de ingreso de un cliente

Los Datos Los datos incluyen las tareas como la definición y manipulación de los datos, almacenamiento de los datos, dirección y recuperación, proceso de transacción, y recopilación de SQL. Aunque esta capa consiste principalmente en servicios de la base de datos, otros objetos también pueden localizarse en esta capa, estos servicios se ponen en los servidores, diseñado para aumentar al máximo, compartiendo entre todos los usuarios (ver figura 1.3). Algunos ejemplos de servicios de los datos incluyen:

• Consulta de datos • Manejo de objetos de la base de datos • Almacenamiento de datos

Figura 1.3 Los Datos




La arquitectura two-tier o Cliente/Servidor En la arquitectura cliente/servidor, las soluciones de software son divididas en dos aplicaciones que trabajan juntos en una relación. La implementación típica cliente/servidor se usa para describir y personalizar aplicaciones comerciales escritas en C++, o un 4GL como PowerBuilder para acceder a un servidor de base de datos sobre una red de área local (LAN) usando SQL.. La aplicación se usa para resolver los problemas comerciales (figura 1.4). Figura 1.4 La Arquitectura Cliente/Servidor

Ventajas de la arquitectura cliente/servidor Cuando se introdujo la arquitectura cliente/servidor trajo muchas nuevas capacidades y ventajas para los negocios para hacerlos más productivos y robustos que la computación centralizada. La filosofía de las soluciones abiertas que vino con la tecnología del cliente/servidor trajo la interoperabilidad del cross-vendor entre los productos y reducir los costos en el hardware y software. Los ahorros de costos mejoraron en las corporaciones, pero los beneficios reales fueron habilitar a las aplicaciones para adaptarse rápidamente a los requerimientos del negocio, y el incremento de la productividad de los desarrolladores y usuarios finales. Problemas con la arquitectura Cliente/Servidor Muchos de los problemas asociados con la arquitectura cliente/servidor es que no permitieron el despliegue de los componentes a las aplicaciones en locación centralizada, frecuentemente la lógica de negocio requiere ser distribuida a cada computadora cliente, haciendo difícil el mantenimiento y la seguridad. En este ambiente hacer siempre cambios triviales para una aplicación en producción fue problemático. Fallas en la seguridad




En un ambiente cliente/servidor, controlar los accesos a la información es extremadamente difícil. Las fallas en la seguridad fácilmente pueden ocurrir porque la máquina del cliente frecuentemente tiene acceso a los algoritmos para manejar los datos de negocio. El trabajo de clientes pesados Cuando toda la lógica de negocio es requerida por una aplicación esta es distribuida a cada máquina cliente, el cliente debe de tener el poder necesario para procesar y para manejarlo. Esto pone una carga indebida en los recursos del cliente. Los problemas adicionales con una arquitectura cliente/servidor que son independientes de la ubicación de la lógica de negocio incluyen :

• Los vendedores de DBMS tienen sus propias extensiones del SQL diferentes que hacen sus soluciones más atractivas, pero reducen la habilidad de reusar el código en un ambiente heterogéneo.

• Cuando un usuario se conecta a la base de datos, siempre crea una nueva conexión y no la libera hasta que cierre la aplicación.

• Aumentado las conexiones exige un mayor consumo de los recursos del servidor.




Arquitectura Distribuida La arquitectura distribuida soluciona muchos de los problemas de la arquitectura cliente/servidor, es un camino natural para separar los componentes que manejan la lógica de negocio de la interfaz de usuario de la aplicación. Centralizando la lógica de negocio en los servidores de aplicaciones, se puede reducir el trabajo en el cliente y el control de acceso a la información. Esto a veces es referenciado como el modelo de tres capas. En el modelo de tres capas, el componente de la interfaz de usuario reside en la máquina del cliente, mientras que los componentes de la lógica de negocio residen en el servidor de aplicaciones. Los datos requeridos por la aplicación residen en el servidor de la base de datos. En una aplicación de tres capas, la interfaz de usuario es aislado de los cambios internos realizados a la lógica de negocio almacenados en el servidor. Similarmente, la lógica de negocio no es afectada por los cambios hechos en la aplicación de la interfaz de usuario (figura 1.5). Figura 1.5 La Arquitectura Distribuida

Ventajas y Desventajas de la Arquitectura Distribuida Trabajar con la arquitectura distribuida brinda muchas ventajas para nuestros desarrollos, pero debemos de tener en cuenta las desventajas de estas mismas, estos temas se detallan a continuación : Ventajas

• Clientes delgados • Disminuye la administración en el cliente • Encapsulación de la lógica • Mejor Performance • Escalabilidad • Consistencia, control, y seguridad • Reutilización de componentes existentes • Posicionamiento para la Web




Desventajas

• Cambios en los hábitos de programación • Mayor curvas de aprendizaje • Mayor tiempo en diseño y desarrollo • Más puntos de falla

Estándares de las Arquitecturas Distribuidas Actualmente se cuenta con tres estándares de arquitecturas distribuidas que son las siguientes:

• Microsoft DCOM • JavaSoft RMI • OMG CORBA

Microsoft DCOM Microsoft DCOM provee comunicación de componentes ActiveX a ActiveX en las plataformas Windows (figura 1.6). Las plataformas soportadas son:

• Windows Los Lenguajes y Componentes soportados :

• Componentes ActiveX • Muchas herramientas (por ejemplo, Power++, PowerBuilder, Visual Basic) soporta la

creación de componentes ActiveX. Otra cosa que hay que recalcar es que los objetos ActiveX y COM son iguales Figura 1.6 Microsoft DCOM




JavaSoft RMI JavaSoft es una entidad SUN Microsystems. RMI es un CORBA pequeño, Java RMI provee comunicación de Java a Java en cualquier plataforma (figura 1.7). RMI fue creado para direccionar lo concerniente para que CORBA no fuera complicado. Una nueva versión RMI sobre IIOP genera IDL desde la interfaz Java, detrás de escena esto es CORBA con interfaz Java. Plataformas soportadas :

• Plataforma independiente Lenguajes y Componentes soportados :

• Solo lenguajes Java. Figura 1.7 Javasoft RMI

OMG CORBA CORBA son las iniciales de Common Object Request Broker Architecture, es una arquitectura estándar de objetos distribuidos desarrollado por el Object Management Group (OMG), establecida en 1989, incluye a más de 800 compañías como IBM, SUN, Oracle, Sybase etc..., pero no incluye a Microsoft, DCOM compite con CORBA, es de vendedores independientes, separa la interfaz de la implementación (figura 1.8). CORBA - Stubs Son los objetos proxy locales, ordena los requerimientos de la invocación de los métodos, delega la invocación de los métodos a la implementación del objeto remoto, provee la transparencia de la localización, implementa la misma interfaz como el objeto remoto deseado, implementa los métodos del IDL definido en el lenguaje de programación del cliente. Object Request Broker (ORB) Maneja todas las comunicaciones entre los objetos con los objetos del sistema distribuido :

1. Acepta los requerimientos desde los clientes 2. Localiza y activa los objetos destinos

a. Identifica la máquina que ejecuta el objeto servidor b. Pide una conexión al ORB de la máquina del servidor

3. Direcciona los requerimientos y recibe las respuestas




CORBA – Skeleton Implementa los mecanismo para la invocación de los requerimientos hacia el servidor y que puedan ser desencriptados y direccionados a los métodos correctos, pone en espera a la implementación del objeto en tiempo de ejecución para el ORB, desempaqueta los argumentos de los métodos, dispone los métodos para la instancia de la implementación del objeto, también es conocido como la clase base de la implementación Implementación Define el comportamiento para todas las operaciones y atributos de las interfaces que estos soporta, es creado usando un lenguaje de programación o modelo de componente como PowerBuilder, Java, C, C++, or ActiveX Servidor Programa que contiene la implementación de uno o más tipos de objetos, provee un ambiente para almacenar los objetos, instancia los objetos CORBA, aplica la seguridad, asimismo maneja las Transacciones, el Failover, y el balanceo de carga. Figura 1.8 El Estádar CORBA

Nota.- El significado de las abreviaciones mostradas en esta parte, se encuentran definidas en las primeras hojas de este libro. Servidores de Aplicaciones Soportados por PowerBuilder PowerBuilder provee soporte para dos servidores de aplicaciones: • Sybase Enterprise Application Server (EAServer) • Microsoft Transaction Server (MTS) Los desarrolladores PowerBuilder pueden crear clientes que invoquen los servicios de un servidor EAServer y MTS. En adición, se pueden crear componentes (u objetos) que se ejecutan en cada uno de estos servidores.




PowerBuilder y EAServer están totalmente integrados Una aplicación PowerBuilder puede actuar como un cliente del EAServer. En adición el EAServer puede contener un custom class user object (no visual) de PowerBuilder que es ejecutado como un componente en la capa intermedia. EAServer almacena el virtual machine nativo de PowerBuilder. Eso significa que el EAServer puede comunicarse directamente con los objetos no visuales de PowerBuilder, y viceversa. Los componentes EAServer desarrollados con PowerBuilder pueden tomar muchas ventajas del uso fácil y la flexibilidad del PowerScript y lo productivo de los objetos de sistema de PowerBuilder. Los componentes EAServer desarrollados en PowerBuilder se comportan como cualquier otro componente EAServer; por consiguiente, los componentes pueden aprovechar del EAServer el manejo de las transacciones, la interoperabilidad, y el pool de instancias. Ambos los clientes PowerBuilder y no PowerBuilder pueden acceder a los componentes PowerBuilder ejecutados en el EAServer. Figura 1.9 La Arquitectura EAServer

Microsoft Transaction Server (MTS) Una aplicación PowerBuilder puede actuar como un cliente para un servidor COM. El servidor puede ser desarrollado usando PowerBuilder o cualquier herramienta de desarrollo de aplicaciones que compile COM y que puede ser ejecutado localmente, en un computador remoto o en un Microsoft Transaction Server. Se puede desarrollar un custom class user object conteniendo lógica de negocio en PowerBuilder y los packages de los objetos como un objeto COM. Un servidor COM de PowerBuilder puede incluir uno o más custom class user objects de PowerBuilder. Se codifica los user objects en el painter del User Object y se envía al servidor en el painter del objeto Project. También se puede hacer la distribución al servidor COM directamente o a un servidor COM local o crear un package MTS desde el painter del Project.




Figura 1.10 La arquitectura del Microsoft Transaction Server (MTS)

Diseñando aplicaciones distribuidas Antes de iniciar el desarrollo de una aplicación para ser ejecutado en un ambiente distribuido, se necesita diseñar la aplicación. A continuación se provee alguna información general de las consideraciones que se deben de tomar al diseñar una aplicación distribuida. Tres razones principales para moverse a una arquitectura distribuida Hacer más escalable la aplicación Reusar los objetos de una mejor forma Planeando el desarrollo de aplicaciones Web o Wireless (inalámbricas) Determinar los requerimientos de la Aplicación Una de las claves para el éxito en el desarrollo de la aplicación es el diseño de lo que se va a construir antes de iniciar el desarrollo. El mejor camino para inicializar la fase de diseño es identificar a detalle los requerimientos que la aplicación debe satisfacer para encontrar las necesidades de los usuarios. Uso de técnicas orientadas a objetos El soporte de PowerBuilder para la computación distribuida es una extensión lógica de esto porque la arquitectura es orientada a objetos. Por esta razón una aplicación PowerBuilder que usa técnicas orientadas a objetos, puede ser convertida a una aplicación distribuida con un mínimo de dificultad. Cuando se está listo para empezar a desarrollar una aplicación distribuida, se necesita empaquetar la lógica de negocio en un custom class user object (no visual). Los custom class user objects proveen lo fundamental para cualquier aplicación distribuida. Una vez creados los objetos no visuales, se puede hacer los ajustes requeridos para las aplicaciones del cliente para acceder a estos objetos remotamente.




Seleccionar los objetos remotos cuidadosamente Cualquier custom class user object (CCUO) puede actuar como un objeto remoto en un servidor de la capa media, sin embargo, no todos los objetos no visuales son buenos candidatos para un proceso distribuido. Desde que la red y la performance del servidor se pueden degradar si se despliegan muchos objetos en los servidores remotos. Se necesita ser selectivo sobre que objetos se decide hacer remotos. Resumen Las grandes cantidades de información que manejan las empresas, la seguridad que se requiere, el fácil acceso, el poder reusar objetos, el optimizar las conexiones a las bases de datos, el trabajar todos contra todos, ha permitido que hoy en día podamos hablar de procesos distribuidos el poder acceder a nuestra empresa desde cualquier punto y a cualquier hora. La arquitectura Distribuida nos permite poder desarrollar aplicaciones que tengan todas estas características que hemos mencionado, ahora las empresas pueden trabajar mejor tomando en consideración que las cosas del mañana se desarrollan hoy.

Computación Distribuida | 1

Documents

Transcript of Computación Distribuida | 1