1.2 Evolucion de las tecnologias para el desarrollo de aplicaciones distribuidas.

Hoy en día las compañías no pueden ignorar el grave problema que implica desarrollar y adaptar software al ritmo que imponen los negocios. Los requisitos varían con mucha frecuencia y las aplicaciones no logran ser desarrolladas y/o adaptadas al ritmo requerido. La globalización y fusión de empresas, el crecimiento de Internet, entre otros factores, han acentuado aún más estos problemas llevando el software desarrollado, que normalmente había sido desarrollado para una plataforma específica, a un ambiente distribuido heterogéneo. Esto involucra, en consecuencia, La necesidad de considerar una amplia gama de aspectos como lo son la integración de datos heterogéneos, la interacción entre diversos sistemas, los distintos sistemas operativos, el middleware, las tecnologías web, cuestiones de escalabilidad y performance, por citar algunos de ellos.

La evolución de las tecnologías cliente/servidor sumada al advenimiento de nuevas tecnologías como XML, web services , la plataforma J2EE, la comunicación asíncrona por medio de mensajes, el uso de application servers , son algunos de los conocimientos que permiten llevar a cabo el desarrollo de aplicaciones modernas.

La evolución de las aplicaciones distribuidas se dio de la siguiente forma:

• Aplicaciones monolíticas.
• Arquitectura cliente/servidor.
• Arquitectura de tres capas.
• Arquitectura de N capas.



http://www.tutoriales.itsa.edu.mx/DesarrolloDeAplicaciones/index.php?mod=evolutec&ban=0

1.1.4 Aplicaciones distribuidas.

Mucho tiempo ha transcurrido ya desde que en la década de los ochenta la tecnología de la información comenzara tímidamente a ocupar el lugar que hoy en día posee. En aquellos días, que tal vez algunos veteranos recuerden con cierta nostalgia, la mayoría de los sistemas informáticos estaban constituidos por enormes sistemas centrales que ejecutaban todos las aplicaciones dentro de sí mismos, y en el mejor de los casos los usuarios interactuaban con esas aplicaciones mediante “terminales tontos”, que no eran sino simples pantallas con teclado que permitían enviar caracteres al sistema central y mostrar las respuestas, también basadas en caracteres, que los monstruos generaban y enviaban a través de un cable.

El advenimiento de los ordenadores personales constituyó la primera revolución. Ahora los usuarios disponían de un procesador y de un sistema de almacenamiento autónomo, capaz de procesar datos e incluso de mostrar gráficos por pantalla además de caracteres. Surgieron multitud de aplicaciones “de escritorio” que independizaron a los usuarios de los grandes sistemas y el coste del hardware se redujo a niveles tan aceptables que empresas que no hubieran podido afrontar la inversión en un sistema informático centralizado comenzaron a introducir en sus procesos de negocio la gestión informática de los datos.

Pero en el fondo los modos de ejecución de aplicaciones no habían cambiado. De la ejecución en un sistema centralizado se pasó a la ejecución en sistemas más pequeños e independientes, pero al fin y al cabo las aplicaciones seguían siendo islas incomunicadas entre si, y los usuarios no podían contar más que con las capacidades del propio ordenador para procesar los datos. Por un lado, la necesidad de compartir datos no quedaba resuelta con sistemas independientes, y la opción de las aplicaciones centralizadas seguía siendo la única viable en entornos multiusuario. Por el otro, cuando los datos eran generados por un ordenador central no había forma de tratarlos localmente y toda la potencia de los ordenadores personales no servía para nada.

El avance en las tecnologías de redes comenzó a dibujar un horizonte en el que las aplicaciones se comunicarían entre sí y en el que los procesos de una aplicación se distribuirían entre diferentes equipos, cada uno con características que les permiteran aumentar la eficacia y la disponibilidad de la aplicación. Se comenzó a separar la lógica de las aplicaciones para situarla en el nivel más conveniente y conceptos como “cliente” y “servidor” fueron cobrando cada vez más sentido. Tras algunos años de indecisión, los protocolos de red se estandarizaron y hacia mediados de los años 90 Internet se convirtió en la primera revolución auténtica del siglo XXI, provocando no sólo un vuelco en las relaciones sociales y económicas sino también, por supuesto, un cambio completo de paradigma en la arquitectura de las aplicaciones informáticas.

