UNIDAD 2.- DESARROLLO DE APLICACIONES WEB. 2.1 Metodologas para el desarrollo de apl !a!

o"es #e$
La ingeniera de software es una disciplina que integra %&todos' (erra% e"tas ) pro!ed % e"tos para el desarrollo de software de computadora. El proceso de desarrollo de software contiene tres fases genricas, independientemente del paradigma de ingeniera elegido. Las tres fases, definicin, desarrollo, y mantenimiento, se encuentran en todos los desarrollos de software independientemente del rea de aplicacin, del tamao del proyecto o de la complejidad. La fase de definicin se centra sobre el qu. Esto es, durante la definicin, el que desarrolla el software intenta identificar qu informacin debe ser proporcionada, qu funcin ) rendimiento se desea, qu interfaces deben establecerse, qu restricciones de diseo e isten y qu criterios de !alidacin se necesitan para definir un sistema correcto. "unque los mtodos aplicados durante la fase de definicin !ariarn dependiendo del paradigma de ingeniera del software aplicado, de alguna forma se producirn tres pasos especficos# Anlisis del sistema. $efine el papel de cada elemento del sistema informtico, asignando finalmente al software el papel que !a a desempear. Planificacin del proyecto de software. %na !e& establecido el mbito del software, se anali&an los riesgos, se asignan los recursos, se estiman los costos, se definen las tareas y se planifica el trabajo. Anlisis de Requerimientos. El mbito establecido para el software proporciona la direccin a seguir, pero antes de comen&ar a trabajar es necesario disponer de una informacin mas detallada del mbito de informacin y de funcin del software. La fase de desarrollo se centra en el cmo. Esto es, durante esta fase. El que desarrolla el software intenta descubrir cmo 'an de disearse las estructuras de datos y la arquitectura del software, cmo 'an de implementarse los detalles procedimentales, cmo 'a de traducirse el diseo a un lenguaje de programacin y cmo 'a de reali&arse la prueba. Los mtodos aplicados durante la fase de desarrollo !aran, pero de alguna forma se aplicarn tres pasos concretos. D se*o de so+t#are. El diseo traduce los requisitos de software a un conjunto de representaciones (algunas grficas ) otras tabulares o basadas en lenguajes) que describen las estructuras de bases de datos, la arquitectura, el procedimiento algortmico y las caractersticas de la interfa&. Cod + !a! ,". Las representaciones del diseo debern ser traducidas a un lenguaje artificial (un lenguaje de programacin con!encional o un lenguaje no procedimental *+,), dando como resultado unas instrucciones ejecutables en la computadora. Pr-e$a del so+t#are. %na !e& que el software 'a sido implementado en una forma ejecutable por la maquina, debe ser probado para descubrir los defectos que puedan e istir, en la funcin, en la lgica y en la implementacin. La fase de mantenimiento se centra en el cambio que !a asociado a la correccin de errores, a las adaptaciones requeridas por la e!olucin del entorno del software y a las modificaciones debidas a los cambios de requisitos del usuario dirigidos a refor&ar o ampliar el sistema. La fase de mantenimiento !uel!e a aplicar las fases de definicin y de desarrollo, pero en el conte to del software ya e istente. $urante la fase de desarrollo se encuentran tres tipos de cambio # -orreccin. .ncluso lle!ando a cabo las mejores acti!idades de gara"ta de !al dad , es muy probable que el cliente descubra defectos en el software. El mantenimiento correcti!o cambia el software para corregir los defectos. "daptacin. -on el paso del tiempo es probable que cambie el entorno original (sistemas operati!os, equipos perifricos, etc.) para los que se desarrollo el software. El mantenimiento adapt!o consiste en modificar el
Desarrollo de Aplicaciones Web 1

software para acomodarlo a los cambios de su entorno e terno. /ejora. -onforme utilice el software, el usuario puede descubrir funciones adicionales que podran interesar que estu!ieran incorporadas en el software. El mantenimiento perfecti!o amplia el software mas all de sus requisitos funcionales originales. Las fases y pasos relacionados descritos en la !isin genrica de la ingeniera de software, se complementan con !arias acti!idades# Las re. s o"es que se reali&an durante cada paso para asegurar que se mantiene la !al dad. La documentacin que se desarrolla y controla para asegurar que toda la informacin sobre el sistema y el software estar disponible para un uso posterior. El control de cambios que se instituye de forma que los cambios puedan ser mejorados y registrados. La prueba de software es un elemento de un concepto ms amplio que, a menudo, se referencia como !erificacin y !alidacin. La !erificacin se refiere al conjunto de acti!idades que aseguran que el software implementa correctamente una funcin especfica. La !alidacin se refiere a un conjunto de acti!idades que aseguran que el software construido se ajusta a los requisitos del cliente. 0o'em lo establece de otra forma# /er + !a! ,"# /al da! ," # 1 Estamos construyendo el producto correctamente2 1 Estamos construyendo el producto correcto2

2.1.1 Espe! + !a! ," de Re0- s tos de So+t#are

En el proceso de desarrollo de un sistema, sea o no para la web, el equipo de desarrollo se enfrenta al problema de la identificacin de requisitos. La definicin de las 3ecesidades del sistema es un proceso complejo, pues en l 'ay que identificar los requisitos que el sistema debe cumplir para satisfacer las necesidades de los usuarios finales y de los clientes. 4ara reali&ar este proceso, no e iste una 5nica tcnica estandari&ada y estructurada que ofre&ca un marco de desarrollo que garantice la calidad del resultado. E iste en cambio un conjunto de tcnicas, cuyo uso proponen las diferentes metodologas para el desarrollo de aplicaciones web. 6e debe tener en cuenta que la seleccin de las tcnicas y el ito de los resultados que se obtengan, depende en gran medida tanto del equipo de anlisis y desarrollo, como de los propios clientes o usuarios que en ella participen. El proceso de especificacin de requisitos se puede di!idir en tres grandes acti!idades 78 captura de requisitos 98 definicin de requisitos :8 !alidacin de requisitos

2.1.2 Clas + !a! ," de Re0- s tos para apl !a! o"es WEB
El desarrollo de sistemas web agrupa una serie de caractersticas que lo 'acen diferente del desarrollo de otros sistemas. 4or un lado, 'ay que tener en cuenta que roles muy diferentes de desarrolladores participan en el proceso# analistas, clientes, usuarios, diseadores grficos, e pertos en multimedia y seguridad, etc. 4or otro lado, la e istencia en estos sistemas de una importante estructura de na!egacin obliga a un desarrollo preciso de este aspecto que garantice que el usuario no se ;pierde en el espacio na!egacional del sistema<. Estas ideas unidas al 'ec'o que los sistemas web suelen tratar con m5ltiples medios y es esencial que ofre&can una interfa& adecuada en cada momento, obligan a que estos aspectos propios de la web deban ser tratados de una forma especial en el proceso de desarrollo. Estas caractersticas especiales tambin 'ay que tenerlas en cuenta en la fase de especificacin de requisitos. 4or ello, la mayora de las propuestas estudiadas ofrecen diferentes clasificaciones de los requisitos. 4ara facilitar la comprensin de las metodologas presentarlas, se establece una clasificacin de requisitos rele!antes para apliaciones web. Requisitos de datos' tambin denominados requisitos de contenido, requisitos conceptuales o requisitos de almacenamiento de informacin. =stos requisitos responden a la pregunta de qu informacin debe almacenar y
Desarrollo de Aplicaciones Web 2

administrar el sistema. Requisitos de interfaz (al usuario), tambin llamados en algunas propuestas requisitos de interaccin o de usuario. >esponden a la pregunta de cmo !a a interactuar el usuario con el sistema. Requisitos navegacionales, recogen las necesidades de na!egacin del usuario. Requisitos de personalizacin , describen cmo debe adaptarse el sistema en funcin de qu usuario interact5e con l y de la descripcin actual de dic'o usuario. Requisitos transaccionales o funcionales internos, recogen qu debe 'acer el sistema de forma interna, sin incluir aspectos de interfa& o interaccin. *ambin son conocidos en el ambiente web como requisitos de ser!icios. Requisitos no funcionales, son por ejemplo los requisitos de portabilidad, de reutili&acin, de entorno de desarrollo, de usabilidad, de disponibilidad, etc.

2.1.1 Metodologas para la de+ " ! ," de Re0- s tos para apl !a! o"es WEB 2.1.1.1 WSDM2 We$ S te Des g" Met(od
?6$/ ($e *royer @ Leune, 7AAB) es una propuesta para el desarrollo de sitios web, en la que el sistema se define en base a los grupos de usuarios. 6u proceso de desarrollo se di!ide en cuatro fases# modelo de usuario, diseo conceptual, diseo de la implementacin e implementacin. La fase que ms repercusin tiene para este trabajo es la primera en la que intenta detectar los perfiles de usuarios para los cuales se construye la aplicacin. 4ara ello, se deben reali&ar dos tareas# -lasificacin de usuarios# en este paso se deben identificar y clasificar a los usuarios que !an a 'acer uso del sistema. 4ara ello, ?6$/ propone el estudio del entorno de la organi&acin donde se !aya a implantar el sistema y los procesos que se !ayan a generar, describiendo las relaciones entre usuarios y acti!idades que reali&an estos usuarios. 4ara la representacin grfica de estas relaciones ?6$/ propone una especie de mapas de conceptos de roles y acti!idades. $escripcin de los grupos de usuarios# en esta segunda etapa se describen con ms detalles los grupos de usuarios detectados en la etapa anterior. 4ara ello, se debe elaborar un diccionario de datos, en principio con formato libre, en el que indican los requisitos de almacenamiento de informacin, requisitos funcionales y de seguridad para cada grupo de usuarios. El resto de las fases del proceso de ?6$/ se 'acen en base a la clasificacin de usuarios que se reali&a en esta primera etapa.

2.1.1.2 SO3DM2 S!e"ar o-$ased O$4e!t-Or e"ted 3)per%ed a Des g" Met(odolog)
Esta propuesta (Lee, Lee @ Coo, 7AAD) presenta la necesidad de disponer de un proceso que permita capturar las necesidades del sistema. 4ara ello, propone el uso de escenarios. El proceso de definicin de requisitos parte de la reali&acin de un diagrama de conte to tal y como se propone en los diagramas de flujos de datos ($E$) de Courdon (7ADA). En este diagrama de conte to se identifican las entidades e ternas que se comunican con el sistema, as como los e!entos que pro!ocan esa comunicacin. La lista de e!entos es una tabla que indica en qu e!entos puede participar cada entidad. 4or cada e!ento diferente, 6FG$/ propone elaborar un escenario. =stos son representados grficamente mediante los denominados 6"-s9 (6cenario "cti!ity -'art). -ada escenario describe el proceso de interaccin entre el usuario y el sistema cuando se produce un e!ento determinado, especificando el flujo de acti!idades, los objetos in!olucrados y las transacciones reali&adas. 6FG$/ propone un proceso para conseguir a partir de estos escenarios el modelo conceptual del sistema, que es representado mediante un diagrama de clases. El proceso de 6FG$/ contin5a reagrupando estas clases para conseguir un modelo de clases na!egacionales del sistema.

