Aplicaciones y arquitecturas web - teoria - p1-16
Aplicaciones y arquitecturas web - teoria - p1-16
Aplicaciones y arquitecturas web - teoria - p1-16
servidores web.
1.- Aplicaciones web.
La web es la parte más visible de Internet, pero no la única. Existen otros servicios, como el correo electrónico, grupos
de noticias, transferencia de archivos, terminal remoto.
En los orígenes del mundo web nos situábamos ante un entorno estático, con páginas en formato HTML que raramente
sufrían modificaciones o actualizaciones y en las que apenas había interacción con el usuario: páginas estáticas .
La Web 2.0 es la transición que se ha dado, a partir de finales de los 90 ( con Yahoo!, Amazon y e-bay como pioneros)
desde las aplicaciones tradicionales hacia aplicaciones que funcionan a través de la web y que abren nuevas
posibilidades Aplicaciones colaborativas, Redes sociales:publicación en comunidad de contenidos, comentarios, ….,
Compra electrónica, etc.
Está basada en páginas dinámicas: varían su contenido según las necesidades y aportaciones del usuario y según los
datos existentes en el servidor: la página que recibe el usuario se “crea” a propósito para él, no existía previamente
Involucra el uso de Bases de datos, perfiles de usuarios, etc
Hoy día a la web 2.0 también se la suele denominar web social. Dado que en ella los usuarios han dejado de ser usuarios
pasivos, meros receptores de contenidos, y han pasado a formar parte activa de la web, creando contenido y conocimiento
(blogs, wikis, redes sociales y otros servicios en la nube, como almacenamiento web o servicios de streaming). La web social
también se caracteriza por fomentar las relaciones sociales.
◦ Aplicación distribuida proporcionada por un servidor web y utilizada por usuarios que se conectan
remotamente a través de un navegador web.
El usuario interactúa con un navegador (el cual proporciona la interfaz de usuario de la aplicación) que accede a
los servicios y recursos que ofrece un servidor web. Esos servicios y recursos son generados previamente por
un programa o aplicación que responde a las acciones del usuario y que realiza la mayor parte del
procesamiento, si no todo.
La aplicación web se sustenta en la consulta a una base de datos donde se almacena la información.
Más ejemplos: gestores de contenido (Joomla, wordpress), buscadores, una tienda electrónica, redes sociales,
comercio electrónico, servicios de correo web,....
Algunas aplicaciones web emulan las funcionalidad de aplicaciones de escritorio. Otras, por
su naturaleza, deben ser remotas y “centralizadas”: redes sociales, plataformas educativas
Establecer una clasificación de los tipos de aplicaciones web es una tarea compleja debido a la
dificultad existente para poder establecer algún parámetro en función del cual establecer dicha
clasificación, junto con la innumerable cantidad de aplicaciones existentes en el actual entorno web
2.0.
Algunos ejemplos genéricos:
• Página web Dinámica. Existen muchos lenguajes de programación que son la base para la mayoría de páginas web
dinámicas. Los que destacamos aquí son los lenguajes PHP y ASP. Estos lenguajes permiten una perfecta
estructuración del contenido. Por una parte crearíamos la estructura de las páginas web y por otra, almacenaríamos el
contenido en determinados archivos. A partir de ahí, crearíamos el código de llamada, que insertaría el contenido en la
propia página web estructurada. Este es el principio básico que siguen los lenguajes de programación. A partir de aquí
se desarrollan aplicaciones para poder gestionar el contenido a través de un panel de control.
• Portal (término obsoleto). Es un sitio web que en su página principal permite el acceso a múltiples secciones que, por
lo general, son foros, chats, cuentas de correo, buscador, acceso registrado para obtener ciertas ventajas, las últimas
noticias de actualidad, ¿Podría servir la “página web” del centro como ejemplo?
• Tienda virtual o comercio electrónico. Sitio web que publica los productos de una tienda en Internet. Permite la
compra on-line a través de tarjeta de crédito, domiciliación bancaria o transferencia bancaria en general. Ofrece al
administrador un panel de gestión para poder subir los productos, actualizarlos, eliminarlos,
• Página web con "Gestor de Contenidos". Se trata de un sitio web cuyo contenido se actualiza a través de un panel de
gestión por parte del administrador del sitio. Este panel de gestión suele ser muy intuitivo y fácil de usar. En aquellas
páginas web que requieran una actualización constante, se suele incorporar este panel de gestión para que la web pueda
controlarse día a día por parte del cliente. Ejemplos: Moodle, WordPress, Joomla, Drupal. Los tres últimos son
altamente configurables y permiten crear múltiples sitios web con distintos objetivos (Buscar temas y plugins de
Joomla)
Reflexiona
Cuando adquirimos un equipo informático nuevo, existen una serie de aplicaciones imprescindibles que es necesario instalar
junto con los drivers de nuestro equipo para poder empezar a utilizarlo. Entre estas aplicaciones encontramos aplicaciones
ofimáticas, antivirus, aplicaciones de mensajería, compresores, visualizadores, reproductores multimedia, conversores….
Ejemplos concretos? Alguna que conozcas que no encuadre en estas categorías?
Examinar sitio de “desarrolloweb”, un programador que desarrolla aplicaciones pequeñas y medianas en php, algunas de ellas
gratuitas
¿En algún momento te has parado a pensar qué cantidad de aplicaciones web hay disponibles en Internet para sustituir a las que
tienes pensado instalar en el equipo?
Esto nos lleva a pensar en las ventajas e inconvenientes; indica razonadamente, 3 ventajas y 3? inconvenientes de las
aplicaciones Web
Siguen operando en la actualidad páginas y sitios web puramente estáticos? Busca algunos ejemplos
Ejemplos de servicios de despliegue de páginas estáticas:
• Netlify
• Surge
• GitHub Pages
• GitLab Pages
• Firebase
• Vercel
• Neocities
Los estándares WWW (W3C) especifican muchos de los mecanismos necesarios para construir un ambiente de aplicación de
propósito general, por ejemplo:
• Modelo estándar de nombres: todos los servidores, así como el contenido de la WWW se denominan según un
Localizador Uniforme de Recursos (Uniform Resource Locator: URL).
• Lenguajes y tecnologías estándar: todos los navegadores soportan un conjunto de formatos y tecnologías estándar,
por ejemplo HTML (Lenguaje de marcas de hipertexto), ECMAScript (JavaScript), CSS, .
• Protocolos estándar, HTTP: éstos permiten que cualquier navegador pueda comunicarse con cualquier servidor web.
El más comúnmente usado en WWW es HTTP (Protocolo de Transferencia de HiperTexto), que opera sobre el
conjunto de protocolos TCP/IP (Protocolo de Control de Transmisión / Protocolo de Internet).
• Contenido: a todos los contenidos en la WWW se les especifica un
determinado tipo, permitiendo de esta forma que los browsers
(navegadores) los interpreten correctamente. MIME (Multipurpose
Internet Mail Extensions )
Esta infraestructura permite a los usuarios acceder a una gran cantidad de aplicaciones y servicios de terceros. También permite
a los desarrolladores crear aplicaciones y servicios para una gran comunidad de clientes.
El esquema de funcionamiento de los servicios web requiere de tres elementos fundamentales:
1. Proveedor del servicio web, que es quien lo diseña, desarrolla e implementa y lo pone disponible para su uso, ya sea
dentro de la misma organización o en público.
2. Consumidor del servicio, que es quien accede al componente para utilizar los servicios que éste presta.
3. Agente del servicio, que sirve como enlace entre proveedor y consumidor para efectos de publicación, búsqueda y
localización del servicio.
HTTP es el protocolo que permite al navegador realizar una petición y al servidor generar una respuesta, y es importante
entenderlo antes de configurar un servidor web, pero si ha triunfado la web y ha llegado hasta donde está hoy día, es también
gracias a otros mecanismos:
• El sistema DNS, que permite traducir un nombre de máquina en una dirección IP. El sistema DNS es una base de datos
distribuida que nos permite acceder a una máquina remota a través de un nombre (como www.gnu.org o
www.debian.org).
• El uso de URLs (Uniform Resource Locator). Una URL es una nomenclatura pensada para poder nombrar recursos en
la red de forma sencilla, por ejemplo: http://www.gnu.org).
• Por el ingenio de muchos desarrolladores y desarrolladoras web que con HTML, CSS y JavaScript, y tecnologías del
lado del servidor, consiguen hacer páginas webs increíbles.
URL: De todos estos conceptos, el que vamos a revisar ahora es el de URL. Para entender una URL lo mejor es analizar un
ejemplo de URL y desglosarla en partes:
http://es.wikipedia.org/wiki/Localizador_de_recursos_uniforme
En la URL anterior aparecen las siguientes partes:
• Esquema. El esquema es donde pone http: y representa el protocolo usado para acceder al recurso. Los esquemas más
usados son http:, https: (protocolo HTTPS) y ftp: (protocolo FTP), aunque hay otros esquemas como tel: (para hacer
referencia a un número de teléfono), mailto: (para hacer referencia a un correo electrónico), y bastantes más.
• Nombre de máquina o FQDN. En este caso es es.wikipedia.org y hace referencia a la máquina a la que estamos
accediendo.
• Ruta hasta el recurso. En este caso sería /wiki/Localizador_de_recursos_uniforme, y hace referencia al camino a
seguir para llegar al recuso.
Si alguna URL necesita usuario y contraseña (por ejemplo, si usamos el esquema ftp), entonces podemos escribirlo de la
siguiente forma:
• ftp://[email protected]/mirror/Apache/: donde anonymous sería el nombre de usuario.
• ftp://anonymous:contraseñ[email protected]/mirror/Apache/: donde anonymous:contraseña son la combinación del
usuario y su contraseña separados por dos puntos.
Y por último, como se verá más adelante, si un protocolo se usa en un puerto diferente al puerto por defecto o estándar,
podemos usar el siguiente formato de URL:
• http://www.ejemplodedominio.com:8080/mirecurso; donde 8080 es el puerto que se usaría en este caso para acceder al
servicio remoto.
Veamos el funcionamiento de HTTP con mayor detalle: Cuando un cliente web (un navegador por ejemplo) accede a un
recurso, se sigue el siguiente procedimiento:
1. Un usuario accede a una URL, seleccionando un enlace de un documento HTML o introduciéndola directamente en el
campo correspondiente del cliente Web.
2. El cliente Web descodifica la URL, separando sus diferentes partes: el protocolo de acceso, la dirección DNS o IP del
servidor, el posible puerto opcional (el valor por defecto es 80) y el objeto requerido del servidor.
http://direccion[:puerto][path]
Ejemplo: http://www.miweb.com/documento.html
3. Se abre una conexión TCP/IP con el servidor, llamando al puerto TCP correspondiente. En ese momento, se realiza la
petición HTTP. Para ello, se envía el comando necesario (GET, POST, HEAD,...), la dirección del objeto requerido (el
contenido de la URL que sigue a la dirección del servidor), la versión del protocolo HTTP empleada y un conjunto
variable de información, que incluye datos sobre las capacidades del navegador (browser), datos opcionales para el
servidor, etc.
4. El servidor devuelve la respuesta al cliente. Consiste en un código de estado y el tipo de dato MIME de la información
de retorno, seguido de la propia información.
5. Se cierra la conexión TCP. Este proceso se repite en cada acceso al servidor HTTP. Por ejemplo, si se recoge un
documento HTML en cuyo interior están insertadas 2 imágenes y 1 vídeo, el proceso anterior se repite cuatro veces,
una para el documento HTML y tres más para los recursos (las dos imágenes y el vídeo).
Para entender mejor este proceso, veamos un ejemplo de comunicación entre un cliente web y navegador web. Supongamos
que en un navegador web ponemos la URL siguiente: http://www.rediris.es/rediris/. En este caso nuestro navegador se pondrá
en contacto con el sistema www.rediris.es y enviará una petición usando el método GET que tendrá el siguiente aspecto:
GET /rediris/ HTTP/1.1
Host: www.rediris.es
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://www.rediris.es/
Cookie: language=en
Connection: keep-alive
La petición anterior comienza indicando el método (GET), el recurso (/rediris/) y la versión del protocolo (). A continuación, el
navegador incluye varias cabeceras de petición (User-Agent, Accept, Cookie, .) que le permitirán al servidor web, y a una
potencial aplicación web que procese la petición , generar una respuesta más completa. El servidor responderá con una
respuesta que tendrá el siguiente aspecto:
HTTP/1.1 200 OK
Date: Thu, 11 May 2017 21:33:53 GMT
Server: Apache/2.2.3 (Red Hat)
Content-Location: index.html.en
Vary: negotiate,accept-language
TCN: choice
Last-Modified: Thu, 04 May 2017 10:03:20 GMT
Etag: "616903-22f3-54eafe1e9ea00"
Accept-Ranges: bytes
Content-Length: 8947
Set-Cookie: language=en; path=/; domain=rediris.es
Cache-Control: no-cache
Connection: close
Content-Type: text/html; charset=UTF-8
Content-Language: en
Lo anterior es solamente la cabecera de respuesta, que comienza por la versión del protocolo (), seguido de un código de
respuesta (200) y un texto que dependiendo del caso puede variar (en el caso del código 200 suele ser u OK o Document
follows). Después de esa primera parte, se incluyen varias cabeceras de respuesta (Date, Set-Cookie, Server, ...) con
información que el cliente web debe tener en cuenta. ¿Y dónde va la información? Justo después de terminar las cabeceras, el
servidor incluirá una línea vacía y, a continuación, el documento o recurso.
Cookies:
Una cookie es un pequeño texto introducido en el ordenador de un usuario por un cliente HTTP (navegador). Una
cookie contiene una o varias parejas nombre = valor, con información como las preferencias de un usuario,
contenidos de carros de la compra por Internet, identificadores de sesión, ... Las cookies se envían por medio de
una cabecera HTTP desde un servidor a un cliente y luego es devuelta por el cliente al servidor cuando éste se lo
solicita.
Algunos usos de las cookies son:
• Gestión de sesiones. Las cookies se usan para guardar datos relacionados con el usuario durante la
navegación, sobre todo cuando hay múltiples visitas. El servidor envía una cookie con un identificador de
sesión único. El cliente devolverá el identificador de sesión con cada petición posterior al servidor
(cesta de la compra).
• Las cookies también se emplean para indicar el permiso de los usuarios a conectarse a un sitio web. El
servidor envía primero una cookie con un identificador de sesión único. Los usuarios envían a continuación
sus credenciales y la aplicación web autentifica la sesión y permite el acceso de los usuarios a sus servicios.
• Personalización. Las cookies se utilizan para recordar la información sobre un usuario que ha visitado un
sitio web para poder mostrarle el contenido más relevante.
• Seguimiento. Las cookies pueden usarse para registrar los hábitos de navegación de los usuarios.
• Método GET: se usa para obtener un recurso, y en general, no admite que el cliente web envíe datos al servidor. Si
queremos usar este método para enviar datos al servidor los datos deben formar parte del recurso solicitado, usando por
ejemplo una cadena de consulta (query string). Por ejemplo:
• Si ponemos la url http://www.estoesunejemplo.com/mipagina.php, se generaría una petición HTTP del estilo a
GET /mipagina.php HTTP/1.1.
• Si ponemos la url http://www.estoesunejemplo.com/mipagina.php?dato1=a&dato2=2, se generaría una
petición HTTP del estilo a GET /mipagina.php?dato1=a&dato2=2 HTTP/1.1. La diferencia con el anterior es
que se ha añadido una cadena de consulta que se procesará internamente por la aplicación web (en este caso
escrita en php) para generar el contenido de forma dinámica.
• Método POST: se usa para enviar datos al servidor, los datos no irán en el recurso solicitado (como es el caso del
query string), sino que se enviarán después de las cabeceras de petición (cabeceras, línea en blanco y a continuación los
datos). De esta forma, los datos enviados al servidor no se ven en la URL y quedan ocultos a los ojos del usuario. La
respuesta del servidor será también contenido que se podrá visualizar en el navegador (generalmente una página web).
• Método HEAD: permite obtener datos de un recurso sin que el servidor llegue a enviarlo al cliente. Se obtendría por
ejemplo la fecha de la última modificación de una imagen y su tamaño, lo cual es útil para mantener una caché en el
navegador con los contenidos descargados más habitualmente o más recientemente.
• HTTP 1.1 incorpora algunos métodos más (OPTIONS, DELETE, PUT, etc) . Método PUT: puede verse como el
comando inverso a GET. Nos permite escribir datos en el servidor o, lo que es lo mismo, poner un recurso en la URL
que se especifique. Si el recurso no existe, lo crea; en caso contrario, lo reemplaza. La diferencia con POST puede ser
algo confusa; mientras que POST está orientado a la creación de nuevos contenidos, PUT está más orientado a la
actualización de los mismos (aunque también podría crearlos).
• HTTP 2 no incluye métodos nuevos
Después de realizar una petición como las anteriores, sea el método que sea, el servidor generará una respuesta HTTP que
contendrá un código de estado de respuesta. El código de estado 200 OK ya se vio en el apartado anterior, pero existen otros
códigos importantes que debes conocer:
• 1XX: los códigos de estado en el rango de 100 son respuestas informativas.
• 100 Continue: significa que todo va bien por ahora y que el cliente debería seguir con la petición.
• 2XX: los códigos de estado en el rango de 200 son respuestas de éxito en la transferencia, por ejemplo:
• 200 OK: significa que la respuesta ha tenido éxito y generalmente implica que los datos van en la respuesta
(depende del método de la petición).
• 3XX: los códigos de estado en el rango de 300 son respuestas de redirección, el recurso ha cambiado de ubicación.
• 301 Moved Permanently: significa que un recurso se ha movido a otro sitio de forma permanente. El servidor
web incluye una cabecera llamada Location: con la nueva ubicación. El navegador realizará una petición a la
nueva ubicación de forma transparente al usuario.
• 302 Found: significa que un recurso se ha movido a otro sitio de forma temporal. El funcionamiento es similar
al 301.
• Otras respuestas relacionadas con la redirección y el cambio de ubicaciones son la 303 See Other, 307
Temporary Redirect y 308 Permanent Redirect. Tienen connotaciones ligeramente diferentes a los códigos
de estado 301 y 302, pero la idea es similar.
• 4XX: los códigos de estado en el rango de 400 son respuestas en las que se indica que hay un error en la petición del
cliente o que algo ha ido mal al procesarla. Veamos algunos ejemplos:
• 400 Bad Request: el servidor no entiende la petición quizás porque está mal formada.
• 401 Unauthorized: es necesario que el usuario se autentique para acceder al recurso y dicha autenticación a
fallado.
• 403 Forbidden: el acceso al contenido solicitado no está permitido.
• 404 Not Found: posiblemente el código de estado más conocido. El servidor responde con este código cuando
el recurso solicitado no existe o no puede ser encontrado.
• 5XX: los códigos de estado que están en el rango de 500 simbolizan que se ha recibido una petición correcta pero que
el servidor no ha podido completar la respuesta. Veamos algunos ejemplos:
• 500 Internal Server Error: generalmente significa que hay un error en la configuración del servidor y que no
se puede completar la respuesta.
• 502 Bad Gateway: suele indicar que el servidor al que se ha solicitado la petición actúa como una pasarela a
otro servidor, y el segundo servidor no ha respondido adecuadamente.
• 503 Service Unavailable: el servidor no está disponible en este momento.
El protocolo HTTPS utiliza cifrado sobre SSL/TLS que proporcionan autenticación y privacidad. Entonces, si necesitas que la
información viaje cifrada debes emplear el protocolo HTTPS, en caso contrario el protocolo HTTP. Hay que dejar claro que la
utilización del protocolo HTTPS no excluye ni impide el protocolo HTTP, los dos pueden convivir en un mismo dominio.
Bien, pero, ¿cómo funcionan? Más o menos hemos visto ya el funcionamiento pero vamos a revisarlo para entender la
diferencia con HTTPS. Cuando escribes una dirección URL en el navegador, por ejemplo http://www.debian.org/index.es.html,
antes de ver la página en el navegador existe todo un juego de protocolos que entran en acción, sin profundizar en todos ellos,
vamos ver el proceso que ocurre:
• Se traduce el dominio DNS por una dirección IP (en este caso www.debian.org se traduce a una dirección IP).
• Una vez obtenida la dirección IP se accede al sistema remoto que tiene dicha IP, concretamente al puerto 80, que es el
puerto TCP asignado por defecto al protocolo HTTP.
• El cliente web entonces realiza la petición HTTP, solicitando un recurso (en este caso podría ser GET /index.es.html
HTTP/1.1, por ejemplo).
• Si el servidor web aloja la página, ésta será transferida a tu navegador en la respuesta HTTP.
Sin embargo cuando escribes en el navegador una dirección URL con llamada al protocolo HTTPS, el procedimiento es similar
al anterior pero un poco más complejo:
• Se traduce el dominio DNS por una IP.
• Una vez que se obtiene la IP, se busca en el servidor web que aloja la página solicitada el puerto 443, puerto TCP
asignado por defecto al protocolo HTTPS.
• Pero ahora, antes de transferir la página a tu navegador se inicia una negociación SSL, en la que entre otras cosas el
servidor envía su certificado de seguridad al navegador (el navegador, aunque es poco habitual, también puede enviar
el suyo), y si el certificado está firmado por un Entidad Certificadora de confianza, el cliente web aceptará el
certificado y se usará un canal seguro de comunicación, donde toda la información irá cifrada.
• Una vez verificado el certificado servidor, se realiza el proceso de petición HTTP y respuesta HTTP pero de forma
cifrada.
Puedes hacer que un servidor web para una determinada página acepte los protocolos HTTP y HTTPS en puertos TCP
distintos del 80 y 443 respectivamente. Eso sí, cuando visites la página web, en la dirección URL debes especificar el puerto
TCP. Por ejemplo, si nuestro servidor atiende peticiones HTTP en el puerto 8080 deberíamos poner
http://www.tupagina.local:8080, de esta forma el cliente web enviará la petición de la página www.tupagina.local al puerto
8080. Del mismo modo si nuestro servidor atiende peticiones HTTPS en el puerto 4333, deberíamos escribir la url en el
navegador de la siguiente forma: https://www.tupagina.local:4333. Como ves, puedes cambiar los puertos por defecto, pero
ten en cuenta que cualquiera que quisiera acceder a esas páginas debería saber el puerto TCP de la solicitud. Entonces,
¿quiere decir que aunque no escribas el puerto TCP en las direcciones URL estas se interpretan en el puerto 80 y 443 para el
protocolo HTTP y HTTPS respectivamente? Pues si, así es. Es lo mismo escribir http://www.tupagina.local:80 que
http://www.tupagina.local y es lo mismo escribir https://www.tupagina.local:443 que https://www.tupagina.local.
SSL/TLS; Secure Sockets Layer/Transport Layer Security. Protocolos criptográficos que proporcionan conexiones seguras por
una red, comúnmente Internet.
Dominio DNS: Nombre por el cual se reconoce a un grupo de dispositivos o equipos conectados a la red. Éstos pueden ser
nombres locales, no existentes en Internet, pero en general tienen por finalidad su uso en Internet. Por ejemplo, debian.org
Puerto: Número utilizado en las comunicaciones cliente/servidor en transmisiones TCP o UDP comprendido entre 1 y 65535
que indica por dónde tiene lugar la conexión con un servidor. Están estandarizados, esto es, un servidor suele estar activo
siempre por definición en un puerto determinado, pero éste puede variarse mediante configuración.
TCP: Es uno de los protocolos fundamentales en Internet. Garantiza que los datos serán entregados en su destino sin errores y
una vez recogidos, que se pondrán en el mismo orden en que se transmitieron.
Los modelos de arquitectura web implementan de diferentes formas, con unos u otros componentes software, cada una de las
capas anteriores;
• Modelo 1. En este caso las aplicaciones se diseñan en un
modelo web CGI, basadas en la ejecución de procesos
externos al servidor web, cuya salida por pantalla era el
HTML que el navegador recibía en respuesta a su petición.
Presentación, negocio y acceso a datos se confundían en un
mismo script perl. El estado se almacena en el cliente
• Modelo 1.5. Aplicado a la tecnología java se da con la
aparición de las JSP -y los servlets.
En este modelo, las responsabilidades de presentación
recaen en las páginas JSP, mientras que los beans
(servlets) incrustados en las mismas son los responsables del modelo de negocio y acceso a datos.
https://victorroblesweb.es/2013/11/18/tutorial-mvc-en-php-nativo/
• Modelo 2X. Aparece con el objetivo de dar respuesta a la necesidad, cada vez más habitual, de desarrollar aplicaciones
multicanal, es decir, aplicaciones web que pueden ser atacadas desde distintos tipos de clientes remotos. Así, una
aplicación web multicanal podrá ejecutarse desde una PDA, desde un terminal de telefonía móvil, o desde cualquier
navegador HTML estándar. El medio para lograr publicar la misma aplicación para distintos dispositivos es emplear
plantillas XSL para transformar los datos XML.
PERL Es un lenguaje de programación diseñado por Larrry Wall en 1987. Perl toma características del lenguaje C, del lenguaje
interpretado shell (), awk, sed, Lisp y, en un grado inferior, de muchos otros lenguajes de programación.
Java - Lenguaje de programación orientado a objetos, desarrollado por Sun Microsystems a principios de los años 90, aunque a
finales de 2006 liberó la mayor parte de sus tecnologías Java bajo la licencia GNU GPL.
Servlet - Son objetos que se ejecutan dentro del contexto de un contenedor de "servlets", por ejemplo Tomcat y amplían su
funcionalidad. La palabra servlet deriva de otra anterior, applet, que se refería a pequeños programas que se ejecutan en el
contexto de un navegador web. Por contraposición, un servlet es un programa que se ejecuta en un servidor. El uso más común
de los servlets es generar páginas web de forma dinámica a partir de los parámetros de la petición que envíe el navegador web.
BEAN: Abreviatura científica del botánico Willian Jackson Bean (18631947). Un bean es un componente software que tiene la
particularidad de ser reutilizable y así evitar la tediosa tarea de programar los distintos componentes uno a uno.
JavaBeans - Son un modelo de componentes creado por Sun Microsystems para la construcción de aplicaciones en Java; se
usan para encapsular varios objetos en un único objeto (bean), para hacer uso de un solo objeto en lugar de varios más simples.
La especificación de JavaBeans los define como "componentes de software reutilizables que se puedan manipular visualmente
en una herramienta de construcción".
• JavaScript: dentro de la idea de "full stack development", en la que se persigue que un mismo desarrollador
o desarrolladora pueda implementar tanto la parte que se ejecuta en el servidor (back-end) como la página
que se visualiza en el cliente (front-end), han surgido cada vez más tecnologías que permiten desarrollar en
JavaScript aplicaciones web que se ejecutan en el servidor (la misma usada en el navegador web), como es el
caso de Express.js y Hapi.js (ambos funcionan sobre Node.js), y Meteor.js. Pero esta idea no es nueva, ya en
1995 el servidor web Netscape Enterprise Server ya contemplaba el uso de javascript en el servidor (server-
side javascript).
La Licencia Pública General de GNU, o más conocida por su nombre en inglés GNU General Public License es una licencia
creada por la " Free Software Fundation" y está orientada, principalmente, a proteger la libre distribución, modificación y uso
de software. Su propósito es declarar que el software cubierto por esta licencia es software libre y protegerlo de intentos de
apropiación que restrinjan esas libertades a los usuarios. El proyecto GNU ( GNU es un acrónimo recursivo para "GNU No es
Unix"). Comenzó en 1984 a desarrollar un sistema operativo completo con la principal propiedad de ser Software Libre.
es un sistema de gestión de bases de datos relacional desarrollado bajo licencia dual: Licencia pública general/Licencia
comercial por Oracle Corporation y está considerada como la base de datos de código abierto más popular del mundo, y una
de las más populares en general junto a Oracle y Microsoft SQL Server, todo para entornos de desarrollo web.
ASP.NET es la evolución de ASP, incluyendo cambios sustanciales, que funcionan sobre el framework .NET
4.- Escalabilidad.