Las aplicaciones se convierten, así, en aplicaciones distribuidas. Sin arriesgarnos a proporcionar una definición académica que puede encontrarse muy fácilmente en Internet, diremos informalmente que una aplicación distribuida es aquella cuyo objetivo final se alcanza mediante la ejecución de diversos procesos independientes que por lo general se ejecutan en equipos diferentes y que de una forma u otra se pasan datos entre ellos mediante protocolos de comunicaciones bien establecidos.

En esta primera sección examinaremos las formas arquitectónicas (o de diseño) que adquieren las aplicaciones distribuidas. Cada una de ellas plantea ciertas ventajas e inconvenientes que será necesario tener en cuenta a la hora de crear el código para los diferentes componentes de la aplicación.

Características de las aplicaciones distribuidas.

Independientemente de su arquitectura, todas las aplicaciones distribuidas comparten ciertas características que las diferencian notablemente de las aplicaciones centralizadas y de las aplicaciones de escritorio. Conocer esas características y evaluar su impacto en las aplicaciones es primordial para escoger el diseño más adecuado de las mismas. No es cierto que una aplicación se pueda diseñar de cualquier manera.

Aspectos primordiales que han de evaluarse a la hora de diseñar una aplicación distribuida:

1. Concurrencia: De igual forma que en las aplicaciones centralizadas, las aplicaciones distribuidas serán utilizadas por cierto número de usuarios concurrentemente. Aspectos como las transacciones, los bloqueos de recursos o el uso de la CPU de los equipos a los que acceden muchos usuarios son determinantes a la hora de diseñar una arquitectura con la máxima eficacia.

2. Topología de la red: A pesar de que a día de hoy los anchos de banda cada vez son má s amplios, el tráfico de red puede ser un aspecto importante que condicione el tiempo de respuesta de la aplicación. En muchos casos también será necesario tener en cuenta el tipo de red (LAN o WAN), o si la aplicación será o no accesible a través de Internet. La forma de distribuir los procesos de la aplicación tendrá que tomar en consideración el tipo de red que soportará el tráfico de datos.

3. Ubicación de la lógica: Dado que en una aplicación distribuida intervienen varios procesos, será necesario decidir en cuál de los posibles procesos físicos se sitúa cada componente lógico de la aplicación. Mientras que algunos procesos, como la presentación de datos o la recuperación de los mismos, tienen un sitio natural, otros, como la validación o la navegación, pueden ocupar diversos lugares dentro del diagrama que conforma la estructura de la aplicación. En muchas ocasiones la ubicación de los componentes lógicos impacta sobre el rendimiento, sobre la reutilización del código o sobre la facilidad de programación.

4. Homogeneidad de las plataformas: En una aplicación distribuida los sistemas operativos involucrados o los lenguajes de desarrollo utilizados pueden ser un factor a tener en cuenta a la hora de decidir algunos aspectos importantes, como por ejemplo el modo de pasar datos entre procesos. La utilización de estándares puede ser muy útil a la hora de crear aplicaciones distribuidas que permanezcan abiertas a diversos sistemas heterogéneos, pero si las plataformas son similares es posible alcanzar mejor rendimiento sacrificando interoperabilidad.

5. Seguridad: Una aplicación distribuida mantiene procesos que de una forma u otra están a la escucha en una red, lo que aumenta la vulnerabilidad de la aplicación. Será necesario establecer políticas de seguridad que impidan el acceso no autorizado a los procesos. Pedir al usuario un nombre y una contraseña al iniciar el programa es probable que no sea suficiente.

No existe una solución única para todos los problemas. A pesar de que en la actualidad se priman ciertas arquitecturas sobre otras, la realidad es que la decisión final dependerá de todos los factores anteriormente citados, y de otros que a veces no se tienen mucho en cuenta pero que también poseen su importancia, como el coste total de la aplicación o la complejidad de la solución respecto al problema planteado. Ni es recomendable subestimar las necesidades de una aplicación compleja, ni tampoco conviene sobredimensionar la estructura de una aplicación sencilla que puede resolverse con medios más asequibles.

