01Computación Distribuida

7/31/2019 01Computacin Distribuida

1/13

Computacin Distribuida | 1

_____________________________________________________________________________________________Derechos Reservados de TechEra e-Learning

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

Captulo 1

Aplicaciones Distribuidas

Este captulo trata acerca de las aplicaciones distribuidas y los servidores de aplicacionesque trabajan con PowerBuilder.

Contenido:


La arquitectura two-tier o cliente/servidor

La arquitectura Distribuida

Servidores de Aplicaciones Soportados por PowerBuilder

Diseando aplicaciones distribuidas


2/13





Hoy en da, la amplia disponibilidad de computadores de bajo costo y el acceso a laconectividad global han impulsado la demanda por una nueva clase de aplicacin, laaplicacin empresarial distribuida. Las aplicaciones distribuidas son usadas por un grannmero de personas alrededor del mundo que estn conectadas a muchos servidores de

aplicaciones y de datos a travs de enlaces permanentes o no permanentes. Estascaractersticas determinan unos requerimientos de la aplicacin que van ms all de lascapacidades de las arquitecturas tradicionales de desarrollo de aplicaciones.

Las aplicaciones distribuidas es la promesa del acceso universal y despliegue de lainformacin en el internet y dentro de las reas de la compaa, construyendo e integrandolas aplicaciones comerciales, o poniendo las aplicaciones en la Web y el Internet, unaarquitectura distribuida centrada en el medio logra hacer la informacin extensamentedisponible y mantenible. La habilidad de desarrollar, desplegar, y manejar las aplicacionescomerciales capaz de apoyar transacciones de gran potencia que procesa en la Web y en laempresa, es de hecho ms fcil con una arquitectura distribuida centrada en los servidoresde aplicaciones. Los servidores de aplicaciones proporcionan las caractersticas robustasque aseguran la escalabilidad y la fiabilidad de los datos trados y procesados.

Hacer que el negocio sea competitivo en el mercado de hoy requiere que las corporacionesconstantemente cambien y se adapten a las nuevas presiones y demandas. Estas demandasson debidas en parte a la globalizacin del mercado comercial, el nmero de compaas queestn unindose (requiriendo una integracin de procesos comerciales y sistemas), y el pasoacelerado del negocio y cambios de tecnologa. El negocio ya no puede enfocarse en lacompeticin regional y los mercados locales porque las mejoras en la tecnologa, lastelecomunicaciones, y el Internet han hecho un mercado abierto al mundo. Los nuevoscompetidores pueden estar tan lejos como al otro lado del mundo, satisfaciendo lasnecesidades del mercado rpidamente. La habilidad de una compaa de identificar lanecesidad por los cambios en el lugar del mercado y ser el primero en hacer esos cambios lepermitir que d alcance a su competicin.

En el mundo comercial de hoy, para una compaa la informacin es un recurso estratgico.Distribuyendo esta informacin a los usuarios apropiados por la compaa, requiereintegracin de datos que se extienden actualmente por los sistemas individuales. Si no seusa la informacin dentro de la compaa para crear una ventaja competitiva, entonces no seest usndo su total potencial. En el mercado que exige ms servicios y valora para afianzarel negocio, una compaa debe asegurar que ms informacin se proporcione a los clientes yempleados, y que la informacin sea til, completa, oportuna, y de una calidad alta.

La Computacin Distribuida

Es una arquitectura dnde una aplicacin se ejecuta en diferentes equipos conectadas sobreuna red. La computacin distribuida, es una arquitectura dividida en capas, en dos capas 3capas. Un Tier es una capa o nivel en una arquitectura de computacin que puede realizar

un nivel particular de proceso. El ambiente del sistema informtico mainframe se describecomo 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 dela computacin distribuida. Las soluciones del software son en cambio dividido en dos o msaplicaciones que trabajan juntos por los espacios del proceso y red. Estas aplicacionestrabajan en una relacin dnde una aplicacin(cliente) requiere los servicios de otraaplicacin (el servidor). El cliente es el iniciador, mientras va pidiendo servicios y recursos deun 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 computacin distribuida es una arquitectura ms compleja que requiere la gestin deredes, middleware, y software de comunicacin, manejar los procesos separados yguardarlos trabajando juntos. En una arquitectura cliente/servidor tpica qu tambin es

conocido como two tiers (dos capas) la arquitectura se procesa en el puesto de trabajo delcliente y el servidor de la base de datos. En esta arquitectura, el cliente se ocupa de la


3/13




