Software Engineering For Internet Applications

Pgina 1 de 30

Captulo 1 - Introduccin Dnde est el desafo, qu es lo interesante, que nos inspira en las aplicaciones Web? Existen algunos desafos relacionados con la tecnologa que son fciles de identificar. Por ejemplo, en muchas situaciones sera ms conveniente interactuar con un sistema de informacin hablndole y escuchando. Podemos identificar fcilmente algunas de las caractersticas ausentes en las aplicaciones web tpicas. Por ejemplo, sesiones compartidas y portables. Puedes usar Internet para compartir tu msica o fotografas. Puedes compartir tus documentos. Lo nico que generalmente no se puede compartir en Internet es tu experiencia al usar Internet. Hablando de navegadores mviles, sus pequeas pantallas nos obligan a plantear las cuestiones de interfaces multimodales y personalizacin. Como ingeniero, te tocar decidir cundo tiene sentido hablar con el usuario, escucharlo, desplegar una pantalla de opciones escritas y solicitarle que seleccione y haga clic para elegir una de ellas. En el lado de la personalizacin, considera los sistemas de coparticipacin de conocimiento (knowledge sharing) o gestin del conocimiento (knowledge management). Si consideramos una organizacin que genera un milln de documentos por da, no sera interesante disponer de un sistema de informacin lo bastante listo como para imaginarse cules son los tres que presumiblemente te resultarn ms interesantes? Cules son las metas humanas duraderas no alcanzadas? Conectarse con otras personas y aprender. El correo electrnico y la biblioteca de referencia son las dos aplicaciones de la Internet universalmente atractivas. Consideremos la meta de conectarse con otras personas. Supongamos que las personas no se conocen todava. Puede ayudar la tecnologa? El clsico estudio de 1973 de Mark Granovetter The Strength of Weak Ties mostr que la mayora de las personas obtiene sus trabajos a partir de personas que no conocan muy bien. Existen ventajas sociales y econmicas acumuladas en las redes de personas con gran cantidad de lazos dbiles. Estas redes permiten un flujo de informacin mucho ms veloz que las redes en las cuales las personas se apegan a sus familias y aldeas. Pero, cmo encontrars a las personas que te pueden ayudar? Tal vez necesitamos un sistema de informacin donde los individuos interesados en un tema en particular se puedan comunicar entre s, o sea, una comunidad en lnea. Qu podemos decir sobre la segunda meta importante (aprender)? La idea bsica siempre ha sido amplificar los esfuerzos de nuestros ms grandes maestros actuales, lo cual usualmente se hace enlatndolos y envindolos a los nuevos estudiantes. El mecanismo de envasado es casi siempre una cmara de vdeo. Hemos continuado esencialmente el mismo enfoque durante cuarenta aos. Si hubiera funcionado, los resultados espectaculares estaran a la vista. Qu tal si, en lugar de incrementar la cantidad de estudiantes por cada maestro, incrementamos la cantidad de maestros? Si son las tres de la maana y querms aprender sobre mecnica cuntica, todo lo que necesitas hacer es sacar un libro de tu estantera y encender la luz de lectura. Pero qu pasa si quieres ensear a las tres de la maana? Qu pasara si pudieras conectarte a un sistema de informacin basado en un servidor y decir: mustrame un listado de todas las preguntas sin respuesta que han publicado los otros usuarios? Luego puedes contestar unas cuantas, simplemente por la satisfaccin de ayudar a otra persona y de sentirte como un experto. Las comunidades en lnea son desafiantes porque el aprendizaje es difcil y las personas son idiosincrticas. Son desafiantes tambin porque el software que
Pgina 2 de 30

Philip Greenspun

funciona para una comunidad de 200 no va a andar para una comunidad de 2.000 20.000. Las comunidades en lnea son proyectos de ingeniera estimulantes porque entregan a los usuarios dos de las cosas que ms quieren para sus vidas: conexiones y educacin.

Pgina 3 de 30

Captulo 2 - Elementos Bsicos Protocolos con estado En un protocolo de comunicaciones tradicional, el programa de computadora A abre una conexin al programa B. Ambos programas corren continuamente mientras dura la comunicacin. De esta manera resulta sencillo para el programa B recordar lo que el programa A le ha enviado. El programa B puede construir estado en su memoria. La memoria puede contener, de hecho, un registro de todo lo que ha llegado por el cable desde el programa A.

Figura 2.1: En un protocolo de comunicaciones tradicional con estado, dos programas que corren en dos computadoras diferentes establecen una conexin y avanzan en el uso de dicha conexin por el tiempo que sea necesario, tpicamente hasta que uno de los programas termina. HTTP: Sin estado y annimo El HyperText Transfer Protocol (HTTP) es el medio fundamental de intercambio de informacin y solicitud de servicios en la Web. Tambin se usa HTTP cuando se desarrollan servicios de texto para usuarios en telfonos mviles y, con VoiceXML, se usa para implementar aplicaciones controladas mediante la voz. Lo ms importante que debemos saber sobre HTTP es que se trata de un protocolo sin estado (stateless). Si miras diez pginas Web, tu navegador realiza diez solicitudes HTTP independientes hacia el servidor Web del proveedor. En cualquier momento entre esas solicitudes, eres libre de reiniciar tu navegador. En cualquier momento entre esas solicitudes, el proveedor es libre de reiniciar su programa servidor. He aqu la anatoma tpica de una sesin HTTP: 1) El usuario escribe www.yahoo.com en el navegador. 2) El navegador traduce www.yahoo.com en una direccin de IP y trata de abrir una conexin TCP al puerto 80 de esa direccin. 3) Una vez que se establece la conexin, el navegador enva el siguiente flujo de bytes: GET / HTTP/1.0 (ms dos grupos retorno de carro - avance de lnea). El GET quiere decir que el navegador est solicitando un archivo. El / es el nombre del archivo, en este caso es simplemente la pgina de ndice. El HTTP/1.0 dice que el navegador prefiere obtener los resultados adhiriendo al protocolo HTTP 1.0. 4) Yahoo responde con un conjunto de cabeceras que indican cul es el protocolo que en realidad se est usando, si el archivo solicitado se encuentra o no, cuntos bytes contiene dicho archivo, y qu clase de informacin est contenida en el mismo. 5) El servidor de Yahoo enva una lnea en blanco, para indicar el fin de las cabeceras. 6) Yahoo enva el contenido de la pgina ndice. 7) La conexin TCP se cierra cuando el navegador recibe el archivo. Puedes verlo por ti mismo desde un intrprete de mandatos (shell) del sistema operativo:
bash-2.03$ telnet www.yahoo.com 80 Trying 216.32.74.53... Connected to www.yahoo.akadns.net.
Pgina 4 de 30

Escape character is '^]'. GET / HTTP/1.0 HTTP/1.0 200 OK Content-Length: 18385 Content-Type: text/html <html><head><title>Yahoo!</title><base href=http://www.yahoo.com/>...

En este caso hemos utilizado el mandato Unix telnet con un argumento opcional que especifica el nmero de puerto de la mquina destino; todo lo que escribe el programador se indica en negritas. Escribimos la lnea GET ... y luego apretamos la tecla Enter dos veces. La primer cabecera que devuelve Yahoo es HTTP/1.0 200 OK. El cdigo de estado HTTP 200 significa que el archivo se encontr (OK). No te pierdas en los detalles del ejemplo HTTP. El punto es que cuando se termina la conexin, se termina. Si el usuario sigue un hiperenlace desde la pgina frontal de Yahoo hacia Fotografa, por ejemplo, esto genera una solicitud HTTP completamente nueva. Si Yahoo usa mltiples servidores para operar su sitio, la segunda solicitud puede dirigirse hacia una mquina diferente. Esto suena bien para navegar por Yahoo. Pero supongamos que ests comprando en un sitio de comercio electrnico como Amazon. Si agregas algo a tu carrito de compras en una solicitud HTTP, vas a querer que est all dentro de diez clics. O suponte que registraste tu ingreso a photo.net en el clic 23 y en el clic 45 ests respondiendo a una entrada en un foro de discusin. No querras que el servidor de photo.net olvide tu identidad y te pida nuevamente tu nombre de cuenta y tu contrasea. Esto implica un desafo para ti, el ingeniero: crear una experiencia de usuario con estado apoyada encima de un protocolo fundamentalmente sin estado. Dnde almacenars el estado entre una solicitud y otra? Tal vez en un archivo de bitcora (log) en el servidor Web. El servidor escribira algo como Joe Smith quiere tres copias de Bus Nine to Paradise de Leo Buscaglia. En cualquier solicitud posterior de Joe Smith, el script que corre en el servidor puede controlar simplemente en el archivo de bitcora y desplegar los contenidos del carrito de compras. Un problema con esta idea, es que el HTTP es annimo. El servidor Web no sabe que Joe Smith se est conectando. El servidor solamente conoce la direccin IP de la computadora que hace la peticin. Algunas veces esto se traduce en un nombre de host. Si es algo como joe-smiths-desktop.stanford.edu, tal vez se pueda identificar las peticiones siguientes que vengan desde ese IP como provenientes de la misma persona. Pero, qu pasa si es cache-rr02.proxy.aol.com, uno de los servidores intermediarios (proxy) que conectan a Internet a los 20 millones de usuarios de America Online? Es muy probable que la siguiente solicitud del mismo usuario provenga de una direccin IP distinta, o sea, de una computadora fsicamente diferente tomada entre los bastidores y ms bastidores repletos de mquinas proxy de AOL. Si la siguiente solicitud que venga de cache-rr02.proxy.aol.com es muy probable que se originada por otra persona, o sea, otro ser humano fsico entre los 20 millones de suscriptores de AOL que comparten un conjunto comn de mquinas proxy. De alguna manera debemos recordar cierta informacin de un usuario individual, que ser devuelta en la siguiente peticin de ese usuario. Una idea sera rescribir todos los hiperenlaces en las pginas que se entregan. Se personaliza la salida de tal manera que un usuario que sigue un enlace est enviando informacin extra al servidor. Amazon.com incorpora claves de sesin en las URLs. Este identificador de sesin se utiliza como clave para encontrar el contenido del carrito de compras en una base de datos dentro de amazon.com. Una implementacin alternativa sera codificar todo el contenido del carrito de compras en la URL, en lugar del ID de sesin (aunque se debe confiar ciegamente en que todos los navegadores podrn procesar URLs largas). Cookies En lugar de dar vueltas con la reescritura de los hiperenlaces en las pginas HTML podemos aprovechar una extensin de HTTP denominada cookies. Las cookies son un mecanismo general que las conexiones del lado de servidor pueden usar tanto para almacenar como para recuperar informacin del lado cliente de la conexin. Cmo funciona? Luego de que Joe Smith agrega un libro a su carrito de compras, el servidor escribe: Set-Cookie: cart_contents=1588750019; path=/
Pgina 5 de 30

Siempre y cuando Joe no cierre su navegador, en cada peticin subsecuente al servidor, el navegador agrega la cabecera: cart_contents=1588750019. Los programas del lado del servidor pueden leer esta cabecera y extraer el contenido actual del carrito de compras. Parece la solucin perfecta? Lo es en ciertos sentidos. Si eres un intelectual de ciencias de la computacin te puedes enorgullecer del hecho que esto forma un sistema de gestin de base de datos distribuido. En lugar de mantener un enorme archivo de bitcora en tu servidor, ests manteniendo pedacitos de informacin en miles de mquinas de usuario alrededor del mundo. Pero un problema con las cookies es que la especificacin limita lo que podemos pedir al navegador que almacene por cuenta de nuestro servidor a no ms de 20 cookies y cada una de esas cookies no debe tener ms de 4 kilobytes de tamao. Un problema menor es que la informacin de las cookies se devuelve al servidor en cada carga de pgina. Si te has consentido almacenando 80 kilobytes de informacin en 20 cookies y el usuario tiene acceso mediante un modem, esto va a enlentecer la interaccin Web. Un problema ms profundo con las cookies es que no son portables para el usuario. Si Joe Smith inicia su experiencia de compra desde su computadora de escritorio en el trabajo y quiere continuar desde el telfono mvil en el taxi o desde el navegador Web en su casa, no puede recuperar desde all el contenido de su carrito de compras. El carrito reside en la memoria de su computadora del trabajo. Un ltimo problema con las cookies es que un pequeo porcentaje de los usuarios las tienen deshabilitadas debido a los problemas de privacidad ilustrados en la figura 2.2.

Figura 2.2: Suponga que tres editores cooperan y se ponen de acuerdo para servir sus propagandas desde http://noprivacy.com. Cuando Joe User visita search-engine.com y escribe "crema acn", la pgina vuelve con una IMG referenciando a noprivacy.com. El navegador de
Pgina 6 de 30

Joe visitar automticamente a noprivacy.com y solicitar el "the GIF for SE9734". Si esta es la primera vez que Joe est usando cualquiera de esos tres servicios que cooperan entre s, noprivacy.com enviar una cabecera Set-Cookie al navegador de Joe. Entre tanto, searchengine.com enva un mensaje a noprivacy.com diciendo que "SE9734 fue una solicitud por pginas de crema para acn" La cadena "crema acn" se almacena en la base de datos de noprivacy.com junto con "browser_id 7586". Cuando Joe visita bigmagazine.com lo fuerzan a registrarse y dar su nombre, direccin de correo electrnico, direccin postal y nmero de tarjeta de crdito. No hay propagandas en bigmagazine.com. Tienen demasiada integridad para ponerlas. Entonces incluyen en sus pginas un IMG que referencia un GIF en blanco en noprivacy.com. El navegador de Joe solicita el GIF para BM17377" y, como est dialogando con noprivacy.com, el sitio que envi la cabecera Set-Cookie, el navegador incluye una cabecera de cookie que dice: "Soy el browser_id 7586". Cuando todo est terminado, la gente en noprivacy.com sabe el nombre de Joe User, sus intereses, y el hecho de que ha descargado seis JPEG de nalgadas desde kiddieporn.com. Un enfoque de ingeniera razonable al uso de las cookies es enviar un identificador nico para los datos, en vez de los datos mismos, tal como en el caso de los "ID de sesin en el URL" del ejemplo de amazon.com descripto previamente. La informacin relacionada con el contenido del carrito de compras se almacena en alguna clase de bitcora en el servidor. De esta manera esa informacin se puede obtener desde otra ubicacin. Para ver cmo funciona esto en la prctica, vea un intrprete de mandatos y solicita la pgina inicial de photo.net:
bash-2.03$ telnet www.eveandersson.com 80 Trying 64.94.245.206... Connected to www.eveandersson.com. Escape character is '^]'. GET / HTTP/1.0 HTTP/1.0 200 OK Set-Cookie: ad_browser_id=3291092; Path=/; Expires=Fri, 01-Jan-2010 01:00:00 GMT Set-Cookie: ad_session_id=3291093%2c0%2c6634C478EF46FC%2c10622158; Path=/; MaxAge=86400 Set-Cookie: last_visit=1071622158; path=/; expires=Fri, 01-Jan-2010 01:00:00 GMT Content-Type: text/html; charset=iso-8859-1 MIME-Version: 1.0 Date: Thu, 03 Feb 2005 00:49:18 GMT Server: AOLserver/3.3.1+ad13 Content-Length: 8289 Connection: close <html> <head> ...

Nota que se establecen dos cookies. La primera, ad_browser_id tiene una fecha de expiracin explcita en enero de 2010. Esto indica al navegador que debe almacenar en el disco rgido el valor de la cookie, en este caso "3291092". El valor de la cookie se enviar al servidor hasta que se cumpla la fecha de expiracin, incluso aunque el usuario cierre y reinicie su navegador. Cul es el sentido de disponer de una cookie en el navegador? Si el usuario dice "Prefiero las cosas en slo texto" o "Prefiero el idioma francs", esas son informaciones que vale la pena almacenar en el navegador. La preferencia para slo texto puede estar relacionada con la conexin a Internet lenta de esa computadora. Si la computadora est en una casa llena de francfonos, existe la posibilidad de que todas las personas que comparten el navegador prefieran el francs. La segunda cookie que se carga, ad_session_id se configura para expirar despus de una hora("Max-Age=3600"). Si no se configura explcitamente su momento de expiracin, entonces expirar cuando el usuario cierre su navegador. Hay cosas que vale la pena asociar con el ID de sesin como el contenido del carrito de compras en un sitio de comercio electrnico, aunque se debe notar que si photo.net fuera un sitio de compras no sera buena idea que la cookie de sesin expire en una hora!. Resulta un fastidio que uno se tome el trabajo de llenar un carrito de compras, te interrumpan y te saquen de la computadora unas horas y luego tener que hacer todo de nuevo cuando regresas a lo que pensabas que era una pgina Web activa.
Pgina 7 de 30

Si estuviramos registrados en photo.net, tendramos una tercer cookie, que identifica al usuario. Los idiomas y preferencias de presentacin almacenados en el servidor para ese usuario tendran precedencia sobre las preferencias correspondientes al ID del navegador. Almacenamiento del lado del servidor Hasta este momento hemos conseguido que la informacin de ID viaje de ida y vuelta al navegador, sea a travs de las cookies o mediante la rescritura de las URLs. Lo que necesitamos ahora es idear una manera de mantener en el servidor Web la informacin asociada. Para ganar flexibilidad a la hora de presentar y analizar los datos proporcionados por los usuarios, probablemente vas a desear que la informacin se mantenga en forma estructurada. Por ejemplo, sera bueno tener tablas. Cul es una buena herramienta para almacenar tablas de informacin? Uno nunca debe aplicar una tecnologa ms compleja de lo necesario para resolver un problema. Cualquier fuente de persistencia en la Web debe lidiar potencialmente con miles de usuarios simultneos que estn leyendo y escribiendo en la base de datos. ste es el problema que resuelven los Sistema de gestin de base de datos (DBMS por su sigla en ingls). Caractersticas de un DBMS: Atomicidad: los resultados de la ejecucin de la transaccin se confirman todos juntos o se revierten todos. O todos tienen efecto, o ninguno. Consistencia: la base de datos se transforma desde un estado vlido en otro estado vlido. Una transaccin es legal solamente si obedece las restricciones de integridad definidas por el usuario. Aislamiento: el resultado de una transaccin es invisible a las otras transacciones hasta que se completa. Durabilidad: una vez comprometida (completada), los resultados de una transaccin son permanentes y sobreviven averas futuras tanto del sistema como del medio de almacenamiento. Se debe notar que para lograr la D del ACID, la computadora debe disponer de ms de un disco rgido. Por qu un sistema de gestin de bases de datos relacional? El primer pilar de la popularidad de los RDBMS es el lenguaje declarativo denominado SQL. El estilo de programacin ms comn no es declarativo; se llama imperativo o procedural. T le dices a la computadora que debe hacer, paso a paso. Los programas escritos en este estilo tienen dos desventajas: rpidamente se vuelven complejos y entonces se necesitan programadores profesionales para desarrollarlos y mantenerlos, y contienen montones de errores. En el estilo de programacin declarativo le decimos a la computadora qu es lo que queremos, no le decimos al RDBMS si tiene que leer primero la tabla de usuarios y luego ver en la tabla de los foros o viceversa. Slo especificamos las caractersticas deseadas del reporte y queda como trabajo para el RDBMS la tarea de prepararlo. El segundo pilar de la popularidad de las RDBMS es la separacin que produce entre los datos importantes y los descuidos de los programadores. La RDBMS limita lo que los programadores pueden hacer, slo dictar oraciones muy simples de la forma INSERT, DELETE y UPDATE. El tercer y ltimo pilar de la popularidad de las RDBMS es su buena performance con varios miles de usuarios simultneos. Este atributo es ms una reflexin sobre el refinado estado del desarrollo comercial en sistemas como IBM DB2, Oracle, Microsoft SQL Server, y la open source PostgreSQL, que una caracterstica inherente a los RDBMS en s mismos. Pasos del desarrollo de cualquier aplicacin web 1. Desarrollar el modelo de datos. Cul es la informacin que vas a almacenar y cmo la vas a representar? 2. Desarrollar una coleccin de transacciones legales sobre ese modelo, por ejemplo, las inserciones y las actualizaciones.
Pgina 8 de 30

3. Disear el flujo de las pginas. Cmo va a interactuar el usuario con el sistema? Cules
sern los pasos que van a llevar hasta cada una de esas transacciones legales? (Note que la idea de flujo de pginas abarca el diseo de interaccin en la Web, en navegadores mviles, y tambin va menes de voz jerrquicos con VoiceXML pero no a los sistemas de voz conversacionales.)

4. Implementar las pginas individuales. Vas a tener que escribir los scripts que consultan informacin al modelo de datos, envuelven esa informacin en una plantilla (en HTML para el caso de una aplicacin Web), y retorna el resultado combinado al usuario. Es muy poco probable que tengas muchas elecciones a la hora de escoger el almacenamiento persistente. Tendrs que usar una RDBMS y no vas a realizar ninguna decisin tecnolgica fundamental en los Pasos 1 y 2. El diseo del flujo de pginas es un ejercicio puramente abstracto. Existen algunos lmites impuestos por la tecnologa sobre la interfaz pero en general derivan de estndares pblicos como HTML, XHTML Mobile Profile, y VoiceXML. Entonces, en el Paso 3 tampoco tienes decisiones tecnolgicas que tomar. El Paso 4 es carente de inters desde el punto de vista intelectual y tambin desde el punto de vista de la ingeniera. Un servicio de Internet triunfa o fracasa por los pasos 1 al 3. Qu puede hacer el servicio por el usuario? Resulta comprensible y utilizable el flujo de pginas? Las respuestas a esas preguntas estn determinadas por los Pasos 1 al 3. Sin embargo, el Paso 4 es donde uno tiene un enorme rango de alternativas de tecnologa y por lo tanto parece generar muchas discusiones. Introduccin al HTML Armado con una alta pila de etiquetas, puedes empezar a desparramarlas entre tus palabras ms o menos al azar. Aunque los navegadores son extremadamente permisivos frente al marcado tcnicamente ilegal, resulta til saber que un documento HTML consiste oficialmente de dos partes: la cabeza (head) y el cuerpo (body). La cabeza contiene informacin acerca del documento como un todo, como por ejemplo el ttulo. El cuerpo contiene la informacin que el navegador debe mostrar al usuario. Otro tema relacionado con la estructura es que tienes que asegurarte de cerrar cada elemento que abras. Si tu documento tiene una etiqueta <BODY> entonces debe tener una </BODY> al final. Si se inicia una tabla HTML con <TABLE> y no existe el </TABLE>, el navegador puede que no muestre nada. Las etiquetas pueden anidarse, pero debes cerrar la ms recientemente abierta antes de las otras. Se muestra a continuacin el fuente HTML de un documento Web con formato simple:
<html> <head> <title>Nikon D1 Digital Camera Review</title> </head> <body bgcolor=white text=black> <h2>Nikon D1</h2> by <a href="http://philip.greenspun.com/">Philip Greenspun</a> <hr> Little black spots are appearing at the top of every ... <h3>Basics</h3> The Nikon D1 is a good digital camera for ... <p> The camera's 15.6x23.7mm CCD image sensor ... <h3>User Interface</h3> If you wanted a camera with lots of buttons, switches, and dials ... <hr> <address> <a href="mailto:philg@mit.edu">philg@mit.edu</a> </address> </body> </html>

Cmo elegir un entorno de programacin Cmo elegir un lenguaje procedimental

Pgina 9 de 30

Como se mencion antes, la mayor parte de tu cdigo procedimental, tambin llamados scripts Web no va a hacer ms trabajo que consultar la RDBMS y unir los resultados con una plantilla HTML, XHTML Mobile Profile, o VoiceXML. Es as que tu productividad o el esfuerzo de mantenimiento del cdigo no van ser afectados en demasa por la eleccin del lenguaje procedimental. Dicho esto, vamos a decir algo amable sobre los lenguajes de scripting. Si necesitas escribir algunas abstracciones complejas, siempre puedes ponerlas en Java corriendo dentro de Oracle, o en C# corriendo dentro de Microsoft .NET. Pero para la capa de presentacin, o sea, las pginas individuales, que no se te escapen las ventajas de usar un lenguaje ms simple y terso como Perl, Tcl y Visual Basic. Cmo elegir un entorno de ejecucin A continuacin se tratan ciertos temas que debes tener en cuenta al seleccionar servidores Web y servidores de aplicacin Web. una URL = un archivo Lo primero que debes mirar en un entorno de ejecucin es la propiedad de que una URL visible para el usuario corresponde a un archivo en el sistema de archivos. Es mucho ms rpido depurar un sistema si, dada una queja sobre http://photo.net/foobar puedes saber que vas a encontrar el programa de computadora responsable en /web/photonet/www/foobar.algo. Algunos entornos de programacin donde esto es cierto son: Perl CGI Microsoft Active Server Pages Java Server Pages AOLserver ADP templates y scripts .tcl