2.1.1.1 RNA2 Relat o"s( p-Na.egat o"al A"al)s s

>3" (0ieber, ,alnares @ Lu, 7AAD) plantea una secuencia de pasos para el desarrollo de aplicaciones web, centrndose fundamentalmente en el flujo de trabajo de anlisis. El proceso de trabajo que presenta >3" se basa en la reali&acin de las siguientes fases#

Desarrollo de Aplicaciones Web

Ease 78 "nlisis del entorno# el propsito de esta fase es el de estudiar las caractersticas de la audiencia. -onsiste en determinar y clasificar a los usuarios finales de la aplicacin en grupos seg5n sus perfiles. Ease 98 Elementos de inters# en esta fase se listan todos los elementos de inters de la aplicacin. 4or elementos de inters se entienden los documentos, las pantallas que se !an a requerir, la informacin, etc. Ease :8 "nlisis del conocimiento# esta fase consiste en desarrollar un esquema que represente a la aplicacin. 4ara ello >3" propone identificar los objetos, los procesos y las operaciones que se !an a poder reali&ar en la aplicacin, as como las relaciones que se producen entre estos elementos. Ease +8 "nlisis de la na!egacin# en esta fase el esquema obtenido en la fase anterior es enriquecido con las posibilidades de na!egacin dentro de la aplicacin. Ease H8 .mplementacin del anlisis# una !e& obtenido el esquema final en el que ya se encuentran incluidos los aspectos de na!egacin, se pasa el esquema a un lenguaje entendible por la mquina. La propuesta de >3" resalta la necesidad de trabajar con la especificacin de requisitos, incluyendo tareas como el anlisis del entorno y de los elementos de inters. "dems, plantea la necesidad de anali&ar los requisitos conceptuales de manera independiente a los na!egacionales.

2.1.1.5 36PM2 3)per%ed a 6le7 $le Pro!ess Model "g

La propuesta de GE4/ (Flsina,7AAD) describe un proceso detallado que cubre todo el ciclo de !ida de un proyecto software. GE4/ propone un total de trece fases para las cuales se especifican a su !e& una serie de tareas. 4ara este estudio es principalmente rele!ante la primera fase, denominada de modelado de requisitos, cuyas tareas son las siguientes# $escripcin bre!e del problema. 3o indica ninguna tcnica concreta pudiendo reali&arse esta descripcin mediante el lenguaje natural. $escripcin de los requisitos funcionales mediante casos de uso. I >eali&ar un modelo de datos para esos casos de uso, proponiendo el uso de un modelo de clases. /odelar la interfa& de usuario. 4ara ello, propone el uso de sJetc'es y prototipos que permitan presentar los datos al usuario. /odelar los requisitos no funcionales. En stos incluyen la na!egacin, la seguridad, etc.

6e puede obser!ar que la propuesta de GE4/ ofrece mayor detalle a la 'ora de reali&ar el tratamiento de los requisitos. 6in embargo, no ofrece tcnicas concretas, especialmente a la 'ora de trabajar con los requisitos no funcionales.

2.1.1.8 OO3DM2 O$4e!t Or e"ted 3)per%ed a Des g" Model

FFG$/ es una propuesta metodolgica ampliamente aceptada para el desarrollo de aplicaciones de la web (6c'wabe @ >ossi, 7AAD). En sus comien&os no contemplaba la fase de captura y definicin de requisitos, pero actualmente propone el uso de %ser .nteraction $iagrams (%.$s) definidos por Kilain, 6c'wabe @ 6iecJenius (9LLL). Esta propuesta parte de los casos de uso, que considera una tcnica muy difundida, ampliamente aceptada y fcilmente entendible por los usuarios y clientes no e pertos, pero que resulta ambigua para el equipo de desarrollo en fases posteriores del ciclo de !ida. .gualmente, resalta la necesidad de empe&ar el diseo del sistema, especialmente en los entornos web, teniendo un claro y amplio conocimiento de las necesidades de interaccin, o lo que es lo mismo de la forma en la que el usuario !a a comunicarse con el sistema. FFG$/ propone que la comunicacin con el usuario se realice utili&ando los casos de uso y a partir de ellos los analistas elaboran los %.$s. Estos %.$s son modelos grficos que representan la interaccin entre el usuario y el sistema, sin considerar aspectos especficos de la interfa&. El proceso de transformacin de un caso de uso a un %.$s es descrito detalladamente en la propuesta. FFG$/ centra el desarrollo de un sistema de informacin web entorno al modelo conceptual de clases. Este diagrama debe surgir de los requisitos que se definan del sistema, pero los casos de uso resultan demasiado ambiguos para ello. "s, propone refinar el proceso de desarrollo descrito en %/L, de forma que de los casos de uso se generen los %.$s que concreticen ms la definicin de los requisitos para, a partir de ellos, obtener el diagrama conceptual. En algunos de los primeros trabajos, FFG$/ propone la descripcin de escenarios en forma te tual y grfica para cada tipo de usuario, como etapa pre!ia al diseo de la na!egacin.

Desarrollo de Aplicaciones Web

2.1.1.9 UWE2 UML-Based We$ E"g "eer "g

%/L80ased ?eb Engineering (%?E) es una propuesta metodolgica basada en el 4roceso %nificado (Macobson, 0ooc' @ >umbaug', 7AAA) y %/L para el desarrollo de aplicaciones web (GennicJer @ Noc', 9LLL, Noc', 9LL7). %?E cubre todo el ciclo de !ida de este tipo de aplicaciones, centrando adems su atencin en aplicaciones personali&adas (adapti!as). "l anali&ar la propuesta de captura de requisitos de %?E. Esta metodologa distingue entre la tarea de licitar requisitos, definir y !alidar los requisitos. El resultado final de la captura de requisitos en %?E es un modelo de casos de uso acompaado de documentacin que describe los usuarios del sistema, las reglas de adaptacin, los casos de uso y la interfa&. %?E clasifica los requisitos en dos grandes grupos# funcionales y no funcionales. Los requisitos funcionales tratados por %?E son# I I I I I requisitos relacionados con el contenido requisitos relacionados con la estructura requisitos relacionados con la presentacin requisitos relacionados con la adaptacin requisitos relacionados con los usuarios

"dems, %?E propone como tcnicas apropiadas para la captura de los requisitos de un sistema web las entre!istas, los cuestionarios y los c'ecJlists y los casos de uso, los escenarios y el glosario para la definicin de requisitos. 4ara la !alidacin propone walJ8t'roug's, auditoras y prototipos..

2.1.1.: W2;;;
?9LLL (0aresi, ,ar&otto @ 4aolini, 9LL7) supone una propuesta que ampla la notacin de %/L con conceptos para modelar elementos de multimedia 'eredados de la propuesta G$/ (Gypermedia $esign /odel) (,ar&otto, 6c'wabe @ 4aolini, 7AA:). El proceso de desarrollo de ?9LLL se di!ide en tres etapas# anlisis de requisitos, diseo de 'ipermedia y diseo funcional. El primero de ellos es el que resulta interesante para este trabajo. La especificacin de requisitos en ?9LLL se di!ide en dos sub8acti!idades# anlisis de requisitos funcionales y anlisis de requisitos na!egacionales. La especificacin de requisitos comien&a 'aciendo un estudio de los diferentes roles de usuario que !an a interactuar con el sistema. -ada actor potencialmente distinto tendr su modelo de requisitos de na!egacin y de requisitos funcionales. El modelo de requisitos funcionales es representado como un modelo de casos de uso tal y como se propone en %/L. En l se representa la funcionalidad principal asociada a cada rol y las interacciones que se producen entre el sistema y cada rol. El segundo modelo consiste en otro diagrama de casos de uso pero que no representa funcionalidad sino posibilidades de na!egacin de cada actor. La representacin grfica es reali&ada con una e tensin de %/L.

2.1.1.< UWA2 U$ 0- t-os We$ Appl !at o"s

%?" 'a nacido de la colaboracin entre diferentes grupos de trabajo, por lo que resulta realmente una agrupacin de propuestas y tcnicas. En concreto, la propuesta de ?9LLL se encuentra incluida en %?". 6in embargo, ?9LLL 'a sido incluida en %?" slo en la fase de diseo 'ipermedia, siendo ambas propuestas diferentes en la fase de definicin de requisitos. El proceso de captura de requisitos en %?" (%wa >equirements Elicitation, 9LL7) comien&a definiendo los diferentes roles de usuario que pueden interactuar con el sistema, los objeti!os globales de ste y la relacin entre ellos. El proceso contin5a 'aciendo un refinamiento de esos objeti!os globales, concretndolos en subobjeti!os. Estos subobjeti!os son estudiados y refinados para detectar conflictos entre ellos. $e esta forma, se concreti&an a5n ms di!idindolos en requisitos. Los requisitos son clasificados en !arios tipos# de contenido, de estructura de contenido, de acceso, de na!egacin, de presentacin, de operaciones de usuario y de operaciones del sistema. $e esta forma, los requisitos se !an refinando 'asta que solo pertene&can a uno de estos grupos. C finalmente los requerimientos son asignados a artefactos de diseo o a reglas de customi&acin.

Desarrollo de Aplicaciones Web

4ara definir los objeti!os, %?" propone una notacin propia, basada en una plantilla. La definicin de los actores y la relacin con los objeti!os se 'ace usando un diagrama basado en casos de uso. 4or 5ltimo, para definir y refinar los subobjeti!os y los requisitos, utili&an una notacin grfica propia que denominan grafo de refinamiento de objetivos , el refinamiento de este grafo permite ir representando la relacin entre los requisitos y 'acer un seguimiento para !alidar la consecucin de los objeti!os del sistema. %na !e& que los requisitos son detectados, 'acen uso de O/L para definirlos de una manera formal.

