Computación Distribuida | 1

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

_____________________________________________________________________________________________
Derechos Reservados de TechEra e-Learning
Este producto solo puede ser usado para uso personal y no para otros fines.
 Computación Distribuida | 2

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
_____________________________________________________________________________________________
Derechos Reservados de TechEra e-Learning
Este producto solo puede ser usado para uso personal y no para otros fines.
 Computación Distribuida | 3

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

_____________________________________________________________________________________________
Derechos Reservados de TechEra e-Learning
Este producto solo puede ser usado para uso personal y no para otros fines.
 Computación Distribuida | 4

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

_____________________________________________________________________________________________
Derechos Reservados de TechEra e-Learning
Este producto solo puede ser usado para uso personal y no para otros fines.
 Computación Distribuida | 5

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

_____________________________________________________________________________________________
Derechos Reservados de TechEra e-Learning
Este producto solo puede ser usado para uso personal y no para otros fines.
 Computación Distribuida | 6

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.

_____________________________________________________________________________________________
Derechos Reservados de TechEra e-Learning
Este producto solo puede ser usado para uso personal y no para otros fines.
 Computación Distribuida | 7

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

_____________________________________________________________________________________________
Derechos Reservados de TechEra e-Learning
Este producto solo puede ser usado para uso personal y no para otros fines.
 Computación Distribuida | 8

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

_____________________________________________________________________________________________
Derechos Reservados de TechEra e-Learning
Este producto solo puede ser usado para uso personal y no para otros fines.
 Computación Distribuida | 9

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

_____________________________________________________________________________________________
Derechos Reservados de TechEra e-Learning
Este producto solo puede ser usado para uso personal y no para otros fines.
 Computación Distribuida | 10

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.

_____________________________________________________________________________________________
Derechos Reservados de TechEra e-Learning
Este producto solo puede ser usado para uso personal y no para otros fines.
 Computación Distribuida | 11

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.

_____________________________________________________________________________________________
Derechos Reservados de TechEra e-Learning
Este producto solo puede ser usado para uso personal y no para otros fines.
 Computación Distribuida | 12

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.

_____________________________________________________________________________________________
Derechos Reservados de TechEra e-Learning
Este producto solo puede ser usado para uso personal y no para otros fines.
 Computación Distribuida | 13

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.

_____________________________________________________________________________________________
Derechos Reservados de TechEra e-Learning
Este producto solo puede ser usado para uso personal y no para otros fines.