Con las aplicaciones distribuidas el mero análisis funcional de las características de una aplicación ya no es suficiente y es necesario también considerar la distribución y estructura de los procesos involucrados. La tarea del arquitecto de aplicaciones consistirá precisamente en tomar la decisión de diseño más adecuada para resolver el problema, ajustándose lo mejor posible a los requerimientos y tomando en cuenta todos los factores implicados.

Arquitectura de las aplicaciones distribuidas.

En una aplicación distribuida en n-capas los diferentes elementos que integran la aplicación se agrupan de forma lógica según la funcionalidad que reciben o suministran al o desde el resto de los elementos. Así, algunos elementos se limitarán a recibir peticiones de datos mientras que otros interactuarán con el usuario y su función será principalmente la de solicitar a otros elementos la información que el usuario precisa.
Atendiendo al papel que los distintos elementos juegan dentro de la aplicación, distinguimos con claridad tres grupos lógicos en los que podemos agrupar elementos según su funcionalidad:

•La capa de servidor incluye aquellos elementos que se encargan de recibir las peticiones de datos o de acceso a servicios básicos del sistema y de suministrar a otros elementos la información solicitada.
•La capa de negocios encapsula las reglas de acceso a datos y la gestión de procesos internos de la aplicación.
•La capa de presentación se encarga de la lógica necesaria para interactuar con el usuario de la aplicación.

Una vez agrupada la funcionalidad en capas lógicas es fácil relacionar unas con otras. El usuario interactuará con la capa de presentación, solicitando datos o desencadenando acciones. Las solicitudes serán atendidas por la capa de negocios, que se encargará de su gestión o de la traducción necesaria para que la capa de servidor realice la tarea solicitada. Si la capa de servidor debe proporcionar datos estos se devolverán a la capa de negocios, la cual los gestionará o transmitirá a la capa de presentación. La figura 2.1 ilustra este esquema.

Figura 2.1: Esquema lógico de las capas en una aplicación distribuida.

Es importante notar que el esquema que mostramos es un esquema lógico, no físico. El modo de distribuir físicamente las capas (en diferentes ejecutables o DLL, o en diferentes equipos) se corresponderá con el esquema lógico en todo o en parte, pero no necesariamente existirá una correspondencia exacta entre la distribución lógica de los elementos y su distribución física. La capa de negocios podría residir en diferentes máquinas, por ejemplo, o las entidades de negocio y la capa de servidor podrían formar parte de la misma DLL. Más adelante hablaremos de la relación física entre las diversas capas lógicas y estudiaremos cómo los diferentes escenarios nos condicionarán la distribución física de las capas lógicas.

Adicionalmente, en las aplicaciones distribuidas existen otras funcionalidades, como la seguridad o el registro de sucesos, que no son exclusivas de un grupo lógico ya que deben aparecer en todos los elementos de la aplicación.

1.1.3 Aplicaciones de 2,3 y n capas.

La construcción de aplicaciones n-tier (n-capas) distribuidas ha emergido como la arquitectura predominante para la construcción de aplicaciones multiplataforma en la mayor parte de las empresas.

Este cambio radical en los modelos de computación, desde los sistemas monolíticos basados en mainframe y los tradicionales sistemas cliente-servidor, hacia sistemas distribuidos multiplataforma altamente modularles, representa el desarrollo rápido y avance de la investigación en el mundo del desarrollo de aplicaciones, tal y como se pone de manifiesto en las últimas tendencias de las grandes empresas de tecnología, como Sun con su estrategia Sun One, o Microsoft con DotNET (.Net).

El modelo presenta algunas ventajas entre ellas:

• Desarrollos paralelos (en cada capa).
• Aplicaciones más robustas debido al encapsulamient .
• Mantenimiento y soporte más sencillo (es más sencillo cambiar un componente que modificar una aplicación monolítica).
• Mayor flexibilidad (se pueden añadir nuevos módulos para dotar al sistema de nueva funcionalidad)
• Alta escalabilidad.