Una notable excepcin de esta propiedad son los Java servlets. Un servlet tpicamente procesa varias URLs. Esto se muestra incmodo en la prctica, porque te enlentece cuando tratas de reparar un defecto en el cdigo de otra persona. Las ideas de modularidad y reutilizacin de cdigo son buenas, pero trata de pensar en cuntos archivos tiene que revisar un programador hasta que encuentra el defecto. Uno, es magnfico. Dos, probablemente est bien. N donde N no es conocido, eso no est bien. Filtros Hemos dicho que la modularidad y la reutilizacin de cdigo pueden abandonarse en favor de preservar el principio sagrado de un URL = un archivo. La forma de ganar nuevamente la modularidad y la reutilizacin del cdigo es mediante filtros, la capacidad de instruir al servidor Web para decirle: corre este fragmento de cdigo antes de servir cualquier URL que comience con /yow/. Esto es particularmente til para el cdigo que realiza la tarea de control de accesos. Supongamos que tiene quince scripts que forman la experiencia de administracin para un sistema de concursos. Quieres asegurarte que slo los administradores autorizados pueden usar esas pginas. Para controlar los permisos de acceso administrativo se requiere una consulta SQL. Puedes escribir un procedimiento denominado CheckForContestAdminAuthority y luego explicar a los autores de los scripts que deben incluir una llamada a este procedimiento en cada uno de los quince scripts administrativos. Igual tienes ahora quince copias del mismo cdigo: una sentencia IF, una llamada a procedimiento y la llamada al procedimiento que muestra el mensaje de error si CheckForContestAdminAuthority retorna unauthorized. Pero la consulta SQL ocurre slo en un lugar y se puede actualizar de manera centralizada. El problema principal de este enfoque no son las quince copias del IF y sus acompaantes. El problema es que inevitablemente uno de los autores de scripts se va a olvidar de incluir la verificacin. Entonces tu sitio tendr un agujero de seguridad. Puedes cerrar el agujero y eliminar catorce copias del IF si instalas el cdigo como un filtro en el servidor. Ya habrs notado que para que esto funcione, el mecanismo de filtro debe incluir una API para abortar el
Pgina 10 de 30

servicio de la pgina solicitada. El filtro debe ser capaz de decirle al servidor Web: no sigas atendiendo a ese usuario con el script o documento solicitado. URLs abstractas Como ingeniero, tu contribucin principal a un servicio de Internet ser el modelo de datos y el diseo de la interaccin (Pasos 1 al 3). Cuando ests esbozando el flujo de pginas para un foro de discusin en una pizarra, le das nombres a las pginas, como por ejemplo todos-lostemas, un-tema, un-hilo, pega-respuesta, pega-confirmacin-respuesta, etc. Vamos a darles el nombre de URLs abstractas. Supongamos que eliges implementar tu servicio en Java Server Pages. Tiene sentido que las URLs sean todos-los-temas.jsp, un-tema.jsp, unhilo.jsp, etc.? Porqu deberan ver tus usuarios que utilizaste JSP? Les interesa? Y si cambias de manera de pensar y te pasas a Perl, vas a cambiar las URL visibles para los usuarios a todos-los-temas.pl, un-tema.pl, un-hilo.pl, etc.? Esto va a afectar los marcadores de todos los usuarios. An ms importante, este cambio va a afectar todos los enlaces que hay en otros sitios y apuntan al tuyo. se es un precio muy alto a pagar por un cambio en la implementacin que debera haber sido invisible a los usuarios finales. Lo que necesitas es un entorno de programacin Web lo suficientemente poderoso como para que te permita construir algo que llamaremos un procesador de solicitudes. Este programa lee la solicitud entrante como URL abstracta, por ejemplo, un-tema y sigue la siguiente lgica: existe un archivo .jsp en el sistema de archivos; si es as, entonces ejectalo busca en las cabeceras para ver si solicitan XHTML Mobile Profile para un navegador de telfono mvil; si es as y si adems hay un archivo .mobile en el sistema de archivos, servirlo, sino, continuar busca un archivo .html busca un archivo .jpg busca un archivo .gif

(Seguramente vas a querer adecuar el orden de las preferencias para tu servidor Web.)

Bitcora centralizada de las consultas a la RDBMS El trabajo principal de nuestros scripts Web ser formular las consultas y transacciones SQL. Si las cosas salen mal, la informacin ms valiosa que puedas obtener es que le dijeron mis scripts Web a la RDBMS que haga y en cul secuencia. Los mejores programas para servidores de aplicacin/Web tienen un nico archivo de bitcora en el cual pueden opcionalmente escribir todas las consultas que se envan a la RDBMS. Servidores que consultan servidores externos Es til construir un sistema de propsito general para almacenar en forma intermedia (cach o memorizacin) los resultados de la evaluacin de cualquier expresin en una variable global. Por qu? Se ve como mala netiqueta que escribamos un programa con el potencial de imponer una carga poco razonable sobre los servidores que se consultan. Adems, si se da el caso que el sitio se vuelve popular, estara realizando consultas a los mismos servidores varias veces por segundo para obtener los mismos datos. Por ltimo, sera mejor si los usuarios no debieran esperar hasta que las pginas se traigan si no necesitan los datos actualizados al ltimo momento. Con la pgina HTML almacenada completa en una variable, queda disponible en el espacio de memoria virtual del AOLserver y se puede acceder mucho ms rpido que incluso un archivo esttico. Los usuarios que desean una respuesta en tiempo real pueden solicitar una mediante un clic adicional. Los clculos realizados para ellos, sirven entonces para actualizar el cach de los usuarios casuales. El mecanismo de cach puede parecer un exceso de ingeniera, pero de tanto en tanto nuestro sitio puede ser enlazado desde sitios de noticias extremadamente populares y recibira varias solicitudes por segundo. La capacidad de manejar una carga razonablemente alta como esa,
Pgina 11 de 30

all por mediados de 1990 sin una enorme granja de servidores era ms bien rara. Si todas esas solicitudes hubieran pasado directamente a travs de la oficina de censos, por ejemplo, el servicio completo se hubiera arrastrado por la lentitud.

Pgina 12 de 30

Captulo 3 - Planificacin Todos en este curso van a construir una comunidad de aprendizaje en lnea, un lugar donde los usuarios se ensean unos a otros. Un buen cliente puede ser una organizacin sin fines de lucro que desea instruir a la gente acerca de su misin. Otro bueno podra ser una empresa de tamao medio que quiere un sistema de coparticipacin de conocimiento para los empleados. Otro puede ser un grupo de estudiantes de tu universidad. Si no puedes encontrar un cliente, elige un tema que te apasione. Elige un tema en el cul te parece que puedas conseguir o generar contenido magntico, algunos tutoriales que atraern usuarios a tu servicio. Antes de empezar a escribir cdigo, sin embargo, nos gustara que hagas un poco de planificacin y de anlisis competitivo. Fundamentalmente, necesitas responder las preguntas Quin va a ensear qu a quines? y Cules son las otras alternativas disponibles en la actualidad para esta clase de aprendizaje? Clases de usuarios Comienza por dividir tus usuarios en clases. Dos usuarios deben caer en la misma clase si esperas que ellos quieran sustancialmente la misma experiencia con tu servicio. A medida que vas dividiendo a tus usuarios en clases, resulta til pensar a la vez cules niveles de privilegios administrativos se necesitarn. Casi nunca resulta til pensar en trminos de maestros versus alumnos; el punto central de una comunidad en lnea es que cada usuario aprende en algunos momentos y ensea en otros. Descomposicin en clases de usuarios: el ejemplo de photo.net Para darte una idea de cmo sera una descomposicin en clases de usuarios, iremos paso a paso por la del servicio photo.net. Primero, consideremos el objetivo general de photo.net: Un lugar donde una persona puede ir y obtener la respuesta a cualquier pregunta sobre fotografa. Segundo, considere los niveles de privilegios de administracin. Existen los administradores del sitio, que tienen libertad para editar o borrar cualquier contenido del sitio. Estos administradores tambin tienen el poder de ajustar la autoridad de los otros usuarios. Tenemos tambin los moderadores que tienen autoridad para aprobar o eliminar entradas (posts) en determinados foros de discusin. Finalmente estn los usuarios regulares que pueden leer y publicar entradas, y editar sus propias contribuciones. Un servicio que sea menos popular puede funcionar con slo dos niveles de privilegios de administracin. Otra manera diferente de dividir a los usuarios es mediante su propsito al visitar el sitio: aspirante a apunta-y-dispara desea un consejo rpido sobre cul cmara comprar de tipo apunta-y-dispara y dnde adquirirla; quiere invertir el mnimo tiempo, esfuerzo y dinero en fotografa fotgrafo novicio de compras quiere empezar a tomar fotos como expresin artstica, pero no tiene una cmara con controles flexible en este momento fotgrafo novicio aprendiendo dispone del equipamiento correcto, pero quiere ideas sobre dnde, cundo y cmo usarlo; desea crticas para los trabajos terminados fotgrafo experto quiere nuevas ideas, ver qu hay de nuevo en el mundo del hardware, quiere compartir su experiencia, quiere comunidad aspirante a fotgrafo comercial puede ser un estudiante de secundaria o de universidad curioso sobre su futuro o una persona mayor que est pensando en cambiar de carrera; quiere saber si es factible vivir de la fotografa, y si la respuesta es afirmativa, cmo iniciarse. expositor quiere subir fotos en el sistema de participacin y desarrollar una audiencia entre los lectores de photo.net viajero desea conocer ubicaciones en todo el mundo para aprovechar de fotografiar como parte de un viaje ya planeado o quiere ideas sobre a dnde viajar para obtener inspiracin fotogrfica lector le gustan las historias de viajes como las de Travels with Samantha y mirar las fotografas pero no desea tomar l mismo las fotos. Una ltima manera de dividir a los usuarios que pude resultar til es de acuerdo a cmo se
Pgina 13 de 30

conectan. En el caso de photo.net, es fcil concebir el usuario con navegador Web. Este usuario sube y se descarga fotos, participa en las discusiones, lee los tutoriales, compra equipamiento, etc. La misma persona puede conectarse con un telfono mvil, en cuyo caso se convierte en un usuario mvil. Si el usuario mvil est en medio de un proyecto fotogrfico, queremos proporcionarle informacin sobre tiendas de fotografa cercanas, laboratorios de procesamiento, tiendas de reparacin, hora de la puesta de sol, buenas ubicaciones y otros datos tiles. Si el usuario mvil se conecta con propsitos sociales, necesitamos pensar en formas prcticas mediante las cuales una persona con un telfono mvil puede participar en una comunidad en lnea. El mismo desafo de ingeniera nos espera con el usuario telefnico. Escenarios de uso Para cada clase de usuario, debes escribir una idea aproximada de qu es lo que obtiene de tu nuevo servicio una persona de esa clase. Puedes dar indicios del flujo de pginas. Ejemplo: fotgrafo novicio de compras en photo.net El novicio debe empezar leyendo un puado de artculos cuidadosamente escritos sobre asesoramiento para adquisicin de cmaras y luego las evaluaciones de cmaras especficas. Muchos de los mejores consejos de adquisicin estn contenidos en los intercambios de preguntas/respuestas dentro de los foros, y por ello los editores necesitan una manera de seleccionar y apuntar a las mejores discusiones en los archivos de los foros. Luego de que nuestro usuario ha ledo todo este material, sera ideal que se lo redirija a un foro de preguntas y respuestas (Q&A) donde sean bienvenidas las preguntas del estilo esto es lo que he decidido comprar, qu piensan?. Esto puede implementarse en la forma de un sistema explcito de compras social con una columna para las respuestas de los otros lectores y una columna adyacente con ofertas de negocios de venta de cmaras. Ejemplo: administrador a nivel de sitio en photo.net Al conectarse, el administrador a nivel de sitio debe poder ver una pgina que le muestre el pulso de la comunidad con estadsticas de la cantidad de nuevos usuarios registrados, la cantidad de fotografas que se incorporaron en el sistema de fotos compartidas, la actividad en los foros de discusin, los esfuerzos relativos de los moderadores (voluntarios de la comunidad). Si hay usuarios no suspendidos que han sido responsables de una gran cantidad de trabajo de moderacin para eliminar postings fuera de foco, etc., se deberan mostrar con un resumen de las actividades problemticas y una opcin para suspenderlos. Construye las pginas de perfil de usuario Cuando uno construye una aplicacin sera ideal si pudisemos contar con los usuarios potenciales en la misma habitacin que nosotros todo el tiempo. Sus necesidades seran entonces manifiestas y concretas. Esto no es muy prctico, sin embargo, y por lo tanto a los fines de hacer ms concretas a las personas para las cuales ests construyendo la aplicacin, deberas escribir dos o tres pginas de perfiles. Una pgina de perfil contiene la siguiente informacin: una foto del usuario el nombre, edad, ocupacin, estado civil, situacin de vivienda, e ingreso las metas de corto y largo plazo del usuario relevantes a la comunidad en lnea que ests construyendo las preguntas inmediatas que este usuario va a traer al sitio la clase de computadora y conexin en la casa de esta persona otras informaciones que ayuden a humanizar a esta persona de ficcin (ejemplo: experiencia en el uso de tecnologa de informacin). Evaluacin de alternativas: Offline Hay buenas razones para mirar los mejores elementos de los sistemas y recursos offline. A lo largo de varios milenios, muchos de esos sistemas se han refinado exquisitamente y son extremadamente efectivos. La comunidad online y el entorno de aprendizaje asistido por computadora que ests construyendo se puede mejorar mucho gracias al cuidadoso estudio de
Pgina 14 de 30

las mejores alternativas offline. Analiza las mejores caractersticas de las alternativas offline de aprendizaje sobre el tema determinado para el servicio que estars construyendo. Indica aquellas caractersticas que piensas que se traducirn en una comunidad online, y cmo se lograr. Escribe una justificacin tres oraciones explicando por qu tu comunidad online va a ser una mejora sobre las alternativas offline al menos para algn grupo de personas. Evaluacin de alternativas: Online Cuando realices tu anlisis de los competidores online debes revisar cualquier servicio o recurso de aprendizaje en tu rea temtica. Debes prestar especial atencin a las comunidades de aprendizaje online. Antes de ponerte a navegar, puede serte til considerar los siguientes elementos de una comunidad online sustentable: 1. contenido atractivo escrito por expertos 2. medios de colaboracin (diferentes maneras en las cuales un usuario puede publicar informacin que luego est disponible para los otros usuario) 3. facilidades poderosas para navegar y buscar entre el contenido atractivo y el contenido contribuido 4. medios para delegar la moderacin 5. medios de identificar miembros que estn imponiendo una carga desproporcionada sobre la comunidad y formas de cambiar su comportamiento y/o excluirlos de la comunidad sin que se den cuenta. 6. medios para que los mismos miembros de la comunidad puedan extender el software Cuando visites un sitio debes preguntarte: Son ellos los autores o licenciaron una parte sustancial del cuerpo de contenido tutorial? Revisa la relacin entre el contenido de autora del publicador y el que es de autora de los usuarios. Si ms de la mitad del contenido es producido por los usuarios, el sitio se est alejando de la publicacin y se est dirigiendo hacia la comunidad. Preste atencin a las diferentes maneras en las cuales un usuario puede publicar informacin que luego est disponible para los otros usuarios (medios de colaboracin). Verifica si la utilidad de bsqueda predefinida en el sitio retorna resultados a partir de cosas como las contribuciones en los foros de discusin. Trabajando como usuario sin privilegios, no va a serte fcil determinar si el sitio dispone de provisiones para distribuir la carga de moderacin del contenido o de modos de excluir usuarios problemticos. Sin embargo, a veces puedes inferir el elemento 6, si el software permite que usuarios regulares y administradores de la comunidad puedan extenderlo, sin necesidad de ser expertos programadores. Si el sitio es comercial, mira en las listas de oportunidades de trabajo abiertas para determinar cules son las habilidades requeridas. Si el sitio no adopt la religin de URLs abstractas, las extensiones de los nombres de archivo pueden darte las pistas necesarias sobre la tecnologa de implementacin. Si hay un .pl, .asp, .php, .adp, o .tcl indica el uso de un lenguaje de scripting lo cual lo hace apropiado para que un novato lo programe. Si hay un .jsp o el trmino servlet en el URL indica el uso de Java, un lenguaje destinado slo para programadores profesionales. Busca las mejores comunidades online que existen en tu rea temtica. Controla cunto satisfacen los seis elementos de sustentabilidad que se enumeraron ms arriba. Escribe cualquier cosa particularmente buena o mala sobre el proceso de registracin y los mecanismos de colaboracin, por ejemplo, en los foros de discusin, comentarios de los artculos y salas de chat. Busca interfaces para dispositivos mviles y de voz. Si estn disponibles, prubalas. Trata de encontrar evidencia de personalizacin y controles directos de las preferencias. Necesita el mundo ms de una comunidad online? Existen dos factores que previenen una concentracin en el mundo de las comunidades online de aprendizaje. Uno es la idiosincrasia de la creacin literaria. La segunda fuerza que previene la concentracin en el mundo de las comunidades online de aprendizaje es la naturaleza de la comunidad en s misma.
Pgina 15 de 30

Si fuera posible para cada uno amontonarse en una nica comunidad y obtener una magnfica experiencia de aprendizaje, America Online hace rato que hubiera absorbido todas las comunidades ms pequeas de la Internet. Uno de los ltimos captulos de este libro se dedica al tema de hacer crecer con gracia una comunidad online. Pero, por ahora, puedes quedarte tranquilo pues es un problema difcil que nadie ha resuelto. Dado suficiente contenido atractivo de calidad y un grupo inicial de personas dedicadas a la enseanza, siempre habr espacio para una nueva comunidad de aprendizaje. Contenido atractivo Se deben identifica los recursos de contenido atractivo para la comunidad. Si parte de este contenido va a provenir de otras personas, escrbeles y solicita su permiso. An si slo vas a usar su trabajo experimentalmente, un autor o publicador puede preocuparse si tu sitio va a ser indexado por las mquinas de bsqueda y los lectores sean dirigidos a tu sitio en lugar del de ellos. En la prctica esto no es problema si tu servidor no es accesible desde la Internet pblica o si incluyes un archivo robots.txt que le indicar a las mquinas de bsqueda que deben excluir cierto contenido. Puedes obtener una respuesta ms amigable de los derechohabientes del copyright si aceptas proporcionar el crdito por el material en la forma de hiperenlaces y si te aseguras que su contenido no ser indexado mltiples veces. Si dispones de un cliente que proporciona todo el contenido atractivo, escribe un resumen de lo que estar disponible y cundo. Al lado de cada clase de documento anota la persona que ser responsable de ensamblar y entregarlos. Como ingeniero, no es tu trabajo ensamblar y desarrollar contenido, pero s es tu trabajo identificar riesgos para el proyecto, tales como no hay suficiente contenido atractivo o nadie pens en el tema del contenido atractivo.

Domain Name System El Domain Name System (DNS) traduce nombres de computadoras legibles para seres humanos, por ejemplo, www.google.com, en direcciones IP legibles por las computadoras y enrutables a travs de la red, por ejemplo, 216.239.57.100. El DNS es una aplicacin distribuida en el sentido que no existe una nica computadora que mantiene las traducciones de todos los nombres posibles. Un registrador de dominios, por ejemploregister.com, registra que los servidores de dominio para el dominio google.com estn en una particular direccin IP. El servidor de nombres local de un usuario consultar a los servidores de nombre de google.com para encontrar la traduccin del nombre de mquina www.google.com. Fjate que no hay nada de mgico en el www; es simplemente un nombre convencional para una computadora que tiene corriendo un servidor Web. El procedimiento de traduccin de un nombre de computadora tal como froogle.google.com es el mismo que se aplica a la traduccin de www Decidirse por un nombre de computadora En conjunto con tu cliente, elige un nombre de computadora para la aplicacin que estars construyendo. Junto a tu cliente debers navegar a travs de la burocracia de IT para registrar ese nombre de computadora y mapearlo a la direccin IP de tu servidor. Si vas a construir un servicio para un cliente que no tiene un dominio de Internet, incentvalo para que seleccione un buen nombre y lo registre. Los autores han tenido buenas experiencias con register.com, un servicio que incluye el uso de sus servidores de DNS; el dueo del dominio puede editar las traducciones de nombre de mquina a direccin IP con una interfaz de navegador Web. Negociar los derechos de propiedad intelectual Una de las cosas que distingue a un ingeniero de software profesional es el xito en negociar los derechos de propiedad intelectual. Si entregas todos los derechos sobre todo lo que produces como trabajo por contrato, no tendrs un bagaje personal de software que puedas reusar en nuevos proyectos. Si no entregas ningn derecho, nadie ser capaz de usar tu software, lo cual quiere decir que no vas a poder resolver problemas sociales u organizacionales. Un buen negociador entrega cosas que son valiosas para el otro lado, pero que no son valiosas de su propio lado. A lo largo de este curso, por ejemplo, t querrs idealmente mantener la propiedad de todo el
Pgina 16 de 30

software que produzcas. De esa manera sers libre de reutilizar el cdigo de cualquier forma o manera. El cliente, sin embargo, va a poner de su parte un montn de tiempo y esfuerzo trabajando contigo durante un perodo de meses y por lo tanto tiene derecho a algn beneficio. Lo que puedes hacer t es otorgar al cliente una licencia para usar tu software. Esto obviamente beneficia al cliente pero tambin te beneficia a ti. Cuanta ms gente haya por all feliz de usar tu software, mejor se ver tu resumen profesional. Deberas tratar de limitar lo que el cliente puede hacer con tu software? Generalmente no vale la pena. Cualquier organizacin que venga a ti para obtener asistencia en la programacin del sitio probablemente no es una organizacin que quiera descolgarse con ofertas de desarrollo de software para otros. Si ellos deciden que de hecho tiene sentido adaptar tu software para otra aplicacin dentro de la compaa, es muy probable que te llamen a ti primero para ofrecerte unos honorarios por consultora a cambio de tu asistencia. Y sobre el tema de limitar tus responsabilidad legales? Con mucha frecuencia se solicita a los ingenieros de software que escriban programas cuyos fallos tienen resultados catastrficos. Suponte que te ofrecen $100.000 para escribir un programa de negocios para un banco de inversiones. Esto suena como un buen trato, hasta que el banco te enjuicia por $100 millones, alegando que un defecto en tu programa les cost $100 millones en ganancias perdidas. Delimitar la responsabilidad legal es dificultoso, an para abogados entrenados, y por ello es mejor dejarlo a los profesionales. Casi todas las licencias de software comercial incluyen una renuncia de garantas. Considera utilizar una licencia estndar de software libre o de programas open source, de las cuales la GNU General Public License es el ejemplo ms conocido. Debes advertir que al usar una licencia de software libre no quiere decir que tu software es entonces libre para todo el mundo. Puedes haber licenciado un cliente bajo la GNU GPL pero si en adelante decides ofrecer una licencia a algn otro es una decisin para el futuro.

Pgina 17 de 30