2.1.1.= ND> - Na. gat o"al De.elop%e"t >e!(" 0-es

3$* (3a!igational $e!elopment *ec'niques) (Escalona, *orres @ /ejas, 9LL9) es una tcnica para especificar, anali&ar y disear el aspecto de la na!egacin en aplicaciones web. 4ara este trabajo, solo es rele!ante la propuesta que ofrece para la definicin y captura de requisitos. El flujo de especificacin de requisitos de 3$* comien&a con la fase de captura de requisitos y estudio del entorno. 4ara ello, plantea el uso de tcnicas como las entre!istas o el brainstorming y M"$. *ras esta fase, se propone la definicin de los objeti!os del sistema. En base a estos objeti!os, el proceso contin5a definiendo los requisitos que el sistema debe cumplir para cubrir los objeti!os marcados. 3$* clasifica los requisitos en# 7. >equisitos de almacenamiento de informacin. 9. >equisitos de actores. :. >equisitos funcionales. +. >equisitos de interaccin, representados mediante# Erases, que recogen cmo se !a a recuperar la informacin del sistema utili&ando un lenguaje especial denominado 03L (0ounded 3atural Language) (0risaboa, 4enabad, 4laces @ >odrgue&, 9LL7). 4rototipos de !isuali&acin, que representan la na!egacin del sistema, la !isuali&acin de los datos y la interaccin con el usuario. H. >equisitos no funcionales *odo el proceso de definicin y captura de requisitos y objeti!os que propone 3$* se basa principalmente en plantillas o patrones, pero tambin 'ace uso de otras tcnicas de definicin de requisitos como son los casos de uso y los glosarios. La propuesta ofrece una plantilla para cada tipo de requisito, lo que permite describir los requisitos y objeti!os de una forma estructurada y detallada. "lgunos de los campos de los patrones son cerrados, es decir, solo pueden tomar !alores predeterminados. Estos campos permiten que en el resto del proceso del ciclo de !ida de 3$* se puedan conseguir resultados de forma sistemtica. El flujo de trabajo de especificacin de requisitos termina proponiendo la re!isin del catlogo de requisitos y el desarrollo de una matri& de tra&abilidad que permite e!aluar si todos los objeti!os 'an sido cubiertos en la especificacin. La propuesta !iene acompaada de una 'erramienta case, 3$*8*ool, que facilita la complementacin de los patrones y que permite automati&ar el proceso de consecucin de resultados.

2.1.1.1; Des g"-dr .e" Re0- re%e"ts El ! tat o" ?DDRE@

$esign8dri!en >equirements Elicitation es parte del proceso design8dri!en que proponen Lowe y EJlund (9LL9) para el desarrollo de aplicaciones en el entorno ?eb. La propuesta consiste en reali&ar la captura, definicin y !alidacin de requisitos durante el proceso de diseo. Ello 'ace necesario que las acti!idades de diseo sean reali&adas de modo que los requerimientos pueden ser tratados y administrados. El proceso se basa en el uso de prototipos para ayudar al cliente en la e ploracin de las posibles soluciones y de los problemas que tienen que ser resueltos. Los usuarios o clientes definen sus requerimientos
Desarrollo de Aplicaciones Web 6

basndose en la obser!acin o trabajo con estos prototipos. Es un proceso iterati!o que consiste en reducir la incertidumbre del cliente. El ciclo tiene tres fases# e!aluacin, especificacin y construccin. Este proceso fue definido sobre la base de un e 'austi!o anlisis de ;best practices< en el desarrollo de aplicaciones comerciales para el entorno ?eb. Esta metodologa trata a todos los requisitos de la misma maneraP estos requisitos son# de contenido, de protocolo de interfaces, de estructura na!egacional, de ;looJ and feel<, de representacin interna de datos, de !ersionamiento, de control de cambios, de seguridad, de gestin de contenido, de acceso de control, de eficiencia, de monitoreo del usuario, de soporte de funcionalidad, de adaptacin del sistema, de identificacin del usuario y sus derec'os de acceso, etc.

2.1.2 Co%para! ," de >&!" !as

En base a la clasificacin de requisitos que se defini, para las tcnicas enunciadas se presentan los tipos de requisitos que contempla cada propuesta. En la siguiente tabla se presentan los diferentes requisitos y se indica cules de ellos son tratados en cada metodologa.

>ECNICA
WSDM SO3DM RNA 36PM OO3DM UWE W2;;; UWA ND> DDRE

Re0. Datos

Re0. I"ter+aA al -s-ar o

Re0. Na.ega! o"ales

Re0. Perso"al Aa! ,"

Re0. tra"sa!! o"ales

Re0. No +-"! o"ales

2.2 Ar0- te!t-ra de las apl !a! o"es #e$

El ??? (world wide web) la telaraa mundial, es un ser!icio que se basa en la arquitectura cliente8ser!idor, donde el ser!idor es un proceso que opera en el bacJground de un ser!idor multiusuario frecuentemente es %3.O, y el cliente es un programa que opera en la computadora del usuario. El cliente solicita documentos al ser!idor, que escuc'a por requisiciones en el lenguaje G**4 ( !per"e#t "ransfer $rotoco) normalmente desde el puerto DL del *-4. El ser!idor, que puede estar locali&ado en cualquier parte del mundo, entrega al cliente documentos usualmente formateados en un lenguaje de descripcin de pgina deri!ado del 6,/L, denominado G*/L ( !per"e#t %ar&up 'anguage)( I"te%et es un conjunto de redes comunicadas entre s, operada cooperati!amente por di!ersas organi&aciones (comerciales, acadmicas, pri!adas, de los gobiernos), utili&ando un esquema com5n para el intercambio de informacin. .ntemet est conectada !a compuertas a otros ser!icios comerciales (64.3, -ompuser!e, "merica FnLine, etc.), as como a otras redes (0itnet, %%-4, Eidonet). El tipo de informacin que puede acceder en .ntemet, depende del tipo de 'erramienta o interface que usted est usando. 4uede utili&ar 'erramientas con interface de te to o grfica. "lgunas interfaces le dan tambin acceso a !arios recursos. "lgunas otras, slo le dan acceso a informacin en un formato particular.

2.1 Le"g-a4es de progra%a! ," de lado del !l e"te.

En realidad el G*/L no es un lenguaje de programacin sino, ms bien, se trata de un lenguaje descripti!o que tiene como objeto dar formato al te to y las imgenes que pretendemos !isuali&ar en el na!egador. " partir de este lenguaje somos capaces de introducir enlaces, seleccionar el tamao de las fuentes o intercalar
Desarrollo de Aplicaciones Web )

imgenes, todo esto de una manera prefijada y en ning5n caso inteligente. En efecto, el G*/L no permite el reali&ar un simple clculo matemtico o crear una pgina de la nada a partir de una base de datos. " decir !erdad, el G*/L, aunque muy 5til a pequea escala, resulta bastante limitado a la 'ora de concebir grandes sitios o portales. Es esta deficiencia del G*/L la que 'a 'ec'o necesario el empleo de otros lenguajes accesorios muc'o ms !erstiles y de un aprendi&aje relati!amente ms complicado, capaces de responder de manera inteligente a las demandas del na!egador y que permiten la automati&acin de determinadas tareas tediosas e irremediables como pueden ser las actuali&aciones, el tratamiento de pedidos de una tienda !irtual. Estos lenguajes capaces de recrear a partir de ciertos QscriptsQ un sinfn de pginas automati&adas son los protagonistas de este concepto de pBg "as d "B% !as. %na pgina dinmica contiene embebido cdigo de alg5n lenguaje de programacin. E isten dos tipos de lenguajes de programacin para generar pginas dinmicas# lenguajes del lado del cliente y lenguajes del lado del ser!idor. El cdigo de un lenguaje de programacin del lado del cliente es procesado por el 3a!egador (browser). Lenguajes de programacin del lado del cliente son Ma!ascript y Kisual 0asic 6cript (K06cript). El cdigo de un lenguaje de programacin del lado del ser!idor es procesado por el ser!idor web. Los ser!idores web interpretan este cdigo generando cdigo G*/L QpuroQ, el cual es en!iado al cliente web. El uso ms frecuente de las pginas del lado del ser!idor es para reali&ar consultas a bases de datos. Lenguajes de programacin del lado del ser!idor son -,. 8 -ommon ,ateway .nterface (com5nmente escritos en 4erl), "46 8 "cti!e 6er!er 4ages ("64), 4G4 8 Giperte t 4repocesor (4G4) y M64 8 Ma!a 6er!er 4ages (M64). F interpretes de lenguajes de propsito general como en el caso de Ma!a (*omcat) y -old Eusion que tiene su propio lenguaje y que finalmente se traduce a Ma!a y luego en G*/L. " continuacin definiremos lo lenguajes mas populares desarrollados del lado del cliente.

2.1.1 Ca.a S!r pt

Es un lenguaje interpretado que permite incluir macros en pginas ?eb. Estas macros se ejecutan en el cliente, y no en el ser!idor. Ma!a6cript proporciona los medios para# -ontrolar las !entanas del na!egador y el contenido que muestran, programar pginas dinmicas simples, e!itar depender del ser!idor ?eb para clculos sencillos, capturar los e!entos generados por el usuario y responder a ellos sin salir a .nternet, simular el comportamiento de las macros -,. cuando no es posible usarlas, comprobar los datos que el usuario introduce en un formulario antes de en!iarlos, comunicarse con el usuario mediante di!ersos mtodos. La caracterstica de Ma!a6cript que ms simplifica la programacin es que, aunque el lenguaje soporta cuatro tipos de datos, no es necesario declarar el tipo de las !ariables, argumentos de funciones ni !alores de retorno de las funciones. El tipo de las !ariables cambia implcitamente cuando es necesario, lo que dificulta el desarrollo de programas complejos, pero ayuda a programar con rapide& macros sencillas. En esto, Ma!a6cript se separa totalmente de lenguajes como -, -RR o Ma!a. Ma!a6cript 'a sido in!entado por 3etscape, que comen& a ofrecerlo como parte de su 3a!igator !.9.L. El nombre original de Ma!a6cript fue Li!e6cript, pero se modific en el 5ltimo momento, aparentemente para apro!ec'ar el tirn de M"K". "l ser cdigo interpretado, Ma!a6cript es ms lento que Ma!a, pero en la prctica no suele ser un factor de importancia. El objeti!o de 3etscape al introducir Ma!a6cript es tratar de establecer un estndar de programacin de macros ejecutables en el na!egador ?eb, que de ser adoptado por los ?ebmasters, facilitara la implantacin de los na!egadores de 3etscape en el mercado. En respuesta a este reto, /icro6oft soporta una !ersin parcial de Ma!a6cript, con el nombre de M6cript, en su .nternet E plorer. El primer incon!eniente de este estado de cosas es que las macros Ma!a6cript slo se ejecutan con normalidad en na!egadores 3etscape, por lo que el ?ebmaster es responsable de configurar la pgina para que pueda !erse decentemente en un na!egador que no sea 3etscape. %na solucin sera utili&ar en nuestras macros el subconjunto de funciones comunes a Ma!a6cript y M6cript, para soportar los na!egadores 3etscape y /icro6oft, pero esta solucin nos obligara a renunciar a muc'as de la s caracter*sticas del lenguaje( 9.:.9 /BS!r pt "bre!iatura de Visual asic !cript "dition, es un lenguaje interpretado por el ?indows 6cripting Gost de /icrosoft. 6u sinta is refleja su origen como !ariacin del lenguaje de programacin Kisual 0asic. Ga logrado un apoyo
Desarrollo de Aplicaciones Web +