La principal ventaja de una aplicación distribuida bien diseñada es su buen escalado, es decir, que puede manejar muchas peticiones con el mismo rendimiento simplemente añadiendo más hardware. El crecimiento es casi lineal y no es necesario añadir más código para conseguir esta escalabilidad.

Como tecnología, las arquitecturas de n-capas proporcionan una gran cantidad de beneficios para las empresas que necesitan soluciones flexibles y fiables para resolver complejos problemas inmersos en cambios constantes.

Todas las aplicaciones basadas en n-capas permitirán trabajar con clientes ligeros, tal como navegadores de Internet, WebTV, Teléfonos Inteligentes, PDAs (Personal Digital Assistants o Asistentes Personales Digitales) y muchos otros dispositivos preparados para conectarse a Internet.

De este modo, las arquitecturas de n-capas se están posicionando rápidamente como la piedra angular de los desarrollos de aplicaciones empresariales y las compañías están adoptando esta estrategia a una velocidad de vértigo como mecanismo de posicionamiento en la economía emergente que tiene su base en la red (lo que se ha venido a denominar "Nueva Economía").

Actualmente, la Red (Internet, intranets y extranets) es el ordenador o, como diría Sun Microsystems, el ordenador es la Red. Este paradigma está creando un cambio fundamental en los modelos de computación que, a su vez, proporciona desafíos y oportunidades como nunca antes había se habían producido.

Realmente, los componentes distribuidos de una arquitectura de n-capas es una tecnología esencial para crear la siguiente generación de aplicaciones e-business, aplicaciones que son altamente escalables, fiables y que proporcionan un alto rendimiento y una integración sin fisuras con los sistemas de back-end heredados.

A diferencia de lo que se pudiera pensar, el desarrollo en n-capas no es un producto o un estándar, es un concepto estratégico que ayuda a la construcción y despliegue lógico de un sistema distribuido. Los sistemas de n-capas subdivididos ayudan a facilitar el desarrollo rápido de aplicaciones y su posterior despliegue, con beneficios incrementales fruto de los esfuerzos del desarrollo en paralelo coordinado y del outsourcing inteligente, resultando un enorme decremento del tiempo de desarrollo y de sus costes. Muchas de las aplicaciones de e-business que se utilizan actualmente simplemente utilizan un navegador de Internet como cliente ligero que implementa una interfaz universal. Una arquitectura basada en clientes ligeros desplaza la capa de presentación de la aplicación en el lado del cliente, mientras que la lógica de negocio y los datos residen en el middleware y los servidores de back-end. El diseño para clientes ligeros minimiza los problemas de despliegue de las aplicaciones, mientras que maximiza la accesibilidad a la misma desde una amplia variedad de plataformas heterogéneas. Los frameworks basados en n-capas se crean para obtener las ventajas de los estándares abiertos de la industria que permiten a las aplicaciones resultantes operar en entornos distribuidos multiplataforma.

Caracteristicas.

Las aplicaciones que se construyen con una arquitectura multicapa tienen entre otras las siguientes características:

• Acceso a bases de datos (BD) o Normalmente con BD relacionales

• Transaccionales o Propiedades ACID (Atomicity-Consistency-Isolation-Durability)

• Operaciones atómicas (Atomicity) son operaciones que se completan en su totalidad o no se completan en absoluto. Así, en el ejemplo anterior de la transferencia tanto el crédito como el débito deben haber sido exitosos para que el estado de transformación sea exitoso (para que haga efectos), de otro modo el estado de la transformación falla, y el sistema es regresado a su último estado conocido.

• Transformaciones consistentes (Consistency) preservan la integridad interna de los recursos involucrados. Por ejemplo, el borrar registros de una tabla primaria viola la integridad referencial de la base de datos si hay registros relacionados que concuerden.

• Transformaciones aisladas (Isolation) parecen ocurrir serialmente, una detrás de otra, creando la ilusión de que ninguna transformación está siendo ejecutada al mismo tiempo.