Captulo 4 - Estructura del Software Estructura general del sistema que vamos a construir. Toda comunidad de aprendizaje online va a tener aproximadamente la misma estructura esencial: 1. base de datos de usuarios 2. base de datos de contenidos 3. relacin usuario/contenido 4. relacin usuario/usuario Base de datos en la lista precedente se usa como trmino abstracto. La base de usuarios, por ejemplo, se puede implementar como un conjunto de tablas SQL dentro de un sistema de gestin de bases de datos relacional. Las tablas para la base de datos de usuarios no necesitan estar separadas de las tablas que implementan los otros mdulos, o sea, todas sern propiedad del mismo usuario, y residirn en el mismo tablespace. Por otro lado, puede ser tambin que la base de datos de usuarios se almacene en forma externa a la comunidad de aprendizaje online. El caso comn en el cual la base de usuarios es externa se da en los sistemas de gestin de conocimiento de las corporaciones, donde los empleados se autentican mediante un servidor central de LDAP. Base de datos de usuarios Como mnimo la base de datos de usuarios debe registrar el nombre real y la direccin de correo electrnico (email) del usuario. Recuerda que cuanto ms identificada, autenticada y ms responsable se la puede hacer, hay ms oportunidad de formar una comunidad a partir del agregado. Un ambiente donde usuarios annimos se gritan entre s detrs de nombres de fantasa no vale la pena es esfuerzo de programacin y administracin de sistemas. La base de usuarios debe disponer de una facilidad para registrar la confiabilidad de un nombre de usuario y direccin de email, pues el nombre ser probablemente ms conocido con confiabilidad a lo largo del tiempo y el email lo ser con menos probabilidad. La base de usuarios debe permitir que los usuarios almacenen un URL personal para contribuir a crear un entorno ms responsable e identificado. Si el URL es un sitio que da a una pgina de Yahoo! eso no va a contribuir mucho a la responsabilidad e identificacin. Por otro lado, si la URL tiene un prefijo como http://research.hp.com/personal/ entonces los otros usuarios van a tener ms confianza en su identidad. Como una de las tristes caractersticas de la Web tal como est estructurada en 1990 es que las URL se corrompen, la base de usuarios necesita alojar un campo extra de datos para registrar que pas cuando el robot intent acceder a la URL almacenada. Si no se puede acceder a la URL en diferentes ocasiones a lo largo de un perodo de una semana, entonces es razonablemente seguro que un programa de computadora suponga que la URL est desactualizada y por lo tanto deje de mostrarla pblicamente. La base de usuarios debe almacenar informacin de privacidad y de preferencias. Como por ejemplo: Desea Jane User mostrar al pblico su direccin de email? Y a otros usuarios registrados? Permite Joe User que le mandes spam con noticias del sitio? Base de datos de contenidos El contenido de una comunidad de aprendizaje online siempre incluye preguntas y respuestas en un foro de discusin. El programador puede empezar por construir una tabla para los mensajes (postings) en los foros de discusin. De los seis elementos requeridos para una comunidad online, el contenido atractivo aparece en primer lugar. La mayora de las comunidades de aprendizaje online ofrecen artculos publicados que se distinguen de las contribuciones de los usuarios. Un programador podra crear entonces una tabla para contener dichos artculos. Todo sitio bien armado que publica artculos, tambin tiene la posibilidad de aceptar comentarios de los usuarios sobre esos artculos. Esos comentarios irn a otra tabla separada. Podemos detectar un patrn aqu? Hemos distinguido una pregunta en una tabla de un foro de
Pgina 18 de 30

discusin porque es un tem de contenido que no es una respuesta a ningn mensaje del foro de discusin. A los artculos los hemos distinguido de los comentarios porque un artculo es un tem de contenido que no es respuesta a ningn otro tem de contenido. Tal vez la representacin de artculos, preguntas, respuestas, etc. se debera unificar todo lo que se pueda. Cada uno de ellos es un tem de contenido. Cada uno tiene uno o ms autores. Cada uno opcionalmente puede ser la respuesta a otro tem de contenido. A continuacin hay algunos servicios que sera interesante centralizar en un nico repositorio de contenido dentro de la base de datos de contenidos: Versionado del contenido. El hecho de si un tem de contenido es una respuesta, comentario o adjunto a algn otro tem. El hecho de que un tem de contenido ha sido aprobado o rechazado por alguno de los moderadores del sitio. A quin debe mostrarse el contenido? Es slo para miembros de un grupo, para un usuario particular, para todos? Quin tiene permiso para editar el contenido? Quin tiene permiso para cambiar a quienes tienen permisos para ver o editar? Quin tiene permiso para comentar sobre un tem? Quin debe revisar los comentarios que se han realizado antes de que vayan a publicarse en vivo? Ritmo del contenido: cundo debe aparecer en vivo? cundo expira? Calidad o importancia del contenido: debe resaltarse frente a los usuarios? Se debera retener hasta que se grade desde el estado de borrador? Resmenes, descripciones y palabras claves del contenido. Una taxonoma consistente a nivel de sitio Quin es el autor o el que contribuy en un tem dado?, y una distincin entre las cosas producidas por el publicador, las que produce un autor y las que produce un usuario. A Quin se debe notificar por medio de email cuando se escribe un comentario o respuesta a un tem de contenido? el hecho de que un tem de contenido ha sido clasificado como de mucho inters para un usuario, o por el contrario de bajo/nulo inters; dadas esas estadsticas, esto implica la habilidad para seleccionar nuevo contenido que es muy probable que sea de inters para el Usuario #17 (esto depende de que el software de procesamiento de texto pueda computar similaridad entre documentos) Relacin usuario/contenido Una comunidad de aprendizaje online generalmente necesita registrar los siguientes sucesos: El Usuario #21 contribuy el Comentario #37 sobre el Artculo #529 El Usuario #192 realiz la Pregunta #512 El Usuario #451 public la Respuesta #3 a la Pregunta #924 El Usuario #1392 ha ledo el Artculo #456 El Usuario #8923 est interesado en que le avisen cuando se haga un cambio en el Artculo #223 El Usuario #8923 est interesado en que le avisen si alguien publica una respuesta a la Pregunta #9213 Seremos cuidadosos al registrar la autora, porque todo contenido atribuido a su autor contribuye a mejorar nuestras posibilidades de construir una comunidad de verdad. Para ofrecer a los usuarios el servicio de notificaciones por email cuando alguien responde a una pregunta o comenta sobre un artculo, resulta necesario que registremos la autora. Deberamos registrar el hecho que un determinado usuario ha ledo, o al menos, se ha descargado determinado documento. Una vez que una comunidad de aprendizaje online registra los actos de lectura, resulta natural que consideremos el registro de si la lectura vali la pena. Relacin usuario/usuario A medida que las comunidades crecen, las relaciones entre los usuarios se vuelven cada vez
Pgina 19 de 30

ms importantes. Alguien que est en un foro de discusin con otras 100 personas puede decir: Me siento ofendido por la perspectiva del Usuario #45; quiero que el sistema evite mostrarme sus contribuciones cuando yo mire las pginas o en las alertas que se me enven por email. Una persona que est en medio de un foro de 100.000 puede querer indicarle al sistema: Estoy abrumado; no quiero volver a saber nada de este foro, a menos que el Usuario #67329 contribuya a un hilo de discusin. La operacin fundamental dentro de la base de usuario/usuario es la agrupacin. En un sistema de registros mdicos colaborativos, vas a necesitar poder decir: Todos estos usuarios trabajan en el mismo hospital y pueden tener acceso a los registros mdicos de los pacientes de ese hospital. En un sistema de conocimiento colaborativo de una corporacin, debes poder decir: Todos estos usuarios trabajan en el mismo departamento y por lo tanto deben tener acceso a los documentos privados del departamento, al foro de discusin dedicado a temas departamentales y debe recibir notificaciones por email de los eventos departamentales. Enviar SQL, no datos, al parser SQL de la base de datos En el captulo Elementos bsicos debes haber escrito scripts que tomaban la entrada del usuario combinada con unos fragmentos de SQL y luego enviaban el mandato en forma de cadena de caracteres hacia el sistema de gestin de base de datos relacional (RDBMS). A continuacin se muestra un ejemplo en C# robado de uno de nuestros estudiantes: string cmd = "Insert into quotations(author_name, category, quote) values (' " + txtAuthor.Text.Replace(" ' ", " ' ' ") + " ', ' " + ctg.Replace(" ' ", " ' ' ") + " ', '" + txtQuotation.Text.Replace(" ' ", " ' ' ") + " ')"; UpdateDB(cmd); // enviar esa enorme cadena al SQL Server Hay unas cuantas cosas menores que estn mal con este enfoque, que mezcla SQL y cadenas literales que se obtienen del usuario: el programador debe recordar que tiene que escapar cualquier carcter apstrofo (single quote) que vaya en cadena que va a enviar, reemplazando los ' con '' [stos son dos caracteres apstrofos y no una comilla doble] la sentencia puede quedar demasiado larga para algunos parsers de SQL y/o los literales de cadena pueden exceder ciertos lmites (Oracle 9.x impone un lmite de 4000 caracteres sobre los literales de cadena de caracteres) si el usuario est ***waxing expansive at the browser***

las repetidas invocaciones de este script van a resultar en que la base de datos recibe versiones de un mandato SQL que son morfolgicamente iguales pero difieren en el texto que se enva; dependiendo de cmo est implementado el RDBMS esto puede impedir que se reutilice el plan de la consulta. En un orden de cosas mucho ms serias, est la posibilidad de que a un usuario malicioso se le ocurra como conformar el formulario de tal manera que resulte en la destruccin de datos o la violacin de privacidad. Por ejemplo, considere el siguiente cdigo: string EventQuery = "select * from events where event_id = " + EventIDfromBrowser; Si se espera un ID de evento numrico y se sabe que los nmeros no necesitan encerrarse en apstrofos como sucede con los literales de cadenas de caracteres, el programador no realiza ningn procesamiento previo a EventIDfromBrowser, que es una variable leda desde la Internet. Supongamos que una persona de mente malvada enva un formulario que asigna a EventIDfromBrowser el valor "42; select * from user_passwords". El punto y coma cerca del principio de la cadena de caracteres tiene la posibilidad de terminar el primer SELECT y entonces puede ejecutar la consulta no autorizada select * from user_passwords. Si la consulta no autorizada est bien armada, la informacin resultante se presentar en el ventana del navegador. Otra construccin que mete miedo podra ser: "42; delete from customers".

Pgina 20 de 30

Puedes resolver todos estos problemas si separas el cdigo SQL y los datos variables. A continuacin se muestra un ejemplo en seudocdigo que muestra cmo se hace con las bibliotecas estndar desde finales de los 1970s: // Asocia el nombre "event_query" con una cadena de SQL PrepareStatement("event_query","select * from events where event_id = :event_id"); // Asocia la variable de ligadura :event_id con el valor particular para esta pgina BindVar("event_query",":event_id",3722); // Pide al RDBMS que ejecute la consulta completada ExecuteStatement("event_query"); ... obtener lo resultados... Note que la estructura del SQL que ve el RDBMS est fija como "select * from events where event_id = :event_id", sin importar cales sean los valores que se reciben como entrada por el formulario Web. Lo nico que cambia es el valor de: event_id. Este es un ejemplo de uso de variables de ligadura (binding variables), que es una prctica estndar en la mayora del software capaz de dialogar con una RDBMS. Saca de los scripts de pginas el nombre de usuario y la contrasea de la base de datos Supongamos que tienes el siguiente cdigo en los scripts de tus pginas: dbconn = OpenDBConn("sysid=local,username=joestest,password=joerocks"); Hay varios problemas con este enfoque cuando se usa para conectarnos a una RDBMS:

1. Una persona maliciosa que lee este cdigo fuente puede conectarse a la RDBMS que
corre en tu servidor y eliminar todas tus tablas. 2. Si se desea correr el cdigo contra una base de pruebas, la cual necesariamente va a tener diferente nombre de usuario en la base de datos, significa que debers editar cada uno de los scripts de pgina. 3. La reutilizacin de cdigo para otro proyecto requerir el cambio del nombre de usuario de la base de datos y la contrasea. Todo buen entorno de desarrollo Web dispone de un mecanismo de recursos comunes (pool) de conexin a la base de datos desde los scripts de las pginas, de tal manera que el servidor Web no necesita reconectarse y reautenticarse frente a la base de datos millones de veces por da. Generalmente, la idea es que el servidor Web va a abrir un puado de conexiones al RDBMS y las va a mantener abiertas. Cuando el script de una pgina necesita realizar una consulta, obtiene una de las conexiones del pool y la usa hasta que se completa el servicio de la pgina. Luego se retorna la conexin al pool. Este esquema se denomina connection pooling. La utilizacin del sistema de connection pooling a la base de datos que provee el servidor Web con frecuencia resulta en una buena manera de sacar el nombre de usuario y la contrasea de la base de datos.

Pgina 21 de 30

Captulo 5 Registro y gestin de usuarios Fat vs Skinny Suponte que, inicialmente, los requerimientos de datos para un usuario pueden ser satisfechos con una nica tabla de base de datos. Luego de unas semanas, alguien dice no sera interesante tener una imagen y una url por cada usuario? Entonces, se modifica la tabla original agregando los campos correspondientes, y asignando el valor Null a los campos que corresponda. Unos meses ms tarde, los datos siguen agregndose, y la tabla sigue creciendo y creciendo. Este tipo de modelo se conoce como fat data model, ya que los datos de una entidad se almacenan todos en una nica tabla gigante. Un enfoque diferente es el skinny data model. En este modelo, los datos elementales de los usuarios se almacenarn en una tabla que contendr slo los datos elementales, es decir, una skin table. Luego se crea una segunda tabla donde se almacenar toda la informacin extra, por ejemplo: user_id 1 2 1 2 3 4 auto_id 1 1 1 2 user_id username guerenge vortolpio field_name char telephone 13246512 url http://df... Birthdate birthdate password ******** ******** int Email guerengue@... vortolpio@... float date 02/10/1985 05/06/1967

Un argumento a favor del fat model es la facilidad de mantenimiento y la documentacin (hay una nica tabla). Adems, el fat model es el estndar en SQL, es decir, un programador SQL que vaya a continuar o mantener tu trabajo, esperar encontrarse con un fat model. No se debe decidir entre skinny model y fat model basada en la eficiencia de almacenamiento de datos presunta. Skinny model es bueno cuando est almacenando datos salvajemente dispares de cada usuario, que se espera que ms de un 75 por ciento de las columnas ser NULL en un modelo de datos de tipo fat. Skinny puede resultar en un aspecto extrao de las consultas SQL y en una opacidad del diccionario de datos Grupos de Usuarios En las comunidades, los grupos son casi la construccin ms poderosa. Un grupo de usuarios podra querer colaborar con cierto contenido, o podra querer tener su propio foro de discusin, o podra ser el nico en acceder a ciertos archivos. Un tpico modelo de datos incluir una tabla de Usuarios y otra de Grupos. Esto llevar indefectiblemente a que muchas tablas del sistema debern incluir dos columnas: user_id y group_id. Si user_id no es Null, entonces el registro pertenece a un usuario. Si group_id no es Null, entonces el registro pertenece a un grupo. Luego, la pertenencia de un usuario a uno o ms grupos estar especificada en una tercer tabla (usuarios, grupos, usuarios_grupos), donde exista un registro por cada grupo al que un usuario determinado pertenezca (el campo clave de esta tercer tabla que relaciona usuarios y grupos est formado por la clave compuesta user_id y group_id). Las consultas relativas a la pertenencia de usuarios a grupos se realizarn uniendo las tres tablas en cuestin. Algunos podran pensar que esto es desagradable, ya que en cada consulta debern accederse a tres tablas. Esto puede simplificarse muy fcilmente, creando una vista, y realizando luego las consultas sobre dicha vista. Limpiar feas consultas con vistas. Limpiar los problemas de rendimiento con ndices Primer forma normal
Pgina 22 de 30

Una tabla est en Primera Forma Normal si: Todos los atributos son atmicos. Un atributo es atmico si los elementos del dominio son indivisibles, mnimos. La tabla contiene una clave primaria nica. La clave primaria no contiene atributos nulos. No debe de existir variacin en el nmero de columnas. Los Campos no clave deben identificarse por la clave (Dependencia Funcional) Debe Existir una independencia del orden tanto de las filas como de las columnas, es decir, si los datos cambian de orden no deben cambiar sus significados Una tabla no puede tener mltiples valores en cada columna. Los datos son atmicos. (A cada valor de X le pertenece un valor de Y y viceversa). Esta forma normal elimina los valores repetidos dentro de una BD Una buena regla general es que para representar una relacin de uno a muchas se requiere de dos tablas: table_A y table_B, en B muchos registros pueden estar asociados con un nico registro de A. Otra regla general es que para representar una relacin de muchos a muchos se requiere de tres tablas: table_A, table_B, y una tercer tabla (table_A_B) para asociar un nmero arbitrario de registros de A con un nmero arbitrario de registros de B. Ejemplo: tabla_usuarios (key: id_usuario) tabla_grupos(key: id_grupo) | | | tabla_usuarios_grupos (key: id_usuario, id_grupo) | Un usuario puede pertenecer a ms de un grupo y un grupo puede albergar a ms de un usuario Control de acceso y aprobacin Usted desea limitar el acceso slo a aquellos solicitantes de registro que haya verificado la recepcin de un mensaje de correo electrnico a la direccin que se suministra al registrarse. Tambin puede rechazar el registro de los usuarios cuya nica direccin de correo electrnico est en hotmail.com o un proveedor de annimos similares. Una comunidad puede tener que cambiar sus polticas cuando el nmero de miembros aumenta. Una forma poderosa para administrar el acceso del usuario es el registro de usuarios modelado como una mquina de estados finitos-, como la que se muestra en la siguiente figura: No es usuario | | Rechazada (a travs de Necesidad de Verificacin de Email cualquier estado previo a Necesidad de aprobacin del administrador la autorizacin) | | Necesita la aprobacin<--------- -------------> Necesita verificacin de del administrador correo electrnico | | | | ----------------------> Autorizado <--------------------| | Prohibido ------- ><-------- ------><------------ Eliminado Un enfoque de Autmata finito para registro de usuario. Un lector se inicia en el estado "No es usuario". Despus de rellenar un formulario de inscripcin, progresa a la "necesita de verificacin de Email / necesita de aprobacin de la administracin". Despus de responder a un mensaje de correo electrnico desde el servidor se traslad en el estado de "Necesita aprobacin de la administracin". Supongamos que en este sitio que tenemos una regla que cualquier persona cuyo correo electrnico termina en "mit.edu" es automticamente aprobado. En ese caso, el lector se mueve al estado "Autorizado", que es donde l se mantendr a menos
Pgina 23 de 30

que l decide dejar el servicio ("eliminado") o que se considera una carga excesiva para moderadores ("prohibido"). Una poderosa manera de manejar el acceso de usuarios es modelando la registracin de usuarios como una mquina de estados finitos. En lugar de verificar las columnas admin_approved_p, email_verified_p, banned_p, deleted_p en la tabla users cada vez que se carga la pagina, este enfoque permite que la aplicacin examine una sola columna de user_state. Flujo de Pginas El primer principio general del diseo multi-pgina es que el usuario debe poder ir hacia delante y hacia atrs en cualquier momento de su sesin. El segundo principio general del diseo es que el usuario debe seleccionar primero el objeto, y luego el verbo. Por ejemplo, en un sitio de mercado, un usuario primero selecciona uno o varios tems, y luego elige qu hacer con ellos (comparar precios, comprar, etc.). En el diagrama de flujo de pginas debe haber un recuadro o crculo por cada URL en el sistema y un arco o flecha por cada transicin posible de una URL A hasta una URL B. Si tienes muchas URLs que son destinos de formularios y realizan actualizaciones de base de datos, pero redirigen a otras pginas para mostrar la informacin, te conviene distinguir esas URLs con un borde fino adicional o un borde de trazos.

El flujo de documentacin de la pgina de un servicio de recordatorio de cumpleaos independiente. Recordatorios de correo electrnico se envan ya sea el mismo da, el da anterior, o una semana antes de la fecha de cada ao GET vs POST En la programacin de una pgina con un formulario HTML, el programador tiene la decisin de utilizar method=POST o method=GET. Un GET implica que se est obteniendo informacin, por lo cual se puede ejecutar un sinnmero de veces, ya que se est pidiendo informacin, y no se est realizando ninguna accin en el back-end. En cambio un POST implica que se estn realizando cambios (alguna accin con efectos
Pgina 24 de 30

secundarios): insertar un registro, actualizarlo, borrarlo, etc. Es por eso que, al intentar recargar una pgina (en el navegador) que utiliza un POST, el navegador solicita una confirmacin de reenvo de datos. Una gran confianza en POST resultara en un sitio que rompa el botn atrs del navegador. Volver atrs a una pgina que resulto de un POST genera el error de page expired y una ventana preguntndole al usuario si quiere refrescar la informacin. Lo ideal al utilizar un POST es ejecutar el script correspondiente que actualice/inserte los datos, y luego redirigir a otra pgina (tipo actualizacin correcta o algo similar). De este modo, si el usuario recarga la pgina, no estar reenviando el POST. En general, deberas respetar los principios anteriores. Ejemplos: Buscar usuarios y contenido debera ser GET. Insertar un usuario o modificar un perfil debera ser POST. Por supuesto que HTML y HTTP tienen restricciones que complican las cosas: Los formularios GET estn limitados en longitud segn la longitud de las URL que mande el navegador. Los formularios POST solo se pueden aplicar teniendo un botn HTML o usando JavaScript, lo que no es ideal. Lo que se puede hacer para evitar problemas es lo siguiente: Cuando se usa un POST o un GET redireccionar inmediatamente a otra pagina para evitar el dao colateral, sobretodo usando POST. De esta manera cuando se utiliza uno de los dos se redirecciona a otra pgina que muestre los resultados pero que no dae los datos en caso de que el usuario quiera volver atrs o actualizar. Cuando se utiliza un vnculo GET para realmente realizar una accin con efectos secundarios, tambin puede tener ese destino de una secuencia de comandos realiza su accin, luego inmediatamente redirigir a una secuencia de comandos sin efectos secundarios. Esto evitar la repeticin accidental de una accin.

Pgina 25 de 30

Captulo 6 Gestin de contenido Existen dos elementos principales para la gestin de contenido: almacenar cosas en un repositorio de contenido; dar soporte al flujo de trabajo de personas interesadas en contribuir con contenido. Una parte importante de la gestin de contenido es reducir el nmero de tipos de contenido. Por ejemplo, considera una comunidad donde se desean tener artculos, comentarios sobre artculos, noticias, comentarios en noticias, preguntas y respuestas. En principio, se nos podra ocurrir guardar este contenido en 6 tablas dentro de una base de datos. Pero es necesario considerar que cada tabla en la base de datos implica alrededor de 20 scripts: 10 para la experiencia del usuario y 10 para la experiencia del administrador. Esto puede ser una gran desventaja, sobre todo considerando que cada tipo de contenido no es muy distinto de los dems, lo cual llevara a tener un montn de scripts similares, donde slo cambia el nombre de la tabla. Es posible combinar los tipos de contenido en una nica tabla (llamada contenido o algo similar) y especificando en algn campo de cada registro qu tipo de contenido es. Incluso los comentarios pueden almacenarse en esa misma tabla, indicando que es contenido del tipo comentario. Adems, ser necesario especificar un campo que relacione un registro de la tabla con otro registro de la misma tabla (esto es, para los comentarios sobre artculos o sobre noticias). Es obvio que existirn algunos campos que sern Null para cierto tipo de contenido (por ejemplo, es necesario incluir un campo de fecha que indique cundo expira una noticia, pero cualquier registro que sea un comentario tendr dicho campo en Null). Asimismo las ventajas siguen siendo mayores en cantidad. Teniendo todo el contenido en un nico repositorio, podra pensarse que las tareas de consultas sern difciles y complejas. Esto es totalmente lo contrario: pueden crearse vistas sobre el repositorio de contenido, y luego utilizar las vistas para realizar las consultas. Ejemplo de articulos, comentarios y noticias juntos: create table content_raw ( content_id integer primary key, content_type varchar(100) not null, refers_to references content, creation_user not null references users, creation_date not null date, release_time date, expiration_time date, language char(2) references language_codes, mime_type varchar(100) not null, one_line_summary varchar(200) not null, body clob, editorial_status varchar(30) check (editorial_status in ('submitted','rejected','approved','expired')) ); Si cambia de opinin acerca de cmo representar el estado de algn contenido, no ser necesario poner al da decenas de secuencias de comandos Web; slo es necesario cambiar la definicin de la vista que consulta el estado de ese contenido: create view articles_approved create view articles_approved as as select * select * from articles_raw from articles_raw where editorial_status = 'approved'; where editorial_status = 'ok'; El conocimiento como un activo abierto a la discusin y al aporte individual. El conocimiento es de composicin abierta. Las personas puede tener opiniones diferentes sin que una de ellas este equivocada. No existe necesariamente una verdad, puede haber muchas verdades. Internet y los ordenadores, utilizados de forma competente y creativa, hacen que sea mucho
Pgina 26 de 30