significati!o por parte de los administradores de ?indows como 'erramienta de automati&acin, ya que, conjunta y paralelamente a las mejoras introducidas en los sistemas operati!os windows donde opera fundamentalmente, permite ms margen de actuacin y fle ibilidad que el lenguaje batc, (o de proceso por lotes) desarrollado a finales de los aos 7ABL para el /68$F6. El crecimiento del uso de las tecnologas de internet 'a supuesto un significati!o a!ance para este lenguaje, dado que es parte fundamental de la ejecucin de aplicaciones de ser!idor programadas en "64 (Active -erver $ages), las cuales estn en auge en el perodo 7AAB89LL:, declinando actualmente en fa!or de tecnologas de cdigo gestionado y mquinas !irtuales, ms seguras en la ejecucin de procesos, y por tanto, ms adaptadas para ejecuciones en entornos p5blicamente accesibles y distribuidos. /icrosoft 'a intentado competir mediante esta tecnologa tambin en entornos de cliente, donde el lenguaje ms utili&ado es Ma!ascript o su !ersin estandari&ada E-/"6cript, sin ito. "ctualmente microsoft no 'a puesto a disposicin p5blica nue!as !ersiones del lenguaje, en fa!or de la tecnologa .3E* en la que se incluye el lenguaje 'ermano Kisual 0asic, dentro del entorno de ejecucin de la plataforma .3E* (-L>, o .ommon 'anguage /untime). 6in embargo sigue siendo muy 5til en gestin de estaciones de trabajo y ser!idores en windows. K06cript es interpretado por el motor de scripting !bscript.dll, que puede ser in!ocado por el motor "64 asp.dll en un entorno web, por wscript.e e en un entorno ?indows de interfase grfica y por cscript.e e es un entorno de lnea de comandos. -uando el cdigo fuente K06cript se guarda en fic'eros independientes, stos tienen tpicamente la e tensin .!bs. -uando se emplea en .nternet E plorer, K06cript funciona de forma muy similar a Ma!a6cript, procesando cdigo contenido en el documento G*/L. K06cript tambin puede usarse para crear aplicaciones G*/L independientes (e tensin .hta), que necesitan .nternet E plorer H.L o superior para poder ser ejecutados. Los desarrolladores de aplicaciones en web suelen preferir Ma!a6cript debido a su mayor compatibilidad con otros na!egadores de .nternet, ya que K06cript slo est disponible para el na!egador de /icrosoft .nternet E plorer. /BS!r pt es el lenguaje usado para escribir algunos famosos gusanos de red, como 0 'ove 1ou. Esto se debe a !arias ra&ones. 4rimero, el icono parecido a un pergamino que representa a los fic'eros .vbs puede lle!ar a pensar a los usuarios ine pertos que se trata de un fic'ero de te to. 6egundo, es fcil escribir un gusano informtico en K06cript que se propague por correo electrnico (se necesitan pocas lneas de cdigo). /icrosoft 'a solucionado los agujeros de seguridad e plotados por dic'os programas maliciosos. DE-& es Opt o" E7pl ! tF Fption E plicit es una sentencia optati!a pero recomendada que se ingresa al principio del cdigo "64 (K06cript) de cada pgina. Las !ariables en "64 no necesitan ser declaradas para usarlas, pero es una buena costumbre 'acerlo. Fption E plicit sir!e para que las !ariables deban ser declaradas si o si. "l no declarar las !ariables se deja el cdigo a libre albedro del 6er!idor. "l declarar las !ariables se $eja de /anera E plicita la 5nica manera de proceder. 2.1.1 / s-al Bas ! .NE> (/B.NE> ) es un lenguaje de programacin orientado a objetos que se puede considerar una e!olucin de Kisual 0asic implementada sobre el frameworJ .3E*. 6u introduccin result muy contro!ertida, ya que debido a cambios significati!os en el lenguaje K0.3E* no es compatible 'acia atrs con Kisual 0asic, cosa que caus gran di!isin en la comunidad de desarrolladores de Kisual 0asic. La gran mayora de programadores de K0.3E* utili&an el entorno de programacin /icrosoft Kisual 6tudio .3et en alguna de sus !ersiones (Kisual 6tudio .3E*, Kisual 6tudio .3E* 9LL: o Kisual 6tudio .3E* 9LLH), aunque e isten otras alternati!as, como 6'arp$e!elop (que adems es libre). -omo pasa con todos los lenguajes de programacin basados en .3E*, los programas escritos en K0.3E* requieren el ErameworJ .3E* para ejecutarse.

2.5 Le"g-a4es de progra%a! ," de lado del ser. dor

E iste una multitud de lenguajes concebidos o no para .nternet. -ada uno de ellos e plota ms a fondo ciertas caractersticas que lo 'acen ms o menos 5tiles para desarrollar distintas aplicaciones. La !ersatilidad de un lenguaje est ntimamente relacionada con su complejidad. %n lenguaje complicado en su aprendi&aje permite en general el reali&ar un espectro de tareas ms amplio y ms profundamente. Es por ello que a la 'ora de elegir el lenguaje que queremos utili&ar tenemos que saber claramente qu es lo que queremos 'acer y si el lenguaje en cuestin nos lo permite o no.
Desarrollo de Aplicaciones Web 2