• La durabilidad (Durability) se refiere a la habilidad para almacenar los resultados de una transformación de estado, usualmente en un disco, de tal modo que los resultados de una transformación puedan ser recuperados en caso de una falla del sistema.

• Escalables.

- Deberían poder soportar más carga de trabajo sin necesidad de modificar el software (sólo añadir más máquinas)

• Disponibilidad o Idealmente no deben dejar de prestar servicio

• Seguras.

- No todos los usuarios pueden acceder a la misma funcionalidad

• Integración.

- Es preciso integrar aplicaciones construidas con distintas tecnologías.

• Tipo de interfaz.

- De entorno de ventanas (clientes desktop): normalmente sólo tiene sentido en intranets.

- Web: En Internet y en intranets.

• Separación clara entre la interfaz gráfica y la Capa de componentes.

- Capa de componentes: encapsulan la lógica de negocio.

- Ejemplo => aplicación bancaria

 Capa de componentes: conjunto de clases que nos permiten: crear cuentas, destruirlas, encontrarlas por distintos criterios, hacer transferencias bancarias, etc.

- La capa de componentes debería ser reusable con distintas interfaces gráficas
- En el ejemplo de la aplicación bancaria podría haber dos clientes: uno Web y otro desktop.

Aplicaciones de una Capa.

Las capas dentro de una arquitectura son nada más que un conjunto de servicios especializados que pueden ser accesibles por múltiples clientes y fácilmente reutilizables.

Este tipo de arquitectura se caracteriza por tener en una sola asociación lógica y en ella a la presentación, la lógica de negocios y los datos; que si los ponemos como servicios se convierten en capas, lo veremos más adelante.

Aplicaciones de 1 Capa

Ejemplos de esta arquitectura son desarrollos realizados en Excel, Access, Fox, entre otros.

Aplicaciones de dos capas.

Se caracterizan por tener 2 asociaciones lógicas, que prestan servicios y que a la final son capas.

Arquitectura de 2 capas.

En la primera capa se incluye a la presentación (Interface grafica) y a la lógica de negocios, toda la lógica la escribimos en las formas (en el onClick del botón por ejemplo), y accedemos a un servicio de datos para la gestión de los mismos, por lo general a un servidor de Base de Datos.

Esta arquitectura es comúnmente llamada cliente servidor, puesto que también el programa fuente puede residir en un servidor y muchos cliente pueden acceder a él para ejecutar una copia del programa.

Arquitectura Cliente – Servidor.


Pero se tubiese la siguiente problemática:

¿Qué podría suceder si tuviésemos que hacer cambios en la implementación de la lógica de negocios?

El resultado es la recompilación de toda la aplicación y reinstalación en todos y cada uno de los clientes; y….si los clientes suman como 200 máquinas?

La solución está en separar la lógica de negocios en un servicio aparte, allí es donde aparece la tercera capa.

Aplicaciones de 3 Capas.

Una aplicación de tres capas es una aplicación cuya funcionalidad puede ser segmentada en tres niveles lógicos (capas):

• Los servicios de presentación.
• Los servicios de negocios (Lógica de Negocios) .
• Los servicios de datos.

Arquitectura de Aplicaciones de 3 capas .

La capa de servicios de presentación es responsable de:

• Obtener información del usuario.
• Enviar la información del usuario a los servicios de negocios para su procesamiento.
• Recibir los resultados del procesamiento de los servicios de negocios.
• Presentar estos resultados al usuario.

El nivel de servicios de negocios es responsable de:

• Recibir la entrada del nivel de presentación.
• Interactuar con los servicios de datos para ejecutar las operaciones de negocios para los que la aplicación fue diseñada a automatizar (por ejemplo, la preparación de impuestos por ingresos, el procesamiento de ordenes y así sucesivamente).
• Enviar el resultado procesado al nivel de presentación.

El nivel de servicios de datos es responsable de:

• Almacenar los datos.
• Recuperar los datos.
• Mantener los datos.
• La integridad de los datos.

Arquitectura de 3 capas .