ms fcil y ms barato recoger y presentar mltiples verdades que en el viejo mundo de la impresin, el telfono y el correo postal. Varios sitios web de mltiples verdades son mucho ms interesante que sitios web de una sola verdad y, por unidad de esfuerzo y dinero invertido, mucho ms eficaces en la educacin de los usuarios. Por qu no usar el sistema de archivos? Hasta aqu, no nos hemos hecho la pregunta. Por qu no almacenar el contenido en archivos .HTML estticos? Una ventaja acerca del sistema de archivos es que hay una amplia variedad de herramientas para usuarios con diferentes niveles de conocimiento para modificar, insertar o eliminar informacin. Una cosa mala de darle permisos a cualquiera sobre el sistema de archivos es el potencial caos que provocara. Un diseador que supone subir un template pero en lugar de eso elimina un archivo, es un desastre. El problema ms profundo de usar el sistema de archivos como piedra angular de la gestin de contenido es que los archivos estn fuera de la base de datos. Es muy difcil mantener la consistencia de cosas referidas fuera del RDBMS. Supongamos que tus tablas del RDBMS estn referidas al sistema de archivos por nombre de archivo. Alguien renombra un archivo. La base de datos no lo sabe. El mecanismo de integridad de la base de datos no se puede invocar para protegerse de esas circunstancias. Es ms fcil mantener un juego de estructuras de datos consistentes si estn dentro de la base de datos. El problema del flujo de trabajo En el ambiente del desarrollo web es comn que el trabajo se divida en publicadores, diseadores de informacin, diseadores grficos, autores y programadores, que el sitio contenga miles de pginas, y que el control de versiones sea algo crtico. As, aparece la cuestin del flujo de trabajo del contenido. El flujo de trabajo de cada tipo de contenido puede pensarse como una mquina de estados finitos, en la cual un tem de contenido puede estar en un nico estado en un instante dado. De este modo, el software escrito sobre dicho flujo puede tomar acciones sin necesidad de saber cules fueron los estados por los que pas el tem. Para cada paso del flujo de trabajo debe especificarse quin tiene que dar la aprobacin (si fuera necesaria), cules emails de alerta se deben generar (si hubiese que generar alguno), qu sucede si se da la aprobacin y qu sucede si se deniega la aprobacin. Como se plantea el flujo de trabajo: Es fcil de construir y mantener una Web si: Una persona es publicador, autor y programador al mismo tiempo. El sitio comprende solo unas pocas pginas. A nadie le importa si estas pginas tienen formato consistente. A nadie le importa recuperar viejas versiones o como la versin actual fue evolucionando. Lo que es ms tpico es lo siguiente: El trabajo es dividido entre publicadores, diseadores de informacin, diseadores grficos, autores y programadores. El sitio contiene miles de pginas. Las pginas deben ser consistentes entre secciones y las secciones tienen un tema definido. El control de versiones es crtico. Control de versiones del contenido Cualquier individuo involucrado en la creacin y edicin de contenido en una comunidad, debe tener la opcin de volver un artculo a una versin anterior, incluso a su primera versin. El control de versiones es un punto crtico al intentar prevenir las actualizaciones perdidas, esto es, cuando varias personas trabajan sobre el mismo artculo. Hay dos modos de implementar el control de versiones del contenido. El primero es implementar dos tablas distintas, y cada vez que se realiza una
Pgina 27 de 30

actualizacin a un registro de una tabla, el registro viejo es escrito en la segunda tabla, con una marca de tiempo. El segundo es implementar las versiones en la misma tabla. Esta tcnica es ms costosa en trminos de recursos computacionales, ya que la informacin vieja est mezclada con la nueva, y las consultas ms comunes involucrarn mayores lecturas a disco. En este esquema, sera necesario redefinir la clave primaria, agregando a ella el nmero de versin del artculo. El problema de este enfoque es que, por ejemplo para un artculo determinado, tendremos varios registros con muchos campos de igual valor (esto es, aquellos campos que no cambian, como el autor, la referencia, la fecha de creacin, etc.). En este caso, el esquema debe llevarse a una segunda forma normal, creando una tabla cuya clave sea el id del contenido (esta tabla contendr los datos que no cambiarn) y una segunda tabla cuya clave sea el id (del contenido) y el nmero de versin (esta tabla contendr los campos que s cambian). Es ms caro en trminos de recursos requeridos computacionalmente. Pero es ms fcil si quieres que el programa tenga la capacidad de mostrar el sitio en un da en particular. Segunda forma normal Para algunos propsitos agregamos una columna versin_number para mantener el nmero de versin. Recuperar informacin para una versin especfica es fcil. Recuperar informacin de varias versiones es tan fcil como hacer un GROUP BY. select content_id, max(zip_code) from content_raw where content_id = 5657 group by content_id Cuando necesitamos almacenar informacin sobre 2 diferentes tipos de cosas, tiene sentido crear 2 tablas diferentes. Tercera formal normal No tendra ms sentido computar y marcar la versin ms nueva aprobada en el momento en que se inserta o modifica? Para esto se agrega una columna mas current_version_p para almacenar si es o no la ltima versin. Las nuevas RDBMS ofrecen una caracterstica mediante la cual una fila en una tabla puede esparcirse en diferentes espacios de tablas, cada uno ubicado en un espacio de disco diferente. Todas las filas para la versin actual del sitio se mantendrn juntas en un bloque compacto. No afectara la performance o el uso de RAM consumida por el bloque en el disco. La base de datos en teora notara que nuestro modelo de datos esta en segunda forma normal pero no en tercera forma normal. En una tabla que es parte de un modelo de datos en tercera forma normal todas las columnas dependen directamente de la clave principal. La columna current_version_p no depende de la clave. Esto se denomina desnormalizacin. Los modelos de datos mas mantenibles resultan ser en tercera forma normal y agregar una til, modesta y cuidadosa desnormalizacin que sea justificada y documentada. Control de versiones del programa Los programas residen, generalmente, en el sistema de archivos, y son escritos por profesionales del desarrollo de software. En el desarrollo de software, los objetivos y las especificaciones de un proyecto cambian, por lo cual es necesario un control de versiones. Un proyecto que involucra objetivos, cambio de especificaciones y mltiples contribuyentes necesita control de versiones. Solucin clsica: cada programador trabaja en su propio directorio, sobre una seccin especfica del programa a construir: anteriormente, el control de versiones usado por los desarrolladores de C era tener el trabajo en su propio directorio. Esto tena sentido porque no existe la persistencia en el mundo de C. Una objecin a este mtodo de desarrollo en el mundo del desarrollo Web es que se vuelve tedioso hacer un cambio pequeo.
Pgina 28 de 30

Una objecin ms profunda sobre aplicar este mtodo es el obstculo de la colaboracin. Esos colaboradores necesitan saber dnde encontrar la ltima versin del software corriendo para que puedan ofrecer crticas y consejos. La solucin de nuestros tiempos: 1. Tres servidores de HTTP: un servidor de produccin, otro de staging y un ltimo de desarrollo. Este enfoque utiliza tres servidores (que pueden ser la misma mquina fsica): Servidor de desarrollo: es donde se crea la pgina web, no tiene por qu estar conectado a Internet, y es donde se colocan los archivos segn son programados. Es donde se crean los scripts y las pginas que contendr el sitio. Servidor de staging: es donde se ensambla, prueba y revisa la versin ms reciente de la aplicacin antes de lanzarla de forma definitiva a Internet. Generalmente las pruebas se realizan usando los datos de forma online. Servidor de produccin: est conectado a Internet y es donde la aplicacin web est en marcha. Es donde acceden los distintos visitantes desde sus ordenadores en cualquier parte del mundo para obtener el servicio. De este modo los desarrolladores no deben esperar a que finalice el testeo para continuar desarrollando, ni los testers debern esperar a que los desarrolladores terminen su trabajo: cada nueva versin puede probarse mientras los desarrolladores siguen trabajando. Cuando los desarrolladores y testers estn de acuerdo con el rendimiento del sitio en el servidor de staging, lo liberan y se coloca en produccin. Las correcciones hechas por el equipo de staging del cdigo que no se han solucionado por el equipo de desarrollo son incluidas en el rea de desarrollo en el repositorio de control de versin. 2. Dos o tres RDBMS y espacios de tablas: tratar de que haya un RDBMS por servidor. La idea bsica es tener dos bases de datos, una para el servidor de produccin y otro para el servidor de desarrollo, para prevenir descuidos durante el desarrollo que resulten en el borrado accidental de tablas o que consultas incompletas o mal diseadas ralenticen el sitio en produccin. Una vez que el desarrollo est probado y listo para lanzarse a la web, se aplican las modificaciones en la base de datos de produccin. Debe haber tres bases de datos, es decir, una para el desarrollo, una para el staging, y una para la produccin? No necesariamente. A menos que uno espera una evolucin radical de modelo de datos, puede ser aceptable el uso de la misma base de datos para el desarrollo y el staging 3. Un repositorio de control de versiones: la funcin del repositorio de control de versiones es: Recordar cules son todas las versiones anteriores chequeadas de un archivo contenido. Demostrar las diferencias entre las versiones no chequeadas y las del repositorio. Ayudar a combinar los cambios hechos por diferentes autores que pudieran no estar consientes del trabajo de los dems. Vistas rpidas de las versiones chequeadas. Existen varias herramientas que permiten configurar un repositorio comn de cdigo, ejemplos son el Concurrent Versions System (CVS) y el Subversion(SVN). Lo bueno de esta solucin: Si pasa algo con el servidor de produccin uno puede volver a una versin anterior probada y conocida. Programadores pueden proteger y comentar los cambios que se hicieron de los archivos. Equipos de programadores y equipos de pruebas pueden trabajar simultneamente.
Pgina 29 de 30

Look and Feel (el aspecto) Espacio en la pantalla La capacidad de clculo de las computadoras ha aumentado exponencialmente a lo largo de la historia, pero los resultados que generan se siguen mostrando en pantallas de 19 pulgadas. En el desarrollo de un sitio web, debes asegurarte de que no sea necesario hacer scroll para acceder al contenido primario, que no haya grandes espacios en blanco sin utilizar (a veces la utilizacin de tablas cumple este objetivo). Usualmente, el mayor desperdicio de espacio de pantalla se da con la utilizacin de conos. Comnmente, ningn usuario entiende el significado de un icono por s mismo, por lo cual los conos deben estar acompaados de un texto descriptivo. Entonces, la mejor poltica para el uso de pantalla es dejar que la informacin sea la interfaz. Tiempo La mayora de la gente prefiere rpido antes que lento. Existen experimentos que indican que una persona puede retener alrededor de 7 cosas en su mente, en forma temporal, por un perodo no mayor a 20 segundos. En un sitio web es imprescindible que un usuario no necesite tener en su mente ms de 5 o 6 cosas o variables. Otra cuestin importante es el tiempo de respuesta entre carga y carga de pgina. En este punto, es preferible un sistema de tiempo constante de respuesta, es decir, se prefiere que cada carga de pgina tarde 5 segundos, antes que tarde 1 segundo a veces y 20 segundos otras veces. Palabras Como programador te encontrars colocando dos tipos de texto: mensajes de error e instrucciones: Instrucciones: puedes escoger voz activa o pasiva y primera, segunda, o tercera persona. Las instrucciones deberan ser en segunda persona imperativa. Ejemplo: Ingrese fecha de salida. Mensajes de error: tendrs que elegir entre un mensaje enrgico o relajado. El primero ser un sistema que tratara de autocorregir la entrada del usuario o por lo menos deducir que est mal. El segundo tipo responder solamente error de sintaxis ante cualquier error. Por ejemplo, ante el ingreso de una fecha que el usuario debe efectuar, es vlido colocar un texto instructivo que indique el formato con el que debe ingresarse la fecha, o bien incluir algn tipo de calendario JavaScript que facilite la tarea. En todo caso, el usuario debe ser guiado hacia un ingreso de datos correcto. El sistema NUNCA debera dar una respuesta como Hay un error. Color El texto es ms legible cuando hay texto en negro (con la excepcin de enlaces, enlaces visitados, etc.) contra un fondo blanco(o en su defecto, de tonos claros). Si te limitas a esto el navegador te tratara bien. Se un poco cuidadoso con los grises en el tope de la pagina. Muchos navegadores usan varios tonos de grises para el fondo del men y la barra de botones en la parte superior de la ventana. La base en cuanto a colores es la siguiente: 1. Usa colores con moderacin. 2. Asegrate que una persona daltnica pueda hacer uso de la aplicacin. 3. Evita el rojo por su asociacin con alertas y peligros. Navegacin En cuanto al diseo de la pgina principal, es comn incluir los siguientes elementos: un directorio de navegacin al resto del sitio noticias y eventos un cuadro de texto para realizar bsquedas un acceso rpido a los servicios o elementos ms solicitados.
Pgina 30 de 30

Al estar visualizando una pgina, debes poder responder las siguientes preguntas: Dnde estoy?, puedes incluir un logo o algo que contenga el nombre del sitio en la esquina superior izquierda de cada pgina. Muchos sitios incluyen un map site, o mapa del sitio, que indica la ubicacin exacta dentro del sitio. Dnde he estado?, se debe dejar los links de los colores originales del navegador para que el usuario vea los de distinto color y sepa donde fue y donde no. Si eres cuidadoso en la programacin de las distintas pginas, el usuario podr hacer clic derecho al botn Back del navegador, y elegir alguna de las pginas donde ha estado. Dnde puedo ir?, obviamente, necesitas links. Estos links podrn ser estticos, pero a veces es conveniente que guarden alguna relacin con el contenido visualizado actualmente. Arquitectura de la informacin: Implcito o explcito? La arquitectura de la informacin es la manera de organizar, presentar y etiquetar todos los tems de contenido del sitio. Algunas de las formas ms comunes son: ordenar del ms reciente al menos reciente (buen mtodo para la experiencia del usuario); ordenar del de mayor calidad al de menor calidad (podra ser de utilidad para los usuarios que ingresan por primera vez); categorizacin de elementos. La arquitectura de la informacin tiene un fuerte impacto en si los usuarios pueden decir He contestado mi pregunta o no. Hay estudios que demuestran que un usuario comn tiene menos del 50% de probabilidad de encontrar respuesta a una pregunta que, de hecho, puede responderse con la documentacin del sitio. Una implementacin muy interesante es almacenar la arquitectura de la informacin en una base de datos, esto es, el esqueleto de las pginas del sitio, almacenado en tablas de datos. De este modo, los cambios a la arquitectura slo implicaran cambiar algunos registros de la base de datos. Las decisiones de la arquitectura de la informacin tienen un gran efecto en el porcentaje de usuarios que consiguen contestar su respuesta. Una razn de que la arquitectura de la informacin en un sitio tpico es daina para el usuario es que la arquitectura est implcita en scripts y en paginas HTML. Para testear una alternativa, implicara un alto costo de mano de obra en programas informticos y marcado HTML. Qu tal si representamos la arquitectura de la informacin de manera explcita en tablas de la base de datos? Estas tablas mantendran la siguiente informacin: Informacin acerca de la arquitectura de informacin: quien la hizo, cuando, cuales son actuales y para quienes. Si los tems dentro de una categora o subcategoria, dentro de una arquitectura de la informacin dada, deberan ser presentados en lnea en una pgina o resumirlos con links abajo a pginas separadas por cada tem. Donde encaja un tem de contenido en la arquitectura de la informacin dada: que subcategoria, que orden de presentacin comparada con otros tems en el mismo nivel. Como debera describirse un tem de contenido o categora.

Pgina 31 de 30

Captulo 7 Modularidad del Software Cmo agrupar el cdigo Cada mdulo del sistema tendr las siguientes clases de software: definicin de tablas de base de datos; procedimientos de almacenado que corren en la base de datos; procedimientos que corren dentro del servidor Web o el programa servidor de aplicaciones y que estn compartidos por ms de una pgina Web (los denominaremos procedimientos compartidos) scripts que generan las pginas individuales; templates (plantillas) que trabajan en conjunto con los scripts de pgina; documentacin que explica los objetivos del mdulo. Una comunidad de usuarios podra tener los siguientes mdulos: registro de usuarios, artculos y comentarios, foros de discusin, Chat, adserver para el uso de banners de publicidad, calendario, anuncios clasificados y subastas, comercio electrnico, email para los miembros de la comunidad, encuestas, blogs privados para los miembros. El software detrs de un servicio de Internet se actualiza con frecuencia a medida que la comunidad crece y se desarrollan nuevas ideas. El software que es actualizado frecuentemente va a tener defectos, lo que significa la necesidad de depuracin. Por ello es importante publicar ciertas convenciones que faciliten al nuevo programador la tarea de encontrar el cdigo relevante. Puede tomar slo quince minutos encontrar y arreglar un problema en el sistema. Pero si toma tres horas encontrar los archivos que hay que revisar, entonces arreglar un defecto insignificante se transforma en un proyecto de medio da. La documentacin del sitio es el punto de partida para los programadores que estn considerando usar el mdulo o extender sus caractersticas. El documento tiene la siguiente estructura: 1. Dnde se encuentra todo el software asociado con este mdulo (las convenciones vlidas en todo el sitio son buenas, pero no hace dao ser explcitos). 2. Informacin a vuelo de pjaro: Por qu se escribi este mdulo? Porqu las alternativas existentes no eran adecuadas para resolver el problema? Cules son las caractersticas de alto nivel, tanto buenas como malas, de este mdulo? Cules fueron las elecciones que se hicieron al desarrollar el modelo de datos? 3. Informacin de configuracin: Qu se puede cambiar de manera sencilla mediante la edicin de los parmetros? 4. Informacin de uso y mantenimiento. Procedimientos compartidos Vs Procedimientos almacenados Los gestores de base de datos modernos pueden interpretar lenguajes Turing completos. Por lo tanto, en principio, se puede realizar cualquier tipo de clculo dentro de una base de datos utilizando procedimientos almacenados. Asimismo, existen ciertas ventajas de performance si separamos la capa de presentacin de la capa de datos; esto nos da la oportunidad de escribir software adicional en forma de procedimientos compartidos. Cmo elegir entre ambos? Piensa en las mltiples aplicaciones que pueden conectarse a la misma base de datos (por ejemplo, un servidor web pblico, un programa que todas las noches extrae informacin para analizar, una herramienta de mantenimiento para administradores, etc.). Si piensas que una parte del cdigo fuente va a resultar til para aquellos otros sistemas que se conectan a la misma base de datos gurdalo all en forma de procedimiento almacenado. Si una parte de cdigo slo ser utilizada por una aplicacin web en particular, entonces gurdala en el servidor como procedimiento compartido. Documentacin Durante aos se ha mantenido la idea de que por cada procedimiento debe escribirse un documento de texto que indique sus entradas, salidas, y su resultado (para cada
Pgina 32 de 30

procedimiento que indique cules entradas acepta, cules salidas genera, y cmo transforma esas entradas en salidas.). Pero, qu tan tiles son estos documentos? Un programador nuevo del sistema no tiene idea de cules de todos los documentos son los ms relevantes, no sabe por qu se construyeron los procedimientos o qu problema resuelven. En cambio, es mucho ms eficiente construir un texto en prosa de algunas pginas que explique la forma de pensar utilizada y el diseo de trabajo aplicado al problema real. Cmo separar a los programadores de los diseadores? La cantidad de crticas y de solicitudes de cambios vendr en proporcin a la cantidad de gente que puede comprender la parte del sistema que est siendo objeto de la crtica. Muy pocas personas son capaces de realizar un modelado de datos o un diseo de interaccin. An cuando stas son las partes del sistema que ms profundamente afectan la experiencia de usuario o la utilidad de un sistema de informacin para sus operadores, raramente te van a ocupar con sugerencias en estas reas. Slo una persona con aos de experiencia relevante puede llegar a proponer que agregues una columna a una tabla, o que cinco tablas se reemplacen con tres tablas. Una cantidad mucho mayor de personas puede escribir scripts Web. Es posible entonces que algunas veces te ridiculicen por la eleccin del entorno de programacin, al margen de qu tan moderno se supone que era al momento que lo elegiste. Prcticamente todo ser humano en el planeta, por otro lado, entiende que el malva se ve diferente que el fucsia, y que Helvtica es diferente de Times Roman. Por ello, la mayor cantidad de sugerencias de cambios en una aplicacin Web van a estar relacionados con el diseo. Uno quiere agregar un nuevo logo a cada pgina del sitio. Otro quiere cambiar el color de fondo en la seccin del foro de discusin. Otro ms quiere agregar un poco de espacio en blanco por aqu y por all. Supongamos que elegiste la manera ms simple y directa para construir tu aplicacin Web. A cada URL corresponde un script, que contiene las sentencias SQL, algo de cdigo procedural en el lenguaje de scripting (sentencias IF, bsicamente), y cadenas estticas de HTML que se van a combinar con los valores que se extraigan de la base de datos para formar la pgina completa. Las partes que componen un programa en Visual Basic Active Server Pages o uno en Java Server Pages o un script CGI en Perl, siempre vas a encontrar esos tres elementos: SQL, sentencias IF, HTML. The Small Hammer Esta es la manera ms simple, y consiste en crear dos archivos por cada URL (en el mismo directorio). El primer archivo contiene cdigo SQL y algo de cdigo que toma datos de la base de datos y arma alguna variable o estructura. El segundo archivo es un simple template que luce como un HTML estndar, y trabaja con los datos y estructuras del primer archivo. La manera ms simple de separar a los programadores de los diseadores consiste en crear dos archivos para cada URL. El Archivo 1 contiene las sentencias SQL y algo de cdigo procedural que rellena las variables locales o una estructura de datos con la informacin que se extrajo de la base de datos. La ltima sentencia en el Archivo 1 es una llamada a un procedimiento que lee el Archivo 2, un archivo plantilla que se ve como HTML estndar con referencias sencillas a los datos preparados en el Archivo 1. The Mdium Hammer El problema del diseo anterior es que ambos archivos residen en el mismo directorio, y podra suceder que un diseador renombrara o eliminara algn archivo de script. Tendra ms sentido separar los archivos en dos directorios, y dar permisos a los diseadores slo sobre el directorio correspondiente. El enfoque del "martillo mediano" mantiene programadores y diseadores completamente separados desde el punto de vista de los permisos del sistema de archivos. The SQL Hammer Si el sistema ya incluye muchas capacidades apoyadas en la RDBMS para permitir el control de versiones y las autorizaciones, puede resultar natural que almacenemos las plantillas en una tabla de la base de datos. Estas plantillas se pueden editar desde un navegador, y los cambios en las mismas se pueden gestionar como parte del flujo de trabajo de publicacin del sitio Este enfoque es til cuando la arquitectura de la informacin es almacenada en la base de
Pgina 33 de 30

datos. Aqu, los templates, tambin se almacenan en la base de datos. The Sledge Hammer (El martillo de demolicin) Este enfoque es muy utilizado, y consiste en utilizar un template maestro para todas las pginas. De este modo, cada template en particular se encarga slo de construir una porcin de la pgina final. Dicha porcin ser incrustada en el template maestro. Este enfoque permite realizar cambios a la estructura de todas las pginas de forma rpida y sencilla. (se utilizan bloques en HTML{% BLOCK <NAME-BLOCK> %} {% END BLOCK} %) APIs Intermdulo En el captulo Registracin y gestin de usuarios mencionamos que queremos lograr que las personas sean responsabilizadas por sus acciones dentro de la comunidad online. Una manera para mejorar la responsabilidad pasa por ofrecer una pgina de contribuciones de usuario en la cual se muestran todas las contribuciones de un usuario particular. En cualquier lugar de la aplicacin donde aparezca el nombre de una persona, se lo transformar en un hiperenlace a su pgina de contribuciones de usuario. Como todo el contenido del sitio se almacena en tablas de la base de datos relacional, la manera ms obvia de empezar a escribir el script para la pgina de contribuciones de usuario es mirar los modelos de datos SQL de cada mdulo individual. Luego podemos escribir un programa que haga consultas en unas docenas de tablas para encontrar todas las contribuciones de un usuario en particular. La desventaja de este enfoque es que ahora nos hemos quedado con cdigo que puede dejar de funcionar si cambiamos el modelo de datos de un mdulo, y se trata de cdigo que no est ubicado en el subdirectorio correspondiente al mdulo; adems es probable que el autor de este cdigo sea diferente del programador que mantiene el mdulo individual. Vamos a considerar una aplicacin diferente: alertas por email. Supongamos que tu comunidad ofrece un foro de discusin y un sistema de avisos clasificados, codificados como mdulos separados. Algunos usuarios quieren recibir resmenes diarios de las actividades en ambas reas. Cada mdulo podra tener su propio mecanismo de alertas. Sin embargo, esto quiere decir que el usuario recibir dos mensajes cada noche cuando lo que esperaba es un nico mensaje combinado. Si construimos un sistema de alertas por email, por otro lado, tenemos el mismo problema que con la pgina de contribuciones de usuario: cdigo compartido que depende de los modelos de datos de los mdulos individuales. Por ltimo, demos un vistazo a la tarea del administrador del sitio. El administrador del sitio ser con toda probabilidad un voluntario ocupado. No desea perder veinte clics de ratn para revisar el contenido nuevo de hoy. El administrador del sitio debe ser capaz de revisar el contenido contribuido recientemente de todos los mdulos desde una nica pgina. Qu quiere decir esto? Otro script que depende de todas las definiciones de tablas en todos los mdulos? Aqu va una pista de la solucin. En el sitio photo.net cada mdulo define un procedimiento cosas nuevas, que toma los siguientes argumentos:

since_when la fecha del contenido ms antiguo en el cual estamos interesados only_from_new_users_p un valor booleano que indica si queremos limitar el informe a las contribuciones de los nuevos usuarios (til para administradores de sitio porque los nuevos usuarios son los que no entienden los estndares y normas de la comunidad) purpose "admin", "email_summary", o "user"; esto controla la entrega del contenido no aprobado, la inclusin de enlaces a opciones de administracin como aprobar/rechazar, y el formato del informe

La salida de tal procedimiento puede ser simple: HTML para una pgina Web o texto plano para un mensaje de correo electrnico. La salida tambin puede ser una estructura de datos. Puede ser un documento XML que se va a interpretar mediante una hoja de estilos XSL. Lo importante es que las pginas interesadas en cosas nuevas que sucedieron en todo el sitio no necesitan conocimiento de los modelos de datos de los mdulos individuales, slo necesita saber el nombre del procedimiento cosas nuevas que le corresponde a cada mdulo. Esta
Pgina 34 de 30

ltima tarea se facilita en photo.net: a medida que el servidor Web carga cada mdulo se registra su procedimiento cosas nuevas en una lista a nivel del sitio. Si una pgina desea presentar contenido nuevo a nivel de todo el sitio, lo que hace es recorrer esta lista y llama a cada procedimiento en ella. Parmetros de configuracin Cunto tiene de buen gusto este enfoque de almacenar parmetros en la base de datos? La respuesta superficial es extremadamente de buen gusto. Toda nuestra informacin est en el RDBMS que es donde pertenece. No hay nmeros mgicos en el cdigo. Los parmetros se pueden editar desde las pginas de administracin, que tienen la misma forma que todas las otras pginas del sitio: consultas y actualizaciones SQL. Cuando se pasa un poco ms de tiempo con este problema, uno se pregunta: por qu estamos consultando la base de datos un milln de veces al da para conseguir informacin que cambia una vez al ao? Dejando a un lado las cuestiones de buen o mal gusto, si tenemos que realizar entre cinco a diez consultas adicionales al RDBMS por cada solicitud, eso se vuelve una carga significativa sobre el servidor de base de datos, que es la parte del la aplicacin de Internet ms difcil de distribuir entre mltiples computadoras fsicas y por lo tanto es la capa ms onerosa a la hora de expandir sus capacidades. Una buena regla de trabajo es que cada script Web nunca debe consultar la base de datos para saber qu hacer, sino slo para conseguir contenido y datos de usuario.

busca en la documentacin de la API del servidor y mira si encuentras un mecanismo para decir: corre esta porcin de cdigo cuando el servidor arranque construye una tabla hash en memoria, donde las claves de la tabla son las claves de los parmetros en la tabla hash carga los valores de un parmetro, en la forma de una lista, asociados con su clave documenta una API contra la tabla hash, que tome una clave como entrada y retorne un valor o una lista de valores como resultado

La tabla hash es lo mejor porque ofrece un acceso del orden O(1) a los datos, o sea, el tiempo que toma para responder a la consulta cul es el valor asociado con la clave 'foobar' no crece a medida que aumenta la cantidad de claves dentro del hash. En algunos lenguajes de programacin para aficionados, las tablas hash que vienen incorporadas al lenguaje pueden denominarse arreglos asociativos. Cmo proteger a un usuario del HTML del otro Fundamentalmente, el trabajo del servidor que hay detrs de una comunidad online es tomar texto que escribe el Usuario A y mostrrselo al Usuario B. Desafortunadamente, existe un riesgo de seguridad inherente en esta actividad. Supongamos que el Usuario A es malicioso y que incluye etiquetas como <SCRIPT> en el cuerpo de un comentario. Cuando el Usuario B visita la pgina que contiene ese comentario, de repente, el JavaScript se va a estar ejecutando en su mquina, y descargando imgenes objetables de diferentes lugares de Internet, tocando msica, abriendo nuevas ventanas, y por ltimo, forzando al navegador del usuario a visitar la pgina que el Usuario A haba elegido. La solucin ms obvia podra ser que deshabilitemos las etiquetas HTML. Cualquier texto que se suba se explora en busca de los caracteres < y > y, si se los encuentra, se rechaza la publicacin explicacin mediante. Esto no va a funcionar en un sitio para matemticos! Tal vez ellos necesiten usar los signos mayor y menor en sus comentarios. El comienzo de una solucin que funcione es un procedimiento, tal vez con un nombre del estilo quoteHTML que toma una cadena de texto que subi el usuario y realiza las siguientes conversiones: los caracteres < por &lt;. los caracteres > por &gt;. los caracteres & por &amp;. Si tus scripts de pgina invocan a este procedimiento cada vez que envan a un navegador el contenido que subi un usuario, nunca un navegador va a interpretar los datos subidos por
Pgina 35 de 30

usuario como si fueran etiquetas HTML. Esta solucin funciona muy bien para campos como first_names, last_name, street_address, lneas de resumen de temas, etc., en los cuales no vale de nada tener una etiqueta HTML. Sin embargo, en el caso de otros documentos largos que escriben los usuarios, puede ser interesante que se les permita utilizar cierto conjunto restringido de las etiquetas HTML, como B, I, EM, P, BR, UL, LI, etc. Si vas a almacenar HTML en la base de datos una vez y servirlo miles de veces al da, es mejor que se controlen las etiquetas legales al momento de subir los documentos. El problema con la verificacin de las etiquetas prohibidas como SCRIPT, DIV y FONT es que el HTML est en continua expansin, tanto de jure como de facto. A menos que quieras en tus manos la responsabilidad de mantenerte al da con todas las maneras que las etiquetas pueden influir en los navegadores, lo mejor ser que verifiques que las etiquetas del documento son slo las aprobadas. En cualquiera de los casos, vas a querer que la lista de etiquetas aprobadas o prohibidas se mantenga en un archivo de configuracin fcil de modificar. Ms an, es posible que quieras hacer validaciones adicionales con respecto al uso de etiquetas como B o I. Si un usuario comete un error y olvida cerrar una de estas etiquetas, puede alterar el estilo de fuentes de los siguientes 100 comentarios.

Pgina 36 de 30

Captulo 8 Discusin El foro de discusin es unas de las herramientas ms bsicas para la cooperacin mediada por computadoras entre seres humanos. El Usuario A puede poner una pregunta. El Usuario B puede poner una respuesta. El Usuario C ve la pregunta y la respuesta, y aprende del intercambio. En un foro con hilos de conversacin (threaded), el Usuario D tiene la posibilidad de poner una respuesta a la pregunta del Usuario A o a la respuesta del usuario B. En un foro en formato preguntas y respuestas, los Usuarios D, E, y F pueden poner respuestas a la pregunta del Usuario A, y las respuestas se van a presentar simplemente en el orden en que fueron enviadas. Con retoques menores en la capa de presentacin, un sistema de foros de discusin puede funcionar como weblog personal que admite comentarios. El foro de discusin como comunidad? Un foro de discusin bien diseado puede por s mismo satisfacer todos los requerimientos de una comunidad de aprendizaje online sustentable. Recuerda que esos elementos son los siguientes: 1. contenido atractivo escrito por expertos 2. medios de colaboracin 3. facilidades poderosas para navegar y buscar entre el contenido atractivo y el contenido contribuido 4. medios para delegar la moderacin 5. medios de identificar miembros que estn imponiendo una carga desproporcionada sobre la comunidad y formas de cambiar su comportamiento y/o excluirlos de la comunidad sin que se den cuenta. 6. medios para que los mismos miembros de la comunidad puedan extender el software Un ejemplo de la idea de foro como comunidad es USENET. Cada grupo de noticias es una comunidad ms o menos autocontenida de gente interesada en un tema particular, que colabora mediante un foro de discusin con hilos de conversacin. En un grupo de USENET el contenido atractivo puede ser cualquier mensaje ms o menos largo que publica algn experto reconocido. La FAQ (frequently asked questions) o preguntas frecuentes con sus respuestas es uno de los contenidos atractivos tpicos de un grupo de noticias. En la FAQ se indica para cada pregunta, la respuesta que los expertos han acordado para ella. El medio de colaboracin en un grupo de USENET es la capacidad de cualquier miembro de iniciar un nuevo hilo de conversacin o responder a un mensaje dentro de un hilo existente. La debilidad de USENET ha sido el cuarto elemento requerido. No haba suficientes voluntarios para la tarea de la moderacin, no exista software para dividir el esfuerzo de la moderacin de un foro entre mltiples moderadores, y el protocolo de News tena agujeros de seguridad que permitan pasar a los mensajes comerciales de spam incluso dentro de grupos moderados. USENET ha fallado trgicamente en el quinto elemento requerido. La mayora de los clientes de USENET incluyen los filtros de bozo que permiten a un usuario individual filtrar los mensajes de otros que sean persistentemente problemticos. Pero un grupo no tiene una forma colectiva de excluir a una persona que consistentemente inicia hilos de conversacin irrelevantes, enva spam al grupo, abusa de otros, o se vuelve molesto de alguna manera. Con respecto al elemento 6, medios, USENET ha funcionado extraordinariamente bien. Los servidores y clientes de USENET tienden a ser programas C monolticos, donde pequeas modificaciones pueden tener consecuencias catastrficas. Por otro lado, el usuario promedio de Internet en sus comienzos era un hbil desarrollador de software. As que si bien no todo usuario de USENET era un programador de herramientas para USENET, al menos es seguro afirmar que todo programador de herramientas USENET era un usuario de USENET. Mas all de USENET Cuando construyas tu propio foro de discusin alojado en la base de datos, hay ciertas mejoras simples que puedes realizar: un campo opcional para envame un mail cuando se publique una respuesta resmenes o alertas instantneas por email indizado de texto completo con actualizacin inmediata (asumiendo que lo permite tu RDBMS)
Pgina 37 de 30

transmisin segura de datos desde y hacia el foro mediante SSL moderacin colaborativa a travs de pginas de administracin para eliminar mensajes ya pasados de tiempo / repugnantes / o con cualquier otro problema. mensajes antiguos navegables por categora

Secure Socket Layer (SSL) El protocolo SSL es un sistema diseado y propuesto por Netscape Communications Corporation. Se encuentra en la pila OSI entre los niveles de TCP/IP y de los protocolos HTTP, FTP, SMTP, etc. Proporciona sus servicios de seguridad cifrando los datos intercambiados entre el servidor y el cliente con un algoritmo de cifrado simtrico, tpicamente el RC4 o IDEA, y cifrando la clave de sesin de RC4 o IDEA mediante un algoritmo de cifrado de clave pblica, tpicamente el RSA. La clave de sesin es la que se utiliza para cifrar los datos que vienen del y van al servidor seguro. Se genera una clave de sesin distinta para cada transaccin, lo cual permite que aunque sea reventada por un atacante en una transaccin dada, no sirva para descifrar futuras transacciones. MD5 se usa como algoritmo de hash. Proporciona cifrado de datos, autenticacin de servidores, integridad de mensajes y, opcionalmente, autenticacin de cliente para conexiones TCP/IP. Cuando el cliente pide al servidor seguro una comunicacin segura, el servidor abre un puerto cifrado, gestionado por un software llamado Protocolo SSL Record, situado encima de TCP. Ser el software de alto nivel, Protocolo SSL Handshake, quien utilice el Protocolo SSL Record y el puerto abierto para comunicarse de forma segura con el cliente. Uno o ms de un foro? La respuesta a esta pregunta depende demasiado del tipo de comunidad y, sobre todo, del tamao de esa comunidad. En una comunidad donde hay slo 50 usuarios y 100 foros de discusin, cmo hacen los usuarios a encontrarse? Es comn dividir los foros de discusin en categoras, esto es, tener algunas pocas categoras principales, y que luego cada una de ellas aloje una cierta cantidad de foros (que tampoco debe ser elevada). Incluso es til pensar en que un usuario pueda personalizar su vista de los foros, esto es, si un foro no le resulta interesante, el usuario puede indicarle al sistema que no le muestre ms ninguna discusin de dicho foro. Usabilidad Hace algo ms de una dcada, el uso de Internet era una experiencia muy diferente. Uno aprenda a utilizar una pgina leyendo el texto en negro, haca clic sobre los textos en azul (links), los cuales eran recordados luego con color prpura. Una vez aprendida esta navegacin, un usuario era capaz de utilizar prcticamente cualquier sitio web. Hoy en da esto ha cambiado radicalmente. El usuario promedio de hoy da es muy distinto al de hace una dcada. Es probable que muchos usuarios de Internet sepan usar una nica aplicacin de computadoras: el navegador web. Adems se han ido incorporando diversos componentes a las pginas web (JavaScript, ActiveX, Flash, etc.). Muchas veces los desarrolladores se cierran en sus creencias, en lo que ellos creen que es usable, que es fcil o sencillo. En lugar de utilizar los diseos ya probados (como Google, Yahoo, Amazon), experimentan buscando un servicio diferente. En la publicidad televisiva, diferente es algo bueno, diferente es bueno cuando al usuario le toma 30 segundos digerir el mensaje de la publicidad. Pero diferente es malo si esto significa que el usuario necesita tiempo extra por cada clic necesario para cumplir con su objetivo.

Pgina 38 de 30

Captulo 9 Usuarios mviles No hay razn alguna para pensar que los programas de escritorio (como Firefox o Internet Explorer) son la mejor manera de participar en comunidades online. La opcin de conexin mvil es cada vez ms comn en las comunidades online; la cuestin es: qu tipos de contenido y sentido de participacin se ajustan mejor a esta clase de usuarios? Standards

Cualquier servidor web puede servir contenido a un dispositivo mvil. El mvil se conecta al servidor a travs de la red wireless del proveedor. El contenido es entregado en XHTML Mobile Profile, un formato de HTML que se ajusta a los convenios de XML. Un ejemplo: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//WAPFORUM//DTD "http://www.wapforum.org/DTD/xhtml-mobile10.dtd">

XHTML

Mobile

1.0//EN"

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <head> <title> XHTML-MP Example </title> </head> <body> <p>We're not in the 1970s anymore.</p> </body> </html> Esto es muy parecido a lo que veramos para un navegador HTML de escritorio. Las principales diferencias son la inclusin de la declaracin XML y del tipo de documento (primeras dos lneas) y el uso del atributo xmlns en el tag <html>. Keypad Hyperlinks Para facilitar la navegacin a un usuario mvil, es posible asignar teclas de acceso rpido a los links del html devuelto al dispositivo mvil, por ejemplo: <ol> <li><a href="calendar" accesskey="1">Calendar</a></li> <li><a href="/academics/grades" accesskey="2">Grades</a></li> <li><a href="urgent-messages" accesskey="3">Urgent Messages</a></li> </ol>

Autenticacin por medio de cookies

Pgina 20 de 30

Los dispositivos mviles tienen soporte para cookies http (incluyendo las cookies persistentes), al igual que los navegadores web de escritorio. Asimismo, existe una excepcin importante en la utilizacin de cookies en dispositivos mviles: una coma dentro del valor de una cookie hace que la cookie no funcione (las comas no pueden utilizarse segn la definicin estricta de http, pero los navegadores de escritorio han sido permisivos en cuanto a su utilizacin). Es importante considerar la idea de utilizar cookies persistentes en los dispositivos mviles, ya que podra ser engorroso tener que loguearse cada vez que se desee utilizar el servicio (tener en cuenta que muy probablemente ser siempre el mismo usuario quien se conecte desde un dispositivo determinado, es decir, el dispositivo mvil lo utiliza slo su dueo). Construyendo la interfaz mvil Al construir la interfaz para un usuario mvil, es necesario tener en cuenta algunos aspectos importantes. Primero, los dispositivos podran comportarse de modo diferente a los emuladores (realiza las pruebas tanto en emuladores como en telfonos). Segundo, los microbrowsers son menos permisivos que los navegadores de escritorio, por lo que la sintaxis de html enviada a los dispositivos mviles debe ser totalmente correcta, no debe contener ningn tipo de error. Tercero, algunos dispositivos no son capaces de cargar pginas alojadas en servidores que corren en puertos no estndar. Por ltimo, el usuario mvil debera tener que tipear slo el hostname del sitio, es decir, no debera tener que agregar cosas como /mbl/ o /movil/ a la direccin del sitio. Busca oportunidades para ofrecer (push) Hasta ahora hemos considerado el modelo sincrnico solicitud/respuestas, que llega al mundo de los dispositivos mviles desde el mundo de la navegacin Web de escritorio. En otra forma usual de comunicacin, el usuario recibe informacin de manera asincrnica desde un servidor robot o desde un compaero de la comunidad. Los usuarios de escritorio reconocern como aplicaciones de esta modalidad a las alertas de email y la mensajera instantnea. Los dos requerimientos para la comunicacin asincrnica, ligada al usuario, son (a) el usuario debe tener una direccin, o sea, mediante una direccin de correo electrnico o un alias, y (b) el usuario debe correr un software que escucha a su favor, por ejemplo, un servidor de correo o un cliente de mensajera instantnea. Estas capacidades se conocen colectivamente como push en la industria inalmbrica. Dependiendo del proveedor de servicio inalmbrico del usuario, puede haber oportunidades para entregar mensajes de texto o multimedia a tus usuarios a medida que suceden eventos interesantes dentro de tu comunidad. Muchos telfonos mviles, por ejemplo, pueden recibir breves mensajes de texto a travs del sistema de correo electrnico. La direccin de email del telfono se forma concatenando el dominio especfico del proveedor con el nmero de telfono. As, si el nmero de telfono 617-555-1212 de Verizon Wireless pertenece a John, podemos enviarle alertas mediante email a 6175551212@vtext.com.

Pgina 21 de 30

Captulo 10 VoiceXML Introduccin Supn que Tracy (vicepresidenta de una firma de Boston) viaja a Los Angeles. Al llegar, ella quiere saber el nmero de telfono y direccin de uno de los empleados de la oficina de Los Angeles. Debido a que la intranet de su compaa no es accesible va telefnica, ella debe llamar a su asistente en Boston y pedirle que abra un navegador web para buscar la informacin deseada. Con VoiceXML, un desarrollador puede, en unas pocas horas, hacer disponible va telefnica cualquier tipo de informacin de la intranet (no slo para usuarios con telfonos de alta tecnologa, sino a usuarios con cualquier tipo de telfono). Tracy sera capaz de discar un nmero y decir el nombre del empleado sobre el que desea encontrar los datos. La aplicacin VoiceXML se encargar de buscar en las tablas de datos de la intranet, y luego ser capaz de leer en voz alta la direccin y el telfono del empleado (ntese que Tracy no depende de que su asistente se encuentre presente en la oficina de Boston). Qu es VoiceXML? VoiceXML es un lenguaje de marcas, al igual que HTML. La diferencia principal es que el HTML es implementado por el navegador web para dar formato al contenido y a los formularios de ingreso de datos; en cambio, VoiceXML es implementado por un navegador de voz. Tu aplicacin puede hablar al usuario por medio de habla sintetizada o por medio de archivos de audio pregrabados. Tu software puede recibir entradas a partir del habla del usuario o a partir de los tonos de las teclas del telfono. Cmo hacer disponible el contenido va acceso telefnico? Existen gateways de VoiceXML libres y gratuitos (www.tellme.com, www.bevocal.com, www.voicegenie.com). Estos gateways toman las pginas VoiceXML de tu servidor y se las leen al usuario. Si tu aplicacin necesita una entrada del usuario, el gateway interpretar la respuesta entrante y la pasar a tu servidor en un formato en que ste ltimo pueda entenderla.

HTML: el propietario del servidor http usa HTML para brindar una experiencia de usuario que es mostrada al lector en su computadora de escritorio. VoiceXML: el propietario del servidor http usa VoiceXML para brindar una experiencia de usuario que es proporcionada al usuario por medio de un gateway de un tercero; dicha experiencia es entregada al usuario en forma de audio.

T, como desarrollador, utilizas un formulario web para configurar el gateway con la URL de tu aplicacin, y el gateway asociar un nmero de telfono con dicha URL. Luego, por ejemplo en el caso de TellMe, los usuarios de tu aplicacin llaman al nmero 1-800-555- TELL, marcan los 5 dgitos de tu extensin, e instantneamente estn hablando con tu aplicacin.
Pgina 22 de 30

Ejemplo de VoiceXML El formato de un documento VoiceXML es muy simple, por ejemplo, el siguiente documento es para decir Hello World a tus usuarios: <?xml version="1.0"?> <vxml version="2.0"> <form> <block> <audio>Hello, World</audio> </block> </form> </vxml> La primera etiqueta, <?xml version="1.0"?> , especifica que el documento que sigue se ajusta al estndar XML 1.0. Todos los documentos VoiceXML siguen esta norma. Al igual que en cualquier documento XML, cada etiqueta de apertura (por ejemplo, <vxml> ) tiene que ser cerrada, ya sea con una etiqueta de cierre, como </vxml>, o con una barra ( / ) al final de la etiqueta, como en la etiquetas <else/> del ejemplo siguiente. La otra regla importante a recordar es que todos los valores de los atributos deben ir entre comillas, como en la versin="2.0" . XML es mucho ms estricto que HTML en estos dos aspectos. La etiqueta <vxml version="2.0"> especifica que se trata de un documento de VoiceXML 2.0. Dentro de la misma, que es un <form>, que puede ser un elemento interactivo - solicitando la intervencin del usuario - o informativos. Usted puede tener tantas formas como desee dentro de un documento VoiceXML. Un <block> es un contenedor para sus ejecutables, lo que significa que todas sus etiquetas que hacen que su aplicacin haga algo, como <audio> , <goto> , y una variedad de otros, pueden ser agrupados juntos dentro de un bloque. <audio>text</audio> va a leer el texto con un convertidor de TTS, mientras que <audio src="wav_file_URL"/> ejecutara un archivo de audio .wav pregrabado. El siguiente es un ejemplo ms complejo, en el que se le pregunta al usuario que llama si prefiere los perros o los gatos; se escucha la respuesta del usuario y, en base a ella, se redirecciona al usuario que llama a otra ubicacin. <?xml version="1.0"?> <vxml version="2.0"> <form id="animal_questionnaire"> <field name="favorite_animal"> <prompt> <audio>Which do you like better, dogs or cats?</audio> </prompt> <grammar> <![CDATA[ [ [dog dogs] {<option "dogs">} [cat cats] {<option "cats">} ] ]]> </grammar> <!-- if the user gave a valid response, the filled block is executed. --> <filled> <if cond="favorite_animal == 'dogs'"> <!-- this would take the user to a form called popular_dog_facts within the same VoiceXML document --> <goto next="#popular_dog_facts"/>

Pgina 23 de 30

<else/> <!-- this expression is an EMCAScript (JavaScript) expression, composed of a concatenated string and variable; this will take the user to the URI psychological_evaluation.cgi?affliction=cats --> <goto expr="'psychological_evaluation.cgi?affliction=' + favorite_animal"/> </if> </filled> <!-- if the user responded but it didn't match the grammar, the nomatch block is executed --> <nomatch> I'm sorry, I didn't understand what you said. <reprompt/> </nomatch> <!-- if there is no response for a few seconds, the noinput block is executed --> <noinput> I'm sorry, I didn't hear you. <reprompt/> </noinput> </field> </form> <!-- additional forms can go here --> </vxml> Aplicaciones mviles frente a voz Los navegadores de texto para mviles y VoiceXML cada uno tiene fortalezas y debilidades y por lo tanto son adecuado para diferentes aplicaciones - o para las diferentes partes de la misma aplicacin. Mobile Browser requiere telfonos con navegador mejorado entrada de usuario con teclado incmodo funciona bien en ambientes ruidosos es necesario desarrollar versiones de su software para una variedad de puertas de enlace(gateways) mviles funciona bien para mostrar una larga lista de informacin el usuario puede introducir informacin arbitraria VoiceXML se puede usar con cualquier telfono entrada por el habla o a travs del teclado difcil de usar en ambientes ruidosos slo necesita desarrollar una versin de su software funciona mal para dar al usuario una larga lista de informacin el usuario slo puede decir frases predefinidas

Una forma de aprovechar lo mejor de las interfaces mviles y de voz ser el desarrollo de aplicaciones multi-modales, como el sistema GPRS de reserva de avin en el ltimo captulo.

Pgina 24 de 30