En el dominio de la red, los lenguajes de lado ser!idor ms ampliamente utili&ados para el desarrollo de pginas dinmicas son el "64, 4G4 y 4E>L. El ASP ("cti!e 6er!er 4ages) es un lenguaje deri!ado del Kisual 0asic desarrollado por /icrosoft. E!identemente su empleo se reali&a sobre plataformas funcionando bajo sistema ?indows 3*. El P3P podra ser considerado como el lenguaje anlogo al "64 utili&ado en plataformas %ni y Linu . Estos dos lenguajes resultan bastante 5tiles para la e plotacin de bases de datos y su aprendi&aje resulta accesible para una persona profana de la programacin. -ualquiera de ellos resultara la opcin ideal a la 'ora de 'acer e!olucionar un sitio web reali&ado en G*/L. 4or otra parte, el PERL es un lenguaje ms rpido y potente que requiere ob!iamente un aprendi&aje ms largo y resulta ms reser!ado para personas ya familiari&adas con la !erdadera programacin. E7te"s o"es2 para escribir una pgina dinmica que pueda ser reconocida posteriormente por el ser!idor 'ttp, es necesario establecer una e tensin. "s, por ejemplo, las pginas de "64 son reconocidas por su e tensin QaspQ del mismo modo que las de 4G4 lo son a partir de e tensiones Qp'pQ u otras en las que se especifica la !ersin utili&ada (Qp'p:Q o Qp'p+Q). 2.5.1 A!t .e Ser.er Pages (ASP) Es una tecnologa del lado ser!idor de /icrosoft para pginas web generadas dinmicamente, que 'a sido comerciali&ada como un ane o a .nternet .nformation 6er!er (..6). La tecnologa "64 est estrec'amente relacionada con el modelo tecnolgico de su fabricante. .ntenta ser solucin para un modelo de programacin rpida ya que programar en "64 es como programar en Kisual0asic, por supuesto con muc'as limitaciones ya que es una plataforma que no se 'a desarrollado como lo esperaba /icrosoft. Lo interesante de este modelo tecnolgico es poder utili&ar di!ersos componentes ya desarrollados como algunos controles "cti!eO. Ftros problemas que 'an 'ec'o e!olucionar esta tecnologa es el no disponer de informacin Qque oriente a quienes desean aprenderla y resulta muy costosa en tiempo descubrir aqu y all toda la informacin para !ol!erla altamente 5tilQ. "64 'a pasado por cuatro iteraciones mayores, "64 7.L (distribuido con ..6 :.L), "64 9.L (distribuido con ..6 +.L), "64 :.L (distribuido con ..6 H.L) y "64.3E* (parte de la plataforma .3E* de /icrosoft). Las !ersiones pre8.3E* se denominan actualmente (desde 9LL9) como "64 cl3sico. En el 5ltimo "64 clsico, "64 :.L, 'ay seis objetos integrados disponibles para el programador, "pplication, "64Error, >equest, >esponse, 6er!er y 6ession. -ada objeto tiene un grupo de funcionalidades frecuentemente usadas y 5tiles para crear pginas web dinmicas. Las pginas pueden ser generadas me&clando cdigo de scripts del lado del ser!idor (incluyendo acceso a base de datos) con G*/L. 2.5.2 A!t .e Ser.er Pages (P3P) P3P es un lenguaje de programacin usado frecuentemente para la creacin de contenido para sitios web con los cuales se puede programar las paginas 'tml y los codigos de fuente. 4G4 es un acrnimo recursi!o que significa QPG4 3yperte t Pre8processorQ (inicialmente 4G4 *ools, o, $ersonal ome $age *ools), y se trata de un lenguaje interpretado usado para la creacin de aplicaciones para ser!idores, o creacin de contenido dinmico para sitios web. Sltimamente tambin para la creacin de otro tipo de programas incluyendo aplicaciones con interfa& grfica usando las libreras Tt o ,*NR. El +B! l uso y la similitud con los lenguajes ms comunes de programacin estructurada, como - y 4erl, permiten a la mayora de los programadores e perimentados crear aplicaciones complejas con una cur!a de aprendi&aje muy sua!e. *ambin les permite in!olucrarse con aplicaciones de contenido dinmico sin tener que aprender todo un nue!o grupo de funciones y prcticas. $ebido al diseo de 4G4, tambin es posible crear aplicaciones con una interfa& grfica para el usuario (tambin llamada ,%.), utili&ando la e tensin 4G48Tt o 4G48,*N. *ambin puede ser usado desde la lnea de rdenes, de la misma manera como 4erl o 4yt'on pueden 'acerlo, esta !ersin de 4G4 se llama 4G4 -L. ( .ommand 'ine 0nterface).

Desarrollo de Aplicaciones Web

14

6u interpretacin y ejecucin se da en el ser!idor web, en el cual se encuentra almacenado el script, y el cliente slo recibe el resultado de la ejecucin. -uando el cliente 'ace una peticin al ser!idor para que le en!e una pgina web, generada por un script 4G4, el ser!idor ejecuta el intrprete de 4G4, el cual procesa el script solicitado que generar el contenido de manera dinmica, pudiendo modificar el contenido a en!iar, y regresa el resultado al ser!idor, el cual se encarga de regresrselo al cliente. "dems es posible utili&ar 4G4 para generar arc'i!os 4$E, Elas', as como imgenes en diferentes formatos, entre otras cosas. 4ermite la cone in a diferentes tipos de ser!idores de bases de datos tales como /y6TL, 4ostgres, Fracle, F$0-, $09, /icrosoft 6TL 6er!er, Eirebird y 6TLiteP lo cual permite la creacin de "plicaciones web muy robustas. 4G4 tambin tiene la capacidad de ser ejecutado en la mayora de los sistemas operati!os tales como %3.O (y de ese tipo, como Linu o /ac F6 O) y ?indows, y puede interactuar con los ser!idores de web ms populares ya que e iste en !ersin -,., mdulo para "pac'e, e .6"4.. El modelo 4G4 puede ser !isto como una alternati!a al sistema de /icrosoft que utili&a "64.3E*U-VUK0.3E*, a -oldEusion de la compaa "dobe (antes /acromedia), , a M64UMa!a de 6un /icrosystems, y al famoso -,.U4erl. "unque su creacin y desarrollo se da en el mbito de los sistemas libres, bajo la licencia ,3%, e iste adems un .$E (entorno integrado de desarrollo) comercial llamado Wend Fptimi&er. >ecientemente, -ode,ear (la di!isin de lenguajes de programacin de 0orland) 'a sacado al mercado un entorno integrado de programacin para 4G4, denominado $elp'i for 4G4. 3 stor a 4G4 fue originalmente diseado en 4erl, seguidos por la escritura de un grupo de -,. binarios escritos en el lenguaje - por el programador dans8canadiense >asmus Lerdorf en el ao 7AA+ para mostrar su currculum !itae y guardar ciertos datos, como la cantidad de trfico que su pgina web reciba. El D de junio de 7AAH fue publicado QPersonal 3ome Page *oolsQ despus de que Lerdorf lo combinara con su propio 5orm 0nterpreter para crear 4G4UE.. 2.5.1 P3P $os programadores israeles del *ec'nion, Wee! 6urasJi y "ndi ,utmans, reescribieron el anali&ador sintctico (parser en ingls) en el ao 7AAB y crearon la base del 4G4:, cambiando el nombre del lenguaje a la forma actual. .nmediatamente comen&aron e perimentaciones p5blicas de 4G4: y fue publicado oficialmente en junio del 7AAD. 4ara 7AAA, 6urasJi y ,utmans reescribieron el cdigo de 4G4, produciendo lo que 'oy se conoce como Wend Engine o motor Wend, un portmanteau de los nombres de ambos, Wee! y "ndi. *ambin fundaron Wend *ec'nologies en >amat ,an, .srael. P3P 5 En mayo de 9LLL 4G4 + fue lan&ado bajo el poder del motor Wend Engine 7.L. La 5ltima !ersin de 4G4 + disponible en febrero de 9LLB es la +.+.B. 4'p.net anuncio el da 7: de Mulio de 9LLB que la !ersin + de 4G4 qued discontinuada. P3P 8 El 7: de julio de 9LL+, fue lan&ado 4G4 H, utili&ando el motor Wend Engine .. (o Wend Engine 9). La !ersin ms reciente de 4G4 es la H.9.+ :L de agosto de 9LLB), que incluye todas las !entajas que pro!ee el nue!o Wend Engine 9 como# 6oporte slido y >E"L para 4rogramacin Frientada a Fbjetos ( o FF4) con 4G4 $ata Fbjects. /ejoras de rendimiento. /ejor soporte para /y6TL con e tensin completamente reescrita. /ejor soporte a O/L ( O4at', $F/... ). 6oporte nati!o para 6TLite. 6oporte integrado para 6F"4. .teradores de datos. E cepciones de errores. P3P 9 Est pre!isto el lan&amiento en bre!e de la rama X de 4G4, cuando se lance esta nue!a !ersin, quedarn solo dos ramas acti!as en desarrollo (4G4 H y X) pues se 'a comunicado que 4G4 + 'a sido discontinuado desde el 7: de
Desarrollo de Aplicaciones Web 11

Mulio de 9LLB. Las diferencias que encontraremos frente a 4G4 H.Y son# 6oportar %nicode Limpie&a de funcionalidades obsoletas como register6globals , safe6mode ... 4E-L /ejoras en orientacin a objetos Los principales usos del 4G4 son los siguientes# 4rogramacin de pginas web dinmicas, 'abitualmente en combinacin con el motor de base datos /y6TL, aunque cuenta con soporte nati!o para otros motores, incluyendo el estndar F$0-, lo que ampla en gran medida sus posibilidades de cone in. 4rogramacin en consola, al estilo de 4erl o 6'ell scripting. -reacin de aplicaciones grficas independientes del na!egador, por medio de la combinacin de 4G4 y TtU,*NR, lo que permite desarrollar aplicaciones de escritorio en los sistemas operati!os en los que est soportado.

/e"ta4as de P3P Es un lenguaje multiplataforma. -apacidad de cone in con la mayora de los manejadores de base de datos que se utili&an en la actualidad, destaca su conecti!idad con /y6TL Leer y manipular datos desde di!ersas fuentes, incluyendo datos que pueden ingresar los usuarios desde formularios G*/L. -apacidad de e pandir su potencial utili&ando la enorme cantidad de mdulos (llamados e tZs o e tensiones). 4osee una amplia documentacin en su pgina oficial ( [7\), entre la cual se destaca que todas las funciones del sistema estn e plicadas y ejemplificadas en un 5nico arc'i!o de ayuda. Es libre, por lo que se presenta como una alternati!a de fcil acceso para todos. 4ermite las tcnicas de 4rogramacin Frientada a Fbjetos. 4ermite crear los formularios para la web. 0iblioteca nati!a de funciones sumamente amplia e incluida 3o requiere definicin de tipos de !ariables ni manejo detallado del bajo ni!el. E4e%plo de C,d go P3P " continuacin un ejemplo de una pgina web sencilla desarrollada utili&ando el lenguaje 4G4 (con coloreado de sinta is)# ]'tml^ ]'ead^ ]title^Ejemplo]Utitle^ ]U'ead^ ]body^ GFp(p if (isset(_`4F6*[ZmuestraZ\)) a ec'o ZGola, Z.'tmlentities(_`4F6*[ZnombreZ\) .Z, tu comida fa!orita es#Z. 'tmlentities(_`4F6*[ZcomidaZ\)P b else a FH ]form met'odcQ4F6*Q actioncQ2Q^ 1-ul es tu nombre2 ]input typecQte tQ namecQnombreQ^ 1-ul es tu comida fa!orita2 ]select namecQcomidaQ^ ]option^6paguetis]Uoption^
Desarrollo de Aplicaciones Web 12

]option^"sado]Uoption^ ]option^4i&&a]Uoption^ ]Uselect^ ]input typecQsubmitQ namecQmuestraQ !aluecQ6eguirQ^ ]Uform^ GFp(p b FH ]Ubody^ ]U'tml^ En este cdigo es posible obser!ar las siguientes caractersticas# Las !ariables en!iadas por un formulario utili&ando el mtodo 4F6*, son recibidas en el lenguaje dentro de la matri& _`4F6*, lo cual facilita la obtencin de este tipo de datos. Este mismo mtodo es utili&ado por el lenguaje para todas las fuentes de informacin en una aplicacin web, tales como cooJies en la matri& _`-FFN.E6, !ariables de %>L en _`,E* (que en formularios puede ser!ir para guardar los datos), !ariables de sesin utili&ando _`6E66.F3, y !ariables del ser!idor y del cliente por medio de la matri& _`6E>KE>. El cdigo 4G4 est incrustado dentro del G*/L e interact5a con el mismo, lo que permite disear la pgina ?eb en un editor com5n de G*/L y aadir el cdigo dinmico dentro de las etiquetas ]2 p'p 2^. El resultado muestra y oculta ciertas porciones del cdigo G*/L en forma condicional. Es posible utili&ar funciones propias del lenguaje para aplicaciones ?eb como 'tmlentitites(), que con!ierte los caracteres que tienen alg5n significado especial en el cdigo G*/L o que podran desplegarse errneamente en el na!egador como acentos o diresis, en sus equi!alentes en formato G*/L..

2.5.1 S!r pts del lado del Ser. dor. Los primeros ser!idores web permitan !isuali&ar e clusi!amente informacin esttica (pginas estticas). Esto represent bien pronto una limitacinP sobre todo desde el momento en el que la acti!idad publicitaria y comercial comen& a concentrarse tambin en la red .nternet. La primera solucin tcnica reali&ada fue la posibilidad que el ser!idor web lan&ase programas residentes en la mquina de ser!icio. Esta tecnologa, conocida como -ommon ,ateway .nterface (-,.) permite al ser!idor web lan&ar programas escritos principalmente en - o en 4erl. 6i bien la tecnologa -,. resol!a el problema de la presentacin e clusi!amente esttica de la informacin, al mismo tiempo presentaba dos limitaciones importantes# una era el problema de seguridad que poda representar el 'ec'o que mediante la llamada a una pgina se pueda ejecutar programas indeseados en el ser!idor, la segunda era de carga del ser!idor (si una misma pgina que lan&aba un programa era llamada desde 7LL clientes concurrentemente, en el ser!idor se ejecutaban 7LL procesos, uno por cada cliente que solicitaba esa pgina). 4ara resol!er estos problemas, se busc desarrollar una tecnologa que permitiera ejecutar, en un 5nico proceso del ser!idor, todos los pedidos de ejecucin de cdigo del ser!idor web sin importar la cantidad de clientes que se conectaban concurrentemente. Esta solucin, denominada ser!let en tecnologa Ma!a o filtro .6"4. en tecnologa /icrosoft, permite el poder ejecutar cdigo en un 5nico proceso e terno que gestiona todas las llamadas reali&adas por el ser!idor web, impidiendo al mismo tiempo que el ser!idor web pueda llamar a ejecutar programas del sistema operati!o. 3o obstante de este modo se limitan los problemas de prestacin y seguridad de la tecnologa -,., no se resuel!e el problema representado por un desarrollo demasiado costoso en trminos de tiempo. "simismo, 'ace necesario que dos figuras profesionales bien distintas trabajen en un 5nico proyecto# el programador (que conoce bien el lenguaje de programacin del lado del ser!idor utili&ado) y el grfico web (que conoce bien grfica y lenguaje G*/L pero no el lenguaje de programacin del lado del ser!idor). 4ara resol!er estas limitaciones, fueron desarrollados lenguajes que pueden ser incluidos al interno de arc'i!os G*/L. Estos comandos pueden ser interpretados (como por ejemplo las pginas "64 o 4G4) o precompilados (como en las pginas M64 o "64.3E*). "simismo, con la utili&acin de esta tecnologa se buscaba desarrollar aptitudes de grfico web en los programadores y de programador en los grficos web (se esperaba con ello el 'acer ms fcil y !elo& el desarrollo de script del lado del ser!idor).
Desarrollo de Aplicaciones Web 13

La unificacin de tareas, que inicialmente pareca una !entaja para el desarrollo de pginas web, se con!irti en realidad en una fuerte limitacin para el desarrollo de aplicaciones web. Las 5ltimas tendencias !en el desarrollo de frameworJ en el ser!idor, solucin que obliga a separar nue!amente el trabajo reali&ado por el grfico web y el programador. Fbtenido de Q'ttp#UUes.wiJipedia.orgUwiJiU6cript`del`lado`del`ser!idorQ 2.5.1.1 Ser.let Los ser.lets son objetos que corren dentro del conte to de un contenedor de ser!lets (ej# *omcat) y e tienden su funcionalidad. *ambin podran correr dentro de un ser!idor de aplicaciones (ej# F-+M Fracle) que adems de contenedor para ser!let tendr contenedor para objetos ms a!an&ados como son los EM0 (*omcat slo es un contenedor de ser!lets). La palabra servlet deri!a de otra anterior, applet, que se refera a pequeos programas escritos en Ma!a que se ejecutan en el conte to de un na!egador web. 4or contraposicin, un servlet es un programa que se ejecuta en un ser!idor. El uso ms com5n de los servlets es generar pginas web de forma dinmica a partir de los parmetros de la peticin que en!e el na!egador web. %n ser!let es un objeto que se ejecuta en un ser!idor o contenedor MEE, fue especialmente diseado para ofrecer contenido dinmico desde un ser!idor web, generalmente es G*/L. Ftras opciones que permiten generar contenido dinmico son con los lenguajes "64, 4G4, M64 (un caso especial de ser!let) y 4yt'on. Los servlets forman parte de MEE (Ma!a Enterprise Edition), que es una ampliacin de M6E (Ma!a 6tandard Edition). %n servlet es un objeto Ma!a que implementa la interfa& ja!a .ser!let.6er!let o 'ereda alguna de las clases ms con!enientes para un protocolo especfico (ej# ja!a .ser!let.Gttp6er!let). "l implementar esta interfa& el ser!let es capa& de interpretar los objetos de tipo Gttp6er!let>equest y Gttp6er!let>esponse quienes contienen la informacin de la pagina que in!oc al servlet. Entre el ser!idor de aplicaciones (o web content) y el servlet e iste un contrato que determina cmo 'an de interactuar. La especificacin de ste se encuentra en los M6> (Ma!a 6pecification >equests) del M-4 ( Ma!a -ommunity 4rocess). " fec'a 9 de Mulio de 9LL+, la especificacin ms reciente de los servlets se encuentra en el M6> 7H+, que define la !ersin 9.+ de los servlets.. La especificacin original de 6er!lets fue creada por 6un /icrosystems (la !ersion 7.L fue terminada en junio de 7AAB). -omen&ando con la !ersion 9.:, la especificacin de 6er!el fue desarrollada siguiendo el 4roceso de la -omunidad Ma!a(Ma!a -ommunity 4rocess).

2.8 A%$ e"te para el desarrollo de apl !a! o"es #e$ 2.8.1 Plata+or%a Ca.a
Es el nombre de un entorno o plataforma de computacin originaria de 6un /icrosystems, capa& de ejecutar aplicaciones desarrolladas usando el Lenguaje de programacin Ma!a y un conjunto de 'erramientas de desarrollo. En este caso, la plataforma no es un 'ardware especfico o un sistema operati!o, sino ms bien una mquina !irtual encargada de la ejecucin, y un conjunto de libreras estndar que ofrecen funcionalidad com5n. La plataforma es as llamada la Plata+or % a Ca.a (antes conocida como 4lataforma Ma!a 9, e incluye# 4lataforma Ma!a, Edicin Estndar (Ma!a 4latform, 6tandard Edition), o Ma!a 6E (antes M96E) 4lataforma Ma!a, Edicin Empresa (Ma!a 4latform, Enterprise Edition), o Ma!a EE (antes M9EE) 4lataforma Ma!a, Edicin /icro (Ma!a 4latform, /icro Edition), o Ma!a /E (antes M9/E)

$esde 9LLX, la !ersin actual de la 4lataforma Ma!a se conoce tanto por !ersin 7.H o !ersin H, aunque todas las denominaciones se refieren a la misma !ersin. 6in embargo, se prefiere el trmino !ersin H. %na !isin general de la multitud de tecnologas que componen la 4lataforma Ma!a puede encontrarse en la pgina de documentacin del M$N.

Desarrollo de Aplicaciones Web

14

2.8.1.1 >e!"ologas Ca.a La 4lataforma Ma!a se compone de un amplio abanico de tecnologas, cada una de las cuales ofrece una parte del complejo de desarrollo o del entorno de ejecucin en tiempo real. 4or ejemplo, los usuarios finales suelen interactuar con la mquina !irtual de Ma!a y el conjunto estndar de bibliotecas. "dems, las aplicaciones Ma!a pueden usarse de forma !ariada, como por ejemplo ser incrustadas en una pgina ?eb. 4ara el desarrollo de aplicaciones, se utili&a un conjunto de 'erramientas conocidas como M$N (Ma!a $e!elopment Nit, o 'erramientas de desarrollo para Ma!a). 2.8.1.2 Ca.a R-"t %e E". ro"%e"t %n programa destinado a la 4lataforma Ma!a necesita dos componentes en el sistema donde se !a a ejecutar# una mquina !irtual de Ma!a (MK/), y un conjunto de libreras para proporcionar los ser!icios que pueda necesitar la aplicacin. La MK/ que proporciona 6un /icrosystems, junto con su implementacin de las libreras estndar, se conocen como Ma!a >untime En!ironment (M>E) o Entorno en tiempo de ejecucin para Ma!a. El M>E es lo mnimo que debe contener un sistema para poder ejecutar una aplicacin Ma!a sobre el mismo. 4ara el desarrollo de programas se ofrece un paquete de utilidades y 'erramientas conocido como M6$N (Ma!a 6oftware $e!elopment Nit). 2.8.1.1 MB0- "a / rt-al de Ca.a El cora&n de la 4lataforma Ma!a es el concepto com5n de un procesador ;!irtual< que ejecuta programas escritos en el lenguaje de programacin Ma!a. En concreto, ejecuta el cdigo resultante de la compilacin del cdigo fuente, conocido como bytecode. Este ;procesador< es la mquina !irtual de Ma!a o MK/ (Ma!a Kirtual /ac'ine), que se encarga de traducir (interpretar o compilar al !uelo) el bytecode en instrucciones nati!as de la plataforma destino. Esto permite que una misma aplicacin Ma!a pueda ser ejecutada en una gran !ariedad de sistemas con arquitecturas distintas, siempre que con una implementacin adecuada de la MK/. Este 'ec'o es lo que 'a dado lugar a la famosa frase# ;write once, run anyw'ere< (escribir una !e&, ejecutar en cualquier parte). La condicin es que $esde la !ersin 7.9 de M>E, la implementacin de la mquina !irtual de 6un incluye un compilador M.* (Must .n *ime). $e esta forma, en !e& de la tradicional interpretacin del cdigo bytecode, que da lugar a una ejecucin lenta de las aplicaciones, el M.* con!ierte el bytecode a cdigo nati!o de la plataforma destino. Esta segunda compilacin del cdigo penali&a en cuanto a tiempo, pero el cdigo nati!o resultante se ejecuta de forma ms efica& y rpida que si fuera interpretado. Ftras tcnicas de compilacin dinmica del cdigo durante el tiempo de ejecucin permiten optimi&ar ms a5n el cdigo, dejando atrs la losa que sobre Ma!a caa en cuanto a su lentitud. 6in embargo, no puede decirse que el resultado de la compilacin de Ma!a pueda compilar el cdigo con un m imo de eficiencia, y apro!ec'ar los beneficios en cuanto a !elocidad de cdigo mquina nati!o. "unque los compiladores cada !e& son ms a!an&ados, no todas las libreras de Ma!a tienen asociado un cdigo mquina equi!alente que apro!ec'ar. 4or ejemplo, la librera ;reflect<, que permite a los programadores de Ma!a e plorar instrucciones que slo estn disponibles en tiempo de ejecucin, est pobremente representado por cdigo mquina. Ma!a no fue la primera plataforma basada en el concepto de una mquina !irtual, aunque es la que de ms amplia difusin 'a go&ado. El empleo de mquinas !irtuales se 'aba centrado principalmente en el uso de emuladores para ayudar al desarrollo de 'ardware en construccin o sistemas operati!os, pero la MK/ fue diseada para ser implementada completamente en software, y al mismo tiempo 'acer que fuera portable a todo tipo de 'ardware. 2.8.1.5 L $reras de Ca.a En la mayora de los sistemas operati!os actuales, se ofrece una cantidad de cdigo para simplificar la tarea de programacin. Este cdigo toma la forma, normalmente, de un conjunto de libreras dinmicas que las aplicaciones pueden llamar cuando lo necesiten. 4ero la 4lataforma Ma!a est pensada para ser independiente del sistema operati!o subyacente, por lo que las aplicaciones no pueden apoyarse en funciones dependientes de cada sistema en concreto. Lo que 'ace la 4lataforma Ma!a, es ofrecer un conjunto de libereras estndar, que contiene muc'a de las funciones reutili&ables disponibles en los sistemas operati!os actuales. Las libreras de Ma!a tienen tres propsitos dentro de la 4lataforma Ma!a. "l igual que otras libraras estndar, ofrecen al programador un conjunto bien definido de funciones para reali&ar tareas comunes, como manejar listas de elementos u operar de forma sofisticada sobre cadenas de caracteres. "dems, las libreras proporcionan una interfa& abstracta para tareas que son altamente dependientes del 'ardware de la plataforma destino y de su sistema operati!o. *areas tales como manejo de las funciones de red o acceso a fic'eros, suelen depender fuertemente de la funcionalidad nati!a de la plataforma destino. En el caso concreto anterior, las libreras ja!a.net y ja!a.io implementan el cdigo nati!o internamente, y ofrecen una interfa& estndar para que aplicaciones Ma!a puedan ejecutar tales funciones. Einalmente,
Desarrollo de Aplicaciones Web 15

no todas las plataformas soportan todas las funciones que una aplicacin Ma!a espera. En estos casos, las libreras bien pueden emular esas funciones usando lo que est disponible, o bien ofrecer un mecanismo para comprobar si una funcionalidad concreta est presente. las librerias de ja!a contienen un cunjunto de funciones. 2.8.1.8 Le"g-a4es La palabra Ma!a, por s misma, se refiere 'abitualmente al Lenguaje`de`4rogramacin`Ma!a, que fue diseado para usar con la 4lataforma Ma!a. Los lenguajes de programacin se encuentran fuera del mbito de lo que es una ;plataforma<, aunque el Lenguaje`de`4rogramacin`Ma!a es uno de los componentes fundamentales de la plataforma Ma!a. El propio lenguaje y el entorno en tiempo de ejecucin suelen considerarse una 5nica entidad. 6in embargo, se 'an desarrollado fuera del entorno de 6un, un gran n5mero de compiladores para la mquina !irtual de Ma!a (MK/). "lgunos de estos lenguajes son# "spectM ,eneric Ma!a (,M), incorporado en la !ersin oficial de Ma!a para el M96E H.L ,roo!y Myt'on 3et>EOO 3ice 4i&&a 6cala

2.8.2 Ado$e 6le7

Gasta 9LLH Ma!ro%ed a 6le7 es un trmino que agrupa una serie de tecnologas publicadas desde /ar&o de 9LL+ por /acromedia para dar soporte al despliegue y desarrollo de "plicaciones de .nternet >icas, basadas en su plataforma propietaria Elas'. Los programadores tradicionales de aplicaciones !en como un desafo adaptar la metfora de la animacin sobre la plataforma con la cual fue originalmente construido Elas'. Ele minimi&a elegantemente este problema pro!eyendo a flujo de trabajo y un modelo de programacin que es familiar a los desarrolladores de aplicaciones. Ele fue inicialmente liberado como una aplicacin de la M9EE o librera de etiquetas M64 que compilara el lenguaje de marcas Ele (/O/L) y ejecutara mediante "ction6cript aplicaciones Elas' (arc'i!os 6?E binarios). Kersiones posteriores de Ele soportan la creacin de arc'i!os estticos que son compilados, y que pueden ser distribuidos en lnea sin la necesidad de tener una licencia de ser!idor. El objeti!o de Ele es permitir a los desarrolladores de aplicaciones web construir rpida y fcilmente "plicaciones de .nternet >icas, tambin llamadas >."s. En un mdelo multi8capa, las aplicaciones Ele son el ni!el de presentacin. Ele pone en relie!e el desarrollo de .nterfaces grficas de usuario usando en lenguaje O/L llamado /O/L. Ele tiene !arios componentes y caractersticas que aportan funcionalidades tales como, 6er!icios ?eb, objetos remotos, arrastrar y soltar, columnas ordenables, grficas, efectos de animacin, y otras interacciones simples. El cliente solo carga la aplicacin una !e&, mejorando as el flujo de datos frente a aplicaciones basadas en G*/L(eg.4G4, "64, M64, -E/O), las cuales requieren de ejecutar plantillas en el ser!idor para cada accin. El lenguaje y la estructura de arc'i!os de Ele buscan el desacoplamiento de la lgica y el diseo. El ser!idor Ele tambin act5a como un gateway permitiendo al cliente comunicarse con ser!icios web O/L y objetos remotos (tales como -oldfusion -E-s, clases Ma!a, y cualquiera que soporte el formato de mensajes de acciones). 2.582.1 6le7 2 Ele 9 cambia el modelo de licencias para abrir la puerta a una !ersin libre de esta tecnologa, denominada QEle ErameworJQ. El nue!o Ele 0uilder 9 est basado en el entorno de desarrollo Eclipse. Los ser!icios orientados a empresas seguirn estando disponibles para aquellos que necesitan caractersticas a!an&adas, tales como el testeo automtico.