presentacin y lgica de la aplicacin mientras que el servidor de la base de datos se ocupadel almacenamiento y recuperacin de los datos. La comunicacin entre las dos capas quenormalmente 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 deaplicaciones, creando tres niveles: el cliente, el servidor de aplicaciones, y el servidor de la

base de datos. El proceso de la aplicacin se hace en el servidor de aplicaciones esto seilustra en la figura 1.1. en este contexto nosotros usamos el trmino el servidor deaplicaciones, aplicndolo ampliamente a la capa media dnde se procesa la aplicacin.

Figura 1.1Computacin Distribuida

Las capas de la Aplicacin

En una arquitectura distribuida, las aplicaciones necesitan dividir la lgica de negocio de lainterfaz, para que este pueda ser invocado por cualquier cliente. Distribuir la aplicacininvolucra dividir la lgica de la aplicacin en objetos y ponerlos en una de tres capas, basadoen su funcionalidad, esto consiste de lo siguiente:

Interfaz de Usuario

Lgica de Negocio

Datos

Interfaz de Usuario

La interfaz de usuario es donde el cliente interacta con la aplicacin. Esto incluye ingreso dedatos, presentacin 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 caracteresmanejado por opciones de men, o tan complejo como un GUI (Interfaz Grfica de usuario)manejado por eventos. La capa de la presentacin no debe contener lgica de negocio o

lgica de direccin de transaccin. Debe contener slo una cantidad mnima de aprobacinde los datos para prevenir las modificaciones de la lgica de presentacin debido a loscambios en otros servicios, a continuacin se detallan algunas caractersticas de la interfaz:

Presionar un botn

Ingresar datos

Buscar datos en una lista

Cambio de colores de los datos

Figura 1.2Interfaz de usuario


4/13




La lgica de Negocio

La capa de las reglas de negocio es donde las decisiones de negocios son resueltas, basadoen un juego de funcionamiento diseado para satisfacer las necesidades de negocio. Estoinvolucra validar la informacin, mientras va guardando la informacin, y buscandoinformacin que los usuarios piden. Algunos ejemplos de lgica de negocio incluyen:

El clculo del porcentaje impuesto.

El proceso de clculo de una planilla.

Generacin de cdigo al empleado.

Validacin de ingreso de un cliente

Los Datos

Los datos incluyen las tareas como la definicin y manipulacin de los datos,almacenamiento de los datos, direccin y recuperacin, proceso de transaccin, yrecopilacin de SQL. Aunque esta capa consiste principalmente en servicios de la base dedatos, otros objetos tambin pueden localizarse en esta capa, estos servicios se ponen enlos servidores, diseado para aumentar al mximo, 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.3Los Datos


5/13




La arquitectura two-tier o Cliente/Servidor

En la arquitectura cliente/servidor, las soluciones de software son divididas en dosaplicaciones que trabajan juntos en una relacin. La implementacin tpica cliente/servidor seusa para describir y personalizar aplicaciones comerciales escritas en C++, o un 4GL comoPowerBuilder para acceder a un servidor de base de datos sobre una red de rea local (LAN)usando SQL.. La aplicacin se usa para resolver los problemas comerciales (figura 1.4).

Figura 1.4La Arquitectura Cliente/Servidor

Ventajas de la arquitectura cliente/servidor

Cuando se introdujo la arquitectura cliente/servidor trajo muchas nuevas capacidades yventajas para los negocios para hacerlos ms productivos y robustos que la computacincentralizada. La filosofa de las soluciones abiertas que vino con la tecnologa delcliente/servidor trajo la interoperabilidad del cross-vendor entre los productos y reducir loscostos en el hardware y software. Los ahorros de costos mejoraron en las corporaciones,pero los beneficios reales fueron habilitar a las aplicaciones para adaptarse rpidamente a

los requerimientos del negocio, y el incremento de la productividad de los desarrolladores yusuarios finales.

Problemas con la arquitectura Cliente/Servidor

Muchos de los problemas asociados con la arquitectura cliente/servidor es que nopermitieron el despliegue de los componentes a las aplicaciones en locacin centralizada,frecuentemente la lgica de negocio requiere ser distribuida a cada computadora cliente,haciendo difcil el mantenimiento y la seguridad. En este ambiente hacer siempre cambiostriviales para una aplicacin en produccin fue problemtico.

Fallas en la seguridad


6/13




En un ambiente cliente/servidor, controlar los accesos a la informacin es extremadamentedifcil. Las fallas en la seguridad fcilmente pueden ocurrir porque la mquina del clientefrecuentemente tiene acceso a los algoritmos para manejar los datos de negocio.