Captulo 11 Escalabilidad Recordemos el hecho de que, por ms grande que sea una comunidad, no puede satisfacer todas y cada una de las necesidades. De hecho, las personas cancelan su suscripcin a listas de correo cuando stas alcanzan un tamao elevado. La utilidad y eficiencia de muchos grupos disminuye cuando la cantidad de miembros aumenta exponencialmente. Entonces: sin importar qu tan grande sea un competidor, siempre habr espacio para una nueva comunidad. La mala noticia es que el crecimiento resulta en importantes desafos de ingeniera. Al crecer una comunidad, algunos desafos pueden ser superados con dinero (dividir la carga para soportar una aplicacin de Internet entre varias CPU y unidades de disco, ms servidores, ms ancho de banda, etc.). Pero algunos desafos ms profundos no pueden resolverse con dinero, por ejemplo: cmo hacer que 100000 usuarios mantengan una conversacin entre ellos? Cmo puede una comunidad de aprendizaje en lnea apoyar 50.000 personas con 50.000 diferentes niveles de pasin por un tema y para la participacin? Cul es el anlogo electrnico de mantenerse en contacto con los vecinos? y con los amigos? En la mayora de las aplicaciones interactivas de Internet se ejecutan tareas fundamentales. Estas tareas son: Encriptacin (cifrado de la capa de transporte (SSL si el sitio tiene pginas seguras HTTPS)) Servicio HTTP capa de presentacin (composicin de pgina; ejecucin de secuencia de comandos(script)) prestacin de abstraccin (a veces llamada "lgica de negocio", cualquier capa de cdigo en la parte superior de la base de datos en bruto (contiene datos sin procesar) donde cada procedimiento es utilizado por ms de una pgina)) persistencia. En un sitio visitado modestamente, sera posible tener una CPU que realice todas de estas tareas. De hecho, para facilitar su mantenimiento y fiabilidad es mejor tener pocos servidores y tan simples como sea posible. No es difcil colocar hardware en un problema de rendimiento. El desafo es configurar ese hardware para que el servicio este funcionando si alguno de los componentes est siendo utilizado y no slo si todos los componentes estn siendo utilizados. Capa de Persistencia Para la mayora de las aplicaciones de Internet, la capa de persistencia es un sistema de gestin de bases de datos relacionales (RDBMS). El programa para el servidor RDBMS es analizar las consultas SQL, escribir las transacciones en el disco, hurgando en el disco(s) para datos rara vez usados, pegar datos en RAM y devolverlos al programa cliente RDBMS. El punto ms importante a tener en cuenta es que el nivel de performance est limitado por la velocidad de lectura/escritura de el/los discos rgidos. Suponiendo que tenemos una aplicacin tan popular que necesita de 16 CPUs para soportar todas las consultas a la base de datos. Deberamos comprar 16 computadoras de 1 CPU cada una? O bien una nica computadora con 16 CPUs? Vamos a considerar las peculiaridades de la aplicacin de RDBMS. El servidor RDBMS se comunica con varios clientes al mismo tiempo. Si el cliente A actualiza un registro en una base de datos y, una fraccin de segundo despus, el cliente B pide el registro, el RDBMS est obligado a entregar la informacin actualizada al cliente B. Si furamos a difundir el programa de servidor RDBMS en varios equipos fsicos, es posible que el cliente A se sirve de la computadora I y el cliente B se sirve de la computadora II. Una transaccin de base de datos no se puede asignar (commit) si no se ha escrito en la unidad de disco duro. Por lo tanto todo lo que estos equipos necesitan hacer es comprobar el disco para las actualizaciones antes de devolver cualquier resultado al cliente B. Los discos rgidos son 100.000 veces ms lento que la RAM. Un solo equipo que ejecute un RDBMS lleva una versin actualizada de las partes de uso
Pgina 25 de 30

general (comnmente usadas) de la base de datos en la RAM. As que nuestro servidor RDBMS de varios equipos, que garantiza la coherencia de la base de datos a travs de procesadores mediante referencias al disco duro comenzar 100.000 veces ms lento que un solo equipo servidor RDBMS. Tpicos productos comerciales de RDBMS, tales como Oracle Parallel Server, trabajan a travs de cada equipo manteniendo copias de la base de datos en la memoria RAM e informando a los dems de actualizaciones a travs de redes de comunicaciones de alta velocidad. La comunicacin mquina a mquina puede ser tan simple como un enlace de Ethernet de alta velocidad o tan complejo como circuitos especializados y cables que alcanzan velocidades de bus de memoria. No tenemos el mismo problema de sincronizacin entre CPUs que con un servidor de una caja de mltiples CPU? Absolutamente. La CPU I sirve al cliente A, la CPU II est sirviendo al cliente B. Las sos CPUs necesitan informar de actualizaciones en la base de datos. Hacen esto escribiendo en la memoria RAM compartida del equipo multiprocesador. Resulta que el ancho de banda de CPU-CPU disponible en servidores de gama alta tpicos alrededor de 2002 es de 100 Gbits/por segundo, que es 100 veces ms rpido que el ms rpido disponible Gigabit Ethernet, FireWire y otras tecnologas de interconexin baratas de mquina a mquina. Conclusin: si necesita ms de una CPU que debe ejecutar el RDBMS, generalmente tiene ms sentido comprar todas las CPU en una nica caja fsica. Capa de Abstraccin Suponiendo que tienes un clculo complejo que debe ser ejecutado en diferentes partes de tu aplicacin. La implementacin ms comn es encapsular dicho clculo en un procedimiento, y luego invocarlo desde los diferentes programas. Los beneficios de la abstraccin procedural son que, slo se tiene que escribir y depurar el cdigo de clculo una vez y que, si las reglas cambian, usted puede estar seguro de que la actualizacin del procedimiento nico ha actualizado su aplicacin completa. La capa de abstraccin se refiere a veces como "la lgica del negocio". Algo que es complejo y fundamental para el negocio debe ser separado de modo que se puede utilizar en varios lugares constantemente y actualizado en un lugar si es necesario. Se debe ejecutar la capa de abstraccin en su propio equipo fsico? Para la mayora de las aplicaciones, la respuesta es '' No ''. Estos procedimientos no son suficientemente exigentes como para dividirlas en diferentes computadoras, teniendo en cuenta, en trminos de sistema, que aumenta el esfuerzo de administracin y la vulnerabilidad a fallas de hardware. Es ms, estos procedimientos a menudo ni siquiera garantizan un entorno de ejecucin nuevo. La mayora de los procedimientos en la capa de abstraccin de un servicio de Internet requiere ntimo acceso a tablas de la base de datos relacional. El acceso es ms rpido cuando se ejecutan los procedimientos dentro del propia RDBMS. Todos los gestores de base de datos modernos proveen un lenguaje procedural (por ejemplo, PL/SQL). Cundo se debe considerar un entorno separado (proceso de "aplicacin de servidor") para la capa de abstraccin?. Supn que un banco tiene un mainframe IBM para manejar las cuentas de cheques, un gestor de base de datos Oracle para manejar las cuentas de crdito, y un servidor basado en SQL para soportar el sistema de clientes. Si un cliente llama y desea pagar la cuenta de su tarjeta de crdito con su cuenta de cheques, un programa de computadora necesita ejecutar una transaccin al mainframe, una transaccin al sistema Oracle y otra al servidor SQL. Tcnicamente es posible que, por ejemplo, un programa en Java corriendo dentro del servidor Oracle se conecte a las otras bases de datos para ejecutar operaciones, pero tpicamente este problema es resuelto implementando un proceso de servidor. Otro ejemplo de cuando un servidor aplicacin fsico separado podra ser deseable es cuando se deben realizar clculos importantes. En la mayora de los sitios para compartir fotos, cada vez que una foto se ha cargado, el servidor debe crear versiones a escala de tamaos estndar. El desafo de rendimiento en el sitio de viajes orbitz.com es an ms grave. Cada solicitud de usuario resulta en la ejecucin de un programa de Lisp que busca a travs de una base
Pgina 26 de 30

de datos de dos mil millones de vuelos y tarifas. Las mquinas de base de datos que realizan transacciones como reservas de billetes se derrumbaran si tendran que soportar tales bsquedas. Si se emplean CPUs fsicas separadas en la capa de abstraccin, deberan todas ellas entren en el misma caja o va a funcionas igual de bien con un rack y la pila de mquinas de una CPU baratas? Ms bien depende de donde se mantiene el Estado. Recuerde que HTTP es un protocolo sin estado. En algn lugar el servidor necesita recordar cosas tales como '' usuario registrado 137 quiere ver pginas en francs'', '' usuario sin registrar que inici sesin 6781205 ha colocado la edicin en tapa dura de los peces cclidos en su carrito de compras''. En una granja de servidores de varios equipos multiproceso, es imposible garantizar que a un usuario particular siempre se le devolver el mismo programa de ordenador en ejecucin, si por ningn otro motivo que desea que la experiencia del usuario sea robusta al fracaso de un solo equipo fsico. Si se mantiene el estado de sesin en cualquier lugar distinto de una cookie o de la capa de persistencia (RDBMS), los programas de servidor de aplicacin debern comunicarse entre ellos constantemente para asegurarse de que su base de datos ad hoc es coherente. En ese caso, podra tener sentido obtener un equipo caro multi-CPU para apoyar el servidor de aplicaciones. Sin embargo, si todas las capas son estticas, excepto la capa de persistencia, la capa de servidor de aplicaciones puede ser manejada por varios equipos de una CPU baratos. Por ejemplo, en orbitz.com, racks de equipos baratos se cargan con idnticas copias locales de tarifas y base de datos de calendarios. Cada vez que un usuario hace clic para ver las opciones de viaje desde Nueva York a Londres, uno de esos equipos de servidor de aplicaciones es seleccionado al azar para la accin. Capa de Presentacin Los programas de computadora de esta capa toman informacin de la capa de persistencia (RDBMS) y unen esos resultados en una plantilla apropiada para la interfaz de usuario y el software cliente. En una aplicacin web, estos programas realizan consultas SQL y unen los resultados en un template HTML que es entregado a un navegador Web. Tal programa es tan simple que a menudo es llamado script. Puedes pensar en la capa de presentacin como dnde corren los scripts. El lugar ms comn de ejecucin de estos scripts es dentro del proceso de sistema operativo sobre el que est corriendo en el servidor Web. En otras palabras, el intrprete de lenguaje de secuencia de comandos est incorporado en el servidor Web. Ejemplos de esta arquitectura son Microsoft Internet Information Server (IIS) y Active Server Pages, AOLserver y su base de intrprete Tcl, Apache y el complemento mod_perl. Si ha decidido utilizar uno de estos estilos populares de desarrollo Web, ha decidido combinar la capa de presentacin con la capa de servicio HTTP y, difundir la carga entre mltiples CPU para una capa ser automticamente extendida a la otra. La decisin entre multi-CPU versus mltiples CPU separadas se basa en este caso en si la capa de presentacin guarda un estado o no. Si ningn estado de sesin est en manos de los scripts de presentacin de ejecucin, es ms econmico agregar CPUs dentro de equipos fsicos independientes. Servicio HTTP Este servicio en s mismo es tan simple que casi no merece su propia capa, a menos que se est entregando audio y/o video a una audiencia masiva. Un programa de servidor de alto rendimiento puro HTTP como Zeus Web Server (consulte www.zeus.com) puede manejar ms de 6.000 solicitudes por segundo y saturar un vnculo de red de 100 Mbps en un nico procesador de 500 MHz Intel Celeron (vnculo de 100 Mbps costara unos 50.000 dlares anualmente como de febrero de 2005 por cierto). Por qu entonces alguien necesitara implementar mltiples CPUs para soportar el servicio HTTP para pginas con HTML bsico y simple? La principal razn es que los programas de servidor de HTTP son usualmente empaquetados con software que da soporte a capas que requieren mayor poder computacional. Por ejemplo, el servidor de base de datos Oracle, adems de soportar la capa de persistencia y abstraccin, incluye el software necesario para
Pgina 27 de 30

interpretar las Java Server Pages e implementar el servicio HTTP. Si se ejecuta un servicio popular directo de Oracle usted probablemente necesitar ms de una CPU. Ms ejemplos comunes son los servidores Web, como IIS y AOLserver que son capaces de manejar la presentacin y las capas de servicios HTTP del proceso del sistema operativo mismo. Si las secuencias de comandos implican una gran cantidad de anlisis de plantilla, es fcil de sobrecargar un solo CPU con las exigencias del servidor Web / intrprete de script. Si los estados no se almacena en la capa de servicio HTTP es ms barato agregar CPU en cajas fsicas separadas. HTTP es sin estado y la interaccin del usuario es totalmente mediada por el RDBMS. Por lo tanto, no hay ninguna razn para una CPU sirviendo una pgina al usuario A a querer comunicarse con una CPU sirviendo una pgina al usuario B. Capa de Transporte cifrada (Encriptacin) Ninguno de los protocolos TCP o IP provee encriptacin de datos en la transmisin. Por ello, cualquiera que sea capaz de controlar los paquetes de la red de rea local del servidor o del cliente o en los routers de la red troncal puede ser capaz de aprender, por ejemplo, las pginas particular solicitada por un usuario en particular. Hay dos formas de proteger la privacidad de los usuarios de rastreadores (sniffers) de paquetes. La primera es usando una versin ms reciente del Protocolo de Internet IPv6, que proporciona seguridad de datos nativos, as como la autenticacin. En el mundo de IPv6, podemos estar seguros del origen de un paquete, si es un usuario legtimo o un atacante de denegacin de servicio. Podemos estar seguros de que sera poco prctico para rastrear los nmeros de tarjeta de crdito u otros datos de la cuenta de usuario del trfico Web. Como de la primavera de 2005, sin embargo, que no es posible registrarse para un hogar una conexin IPv6. Por lo tanto, nos vemos obligados a retroceder en el enfoque de los aos 90 de agregar una capa entre HTTP y TCP. Esto fue desarrollado por Netscape Communications como Secure Sockets Layer (SSL) y ahora est siendo estandarizado como TLS 1.0 (vase http://www.ietf.org/html.charters/tls-charter.html). Sin embargo, el cifrado hace un uso intensivo del procesador. En el lado del cliente, no es gran cosa. El equipo cliente probablemente tiene un procesador de 2 GHz 98 por ciento inactivo. Sin embargo, en el lado del servidor, realizar el cifrado puede atar una CPU completa por el usuario durante la duracin de una solicitud. La adicin de procesadores de propsito general para un equipo multi-CPU es muy caro. Agregar ms servidores font-end de nica CPU a una granja de servidores de dos niveles no serauna mala estrategia, sobre todo porque, si ya ejecuta un conjunto de servidores de dos niveles, no requiere nuevas ideas ni habilidades de administracin de sistema. Sin embargo, es posible, que el hardware de propsito especial ser ms rentable o fcil de administrar. En particular es posible realizar el cifrado en el enrutador para IPv6. El cifrado SSL para conexiones HTTP puede hacerse con tarjetas plug-in, un ejemplo es el Compaq AXL300 PCI tarjeta, disponible en 2005 de 1.400 dlares y capaz (segn se afirma) de manejo 330 conexiones SSL por segundo. Finalmente es posible la interposicin de una mquina de cifrado de hardware entre el servidor Web, que se comunica a travs de HTTP normal, y el cliente, que realiza solicitudes a travs de HTTPS. Esta funcin es, por ejemplo, una opcin de balanceo de carga de enrutadores F5 Networks (www.f5.com). Tienes suficientes CPUs? Seguramente te has preguntado cmo determinar si el hardware con el que cuentas es suficiente para soportar el volumen de trfico de las peticiones esperadas. Una buena regla es que no puedes manejar ms de 10 peticiones de pginas dinmicas por segundo por cada CPU (una pgina dinmica es aquella que involucra la ejecucin de cualquier programa de computadora en el lado de servidor que no sea el simple servicio HTTP, es decir algo mas que el envo de un archivo JPEG o HTML). La cifra de 10 por segundo supone que las pginas, o bien no estn cifrados o que la encriptacin se realiza mediante hardware adicional en la parte frontal del servidor HTTP. Por ejemplo, si tiene un servidor RDBMS de con 4-CPUs manejando persistencia y abstraccin y 4 mquinas front-end de 1-CPU manejando presentacin y servicio HTTP, no debe esperar ofrecer ms de 80 pginas dinmicas por segundo.
Pgina 28 de 30

Este esquema tampoco considera la velocidad de la CPU, ya que la misma es independiente al nmero de peticiones que puedes soportar. Por qu? Porque, si bien la velocidad de las CPUs ha aumentado con el tiempo, tambin lo ha hecho la complejidad de las pginas que se sirven (Java, XML/XSLT, etc.). Balanceo de Carga Un servicio de Internet con 100 CPUs distribuidas en 15 computadoras fsicas no necesariamente ser confiable si todas las CPUs deben estar funcionando en pos de la funcin general del sistema. Al contrario, se necesita una estrategia de balanceo de carga para que: 1) las peticiones de usuario se distribuyan de modo uniforme entre las CPUs disponibles. 2) cuando una parte del hardware falle, esto no resulte en demasiados errores devueltos a los usuarios. 3) podemos reconfigurar hardware y red sin daar marcadores y vnculos de otros sitios del usuario. Empezaremos con un enfoque de una granja de servidores de dos niveles con una sola mquina multi-CPU que ejecuta el RDBMS y varias mquinas front-end de una sola CPU, en cada una de las cuales se ejecuta el programa de servidor Web, interpreta los scripts de la pgina, realiza el cifrado SSL, y, en general efecta cualquier clculo que no se realiza dentro del RDBMS.

Una configuracin de servidor tpico para un volumen de aplicacin de Internet de medio a alto. Un servidor potente multi-CPU compatible con el sistema de gestin de base de datos relacional. Varias pequeas mquinas de 1-CPU ejecutan el programa de servidor HTTP Balanceo de carga en la capa de Persistencia En nuestro enfoque la capa de persistencia es un servidor multi-CPUs ejecutando el RDBMS, el cual tpicamente es un programa dividido en mltiples procesos o hilos. Para cada base de datos de cliente, el RDBMS genera un hilo de procesamiento separado del resto. Si asumimos que la carga de las peticiones de usuario se distribuyen entre las mquinas front-end, la carga del trabajo de base de datos ser distribuida entre todas las CPUs disponibles por el proceso de sistema operativo o el programador de subprocesos. Balanceo de carga entre las mquinas Front-End Para preservar la libertad de reorganizar los componentes dentro del conjunto de servidores, por lo general los usuarios de Internet pblica slo hablan a un enrutador de balanceo de carga, que es la "cara pblica" del servicio y cuya direccin IP se traduce a www.popularservice.com.
Pgina 29 de 30

El enfoque moderno de balanceo de carga es el enrutador de balanceo de carga. Esta mquina, tpicamente construida de hardware estndar de PC que ejecuta un sistema operativo Unix libre y una fina capa de software personalizado, es la nica mquina que es visible desde la Internet pblica. Todo el hardware de servidor est detrs el equilibrador de carga y tiene las direcciones IP que no son enrutables del resto de Interne. Si un usuario solicita la www.photo.net, por ejemplo, esto se traduce a 216.127.244.133, que es la direccin IP del equilibrador de carga de photo.net. El equilibrador de carga acepta la conexin TCP en el puerto 80 y espera al cliente Web para proporcionar una lnea de solicitud, por ejemplo, "GET/HTTP/1.0". Slo despus de que ha recibido esa solicitud hace el intento de equilibrador de carga para ponerse en contacto con un servidor Web en la red privada detrs de l. Este tipo de enrutador proporciona una seguridad inherente. Los servidores Web y el servidor RDBMS no pueden ser contactados directamente por crackers en la Internet pblica. La nica forma de ataque con xito en el equilibrador de carga, es a travs de un ataque en el programa de servidor Web (Microsoft Internet Information Server sufri muchas vulnerabilidades de desbordamiento de bfer) o un ataque en los scripts de pgina de los editores/autores. El enrutador tambin ofrece cierta proteccin contra ataques de denegacin de servicio. Si un servidor Web est configurado para generar un mximo de 100 subprocesos simultneos, un usuario malintencionado puede efectivamente cerrar el sitio simplemente al abrir 100 conexiones TCP al servidor y luego no enviar nunca una lnea de solicitud. Los equilibradores de carga son inteligentes acerca de recoger tales conexiones inactivas y en cualquier caso tienen muy largas colas. El equilibrador de carga puede ejecutar arbitrariamente complejos algoritmos para decidir cmo encaminar una solicitud del usuario. Se puede enviar la solicitud a un conjunto de servidores de aplicaciones en un round-robin, teniendo un servidor fuera de la rotacin si no responde. El equilibrador de carga peridicamente puede extraer informacin de salud y carga de los servidores front-end y enviar cada solicitud entrante al servidor menos ocupado. El equilibrador de carga puede inspeccionar el URI solicitado y la ruta a un servidor en particular, por ejemplo, el envo de cualquier solicitud que comienza con "/ discutir /" a la mquina Windows que se ejecuta el software de foro de discusin. El equilibrador de carga puede tener una tabla donde las solicitudes anteriores fueron encaminadas y tratar de encaminar las peticiones sucesivas de un usuario particular, a la misma mquina de front-end (til en los casos en que el estado se acumula en una capa que no es el RDBMS). Sea cual sea el algoritmo de equilibrador de carga que est utilizando, un fallo de hardware en una de las mquinas frontales generalmente se traducir en el hecho de que slo un puado de peticiones de los usuarios, es decir, aquellos en proceso en la mquina, realmente fallen. Failover (Conmutacin por error) Si recordamos los 3 objetivos del balanceo de carga, podemos decir que con el enfoque presentado estos objetivos son alcanzados. Pero, qu sucede si el servidor de base de datos falla en su totalidad? Qu sucede si el balanceador de carga falla? Hacer un failover desde un balanceador de carga que no funciona a uno que s es, esencialmente, un desafo de la configuracin de la red. Bsicamente son requeridos dos balanceadores de carga idnticos, cooperando con el siguiente link de ruteo hacia la Internet. Este siguiente link debe saber con qu balanceador de carga comunicarse, dependiendo de
Pgina 30 de 30

cul est activo y funcionando. En cuanto a hacer un failover de un servidor de base de datos cado a otro que funcione es un desafo ms grande. El primer enfoque es contar con dos o tres fuentes de alimentacin para el servidor, hacer un espejado de discos rgidos y, por supuesto, varias CPUs internas. Asimismo, este enfoque no es 100% confiable. Un enfoque ms confiable es montar varios servidores en paralelo; los clientes de base de dato se conectarn al servidor que est disponible en ese momento. Si bien una falla en uno de los servidores provocara errores en la conexin a algunos clientes, las posteriores peticiones seguiran funcionando correctamente. Traducir las cosas buenas de una comunidad offline a una online Como traducimos cosas como la identificacin, autenticacin y responsabilidad al mundo online? En compaas privadas es fcil, no dejamos que nadie fuera de la compaa ingrese. Otra forma, menos restrictiva y que se usa en las comunidades online, requiere una verificacin de email. En las conversaciones cara a cara, un orador puede ver las reacciones de las personas a medida que habla. En un programa de comunicacin de computadora tpico se hace fcil transmitir las ideas a cualquiera que lo est usando, pero sin la oportunidad de obtener retroalimentacin en cmo se recibe el mensaje. Para esto se podra hacer que un usuario exponga sus pensamientos a un grupo de gente, que sera un porcentaje de la audiencia total, y obtener una reaccin en respuesta de ellos. De esta manera se puede refinar el mensaje antes de enviarlo a todo el grupo. Otra cosa genial seria enviar el mensaje a aquellos usuarios que estn conectados en ese momento, para hacerlo ms dinmico. A la gente le gustan las computadoras e internet porque son rpidas. Si buscas una respuesta a una pregunta vas al mejor buscador que conozcas. En el mundo offline la gente desea velocidad. Sin embargo cuando hay emociones de por medio, generalmente, se elije esperar antes de reaccionar. Para algunas comunidades eso sera muy bueno. Responder a algo ahora pero no publicarlo, sino mandar un mail a las 24 horas diciendo lo que escribiste y si lo deseas publicar o no, en caso de que hallas cambiado de opinin.

Pgina 31 de 30

Captulo 12 Bsqueda Una comunidad online sustentable es aquella que puede acomodar y guiar a los nuevos usuarios. Si un usuario no puede encontrar contenido relevante a sus necesidades, molestar a otros miembros. La primera lnea de defensa de una comunidad es la arquitectura de la informacin y la navegacin. Los usuarios son mejores navegadores que formuladores de consultas. Sin embargo, la segunda lnea de defensa de una comunidad es un servicio excelente de bsqueda de texto completo. La base de datos de bsqueda debe incluir tanto el editor/autor como el contenido aportado por el usuario. Aqu hay algunos ejemplos categoras de consultas:

respondiendo a la pregunta: por ejemplo, planeando un viaje a la isla de Sanibel