Desarrollo de Aplicaciones Web

16

Ele 9 introduce el uso de una nue!a !ersin del lenguajes de scripts "ction6cript, "ctionscript :, que requiere reproductor Elas' A o posterior para su funcionamiento. Ele ser el primer producto de /acromedia en ser etiquetado como producto de "dobe, empe&ando por la !ersin 9.L.

2.8.2.2 6le7 ) Cold6-s o"

/acromedia integra un subconjunto de Ele 7.H en su plataforma -oldfusion /O B, para usarlo en formularios Elas'. Es posible usar esta aplicacin para escribir aplicaciones de internet ricas, sin embargo su intencin original es solamente enriquecer formularios y esta funcionalidad no es soportada por /acromedia.

2.8.2.1 Pro!eso de desarrollo de -"a apl !a! ," 6le7

Los datos mostrados a continuacin 'an sido e trados directamente del arc'i!o de ayuda de la !ersin 9.L 0eta :# $efinir un interfa& de aplicacin usando un conjunto de componentes pre8definidos (formularios, botones,...) Frdenar estos componentes en el diseo del interfa& de usuario %sar estilos y temas para definir el diseo !isual "adir comportamiento dinmico (una parte de la aplicacin interactuando con otra, por ejemplo) $efinir y conectar a ser!icios de datos seg5n sea necesario (ser!icios 'ttp) -ompilar el cdigo fuente en un arc'i!o 6?E que funcione en el reproductor Elas' Ele Ele Ele Ele Ele Ele Ele Ele 7.L 8 /ar&o 9LL+ 7.H 8 Fctubre 9LL+ 9.L ("lp'a) 8 Fctubre 9LLH 9.L 0eta 7 8 Eebrero 9LLX 9.L 0eta 9 8 /ar&o 9LLX 9.L 0eta : 8 /ayo 9LLX 9.L E.3"L 8 9D Munio 9LLX 9.L.7 8 H Enero 9LLB