El trabajo de clientes pesados

Cuando toda la lgica de negocio es requerida por una aplicacin esta es distribuida a cadamquina 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 dela ubicacin de la lgica de negocio incluyen :

Los vendedores de DBMS tienen sus propias extensiones del SQL diferentesque hacen sus soluciones ms atractivas, pero reducen la habilidad dereusar el cdigo en un ambiente heterogneo.

Cuando un usuario se conecta a la base de datos, siempre crea una nuevaconexin y no la libera hasta que cierre la aplicacin.

Aumentado las conexiones exige un mayor consumo de los recursos del

servidor.


7/13




Arquitectura Distribuida

La arquitectura distribuida soluciona muchos de los problemas de la arquitecturacliente/servidor, es un camino natural para separar los componentes que manejan la lgicade negocio de la interfaz de usuario de la aplicacin. Centralizando la lgica de negocio enlos servidores de aplicaciones, se puede reducir el trabajo en el cliente y el control de acceso

a la informacin.

Esto a veces es referenciado como el modelo de tres capas. En el modelo de tres capas, elcomponente de la interfaz de usuario reside en la mquina del cliente, mientras que loscomponentes de la lgica de negocio residen en el servidor de aplicaciones. Los datosrequeridos por la aplicacin residen en el servidor de la base de datos.

En una aplicacin de tres capas, la interfaz de usuario es aislado de los cambios internosrealizados a la lgica de negocio almacenados en el servidor. Similarmente, la lgica denegocio no es afectada por los cambios hechos en la aplicacin 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 detallana continuacin :

Ventajas

Clientes delgados

Disminuye la administracin en el cliente

Encapsulacin de la lgica

Mejor Performance

Escalabilidad

Consistencia, control, y seguridad

Reutilizacin de componentes existentes

Posicionamiento para la Web


8/13




Desventajas

Cambios en los hbitos de programacin

Mayor curvas de aprendizaje

Mayor tiempo en diseo y desarrollo

Ms puntos de falla

Estndares de las Arquitecturas Distribuidas

Actualmente se cuenta con tres estndares de arquitecturas distribuidas que son lassiguientes:

Microsoft DCOM

JavaSoft RMI

OMG CORBA

Microsoft DCOM

Microsoft DCOM provee comunicacin de componentes ActiveX a ActiveX en las plataformasWindows (figura 1.6).

Las plataformas soportadas son:

Windows

Los Lenguajes y Componentes soportados :

Componentes ActiveX

Muchas herramientas (por ejemplo, Power++, PowerBuilder, Visual Basic) soporta lacreacin de componentes ActiveX.

Otra cosa que hay que recalcar es que los objetos ActiveX y COM son iguales

Figura 1.6

Microsoft DCOM


9/13




JavaSoft RMI

JavaSoft es una entidad SUN Microsystems. RMI es un CORBA pequeo, Java RMI proveecomunicacin 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 versin RMI sobre IIOP genera IDL desde la interfaz Java, detrs de escena estoes CORBA con interfaz Java.

Plataformas soportadas :

Plataforma independiente

Lenguajes y Componentes soportados :

Solo lenguajes Java.

Figura 1.7Javasoft RMI

OMG CORBA

CORBA son las iniciales de Common Object Request Broker Architecture, es unaarquitectura estndar de objetos distribuidos desarrollado por el Object Management Group(OMG), establecida en 1989, incluye a ms de 800 compaas como IBM, SUN, Oracle,Sybase etc..., pero no incluye a Microsoft, DCOM compite con CORBA, es de vendedoresindependientes, separa la interfaz de la implementacin (figura 1.8).

CORBA - Stubs

Son los objetos proxy locales, ordena los requerimientos de la invocacin de los mtodos,delega la invocacin de los mtodos a la implementacin del objeto remoto, provee la

transparencia de la localizacin, implementa la misma interfaz como el objeto remotodeseado, implementa los mtodos del IDL definido en el lenguaje de programacin delcliente.

Object Request Broker (ORB)

Maneja todas las comunicaciones entre los objetos con los objetos del sistema distribuido :

1. Acepta los requerimientos desde los clientes2. Localiza y activa los objetos destinos

a. Identifica la mquina que ejecuta el objeto servidorb. Pide una conexin al ORB de la mquina del servidor

3. Direcciona los requerimientos y recibe las respuestas


10/13




CORBA Skeleton

Implementa los mecanismo para la invocacin de los requerimientos hacia el servidor y quepuedan ser desencriptados y direccionados a los mtodos correctos, pone en espera a laimplementacin del objeto en tiempo de ejecucin para el ORB, desempaqueta losargumentos de los mtodos, dispone los mtodos para la instancia de la implementacin del

