1.2 ARQUITECTURA

1.2 ARQUITECTURA

ANTES DE EMPEZAR A TRABAJAR EN EL ASPECTO PURAMENTE ESTÉTICO DE LAS PÁGINAS WEB, HAY QUE SABER QUE ESTRUCTURA DARLE A NUESTRA PAGINA Y SOBRE TODO DE QUE TRATARA RESPECTO EN EL DISEÑO EL COLOR SI TENDRA IMAGENES ETC.
HAY QUE DEFINIR ALGUNAS COSAS COMO:

DEFINIR LAS SECCIONES Y PÁGINAS WEB QUE DEBE TENER EL SITIO.ESCOGER LAS SECCIONES O PÁGINAS A LAS QUE PODREMOS ACCEDER DESDE LA PÁGINA PRINCIPAL (O DE INICIO)EL MOTIVO EL CUAL HAREMOS LA PAGINA

PROTOCOLO :

EL PROTOCOLO HTTP FORMA PARTE DE LA FAMILIA DE PROTOCOLOS DE COMUNICACIONES TCP/IP QUE SON LOS EMPLEADOS EN INTERNET ESTOS PERMITEN LA CONEXION DE SISTEMAS HETEROGENEOS LO QUE FACILITA LA INTERCAMBIO DE INFORMACION ENTES DISTINTOS ORDENADORES.


LA FORMA DE DESARROLLAR APLICACIONES HASTA EL MOMENTO ESTABA PENSADO SOBRE UNA ARQUITECTURA SIMPLE: LA APLICACIÓN CORRÍA EN FORMA LOCAL EN NUESTRA PC. LA VENTAJA ERA QUE LA VM SERVÍA COMO AMBIENTE DONDE CADA UNO DE LOS OBJETOS CUMPLÍA SU FUNCIÓN: UI, MODELO DE VISTA (FUERA APPLICATION MODEL O NEGOCIO), HOME, ETC.PARA COMENZAR A ENTENDER LA FILOSOFÍA WEB, TENEMOS QUE EXPLICAR PRIMERO CÓMO FUNCIONA SU ARQUITECTURA PORQUE DE MOVIDA HAY COSAS QUE NO SON TRADUCIBLES A LO QUE CONOCEMOS:

EL CLIENTE TIENE UN PROGRAMA EJECUTABLE (APPLICATION CLIENT, EL WEB BROWSER ES EL MÁS COMÚN)
Y EL SERVIDOR TIENE UN PROGRAMA EJECUTABLE: EN LA MATERIA SERÁ NUESTRO APPLICATION SERVER EL QUE TENDRÁ UNA VM DONDE VIVAN LOS OBJETOS DE NEGOCIO.
EL CLIENTE HACE PEDIDOS A TRAVÉS DE UN PUERTO CONTRA EL SERVIDOR, EL SERVIDOR RESPONDE.EL FLUJO DE MENSAJES SIEMPRE COMIENZA EN EL CLIENTE:
CLIENTE PIDE SERVICIO (REQUEST)SERVIDOR RESPONDE (RESPONSE)