3 stor al de .ers o"es

2.8.2 Plata+or%a .NE>

NE> es un proyecto de /icrosoft para crear una nue!a plataforma de desarrollo de software con nfasis en transparencia de redes, con independencia de plataforma y que permita un rpido desarrollo de aplicaciones. 0asado en esta plataforma, /icrosoft intenta desarrollar una estrategia 'ori&ontal que integre todos sus productos, desde el 6istema Fperati!o 'asta las 'erramientas de mercado. .3E* podra considerarse una respuesta de /icrosoft al creciente mercado de los negocios en entornos ?eb, como competencia a la plataforma Ma!a de 6un /icrosystems. " largo pla&o /icrosoft pretende reempla&ar el "4. ?in:9 o ?indows "4. con la plataforma .3E*. Esto debido a que el "4. ?in:9 o ?indows "4. fue desarrollada sobre la marc'a, careciendo de documentacin detallada, uniformidad y co'esin entre sus distintos componentes, pro!ocando m5ltiples problemas en el desarrollo de aplicaciones para el sistema operati!o ?indows. La plataforma .3E* pretende sol!entar la mayora de estos problemas pro!eyendo un conjunto 5nico y e pandible con facilidad, de bloques interconectados, diseados de forma uniforme y bien documentados, que permitan a los desarrolladores tener a mano todo lo que necesitan para producir aplicaciones slidas. $ebido a las !entajas que la disponibilidad de una plataforma de este tipo puede darle a las empresas de tecnologa y al p5blico en general, muc'as otras empresas e instituciones se 'an unido a /icrosoft en el desarrollo y fortalecimiento de la plataforma .3E*, ya sea por medio de la implementacin de la plataforma para otros sistemas operati!os aparte de ?indows (4royecto /ono de OimianU3o!ell para Linu U/acF6 OU06$U6olaris), el desarrollo de lenguajes de programacin adicionales para la plataforma ("36. - de la %ni!ersidad de 4rinceton, 3et-F0FL de Eujitsu, $elp'i de 0orland, entre otros) o la creacin de bloques adicionales para la plataforma (como controles, componentes y
Desarrollo de Aplicaciones Web 1)

bibliotecas de clases adicionales)P siendo algunas de ellas software libre, distribuibles bajo la licencia ,4L. -on esta plataforma /icrosoft incursiona de lleno en el campo de los 6er!icios ?eb y establece el O/L como norma en el transporte de informacin en sus productos y lo promociona como tal en los sistemas desarrollados utili&ando sus 'erramientas. .NE> intenta ofrecer una manera rpida y econmica pero a la !e& segura y robusta de desarrollar aplicaciones 8 o como la misma plataforma las denomina, soluciones 8 permitiendo a su !e& una integracin ms rpida y gil entre empresas y un acceso ms simple y uni!ersal a todo tipo de informacin desde cualquier tipo de dispositi!o. .NE> 6ra%e#orI

$iagrama detallado del Mar!o de >ra$a4o .NE> El QframeworJQ o marco de trabajo, constituye la base de la plataforma .3E* y denota la infraestructura sobre la cual se re5nen un conjunto de lenguajes, 'erramientas y ser!icios que simplifican el desarrollo de aplicaciones en entorno de ejecucin distribuido. 0ajo el nombre .NE> 6ra%e#orI o Mar!o de tra$a4o .NE> se encuentran reunidas una serie de normas impulsadas por !arias compaas adems de /icrosoft (como Gewlett84acJard , .ntel, .0/, Eujitsu 6oftware, 4lum Gall, la %ni!ersidad de /onas' e .6E), entre las cuales se encuentran# La norma que define las reglas que debe seguir un lenguaje de programacin para ser considerado compatible con el %ar!o de tra$a4o .NE> (E-/"8::H, .6FU.E- 9:9B7) 4or medio de esta norma se garanti&a que todos los lenguajes desarrollados para la plataforma ofre&can al programador un conjunto mnimo de funcionalidad, y compatibilidad con todos los dems lenguajes de la plataforma. La norma que define el lenguaje -V (E-/"8::+, .6FU.E- 9:9BL) Este es el lenguaje insignia del %ar!o de tra$a4o .NE> , y pretende reunir las !entajas de lenguajes como -U-RR y Kisual 0asic en un solo lenguaje. La norma que define el conjunto de funciones que debe implementar la l $rera de !lases $ase (BCL por sus siglas en ingls) (incluido en E-/"8::H, .6FU.E- 9:9B7) *al !e& el ms importante de los componentes de la plataforma, esta norma define un conjunto funcional mnimo que debe implementarse para que el marco de trabajo sea soportado por un sistema operati!o. "unque /icrosoft implement esta norma para su sistema operati!o ?indows, la publicacin de la norma abre la posibilidad de que sea implementada para cualquier otro sistema operati!o e istente o futuro, permitiendo que las aplicaciones corran sobre la plataforma independientemente del sistema operati!o para el cual 'aya sido implementada. El 4royecto /ono emprendido por Oimian pretende reali&ar la implementacin de la norma para !arios sistemas operati!os adicionales bajo el marco del so+t#are l $re o !,d go a$ erto. Los principales componentes del marco de trabajo son# El conjunto de lenguajes de programacin La 0iblioteca de -lases 0ase o 0-L El E"tor"o Co%J" de E4e!-! ," para Le"g-a4es o -L> por sus siglas en ingls.
1+