Al ser la primera capa un servicio, se puede inferir que las aplicaciones no solo podrían ser de escritorio, si quisiéramos que nuestra aplicación tenga una interface web, pues solamente bastaría con cambiar la capa de presentación y de allí en adelante nada tiene porque cambiar.

Entonces nuestras páginas web estarían alojadas en un Servidor Web las mismas que se conectan a la lógica de negocios y de allí a los servicios de datos.

Arquitectura de 3 capas con interface Web .


Aplicaciones de n Capas.

Podríamos ir separando nuestra aplicación en mas niveles lógicos, por ejemplo, vamos a querer que nuestra aplicación tenga múltiples interfaces, es decir interface gráfica (standalone o desktop) y también interface Web.

Lo aconsejado en esta circunstancia es separar al Servidor Web encargado de alojar las páginas Web en una capa más. En este caso se tendrían 4 capas.


Arquitectura de 4 capas


Mientras más servicios coloquemos a nuestra aplicación y mientras más escalable lo imaginemos, mas capas lógicas van a irse añadiendo a nuestra arquitectura; allí está el inicio del estudio de las siguientes secciones del curso, LOS PATRONES DE DISEÑO.

• La arquitectura en 3 capas es la más usada
• La arquitectura en 4 capas puede ser más escalable

http://faustol.files.wordpress.com/2007/09/construccion-de-aplicaciones-en-capas.doc.

1.1.2 Aplicaciones Cliente/Servidor.

Clientes y servidores.

El paradigma cliente - servidor divide las aplicaciones comunicantes en dos categorías, dependiendo de si la aplicación se queda en espera de conexiones (servidor) o las inicia (cliente).

En general, una aplicación que inicia una comunicación con otra se la califica como cliente. Los usuarios finales invocan aplicaciones cliente cuando utilizan un servicio de red. Cada vez que se ejecuta una aplicación cliente, esta contacta con el servidor, le envía una solicitud de servicio y espera la respuesta o resultados del servicio. El proceso cliente es el encargado de llevar a cabo la interacción con el usuario y de mostrar los resultados de las peticiones de servicio. En la mayoría de las ocasiones los clientes son mas fáciles de diseñar que los servidores, y no suelen precisar privilegios especiales del sistema para poder funcionar.

Un servidor es un programa que espera peticiones de servicio por parte de un cliente. El servidor recibe la petición del cliente, ejecuta el servicio solicitado y retorna los resultados al cliente. No existe una interacción directa entre el usuario y el servidor, de esto ya se encarga la aplicación cliente.
Desde el punto de vista de una aplicación, el TCP/IP, al igual que muchos otros protocolos de comunicación, implementa un mecanismo fiable para la transmisión de datos entre ordenadores. En concreto, el TCP/IP permite que un programador pueda establecer comunicación de datos entre dos programas de aplicación, tanto si ambos se están ejecutando en la misma máquina, como en maquinas distintas unidas por algún camino físico (una red local, conexión telefónica directa entre computadoras, computadoras conectas a Internet,... ).

Hay que tener presente que el protocolo TCP/IP especifica los detalles y mecanismos para la transmisión de datos entre dos aplicaciones comunicantes, pero no dictamina cuando ni porque deben interactuar ambas aplicaciones, ni siquiera especifica cómo debería estar organizada una aplicación que se va a ejecutar en un entorno distribuido. Es tarea del diseñador de la aplicación distribuida el establecer un protocolo de comunicación y sincronización adecuado.

En la práctica el esquema de programación más utilizado para la implementación de aplicaciones distribuidas es el paradigma cliente - servidor. La motivación fundamental para el empleo del paradigma cliente - servidor surge del problema del rendezvous. Para entender dicho problema, imaginemos un técnico de computadoras que inicia la ejecución de dos programas en máquinas distintas y que tiene la intención de que dichos programas puedan comunicar entre sí. Una vez iniciado el primer programa este envía un mensaje a su contertulio. La conexión con la maquina a la cual va dirigido el mensaje se puede establecer en un intervalo de unos pocos milisegundos (recordar que las computadoras funcionan a velocidades muchos ordenes de magnitud por encima de los humanos), por lo que el proceso recién lanzado determina que su contertulio todavía no existe, con lo cual emite un mensaje de error y finaliza su ejecución. Mientras tanto, el técnico inicia la ejecución del segundo proceso. Desafortunadamente, el segundo proceso no puede comunicar con el primero ya que este ha concluido su ejecución. Incluso si los dos procesos intentan establecer la comunicación continuamente, estos pueden ejecutarse tan rápidamente, que la probabilidad de colisiones es muy alta.

