Instituto Tecnológico De Durango In g. En Sistemas Computacionales
Reporte de Investigación de Arquitectura Web Web y Programación Cliente – Servidor de capa y !
"ateria# Pro Programación gramación We Web Catedr$tico %a&# Armstrong Aramburo Cristabel Alumno %a&# Zamora De Santiago Everardo Everardo 'o( Control# 11040447
Introducción Una arquitectura simplificada de la web, es una típica arquitectura cliente/servidor, en la cual de un lado se encuentra el cliente que está compuesto de browsers web, capaces de mostrar y solicitar documentos sobre una red. Opcionalmente, el cliente puede estar acompañado por aplicaciones externas usando una presentación del documento, o parte de este. l otro lado de la arquitectura web !ace del servidor, compuesto por el servidor web, cuya función es atender los pedidos del cliente web por documentos almacenados en el sistema de arc!ivos de la plataforma donde se encuentra instalado. Una importante característica de la web es que "l fue proyectado para funcionar en topolo#ía de $nternet, está compuesta por una #ran variedad de computadoras que interact%an entre sí. $nternet tiene un espacio #lobal y se comunica por canales p%blicos de comunicación sin restricción cundo es continuo. &e esta forma el web incorpora naturalmente la característica de ser un ambiente distribuido y multiplataforma n este contexto, el estudio se centra en los aspectos arquitectónicos y tecnoló#icos de los componentes responsables de la presentación de la aplicación. stos componentes son los que residen en el cliente 'unto con los que interact%an con ellos desde el lado del servidor. (as tecnolo#ías que no se apliquen a este aspecto no son tratadas aquí.
)rquitectura *eb (a arquitectura de una aplicación *eb es similar a la de un sitio *eb, se basa en el modelo +liente/ervidor. +omo en el caso del sitio *eb, tenemos el nave#ador en la parte cliente, el servidor *eb en la parte del servidor y una conexión de red. -ero en las aplicaciones *eb !ay que considerar que existe una ló#ica de ne#ocio sensible a las interacciones del usuario. Ori#inalmente la *eb %nicamente contaba con contenidos estáticos. (a necesidad de ofrecer servicios más sofisticados a trav"s de este medio llevó a soluciones tecnoló#icas que permitiesen cierto #rado de interacción con el servidor más allá de solicitar una pá#ina en concreto. (os +$s fueron las primeras opciones en este sentido. -ermitían interactuar con códi#o e'ecutable en el servidor desde el nave#ador. ) trav"s de la U( solicitada por el nave#ador se pasaban los parámetros de entrada para el códi#o e'ecutable y este devolvía una pá#ina 012( con la respuesta. ste mismo m"todo se utili3a en tecnolo#ías similares como $)-$, 4)-$ o 5ava. ) medida que la sofisticación de los servicios ofrecidos vía *eb !a ido aumentando, se !a ido añadiendo, al menos a nivel ló#ico y no necesariamente a nivel físico, nuevos elementos en la arquitectura de las aplicaciones *eb 6por e'emplo el servidor de aplicaciones, bases de datos,...7. (as nuevas disposiciones de elementos se !an basado en patrones arquitectónicos del contexto de las aplicaciones distribuidas. Patrón arquitectónico: un patrón arquitectónico es cualquier esquema relativo a la configuración de un sistema en su conjunto, no relativo a una parte de él. Por lo tanto aplica a una escala en la que la unidad de organización es mucho mayor que la clase y más próxima a los programas o ejecutales.
n las aplicaciones distribuidas, partiendo del modelo +liente/ervidor, al aumentar la comple'idad de los procesos se acaba con el denominado problema del 8+liente -esado9. )l poner la mayor parte del códi#o necesario para llevar a cabo los procesos en el cliente, este debe descar#ar del servidor los datos necesarios para llevarlos a cabo. sto es muy ineficiente por dos ra3ones principales: ; ;
(a red sufre una #ran car#a debido a las m%ltiples descar#as de cada uno de los clientes. (a #ran dependencia en el rendimiento del !ardware en el lado del cliente.
(a arquitectura en tres niveles divide la funcionalidad para optimi3ar el uso de recursos. e consi#uen soluciones muc!o más flexibles y escalables. (os tres niveles son: ; +liente: +ontiene los componentes de usuario que son %nicos para cada uno de ellos. sto es la ló#ica de aplicación específica del usuario y la interfa3. ; )plicación: +onstituye un entorno multiusuario y mantiene las partes compartidas de la aplicación. (as operaciones con un uso intensivo de datos deben e'ecutarse en este nivel. 1ambi"n es punto donde se puede llevar a cabo la coordinación de transacciones 6operaciones de m%ltiples usuarios7. ; )lmacenamiento: s nivel de la base de datos. e especiali3a en dar un servicio de persistencia a los datos de la aplicación y permite mane'ar #randes vol%menes de ellos.
-ro#ramación +liente < ervidor de = y > capas l modelo cliente/servidor es un modelo de comunicación de computadores en el cual el computador cliente solicita servicios al computador servidor por medio de mensa'es. (a diferencia entre el cliente y el servidor es que el cliente es el que inicia el contacto y el servidor es el que responde a dic!a solicitud de conexión. +lientes y servidores son entidades físicas diferentes que operan en con'unto a trav"s de una red para reali3ar una tarea. (a arquitectura cliente/servidor está compuesta por tres elementos básicos, el cliente, el servidor y el middleware. +aracterísticas del modelo +liente/ervidor ervicio: +liente/servidor es fundamentalmente una relación entre procesos e'ecutados en computadores distintos. l proceso del servidor !ace de "ste un proveedor de servicios. l cliente es un consumidor de servicios. ecursos compartidos: Un servidor puede atender a muc!os clientes al mismo tiempo y re#ular su acceso a recursos compartidos. -rotocolos asim"tricos: ntre cliente y servidor se establece una relación de n a ?. on siempre los clientes los que inician el diálo#o al solicitar un servicio. @ los servidores a#uardan pasivamente las solicitudes de los clientes. 1ransparencia de ubicación: l servidor es un proceso que puede residir en el mismo equipo que el proceso cliente o en un equipo distinto a lo lar#o de una red. uele ocultarse a los clientes la ubicación del servidor mediante el
redireccionamiento de las llamadas de servicio en caso de ser necesario. Un pro#rama puede ser un cliente, un servidor o ambos a la ve3. 2e3cla e i#ualdad: l software ideal de cliente/servidor es independiente del !ardware y de la plataforma de software del sistema operativo. e debe poder me3clar e i#ualar las plataformas del cliente y del servidor. $ntercambio basado en mensa'es: +lientes y servidores tienen ba'o acoplamiento e interact%an a trav"s de un mecanismo determinado de transmisión de mensa'es. l mensa'e es el mecanismo de entre#a para las solicitudes y de respuestas de servicios. 6e considera como mensa'e tanto a la solicitud como a la respuesta7. Aacilidad de scalabilidad: (os sistemas cliente/servidor pueden escalarse !ori3ontal o verticalmente. $nte#ridad: l códi#o del servidor y los datos se conservan centralmente, lo que resulta en un mantenimiento de menor costo y en la protección de los datos de la inte#ridad de los datos compartidos. ) su ve3, los clientes mantienen su individualidad e independencia. Benta'as y desventa'as del modelo +liente/ervidor n esta subsección se presentan las venta'as y desventa'as de la arquitectura cliente/servidor frente al modelo centrali3ado donde existe un %nico nodo físico. Benta'as ; -osibilidad de reducir costos de desarrollo. ; 2e'ores !erramientas de desarrollo. ; 2odificabilidad es compatible con buen diseño. ; Alexibilidad en el cliente. ; -ermite un me'or control sobre permisos de acceso a información. ; scalabilidad. i la empresa cambia en lo que respecta al tamaño, alcance, requerimientos de información, la escala de la arquitectura cliente/servidor puede ser cambiada. ; (a tecnolo#ía disponible es tan variada que puede utili3arse la que me'or se adecue a la realidad de la empresa. ; l software puede ser desarrollado desde varios lu#ares, lo que reduce el costo de desarrollo. C oporta los conceptos de comercio electrónico. &esventa'as ; Aalta de profesionales calificados. ; 4ecesidad de reimplementación de software existente, ya que el software monolítico no suele ser compatible con la arquitectura cliente/servidor.
;
4ecesidad de entrenamiento de usuarios, debido al cambio de las aplicaciones existentes.
)rquitectura en = +apas Una arquitectura en = capas distribuye la aplicación en dos componentes ló#icos. (as responsabilidades de cada componente !acen a las variantes de esta arquitectura. ur#e la arquitectura en = capas como consecuencia de la arquitectura cliente/servidor. sta topolo#ía permite distribuir la car#a de la aplicación a dos computadores diferentes, lo que llevó naturalmente a distribuir las responsabilidades de la misma a dos unidades ló#icas. )rquitectura -D(/& Una primera variante es retirar el mane'o de datos de la aplicación. sto permite a varios clientes utili3ar el mismo 'ue#o de datos. -D( es una unidad ló#ica por sí, donde el mane'o de interfa3 de usuario y el mane'o de la ló#ica no se los distin#ue como módulos independientes. 1ípicamente -D( se encuentra en el cliente, mientras que & se encuentra en el servidor. Un e'emplo de aplicaciones con esta arquitectura es una aplicación que dele#a la persistencia a un mane'ador de base de datos. )rquitectura -/(D& l !ec!o de tener la misma ló#ica en cada cliente permitió factori3arla, llevando la misma al servidor. )quí la ló#ica de la aplicación se encuentra embebida al mane'o de la persistencia de datos. n este tipo de aplicaciones la ló#ica resuelve los problemas de persistencia encar#ándose ella misma de dic!a tarea, no necesariamente utili3ando un mane'ador de base de datos, o embebiendo toda la ló#ica de ne#ocios en el mismo. )rquitectura -D(/(D& Una tercera variante es repartir la tarea de la ló#ica, una parte 'unto a la interfa3 de usuario, y otro 'unto al mane'o de persistencia de datos. Un e'emplo de aplicaciones con esta arquitectura son aplicaciones similares a las que tienen arquitectura -D(/&, que tienen implementada parte de la ló#ica en procedimientos almacenados en el mane'ador de la base de datos. &esventa'as de la )rquitectura en = capas ; (a ló#ica de la aplicación no puede ser reusada ya que está li#ada o a la interfa3 de usuario o al mane'o de persistencia de datos.
;
;
; ; ;
(as estaciones de traba'o pueden tener serias restricciones de recursos. (os desarrolladores deben estar entrenados para optimi3ar la aplicación de forma que pueda ser utili3ada en dic!os entornos. $ncremento de la car#a de la red: dado que el procesamiento de los datos se reali3a en el cliente, #ran cantidad de información debe ser transmitida desde el servidor. l -+ procesa y presenta la información. (leva a aplicaciones monolíticas, caras y difíciles de mantener. 6Efat client97. (a Eló#ica de ne#ocios9 está implementada en el -+. 4otar que la ló#ica de ne#ocios nunca usa el sistema de ventanas. $mplica un procedimiento de distribución complicado, ya que en caso de un cambio todos los -+s deben ser actuali3ados. s difícil #aranti3ar que un cliente está corriendo una versión anterior
)rquitectura en > +apas (a arquitectura en = capas, con su variante -/(D&, dio lu#ar a la arquitectura en > capas. l !ec!o de que la ló#ica de ne#ocios y el mane'o de persistencia sean una unidad presentaba desventa'as importantes: el mane'ador de base de datos resultaba pequeño y quería mi#rarse a otro, debía actuali3arse la versión, o se deseaba incorporar datos de nuevas fuentes. n esta arquitectura la ló#ica de la aplicación ocupa una capa intermediaF está separada tanto de los datos como de la interfa3 de usuario 6-/(/&7. (os procesos pueden ser administrados y desple#ados en forma autónoma, sin relación con la interfa3 de usuario y el mane'ador de base de datos. n teoría, los sistemas en > capas son de más fácil ampliación y más robustos y flexibles. )demás, pueden inte#rar datos de m%ltiples fuentes. s importante notar que los límites entre las capas son ló#icos, por lo que es posible e'ecutar las tres capas en la misma máquina. (o importante es que el sistema está claramente estructurado y que !ay una buena planificación de los límites entre las diferentes capas. Benta'as de la arquitectura en > capas ; eparación clara de la interfa3 de usuario de la ló#ica de la aplicación. sta separación permite tener diferentes presentaciones accediendo a la misma ló#ica. ; (a redefinición del almacenamiento de información no tiene influencia sobre la presentación.
;
n contraste con una arquitectura en = capas, donde solamente datos están accesibles al p%blico, los ob'etos de ne#ocios pueden brindar servicios 6ló#ica de la aplicación7 por la red
Conclusiones &ebido a que la arquitectura condiciona la aplicabilidad de ciertas tecnolo#ías se considera necesario dedicar atención a este tema. )rquitectura cliente/servidor y en capas son t"rminos no estandari3ados y al#o confusos, la biblio#rafía no es uniforme respecto a ellos e inclusive en ocasiones confunde ambos t"rminos. )quí se los define por separado y se determina una relación entre ambos conceptos que representa nuestra visión sobre el tema ya que no se encontró una referencia adecuada. l tratamiento de estos temas sirve además para uniformi3ar la terminolo#ía a lo lar#o del traba'o y permite abstraer las características comunes que puedan tener un #rupo de tecnolo#ías. Una ve3 comprendidas estas características, resulta más sencillo comprender los detalles.
Bibliografía !ttp://safari.awprofessional.com/G=G?H?IJJG !ttp://c=.com/c#i/wiKiL0exa#onal)rc!itecture !ttp://serverwatc!.internet.com/articles/servlets/overviewMd.!tml !ttp://www.servlets.com/soapbox/problems;'sp.!tml !ttp://www.servlets.com/soapbox/problems;'sp;reaction.!tml