Desarrollo de Aplicaciones Web

$ebido a la publicacin de la norma para la "+raestr-!t-ra !o%J" de le"g-a4es (-L. por sus siglas en ingls), el desarrollo de lenguajes se facilita, por lo que el %ar!o de tra$a4o .NE> soporta ya ms de 9L lenguajes de programacin y es posible desarrollar cualquiera de los tipos de aplicaciones soportados en la plataforma con cualquiera de ellos, lo que elimina las diferencias que e istan entre lo que era posible 'acer con uno u otro lenguaje. "lgunos de los lenguajes desarrollados para el %ar!o de tra$a4o .NE> son# -V, Kisual 0asic, $elp'i (Fbject 4ascal), -RR, MV, 4erl, 4yt'on, Eortran y -obol.3E*. El E"tor"o de Co%J" de E4e!-! ," para Le"g-a4es ( CLR por sus siglas en ingls), es el !erdadero n5cleo del ErameworJ de .3E*, entorno de ejecucin en el que se cargan las aplicaciones desarrolladas en los distintos lenguajes, ampliando el conjunto de ser!icios del sistema operati!o (?9J y ?9LL:). La 'erramienta de desarrollo compila el cdigo fuente de cualquiera de los lenguajes soportados por .3E* en un cdigo intermedio (/6.L, /icrosoft .ntermediate Lenguaje), similar al 0C*E-F$E de Ma!a. 4ara generar dic'o cdigo el compilador se basa en el -ommon Language 6pecification (-L6) que determina las reglas necesarias para crear ese cdigo /6.L compatible con el -L>. 4ara ejecutarse se necesita un segundo paso, un compilador M.* (Must8.n8*ime) es el que genera el cdigo mquina real que se ejecuta en la plataforma del cliente. $e esta forma se consigue con .3E* independencia de la plataforma 'ardware. La compilacin M.* la reali&a el -L> a medida que el programa in!oca mtodos, el cdigo ejecutable obtenido, se almacena en la memoria cac' del ordenador, siendo recompilado de nue!o slo en el caso de producirse alg5n cambio en el cdigo fuente. B $l ote!a de Clases Base de .NE> La 0iblioteca de -lases 0ase (0-L por sus siglas en ingls) maneja la mayora de las operaciones bsicas que se encuentran in!olucradas en el desarrollo de aplicaciones, incluyendo entre otras# .nteraccin con los dispositi!os perifricos /anejo de datos ("$F.3E*) "dministracin de memoria -ifrado de datos *ransmisin y recepcin de datos por distintos medios ( O/L, *-4U.4) "dministracin de componentes ?eb que corren tanto en el ser!idor como en el cliente ("64.3E*) /anejo y administracin de e cepciones /anejo del sistema de !entanas Gerramientas de despliegue de grficos (,$.R ) Gerramientas de seguridad e integracin con la seguridad del sistema operati!o /anejo de tipos de datos unificado .nteraccin con otras aplicaciones /anejo de cadenas de caracteres y e presiones regulares Fperaciones aritmticas /anipulacin de fec'as, &onas 'orarias y periodos de tiempo /anejo de arreglos de datos y colecciones /anipulacin de arc'i!os de imgenes "leatoriedad ,eneracin de cdigo /anejo de idiomas "uto descripcin de cdigo .nteraccin con el "4. ?in:9 o ?indows "4.. -ompilacin de cdigo

Esta funcionalidad se encuentra organi&ada por medio de espacios de nombres jerrquicos.

Desarrollo de Aplicaciones Web 12

La 0iblioteca de -lases 0ase se clasifica, en tres grupos cla!e# "64.3E* y 6er!icios ?eb O/L ?indows Eorms "$F.3E* E"sa%$lados Los ensamblados son fic'eros con forma de EOE o $LL que contienen toda la funcionalidad de la aplicacin de forma encapsulada. -on los ensamblados ya no es necesario registrar los componentes de la aplicacin.

2.9 Aspe!tos de seg-r dad 2.9.1 Co"!eptos ) pr "! p os de la seg-r dad "+or%Bt !a.
Seg-r dad I"+or%Bt !a# Ftorgar la calidad de SEKURO a los sistemas que 'acen el procesamiento de la informacin y a sus procesos de transmisin desde su elaboracin, creacin, utili&acin y mantenimiento drea del conocimiento relacionada con los mecanismos, 'erramientas y estrategias que permiten otorgar a un sistema, no necesariamente informtico, un conjunto de caractersticas que indican que esta libre de peligro, dao o riesgo. 3o se limita al software o al 'ardware, considera# %so adecuado de las instalaciones donde se manejan los sistemas informticos. a. 4olticas de seguridad. b. /edidas de contingencia. c. -ultura de las personas y la organi&acin. En sistemas informticos se 'abla de sistemas fiables y no estrictamente seguros, en un sistema fiable se garanti&an tres aspectos# 7. Co"+ de"! al dad# Los objetos de un sistema 'an de ser accedidos 5nicamente por usuarios autori&ados. 9. I"tegr dad # Los objetos solo pueden ser modificados por usuarios autori&ados y de una manera controlada. :. D spo" $ l dad # Los objetos del sistema tiene que permanecer accesibles a usuarios autori&ados. En cuanto a comunicaciones se debe de garanti&ar dos aspectos# 7. A-te"t ! dad# Las entidades que se comunican son quienes dicen ser. EjemploP -'at. 9. No rep-d o # Frigen# 3o puede negar que dijo lo que dijo. $estino# 3o puede negar que escuc'o lo que escuc'o. CONCLUSION 6i un sistema cuenta con confidencialidad e integridad, pero no esta disponible para los usuarios autori&ados, entonces se pierde toda su utilidad. 6i no 'ay garanta de saber con quien me estoy comunicando o si no mi contraparte puede negar que dijo lo que dijo, o que escuc'o o que escuc'o, no importara que los datos estn seguros. DE-e se "te"ta protegerF $atos# .ntegridad, $isponibilidad, -onfidencialidad. 4ersonas e instituciones# .ntegridad, imagen, >eputacion.

Desarrollo de Aplicaciones Web

24

.dentidad# 3ombre, .4, -uenta de correo, %>L 6istema# E!itar acciones >eprogramar el sistema telefnico /odificaciones a los contenidos de ser!idor ?E0 -omunicaciones# ,aranti&ar "utenticidad 3o repudio >ecursos# E!itar accesos no autori&ados Espacio d disco y memoria. *iempo de procesamiento. >iesgos de los %suarios# 4erdida de la pri!acidad. $esconocimiento (cultura) /uc'os lo obser!an. Ealta de regulacin (globali&acin). 3o sabe como protegerse. >iesgos de las Empresas# Fbjeto de ataques o intrusiones. E istencia de GacJers, -racJers y 6nifters >ecursos gratuitos disponibles en la red. *iempo de maquina disponible en red. $elito informtico# /s atracti!o. En e!idencia sus debilidades tecnolgicas. 3o 'ay sistema perfecto. 6istema operati!o "plicaciones Gardware Ealla en la administracin de los recursos. Eactor 'umano. Ealta de cultura, influencia de modas y mercadotecnia. "mplia nter conecti!idad 6istemas $eficiencia, !ulnerabilidad Eallas en administracin. .ntrusos Ecil adquisicin de 'erramientas. /alware 4obre cultura de usuarios y empresarios. La seguridad no puede ni debe ser igual. $istinguir usuarios. $istinguir aplicaciones Ealta de precauciones# -ultura -onfian&a 6uper!isin Pr "! p o CERO de la SI El costo de cualquier mecanismo de seguridad que implemente no debe rebasar el costo, la perdida de lo protegido. >eali&ar un anlisis de riesgos. -uidar la relacin costo8beneficio. 6e requiere de anlisis de riesgos. Pr "! p o UNO de la SI El intruso utili&ara cualquier mecanismo o 'erramienta que 'aga ms fcil su acceso y posterior ataque.

Desarrollo de Aplicaciones Web

21

6iempre e isten !arios frentes de ataque Esto dificulta el anlisis de riesgo El delincuente aplica la filosofa de acceder a trabes del punto mas dbil ;gradualmente gana pri!ilegios< Pr "! p o DOS de la SI Los datos deben protegerse solo 'asta que pierdan su !alor -aducidad del sistema de proteccin o *iempo de confidencialidad o secreto del dato o -riterio para medir la fortale&a del sistema cifrado Pr "! p o >RES de la SI Las medidas de control deben implantarse y utili&arse de forma efecti!a $eben ser eficientes, fciles de usar y apropiadas Tue funcionen en el momento oportuno Tue lo 'agan optimi&ando los recursos del sistema Tue pase desapercibidas para el usuario 3ing5n sistema de control resulta efecti!o 'asta que se utili&a a partir de una necesidad

2.9.2 Ad% " stra! ," de la seg-r dad "+or%Bt !a.

Lreas de ad% " stra! ," de la seg-r dad A-te"t + !a! ," Establecer las garantas que permitan que las entidades legitimas puedan tener acceso a los recursos de computo que un entorno de trabajo ofrece. A-tor Aa! ," Tue las entidades autori&adas tengan efecti!amente acceso unicamente a las areas de trabajo sobre las cuales ellas deben tener dominio. A-d tor a -ontin5a !igilancia de los ser!icios en produccin. Entra dentro de este rubro el mantener estadisticas de acceso, estadsticas de uso y polticas de acceso fsico a los recursos. Pr "! p o +-"da%e"tal de la ad% " stra! ," de la SI 6i se tiene responsabilidad sobre la seguridad, pero no se tiene autoridad para fijar las reglas y castigar a quienes las !iolen, su papel en la organi&acin es asumir la culpa si sucede algo gra!e. 4or regla general La poltica es el primer paso

1Tue aspectos de seguridad se deben de considerar en el desarrollo de aplicaciones ?eb2 4ara mantener los pri!ilegios de acuerdo al papelUpuesto del usuario -ertificacin de derec'os otorgados Lineamientos de uso de contraseas Lineamientos de uso de cuentas Lineamientos de registro de operaciones E!itar el robo de informacin Lineamientos para el acceso a la red (autentificacin) Lineamientos de proteccin para el cdigo de fuente ('ttps) Lineamientos de seguridad para el uso de base de datos

Desarrollo de Aplicaciones Web

22