(Florida) para tomar fotografas de aves y querer saber qu largo debe tener un teleobjetivo para alquilar, el usuario escribe "mejor lente Sanibel" donde se encuentra, por ejemplo, recordar que existe un tutorial sobre cmo tomar fotografas en los jardines, el usuario escribe " fotografa jardn" encontrar discusiones de compartir fotos cuando escribe " compartir foto"

navegacin: el usuario sabe que un documento existe en el servidor, pero no recuerda

realizacin de tareas: el usuario desea encontrar la pgina de carga de fotos, no limpieza: el usuario desea encontrar la poltica de privacidad del sitio, no un debate

sobre las polticas de privacidad, despus de escribir "poltica de privacidad" En un sitio grande, un usuario podra restringir la bsqueda de alguna manera. Si el formulario de bsqueda en la parte superior de un documento que es un captulo de un libro en lnea, podra tener sentido ofrecer las opciones "todo el sitio" y "dentro de los captulos de este libro". Si el editor o los dems usuarios se han tomado el trabajo de calificar el contenido, la bsqueda predeterminada puede limitar los resultados a aquellos documentos que han sido calificados de alta calidad. Si hay varios foros de discusin en el sitio, que es esencialmente una subcomunidad independiente, los cuadros de bsqueda en las pginas pueden ofrecer una opcin de "restringir la bsqueda a los mensajes en este foro". Si un usuario no ha visitado el sitio durante un mes y quiere ver si hay algo nuevo y pertinente, el sitio quizs debera ofrecer una opcin de "restringir la bsqueda a contenido agregado en los ltimos 30 das". Qu est mal de SQL? (calidad de bsqueda) El RDBMS parece la herramienta perfecta para las bsquedas. Tenemos un montn de datos, y deseamos gran flexibilidad en las consultas. Supn que una persona ingresa el texto running en el formulario de bsqueda. La sentencia SQL se traducir en algo as: SELECT * FROM CONTENT WHERE UPPER(BODY) LIKE UPPER(%running%) Qu sucede si el usuario ingresa varias palabras, por ejemplo, running shoes? La consulta no devolver aquel registro con el contenido shoes for running. En cambio, debemos modificar la sentencia SQL: SELECT * FROM CONTENT WHERE UPPER(BODY) LIKE UPPER(%running%) AND UPPER(BODY) LIKE UPPER(%shoes%) Es evidente que esta forma no es la ms eficiente, ni tampoco la correcta. Si hay varios documentos que contienen ambas palabras, estos son los que el usuario debera ver primero. Pero si no existen resultados con ambas palabras, el usuario podra querer ver aquellos donde se encontr al menos una de las palabras. Otra limitacin de esta tcnica, es que no encontrar resultados donde el contenido no sea explcitamente el solicitado en la consulta (por ejemplo, contenido con palabras como ran, marathon, etc). Lo que se necesita es un sistema para contener tanto los trminos de consulta y los trminos
Pgina 32 de 30

indexados: running, runs, y ran todo sera colocado bajo la palabra madre run para la indexacin y recuperacin. Qu pasa con un mensaje que dice ''asist al 100 aniversario de la Maratn de Boston ''? La consulta LIKE no tomar eso. Lo que se necesita es un sistema para ampliar las consultas a travs de un diccionario de sinnimos suficientemente potente como para hacer la conexin entre ''running'' y ''marathon''.

Qu est mal de SQL? (performance) Al utilizar la sentencia LIKE, el RDBMS debe examinar cada registro de la tabla en cuestin para examinar el campo sobre el que se aplica el operador LIKE. Supongamos que una tabla est indexada por la columna body. De este modo, podemos responder consultas como SELECT * FROM CONTENT WHERE BODY = running o SELECT * FROM CONTENT WHERE BODY LIKE running%. Pero los intereses de los usuarios no estn restringidos a aquellos documentos que slo contengan la palabra running ni a los que comiencen con dicha palabra. El usuario desea documentos en los que la palabra running puede estar sepultada .Un nico ndice rbol-B no va a ayudar. Abandonar el RDBMS para las bsquedas full-text Podemos resolver los problemas de performance y calidad de bsqueda solo con volcar todos nuestros datos en un sistema de bsqueda de texto completo. Como el nombre lo dice, este sistema indexa cada palabra en un documento, no solo las primeras palabras sino todo como un rbol B. Un ndice de texto completo puede responder a la pregunta "Encontrarme los documentos que contengan la palabra running" en el tiempo que se acerca O [1], es decir, una cantidad de tiempo que no vara con el tamao del corpus indexado. Si hay 10 millones de documentos en el corpus, una bsqueda a travs de esos 10 millones de documentos no tomar mucho ms tiempo que una bsqueda a travs de un corpus de 1000 documentos. (para acercarse a tiempo constante en esta situacin sera necesario que la coleccin de 10 millones de documentos haya utilizado un vocabulario ms grande que la coleccin de 1000 documento y que no era el caso de que, por ejemplo el 90 por ciento de los documentos contiene la palabra "running".) Cmo funciona? Como cualquier otra estrategia de indexacin, requiere un tiempo extra de proceso al momento de insertar la data, para luego utilizar menos tiempo al realizar la consulta. Considera la creacin de una gran tabla de datos que contenga cada palabra del lenguaje ingls y, por cada palabra, una lista de los IDs de documentos donde dicha palabra aparece. Luego, al insertar un nuevo documento, deberemos recorrer todas y cada una de sus palabras, actualizando los registros correspondientes de la tabla anterior. Este esfuerzo extra requerido en la insercin har que la bsqueda sea ms eficiente y rpida. A veces es til omitir ciertas palabras: the, in, on, la, los, de, etc. Luego, con este esquema, podemos encontrar rpidamente los documentos que contengan la palabra shoes. Tambin los que contengan la palabra running. De hecho, podemos combinar los resultados para obtener aquellos que contienen ambas palabras. Es ms: con algn mecanismo de indexacin ms elegante, podemos devolver aquellos documentos que poseen las palabras en forma contigua (running shoes). Supn que hay 1000 documentos que contienen las dos palabras. Cules son ms relevantes al usuario? Para determinar esto, necesitamos un histograma de frecuencias de palabras. Este histograma nos dir qu palabras hay en un documento, y qu tan frecuentemente son usadas (segn la longitud del documento). Despus de que se hace el histograma en crudo, normalmente se ajustado por la prevalencia de las palabras en Ingls estndar. As, por ejemplo, la aparicin de ''se parecen'' es ms interesante que ''feliz'' porque ''se parecen'' es produce con menos frecuencia en la norma Ingls. Palabras vacas como ''es'' se desechan por completo. Stemming (races) es otro refinamiento til. En el ndice y en las consultas, convertimos todas las palabras en sus tallos. La palabra madre para familias, por ejemplo, es familia''. Con Stemming, una consulta para familias se correspondera con un documento que contiene familia y viceversa.
Pgina 33 de 30

Dado un cuerpo de histogramas es posible responder a consultas como '' Mostrar documentos que son similares a sta '' o '' Mostrar documentos cuya histograma es ms cercano a una cadena introducida por el usuario''. La consulta entre documentos similares se puede controlarse mediante la comparacin de histogramas ya almacenados en la base de datos de texto. La cadena de bsqueda '' minas de platino en Nueva Zelanda '' podra ser procesada primero descartando las palabras '' en '' y '' nueva ''. Mediante el uso de comparacin de histograma, el software entrega artculos que tienen ms ocurrencias de platino, minas' y Zelanda. Supongamos que Zelanda es una palabra ms rara que platino. Entonces un documento con una aparicin de Zelanda se ve favorecido por uno con una aparicin de platino. Un documento con una ocurrencia de cada palabra se prefiere un artculo donde aparece slo una de esas palabras. Un documento que contiene slo la frase minas de platino Zelanda es un partido mejor que un documento que contiene 100.000 palabras, tres de las cuales aparecen para que coincida con los trminos de consulta. El poder de esta clase de sistemas es muy excitante y trae aparejado la pregunta: Podremos corre nuestro sitio desde un sistema de base de datos de bsqueda de texto completo especializado? Seguramente, porque no colocar todo en el RDBMS? No lo colocamos dentro de la base de datos porque deberemos manejar el problema de la concurrencia. Dos usuarios tratando de modificar el mismo tem simultneamente generaran un problema. Un acercamiento seria empezar por guardar todos los documentos en el RDBMS. Una vez por noche o cada cierto tiempo, actualizar la coleccin del sistema de bsqueda. Las pginas que son parte de la experiencia del usuario y el flujo de trabajo operaran desde el RDBMS. Sin embargo, el cuadro de bsqueda en la esquina superior derecha de cada pgina, consulta contra el sistema de bsqueda de texto completo. Vamos a llamar un diseo de sistema dividido. Un argumento en contra del enfoque del sistema dividido es que se mantienen dos copias de la coleccin de documentos. En una era de $200 por unidades de disco de alta capacidad, esto no es un argumento poderoso. Es casi imposible llenar una unidad de disco moderna con palabras escritas por los seres humanos. Uno puede llenar una unidad de disco con secuencias de vdeo o audio, pero no con texto. Y en cualquier caso algunos sistemas de bsqueda de texto completo pueden crear un ndice para una coleccin de documentos sin ellos mismos mantener el documento original, que es, de hecho slo una copia del documento en el RDBMS. Un segundo argumento contra el uso de sistemas de bsqueda de texto completo y RDBMS simultneamente es que las colecciones de documentos obtenidas estran desincronizadas. Si el servidor Web se estrella en medio de una transaccin de RDBMS, todo el trabajo se deshace. Si el servidor Web simultneamente fuera a insertar un documento en un sistema de bsqueda de texto completo, es posible que la base de datos de texto contenga un documento que de hecho no est disponible en las pginas principales del sitio, el sitio se genera desde el RDBMS. Por otra parte, la insercin en el RDBMS podra tener xito mientras que la insercin de texto completo falla, llevando a un documento que est disponible en el sitio, pero no para bsquedas. Este argumento, tambin, en ltima instancia carece de poder. Es cierto que el RDBMS es un medio conveniente y casi infalible de administracin de transacciones y concurrencia. Sin embargo, no es la nica manera. Si uno contratar programadores suficientemente cuidadosos y sistema suficientemente dedicado y los administradores de bases de datos, sera posible mantener dos bases de datos sincronizadas. Un tercer argumento en contra es la diferencia entre interfaces. Sin embargo, el mejor argumento en contra del uso de un RDBMS y un sistema de bsqueda de texto completo es que el sistema de divisin naturalmente no admiten los tipos de consultas que son necesarias: Mostrar documentos que coincidan con los "mejores restaurantes", escritos por los usuarios cuya direccin registrada es menos de 10 millas del cdigo postal 02138 Mostrar documentos que coincidan con la "Fotografa de estudio", escrita por los usuarios cuyas contribuciones han sido calificados por encima del promedio de otros usuarios (clasificacin de dicho elemento de contenido se almacena en tablas RDBMS)
Pgina 34 de 30

 Mostrar documentos que coincidan con "mejores trucos de publicidad " escritos por usuarios cuyos anuncios recientes han atrado a ms de 5 ofertas cada uno

Un enfoque de Divisin-sistema para proporcionar bsquedas de texto completo. El contenido de la aplicacin se almacena en un sistema de gestin de base de datos relacional. Secuencias de comandos mantienen peridicamente una segunda copia en una base de datos de texto especializado. El programa de servidor Web realiza consultas, inserciones y actualiza el RDBMS. Cuando un usuario solicita una bsqueda de texto completo, sin embargo, la consulta se enva a la base de datos de texto. Utilizando motores de bsqueda pblicos Si tu comunidad se encuentra en la Internet pblica, probablemente quisieras que su contenido sea indexado por los buscadores pblicos, como Google. En primer lugar, Google tiene que saber acerca de su servidor. Esto ocurre ya sea cuando alguien ya agreg en los enlaces del ndice de Google a su sitio o cuando se agregue manualmente la direccin URL de un formulario de la pgina de inicio google.com. En segundo lugar, Google tiene que ser capaz de leer el texto en el servidor. Al menos hasta 2005 ninguno de los motores de bsqueda pblicos implementaba reconocimiento ptico de caracteres (OCR). Esto significa que no se indexaba texto incrustado en un archivo GIF, animacin Flash o un applet de Java. Podra ser legible por un usuario humano con visin perfecta, pero no ser legible por los programas de ordenador que rastrear la Web para construir bases de datos para los motores de bsqueda pblicos. En tercer lugar, Google tiene que ser capaz de entrar en todas las pginas en el servidor. Si se requiere registro para ver discusiones, por ejemplo, esos debates no son indexados por Google a menos que el software sea lo suficientemente inteligente como para reconocer que es Google detrs de la solicitud y hacer una excepcin.
Pgina 35 de 30

robots.txt El fichero robots.txt es un archivo de texto que dicta unas recomendaciones para que todos los crawlers y robots de buscadores cumplan (ojo! recomendaciones, no obligaciones). Pero comencemos por el principio. Un crawler es un robot de una entidad (generalmente buscadores) que acceden a las pginas web de un sitio para buscar informacin en ella, aadirla en los buscadores, etc. Tambin son llamados spiders, araas, bots o indexadores. Por ejemplo, Googlebot es el nombre del crawler del buscador Google. Tambin existen otros como: Mediapartners-Google, que es el crawler que se encarga de revisar los anuncios de Google Adsense. Googlebot-Image, robot indexador de imagenes del buscador de Google. Slurp, crawler de indexacin del buscador Yahoo! noxtrumbot, del buscador Noxtrum. Scooter, del buscador Altavista. Y muchsimos ms. Si establecemos un control en nuestro robots.txt, podremos conseguir una serie de beneficios: Impedir acceso a robots determinados: Puede parecer contradictorio, pero algunos crawlers no nos proporcionarn sino problemas. Algunos robots no son de buscadores, e incluso algunos robots no son ni amigos. Pero de eso ya hablaremos ms tarde. Reducir la sobrecarga del servidor: Podrs controlar el flujo de algunos robots. Algunos de ellos son un verdadero descontrol de peticiones que pueden llegar a saturar tu servidor. Prohibir zonas: Nos puede interesar tener disponible una zona en nuestra web, que sea accesible para algunos, pero que no aparezca en buscadores. Eliminar contenido duplicado: Uno de los casos ms importantes, que casi siempre es olvidado por los webmasters. Si eliminamos la duplicidad de contenido, los buscadores nos puntuaran muy alto, aumentando el flujo de visitas. Fijar mapas del sitio: Tambin es posible acoplar un sitemap para indicar el buen camino a los robots. Y entonces, que hay que hacer? Es muy sencillo. Slo tenemos que crear un fichero de texto robots.txt y comenzar a escribir en el. Partir del siguiente ejemplo donde permitimos la entrada a todos los crawlers (igual que sin ningn robots.txt): User-agent: * Disallow: En User-agent debemos introducir el nombre del robot, y a continuacin las rutas donde queremos prohibir que acceda. Algunos ejemplos: Disallow: / prohibe la entrada a todo el sitio. Disallow: /foro/ prohibe la entrada a los documentos del directorio foro. Disallow: permite la entrada a todo el sitio. En algunos casos suele utilizarse en lugar de Disallow, la palabra Allow. Aunque por definicin es correcta, es conveniente no utilizarla, puesto que las rutas omitidas se asumen que estn permitidas por defecto, y algunos crawlers no entienden la palabra Allow. Es posible acumular varios Disallow bajo un mismo User-agent, pero no podemos utilizar varios User-agent encima de un Disallow. Bien, algn ejemplo: # Crawler de MSN User-agent: msnbot Disallow: /links.html Disallow: /private/ Disallow: /photos/ Este cdigo impide al crawler del buscador de Live (MSN) acceder a la pgina links.html, y las carpetas private y photos (y todo su contenido) de nuestro sitio.
Pgina 36 de 30

Aadiendo el carcter # al principio de una linea podemos escribir comentarios que no interpretar el crawler. Es posible ir acumulando reglas para distintos crawlers, formando un robots.txt ms largo y completo. Cada vez que escribamos un User-agent deberemos dejar una linea en blanco de separacin. Adems, existe una ligera adaptacin que permiten usar comodines ($ y *) en las rutas en algunos crawlers (slo Googlebot y Slurp): User-agent: Slurp Disallow: /*.js$ Disallow: /2006/* Disallow: /2007/* Disallow: /articulos/*/pagina/* Se est indicando al robot de Yahoo, que no indexe los ficheros que terminen en .js (javascript), direcciones que empiecen por 2007 o 2006 (fechas), ni artculos con la palabra pagina (paginado de comentarios). Estos casos pertenecen a la idea de no indexar contenido duplicado. En la mayora de los blogs, puedes acceder a un mismo artculo por las direcciones: blog.com/articulo/titulo, la direccin principal. blog.com/2007/04/, el archivo del mes. blog.com/articulo/titulo/feed, feed RSS del artculo. blog.com/articulo/titulo/pagina/2, pagina 2 de comentarios. Todo esto es contenido duplicado, una de las razones ms importantes de penalizacin para un buscador, a no ser, claro, que te las ingenies para que slo sea accesible desde una direccin. A la hora de ver los resultados te asombrars lo bien que estars quedando ante los ojos de Google, por ejemplo. Hay que tener mucho cuidado con usar cosas como Disallow: /pagina o Disallow: /*pagina, puesto que en lugar de bloquear lo que queramos (carpeta pagina o artculos paginados), terminen bloqueando direcciones como /decorar-mi-pagina o /paginas-para-amigos/. Si revisas estadsticas y dems, tambin puedes observar que a veces algunos crawlers se pasan revisando nuestro sitio, y funden a peticiones a nuestro pobre servidor. Existe una manera de tranquilizar a los robots: User-agent: noxtrumbot Crawl-delay: 30 Con esto le decimos al robot de noxtrum que espere 30 segundos entre cada acceso. Cuidado, porque Crawl-delay no lo soportan todos los crawlers (al menos MSNBot y Slurp si lo soportan, y Googlebot desde el panel de webmasters tambin). Finalmente, podemos tambin incluir un mapa del sitio en nuestro robots.txt de la siguiente forma: Sitemap: http://www.algunsitio.com/sitemap.xml En RobotsTXT.org podrs encontrar documentacin oficial si quieres profundizar y en esta bsqueda de Google encontrars muchos robots.txt de ejemplo, incluso robots.txt optimizados para tu tipo de web. Adems, tambin tienes un validador de robots.txt. Recordar a todos que con el fichero robots.txt no podemos bloquear los accesos por fuerza bruta. Robots.txt es una recomendacin del webmaster a los buscadores, que como son robots buenos, las seguirn al pie de la letra. Existen otros robots malos (que buscan direcciones de correos o formularios para hacer SPAM) que no dudarn en acceder a los lugares que hayas prohibido si lo desean. Para bloquear estos, deberemos echar mano al fichero .htaccess, pero como deca Michael Ende, eso ya es otra historia.

Pgina 37 de 30

Captulo 14 Computacin con HTTP, XML, SOAP y WSDL distribuida Lo que hace posible esto son los nuevos protocolos que se han creado desde HTTP, y son diseados para que los programas interacten con programas en lugar de que la gente navegue con sus navegadores. Existen varios protocolos: 1. Intercambio de datos: algo mejor que rascar texto de la Web para que los humanos lean (se puede utilizar XML aqu). 2. Invocacin de programas: alguna manera de invocar remotamente mtodos, es decir, para que programas llamen a otros programas corriendo en otras maquinas y contesten esta llamada. El estndar emergente aqu (mayo de 2000) se llama SOAP (Simple Object Access Protocol) 3. Autodescripcin (de formas de ser invocado): Una forma legible por mquina para que los programas puedan describir cmo se supone que se llamar, por ejemplo, con Web Services Description Lenguage (WSDL). Por ejemplo, con Universal Description Discovery and Integration (UDDI) 4. Descubrimiento (de servicios): una manera de que los programas aprendan automticamente de otros programas.

Una interaccin de servicios Web. Usuarios humanos hablan a los servidores A y B a travs del protocolo HTTP reciben resultados en pginas HTML. Cuando el servidor A necesita invocar un procedimiento en el servidor B primero intenta averiguar cules son los nombres de las funciones y sus argumentos. Esta informacin vuelve en un documento de lenguaje de descripcin de servicios Web (WSDL). Utilizando la informacin de ese documento WSDL, el servidor A es capaz de formular una solicitud legal de SOAP (Simple Object Access Protocol) y procesar los resultados. En estos momentos estamos pasando de un entorno donde las aplicaciones se implementan en las distintas mquinas y servidores Web, a un mundo donde las aplicaciones se componen
Pgina 30 de 40

de piezas - llamadas servicios en la jerga actual - que se propagan a travs de muchas mquinas diferentes, y donde los servicios interactuar sin problemas y de forma transparente para producir un efecto global. Si bien las consecuencias de este cambio podran ser menores, tambin es posible que puedan ser tan profundas como la introduccin de la Web. En cualquier caso, las empresas estn introduciendo nuevos marcos de servicios web que se aprovechan de la nueva infraestructura. Microsoft. NET es un marco de esa ndole. SOAP en el cable Vamos a comenzar con un vistazo de los mensajes SOAP, que normalmente se envan a travs de la red incrustados en POSTs HTTP. Aqu hay un par de solicitud/respuesta SOAP en crudo para un servicio hipottico de '' quin est en lnea '' que devuelve informacin sobre los usuarios que han estado activos en los ltimos N segundos: Solicutd: POST /services/WhosOnline.asmx HTTP/1.1 Host: somehost Content-Type: text/xml; charset=utf-8 Content-Length: length SOAPAction: "http://jpfo.org/WhosOnline" <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <WhosOnline xmlns="http://jpfo.org/"> <n_seconds>600</n_seconds> </WhosOnline> </soap:Body> </soap:Envelope> Respuesta: HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Content-Length: length <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <WhosOnlineResponse xmlns="http://jpfo.org/"> <WhosOnlineResult> <user> <first_names>Eve</first_names> <last_name>Andersson</last_name> <email>eve@eveandersson.com</email> </user> <user> <first_names>Philip</first_names> <last_name>Greenspun</last_name> <email>philg@mit.edu</email> </user> <user> <first_names>Andrew</first_names> <last_name>Grumet</last_name>
Pgina 31 de 40

<email>aegrumet@alum.mit.edu</email> </user> </WhosOnlineResult> </WhosOnlineResponse> </soap:Body> </soap:Envelope> WSDL: El archivo WSDL es una descripcin formal de las funciones que se pueden llamar, los nombres de los argumentos y tipos y los tipos de valor devuelto. Ms entornos de desarrollo de aplicaciones de Internet proporcionan un conjunto de herramientas SOAP que transforman el archivo WSDL en un conjunto de clases de proxy o bibliotecas de funciones que se pueden llamar como si el servicio se implementara en tiempo de ejecucin local. En Microsoft Visual Studio.NET, esta operacin se conoce como '' agregar una referencia Web''. Web semntica: Qu es la Web Semntica? La Web Semntica es una Web extendida, dotada de mayor significado en la que cualquier usuario en Internet podr encontrar respuestas a sus preguntas de forma ms rpida y sencilla gracias a una informacin mejor definida. Al dotar a la Web de ms significado y, por lo tanto, de ms semntica, se pueden obtener soluciones a problemas habituales en la bsqueda de informacin gracias a la utilizacin de una infraestructura comn, mediante la cual, es posible compartir, procesar y transferir informacin de forma sencilla. Esta Web extendida y basada en el significado, se apoya en lenguajes universales que resuelven los problemas ocasionados por una Web carente de semntica en la que, en ocasiones, el acceso a la informacin se convierte en una tarea difcil y frustrante. Para qu sirve? La Web ha cambiado profundamente la forma en la que nos comunicamos, hacemos negocios y realizamos nuestro trabajo. La comunicacin prcticamente con todo el mundo en cualquier momento y a bajo coste es posible hoy en da. Podemos realizar transacciones econmicas a travs de Internet. Tenemos acceso a millones de recursos, independientemente de nuestra situacin geogrfica e idioma. Todos estos factores han contribuido al xito de la Web. Sin embargo, al mismo tiempo, estos factores que han propiciado el xito de la Web, tambin han originado sus principales problemas: sobrecarga de informacin y heterogeneidad de fuentes de informacin con el consiguiente problema de interoperabilidad. La Web Semntica ayuda a resolver estos dos importantes problemas permitiendo a los usuarios delegar tareas en software. Gracias a la semntica en la Web, el software es capaz de procesar su contenido, razonar con este, combinarlo y realizar deducciones lgicas para resolver problemas cotidianos automticamente. Cmo funciona? Supongamos que la Web tiene la capacidad de construir una base de conocimiento sobre las preferencias de los usuarios y que, a travs de una combinacin entre su capacidad de conocimiento y la informacin disponible en Internet, sea capaz de atender de forma exacta las demandas de informacin por parte de los usuarios en relacin, por ejemplo, a reserva de hoteles, vuelos, mdicos, libros, etc. Si esto ocurriese as en la vida real, el usuario, en su intento, por ejemplo, por encontrar todos los vuelos a Praga para maana por la maana, obtendra unos resultados exactos sobre su bsqueda. Sin embargo la realidad es otra. La figura 1 muestra los resultados inexactos que se obtendran con el uso de cualquier buscador actual, el cual ofrecera informacin variada sobre Praga pero que no tiene nada que ver con lo que realmente el usuario buscaba. El paso siguiente por parte del usuario es realizar una bsqueda manual entre esas opciones que aparecen, con la consiguiente dificultad y prdida de tiempo. Con la incorporacin de semntica a la Web los resultados de la bsqueda seran exactos. La figura 2 muestra los resultados obtenidos a travs de un buscador semntico. Estos resultados ofrecen al usuario la informacin exacta que estaba buscando. La ubicacin geogrfica desde la que el usuario enva su pregunta es detectada de forma automtica sin necesidad de especificar el punto de
Pgina 32 de 40