EL BROWSER SÓLO ENTIENDE HTML (HYPER TEXT MARKUP LANGUAGE), ES DECIR: EL SERVIDOR CONTESTA CON UN STRING QUE TIENE TAGS (ETIQUETAS) HTML QUE EL BROWSER PUEDE PARSEAR.
ALGUNAS CONSECUENCIAS:NUESTRA APLICACIÓN PASA A SER UNA APLICACIÓN DISTRIBUIDA: VA A TENER UNA PARTE CORRIENDO EN EL SERVIDOR Y OTRA PARTE CORRIENDO EN EL CLIENTE. POR AHORA PUSIMOS TODA LA LÓGICA EN EL SERVIDOR Y LO QUE LE LLEGA AL CLIENTE ES SÓLO UN DOCUMENTO HTML PERO MÁS ADELANTE VAMOS A REPARTIRLO DE DIFERENTES MANERAS.EL CLIENTE ES LIVIANO (THIN) O ZAC (ZERO ADMINISTRATION CLIENT), ENTONCES ES FÁCIL MANTENER LA APLICACIÓN CUANDO TENGO MUCHOS CLIENTES UBICADOS GEOGRÁFICAMENTE EN LUGARES DISPERSOS, SÓLO TENGO QUE ACTUALIZAR EL SERVIDORPOR MÁS LIVIANO QUE SEA EL CLIENTE, LOS BROWSERS NO SON UNIFORMES, ENTONCES SI QUEREMOS QUE UNA APLICACIÓN ANDE EN TODOS ELLOS MUCHAS VECES VAMOS A TENER QUE MANEJAR CÓDIGO ESPECÍFICO PARA CADA PLATAFORMA (BROWSER, VERSIÓN, SISTEMA OPERATIVO Y A VECES HASTA EL HARDWARE).COMO EL CLIENTE ES EL QUE DISPARA LOS PEDIDOS, TODAS LAS INTERACCIONES ENTRE EL USUARIO Y LA APLICACIÓN DEBEN SER INICIADAS POR EL USUARIO, LA APLICACIÓN NO PUEDE TOMAR LA INICIATIVA (EJ: SI TENGO UNA LISTA DE TAREAS PENDIENTES, PARA QUE APAREZCA UNA NUEVA TAREA HAY QUE OBLIGAR AL CLIENTE A QUE DISPARE EL REFRESHUNA APLICACIÓN WEB ES PROPORCIONADA POR UN SERVIDOR WEB Y UTILIZADA POR USUARIOS QUE SE CONECTAN DESDE CUALQUIER PUNTO VÍA CLIENTES WEB (BROWSERS O NAVEGADORES). LA ARQUITECTURA DE UN SITIO WEB TIENE TRES COMPONENTES PRINCIPALES: UN SERVIDOR WEB UNA CONEXIÓN DE RED UNO O MÁS CLIENTESEL SERVIDOR WEB DISTRIBUYE PÁGINAS DE INFORMACIÓN FORMATEADA A LOS CLIENTES QUE LAS SOLICITAN. LOS REQUERIMIENTOS SON HECHOS A TRAVÉS DE UNA CONEXIÓN DE RED, Y PARA ELLO SE USA EL PROTOCOLO HTTP. UNA VEZ QUE SE SOLICITA ESTA PETICIÓN MEDIANTE EL PROTOCOLO HTTP Y LA RECIBE EL SERVIDOR WEB, ÉSTE LOCALIZA LA PÁGINA WEB EN SU SISTEMA DE ARCHIVOS Y LA ENVÍA DE VUELTA AL NAVEGADOR QUE LA SOLICITÓ.

SÍ, EN DEFINITIVA ES LA REPRESENTACIÓN DE LO QUE ES UN MENSAJE.LO QUE PASA ES QUE EN UN SISTEMA CON OBJETOS NO PONGO RESTRICCIONES: CUALQUIERA PUEDE SER EMISOR Y CUALQUIERA RECEPTOR. EN CAMBIO ACÁ NO HAY UNA CONEXIÓN DE IDA Y VUELTA ENTRE CLIENTE Y SERVIDOR: EL SENTIDO ES ÚNICO.ENTONCES, ¿CÓMO SE IMPLEMENTA?A. EL CLIENTE ABRE EL BROWSER QUE PERMITE DISPARAR EL PEDIDO: "NECESITO X", ENTONCES ESCRIBE EN EL BROWSER LA DIRECCIÓN DE UNA PÁGINA EN PARTICULAR, ESA DIRECCIÓN RECIBE EL NOMBRE DE URL (UNIFORME RESOURCE LOCATOR, O FORMA DE ENCONTRAR UN RECURSO EN EL SERVIDOR):
HTTP://LOCALHOST:8080/HTML-CSS/INDEX.HTML DONDEDEBEMOS DEFINIR EL PROTOCOLO QUE EL BROWSER VA A UTILIZARHTTP SIGNIFICA HYPERTEXT TRANSFER PROTOCOLHTTPS ES EL PROTOCOLO QUE IMPLEMENTA SECURE HTTP, DONDE LOS DATOS VIAJAN ENCRIPTADOSOTROS PROTOCOLOS SON FTP, GOPHER (DEPRECADO), ETC.LUEGO EL SERVIDOR WEB HACIA EL QUE VAMOS A CONECTARNOSEL SERVIDOR WEB PUEDE SER UNA DIRECCIÓN IP O UN NOMBRE QUE LUEGO ES CONVERTIDO A UNA DIRECCIÓN IP A TRAVÉS DE UN DNS (DOMAIN NAME SERVER)LOCALHOST ES EL WEB SERVER QUE ESTÁ EN LA PC LOCAL, QUE EQUIVALE A LA DIRECCIÓN IP 127.0.0.1LUEGO EL PUERTO DONDE EL SERVIDOR ESTÁ "ESCUCHANDO" PEDIDOSEL PORT DEFAULT ES 8080Y FINALMENTE LA PÁGINA QUE QUEREMOS CARGAR, QUE RECIBE EL NOMBRE DE RECURSOEN EL CASO DE JAVA ES PROYECTO + NOMBRE DEL "RECURSO"/PÁGINA: HTML-CSS/INDEX.HTMLLOS PEDIDOS PUEDEN RESOLVERSE MEDIANTE PÁGINAS HTML ESTÁTICAS O DINÁMICASQUÉ OCURRE CUANDO HAY UN PEDIDO HTTPA PARTIR DE AQUÍ SE DEFINEN 4 ETAPAS:EL BROWSER SE CONECTA CON EL SERVIDOR A PARTIR DEL DOMINIO O IP (LOCALHOST = 127.0.0.1) Y PUERTOSE ENVÍA LA PETICIÓN AL SERVIDOR CON PARÁMETROS, PROTOCOLO, ETC.EL SERVIDOR RESPONDE ESE PEDIDO: ESA RESPUESTA ES UNA NUEVA PÁGINA CON UN CÓDIGO DE ESTADO HTTP:200 OK403 FORBIDDEN404 NOT FOUND500 INTERNAL SERVER ERROR, ETC.EL BROWSER SE DESCONECTA DEL SERVIDOR UNA VEZ PROCESADA LA RESPUESTALA PÁGINA ES LA MÍNIMA UNIDAD DE INFORMACIÓN ENTRE CLIENTE Y SERVIDOR, LO QUE IMPLICA:PROBLEMAS EN LA PERFORMANCE: NO SIEMPRE DEBERÍA REFRESCAR TODA LA PÁGINA SI SÓLO NECESITO ACTUALIZAR PARCIALMENTE LA INFORMACIÓN DE DICHA PÁGINAPROBLEMAS EN EL DISEÑO: TENGO DIFICULTADES PARA PODER PARTICIONAR UNA PANTALLA EN COMPONENTES VISUALESPROBLEMAS DE USABILIDAD: EJEMPLOSATRAPAR EVENTOS DE USUARIO REQUIERE TRABAJO DE PROGRAMACIÓNLA SENSACIÓN DE PARPADEO CADA VEZ QUE EL CLIENTE DISPARA UNA ACCIÓN QUE DEBE IMPACTAR EN EL SERVIDORLAS APLICACIONES WEB ESTÁN BASADAS EN EL MODELO CLIENTE/SERVIDOR QUE GESTIONAN SERVIDORES WEB, Y QUE UTILIZAN COMO INTERFAZ PÁGINAS WEB.LAS PÁGINAS WEB SON EL COMPONENTE PRINCIPAL DE UNA APLICACIÓN O SITIO WEB. LOS BROWSERS PIDEN PÁGINAS (ALMACENADAS O CREADAS DINÁMICAMENTE) CON INFORMACIÓN A LOS SERVIDORES WEB. EN ALGUNOS AMBIENTES DE DESARROLLO DE APLICACIONES WEB, LAS PÁGINAS CONTIENEN CÓDIGO HTML Y SCRIPTS DINÁMICOS, QUE SON EJECUTADOS POR EL SERVIDOR ANTES DE ENTREGAR LA PÁGINA.UNA VEZ QUE SE ENTREGA UNA PÁGINA, LA CONEXIÓN ENTRE EL BROWSER Y EL SERVIDOR WEB SE ROMPE, ES DECIR QUE LA LÓGICA DEL NEGOCIO EN EL SERVIDOR SOLAMENTE SE ACTIVA POR LA EJECUCIÓN DE LOS SCRIPTS DE LAS PÁGINAS SOLICITADAS POR EL BROWSER (EN EL SERVIDOR, NO EN EL CLIENTE). CUANDO EL BROWSER EJECUTA UN SCRIPT EN EL CLIENTE, ÉSTE NO TIENE ACCESO DIRECTO A LOS RECURSOS DEL SERVIDOR. HAY OTROS COMPONENTES QUE NO SON SCRIPTS, COMO LOS APPLETS (UNA APLICACIÓN ESPECIAL QUE SE EJECUTA DENTRO DE UN NAVEGADOR) O LOS COMPONENTES ACTIVEX. LOS SCRIPTS DEL CLIENTE SON POR LO GENERAL CÓDIGO JAVASCRIPT O VBSSCRIPT, MEZCLADOS CON CÓDIGO HTML.LA COLECCIÓN DE PÁGINAS SON EN UNA BUENA PARTE DINÁMICAS (ASP, PHP, ETC.), Y ESTÁN AGRUPADAS LÓGICAMENTE PARA DAR UN SERVICIO AL USUARIO. EL ACCESO A LAS PÁGINAS ESTÁ AGRUPADO TAMBIÉN EN EL TIEMPO (SESIÓN). LOS COMPONENTES DE UNA APLICACIÓN WEB SON:1. LÓGICA DE NEGOCIO. PARTE MÁS IMPORTANTE DE LA APLICACIÓN. DEFINE LOS PROCESOS QUE INVOLUCRAN A LA APLICACIÓN. CONJUNTO DE OPERACIONES REQUERIDAS PARA PROVEER EL SERVICIO.2. ADMINISTRACIÓN DE LOS DATOS. MANIPULACIÓN DE BD Y ARCHIVOS.3. INTERFAZ LOS USUARIOS ACCEDEN A TRAVÉS DE NAVEGADORES, MÓVILES, PDAS, ETC.FUNCIONALIDAD ACCESIBLE A TRAVÉS DEL NAVEGADOR. LIMITADA Y DIRIGIDA POR LA APLICACIÓN.

CON LA INTRODUCCIÓN DE INTERNET Y DEL WEB EN CONCRETO, SE HAN ABIERTO INFINIDAD DE POSIBILIDADES EN CUANTO AL ACCESO A LA INFORMACIÓN DESDE CASI CUALQUIER SITIO. ESTO REPRESENTA UN DESAFÍO A LOS DESARROLLADORES DE APLICACIONES, YA QUE LOS AVANCES EN TECNOLOGÍA DEMANDAN CADA VEZ APLICACIONES MÁS RÁPIDAS, LIGERAS Y ROBUSTAS QUE PERMITAN UTILIZAR EL WEB.AFORTUNADAMENTE, TENEMOS HERRAMIENTAS POTENTES PARA REALIZAR ESTO, YA QUE HAN SURGIDO NUEVAS TECNOLOGÍAS QUE PERMITEN QUE EL ACCESO A UNA BASE DE DATOS DESDE EL WEB, POR EJEMPLO, SEA UN MERO TRÁMITE. EL ÚNICO PROBLEMA ES DECIDIR ENTRE EL CONJUNTO DE POSIBILIDADES LA CORRECTA PARA CADA SITUACIÓN.




LAS APLICACIONES WEB SE BASAN EN UNA ARQUITECTURA CLIENTE/SERVIDOR: POR UN LADO ESTÁ EL CLIENTE (EL NAVEGADOR, EXPLORADOR O VISUALIZADOR) Y POR OTRO LADO EL SERVIDOR (EL SERVIDOR WEB). EXISTEN DIVERSAS VARIANTES DE LA ARQUITECTURA BÁSICA SEGÚN CÓMO SE IMPLEMENTEN LAS DIFERENTES FUNCIONALIDADES DE LA PARTE SERVIDOR.EL LENGUAJE PHP ES HOY EN DÍA UNO DE LOS MÁS POPULARES EN EL DESARROLLO DE APLICACIONES WEB. EXISTEN OTRAS TECNOLOGÍAS SIMILARES, COMO JAVA O .NET, PERO PHP ES QUIZÁS LA MEJOR OPCIÓN PARA APRENDER A DESARROLLAR APLICACIONES WEB.

EL VIEJO CGI HA CUMPLIDO CON EL PROPÓSITO DE AÑADIR INTERACTIVIDAD A LAS PÁGINAS WEB PERO SUS DEFICIENCIAS EN EL DESARROLLO DE APLICACIONES Y EN LA ESCALABILIDAD DE LAS MISMAS HA CONDUCIDO AL DESARROLLO DE APIS ESPECÍFICOS DE SERVIDOR COMO ACTIVE SERVER PAGES, ASP, Y PHP, QUE SON MÁS EFICIENTES QUE SU PREDECESOR CGI.PARA APROVECHAR EL POTENCIAL DE ESTAS TECNOLOGÍAS Y OFERTAR UNA SOLUCIÓN DE SERVIDOR MÁS EXTENSIBLE Y PORTABLE, SUN HA DESARROLLADO LA TECNOLOGÍA LLAMADA SERVLET. LOS SERVLETS JAVA SON MUY EFICIENTES, DEBIDO AL ESQUEMA DE THREADS EN EL QUE SE BASAN Y AL USO DE UNA ARQUITECTURA ESTÁNDAR COMO LA JVM, JAVA VIRTUAL MACHINE.OTRA NUEVA TECNOLOGÍA VIENE A SUMARSE A LAS QUE EXTIENDEN LA FUNCIONALIDAD DE LOS SERVIDORES WEB, LLAMADA JAVA SERVER PAGES, JSP. LOS JSP PERMITEN JUNTAR HTML, APLICACIONES JAVA, Y COMPONENTES COMO LAS JAVA BEANS CREANDO UNA PÁGINA WEB ESPECIAL QUE EL SERVIDOR WEB COMPILA DINÁMICAMENTE EN UN SERVLET LA PRIMERA VEZ QUE ES LLAMADA.

MODELO DE TRES CAPAS.

ESTA DISEÑADA PARA SUPERAR LAS LIMITACIONES DE LAS ARQUITECTURAS AJUSTADAS AL MODELO DE DOS CAPAS, INTRODUCE UNA CAPA INTERMEDIA (LA CAPA DE PROCESO) ENTRE PRESENTACIÓN Y LOS DATOS, LOS PROCESOS PUEDEN SER MANEJADOS DE FORMA SEPARADA A LA INTERFAZ DE USUARI O Y A LOS DATOS, ESTA CAPA INTERMEDIA CENTRALIZA LA LÓGICA DE NEGOCIO, HACIENDO LA ADMINISTRACIÓN MÁS SENCIL A, LOS DATOS SE PUEDEN INTEGRAR DE MÚLTIPLES FUENTES, LAS APLICACIONES WEB ACTUALES SE AJUSTAN A ESTE MODELO.
LAS CAPAS DE ESTE MODELO SON:
1. CAPA DE PRESENTACIÓN (PARTE EN EL CLIENTE Y PARTE EN EL SERVIDOR
RECOGE LA INFORMACIÓN DEL USUARIO Y LA ENVÍA AL SERVIDOR (CLIENTE)MANDA INFORMACIÓN A LA CAPA DE PROCESO PARA SU PROCESADORECIBE LOS RESULTADOS DE LA CAPA DE PROCESOGENERAN LA PRESENTACIÓNVISUALIZAN LA PRESENTACIÓN AL USUARIO (CLIENTE)
2. CAPA DE PROCESO (SERVIDOR WEB)
RECIBE LA ENTRADA DE DATOS DE LA CAPA DE PRESENTACIÓNINTERACTÚA CON LA CAPA DE DATOS PARA REALIZAR OPERACIONESMANDA LOS RESULTADOS PROCESADOS A LA CAPA DE PRESENTACIÓN
3. CAPA DE DATOS (SERVIDOR DE DATOS)
ALMACENA LOS DATOSRECUPERA DATOSMANTIENE LOS DATOSSEGURA LA INTEGRIDAD DE LOS DATOS

MODELO DE DOS CAPAS.

GRAN PARTE DE LA APLICACIÓN CORRE EN EL LADO DEL CLIENTE (FAT CLIENT).

LAS CAPAS SON:

CLIENTE (FAT CLIENT): LA LÓGICA DE NEGOCIO ESTÁ INMERSA DENTRO DE LA APLICACIÓN QUE REALIZA EL INTERFAZ DE USUARIO, EN EL LADO DEL CLIENTE.
SERVIDOR: ADMINISTRA LOS DATOS.

LAS LIMITACIONES DE ESTE MODELO SON.
ES DIFÍCILMENTE ESCALABLE
NÚMERO DE CONEXIONES REDUCIDA
ALTA CARGA DE LA RED.
LA FLEXIBILIDAD ES RESTRINGIDA
LA FUNCIONALIDAD ES LIMITADA. 
PAGINAS:

HTTPS://BOOKS.GOOGLE.COM.MX/BOOKS?ID=R9CQDYH2-LOC&PG=PR16&LPG=PR16&DQ=ARQUITECTURA+DE+LAS+APLICACIONES+WEB&SOURCE=BL&OTS=MIZPSN8QH0&SIG=H9N1AW9DIIGEENALE7I9C-SA1G4&HL=ES&SA=X&EI=WERRVZGMD8U1YASMHYGQCA&VED=0CECQ6AEWBZGK#V=ONEPAGE&Q=ARQUITECTURA%20DE%20LAS%20APLICACIONES%20WEB&F=FALSE