El modelo cliente - servidor da solución al problema del rendezvous (reencuentro). Según este modelo, en cualquier par de aplicaciones comunicantes, una de las partes implicadas en la comunicación debe iniciar su ejecución y esperar (indefinidamente) hasta que la otra parte contacte con ella. Esta solución es importante, ya que el TCP/IP no proporciona ningún mecanismo que automáticamente lance procesos para atender mensajes entrantes, debe de existir un proceso en espera que sea capaz de atender dichos mensajes (peticiones de servicio).
Muchos administradores hacen que ciertos programas de comunicaciones se inicien automáticamente cuando el sistema arranca, de este modo se aseguran que la computadora estará preparada para aceptar ciertas solicitudes de servicio. Después de iniciar su ejecución, cada uno de estos programas se queda en espera de la siguiente petición para el servicio que oferta.

El modelo cliente - servidor.

TCP es un protocolo orientado a conexión. No hay relaciones maestro/esclavo. Las aplicaciones, sin embargo, utilizan un modelo cliente/servidor en las comunicaciones.
Un servidor es una aplicación que ofrece un servicio a usuarios de Internet; un cliente es el que pide ese servicio. Una aplicación consta de una parte de servidor y una de cliente, que se pueden ejecutar en el mismo o en diferentes sistemas.

Los usuarios invocan la parte cliente de la aplicación, que construye una solicitud para ese servicio y se la envía al servidor de la aplicación que usa TCP/IP como transporte.
El servidor es un programa que recibe una solicitud, realiza el servicio requerido y devuelve los resultados en forma de una respuesta. Generalmente un servidor puede tratar múltiples peticiones(múltiples clientes) al mismo tiempo.

Figura: El modelo de aplicación cliente/servidor.

Algunos servidores esperan las solicitudes en puertos bien conocidos de modo que sus clientes saben a que zócalo IP deben dirigir sus peticiones. El cliente emplea un puerto arbitrario para comunicarse. Los clientes que se quieren comunicar con un servidor que no usa un puerto bien conocido tienen otro mecanismo para saber a qué puerto dirigirse. Este mecanismo podría usar un servicio de registro como Portmap, que utiliza un puerto bien conocido.

http://neo.lcc.uma.es/evirtual/cdd/tutorial/aplicacion/cliente-servidor.html
http://www.ctv.es/USERS/carles/PROYECTO/cap3/cap3.html

1.1.1 Aplicaciones Monoliticas.

Migración de Aplicaciones al Modelo Cliente Servidor

Muchas de las aplicaciones de oficina utilizadas actualmente poseen buenos modelos de datos e interfaces realmente claras que permitieron en su momento un significativo aumento de la productividad. El problema es que ven afectada su posibilidad de crecimiento por características tecnológicas de base que dificultan el acceso a alta velocidad dentro de la Red Local e impiden el acceso desde fuentes remotas como Internet y otras redes no locales.

Tal es el caso de la mayoría de las aplicaciones desarrolladas en los últimos años en que el acceso a datos se efectuaba a partir de aplicaciones monolíticas que concentran en una sola capa tanto la interfaz visual como lo métodos de acceso a datos, lo que comúnmente se conoce como modelos Cliente - Cliente.

Estas aplicaciones Cliente- Cliente concentran toda la actividad en los equipos de los usuarios, dejando al los servidores la labor de meros reservorios de datos compartidos.

Así ante cada petición de datos, el servidor devuelve archivos completos que luego son procesados por el equipo cliente, para obtener el resultado.