objeto, tambin es conocido como la clase base de la implementacin

Implementacin

Define el comportamiento para todas las operaciones y atributos de las interfaces que estossoporta, es creado usando un lenguaje de programacin o modelo de componente comoPowerBuilder, Java, C, C++, or ActiveX

Servidor

Programa que contiene la implementacin de uno o ms tipos de objetos, provee unambiente para almacenar los objetos, instancia los objetos CORBA, aplica la seguridad,asimismo maneja las Transacciones, el Failover, y el balanceo de carga.

Figura 1.8El Estdar CORBA

Nota.- El significado de las abreviaciones mostradas en esta parte, se encuentran definidasen 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 unservidor EAServer y MTS. En adicin, se pueden crear componentes (u objetos) que seejecutan en cada uno de estos servidores.


11/13




PowerBuilder y EAServer estn totalmente integrados

Una aplicacin PowerBuilder puede actuar como un cliente del EAServer. En adicin elEAServer puede contener un custom class user object (no visual) de PowerBuilder que esejecutado como un componente en la capa intermedia.

EAServer almacena el virtual machine nativo de PowerBuilder. Eso significa que el EAServerpuede comunicarse directamente con los objetos no visuales de PowerBuilder, y viceversa.Los componentes EAServer desarrollados con PowerBuilder pueden tomar muchas ventajasdel uso fcil y la flexibilidad del PowerScript y lo productivo de los objetos de sistema dePowerBuilder.

Los componentes EAServer desarrollados en PowerBuilder se comportan como cualquierotro componente EAServer; por consiguiente, los componentes pueden aprovechar delEAServer el manejo de las transacciones, la interoperabilidad, y el pool de instancias. Amboslos clientes PowerBuilder y no PowerBuilder pueden acceder a los componentesPowerBuilder ejecutados en el EAServer.

Figura 1.9La Arquitectura EAServer

Microsoft Transaction Server (MTS)

Una aplicacin PowerBuilder puede actuar como un cliente para un servidor COM. Elservidor puede ser desarrollado usando PowerBuilder o cualquier herramienta de desarrollode aplicaciones que compile COM y que puede ser ejecutado localmente, en un computadorremoto o en un Microsoft Transaction Server.

Se puede desarrollar un custom class user object conteniendo lgica de negocio enPowerBuilder y los packages de los objetos como un objeto COM. Un servidor COM dePowerBuilder puede incluir uno o ms custom class user objects de PowerBuilder.

Se codifica los user objects en el painter del User Object y se enva al servidor en el painterdel objeto Project. Tambin se puede hacer la distribucin al servidor COM directamente o aun servidor COM local o crear un package MTS desde el painter del Project.


12/13




Figura 1.10La arquitectura del Microsoft Transaction Server (MTS)

Diseando aplicaciones distribuidas

Antes de iniciar el desarrollo de una aplicacin para ser ejecutado en un ambiente distribuido,se necesita disear la aplicacin. A continuacin se provee alguna informacin general de lasconsideraciones que se deben de tomar al disear una aplicacin distribuida.

Tres razones principales para moverse a una arquitectura distribuida

Hacer ms escalable la aplicacinReusar los objetos de una mejor formaPlaneando el desarrollo de aplicaciones Web o Wireless (inalmbricas)

Determinar los requerimientos de la Aplicacin

Una de las claves para el xito en el desarrollo de la aplicacin es el diseo de lo que se va aconstruir antes de iniciar el desarrollo. El mejor camino para inicializar la fase de diseo esidentificar a detalle los requerimientos que la aplicacin debe satisfacer para encontrar lasnecesidades de los usuarios.

Uso de tcnicas orientadas a objetos

El soporte de PowerBuilder para la computacin distribuida es una extensin lgica de estoporque la arquitectura es orientada a objetos. Por esta razn una aplicacin PowerBuilderque usa tcnicas orientadas a objetos, puede ser convertida a una aplicacin distribuida conun mnimo de dificultad.

Cuando se est listo para empezar a desarrollar una aplicacin distribuida, se necesitaempaquetar la lgica de negocio en un custom class user object (no visual). Los customclass user objects proveen lo fundamental para cualquier aplicacin distribuida. Una vezcreados los objetos no visuales, se puede hacer los ajustes requeridos para las aplicacionesdel cliente para acceder a estos objetos remotamente.


13/13

01Computación Distribuida

Documents

Transcript of 01Computación Distribuida