partida, elementos de la oracin como "maana" adquiriran significado, convirtindose en un da concreto calculado en funcin de un "hoy". Algo semejante ocurrira con el segundo "maana", que sera interpretado como un momento determinado del da. Todo ello a travs de una Web en la que los datos pasan a ser informacin llena de significado. El resultado final sera la obtencin de forma rpida y sencilla de todos los vuelos a Praga para maana por la maana.

La forma en la que se procesar esta informacin no slo ser en trminos de entrada y salida de parmetros sino en trminos de su SEMNTICA. La Web Semntica como infraestructura basada en metadatos aporta un camino para razonar en la Web, extendiendo as sus capacidades. No se trata de una inteligencia artificial mgica que permita a las mquinas entender las palabras de los usuarios, es slo la habilidad de una mquina para resolver problemas bien
Pgina 33 de 40

definidos, a travs de operaciones bien definidas que se llevarn a cabo sobre datos existentes bien definidos. Para obtener esa adecuada definicin de los datos, la Web Semntica utiliza esencialmente RDF, SPARQL, y OWL, mecanismos que ayudan a convertir la Web en una infraestructura global en la que es posible compartir, y reutilizar datos y documentos entre diferentes tipos de usuarios.

RDF proporciona informacin descriptiva simple sobre los recursos que se encuentran en la Web y que se utiliza, por ejemplo, en catlogos de libros, directorios, colecciones personales de msica, fotos, eventos, etc. SPARQL es lenguaje de consulta sobre RDF, que permite hacer bsquedas sobre los recursos de la Web Semntica utilizando distintas fuentes datos. OWL es un mecanismo para desarrollar temas o vocabularios especficos en los que asociar esos recursos. Lo que hace OWL es proporcionar un lenguaje para definir ontologas estructuradas que pueden ser utilizadas a travs de diferentes sistemas. Las ontologas, que se encargan de definir los trminos utilizados para describir y representar un rea de conocimiento, son utilizadas por los usuarios, las bases de datos y las aplicaciones que necesitan compartir informacin especfica, es decir, en un campo determinado como puede ser el de las finanzas, medicina, deporte, etc. Las ontologas incluyen definiciones de conceptos bsicos en un campo determinado y la relacin entre ellos.

Otra tecnologa que ofrece la Web Semntica para enriquecer los contenidos de la Web tradicional es RDFa. Mediante RDFa se pueden representar los datos estructurados visibles en las pginas Web (eventos en calendarios, informacin de contacto personal, informacin sobre derechos de autor, etc.), a travs de unas anotaciones semnticas incluidas en el cdigo e invisibles para el usuario, lo que permitir a las aplicaciones interpretar esta informacin y utilizarla de forma eficaz. Por ejemplo, una aplicacin de calendario podra importar directamente los eventos que encuentra al navegar por cierta pgina Web, o se podran especificar los datos del autor de cualquier foto publicada, as como la licencia de cualquier documento que se encuentre. Para extraer el RDF se podra utilizar GRDDL, una tcnica estndar para extraer la informacin expresada en RDF desde documentos XML, y en particular, de las pginas XHTML. Ejemplos Dos de los ejemplos ms conocidos de aplicacin de Web Semntica son RSS y FOAF.

RSS es un vocabulario RDF basado en XML que permite la catalogacin de informacin (noticias y eventos) de tal manera que sea posible encontrar informacin precisa adaptada a las preferencias de los usuarios. Los archivos RSS contienen metadatos sobre fuentes de informacin especificadas por los usuarios cuya funcin principal es avisar a los usuarios de que los recursos que ellos han seleccionado para formar parte de esa RSS han cambiado sin necesidad de comprobar directamente la pgina, es decir, notifican de forma automtica cualquier cambio que se realice en esos recursos de inters seleccionados. Un ejemplo de la aplicacin de RSS se puede encontrar en las Noticias de la Oficina Espaola del W3C como canal RSS. FOAF es un proyecto de Web Semntica, que permite crear pginas Web para describir personas, vnculos entre ellos, y cosas que hacen y crean. Se trata de un vocabulario RDF, que permite tener disponible informacin personal de forma sencilla y simplificada para que pueda ser procesada, compartida y reutilizada. Dentro de FOAF podemos destacar FOAF-a-Matic, que se trata de una aplicacin Javascript que permite crear una descripcin FOAF de uno mismo. Con esta descripcin, los datos personales sern compartidos en la Web pasando a formar parte de un motor de bsqueda donde ser posible descubrir informacin a cerca de una persona en concreto y de las comunidades de las que es miembro de una forma sencilla y rpida.
Pgina 34 de 40

Ejemplo de extraccin de datos usando RDFa, GRDDL y SPARQL:

Se desea establecer una reunin entre tres personas, que tienen publicados en

sus sitios Web los calendarios de sus citas y eventos. Estos datos estn expuestos en pginas XHTML de forma grfica, pero adems se incluye informacin en RDFa.
Una herramienta nos permite extraer, mediante GRDDL, los datos de sus

calendarios en un formato homogneo y fcil de tratar (RDF), para poder procesarlo posteriormente.
Se realiza una consulta sobre la disponibilidad de las personas para un cierto da

a una hora concreta. Los datos consultados estn en formato RDF y la consulta se podra realizar mediante SPARQL.
La herramienta procesa y analiza el resultado obtenido, concluyendo si las

personas estn disponibles en el instante que se haba elegido previamente.

Figura 3 - Ilustracin del ejemplo de consulta de eventos de calendario Los buscadores semnticos son un ejemplo ms de aplicaciones basadas en Web Semntica. El objetivo es satisfacer las expectativas de bsqueda de usuarios que requieren respuestas precisas. Otros ejemplos de aplicaciones basadas en Web Semntica pueden encontrarse en SWAD-Europe: Aplicaciones de Web Semntica - anlisis y seleccin. Resource Description Framework: RDF es un modelo estndar para el intercambio de datos en la Web. RDF tiene caractersticas que facilitan la fusin de los datos incluso si los esquemas subyacentes son diferentes, y se apoya especficamente en la evolucin de esquemas en el tiempo sin necesidad de todos los consumidores de datos para ser cambiado. RDF extiende la estructura de enlace de la Web para utilizar URI para nombrar la relacin entre las cosas, as como los dos extremos del enlace (normalmente conocido como "triple "). El uso de este modelo simple, que permite que los datos estructurados y semiestructurados puedan ser mezclados, expuestos y compartidos a travs de diferentes aplicaciones.
Pgina 35 de 40

Esta estructura de enlace, forma un grafo dirigido y etiquetado, donde los bordes representan el nombre del enlace entre dos recursos, representada por los nodos del grfico. Este punto de vista grfico es el ms fcil posible modelo mental para RDF y se utiliza a menudo en fcil de entender las explicaciones visuales.

http://www.guilleromomuller.com-----> Autor---- Guillermo Mller RDF est construido sobre una de las estructuras ms simples para representar datos: un grafo dirigido etiquetado. Un grafo RDF es tpicamente un conjunto de tripletas de la forma <Sujeto,Propiedad,Objeto> y cada una de estas tripletas es una asercin que expresa que un recurso (una entidad en la Web Semntica) est relacionado con otra entidad o con un valor a travs de una propiedad. Utilizando la terminologa RDF, los recursos y propiedades se identifican mediante URIs (Uniform Resource Identifiers: es una cadena corta de caracteres que identifica inequvocamente un recurso (servicio, pgina, documento, direccin de correo electrnico, enciclopedia, etc.). Normalmente estos recursos son accesibles en una red o sistema.) En un grafo RDF, los nodos siempre se referencian mediante URIs, valores o nodos en blanco. Cada una de estas URIs denotan recursos, los valores son literales y los nodos en blanco referencian recursos annimos en un grafo RDF. Estn conectados por arcos dirigidos desde los nodos Sujeto hasta los nodos Objeto. Estos arcos representan predicados (Propiedades) y se identifican tambin mediante URIs: las propiedades tambin son recursos en la Web Semntica. Resumiendo, un grafo RDF es un conjunto de tripletas de la forma <s,p,o> donde, s es un nodo Sujeto, que puede ser una URI o un nodo en blanco. p es un arco Propiedad, un predicado binario identificado por una URI. es un nodo Objeto, que puede ser una URI, un nodo en blanco o un literal. Really Simple Syndication o RSS: Un formato XML para sindicar o compartir contenido en la web. Se utiliza para difundir informacin actualizada frecuentemente a usuarios que se han suscrito a la fuente de contenidos. El formato permite distribuir contenidos sin necesidad de un navegador, utilizando un software diseado para leer estos contenidos RSS (agregador). A pesar de eso, es posible utilizar el mismo navegador para ver los contenidos RSS. Las ltimas versiones de los principales navegadores permiten leer los RSS sin necesidad de software adicional. RSS es parte de la familia de los formatos XML desarrollado especficamente para todo tipo de sitios que se actualicen con frecuencia y por medio del cual se puede compartir la informacin y usarla en otros sitios web o programas. A esto se le conoce como redifusin web o sindicacin web (una traduccin incorrecta, pero de uso muy comn).

Pgina 36 de 40

Captulo 15 Metadato y generacin automtica de cdigo En esta seccin podr crear una representacin legible por mquina de los requisitos de una aplicacin y, a continuacin, crear un programa para generar los programas de ordenador que implementan la aplicacin. Vamos a tratar este material en el contexto de la construccin de un sistema de gestin de conocimiento, uno de los tipos ms comunes de las comunidades en lnea y tratar de introduccin a la terminologa utilizada por gente de negocios en esta rea. Exploraremos el concepto de metadato (dato sobre el modelo de datos) y la cuestin de la generacin automtica de cdigo en el ambiente de la administracin del conocimiento. Qu es el Knowledge Management (Gestin del Conocimiento)? Un sistema de gestin de conocimientos o sistema de intercambio de conocimientos es un sistema de informacin para varios usuarios (multi-usuario) que les permite compartir conocimientos sobre un dominio compartido de experiencia e investigacin. Qu es conocimiento? Desde la perspectiva de un sistema de bases de datos relacional, consideraremos el conocimiento como texto, escrito por un usuario de la comunidad, al cual el usuario podra adjuntar un documento, una fotografa o una hoja de clculo. Otros usuarios pueden hacer comentarios sobre el conocimiento, la presentacin de texto y adjuntos opcionales de su propiedad. Por qu las organizaciones desean un sistema de administracin del conocimiento? En cualquier organizacin, la habilidad y experiencia de un grupo de trabajadores o estudiantes tendr aproximadamente una distribucin Gaussiana: un pequeo puado de personas que no sabrn prcticamente nada (principiantes), un pequeo puado de personas que sabrn absolutamente todo (magos, avanzados), y la mayor parte del grupo, que posee conocimientos moderados. Entonces, los directivos se preguntan: qu tanto podramos progresar si todas las personas de la organizacin tuviesen el mismo conocimiento que los magos? Normalmente, la hiptesis inicial es que el conocimiento es finito y esto se traduce en la construccin de un sistema para contener un cuerpo principalmente esttico de conocimiento, a ser extrado de los cerebros de los expertos y codificado en una serie archivos o registros de la base de datos. Un segundo enfoque intenta ayudar a los usuarios novatos y no tanto con la experiencia de los usuarios ms capaces, utilizando un sistema de knowledge-sharing, donde el usuario A puede colocar una pregunta frente a la comunidad, y los usuarios B, C y D pueden escribir nuevo material sobre el tpico y/o indicar al usuario A dnde encontrar la informacin que necesita (por ejemplo en artculos ya escritos). Control dimensional Cuando se muestra gran cantidad de informacin en una pgina, se debe considerar colocar control dimensional en la parte superior. Supongamos que quisieras ayudar a un administrador a navegar entre los inscriptos de un sitio. Un sitio bien diseado tendr un pequeo nmero luego de cada opcin a la que pueda acceder el administrador mostrando los usuarios que existen en cada categora. Un sistema de diseo pobre no tendr ninguna referencia y dejara que el administrador adivine la cantidad de usuarios por cada opcin. Este enfoque tradicional tiene algunos inconvenientes. En primer lugar, agrega un clic del ratn antes de que el administrador pueda ver los nombres de usuario. Idealmente, se desea que todas las pginas de una aplicacin muestren informacin y posibles acciones en lugar de burocracia pura y navegacin. En segundo lugar y ms en serio, este enfoque no escala bien. Cuando un administrador dice "Necesito ver los usuarios que se han registrado en los ltimos 30 das, que ha contribuido con ms de 4 revisiones de productos, y que han comprado al menos por 100 dlares de cosas, para que yo les pueda enviar spam con un cupn," otra opcin debe agregarse a la lista. Finalmente la pgina de navegacin se queja con opciones. Una manera diferente de implementar esto sera la siguiente: imagnense ahora que un clic lleva al administrador a ver todos los usuarios que se registraron en el ltimo mes en una lista grande. En la parte superior existen deslizadores. Cada deslizador controla una dimensin, cada uno puede restringir o expandir el nmero de tems en la lista.
Pgina 37 de 40

A continuacin presentamos algunas dimensiones de ejemplo para un sitio de comercio electrnico de la comunidad como amazon.com: inmediatez de registro, desde hace 1 da (restrictivas) al principio del tiempo (suelta). la proximidad geogrfica, desde el mismo cdigo postal (restrictiva), a la misma ciudad, con el mismo Estado a cualquier parte del mundo (suelta). total de compras, de al menos $10.000 (restrictivas), al menos 500 dlares, a $0 o ms (suelta). examinar la actividad, del Top 100 revisores (restrictivas), del Top 1000 revisores para 0 o ms revisiones (sueltas). contenido de calidad, de revisin promedio calificada 4,5 estrellas o mejor (restrictivas) a cualquier media. Si la pgina predeterminada muestra demasiados nombres, el administrador ajustar un regulador o dos pare ser ms restrictivo. Si el administrador desea ver ms nombres, ajustar un regulador hacia el extremo suelto de esa dimensin. Cmo implementar controles dimensionales? Lamentablemente, no hay ninguna etiqueta HTML que generar un pequeo control deslizante continuo. Puede simular un regulador, para cada dimensin, ofreciendo un conjunto de puntos discretos a lo largo de la dimensin, que es un anclaje de hipervnculo de texto simple. Por ejemplo, para la calidad del contenido puede ofrecer '' 4 o mejor,'' '' 3 o mejor,'' '' 2 o mejor,'' '' todos ''. Zanahorias y palos; el huevo y la gallina La mayora de los trabajadores son recompensados por trabajar, porque querran tomarse un tiempo extra para ensear y responder preguntas en un sistema online? Las personas se toman el tiempo para realizar preguntas y, por eso, esperan una respuesta. Si nadie responde, nadie pregunta y se convierte en un crculo vicioso. Es importante crear un sistema de incentivos que recompense a usuarios por demostrar el comportamiento deseado. Que tiene sentido premiar en una comunidad en lnea? Podramos comenzar con un par de actividades obvia: la creacin de contenidos y responder a las preguntas. Cada noche, nuestro sistema puede consultar las tablas de contenido y la tabla de usuario, actualizando filas de acuerdo a la cantidad de artculos y respuestas que haban publicado en la base de datos. Es realmente una buena idea de recompensar a los usuarios nicamente sobre la base del volumen? No deberamos dar ms peso al contenido que en realidad ha ayudado a la gente? Por ejemplo, suponga que hay diez respuestas a una pregunta en el foro de discusin. Tiene sentido para dar una mayor recompensa al autor de la respuesta que la persona que pregunta senta que era ms valioso. Si una pregunta puede ser marcado como "urgente" por el que pregunta, es probable que tenga sentido para dar mayores beneficios a las personas que responder a las preguntas urgentes que los que no son urgentes. Un artculo est bien, pero un artculo que lleva a otro usuario a decir "volv a utilizar esta idea en mi rea de la organizacin" es mucho ms agradable y debe fomentarse con una recompensa mayor.

Pgina 38 de 40

Captulo 16- Anlisis de la actividad del usuario Este captulo examina las maneras en que puede supervisar la actividad del usuario dentro de su comunidad y cmo esa informacin puede utilizarse para personalizar la experiencia del usuario. Paso 1: haga las preguntas apropiadas Antes de considerar lo que es tcnicamente factible, es mejor empezar con una lista de deseos de las preguntas sobre la actividad de los usuarios que tienen ms relevancia para la aplicacin de su cliente. stas son algunas preguntas de arranque:

Cules son las direcciones URL que producen errores de servidor? (la respuesta
conduce a la accin: corregir cdigo defectuoso)

Cuntos usuarios pidieron archivos inexistente, y de donde se reciben las URLs

incorrectas? (la respuesta conduce a la accin: reparacin de vnculos incorrectos)

Al menos el 50% de los usuarios visitan /foobar/, nuestra seccin ms reciente y ms

importante?(la respuesta conduce a la accin: aadir tal vez ms punteros a la nueva seccin de otras reas del sitio)

Cun populares son la voz y las interfaces inalmbricas para la aplicacin? (la respuesta conduce a la accin: dedicar ms esfuerzos a las interfaces populares)

Cules son las pginas que estn causando que los usuarios se atasquen y abandonen
sus sesiones? Es decir, cules son las ltimas pginas tpicas visitadas antes de que un usuario desaparezca? (la respuesta conduce a la accin: aclarar la interfaz de usuario o la anotacin en esas pginas) anuncios en Google y www.nytimes.com. Qu probabilidades hay de que visitantes de estas dos fuentes compren algo? Cmo se comparan los importes en dlares? (la respuesta conduce a la accin: comprar ms anuncios desde el lugar que enve a usuarios de alta rentabilidad)

Supongamos que operamos un sitio de comercio electrnico y que hemos comprado

Paso 2: mira lo que esta fcilmente disponible Cada programa de servidor HTTP se puede configurarse para registrar sus acciones. Normalmente el servidor escribir dos registros (logs): (1) el "registro de acceso"(access log), que contiene una lnea correspondiente a cada solicitud de usuario y (2) el "registro de errores" (error log), que contiene informacin completa sobre lo que pas durante las solicitudes que dio lugar a errores de programa. Un "archivo no encontrado" resultar en una entrada de registro de acceso, pero no en una entrada de registro de error porque el servidor no tena que detectar un error de secuencia de comandos. Por el contrario, dar como resultado una secuencia de comandos, enviar un comando SQL ilegal a la base de datos, un registro de acceso y una entrada de registro de error. Paso 3: date cuenta de qu informacin extra necesitas almacenar Si su cliente est descontento con el tipo de informacin disponible en los registros estndar, existen tres alternativas bsicas: configurar el programa de servidor HTTP para agregar contenido de encabezado cookie para el registro de acceso estndar. aumentar su software para registrar la actividad de usuario adicional en el RDBMS y construir las pginas de consulta ad hoc en el rea de administrador de sitio del servicio construir un almacn de datos dimensional completo de actividad de usuario Si todo lo que necesita es el ID de usuario para cada solicitud, a menudo es una cuestin simple configurar el programa de servidor HTTP, por ejemplo, Apache o Microsoft Internet
Pgina 39 de 40

Information Server, para anexar el contenido de la cookie a cada lnea en el registro de acceso. Cuando eso no es suficiente, puede comenzar a agregar columnas a las tablas de la base de datos. Probablemente tenga una columna registration_date en la tabla de usuarios, por ejemplo. Esta informacin se podra derivar de los registros de acceso, pero si necesita mostrar una anotacin de "miembro desde 2001" como parte de su perfil de usuario, tiene ms sentido mantenerlo en el RDBMS. Si desea ofrecer a los miembros una pgina de "nuevos elementos desde su ltima visita" probablemente va a agregar columnas last_login y second_to_last_login a la tabla de usuarios. Tenga en cuenta que necesita una columna second_to_last_login porque tan pronto como el usuario #345 vuelve al sitio, el software actualizar last_login. Cuando se hace clic en la pgina "nuevo desde la ltima visita", podra ser slo treinta segundos desde la marca de tiempo en la columna last_login. Lo ms probable es que espera el nuevo contenido del usuario #345 desde el lunes anterior, su anterior perodo de sesiones con el servicio. El camino de agregar columnas a las tablas de procesamiento de transacciones y creacin de consultas SQL ad hoc para responder preguntas, es un largo y tortuoso. La manera tradicional de volver a un sistema de informacin fcil de administrar con usuarios, para obtener las respuestas que necesita, es el almacn de datos dimensional. Un almacn de datos es una copia sin normalizar en gran medida, de la informacin en las tablas de procesamiento de transacciones, dispuestos a fin de facilitar las consultas en lugar de actualizaciones. Riesgo de seguridad por correr programas en respuesta de una solicitud Web Correr el analizador de log por pedido de un administrador suena inocente, pero cualquier sistema en el que un servidor de HTTP pueda iniciar un proceso en respuesta a una solicitud Web puede presentar riesgos. Muchos lenguajes de script tiene el comando exec con el cual el servidor Web tiene todo el poder de un usuario logreado escribiendo una lnea de comandos. Esta es una capacidad poderosa y til, pero un usuario malicioso puede ser capaz, por ejemplo, de correr un programa que devuelva el nombre de usuario y la contrasea del servidor. En el mundo Unix la solucin ms efectiva a este desafo es chroot, corta para cambiar de raz. Este comando cambia la raz del sistema de archivos del servidor web, y cualquier programa iniciado por el servidor Web, a algn otro lugar en el sistema de archivos, por ejemplo, /web/main-server/. Un programa en el directorio /usr/local/bin/ no puede ser ejecutado por el servidor Web chroot porque el servidor Web no puede ni siquiera describir un archivo a menos que su ruta se inicia con /web/main-server/. El directorio raz, /, es ahora /web/mainserver/ . Una desventaja de este enfoque es que si el servidor Web debe ejecutar un programa en el directorio /usr/local/bin/ no se puede. La solucin es tomar todas las utilidades, los analizadores de registro del servidor, y otros programas necesarios y colocarlos debajo de /web/main-server/, por ejemplo, a /web/main-server/bin/. Notificaciones de errores en tiempo real Podra ser til crear notificacin de error en el software. Pueden capturar errores graves y el controlador de errores puede llamar a un procedimiento de notify_the_maintainers que enva correos electrnicos. Esto podra valer como, por ejemplo, en una instalacin centralizada que permite secuencias de comandos de pgina para conectarse con el sistema de gestin de bases de datos relacionales (RDBMS). Si no est disponible el RDBMS, los administradores de sistemas, dbadmins, y programadores deberan ser notificados inmediatamente para que puedan averiguar lo que pas y llevar el sistema devuelta al funcionamiento correcto. Supongamos que una falla en el RDBMS se combin con una aplicacin ingenua de notify_the_maintainersen un sitio que obtiene 10 solicitudes por segundo. Supongamos adems que todas las personas en la lista de notificacin de correo electrnico han salido para almorzar junto durante una hora. A su regreso, encontrarn 60 x 60 x 10 = 36.000 idnticos mensajes en la bandeja de entrada de correo electrnico. Para evitar este tipo de desastre, es probablemente mejor tener notify_the_maintainers registrada con una marca de tiempo last_notification_sent en la memoria del servidor HTTP o en disco y utilizarlo para ignorar o acumular las solicitudes de notificacin que vienen en,
Pgina 40 de 40

digamos, a 15 minutos de una solicitud anterior. Una suposicin razonable es que un programador, una vez alertado, visitar el servidor y empezar a mirar los registros de errores completos. As notify_the_maintainers realmente no necesita enviar informacin acerca de cada problema encontrado.

Pgina 41 de 40