Por ejemplo, suponiendo que una base de cliente tuviera un tamaño medio de 5Mb y se efectúa una búsqueda muy simple de un cliente en particular, el servidor no efectuará la búsqueda por sí sino que devuelve la tabla de 5Mb completa, luego el equipo del usuario procesa la búsqueda en su equipo para seleccionar 1 registro de digamos unos 1Kb y descarta el resto de la información.

Los principales defectos de este modelo son:

• Requieren más y mejor Hardware en las estaciones de trabajo.
• Son infinitamente más lentos en el procesamiento de peticiones sencillas.
• Ocupan mayor ancho de banda, provocando congestionamiento en la Red Local.
• Requieren habilitar el acceso real a la carpeta de datos para todos los usuarios de la aplicación.
• Su actualización es más costosa.
• No permiten el acceso en línea desde fuera de la Red Local.

O’Lach Multi Media ofrece servicios de migración de aplicaciones al modelo Cliente servidor, a partir de grupos de trabajo cooperativos con los desarrolladores originales, el equipo de desarrollo de la empresa contratante o la interacción de nuestro equipo de desarrollo con los usuarios calificados y el personal de sistemas.

De esta forma, se logran mejorar las capacidades de los sistemas existentes mediante su división en capas (Reservorio, Acceso a Datos e Interfaz Visual) aprovechando todas las aptitudes de la aplicación y ampliando sus posibilidades de uso y crecimiento gracias a la implementación del modelo Cliente Servidor.

http://www.mitecnologico.com/Main/EvolucionAplicacionesInformaticas

1.1 EVOLUCION DE LAS APLICACIONES INFORMATICAS.

1.1 Evolucion de las Aplicaciones Informaticas.

Aplicaciones.

En sus orígenes la programación de los ordenadores era hecho sólo, para y por los mismos científicos que las construían para propósitos muy específicos. El cálculo de la trayectoria de los proyectiles usados en la II Guerra Mundial, y posteriormente usos muy parecidos, hasta que mucho después que fue utilizada en el Censo de los Estados Unidos fue reconociéndose su valor en el campo administrativo donde estuvo hasta hace 2 décadas, cuando gracias a la Computadora Personal pasaron al dominio público donde con tantas necesidades fueron surgiendo las aplicaciones diversas para cada oficio.

A diferencia de algunos años atrás, hoy existe una infinidad de aplicaciones para satisfacer desde diversiones o entretenimiento de niños hasta sofisticados programas de investigación científica; más sin embargo, para las necesidades de la mayoría de los mortales que trabajan en Instituciones o Empresas y aún para los particulares existe un número preciso de aplicaciones, que como herramientas no deben faltar en ninguna computadora de uso personal.

La evolución de las aplicaciones informáticas se dio debido a los siguientes factores:

1. Trabajo a distancia.
2. Compartir información.
3. Accesibilidad.
4. Seguridad en la protección de la información (tener la base de datos particionada en dos o más nodos).
5. Independencia lugares.

En la actualidad cualquier aplicación cuenta generalmente con tres partes diferenciadas:

1. Una interfaz de usuario: Elemento con el que interacciona el usuario de la aplicación, ejecutando acciones, introduciendo u obteniendo información.
2. Lógica ó Reglas de negocio: Son las que procesan la información para generar los resultados que persiguen, siendo el elemento fundamental que diferencia unas aplicaciones de otras.
3. Gestión de datos: Se ocupa del almacenamiento y recuperación de la información.

http://html.rincondelvago.com/evolucion-de-la-informatica_4.html
http://www.tutoriales.itsa.edu.mx/DesarrolloDeAplicaciones/index.php?mod=evoluciondeaplicaciones&ban=0

UNIDAD 1 PANORAMA GRAL. DE LAS APLICACIONES DISTRIBUIDAS.

INSTITUTO TECNOLOGICO DE CIUDAD ALTAMIRANO.



MATERIA:
DESARROLLO DE APLICACIONES PARA AMBIENTE DISTRIBUIDO.

PROFESOR:
MC. Ángel Sixtos Solís.

ALUMNA:
Deysi Yuri Hernández Ríos.

Cd. Altamirano, Gro. Febrero 2011.