Post on 06-Dec-2015
description
CURSO DE
ASP.Net
ÍNDICE GENERAL
UNIDAD DIDÁCTICA 1: CARACTERÍSTICAS GENERALES ASP.Net 1
LECCIÓN 1: Introducción al .Net Framework 1
1. Conceptos generales de .Net Framework 1
2. Aspectos generales de ASP.Net 3
3. Entorno Visual Studio .Net y Visual Web Developer 8
3.1. Visual Studio 8
3.2. Visual Web Developer 19
LECCIÓN 2: Infraestructura de ASP.Net 23
1. Módulos HTTP y Controladores HTTP 23
1.1. Módulos HTTP 23
1.2. Controladores Http 29
2. Administración de Estados ASP.Net 35
3. Enrutamiento 39
EJERCICIOS DE REPASO UNIDAD DIDÁCTICA 1 48
ENUNCIADOS 48
SOLUCIONES 49
UNIDAD DIDÁCTICA 2: CREACIÓN DE UN SITIO WEB 50LECCIÓN 1: Planeamiento de un Sitio Web en ASP.Net 50
1. Ciclo de vida 50
1.1. Ciclo de vida de una aplicación ASP.Net para IIS 5.0 e IIS 6.0 50
1.2. Ciclo de vida de una página ASP.Net 56
2. Creando una página Web 60
3. Controles 70
3.1. Controles de usuario 70
3.2. Controles de servidor 75
3.3. Controles de elementos 80
4. Modelo de código de páginas 82
4.1. Modelo de página de un solo archivo 83
4.2. Modelo de página de código subyacente (code behind) 84
LECCIÓN 2: Servicios Web XML con ASP.Net 86
1. Infraestructura servicios web XML 86
2. Métodos asincrónicos 94
3. Transacciones en servicios web XML 98
4. Proteger servicios web XML.Soap 101
5. Implementar y publicar servicios web XML 105
5.1. Implementación 105
5.2. Publicación 108
6. Herramientas de Servicios Web XML 111
6.1. WSDL.exe 111
6.2. Disco.exe 117
7. Esquema de Configuración de Servicios web XML 119
EJERCICIOS DE REPASO UNIDAD DIDÁCTICA 2 124
ENUNCIADOS 124
SOLUCIONES
125
UNIDAD DIDÁCTICA 3: FUNCIONALIDADES CON ASP.NET 126
LECCIÓN 1: Manejo de funcionalidades con ASP.Net 126
1. Agregar AJAX a sitios web 126
2. Obtención de acceso a datos 134
2.1. Controles de origen de datos 135
2.2. Controles enlazados a datos 136
2.3. Linq 138
2.4. Datos dinámicos 140
LECCIÓN 2: Optimización de aplicaciones ASP.Net 143
1. Aplicar seguridad en aplicaciones ASP.Net 143
1.1. Suplantación 149
1.2. Autenticación de formularios 150
2. Mejora de rendimiento de aplicaciones ASP.Net 152
3. Depuración en ASP.Net 154
EJERCICIOS DE REPASO UNIDAD DIDÁCTICA 3 158
ENUNCIADOS 158
SOLUCIONES 159
PRÁCTICAS 160ENUNCIADOS 160
SOLUCIONES 164
GLOSARIO 165
ASP.Net
1
TEMA 1. CARACTERÍSTICAS GENERALES DE ASP .NET
LECCIÓN 1. INTRODUCCIÓN AL .NET FRAMEWORK
1. CONCEPTOS GENERALES DE .NET FRAME WORK
La idea central detrás de la plataforma .NET es la de servicio. Más concretamente
software como servicio y de cómo construir, inst alar, consumir, integrar o
agregar (en federaciones) estos servicios para que puedan ser accedidos mediante
Internet. Esto es posib le debido a que tenemos la infraestructura de comunicación
global que es Internet cada vez más rápida y a un costo cada vez menor y además,
a la capacidad de los procesadores que continúa incrementándose año tras año . El
usuario de Internet puede con un explorad or de Interne t no solamente acced er a
contenido como texto, imágenes o sonido , también puede hacer uso de servicios
Web. Estos son los bloques de construcción o componentes sobre los cuales se basa
el modelo de computación distribuida en Internet. La plataforma .NET
permite usar Internet y su capacidad de di stribución para que los usuarios accedan
desde cualquier disp ositivo, en cualquier sistema operativo y lugar a la
funcionalidad que los servicios Web proveen.
El objetivo de la plataforma .NET es simplificar el desarrollo de
aplicaciones. Provee las herramientas y tecnolog ías para transfor mar a Inter net
en una plataforma de computaci ón distri buida en gra n escala. Es ta plataforma
además soporta los estándares sobre los cuales se basan los servicios Web
.NET Fram ework contiene dos compon entes principales: Common Language
Runtime y la biblioteca de clases de .NET Framework.
El Common Language Runtime (CLR) provee lo que se llama código
administrado, es decir, un entorno que provee servicios automáticos al código que
se ejecuta. Los servicios son variados:
• Cargador de Clases: Permite cargar en memoria las clases.
• Compilador MSIL a nativo: Tr ansforma código intermedio de al to ni vel
independiente del hardware que lo ejec uta a código de máquina propio de l
dispositivo que lo ejecuta.
ASP.Net
2
• Administrador de Código: Coordina toda la operac ión de los distintos
subsistemas del Common Language Runtime.
• Recolector de Basura: Elimina de memoria objetos no utilizados.
• Motor de Seguridad: Administra la seguridad del código que se ejecuta
recibiendo grados de confianza diferentes, d ependiendo de u na s erie de
factores co mo su origen, este co ntrol d e seguridad implica que un
componente administrado pueda ser capa z o no de realizar operaciones de
acceso a archivos al Registro y otras funciones delicadas.
• Motor de Depuración: Permite hacer un seguimiento de la ejecución de l
código aún cuando se utilicen lenguajes distintos.
• Verificador de Tipos: Controla que las v ariables de la aplicac ión usen e l
área de memoria que tienen asignado.
• Administrador de Excepciones: Maneja los err ores que se producen
durante la ejecución del código.
• Soporte de multiproceso (threads): Permite e jecutar código en forma
paralela.
• Empaquetador de COM: Coordina la comunicaci ón con los componentes
COM para que puedan ser usados por el .NET Framework.
• Soporte de la Biblioteca de Clases Base: Interfase con las clas es base
del .NET Framework.
• Implementación de una infraestructura de comprobación de tipos y
código llamada CTS, que garantiza que todo el cód igo administ rado es
autodescriptivo, es decir, que el código administrado puede usar otros tipos
e instancias administrados y a la vez mantener la fidelid ad y seg uridad de
sus propios tipos.
La librería de clases base son las clases sob re las cuales se construyen todas las
demás clases que utilizan los programas de Visual Studio .NET. La clase madre de
todas es System. A partir de ella por un mec anismo llamado herencia de clases,
se construyen las demás clases.
Debido a q ue en la librería de c lases ba se hay muchas clases, s e utiliza pa ra
identificarlas un mecanismo llamado espacio de nombres (namespace). La parte
del nombre de la clase que se encuentra a la derecha del último punto se llama tipo
de la clase. Todo lo que resta se llama espacio de nombres.
La librera de clases base es independiente del lenguaje. Permite el uso y la
depuración de otros lenguajes. Es extensible ya que por el mecanismo de herencia
ASP.Net
3
el usuari o puede crear nuevas clases que u san l as cl ases base como "l adrillos".
También el usuario puede incorporarlas en bibliotecas para su utilización posterior.
Es segura ya que es posible permitir o restringir su uso por med io de distint os
mecanismos de seguridad.
La plataforma .NET organiza t oda la f uncionalidad de l sist ema o perativo en u n
espacio de nombres jerárquico de forma que a la hora de programar resulta
bastante sencillo encontrar lo que se necesita.
Para ello, el Framework posee un sistema de tipos común, denominado
Common Type System (CTS). Este sistema permite qu e el programador pueda
interactuar los tipos que se incluyen en el propio Framework (biblioteca de clases
de .Net) con los creados por él mismo ( clases). De esta forma se aprovechan l as
ventajas pr opias de la programación or ientada a objetos, como la herencia de
clases pred efinidas para crear nuevas cl ases, o el polimorfismo d e clases pa ra
modificar o ampliar funcionalidades de clases ya existentes.
La biblioteca de clases de .Net Framewor k incluye, entre otro s, tres componentes
clave:
• ASP.NET para construir aplicaciones y servicios Web.
• Windows Forms para desarrollar interfaces de usuario.
• ADO.NET para conectar las aplicaciones a bases de datos.
2. ASPECTOS GENERALES DE ASP. NET
ASP.NET e s un modelo de desarrollo Web unificado que incluye los serv icios
necesarios para crear aplicaciones Web empresariales con el código mínimo. Forma
parte de .NET Framework y al codificar las aplicaciones ASP.NET se tiene acceso
a las clases en .NET Framework. El código de las aplicaciones puede escribirse en
cualquier lenguaje compat ible con el Common Language Runtime (CLR), entre
ellos Microsoft Visual Basic, C#, JScript .NET y J#. E stos lenguajes permiten
desarrollar aplicaciones ASP.NET que se benefician de todos los componentes de la
plataforma .NET.
En este curso utilizaremos el lenguaje Visual Basic 2008.
ASP.NET incluye las siguientes características:
ASP.Net
4
• Marco de trabajo de página y controles
Es un marco de trabaj o de progra mación que se e jecuta en un servidor Web
para generar y representar de forma dinámica páginas Web ASP.NET. Las
páginas Web ASP.N ET se pueden solic itar a cualquier ex plorador o dispositivo
del c liente y ASP.NE T representa el ma rcado (como HTML) al exp lorador que
realizó la solicitud. Por lo general, se puede utilizar la misma página para varios
exploradores, porq ue ASP.NET represen ta el marcado adecuado para el
explorador que realiza la so licitud. Aunque también se puede diseñar una
página Web ASP.N ET para ejecutarse en un explorador determ inado, como
Microsoft Internet Explorer 6, y aprovechar así todas las características de es e
explorador. Es compa tible con los controles móviles de los disposit ivos
preparados para trabajar en Web como teléfonos celulares, PC portátiles y
asistentes digitales personales (PDA).
Las páginas Web ASP.NET están completamente orientadas a objetos y se
puede trabajar con elementos HTML que usen propiedades, métodos y eventos.
Quita los detalles de implementación relacionados con la separación de cliente y
servidor in herente a la s aplicac iones Web presen tando un modelo unificado
que responde a los eventos de los clientes en el cód igo que se ej ecuta en el
servidor. El marco de trabajo mantiene automáticamente el estado de la
página y de los controles que contenga durante el ciclo vital de
procesamiento de la página.
Permite encapsular la funcionalidad común de la interfaz de usuario en controles
fáciles de u sar y reut ilizables. L os con troles se escriben una vez, se pueden
utilizar en varias páginas y se in tegran en la página Web ASP.NET en la que
se colocan durante la representación.
Proporciona funciones para contro lar la apariencia y el funcionamiento general
de los s itios Web a través de temas y máscaras. Se pueden definir temas y
máscaras y, a continuación, aplicarlos en las páginas o controles.
Puede defi nir una p ágina pri ncipal úni ca q ue de fine el di seño y el
comportamiento están dar deseados pa ra todas las páginas (o un grupo de
páginas) de la aplicación. A continuación, se pueden crear páginas de contenido
individuales con el contenido específico de la página que se desee mostrar.
ASP.Net
5
• Compilador de ASP.NET
Compila todo el código de ASP.NET, lo que permite el establecimiento inflexible
de tipos, las optimiz aciones de rendim iento y el enlace en tiempo d e
compilación, entre otras ventajas. Una ve z que se ha c ompilado el código, el
Common Language Runtime compila una vez más código de ASP.N ET e n
código nativo, lo que permite un mayor rendimiento.
ASP.NET in cluye u n compilador que compil ará todos los componentes de la
aplicación, in cluidas la s pági nas y los contr oles, en un ensamblado que el
entorno de host de ASP.NET puede u tilizar a con tinuación para at ender las
solicitudes del usuario.
• Infraestructura de seguridad
Además de las características de s eguridad de .NET, ASP.NET proporciona una
infraestructura de seguridad avanzada para autenticar y autorizar el acceso d e
los usuarios y realiza r otras tareas relacionadas con la seguridad. Puede
autenticar usuarios con la autenticación de Wi ndows suministrada por IIS o
puede admi nistrar la autenti cación con s u p ropia base de datos de usuari o
utilizando l a au tenticación media nte f ormularios ASP .NET y la su scripción
ASP.NET. Además, p uede admini strar l a autorización a las capacidades e
información de su aplicación Web median te los grupos de Windows o su propia
base de d atos de f unciones person alizada u tilizando las funciones de
ASP.NET. Resu lta fácil qu itar, agregar o reemplazar estos esquem as
dependiendo de las necesidades de la aplicación.
ASP.NET siempre se e jecuta con una identidad particular de Windows de modo
que puede asegurar su aplicac ión utilizando las capacidades de Win dows como,
por ejemplo, las listas de control de acceso (ACL) de NTFS, permisos de la base
de datos, etc.
ASP.Net
6
• Funciones de administración de estado
ASP.NET proporciona funcionalida d de administración de estado intrínseca
que permit e almacen ar in formación en tre las solic itudes de págin a, como l a
información de cl ientes o e l contenido del carro de la compra. Puede guardar y
administrar in formación específ ica de la ap licación, específ ica de la ses ión,
específica d e la página, es pecífica del usuari o y definid a por el desarrollador .
Esta información puede ser independiente de cualquier control de la página.
Ofrece funciones de estado distribuidas, lo que le permite administrar
información de est ado en mú ltiples in stancias de la misma apl icación en un
equipo o en varios.
• Configuración de la aplicación
Las aplicaciones ASP.NET utilizan un sistema de configuración que le permite
definir valores de configuración para su servidor Web, para un sitio Web o para
aplicaciones in dividuales. P uede crear v alores de co nfiguración cu ando se
implementan est as aplicac iones y pu ede agregar o r evisar los valores d e
configuración en cual quier momento con un impacto mínimo en ap licaciones y
servidores Web de operaciones. Los valores de configuración de ASP.NET se
almacenan en archivos basados en la tecnología XML. Dado que estos archivos
XML son archivos de texto ASCII, es f ácil realizar cambios de con figuración a
sus aplicaciones Web. Puede extender el esquema de configuración para
satisfacer sus requisitos.
• Supervisión de estado y características de rendimiento
Estas características que permiten supervisar el estado y el rendim iento de las
aplicaciones proporcionando información sobre eventos clave que nos dan la
información sobre el estado de una aplicación y sobre las condiciones de error.
Estos eventos muestran una com binación de diagnósticos y características d e
supervisión, a la v ez que proporcionan un elevado grado de flexibilidad en lo
que respecta a lo que se registra y cómo.
ASP.NET admite dos grupos de contadores de rendimiento a los qu e pueden
obtener acceso las aplicaciones:
ASP.Net
7
• El grupo de contadores de rendimiento del sistema
• El grupo de contadores de rendimiento de la aplicación
• Capacidad de depuración
Se aprovecha la infraestructura de de puración en tiempo de ejecución par a
permitir la depuración entre lenguajes y equipos. Se pueden depurar tanto
objetos administrados como no administrados, así como todos los
lenguajes compat ibles con el Common Language Runtime (CLR) y los
lenguajes de script.
Además, el marco de trabajo de páginas ASP.NET proporciona un modo de
seguimiento qu e permit e in sertar men sajes de in strumentalización en las
páginas Web.
• Marco de trabajo de servicios Web XML
ASP.NET es compatible con los servicios Web XML. Un servicio Web XML es
un compo nente que i ncluye f uncionalidad de empresa que per mite a las
aplicaciones intercambiar información entre firewalls utilizando estándares como
los serv icios de men sajería HTTP y XML. Los servicios Web XML no están
relacionados con ninguna tecnología de componentes ni con ninguna convención
de llamada a objetos en concreto. Como resultado, pueden obtener acceso a los
servicios Web XML los programas escritos en cualquier l enguaje, que use n
cualquier modelo de componentes y se ejecuten en cualquier sistema operativo.
• Entorno de host extensible y administración del ciclo de vida de las
aplicaciones
Incluye un entorno d e host ext ensible que control a el ci clo de v ida de una
aplicación desde el mo mento en que un usuario cualquiera tiene acceso a un
recurso (como una página) en la aplicac ión hasta el mo mento en que se cierra
la aplicación. Aunque se basa en un servidor Web (IIS) como un host de la
aplicación, ASP.NET proporciona gran parte de la propia funcionalidad de host.
La arquitectura de ASP.NET permit e respo nder a los eventos de aplicac ión y
crear controladores y módulos HTTP personalizados.
ASP.Net
8
3. ENTORNO VISUAL STUDIO .NET Y VISUAL WEB DEVELOPER
3.1 VISUAL STUDIO
El entorno de desarrollo ( Integrated Development Environment - IDE) de
Visual Studio 2008 es el resultado de la evolución de los IDE’s de Microsoft, recoge
todas las herramientas para desarrollar una amplia gama de tipo s de aplicaciones
y/o soluciones.
Visual Studio 2008 se presenta en varias versiones:
• Express
• Standard
• Professional
• Team System
La primera vez que se ejecuta Visual Studio 2008 aparece una ventana splash un
momento antes de que se seleccione las op ciones de configuración del entorno por
defecto. Como se puede trabajar con va rios lenguajes y tecnologías en un mi smo
IDE, éste debe contar con varias opciones que permita trabajar marcando las
diferencias en la manera de desarrollar.
Normalmente al principio se deja la opción “Configuración general de desarrollo
- General Development Settings”.
Dependiendo de l a con figuración del entorno cuando se haga clic en el botón de
“Iniciar Visual Studio” nos saldrá una ventana en la que se informa que entorno
de desarrollo se ha configurado. Una vez realizado esto Visual Studio 2008 se abrirá
y podremos empezar a trabajar.
La vista general del entorno de Visual Studio 2008 es la siguiente:
ASP.Net
9
Figura 3.1
De forma genérica los menús y barra de herramientas están posicionados arriba del
todo y las de selección de subventanas o paneles aparecen a la derec ha e
izquierda del área de la ventana principal. El centro se reserva para el espacio del
editor principal, sin embargo al abrir un fichero de código, un documento XML, un
formulario o cualquier otro fichero, aparecerán dentro de este espacio central.
La barra de menús nos permitirá acceder a la ma yoría de las opciones que
controlan el entorno de desarrollo. Los menús y los comandos trabaj an según una
serie de reglas estándar utilizadas en todos los programas basados en Windows; y
podremos acceder a ellos utilizando el teclado o el ratón.
Justo debajo de la barra de menús se encuentra la barra de herramientas
Estándar, un conju nto de botones que fu ncionan como atajos para ejecutar
opciones y controlar el entorno de desarro llo de Visual Studio. En la part e inferior
de la pan talla se encuentra la barra de t areas de Windows, c on esta barra
podremos conmutar e ntre distintos compon entes de Visual Studio .NET y para
activar otros programas de Windows.
Por cada fic hero que se abra, se creará una pestaña de tal manera que se pueda
tener a la vista todos los objetos abiertos.
ASP.Net
10
En Visual Studio 2008 los prog ramas qu e se encuentran en desarrollo se
denominan soluciones porque contienen varios componentes individuales, y no un
único archivo.
Se pueden crear o abrir 2 tipos de soluciones y una opción para agregar archivos a
esas soluciones
• Crear/abrir Proyecto (VER figura 3.2)
Figura 3.2
ASP.Net
11
• Crear/abrir Sito web (Ver figura 3.3)
Figura 3.3
• Crear/abrir Archivo (VER Figura 3.4)
Figura 3.4
ASP.Net
12
A pesar de tener unas características generales el aspecto puede variar ligeramente
dependiendo del t ipo de solución que de seemos crear o abrir. La diferencia
principal es el Explorador de soluciones caso de se leccionar un proyecto s e
visualizara de la siguiente manera.
Figura 3.5
Si seleccion amos Sitio Web el aspecto del Explorador de soluciones será el
siguiente.
En cualquier caso se p odrá ir añadiendo tantos archivos como sean necesarios
para n uestra aplicac ión qu e se irán añ adiendo a la ven ta del Explorador de
Soluciones
Figura 3.6
ASP.Net
13
Desde esta ventana se controlará la situación de la solución y sus proyectos en todo
momento. E n ella se in cluye t odos lo s ob jetos que tiene la so lución, como
proyectos, formularios, módulos, clases, referencias del servicio Web…
Pulsando el botón der echo del ratón sobre la el tipo de objeto que hayamos
abierto Web Application o Web Site se podrá acceder a las principales acciones
a realizar sobre la solución.
Figura 3.7
Debajo de la venta na del “Explorador de soluciones” se encuentra la “Ventana
de propiedades” en ella se podrán consultar o modificar las características o las
definiciones de propied ades de los elementos que componen la interfaz de usua rio
de un formulario.
Una definición de propiedad es una cualidad de uno de los objetos contenidos en su
interfaz de usuario. Por ejemplo, se podrá modificar la fuente, color, tamaño y en
general las características por alguna ma nera llamarlas física , pero tambi én se
podrán modificar el c omportamiento o apariencia de un elemento. Se puede
modificar la definición de las propiedades utilizando la ventana Propiedades, cuando
ASP.Net
14
se está cre ando la interfaz de usuario, o se podrá agregar código en el programa
utilizando el Editor de código para modificar una o más def iniciones de propiedades
durante la ejecución del programa.
La ventana Propiedades conti ene un cua dro de lista desplegable denominado
Objeto que part iculariza t odos los elemen tos ( objetos) de la in terfaz de usuario
contenidos en e l f ormulario; la v entana t ambién l ista las definiciones de
propiedades que se podrán modificar para cada uno de los objetos (podrá hacer
clic en uno de los dos botones disponib les para ver las propiedades ordenadas
alfabéticamente o por categorías).
El Cuadro de herramientas contiene la mayoría de los controles que se utilizarán
para generar aplicacio nes. Existen varias co lecciones de controle s en el cuadro de
herramientas y se p odrá acceder a toda s ellas s in más que hacer clic en las
pestañas que se puede ver dentro del Cuadro de herramientas.
NOTA 1: Si ahora no ves el C uadro de herramientas, seleccion a el comando
Cuadro de herramientas del menú Ver o pulsa el icono del martillo.
NOTA 2: Hay que tener en cuenta que si la solución seleccionada en un Sitio Web
no tiene interfaz gráfica por lo tanto el cuadro de herramientas aparecerá vacío.
Figura 3.8
El cuadro de herramientas normalmente está visible s iempre que otra ventana
conocida como Diseñador de Páginas, que es básicamente un lienzo en blanco
ASP.Net
15
que representa la interfaz de usuario de la aplicación, esté también visible. En esta
ventana se diseñarán todos los controles que conformarán la página.
Las páginas asp.net son archivos formados por el nombre de la página y la
extensión aspx. Por defecto al abri r una sol ución ti po Aplicación Web se creará
una página llamada “Default.aspx”, est a página n os serv irá co mo in icio de
nuestra aplicación. En ella se v isualizará tanto el cód igo que escribamos como el
diseño de la página tal y como aparece en la figura 3.9.
Figura 3.9
Este mensaje ( figura 3.10) aparece porque para ejecutar las pág inas se necesita
un Servidor Web, co mo IIS (Internet Information Server) que deberíamos
tener instalado, si nuestro sistema op erativo es 2000, 2003, 2008, XP (No en la
versión Home) o Vista este servidor estará incluido.
Si todavía no hemos conectado el sitio web que estamos desarrollando con el IIS...
¿cómo podemos ejecutar las páginas? Recuer da que no se pueden hacer doble clic
en ellas en el explorador de archivos sino que deben ejecutarse en un servidor web.
La solución es que el entorno de desarrollo incorpora un pequeño servidor web para
la depuración y la ejecución de las páginas.
No se puede utilizar como servidor web, es sólo para la prueba de las
páginas, así no tenemos que moverlas a un servidor IIS para probarlas.
ASP.Net
16
Lo que realmente significa este mensaje de: http://localhost:4450/Website2 Es que
el servidor es "localhost" que es una palabra clave que apunta a nuestro propio
equipo y ejecuta el servidor web en el puerto 4450 de ahí loca lhost:4450. Aunque
los servidores web se ejecutan en el puerto 80 pero como este es uno de pruebas lo
ejecuta en ese puerto, no importa ya que es para probar las p áginas, no es
necesario configurar nada de este servi dor web porque lo gestiona todo el entorno
de desarrollo.
Figura 3.10
Al depurar la ap licación podemos encont rarnos con otro problem a ya que por
defecto la depuración en el Internet Explorer no está activada, por lo que es
posible que al ejecutar la página salga el siguiente mensaje:
Figura 3.11
Para solu cionarlo n os iremos a las Opcio nes del In ternet Ex plorer del m enú
herramientas y seleccionamos la solapa "Opciones Avanzadas":
Desmarcamos la opci ón de "D eshabilitar la depu ración de script s ( Internet
Explorer) y re iniciamos el navegador. C ancelamos la ejecución d e la página del
mensaje anterior para que coja es tos cambios y le volve mos a puls ar al botón d e
depuración para ejecutar la página.
ASP.Net
17
Figura 3.12
Hay numer osas venta nas adi cionales en el IDE, cad a una para una tarea de
programación concreta. Algunas de las más comunes se muestran a continuación.
• La ventana Lista de errores (figura 3.13) aparece en la parte inferior de l
IDE si se escribe cód igo incorrecto o ap arecen otros err ores en tie mpo de
diseño.
ASP.Net
18
Figura 3.13
• La v entana d el Explorador de Servidores (figura 3.14) se u tiliza para
examinar los servidor es tanto de Base de datos como Web a los qu e
tenemos conexión.
Figura 3.14
ASP.Net
19
• La ventana de Resultados (figura 3.15), en testa venta se podrá ver lo s
pasos de ejecución al depurar la página asp.
Figura 3.15
3.2 VISUAL WEB DEVELOPER
Visual Web Devel oper es un entorno de desarrollo completo para crear
aplicaciones Web ASP .NET (den ominadas si mplemente " sitios We b"). Visu al Web
Developer tiene las características siguientes:
• Diseño de páginas Web Un editor de páginas Web eficaz que incl uye la
edición WYSIWYG (What You See Is What You Get) y el modo de
edición HTML con IntelliSense y validación.
• Características del diseño de páginas La disposición de sit ios uniforme
con páginas principales y apariencia de pági nas uni forme con temas y
máscaras.
• Edición de código Un editor de código que le permite escribir código para
las páginas Web dinámicas en Visual Basic o C#. El editor de código incluye
coloración para la sintaxis e IntelliSense.
• Depuración Un dep urador que le ayud a a encontr ar errores en sus
programas.
• Controles Un conjunto extenso d e controles de servidor Web de ASP.N ET
que incorpora mucha de la funcionalidad necesaria para crear sitios Web.
• Acceso a datos Compatibilidad para mostrar y editar datos en las páginas
Web. Los datos pueden estar en una variedad de almacenes de datos, entre
los que se incluyen bases de datos o archivos XML. En muchos casos, puede
ASP.Net
20
agregar la posibilidad de ver los datos y de editarlos en sus páginas Web sin
necesidad de escribir ningún código.
• Seguridad y personalización Servicios de aplicaciones integradas que le
permiten agregar suscripciones para la seguridad de inicio de sesión en el
sitio, propi edades de perf iles q ue le permit an mant ener la in formación
específica de los usuarios y otras características, la mayoría de las cuales no
requiere ningún código.
Visual Web Developer proporciona un entorno muy bueno para generar sitios Web y
publicarlos en un sitio de hospedaje ya que con las herramientas de desarrollo
que proporciona se puede desarrollar páginas Web ASP.NET en tu propio equipo.
También incluye un servidor Web local que proporciona todas las característic as
necesarias para probar y depurar pági nas Web ASP.N ET, sin nec esidad de que
estén instalados los Internet Information Services (IIS).
Una vez que el sitio web esté listo se podrá publicar en el equipo host utilizando la
herramienta Copiar W eb integrada, que tran sfiere los archivos cua ndo se quiera
compartir con los demás. Asimis mo, se puede precompilar e implementar un sitio
Web mediante el comando Generar sitio Web que ejecuta el compilado r en todo
el sitio Web (no sólo en los archivos de código) y genera un diseño de sitio Web que
se puede implementar en un servidor de producción, e ste componente no está
disponible en la versión Express.
Por último decir que se pu ede aprovechar la compa tibilidad integrada con el
Protocolo de transferencia de archivos (FTP). Si se utiliza las funciones FTP
de Visual Web Developer, nos podemos conectar direct amente al equipo host y
luego crear y editar archivos en otro servidor.
Al ejecutar Visual Web Developer 2.008 en e l último punto de la instalación es e l
registro del programa:
ASP.Net
21
Figura 3.16
Nos registramos para obtener la clav e y nos encontr aremos des pués con el
entorno de desarrollo:
• Pantalla inicial (figura 3.17)
Figura 3.17
ASP.Net
22
• Entorno desarrollo (figura 3.18)
Figura 3.18
Como se puede comprobar este entorno es muy parecido al en torno genérico de
Visual Studio. Si quis iéramos crear un sitio web ASP.NET se seleccionaría esa
opción y nos f ijaremos qu e debajo se mu estra el len guaje qu e vamos a u tilizar
"Visual Basic" y "Location" indica que es "File System" es decir, una carpeta
normal de nuestro disco duro.
ASP.Net
23
LECCION 2. INFRAESTRUCTURA DE ASP .NET
En esta lección nos adentraremos en las principales cara cterísticas de la
programación Web mediante ASP.NET, conociendo toda la infraestructura de un
sitio Web y fami liarizándonos con térmi nos tan importantes como es la
administración de estados y el enrutamiento.
1. MÓDULOS HTTP Y CONTROLADORES HTTP
Los módulos y los controladores HTTP forman una parte integrante de la
arquitectura de ASP.NET.
En el ciclo de depuración de una página ASP hay varios módulos HTTP que la
procesan (por ejemp lo, el módulo de au tenticación y el módulo de sesión) y
después es procesado por un único controlador HTTP, y por último cuando el
controlador ya ha proc esado la solicitud, ésta es devuelta a través de los módulos
HTTP.
1.1. MODULOS HTTP
Los módulos se llama n antes y después de que se ejecute el controlador. Los
módulos permit en a los desa rrolladores interceptar cada so licitud individual,
participar en ella o m odificarla e imp lementan la interfaz IHttpModule, que se
encuentra en el espacio de nombres System.Web.
Entre los usos habituales de los módulos HTTP se incluyen los siguientes:
• Seguridad Dado que se pueden examinar las so licitudes en trantes, u n
módulo HTTP puede realizar una au tenticación person alizada u ot ras
comprobaciones de seguridad antes de qu e se llame a la página, al servicio
web XM L o al con trolador solic itado. En el modo integrado de Internet
Information Services (IIS) 7.0 , se puede extender la aute nticación de
formularios a todos los tipos de contenido de una aplicación.
ASP.Net
24
• Estadística y registro Como en cada solicitud se llama a módu los HTTP,
se puede recopilar estadísticas e información de registro sobre las solicitudes
en un módulo centralizado, en lugar de hacerlo en páginas individuales.
• Encabezados o pies personalizados Ya que es p osible mod ificar la
respuesta de salida, se puede insert ar cont enido, como in formación d e
encabezado personalizada, en cada respuesta de página o servicio web XML.
Eventos disponibles
Una clase HttpApplication proporciona una serie de eventos con los que los
módulos se pueden sincronizar.
Los evento s de la lis ta de abajo está n di sponibles para que los módulos se
sincronicen en ca da solicitud. (Estos eventos se muestran en orden
secuencial)
• BeginRequest: se h a in iciado l a solic itud. Si se necesita hacer algo al
principio de una solic itud (por ejempl o, mostrar titulares de anuncio al
principio de cada página), sincronizamos este evento.
• AuthenticateRequest: Si desea mos u tilizar n uestro propio esquema de
autenticación personalizado (por ejemplo, buscar un usuario en una base
de datos para validar la contraseña), crearemos un mó dulo que sincronice
este evento y autentique al usuario como nosotros queramos.
• AuthorizeRequest: este evento se usa inte rnamente para imp lementar
mecanismos de autorización (por ejemp lo, para alm acenar las listas de
control de acceso (ACL) en una base de datos en lugar de en el sistema de
archivos). Aunque se puede invalidar este evento, no es muy conveniente.
• ResolveRequestCache: este evento determina si una página s e pued e
servir desde la caché de salida. Si queremos escribir nuestro propio módulo
de almacenamiento en caché, por ejemplo, crear una caché basada en
archivos en lugar de una caché de me moria, sincronizar emos este evento
para determinar si servir la página desde la caché.
• AcquireRequestState: el estado de la sesión se obtiene del almacén d e
estados. Si queremos crear nuestro propio módulo de administración de
estados, sincronice este evento para obtene r el estado de la sesión de su
almacén de estados.
ASP.Net
25
• PreRequestHandlerExecute: este evento se produce antes de que se
ejecute el controlador HTTP.
• PostRequestHandlerExecute: este evento se produce después de que se
ejecute el controlador HTTP.
• ReleaseRequestState: el estado de la sesión se vuelve a almacenar en e l
almacén de estados. Si estamos creando un módulo de estado de
sesión personalizado, deberemos almacenar el estado de nuevo en el
almacén de estado.
• UpdateRequestCache: este evento escribe el r esultado en la caché d e
resultados. Si estamos creando un módulo de caché personalizado,
escribiremos el resultado en la caché.
• EndRequest: la solicitud se ha completado. Puede ser conveniente crear un
módulo de depuración que recopile información a través de la solicitud y,
después, la escriba en la página.
Los siguientes eventos están disponibles para que los módulos se sincronicen en
cada t ransmisión de la solic itud. (El orden de estos eventos no se puede
predecir.)
• PreSendRequestHeaders: este evento se produce antes de que se envíen
los encabezados. Si queremos agrega r encabezados adicionales, podemos
sincronizar este evento desde un módulo personalizado.
• PreSendRequestContent: este evento ocurre cuando se llama a l método
Response.Flush. Si qu eremos agregar con tenido adicional, podemos
sincronizar este evento desde un módulo personalizado.
• Error: este evento ocurre cuando se pr oduce una excepci ón no contr olada.
Si querem os escrib ir un módulo de controladores de error
personalizado, podemos sincronizar este evento.
Configurar módulos HTTP
El controlador de la sección de configuración <httpModules> es responsable de
configurar los módu los HT TP den tro de u na aplicac ión. Se pu ede declarar en l os
equipos, lo s sit ios o las aplicac iones. Ut ilizaremos la s iguiente sin taxis para el
controlador de la sección <httpModules>:
ASP.Net
26
<httpModules> <add type="[CO M+ Class], [A ssembly]" n ame="[ModuleName]" / > <re move
type="[COM+ Class], [Assembly]" name="[ModuleName]" /> <clear /> </httpModules>
Crear módulos HTTP personalizados
El proceso general para escribir un módulo HTTP es el siguiente:
• Crearemos una clase que implemente la interfaz IHttpModule.
• Escribiremos un controlador para el método Init. El método de inicialización
debe in icializar e l mód ulo y rea lizar la su scripción a cu alquier ev ento de
aplicación que necesite. Por ejemplo, si desea anexar algún elemento a las
respuestas, podría realizar la suscripción al evento EndRequest. Si desea
aplicar lógica de autenticación personalizada, podría realizar la suscripción al
evento AuthenticateRequest.
• Escribiremos código para los eventos a los que nos hayamos suscrito.
• Opcionalmente, implementaremos el método Dispose si el módulo requiere
limpieza.
• En nuestro sitio Web añadiremos un nuevo elemento de tipo Clase con
extensión .vb si utilizamos Visual Basic o .cs si utilizamos C# que se añadirá
en la carpeta App_Code.
ASP.Net
27
Imports Microsoft.VisualBasic
Imports System.Web
Public Class ModuloHolaMundo
Implements IHttpModule
Public Sub New()
End Sub
Public ReadOnly Property ModuleName() As String
Get
Return " ModuloHolaMundo "
End Get
End Property
' En la funcion Init, registramos los eventos para HttpApplication
' añadidos por nuestros manejadores.
Public Sub Init(ByVal application As HttpApplication) _
Implements IHttpModule.Init
AddHandler application.BeginRequest, _
AddressOf Me.Application_BeginRequest
AddHandler application.EndRequest, _
AddressOf Me.Application_EndRequest
End Sub
Private Sub Application_BeginRequest(ByVal source As Object, _
ByVal e As EventArgs)
' Creamos los objetos HttpApplication y HttpContext para acceder
' a las propiedades request y response.
Dim application As HttpApplication = DirectCast(source, _
HttpApplication)
Dim context As HttpContext = application.Context
Dim filePath As String = context.Request.FilePath
Dim fileExtension As String = _
VirtualPathUtility.GetExtension(filePath)
If fileExtension.Equals(".aspx") Then
context.Response.Write("<h1><font color=red>" & _
" ModuloHolaMundo: Beginning of Request" & _
"</font></h1><hr>")
End If
End Sub
Private Sub Application_EndRequest(ByVal source As Object, _
ASP.Net
28
ByVal e As EventArgs)
Dim application As HttpApplication = DirectCast(source, _
HttpApplication)
Dim context As HttpContext = application.Context
Dim filePath As String = context.Request.FilePath
Dim fileExtension As String = _
VirtualPathUtility.GetExtension(filePath)
If fileExtension.Equals(".aspx") Then
context.Response.Write("<hr><h1><font color=red>" & _
" ModuloHolaMundo: End of Request</font></h1>")
End If
End Sub
Public Sub Dispose() Implements System.Web.IHttpModule.Dispose
End Sub
End Class
• Guardamos y cerramos el arch ivo de clase y en el menú “Generar”
seleccionaremos “Generar Sitio Web”
• Registramos el módu lo en el archivo Web.config. Si aún no te nemos un
archivo web.config en el sit io web, lo crearemos bajo la raíz del sitio y
agregaremos el siguiente código al archivo Web.config:
<configuration>
<system.web>
<httpModules> <add name="NombreModulo" type=" NombreModulo "/> </httpModules>
</system.web>
</configuration>
Este código registrará el módulo con el nombre de la clase y el nombre del
módulo.
ASP.Net
29
1.2 CONTROLADORES HTTP
Los controladores se usan para procesar solic itudes de extremos individuales,
permiten a ASP.NE T Framework procesar direcciones URL HTTP indiv iduales o
grupos de extensiones URL dentro de una aplicación.
A diferencia de los módulos, sólo se usa un controlador para procesar una solicitud.
Todos los controladores implementan la interfaz IHttpHandler, que se encuentra
en el espa cio de no mbres System.Web. Los contr oladores s on ligeramente
parecidos a las extensiones de la Interfaz de programación de aplicaciones
para servidores de Internet (ISAPI).
El controlador más común es el de la página ASP.NET que procesa archivos
.aspx. Cuando los usuarios solicitan un archivo .aspx, la página procesa la solic itud
a través del controlador de pág inas. Ex isten otros controladores integrados en
ASP.NET
CONTROLADOR DESCRIPCIÓN
Controlador de
páginas ASP.NET
(*.aspx)
Controlador HTTP pr edeterminado para todas las
páginas ASP.NET.
Controlador de
servicios Web
(*.asmx)
Controlador HTTP pred eterminado para las p áginas de
servicios web creadas como archivos .asmx en
ASP.NET.
Controlador web
genérico (* .ashx)
El controlador HTTP predeterminado para todos los
controladores web qu e no ti enen ni nguna interfaz de
usuario y que incluyen la directiva @ WebHandler.
Controlador de
seguimiento
(trace.axd)
Controlador que muestra la información de seguimiento
de la página actual. Para obtener información detallada,
vea Cómo: Ver información de seguimiento de ASP.NET
con el visor de seguimiento.
ASP.Net
30
Configurar controladores HTTP
El controlador de la sección de configuración <httpHandlers> es responsable
de asignar las direc ciones URL entrantes para las clases IHttpHandler o
IHttpHandlerFactory. Se puede declar ar en los equipos, los sitios o las
aplicaciones. Los subdirectorios heredan estas opciones.
Los administradores usan la directiva de la etiqueta <add> para confi gurar l a
sección <httpHandlers>. Las directivas <Add> se interpretan y procesan en
orden secuencial descendente. Utilizaremos la siguiente sintaxis para el controlador
de la sección <httpHandler>:
<httpHandlers> <add verb ="[verb list]" path= "[path/wildcard]" t ype="[COM+ Cla ss], [Assembly]"
validate="[true/false]" /> <remo ve v erb="[verb list]" path ="[path/wildcard]" /> <cle ar / >
</httpHandlers>
Crear controladores HTTP
Podemos crear nuestros propios c ontroladores HTTP que representen el resulta do
personalizado en el explorador.
Para crear un co ntrolador HT TP pers onalizado, cr earemos una clase que
implementa la interfaz IHttpHandler para crear un controlador sincrónico o
implementar la interfaz IHttpAsyncHandler para crear un controlador
asincrónico. L as dos in terfaces del con trolador requieren que se implemente la
propiedad IsReusable y el método ProcessRequest.
• La propiedad IsReusable especifica si el objeto IHttpHandlerFactory (el
objeto que realmente llama a l controlador adecuado) puede colocar el
controlador en un gru po y reuti lizarlo pa ra aumentar el rendimiento. Si e l
controlador no se puede agrupar, el generador debe crear una nueva
instancia del controlador cada vez que se necesite.
• El mé todo ProcessRequest es e l responsable de procesar las solicitudes
HTTP in dividuales. E n este mét odo, se escribirá el cód igo que genera el
resultado para el controlador.
ASP.Net
31
Los controladores HTTP tienen acceso al con texto de la aplicac ión. Esto incluye la
identidad d el usuario que realiza la solicitu d (si se conoce), el estado de la
aplicación e información de la sesión. Cuando se solic ita un contr olador HTTP,
ASP.NET lla ma al mét odo ProcessRequest del controlador adecu ado, el cód igo
que se escribe en este método del controlador crea una respuesta, que se devuelve
al explorador que realizó la solicitud.
• Controlador síncrono
Imports System.Web
Public Class ControladorHolaMundo
Implements IHttpHandler
Public Sub ProcessRequest(ByVal context As _
System.Web.HttpContext) Implements _
System.Web.IHttpHandler.ProcessRequest
Dim request As HttpRequest = context.Request
Dim response As HttpResponse = context.Response
' Este controlador es llamado cada vez que un fichero que termina
' en .sample is solicitado.
response.Write("<html>")
response.Write("<body>")
response.Write("<h1>Hola desde un controladorHTTP síncrono personalizado.</h1>")
response.Write("</body>")
response.Write("</html>")
End Sub
Public ReadOnly Property IsReusable() As Boolean _
Implements System.Web.IHttpHandler.IsReusable
Get
Return False
End Get
End Property
End Class
• Controlador asíncrono. Los co ntroladores HTTP asincrónicos permiten
iniciar un proceso externo, como por ejemplo una llamada a un método en
un servi dor remoto, mi entras que el control ador conti núa procesan do si n
esperar a q ue termine el proceso externo. Durante el procesamiento de un
controlador HT TP asin crónico, ASP .NET coloca el subproceso que
normalmente se u tilizaría para el p roceso externo de nu evo en el gru po de
subprocesos hasta que el controlador re ciba una de volución de llamada del
ASP.Net
32
proceso externo. Esto puede evitar el agrupamiento en bloques de los
subprocesos y mejor ar e l rendimiento ya que solo es posib le ejecutar
inmediatamente un número limitado de subprocesos. Si var ios usuarios
solicitan controladores HTTP sincró nicos que dependan de procesos
externos, el sistema operativo puede quedarse sin subprocesos rápidamente
porque muchos estarán bloqueados y esperando un proceso externo.
En este ejemplo crear emos una clase llamada ControladorAsincHolaMundo
en el directorio App_Code
Imports Microsoft.VisualBasic
Imports System.Web
Imports System.Threading
Public Class ControladorAsincHolaMundo
Implements IHttpAsyncHandler
Public ReadOnly Property IsReusable() As Boolean Implements
System.Web.IHttpHandler.IsReusable
Get
Return False
End Get
End Property
Public Function BeginProcessRequest( _
ByVal context As System.Web.HttpContext, _
ByVal cb As System.AsyncCallback, _
ByVal extraData As Object) _
As System.IAsyncResult _
Implements System.Web.IHttpAsyncHandler.BeginProcessRequest
context.Response.Write("<p>Begin IsThreadPoolThread is " _
& Thread.CurrentThread.IsThreadPoolThread & "</p>" & vbCrLf)
Dim asynch As New AsynchOperation(cb, context, extraData)
asynch.StartAsyncWork()
Return asynch
End Function
Public Sub EndProcessRequest(ByVal result As _
System.IAsyncResult) _
Implements System.Web.IHttpAsyncHandler.EndProcessRequest
End Sub
Public Sub ProcessRequest(ByVal context _
As System.Web.HttpContext) _
ASP.Net
33
Implements System.Web.IHttpHandler.ProcessRequest
Throw New InvalidOperationException()
End Sub
End Class
Class AsynchOperation
Implements IAsyncResult
Private _completed As Boolean
Private _state As [Object]
Private _callback As AsyncCallback
Private _context As HttpContext
ReadOnly Property IsCompleted() As Boolean _
Implements IAsyncResult.IsCompleted
Get
Return _completed
End Get
End Property
ReadOnly Property AsyncWaitHandle() As WaitHandle _
Implements IAsyncResult.AsyncWaitHandle
Get
Return Nothing
End Get
End Property
ReadOnly Property AsyncState() As [Object] _
Implements IAsyncResult.AsyncState
Get
Return _state
End Get
End Property
ReadOnly Property CompletedSynchronously() As Boolean _
Implements IAsyncResult.CompletedSynchronously
Get
Return False
End Get
End Property
Public Sub New(ByVal callback As AsyncCallback, _
ByVal context As HttpContext, _
ByVal state As [Object])
_callback = callback
_context = context
_state = state
ASP.Net
34
_completed = False
End Sub
Public Sub StartAsyncWork()
ThreadPool.QueueUserWorkItem(New WaitCallback(AddressOf StartAsyncTask), Nothing)
End Sub
Private Sub StartAsyncTask(ByVal workItemState As [Object])
_context.Response.Write("<p>Completion IsThreadPoolThread is " &
Thread.CurrentThread.IsThreadPoolThread & "</p>" & vbCrLf)
_context.Response.Write("Hola mundo desde el controlador HTTP asíncrono!")
_completed = True
_callback(Me)
End Sub 'StartAsyncTask
End Class 'AsynchOperation
NOTA
Si en el co ntrolador HTTP requiere el estado de la sesión, tambi én tenemos que
implementar la interfaz IRequiresSessionState.
En ambos casos para registrar el controlador en el archivo Web.config. Si aún no
tenemos un archivo web.config en el sitio web, lo crearemos bajo la raíz del sitio y
agregaremos el siguiente código al archivo Web.config:
<configuration>
<system.webServer>
<handlers> <add verb="*" path="*.sample" name="HelloWorldHandler"
type="HelloWorldHandler"/> </handlers>
</system.webServer>
</configuration>
El elemento de configuración regis tra el controlador pers onalizado por nombre d e
clase y le asigna la extensión de nombre de archivo .sample.
ASP.Net
35
2. ADMINISTRACIÓN DE ESTADOS ASP.NET
Cada vez q ue la págin a se en vía al serv idor, se crea una nueva instancia de la
clase de la página Web. En la programación Web tradicional, esto significa que toda
la información asociada a la página y sus controles se pierden con cada recorrido de
ida y vuelta, para poder superar esta lim itación inherente de la programación Web
tradicional, ASP.NET incluye varias opciones que ayudan a preservar los datos en
cada página y en toda la aplicación.
Estas opciones pueden almacenarse en el cliente o en la memoria del servidor:
• Cliente
o Estado de vista
o Estado de control
o Campos ocultos
o Cookies
o Cadenas de consulta
• Servidor
o Estado de aplicación
o Estado de sesión
o Propiedades de perfiles
Estado de Vista: La propiedad ViewState propo rciona un objeto d e
diccionario para conservar valores entre las distintas solicitudes de una misma
página. Éste es el método predeterminado que la pág ina utiliza para conservar
los valores de las pr opiedades de la propia página y sus co ntroles entre
recorridos de ida y vuelta.
Cuando se procesa la página, se calcula el valor de hash del estado actual de la
página y de l os controles en una c adena y se guarda en la página como campo
oculto o varios campo s ocultos si el volumen de los da tos almacenados en la
propiedad ViewState sobrepasa el va lor especifica do en la propiedad
ASP.Net
36
MaxPageStateFieldLength. Cuando se vuelve a enviar la página al servidor,
ésta an aliza la caden a de est ado de v ista du rante su in icialización y la
información de las propiedades se restablece en ella.
Estado de control: La propiedad ControlState permite m antener la
información de las pro piedades q ue es específica de un control y que no se
puede desactivar como ocurre con la propiedad ViewState.
Esta propiedad es útil porque en ocasiones es necesario almacenar los datos del
estado de control simplemente para que un control funcione correctamente. Por
ejemplo, si ha escrito un co ntrol persona lizado con varias fichas que muestran
distintos tipos de información, el control debe saber la ficha que se selecciona en
los reco rridos de ida y vuelta para qu e funci one tal y como se espera. La
propiedad ViewState se pu ede u tilizar para este propósit o, pero los
desarrolladores pueden desactivar el es tado de vista en el nivel de página,
interrumpiendo su control eficazmente.
Campos ocultos: ASP.NET per mite almacenar i nformación en un control
HiddenField, que se representa como campo oculto estándar HTML. Un campo
oculto no está visib le en e l e xplorador, pero se pueden configurar sus
propiedades igual que las de un control estándar. Cuando se envía una página al
servidor, el contenido del campo oculto se envía en la colección Form de HTTP
junto con los valores de otros controles. Un campo oculto actúa como repositorio
de cualquier información específica de página que desee almacenar directamente
en la página.
Un control HiddenField almacena una única variable en su propiedad Value y
se debe agregar en la página de forma explícita. Para que los v alores de los
campos ocultos estén disponibles durante el procesamiento de la página, se debe
enviar med iante el método POST de HTTP. Si uti liza campos ocul tos y una
página se procesa como respuesta a un vínculo o a un comando GET de HTTP,
los campos ocultos no estarán disp onibles. Es fáci l que un us uario
malintencionado vea y modi fique el contenido de un campo oculto. No se deb e
almacenar ninguna i nformación que sea co nfidencial o en la que se base la
aplicación para funcionar correctamente en un campo oculto..
Cookies: Una cookie es una cantidad pequeña de datos que se almacena en un
archivo de texto en el sistema de archivos del cl iente o que se mant iene en la
memoria durante la sesión del explor ador cl iente. Contiene i nformación
ASP.Net
37
específica del s itio que el servidor envía al cl iente junto con el resultado de la
página. Las cookies pueden ser temporales (con fechas y horas de caducidad
específicas) o permanentes. L as cook ies s e pu eden u tilizar par a almacen ar
información acerca de un cliente, sesión o aplicación específicos. Las cookies se
guardan en el dispositivo cliente y, cuando el explorador solicita una
página, el cliente envía la información de la cookie junto con la
información de la solicitud. El servidor puede leer la cookie y extraer su valor.
Uno de los usos típicos es almacenar un símbolo (puede que cifrado ) que indica
que el usuario ya se ha autenti cado en la aplicación. Hay que tener en cuenta
que para tener seguridad en nuestra página, el explorador sólo puede devolver
los datos al servidor que cr eó la cookie, pero algunos usuarios malintencionados
cuentan con medios p ara tener acceso a las cookies y leer su contenido. Se
recomienda no almacenar información confidencial, como el nombre de usuario o
la contraseña, en una cookie. En su lugar, almacenaremos un símbolo (token)
en la cook ie que identifique al usuario y, a co ntinuación, utilizaremos el símbolo
para buscar la información confidencial en el servidor
Cadenas de consulta: Una cadena de consulta es información que se anexa
al final d e la dirección URL de una pá gina. Un ejemplo típico de cadena de
consulta podría tener el siguiente aspecto:
http://www.tienda.com/listaarticulos.aspx?categoria=basica&precio=100
En la rut a URL in dicada, la caden a de c onsulta em pieza por un signo d e
interrogación (?) e incluye dos pares de at ributo-valor, uno de ellos se denomina
"categoria" y el otro, "precio".
Las cadena s de cons ulta proporcionan una manera senci lla pero limitada de
mantener la información de estado. Por eje mplo, es una manera sencilla d e
pasar información de una página a otra, como pasar u n código de producto de
una página a otra donde se procesará. Sin embargo, en algunos exploradores y
dispositivos de cl iente la lon gitud de la d irección URL t iene u na l imitación de
2083 caracteres. Para que los valores de las cadenas de consulta estén
disponibles durante el procesamiento de la página, se debe enviar la página
utilizando el método GET de HTTP.
Es fáci l manipular l a información que se pasa entre una página a otra con l as
cadenas d e consul tas, así que l a mejor opci ón es no poner i nformación
importante o confidencial.
ASP.Net
38
Estado de aplicación: ASP.NET permite guardar valores utilizando el estado de
sesión, que es una instancia de la clase HttpApplicationState, de ca da
aplicación Web activa. El estado de aplicación es un mecani smo de
almacenamiento global al que se p uede obtener acceso desde todas las páginas
de la ap licación Web. Resu lta ú til para alma cenar la información q ue se debe
mantener en los recorridos de ida y vuelta del servidor y entre las solicitudes de
las páginas. Se almacena en un diccionario de tipo clave-valor que se crea
cada vez q ue se envía una solicit ud a una d irección URL específica. Se puede
agregar in formación específica de la ap licación a esta estructura para
almacenarla entre las peticiones de página, después de agregar esta información
específica d e la aplicac ión a estado de aplica ción, el ser vidor se en carga de
administrarla.
Estado de sesión: ASP.NET permit e gu ardar v alores utilizando e l est ado de
sesión, que es una instancia de la clase HttpSessionState, de cada sesión d e
una aplicación Web activa. Estado de sesión es sim ilar a estado de aplicac ión,
con la diferencia de que el ámbit o es la actual sesión del explo rador. Si hay
varios usuarios uti lizando l a apli cación, cada uno de ellos tendrá un estado de
sesión distinto y si un us uario sale de la a plicación y v uelve m ás t arde, e l
segundo usuario tendrá un estado de sesión distinto al del primero.
El estado de sesión ti ene la estructura de un diccionario de tipo clave-valor
para almacenar información espec ífica de cada sesión que se debe c onservar en
recorridos de ida y vuelt a del ser vidor, así como en tre solicitudes de págin as.
Puede utilizar el estado de sesión para llevar a cabo las tareas siguientes:
En función de las opc iones especificadas, la información de la ses ión se pu ede
almacenar en cookies, en un servidor que no forme parte del proce so, o en un
equipo que ejecute Microsoft SQL Server.
Propiedades de perfiles: Permite almacenar datos específicos del usuario. Esta
característica es similar al estado de sesión, salvo que los datos del perfil no
se pierden cuando caduca la sesión de un usuario. La característica
propiedades de perf iles utiliza un perf il ASP.NET, que se gu arda en un formato
persistente y que se asoci a con un usuari o específico. El perfil ASP.NET permite
administrar con facilid ad la información sobre el usuario si n que sea necesario
crear y ma ntener una base de datos propia. Además, el perfil hace que la
información del u suario est é dispon ible med iante un a AP I con est ablecimiento
ASP.Net
39
inflexible d e t ipos a la que puede obt ener acceso desde cualquier punto de la
aplicación. Se puede almacenar objetos de cualquier tipo en el perfil y est o
proporciona un sistema de almacenami ento genérico que permite definir y
mantener casi cualquier tipo de d atos mientras éstos sig an estando disponibles
en un modo de seguridad de tipos.
Para u tilizarlas debem os con figurar u n proveedor de p erfiles. ASP .NET in cluye
una clase SqlProfileProvider que permite almacenar los datos del perfil en una
base de datos de SQL, aunq ue también se puede crear una clase propia de
proveedor de perfiles que almacene los datos del perfil en un formato
personalizado y disponga de un mecanism o de almacenamiento personalizad o,
como un archivo XML o incluso un servicio Web.
3. ENRUTAMIENTO
El enrutamiento de ASP.NET permite usar direcciones URL s in tener que
asignarlas a archivos específicos de un sitio web. Como la dirección URL no tiene
que asignarse a un archivo, en una aplicación web se puede usar direcciones URL
descriptivas de la acción del usuario, y p or tanto, que l os us uarios puedan
identificar mejor.
En una apli cación ASP .NET que no u tiliza en rutamiento, una solicitud en trante de
una dirección URL normalmente se asi gna a un archivo físico en el disco como un
archivo .aspx.
En el enrutamiento ASP.NET, se definen modelos de dirección URL que contienen
marcadores de posición para los valores utilizados al administrar solicitudes URL.
En tiempo de ejecució n, las parte s de la dire cción URL que siguen al nombre de
aplicación se analizan como valores discretos, tomando como base un modelo de
dirección URL que haya definido. Por ejemp lo, en la solic itud de
http://server/application/Productos/disponibles/pasta, el analizador del
enrutamiento puede pasar los v alores P roductos, dispon ibles y t ornillos a un
controlador para l a sol icitud. Al c ontrario, en una sol icitud q ue no administre el
enrutamiento de direcciones URL, / Productos/disponibles/pasta se interpretaría
como la ruta de acceso de un archivo de la aplicación.
También pu ede u tilizar los mo delos de dirección URL para crear med iante
programación direcciones URL que corre sponden a las rutas. Esto permite
centralizar la lógica para crear hipervínculos en la aplicación ASP.NET.
ASP.Net
40
Esquema de enrutamiento de ASP.NET.
Hay tres re productores fundamentales en el motor de enrutamiento de direcció n
URL: rutas, controladores de ruta y el módulo de enrutamiento.
• Una ruta asocia una dirección URL a un controlador de ruta.
• Una insta ncia de la clase de ruta del espacio de nombres
System.Web.Routing representa una ruta durante el tiempo de e jecución
y describe los parámetros y restricciones de la ruta.
• Un controlador de ruta se hereda de la interfaz
System.Web.Routing.IRouteHandler. Esta interfaz requiere el
controlador de ruta p ara implementar un método GetHttpHandler que
devuelve un objeto que implementa la interfaz de IHttpHandler.
• El módulo intercepta las solic itudes entrantes, examina la dirección URL y
detecta si hay ruta s coincidentes de finidas. El módulo recuperará el
controlador de ruta asociada para una ruta coincidente y pedir al controlador
de enrutamiento que va a procesar la solicitud.
Figura 3.1
ASP.Net
41
Enrutamiento de ASP.NET frente a reescritura de direcciones URL
El enrutamiento de ASP.NE T es diferent e de otros esquemas de reescritura de
direcciones URL. La reescritura de direcciones URL procesa las petic iones
entrantes cambiando r ealmente la direcc ión URL antes de enviar la solicitud a la
página web , normalmente no se tiene una API para crear direcciones URL basadas
en sus modelos. En la reescritura de di recciones URL, si cambia un modelo de
dirección URL , deberá act ualizar man ualmente t odos los h ipervínculos qu e
contengan la dirección URL original.
Con e l enrutamiento de ASP.NET, la dirección URL no se cambia cuando se
controla una solicitud entrante, porque el enrutamiento puede extraer valores de la
dirección URL. Si tiene que crear una dirección URL, pase los valores del parámetro
a un métod o que gene re la d irección URL pa ra usted. Para cambiar el modelo de
dirección URL , cámbiel o en un a ubicación y t odos los vínculos que cree en la
aplicación basada en dicho modelo utilizarán automáticamente el nuevo modelo.
Definir rutas de dirección URL
Los modelos de dirección URL que se definen se conocen como rutas, en ellas
se especifican marcadores de posic ión que se asignan a valores que se analizan de
la sol icitud URL. También se pu eden especif icar valores constantes que se utilizan
para comparar solicitudes URL.
En u na rut a, se defi nen marcadores de posición (denominados parámetros
URL) encerrándolos entre corchete s ( { y } ). El carácter / se interpreta como un
delimitador cuando se analiza la dirección URL.
La información de la definición de la ru ta que no es un delimitador y que no e stá
encerrada entre corche tes se trata como un valor constante. Los valores que se
extraen entre los delimitadores se asignan a marcadores de posición.
Se puede definir más de un mar cador de posición entre los de limitadores, pero
deben ir separados por un valor constante.
Por ejemplo, {idioma}-{pais}/{action} es un modelo de ruta válido. Sin embargo,
{idioma}{pais}/{action} no es un modelo válido, porque no hay ninguna constante
o delimitador entre los marcadores de posi ción. Por lo tanto, el enrutamiento no
puede determinar dónde debe separar el va lor del marcador de posición language
del valor del marcador de posición pais.
En la tabla siguiente se muestran modelos de ruta válidos y ejemplos de solicitudes
URL que coinciden con los modelos.
ASP.Net
42
Definición de la ruta Ejemplo de dirección URL coincidente
{controlador}/{acción}/{id} /Productos/mostrar/comidas
{tabla}/Detalles.aspx /Productos/Detalles.aspx
blog/{acción}/{entrada} /blog/mostrar/123
{tipo_informe}/{año}/{mes}/{día} /sales/2008/1/5
{configuración regional}/{acción} /en-US/ mostrar
{idioma}-{país}/{acción} /en-US/ mostrar
Normalmente, se agregan rutas de un método que se llama desde el
controlador del evento Application_Start en el archivo Global.asax. Este
enfoque comprueba que las ru tas están disponibles cuando se in icia la ap licación.
También permite llamar directam ente al método cuando se realiz a una pr ueba
unitaria de la aplicac ión. Si queremos llam ar directamente a un método al rea lizar
una prueba uni taria de l a apli cación, el método que registra las rutas debe ser
estático (Shared en Visual Basic) y tener un parámetro RouteCollection.
En e ste ejemplo ver emos el código de un archivo Global.asax que agrega un
objeto Route que define dos parámetros URL denomi nados acti on y
categoryName.
Sub Application_Start(ByVal sender As Object, ByVal e As EventArgs)
RegisterRoutes(RouteTable.Routes)
End Sub
Shared Sub RegisterRoutes(routes As RouteCollection)
Dim urlPattern As String
Dim rutaCategoria As Route
urlPattern = " Categoria /{action}/{categoryName}"
rutaCategoria = New Route(urlPattern, New CategoryRouteHandler)
routes.Add(rutaCategoria)
End Sub
ASP.Net
43
Establecer los valores predeterminados de los parámetros de la ruta
Al definir una ruta, se puede asi gnar un valor predeterminado a un parámetro. El
valor predeterminado se utiliza si un valor de dicho parámetro no está incluido en la
dirección URL. Estos valores predeterminados de una ruta l os establecernos
asignando un diccionario a la propiedad Defaults de la clase Route.
En este ejemplo veremos una ruta con valores predeterminados.
Sub Application_S tart(ByVal se nder As Object , ByV al e As Even tArgs)
RegisterRoutes(RouteTable.Routes)
End Sub
Shared Sub RegisterRoutes(ByVal routes As RouteCollection)
Dim urlPattern As String
Dim rutaCategoria As Route
urlPattern = "Categoria/{action}/{categoryName}"
rutaCategoria = New Route(urlPattern, New CategoriaRouteHandler)
rutaCategoria.Defaults = New RouteValueDictionary(New With _
{.categoryName = "comida", .action = "mostrar"} )
routes.Add(categoryRoute)
End Sub
Cuando el enrutamiento de ASP.NET controla una solicitud URL, la definición de
ruta mostrada en el ejemplo (con los valo res predeterminados de comida p ara
categoryName y mostrar para action) genera los siguientes resultados.
DIRECCIÓN URL VALORES DE PARÁMETROS
/ Categoria action = "mostrar" (valor predeter minado)
categoryName = "comida" (valor predeterminado)
/ Categoria/add action = "agregar"
categoryName = "comida" (valor predeterminado)
/
Categoria/add/beverages
action = "agregar"
categoryName= "bebidas"
ASP.Net
44
Administrar un número variable de segmentos
A veces se tiene que controlar solicitudes URL que contienen un número variable
de segmentos de direc ción UR L. Al definir u na ruta , se puede especificar que el
último parámetro coincida co n el resto de la dirección URL marcando el parámetro
con un asterisco *. Esto se conoce como un parámetro comodín. Una ruta con un
parámetro comodín también coin cidirá co n las di recciones URL qu e no conti enen
ningún val or para el ú ltimo parámetro. E n el e jemplo siguiente se muestra un
modelo de ruta que coincide con un número de segmentos desconocido.
query/{queryname}/{*queryvalues}
Cuando el enrutamiento de ASP.NET controla una solicitud URL, la definición de la
ruta mostrada en el ejemplo gene ra los resultados que se enumeran en la tabla
siguiente.
DIRECCIÓN URL VALORES DE PARÁMETROS
/query/select/bikes/onsale queryname = "select"
queryvalues = "bikes/onsale"
/query/select/bikes queryname = "select"
queryvalues = "bikes"
/query/select queryname = "select"
queryvalues = Cadena vacía
Agregar restricciones a las rutas
Además de comparar una solicitud URL con una definición de ruta por el número de
parámetros de la dirección URL, se pu ede especificar que los valores de los
parámetros cumplan c iertas restricciones. Si una di rección URL co ntiene val ores
que están fuera de la s restriccio nes de una ruta, esa ruta no se uti liza para
administrar la so licitud. Se debe agregar restricciones para asegurarse de que los
parámetros URL contienen valores que funcionarán en la aplicación.
ASP.Net
45
Las restricciones se defi nen uti lizando expres iones regu lares u objet os qu e
implementan la interfaz IRouteConstraint. Al agregar la definición de la ruta a la
colección Routes, hay que agregar restricciones creando un objeto
RouteValueDictionary que contenga la prueba de comprobación. A continuación,
se asigna este objeto a la propiedad Constraints . La clave del d iccionario
identifica el parámetro al que se aplica la restricción. El valor del diccionario puede
ser o una cadena que representa un a expresión regular o u n objeto que
implementa la interfaz IRouteConstraint.
En este ejemplo se muestran restricciones que limitan qué valores se pueden incluir
en los parámetros “año” y “local”.
Shared Sub RegisterRoutes(ByVal routes As RouteCollection)
Dim urlPattern As String
Dim reportRoute As Route
urlPattern = "{local}/{año}"
reportRoute = New Route(urlPattern, New ReportRouteHandler)
reportRoute.Constraints = New RouteValueDictionary(New With _
{. local = "[a-z]{2}-[a-z]{2}", . año = "\d{4}"})
routes.Add(reportRoute)
End Sub
Cuando el enrutamiento controla una solicitud URL, la definición de ruta mostrada
en el ejemplo anterior genera los resultados que se enumeran en esta tabla
DIRECCIÓN
URL RESULTADO
/en-US Ninguna coincidencia. Se requieren las plantillas local y año.
/en-US/08 Ninguna c oincidencia. La restricción en año requiere 4
dígitos.
/en-US/2008 local = "en-US"
año = "2008"
ASP.Net
46
Cómo se comparan las direcciones URL con las rutas
Cuando e l enrutamiento controla solicitudes URL, intenta comparar la d irección
URL de la solicitud con una ruta. La comparación de una solicitud URL con una ruta
depende de todas las siguientes condiciones:
• Los modelos de ruta que se han definido o los modelos de ruta
predeterminados, si los hubiera, incluidos en el tipo de proyecto.
• El orden en que se agregaron a la colección Routes.
• Cualquier valor predeterminado que se haya proporcionado para una ruta.
• Cualquier restricción que se haya proporcionado para una ruta.
• Si se ha definido el enrutamiento para controlar solic itudes que coinciden
con un archivo físico.
Para evitar que el controlador equivocado administre una solici tud, se debe tener
en cuenta todas estas condiciones al defi nir r utas. El orden en que aparecen lo s
objetos Route en la colección Routes es importante. La comparación de las
rutas se real iza desde la prim era a la ú ltima ruta de la colecci ón y cuando existe
una coincidencia , no se evalúan más rutas.
Si una dirección URL no coi ncide con ni ngún objeto Route definido en la
colección RouteTable, el enrutamiento de ASP.NE T no procesará la solicitud y el
procesamiento se pas a a una página ASP.NET, servicio web u otro extremo
ASP.NET.
Crear direcciones URL a partir de rutas
Podemos utilizar rutas para generar dire cciones URL si querem os cen tralizar l a
lógica para crear direcciones URL. Una di rección URL se crea pasando valores d e
parámetro como un diccionario al método GetVirtualPath que b usca la primera
ruta del objeto RouteCollection que coincide con los parámetros del dicc ionario.
La ruta coincidente se utiliza para generar la dirección URL.
ASP.Net
47
Ejemplo 1: Definición de ruta.
Shared Sub RegisterRoutes(ByVal routes As RouteCollection)
routes.Add(New Route( _
"Categoria/{action}/{categoryName}", _
New RouteValueDictionary(New With _
{.categoryName = "comida", _
.action = "mostrar"}), _
New CategoryRouteHandler()) )
End Sub
Ejemplo 2: Control que crea una dirección URL basada en la ruta.
Dim urlParameters As RouteValueDictionary
urlParameters = New RouteValueDictionary(New With {.categoryName = "pasta", _
.action = "summarize"})
HyperLink1.NavigateUrl = RouteTable.Routes.GetVirtualPath _
(context, urlParameters).VirtualPath
Cuando se ejecuta este código, el co ntrol HyperL ink1 conte ndrá el valo r
"Categoria/summarize/pasta" de la propiedad NavigateUrl.
Al crear una di rección URL a parti r de una ruta, se puede especif icar qué ruta s e
debe utilizar incluyendo un nombre para la ruta.
ASP.Net
48
EJERCICIOS DE REPASO DE LA UNIDAD DIDÁCTICA 1: REVISANDO EL
DOCUMENTO
ENUNCIADOS.
1. ¿Cuántos niveles de compilación ocurren en .NET Framework?
2. ¿Cuáles de los siguientes lenguajes se pueden utilizar para escribir
Scripts del lado de servidor en ASP.Net?
3. Cuando una página .aspx es devuelta por el servidor, la salida se
enviará al browser o navegar con formato…
4. Los controladores se usan para procesar…
ASP.Net
49
SOLUCIONES A LOS EJERCICIOS DE REPASO. UNIDAD DIDÁCTICA 1
1. La frase correcta es: Uno
2. La respuesta correcta es: La D) A y B
3. La respuesta correcta es: HTML
4. La respuesta correcta es: Solicitudes de Extremos individuales y direcciones URL
HTTP o grupos de extensiones dentro de una aplicación.
ASP.Net
50
TEMA 2. CREACIÓN DE UN SITIO WEB
En estas d os lecc iones vamos aplicar de sde un punto más práctico lo aprendido
hasta ahora, creando una sencilla página web pero que nos ayudará a af ianzar los
conceptos hasta ahora aprendidos.
LECCIÓN 1. PLANEAMIENTO DE UN SITIO WEB EN ASP. NET
1. CICLO DE VIDA
1.1. CICLO DE VIDA DE UNA APLICACIÓN ASP.NET PARA IIS 5.0 E IIS 6.0
En A SP.NET, deben producirse varios pasos de procesamiento para que una
aplicación ASP.NET se inic ialice y procese las solicitudes. Además es sólo una
parte de la arquitectura de servidor Web que atiende las solicitudes
realizadas por los exploradores. Es importante que c omprendamos el ciclo de
vida de la aplicación para que sep amos donde escribir código en la fase apropiada
del ciclo y conseguir el efecto deseado.
El ciclo de vida de una aplicación ASP.NET consta principalmente de 5 fases:
1ª Fase: El usuario solicita un recurso de aplicación del servidor Web, esta
acción se inicia con una so licitud enviada por un explorad or al servidor Web (p ara
las aplicaciones ASP.NET, norm almente es IIS). ASP.NET es una extensión
ISAPI (archivo DLL que puede cargarse y se r llamado por un servidor HTTP) bajo
el servidor Web. Cuando un servidor web recibe una solicitud, examina la extensión
de nombre de archivo del archiv o solicitado, determ ina la ex tensión ISAPI que
debería procesar dicha soli citud y, a conti nuación, pasa ésta a l a extensión ISAPI
apropiada. ASP.NET pr ocesa las extensio nes de nombr e de archivo que tiene
asignadas, como .aspx, .ascx, .ashx y .asmx.
2ª Fase: ASP.NET recibe la primera solicitud para la aplicación. Cuando
ASP.NET recibe la pr imera so licitud para cualqu ier rec urso de u na apl icación, la
clase ApplicationManager crea un dominio de aplicac ión. Los dominios de
aplicación proporcionan aislamiento entre aplic aciones para las variables globales
y permiten descargar cada aplicación de forma i ndependiente. Dentro de u n
dominio de aplicac ión, se crea u na in stancia de la clase HostingEnvironment,
que proporciona acceso a la in formación sobre la aplicac ión, como el n ombre de la
carpeta en la que está almacenada la aplicación.
ASP.Net
51
Figura 1.1
3ª Fase: Se crean los objetos de núcleo ASP.NET para cada solicitud
Una vez creados el dominio de aplicación y una instancia del objeto
HostingEnvironment, ASP.NET crea e inicializa los objetos de núcleo:
• La clase HttpContext contiene objetos específicos de la solicitud de aplicación
actual, como los objetos HttpRequest y HttpResponse.
• El objeto HttpRequest contiene datos sobre la so licitud actual, entre los que
se incluyen las cookies e información del explorador.
• El objeto HttpResponse contiene la respuesta que se envía al cliente, la cual
incluye todos los resultados representados y las cookies.
4ª Fase: Se asigna un objeto HttpApplication a la solicitud.
Una vez que se h an inicializado todos los objet os principales de la a plicación, ésta
se inicia creando una instancia de la clase HttpApplication. Si la aplicac ión tiene
un archivo Global.asax, ASP.N ET crea una instancia de la clase Global.asax
derivada de la clase HttpApplication y la utiliza para representar la aplicación.
Cuando se crea una instancia de HttpApplication, también se crean los módulos
configurados.
ASP.Net
52
Por ejemplo, si la aplicación está configurada para ello, ASP.NET crea u n módulo
SessionStateModule. Una vez cr eados todos los módulos configur ados, se llama
al método Init de la clase HttpApplication.
Figura 1.2
5 ª Fase: La canalización de HttpApplication procesa la solicitud.
La clase HttpApplication ejecuta los eventos siguientes mientras se procesa la
solicitud, estos eventos son import antes si queremos extender la clase
HttpApplication.
El proceso de esa solicitud se realiza de la siguiente manera:
1. Valida la so licitud, que examina la información enviada por el ex plorador y
determina si contiene formato potencialmente malintencionado.
ASP.Net
53
2. Realiza l a asignación de di recciones URL si se ha confi gurado alguna
dirección URL en la sección UrlMappingsSection del archivo Web.config.
3. Produce los eventos BeginRequ est, Aut henticateRequest,
PostAuthenticateRequest, Au thorizeRequest, Post AuthorizeRequest,
ResolveRequestCache, PostResolveRequestCache
4. Basándose en la extensión de nombre de archivo del recurso s olicitado
(asignada en el arch ivo de con figuración de la ap licación), seleccion a u na
clase que implemente IHttpHandler para procesar la solic itud. Si la solicitud
es para un objeto (página) derivado de la clase Page y es necesario compilar
la página, ASP.NET la compila antes de crear una instancia de ella.
5. Produce los evento s PostMapRequest Handler, AcquireRequestState,
PostAcquireRequestState, PreRequestHandlerExecute
6. Llama a l mét odo P rocessRequest ( o a la versión a sincrónica
IHttpAsyncHandler..::.BeginProcessRequest ) de la clase IHt tpHandler
apropiada para la solicitud. Por ejemplo, si la solicitud es para una página, la
controla la instancia de la página actual.
7. Produce lo s eventos PostRequestHandl erExecute, Re leaseRequestState,
PostReleaseRequestState
8. Realiza el filtrado de respuestas si se define la propiedad Filter.
9. Produce los evento s UpdateReques tCache, PostUp dateRequestCache,
EndRequest, PreSendRequestHeaders, PreSendRequestContent
Los eventos y el archivo global.asax
Durante el ciclo de vida de la aplicación, ésta produce eventos que se pue den
controlar y llama a determinados mét odos que se pueden reemplazar. Para
controlar estos eventos y méto dos, se p uede crear un arc hivo denominad o
Global.asax en el directorio raíz de la aplicación.
Si se crea un archivo Global.asax, ASP.NET lo comp ila en una clase derivad a de
la clase HttpApplication y, continuación, utiliza la clase derivada para representar
la aplicación.
Una instancia de HttpApplication no puede p rocesar va rias so licitudes
simultáneamente. E sto simp lifica el con trol de los eventos de la aplicación, dado
que no es necesario b loquear los miembros no estáticos de la clase de aplicación al
tener acceso a ellos. Esto t ambién permit e almacen ar datos específicos de la
solicitud en miembros no estáticos de la clase de aplicación. Por ejemplo,
puede definir una pr opiedad en el ar chivo Gl obal.asax y asi gnarla un val or
específico de la solicitud.
ASP.Net
54
ASP.NET enlaza automáticamente los evento s de aplicac ión a los controladores en
el archiv o Global.asax me diante la conve nción de nomenclatura
Application_evento; por ejemplo, Application_BeginRequest.
Los métodos Application_Start y Application_End son métodos especiales que
no representan eventos HttpApplication. ASP.NET los llama sólo una vez dura nte
el período de duración del dominio de aplicación, no para cada instancia de
HttpApplication.
En esta tab la se muestran l os eventos principales que se u tilizan, hay muchos
más pero realmente c asi no se utilizan , así que nos q uedamos con estos que son
los verdaderamente importantes.
EVENTO O MÉTODO DESCRIPCIÓN
Application_Start Se le llama cuando se solicita el primer recurso (por ejemplo, una
página) en una aplicación ASP.NET. Sólo se llama una vez durante
el ciclo de vida de una aplicación.
Application_event Se produce en el mome nto adecuad o del ci clo de vi da de l a
aplicación. Application_Error s e puede p rovocar en c ualquier fa se
del ciclo de vida de la aplicación.
Application_EndRequest e s el úni co evento cuya ejecuci ón se
garantiza en cada solicitud, dado que ésta se puede cortocircuitar.
Init Se le llama una vez para cada instancia de la clase HttpApplication
una vez que se han creado todos los módulos.
Dispose Se le llama antes de que se destruya la instancia de aplicación. Se
puede util izar este método para li berar manualmente cual quier
recurso no administrado.
Application_End Se le llama una vez durante el período de duración de la aplicación
antes de que ésta se descargue.
Ciclo de vida de la compilación
Cuando se real iza la primera sol icitud a u na aplicación , ASP .NET compila los
elementos de la aplica ción en un orden específico. Los primer os elementos que se
van a compi lar se denomi nan elementos de nivel superior. Después de la
ASP.Net
55
primera solicitud, se v uelven a c ompilar los elementos de nive l s uperior só lo s i
cambia una dependencia.
Después de compilar los elementos de ni vel superi or de l a aplicación, ASP.N ET
compila las carpetas, páginas y otros elementos según sea necesario.
Los ensamblados compilados se almacenan en la memoria caché del servidor, se
vuelven a utilizar en solic itudes su bsiguientes y se conservan al rein iciarse la
aplicación siempre y cuando permanezca sin modificar el código fuente.
Dado que la aplicación se comp ila con la primera solicitud, la sol icitud inicial a una
aplicación puede tardar bastante más que las solicit udes subsigu ientes. Se pued e
precompilar la aplicación para reducir el tiempo requerido para la primera solicitud.
Tabla de orden de compilación de los elementos nivel superior
ELEMENTO DESCRIPCIÓN
App_GlobalResources Se compilan los recursos globales de la aplicación y se
genera un e nsamblado de recursos. Los ensambl ados
ubicados e n la c arpeta Bin d e la a plicación están
vinculados al ensamblado de recursos.
App_WebResources Se crean y se compilan los tipos de servidor proxy para
los s ervicios W eb. El e nsamblado de r eferencias Web
resultante está vinculado al ensamblado de recursos, si
existe.
Propiedades de perfil
definidas en el archivo
Web.config
Si hay propiedad es d e p erfil defi nidas en el arc hivo
Web.config de l a apli cación, se genera un ensamblado
que contenga un objeto de perfil.
App_Code Se generan los archivos de código fuente y se crea uno
o vari os en samblados. Todos l os ensambl ados de
código y el ensamblado de perfi les están vi nculados a
los ensamblados de rec ursos y refe rencias Web, si
existen.
Global.asax Se compila el objeto de aplicación y s e vincula a todos
los ensamblados previamente generados.
ASP.Net
56
Tabla de orden de compilación de las carpetas y los elementos de ASP.NET.
ELEMENTO DESCRIPCIÓN
App_LocalResources Si la carpet a que co ntiene el ele mento
solicitado in cluye u na carpeta
App_LocalResources, se compila el
contenido de la carpeta de recursos
locales y s e vincula al ensamblado de
recursos globales.
Páginas Web individuales
(archivos .aspx), controles de
usuario (archivos .ascx),
controladores HTTP (archivos
.ashx) y módulos HTTP (archivos
.asmx)
Se compilan según sea necesario y se
vinculan al ensamblado de recursos
locales y a los ensamblados de nivel
superior.
Temas, páginas principales, otros
archivos de código fuente
Los archivos de máscara para temas
individuales, páginas principales y otros
archivos de código f uente a los que
hacen referencia las páginas se
compilan u na v ez compilada la página
que hace referencia.
1.2. CICLO DE VIDA DE UNA PAGINA ASP.NET
Hemos visto en el ciclo de vida de una aplicación ASP.NET las fases por la que debe
pasar, pero estas fases se producen ante s y d espués de una sol icitud pero no son
específicas de una página. Por eso es necesario saber las fases de la propia página,
para que al igual que en la aplicación podamos escribir el código en la fase del ciclo
de vida apropiado.
Cuando se ejecuta una página ASP.NE T, és ta recorre un ciclo de vida en el q ue
realiza una serie de pasos de procesamiento. En tre ellos se in cluyen la
inicialización, la creación de instancias d e controle s, la restauración y el
ASP.Net
57
mantenimiento del est ado, la e jecución del c ódigo del controlador de eventos y la
representación.
En términos generales, la página recorre las siguientes fases:
1ª Fase: Solicitud de página. La solicitud de página se produce antes de que
comience el cic lo de vida de la página. Cuando un usuario solicita la página,
ASP.NET determina si ésta se debe analizar y compilar (a fin de que comience el
ciclo de v ida de la página) o si se puede enviar una vers ión en caché de l a página
como respuesta sin ejecutar la página.
2ª Fase: Inicio En el paso de inicio, se establecen las propiedades de la página,
como Request y Response. En esta fase, l a pági na tambi én determi na si la
solicitud es u na devolución de datos o una nueva solicitud, y establece la
propiedad IsPostBack. Además, durante esta fase se establece la propiedad
UICulture de la página.
3ª Fase: Inicialización de página Durante la inicialización de la página, los
controles incluidos en ella están disponibles y se establece la propiedad UniqueID
de cada uno de ellos. Además, se aplican los temas correspondi entes a l a página.
Si la solicitud actual es una devoluc ión de datos, los datos de devolución aún no se
han cargado y los valores de las propiedades del control no se han restaurado a los
valores del estado de vista.
4ª Fase: Carga Durante la carga, si la solicitud actual es una devolución de datos,
las propied ades del control se car gan co n información recuperada del estado de
vista y del estado del control.
5ª Fase: Validación Duran te la validación, se lla ma al método Validate de
todos los controles de validación, que establece la propiedad IsValid de cada uno
de los controles de validación y de la página.
6ª Fase: Control de eventos de devolución de datos Si la solicitud es u na
devolución de datos, se llama a los controladores de eventos.
7ª Fase: Representación Dura nte l a representación, el estad o de vista se
guarda en la página y, a co ntinuación, ésta llama a cada uno de los controles para
que aporte su salida representada al valor OutputStream de la propiedad
Response de la página.
8ª Fase: Descarga Se llama a la descarga cuando la página se ha representado
completamente, se ha enviado al cliente y está lista pa ra ser descartada. Llegad o
ASP.Net
58
este mome nto, se descargan las propiedades de la página, como Response y
Request, y se llevan a cabo las operaciones de limpieza correspondientes.
Eventos del ciclo de vida
Dentro de cada fase d el ciclo de vida de una página, se produce eventos que
puede controlar para ejecutar su propio código. E n los eventos de control, el
controlador de suceso s se debe enlazar al evento, bien mediante declarac ión
utilizando atributos como onclick o bien en el código.
Las pági nas tambi én admi ten la conexión automática de eventos, l o que
significa que ASP.NE T busca métodos co n nombres determinados y los ejecu ta
automáticamente cuando se prod ucen ciertos eventos. Si el atributo
AutoEventWireup de la directiva @ Page se establece en true (o si no está
definido, ya que de forma predeterminada es true), l os eventos de página s e
enlazan de f orma au tomática a los m étodos qu e ut ilizan la c onvención de
nomenclatura Page_event, por ejemplo Page_Load y Page_Init.
ASP.Net
59
En esta tabla se muestran l os eventos más utilizados, aunque hay muchos más
normalmente no se uti lizan ya que son eventos que usa el servidor p ara el control
de las páginas.
EVENTO DE PÁGINA USO TÍPICO
Page_PreInit Aquí u tilizaremos la propiedad IsPostBack para
determinar si ésta es la primera vez que se procesa
la página.
Crear o volver a crear controles dinámicos.
Establecer una página maestra de forma dinámica.
Establecer la propiedad Theme de forma dinámica.
Leer o establecer los valores de las propiedades de
perfil.
Page_Init Leer o inicializar las propiedades de los controles.
Page_Load Leer y actualizar las propiedades de los controles.
Control events Realizar el procesamiento específico de la aplicación:
Si la pági na conti ene control es de vali dación,
comprobamos la propiedad IsValid de la página y de
cada uno de los controles de v alidación antes de
realizar cualquier procesamiento.
Controlar un evento específico; po r ejemplo, para e l
control Button, el evento Click.
Page_PreRender Realizar los cambios f inales en e l con tenido de la
página.
Page_Unload Llevar a ca bo el trabajo de limpieza f inal, que podr ía
incluir:
El cierre de los archivos ab iertos y de las conex iones
a bases de datos.
La f inalización del r egistro o de ot ras t areas
específicas de cada solicitud.
ASP.Net
60
2. CREANDO UNA PAGINA WEB
Aunque las páginas Web ASP.NET se crean de forma similar a las páginas Web
HTML estáticas (pági nas que no conti enen procesami ento basado en servi dor),
incluyen elementos adicionales que ASP.NET reconoce y procesa cuando se ejecuta
la página. Las caracte rísticas que dist inguen las páginas Web ASP.NET de las
páginas HTML estáticas (u otras) son las siguientes:
• La extensión de nombre de archivo .aspx en lugar de .htm, .html u
otras extensiones. L a extensi ón de nombre de archi vo .aspx ha ce que
ASP.NET procese la página, la as ignación de estas extensiones de nombre
de archivo a ASP.NET se realiza en Inte rnet Information Services (IIS), por
defecto ASP.NET ejecuta las páginas .aspx y no las páginas .htm y .html.
• Una directiva @ Page u otra directiva opcional, según convenga para el
tipo de página que se está creando.
• Un elemento form que está configurado correctamente para ASP.N ET. El
elemento form sólo es necesario si la pág ina contiene controles cuyo s
valores se deben utilizar durante el procesamiento de páginas.
• Controles de servidor Web.
• Código del servidor si agrega su propio código a la página.
Directivas
Las directivas permiten especificar las propiedade s de la página y la información
de configuración para ést a. ASP.NET utiliza las directivas como in strucciones sobre
el modo en que se debe procesar la página, pero no se representan como parte del
formato que se envía al explorador.
La directiva que se utiliza normalmente es @ Page, que permite especificar muchas
opciones de confi guración para l a pá gina, entre las que se encuentran las
siguientes:
• Lenguaje de programación del servidor para el código de la página.
• Si se trata de una página en la que se ha incluido directamente el código del
servidor, denomi nada página de un solo archivo, o si se trata de una
página en la que el cód igo s e ha inclu ido en un archivo d e clase
independiente, denom inada página de código subyacente (code
ASP.Net
61
behind). La página d el ejemplo anterior es de un solo archivo; el código
está directamente en la página y la directiva @ Page no incluye
información sobre archiv os de clase v inculados. Opciones de depur ación y
seguimiento.
• Si la página tiene una página maestra asociada y, por consiguiente, debe
tratarse como una página de contenido.
Si no se incluye ninguna directiva @ Page en la página o si la directiva no incluye
una con figuración especí fica, la conf iguración se hereda del archi vo de
configuración de l a aplicación Web (archivo Web.config) o del archivo de
configuración del sitio (archivo Machine.config).
Además de in cluir la directiva @ Page, también se pueden in cluir otras directivas
que admiten opciones adicionales específicas de la página como son:
• @ Import Esta directiva permite especificar los espacios de nombres a
los que se desea hacer referencia en el código.
• @ OutputCache Esta directiva permite especificar que la página se debe
almacenar en la memoria caché, junto con los parámetros que indican
cuándo y cuánto tiempo debe permanecer almacenada.
• @ Implements Esta directiva permite es pecificar que la página debe
implementar una interfaz .NET.
• @ Register Esta directiva permite registrar controles adicionales para
su uso e n la página, declara el pref ijo de la et iqueta del con trol y l a
ubicación de su en samblado. Si queremos agregar controles de usuario o
controles ASP .NET person alizados a un a págin a debemos u tilizar est a
directiva.
Algunos tipos de archivos ASP.NET utilizan otras directivas distintas de @ Page. Por
ejemplo, la s páginas maestras ASP .NET utilizan la d irectiva @ Master y l os
controles de u suario ASP.NET ut ilizan la direct iva @ Control. Cada directiva
permite especificar opciones distintas adecuadas para el archivo.
Elementos de formulario
Cuando queremos incluir controles que permiten a los u suarios in teractuar con la
página y enviarla, debemos i ncluir un elemento form. Au nque se uti liza el
ASP.Net
62
elemento form de HTML estándar, se deben cumplir ciertas reglas para utilizar este
elemento:
• La página sólo puede contener un elemento form.
• El elemento form debe contener el atributo runat establecido con el valor
server. Este atributo permite hacer refere ncia al f ormulario y los cont roles
de la página mediante programación en código del servidor.
• Los controles de servidor que pueden realizar devolución de dato s deben
estar dentro del elemento form.
• La etiqueta de apertura no d ebe conten er ni ngún atributo action.
ASP.NET e stablece es tos atributos di námicamente cuando se pr ocesa la
página y reemplaza cualquier configuración que se pueda establecer.
Controles de servidor Web
En la mayoría de las páginas ASP.N ET te ndremos que agregar controles qu e
permitan a l usuario in teractuar con la pá gina, como botones, cuad ros de texto,
listas, etc. Estos controles de servidor Web son parecidos a los botones y los
elementos input de HTML. Pero éstos se procesan en e l servidor, lo que permite
utilizar e l c ódigo de l s ervidor par a est ablecer su s propi edades. E stos con troles
también provocan eventos que se pueden controlar en el código del servidor.
Los controles de servidor u tilizan una si ntaxis especial que ASP.NE T reconoce
cuando se ejecuta la página. En este ejem plo se muestran algunos de los controles
de servidor Web que se emplean normalmente.
<asp:TextBox ID="TextBox1" runat="server"></asp:TextBox>
<asp:Button ID="Button1" runat="server"
Text="Click" OnClick="Button1_Click" />
Código del servidor
La mayoría de las pág inas ASP.NET incluyen código que se ejecuta en el servidor
cuando se procesa la página. ASP.NET admite un gran número de lenguajes, entre
los que se encuentran C#, Visual Basic, J#, Jscript y otros.
ASP.NET admite dos modelos a la hora de es cribir el código del servidor para una
página Web. En el modelo de un s olo archivo, el código de la página se encuentr a
ASP.Net
63
en un elemento script cuya etiqueta de apertura incluye el atributo
runat="server". Opcionalmente, podemos crear el código para la página en un
archivo de clase independiente al que se hace referencia como modelo de código
subyacente. En este caso, la p ágina Web ASP .NET general mente NO conti ene
código del servidor, vez de eso la d irectiva @ Page incluye información que vincula
la página .aspx co n su archivo de códi go subyacente asociado. E n este ejemplo
vemos una directiva @ Page típ ica para una página con un arc hivo de có digo
subyacente.
<%@ Page Language="VB" CodeFile="Default.aspx.vb" Inherits="Default" %>
El atributo CodeFile especifica el nombre d el archivo de clase independiente y el
atributo Inherits es pecifica el nombre de la c lase del archivo de código
subyacente que corresponde a la página.
Ahora que ya tenemos suficiente información, vamos a crear ahora nuestra primera
página con código ASP.NET. Será un sencillo ejemplo para saber cómo se ejecutan
estas páginas y así rep asamos la ejecución otra vez. Vamos al editor de páginas y
nos situamos en la edición de la página de ejemplo "default.aspx"
Activamos la vi sta en códi go fuente seleccion ando de las solapas de debajo la que
pone "Source" y escribimos lo siguiente:
Figura 2.1
ASP.Net
64
En esta im agen vemos que al empezar a escribir una función nos aparece una
ventana con las posibles opciones que tenem os a la hora de introducir código, esta
ventana es IntelleSense y nos ayuda a sa ber todos los métodos, propiedades,
atributos etc. que pod emos utilizar cu ando est amos e scribiendo código en una
página A>Sp.NET
Una vez escrito pulsaremos en ejecutar la página:
Figura 2.2
El resultado se puede observar en la figura 2.3
Figura 2.3
"Now" es una función que devuelve la fech a y hora del s istema. Veamos lo que ha
pasado... Nuestro servidor web a ejecutado la página, esto es, ha localizado e l
código ASP.NET que hemos insertado y lo ha ejecutado antes de devolver la página.
ASP.Net
65
Como en e ste caso er a una simple llamada a la f unción Now, le h emos dicho con
ese código que devuelva el resultado de ejec utar esa función, y por tanto , la fecha
y hora que ves en pan talla. Esto es la ejecución del lado del servidor, o l o que
es lo mism o, la ejecución de una página por el servidor de páginas web. Si
hubiésemos ido por el explorador de arch ivos y le h ubiésemos dicho que abriera
esa página, no habría funcionado porque debe pasar por el servidor web para poder
hacer esa ejecución.
El otro tipo de ejecución es la del "lado del cliente", es decir código que está
dentro de la página pero que se ejecuta en el Internet Explorer. Este código es muy
distinto ya que solo hace pequeñas operac iones sobre el código de la página. Este
código se suele escribir en Java o en Javascript y no tiene comparación en cuanto a
potencia porque no tenemos a nue stra disposición todas las funciones de ASP.N ET
ejecutándose en el servidor.
ASP.NET es tá pues conectado co n un servidor que puede ser un IIS, co mo
seguramente sea cuando esté en func ionamiento nuestra aplicación web o
ejecutándose con el m iniservidor web que nos ofrece e l entorno de desarrollo
integrado.
Una vez hayamos termi nado nu estro si tio web tendre mos que c olocarlo desde
nuestro equipo, donde lo hemos creado y pu esto a prueba al servidor principal con
IIS. Es decir copiar el web de nue stro disco duro al del s ervidor web. Tendremo s
que realizar dos sencillos pasos:
1. Crear un directorio virtual en el servidor
2. Copiar el sitio web completo
Antes de copiarlo debemos desactivar todo el código que hayamos puesto para
depuración y que veremos mas adelante. Pa ra real izar esta labor n os iremos a l a
opción de publicar web en el menú "Sitio Web":
ASP.Net
66
Figura 2.4
Figura 2.5
ASP.Net
67
Primero debemos conectarnos al destino pulsando el botón de arriba de "Conectar":
Tenemos varias opciones.
• Si elegimos Sistema de archivos (File System) necesitaremos indicarle
simplemente la carpet a destino. Si tenemos mapeada en una unidad la
ruta del servidor será una forma sencilla
• ISS Local lo instalará en el servidor web IIS de nuestro equipo. Esto es
útil si hemos estado desarrollando en el propio Windows Server, que no es
habitual. Esta opción la utilizaremos poco ya que es muy poco común.
• Sitio FTP. Copia los fichero mediante el protocolo de transferencia d e
ficheros FT P. Los datos que nec esita para conectarnos son los de un
servidor con el servicio FTP hab ilitado, una carpeta como destino y los
"credenciales" para poder copiar. Normalmente los sitios FTP no s on de
escritura por eso tendremos que dispon er de una c uenta con acceso de
escritura. Este sistema es muy común c uando tenemos nues tro web
alojado fuera de nuestra empresa. Por ejemplo, realizamos los desarrollos
en local o e n nuestra e mpresa pero el servidor de explotación está en un
proveedor de Internet. És te nos habrá comunicado nuestra cuenta de FTP
para que podamos transferir allí el web y los sucesivos cambios que
realicemos en él.
ASP.Net
68
Figura 2.6
• Sitio remoto. Es la opción mas habitual si tenemos u n IIS funcionando en
nuestra web, nos podremos conectar a él para transferir con en esta utilidad
las páginas (Ver figura 2.7).
ASP.Net
69
Figura 2.7
Una vez seleccionada el t ipo de conexión que se qui era realizar, el funcionamiento
es muy sencillo ya que solamente seleccionaremos las partes que queremos mover
y pulsaremos en la f lecha de la di rección que queremos move r. Una buena técnica
que hay que tener en cuenta es realizar una copia de seguridad antes de este
proceso.
Figura 2.8
ASP.Net
70
3. CONTROLES
Los controles de ASP.NET son ob jetos de páginas web ASP.N ET q ue se ejecutan
cuando se s olicita la página y que representan marcado e n un explorador. Muchos
controles son similares a elementos HTML conocidos, como botones y c uadros de
texto. Otros controles abarcan comportamiento complejo, por ejemplo controles de
calendario y controles que administran las conexiones de datos.
3.1. CONTROLES DE USUARIO
Un control de usuario es un ti po de contro l compuesto que f unciona de for ma
similar a la de una pági na Web ASP.NET: se pueden agregar controles de servidor
Web y mar cado a u n control de usuari o, así como definir propied ades y métodos
para el control. Desp ués se p ueden in crustar en páginas Web A SP.NET, do nde
actúan como una unidad.
Los controles de usuario ASP.NET se crean casi de la misma forma en la que se
diseñan l as páginas Web ASP.NET. Se pueden usar los m ismos ele mentos y
controles HTML en un control de usuario que en una pági na ASP.NET estándar. Sin
embargo, el control de usuario no tiene elementos html, body ni form; además,
la extensión de nombre de archivo debe ser .ascx.
Para crear un control de usuario ASP.NET
1. Abrimos el proyecto de sitio Web al que queramos agregar controles d e
usuario. Si aún no tenemos ningún proyecto de sitio Web lo crearemos.
2. En el menú Sitio Web, hacemos clic en Agregar nuevo elemento.
Aparecerá el siguiente cuadro de diálogo:
ASP.Net
71
Figura 3.1
3. Hacer clic en Control de usuario Web.
4. En el cuadro Nombre, escribiremos un nombre para el control.
De forma p redeterminada, la extensión de no mbre de archivo .ascx se anexa
al nombre de control que escriba.
5. En la list a Lenguaje, seleccionaremos el lenguaje de programación que
queramos utilizar, en nuestro caso Visual Basic.
6. Opcionalmente, si queremos mantener al gún código del control de usuari o
en un archi vo independiente, activaremos la casilla Colocar el código en
un archivo independiente.
7. Hacemos clic en Agregar.
De esta manera crearemos el nuevo contro l de usuario ASP.NET y, a continuación,
se abre en el diseñador. El código de formato para este nuevo control es similar al
de una pági na Web ASP.NET, salvo que conti ene una directiva @ Control en vez
de una directiva @ Page.
En este ejemplo vemos un control de usuario que implementa un control de número
en el que los usuarios pueden hacer clic en los botones arriba y abajo para mostrar
varias opciones de un cuadro de texto.
ASP.Net
72
<%@ Control Language="VB" ClassName="UserControl1" %>
<script runat="server">
Protected colors As String() = {"Red", "Green", "Blue", "Yellow"}
Protected currentColorIndex As Integer = 0
Protected Sub Page_Load(ByVal sender As Object, _
ByVal e As System.EventArgs)
If IsPostBack Then
currentColorIndex = CInt(ViewState("currentColorIndex"))
Else
currentColorIndex = 0
DisplayColor()
End If
End Sub
Protected Sub DisplayColor()
textColor.Text = colors(currentColorIndex)
ViewState("currentColorIndex") = currentColorIndex.ToString()
End Sub
Protected Sub buttonUp_Click(ByVal sender As Object, _
ByVal e As System.EventArgs)
If currentColorIndex = 0 Then
currentColorIndex = colors.Length - 1
Else
currentColorIndex -= 1
End If
DisplayColor()
End Sub
ASP.Net
73
Protected Sub buttonDown_Click(ByVal sender As Object, _
ByVal e As System.EventArgs)
If currentColorIndex = colors.Length - 1 Then
currentColorIndex = 0
Else
currentColorIndex += 1
End If
DisplayColor()
End Sub
</script>
<asp:TextBox ID="textColor" runat="server"
ReadOnly="True" />
<asp:Button Font-Bold="True" ID="buttonUp" runat="server"
Text="^" OnClick="buttonUp_Click" />
<asp:Button Font-Bold="True" ID="buttonDown" runat="server"
Text="v" OnClick="buttonDown_Click" />
Hay que te ner en cuenta que el control de usuari o es muy similar a u na pág ina
ASP.NET, y a que conti ene vari os controles (un co ntrol TextBox y dos controles
Button) y código que controla los eventos Click de los boton es y el ev ento Load de
la página. Sin embargo, el control no contiene ningún formato, excepto p ara
los controles.
Agregar un control de usuario a una página
Para agregar un control de usuario a una página es necesario registrarlo primero
en la página que aloja el control (o página host). Al hacerlo, se debe
especificar el archivo .ascx que conti ene e l control , así como un prefi jo y un
nombre de etiqueta que se utilizarán para declarar el control en la página.
Definir propiedades y métodos para un control de usuario
Se puede definir prop iedades y métodos pa ra un con trol de usuari o de la misma
manera que l o haríamos para una pági na. La definición de una propiedad para un
ASP.Net
74
control de usuari o permite establecer sus propiedades mediante declaración
y en el código.
Eventos de los controles de usuario
Si un control de usuario contiene controles de servidor Web, es pos ible
escribir cód igo en dic ho control para contro lar los eventos prod ucidos por los
controles secundarios. Por ejempl o, si nuestro cont rol de usuari o contiene un
control Button, se puede crear un controlador en el control de usuario para el
evento Click del botón.
Por defecto, los eventos producidos por los controles secundarios en un
control de usuario no están disponibles para la página host. Pero si es
posible definir en el c ontrol de usuari o eventos y producirlos de modo que se
notifiquen a la página host. Esto se hace de la misma manera que la definición de
eventos para una clase.
Hacer referencia a recursos externos
Cuando se ejecuta un control de usuario, las referencias a recursos externos,
como i mágenes o de limitadores para ot ras págin as, se resu elven u tilizando l a
dirección URL del control de usuario como dirección URL base. Por ejemplo,
si el control de usuari o contiene un cont rol Image cuya propiedad ImageUrl se ha
establecido en Images/ Button1.gif, la direcc ión URL de l a imagen se agrega a l a
dirección URL del control de usua rio para resolver la ruta de acceso completa a la
imagen. Si el control de usuari o hace referencia a un recurso que no se encuentra
en una subcarpeta del propio control, se debe proporcionar una ruta de acceso que
se resuelva en la carpeta correcta en tiempo de ejecución.
Almacenamiento en caché y controles de usuario
Los controles de usuario pueden admitir e l uso de directivas de
almacenamiento en caché independientes de la página host. Por lo tanto se
puede agregar a las páginas controles de usuario que permitan almacenar en caché
partes de una página.
Para incluir un control de usuario en una página de formularios Web Forms
1. En la página Web ASP.N ET co ntenedora, crearemos una directiva @
Register que incluya lo siguiente:
ASP.Net
75
• Un atributo TagPrefix, que permite asociar un prefijo al con trol de
usuario. Es te prefi jo se i ncluirá en l a etiqueta de apertura d el
elemento del control de usuario.
• Un atributo TagName, que permite asociar un nombre al control de
usuario. Es te nombre se incluirá en la et iqueta de apertura del
elemento del control de usuario.
• Un atributo Src, que permite definir la ru ta de acceso virtual al
archivo del control de usuario que se va a incluir.
2. En el cuerpo de la página Web, declararemos e l elemento de control de
usuario dentro del elemento form.
3. Si el control de usuari o expone propiedades públicas, también podemo s
establecerlas mediante declaración.
<%@ Page Language="VB" %>
<%@ Register TagPrefix="uc" TagName="Spinner"
Src="~\Controls\Spinner.ascx" %>
<html>
<body>
<form runat="server">
<uc:Spinner id="Spinner1"
runat="server"
MinValue="1"
MaxValue="10" />
</form>
</body>
3.2 CONTROLES DE SERVIDOR
Los controles de servidor web ASP.NET son objetos de páginas web ASP.N ET
que se ejecutan cuando se solic ita la pá gina y que re presentan marcado en e l
explorador. Muchos controles de servid or Web son similares a los conocid os
elementos HTML, com o botones y cuadro s de texto. Otros contr oles abarcan
comportamiento complejo, como los cont roles de un calendario, y controles que
puede usar para conectar a orígenes de datos y datos de visualización.
ASP.Net
76
Controles de servidor HTML
Los controles de servidor HTML son elementos HTML (o ele mentos en otro
marcado compatible, c omo XHTML) que cont ienen atributos que los convierten en
programables en código del servidor. Por defecto, los elementos HTML en una
página Web ASP.N ET no están disponibles para el servidor. En su lugar, se tratan
como texto opaco y se pasan al explorador. Pero cuando se convierten en controles
de servidor HTML, los elem entos HTML q uedan exp uestos co mo elementos
programables en el servidor.
El modelo de objetos de los controles de serv idor HTML se relaciona
estrechamente con el de los elementos correspondientes. Por ejemplo, los atributos
HTML se exponen en controles de servidor HTML como propiedades.
Cualquier elemento HTML de una página se puede conve rtir en control de serv idor
HTML agre gando el atributo runat="server". Durante el anális is, el marc o de
trabajo de la página ASP.NET crea instancias de todos los elementos que contienen
el atributo runat="server". Si queremos hacer referenci a al control como un
miembro dentro del código, también deberemos asignarle un atributo id al control.
El marco de trabajo de la pág ina proporciona controles de servidor HTML
predefinidos para los elementos HTML que se uti lizan con más frecuenci a
dinámicamente en una página: el elemento form, los elementos input (cuadro
de texto, casi lla, botón En viar), el elemento select, etc. Estos controles de
servidor HTML predefinidos comparten las propiedades básicas del control genérico
y, además, cada control normalmente proporciona su propio conjunto de
propiedades y su propio evento.
Los controles de servidor HTML ofrecen las funciones siguientes:
• Un modelo de objetos que pueda volver a programar en el servidor con las
técnicas habituales orientadas a objet os. Los controles de servidor exponen
propiedades que pe rmiten manipular los atributos de marcado del
control mediante programación en el código del servidor.
• Un conjunto de eventos para los que pueda escrib ir controles de eventos
de la misma forma que lo harí a en un fo rmulario basado en cliente, con la
excepción de que un evento se controla en código del servidor.
• La capacidad de controlar eventos en un script de cliente.
ASP.Net
77
• Mantenimiento automático del estado del control. Cua ndo la página
realiza u na acción de ida y v uelta al serv idor, los v alores qu e el u suario
escriba en los controles de servid or HTML se mantendrán automáticamente
y la página se devuelve al explorador.
• Interacción con los controles de validación ASP.NET para poder
comprobar que un usuario ha escrito la información adecuada en un control.
• Enlace de datos a una o varias de las propiedades del control.
• Compatibilidad con estilos si la página Web ASP.NET se muestra en un
explorador que admite hojas de estilos en cascada.
• Paso a tr avés de atributos personalizados. Pueden agregarse lo s
atributos que se necesite n a un control de servi dor HTML: el marco de
trabajo de páginas los representará si n ningún cambio en l a funcionalidad.
Esto permite agregar atributos específicos del explorador a los controles.
Controles de servidor Web
Los controles de servidor Web son un seg undo conjunto de controles diseñado
con otro enfoque. No se asignan necesariamente uno a uno a controles de servidor
HTML. En l ugar de el lo, se defi nen como controles abstractos, e n los que el
marcado real represen tado por el contro l puede ser muy diferente al mode lo con
respecto al que se han programado. Po r ejemplo, un control RadioButtonList de
servidor Web podría representarse en una tabla o como un texto en línea con otr o
marcado.
Los controles de servidor Web in cluyen controles de formulario tradicionales
como botones y cuad ros de texto, adem ás de controles complejos, como, por
ejemplo, las tablas. También incluyen controles que proporcionan funcionalidad de
formulario de uso fre cuente, co mo l a pr esentación d e datos en cuadrícula, la
elección de fechas, la visualización de menús, etc.
Los controles de servidor Web ofrecen to das las funciones descritas anteriormente
para los controles de servidor HTML (excepto la asignación uno a uno a elementos)
y estas funciones adicionales:
• Un modelo de objetos enriquecido q ue proporcion a capacidades de
programación de tipo seguro.
ASP.Net
78
• Detección automática del explorador. Los controles pueden detectar las
funciones del explorador y representar el marcado adecuado.
• Para algunos controles, la capacidad para definir su propio diseño para
el control utilizando Templates.
• Para algunos controles, la capacidad de especificar si un evento del
control provoca un envío inmediato al servidor o, en su lugar, se
almacena en caché y se activa cuando se envía la página.
• Compatibilidad para temas, lo que le permite definir un aspecto uniforme
para los controles en todo el sitio.
• Capacidad para pasar eventos de un control anidado (como un botón
en una tabla) al control contenedor.
Para agregar un control mediante declaración
1. Cambiamos a la vista de edición de origen.
2. Escribimos el e lemento que repre senta el co ntrol en el archivo .aspx. La
sintaxis exacta que debemos utiliz ar depende del con trol que estemos
agregando, pero en general se aplican las siguientes reglas:
• Los controles deben incluir el atributo runat="server".
• Establecer el atributo ID del control a menos que el control forme
parte de un control complejo y se repita.
• Los controles de servidor Web se declaran con una etiqueta XML
que hace referencia al espacio de nombres asp.
• Las declaraciones del control deben cerrarse correctamente. Se
puede especificar una etiqueta de cierre explícita o, en caso de que el
control no tenga elementos secund arios, puede especif icarse una
etiqueta de cierre automáti co. Las únicas excepciones son los
controles de entrada HTML q ue no pue den tener elem entos
secundarios, como los controles de entrada.
• Las propiedades del control se declaran como atributos.
ASP.Net
79
En los siguientes ejemplos se muestran declaraciones típicas para controles
de servidor Web:
<!-- Textbox Web server control -->
<asp:textbox id="TextBox1" runat="Server" text="">
</asp:textbox>
<!-- Same, but with self-closing element -->
<asp:textbox id="Textbox2" runat="Server" Text="" />
<!-- Web DropDownList control, which contains subelements -->
<asp:DropDownList id="DropDown1" runat="server">
<asp:ListItem Value="0">0</asp:ListItem>
<asp:ListItem Value="1">1</asp:ListItem>
<asp:ListItem Value="2">2</asp:ListItem>
<asp:ListItem Value="3">3</asp:ListItem>
</asp:DropDownList>
<asp:Repeater id="Repeater2" runat="server">
<HeaderTemplate>
Company data:
</HeaderTemplate>
<ItemTemplate>
<asp:Label ID="Label1" runat="server"
Font-Names="verdana" Font-Size="10pt"
Text='<%# Eval("Name") %>' />
( <asp:Label ID="Label2" runat="server"
Font-Names="verdana" Font-Size="10pt"
Text='<%# Eval("Ticker") %>'/>
)
</ItemTemplate>
<SeparatorTemplate>
,
</SeparatorTemplate>
</asp:Repeater>
Para agregar un control de servidor Web mediante el diseñador
1. Cambiamos a la vista Diseño.
2. Desde la ficha Estándar del Cuadro de herramientas, arrastr amos el
control a la página.
ASP.Net
80
Figura 3.3
3.3 CONTROLES DE ELEMENTOS
Los controles de los elementos Web ASP.NET son un conju nto i ntegrado de
controles concebidos para crear sitios We b que permiten al usuario mod ificar el
contenido, el aspecto y el comportamiento de las páginas Web directamente en un
explorador.
Las modific aciones se pueden aplicar a to dos l os usuari os del si tio o a usuari os
individuales. Cuando los usuarios modifican páginas y controles, es posible guardar
la confi guración para conservar l as pref erencias pers onales de un usuario en
futuras sesiones del ex plorador; esta característica se denomina personalización.
Estas funciones de l os elementos Web significan q ue los desarrolladores podemos
permitir que los usuari os finales personalicen dinámicamente una apl icación Web,
sin intervención del desarrollador o del administrador.
Utilizando el conjunt o de control es de elementos Web, e l usuario como
desarrollador puede permitir que los usuarios finales hagan lo siguiente:
ASP.Net
81
• Personalizar el contenido de la página. Los us uarios pueden a gregar
nuevos controles de elementos Web a una página, quitarlos, ocult arlos o
minimizarlos como las ventanas normales.
• Personalizar el diseño de página. Los usuarios pueden arrastrar un
control de elementos Web a una zo na diferente de una página o cambiar su
apariencia, sus propiedades y su comportamiento.
• Exportar e importar controles. Los usuarios pueden importar o exportar
configuraciones de con troles de e lementos Web para utilizarlas en ot ras
páginas o en otros sitios, conservand o las propiedad es, la apar iencia e
incluso los datos de los controles. Esto reduce la necesidad de entr ada de
datos y de configuración por parte de los usuarios finales.
• Crear conexiones. Los usuarios pueden establecer co nexiones e ntre los
controles de forma que, por ejem plo, un control gráfico podría mostrar un
gráfico para los datos de un co ntrol de cotización bursátil. Los usuarios
pueden personalizar no sólo la propia conexión, sino también la apariencia y
los detalles de cómo el control gráfico muestra los datos.
• Administrar y personalizar la configuración de todo el sitio. Lo s
usuarios autori zados pueden configurar opciones para todo el si tio,
determinar quién puede tener acceso a un sitio o a una página, establecer el
acceso a los controles basado en funciones, etc.
Fundamentos de los elementos Web
El conjunto de control es de elementos Web consta de tres pilares básicos: l a
personalización, los componentes estructurales de la interfaz de usuario y
los controles de la interfaz de usuario de elementos Web reales. Gran parte
del esfuerzo de desarrollo se cent rará en los controles de elementos Web, que son
simplemente controles ASP.NET que pueden utilizar las características del conjunto
de controles de elementos Web.
Escenarios donde utilizar elementos Web
Normalmente hay tres formas de trabajar con elementos Web: crear páginas que
utilicen controles de elementos Web, crear controles de elementos Web individuales
o crear aplicaciones Web completas personalizables, como un portal.
ASP.Net
82
• Desarrollo de páginas. Podemos utilizar herramientas de diseño visual como
Microsoft Visual Studio 2008 para crea r pág inas que utilizan e lementos Web.
Una ventaja del uso de una herramienta como Visual Studio es que el conjunto
de controles de elementos Web ofrece ca racterísticas para crear y configurar
controles de elementos Web en un dise ñador visual med iante operaciones d e
tipo arrastrar y colocar. Esto puede acel erar el desarrollo de aplicaciones de
elementos Web y reducir la cantidad de código que tiene que escribir.
• Desarrollo de controles. Podemos utilizar cualquier control ASP.N ET
existente como un control de e lementos Web, incluyendo los controles de
servidor Web estánda r, controles de servidor personaliz ados y controles d e
usuario. Para lograr el máximo control de programación de su entorno, también
podemos crear controles de elementos We b personalizados que derivan de la
clase WebPart. Para el desarrollo de controles de elementos Web individuales,
normalmente crearemos un control de usuario y lo utilizará como un control
de elementos Web o desarrollará un control de elementos Web personalizado.
• Desarrollo de aplicaciones Web. El desarrollo de aplicaciones Web
totalmente i ntegradas y personal izables, como un port al, i mplica el uso más
completo de elem entos Web. Podemos desarrollar un siti o Web que permit a
una personalización complet a de l a in terfaz de usuari o y del conte nido, con
características similares a MSN (Microsoft Network). O incluso puede
desarrollar una aplicación empaquetada qu e se puede dis tribuir y ser utilizada
por compañías o ISP (Proovedor de Servicios de Internet.
4. MODELO DE CODIGO DE PAGINAS
Una página Web ASP.NET se compone de dos partes:
• Elementos visuales, incluidos el formato, los c ontroles de servidor y el texto
estático.
• Lógica de programación para la pá gina, q ue incluye controladores de
eventos y otro tipo de código.
ASP.NET pr oporciona dos modelos para ad ministrar el código y los e lementos
visuales: el modelo de página un solo archivo y el modelo de página de
código subyacente. Los dos funcionan de la misma manera y se pueden utilizar
los mismos controles y el mismo código para ambos modelos.
ASP.Net
83
4.1. MODELO DE PAGINA DE UN SOLO ARCHIVO
En es te modelo de página, el formato de la página y s u código de programación
están el mismo archivo .aspx físico. El código de programación se encuentra en un
bloque script q ue c ontiene el atributo runat="server" para marcarlo c omo
código que debe ejecutar ASP.NET.
En este ejemplo se muestra u na pági na de un sol o archivo que conti ene un
control Button y u n c ontrol Label . La pa rte resaltada muestra el controlador de
eventos Click para el control Button dentro de un bloque script.
<%@ Page Language="VB" %>
<script runat="server">
Protected Sub Button1_Click(ByVal sender As Object, _
ByVal e As System.EventArgs)
Label1.Text = "Clic en " & DateTime.Now.ToString()
End Sub
</script>
<html>
<head id="Head1" runat="server">
<title>Model de pagina de un archivo</title>
</head>
<body>
<form id="form1" runat="server">
<div>
<asp:Label ID="Label1"
runat="server" Text="Label">
</asp:Label>
<asp:Button ID="Button1"
runat="server" OnClick="Button1_Click" Text="Button">
</asp:Button>
</div>
</form>
</body>
</html>
El bloque script puede contener tanto código como requiera la página, este código
puede contener controladores de eventos para los controles de la página (c omo
en el e jemplo), métodos, propiedades y cualquier tipo de código como el que se
emplearía normalmente en un archivo de clase.
ASP.Net
84
En tiempo de ejecución, la página de un solo archivo se trata como una
clase que deriva de la clase Page. La página no co ntiene una declaración de
clase ex plícita, sin o qu e e l comp ilador genera una nuev a cl ase que conti ene los
controles como miembros. (No to dos los co ntroles se ex ponen como miembros d e
la página; al gunos son control es secundari os de otros controles.) El código d e l a
página pasa a formar p arte de la clase; por ejemplo, los controladores de eventos
que se hayan creado se convierten en miembros de la clase Page derivada.
4.2. MODELO DE PAGINA DE CODIGO SUBYACENTE (CODE BEHIND)
Este modelo permite mantener el formato e n un archivo ( el archivo .aspx) y el
código de programación en otro. El nomb re del archivo de código varía según el
lenguaje de programación que se esté utilizando.
Hay que te ner en cue nta que no todos lo s lenguajes de programación de .N ET
permiten crear archivos de código subyacente para las páginas Web ASP.N ET. Los
lenguajes deben admit ir c lases p arciales. Por ejemp lo, J# no adm ite las clas es
parciales y, por cons iguiente, no permit e la creación de archivos de código
subyacente para las páginas ASP.NET.
En el modelo de código subyacente, el ejemplo utilizado en el punto anterior para la
página de un solo arc hivo estaría en dos partes. E l formato estaría en un archivo
(en este ej emplo, E jemplo.aspx) y sería similar a la página de un solo archivo,
como se muestra a continuación.
Fichero Ejemplo.aspx (Que se muestre a parte)
<%@ Page Language="VB" CodeFile="Ejemplo.aspx.vb"
Inherits="Ejemplo" AutoEventWire="false" %>
<html>
<head runat="server" >
<title>Modelo de código subyacente</title>
</head>
<body>
<form id="form1" runat="server">
<div>
<asp:Label id="Label1"
runat="server" Text="Label" >
</asp:Label>
<br />
<asp:Button id="Button1"
ASP.Net
85
runat="server"
onclick="Button1_Click"
Text="Button" >
</asp:Button>
</div>
</form>
</body>
</html>
El modelo de código subyacente de la versión 2.0 de ASP.NET aprovecha una nueva
característica de lenguaje conocid a como clases parciales. El archivo de código
subyacente de una pá gina no es una definición de clase completa. Incluye sólo el
código de la aplicac ión necesario, como los controladores de eventos. La cl ase
parcial de código subyacente no necesita incluir variables de instancia ni enlaces de
eventos explíc itos. ASP.NE T puede deducir las instancias de contro l y derivar los
enlaces de eventos del marcado durante la compilación.
Nota Que aparezca el texto tipo bocadillo
Las págin as ASP .NET que u tilizan Visu al Bas ic como l enguaje de programaci ón
pueden utilizar la palabra clave Handles en los métodos para enlazarlos a eventos
explícitamente y lograr un rendimiento ligeramente más rápido.
Ejemplo de un archivo de código subyacente
Partial Class SamplePage
Inherits System.Web.UI.Page
Protected Sub Button1_Click(ByVal sender As Object, _
ByVal e As EventArgs) Handles Button1.Click
Label1.Text = "Clic en " & DateTime.Now.ToString()
End Sub
End Class
LECCIÓN 2. SERVICIOS WEB XML CON ASP. NET
ASP.Net
86
XML (Lenguaje de marcado extensible) como un formato de descripción de
datos abierto ha dado l ugar a la r ealidad de un I nternet programable. Del mis mo
modo que TCP/IP pr oporcionó la conecti vidad uni versal para Int ernet, y HTML
proporcionó un l enguaje normali zado para mostrar i nformación en una gran
variedad de pl ataformas para el consumo humano, XML proporciona un lenguaj e
normalizado para intercambiar d atos para el consumo automati zado, nos d a l a
capacidad de representar los datos en un formato ampliamente aceptado que
permite a l os equipos enviar y recibir dat os en un est ilo predecible, habilitando la
capacidad de programación que se extiende más allá de sistemas cerrad os y
controlados. XML es liberador porque su simplicidad y extensibilidad permiten
definirlo prácticamente todo, dejando espacio para la expansión. Uno de los bloques
de creación fundamentales del Internet programable son los servicios Web XML.
Microsoft proporciona la compatibilidad para generar los servicio s Web XML,
utilizando t ecnologías diseñadas para sat isfacer las n ecesidades de dest inatarios
diferentes. Específica mente, Microsoft ofrece a los programadores la opción d e
crear servic ios Web XML utilizando ASP.NET, ATL Server, .NET Remoting, y
SOAP Toolkit 2.0. ASP.NET y .NET Remoting f acilitan la creaci ón de serv icios
Web XML, puesto que se generan en la parte superior de .NET Framework. El SOAP
Toolkit 2.0 proporciona los servicios Web XML compatibles que admiten Microsoft
Visual St udio 6. 0 y las aplicaci ones h eredadas, permit iendo in teroperar con los
servicios Web XML generados en .NET Framework.
1. INFRAESTRUCTURA SERVICIOS WEB XML
Un servicio web XML es una e ntidad programable que proporciona un elem ento
determinado de f uncionalidad, c omo lógica de la ap licación y e s accesibl e por
diversos sistemas potencialmente dispar es usando los estándare s de Internet
ubicuos, como XML y HTTP. Los s ervicios web XML dependen en gr an medida de la
amplia aceptación de XML y otros está ndares de Internet para crear una
infraestructura qu e admita la interoperabilidad de aplicaciones en un ni vel
que resuelva muchos de los problemas que anteriormente impidieron tales intentos.
Un serv icio w eb XM L pu ede u sarse in ternamente por u na sola aplicac ión o
exponerse externamente a través de Internet para su uso por diversas aplicaciones.
Puesto que es accesible a través de una in terfaz est ándar, u n servicio w eb X ML
permite a si stemas h eterogéneos f uncionar juntos co mo una senci lla web de
cálculo.
ASP.Net
87
En lugar de seguir las funciones genéricas de portabilidad de código, los servicios
web XML proporcionan una solución vi able para habilitar los datos y la
interoperabilidad de l si stema, ya que usan la mensajería basada en XML como
un medi o fundamental para l a comunicación de datos y ayudar a salvar las
diferencias que existen entre los sistem as que usa n m odelos de componentes,
sistemas operativos y lenguajes de programación incongruentes. Los
programadores podemos crear ap licaciones que desarrollen juntas servicios we b
XML de v arios or ígenes de la m isma man era qu e u samos t radicionalmente lo s
componentes para crear una aplicación distribuida.
Una de las características básica s de un servicio web XML es el alto grado de
abstracción que existe entre la implementación y el uso de un servicio. Al
usar la mensajería basada en XML como el mecanismo para crear y tener acceso al
servicio, e l cli ente y el prov eedor del se rvicio w eb XM L se l iberan de la mu tua
necesidad de tener información de las entradas, las salidas y la ubicación.
Los servicios web XML deben ser independientes respecto a la opción de
sistema operativo, modelo de objetos y lenguaje de programación para
tener éxito en la disparidad de Web. Asimismo, para los serv icios web de XML
se aprovechen de la misma adopción ex tendida que otras tecnologías basadas en
Web, deben tener las siguientes características :
• Muy poco dependientes: dos sistemas se consideran poco dependientes si
la ú nica obligación impuesta en am bos sistemas es comprender los
mensajes autodescriptivos, basad os en texto menci onados anteri ormente.
Los si stemas muy dependi entes, por otro lado, imponen una c antidad
significativa de carga person alizada para h abilitar la comu nicación y
requieren una comprensión mayor entre los sistemas.
• Comunicación ubicua: es impr obable que cualquiera genera ahora un
sistema operativo o e n un futuro cercano que no incorpore la capacidad de
conectarse a Internet, lo que proporciona un canal de comunicación ubicuo.
Por tanto, l a capacidad de conectar casi cualquier sistema o dispositivo a
Internet garantiza que tal es sistemas y di spositivos estarán universalmente
disponibles a cualquier otro sistema o dispositivo conectado a Internet.
• Formato de datos universal: al adoptar los métodos de comunicación de
bucle cerrado con estándares abiertos sobre la propiedad, cualquier sistema
que admita los mism os estándares ab iertos es capaz de entender lo s
ASP.Net
88
servicios web de XM L. Al u sar mensajes autodescriptivos, basados e n texto
que los servicios web XML y sus clientes pueden compartir s in conocer lo
que constituye cada sistema subyacente se habilita la comunicación entre
sistemas autónomos y diferentes. Los servicios web XML logran esta función
con XML.
Los servicios web XML emplean una infraestructura que proporciona lo siguiente:
• Un mecanismo para localizar servicios web XML
• Una descripción de servicio para definir cómo usar esos servicios
• Formatos de conexión estándar con los que comunicarse.
La siguiente imagen muestra un ejemplo de esta infraestructura.
Figura 1.1
En es ta tabla podemos ver la función de cada una de las partes d e la
infraestructura.
ASP.Net
89
PARTE DE LA
INFRAESTRUCTURA FUNCIÓN
Directorios de
servicios web XML
Los directorios de servicio s web XML proporcionan una
ubicación central par a loca lizar serv icios w eb XML
proporcionados por otr as organizaciones. Los directorios
de servicios web XML como un re gistro UDDI cumplen
esta f unción. L os clientes del ser vicio w eb X ML pu eden
hacer referencia el directorio de un servicio web XML.
Descubrimiento de
servicios web XML
El descubrimiento de servicios web XML es un proceso
que consiste en loca lizar, o descubrir, uno o varios
documentos relac ionados que des criben un s ervicio web
XML determinado usando el Lenguaje de des cripción de
servicios web (WSDL). La especificación DISCO define un
algoritmo para local izar descripciones de servicio. Si los
clientes del servicio web de XML conocen la ubicación de
la descr ipción de serv icio, pu eden omit ir el p roceso de
descubrimiento.
Descripción del
servicio web XML
Para entender cómo interactuar con un servicio web XML
determinado, es necesario proporcionar una descripción
de servic io que defina qu é interacciones admite e l
servicio w eb XM L. Los clien tes del serv icio w eb XM L
deben saber cómo interactuar co n un servicio web X ML
antes de poder usarlo.
Formatos de
conexión del
servicio web XML
Para h abilitar la comu nicación u niversal, los serv icios
web XM L s e comuni can usando f ormatos de conexi ón
abiertos, q ue son protocolos q ue entiende cualquier
sistema capaz de admitir los estándares web más
comunes. SOAP es el proto colo c lave para la
comunicación del servicio web XML.
Proceso de una llamada al servicio Web XML
ASP.Net
90
El proceso que produc e al hacer una l lamada a un servicio web XML es similar al
proceso que se produce al realizar una llamada a un método normal. L a
diferencia principal es que en vez de llamar a un método que se e ncuentra en la
aplicación cl iente, se g enera un mensaje de solicitud a través del transporte
especificado, por ejem plo, HTTP. Puesto qu e el m étodo de servicio web XML s e
puede encontrar en otro equipo, la inform ación que el s ervicio web XML necesit a
para procesar la solicitud se deb e pasa r po r la r ed al servidor q ue hospeda el
servicio w eb XM L. El serv icio w eb XM L procesa la in formación y devuelve el
resultado, a través de la red, a la aplicación cliente.
Figura 1.2
Eventos que se producen
La secuencia de eventos que se producen cuando se llama a un servicio web
XML:
1. El clien te crea una nueva instancia de la clase de proxy del servicio
web XML. Este objeto reside en el mismo equipo que el cliente.
2. El cliente invoca un método en la clase de proxy.
3. La infraestructura en el equipo cliente serializa los argumentos del
método de servicio web XML en un mensaje SOAP y lo envía a través
de la red al servicio web XML.
ASP.Net
91
4. La infraestructura recibe el mensaje SOAP y deserializa el XML. Crea
una in stancia de la cl ase que implemen ta e l servicio web XML e in voca el
método de servicio web XML, pa sando el XML deserializado como
argumentos.
5. El método de servicio web XML ejecuta su código, estableciendo
finalmente el valor devuelto y los parámetros out.
6. La infraestructura en el serv idor web serializa el valor devuelto y los
parámetros out en un mensaje SOAP y lo dev uelve a través de la red a l
cliente.
7. La in fraestructura del serv icio w eb XML, en el equipo cliente, recibe el
mensaje SOAP, deserializa el XML en el valor devuelto y los
parámetros out, y los pasa a la instancia de la clase de proxy.
8. El cliente recibe el valor devuelto y los parámetros out.
Generar un servicio web XML
Crear un servicio web de XML es simi lar a crear cualquier componente que
proporcione acceso mediante programación a la lógica de la ap licación. Para crear
un servicio web XML, necesi tamos al guna fu ncionalidad que i ntegre el servicio
que desea exponer, una descripc ión del serv icio que defina cómo usar el servicio y
una infraestructura para admit ir la recepción y el procesamiento de solicitudes y el
envío de respuestas.
Generar un cliente de servicio web XML
Puesto que se puede tener acces o a los servicios w eb XM L me diante direcciones
URL, HTTP y XML, est o sign ifica qu e los programas que se ejecuten en
cualquier plataforma y lenguaje podrán tener acceso a los servicios web
XML. Y a qu e la n aturaleza desce ntralizada de los serv icios w eb X ML permit e a l
cliente y al serv icio w eb XM L f uncionar como uni dades autó nomas, exi sten
innumerables formas de usar un s ervicio web XML. Por ejemplo, una llamada a un
servicio w eb XM L pu ede in cluirse en u na aplicac ión w eb, u n compon ente de
software int ermedio o in cluso ot ro serv icio w eb XM L. In dependientemente del
formulario que pueda obtener el cliente del servicio web XML, todo lo que hace falta
para llamar a un servicio web XML es enviar un mensaje de solicitud con el formato
correcto que cumpla la descripción de servicio publicada para ese servicio web XML.
Dependiendo de la n aturaleza del serv icio web XML, podríamos enviar a cambio un
ASP.Net
92
mensaje de respuesta. El autor de la soli citud debe ser capaz, posteriormente, de
extraer la información necesaria de este mensaje.
Declaración de servicios web
Al crear un servicio web en AS P.NET, se coloca la directiva @ WebService
necesaria al principio de un arch ivo de text o con una extensi ón de nombre de
archivo .asmx. La presencia del archivo .asmx y la directiva @ WebService pone
en correlac ión la d irección URL del serv icio web con su impl ementación. También
implementa la clase d e servicio web qu e define los m étodos y tipos de datos
visibles por los clientes de servicios web.
La clase de servicio web que definamos puede inclui rse directamente en e l
archivo . asmx o en u n arch ivo in dependiente. Si usamos un archivo
independiente, debe estar compilado en un ensamblado. Opcionalmente,
podemos aplicar un atributo WebService a la c lase que implem enta el ser vicio
web. La clase que implementa el servicio web puede derivar de la clase
WebService.
Podemos establecer e l espacio de nombres XML predeterminado para el
servicio w eb ju nto con un a caden a para describir el servicio w eb aplican do e l
atributo WebService opcional a una clase que impl ementa un servicio web. Se
recomienda cambiar este espacio de no mbres predeterminado, que or iginalmente
es http://tempuri.org, antes de que el servicio web se use públicamente. Esto es
importante porque el s ervicio web debe diferenciarse de otros servicios web q ue
podrían usar inadvertidamente el espacio de nombres como valor pr edeterminado
(<http://tempuri.org/>).
Declaración en el mismo archivo
<%@ WebService Language="VB" Class="Util" %>
Declaración de implementación en un ensamblado
<%@ WebService Language="VB"
Class="MyName.MyWebService,MyAssembly" %>
Definición de métodos de servicios web
Los métodos de una clase que implem entan un servicio we b NO tienen
automáticamente la posibilidad de recibir las solicitudes del servicio web y devolver
ASP.Net
93
las respuestas, pero c on los servicios web creados u tilizando ASP .NET es muy
simple agregar esa capacidad, aplicando el atributo WebMethod a los métodos
públicos. Los métodos de una clase de se rvicio web que se pueden comunicar a
través de Web se denominan métodos de servicios web.
Los métodos de servicios web forman una parte clav e de la infraestructura de
mensajería empleada por los servicios web. Es decir, un cliente y un servicio web se
comunican de forma predeterminada utilizando mensajes, concretamen te
mensajes SOAP. Los clientes env ían una solicitud SOAP a u n servi cio web y un
método de servicios web devuelve normal mente una respuesta SOAP. Los servicios
web definen el tipo de mensajes que aceptan utilizando operaciones, como define el
Lenguaje de descripción de servicios web (WSDL). Es tas operaciones ponen
en correlación cada uno de los métodos de servicios web dentro de un servicio web.
Aunque ca da uno de estos mét odos de servicios web se define en ASP.NET
utilizando un método de una clase, es importante comprender que los datos que se
comunican eventualmente a travé s de l a red se deban serializar en XML. Por
tanto, es importante recordar que los serv icios web NO son una susti tución de
DCOM, si no una infraestructura de mensajería para comunicarse entre
plataformas utilizando los estándares de la industria.
<%@ WebService Language="VB" Class="Util" %>
Imports System.Web.Services
Imports System
<WebService(Namespace:="http://www.contoso.com/")>
Public Class Util
Inherits WebService
< WebMethod()> _
Public Function Multiply(a As Integer, b As Integer) As Long
Return a * b
End Function
End Class
2. MÉTODOS ASÍNCRONOS
Implementar un método de servicio web asincrónico permite a ese subproce so
ejecutar otro código cuando se devuelve al grupo de subprocesos. Esto permite la
ASP.Net
94
ejecución de un subproceso más que el núme ro lim itado de subprocesos en e l
grupo, mejorando el rendimiento total y la escalabilidad del sistema.
Para implementar un método de servicio web asincrónico
1. Dividiremos un método de servicio web sincrónico en dos métodos, cada uno
con el mismo nombre base, uno con ese nombre empezando con Begin y el
otro con End.
2. La lista de parámetros del método Begin conti ene todos los parámetros in y
by reference para la funci onalidad de l método además de dos parámetros
adicionales.
• Los parámetros By reference se enumeran como parámetros in.
• El penúltimo parámetro debe ser AsyncCallback. Este parámetro
permite a un cl iente proporcionar un delegado, que se invoca cuando
finaliza el método. C uando u n mét odo de s ervicio w eb asin crónico
llama a otro método a sincrónico, este parám etro se pue de pasar e n
el penúltimo parámetro de ese método.
• El último parámetro es Object. Este parámetro permi te a un
llamador proporcionar información de estado al método. Cuando un
método de servicio web asincrónico llama a otro método asincrónico,
este parám etro se puede pasar en el últ imo parám etro de es e
método.
• El valor devuelto debe ser de tipo IAsyncResult.
3. La lista de parámet ros para el método End es tá compuesto de
IAsyncResult seguido de cualquier parámetro out y by reference
específico para la funcionalidad del método.
• El val or devuel to es del mi smo t ipo que el valor dev uelto de un
método de servicio web sincrónico.
• Los parámetros By reference se enumeran como parámetros out.
Imports System.Web.Services
<WebService(Namespace:="http://www.contoso.com/")> _
Public Class MyService
Inherits WebService
ASP.Net
95
Public remoteService As RemoteService
Public Sub New()
MyBase.New()
' Crear una nueva instancia de la clase del proxy para
' el servicio Web que llamamos.
remoteService = New RemoteService()
End Sub
' Define el método Begin.
<WebMethod()> _
Public Function BeginGetAuthorRoyalties(ByVal Author As String, _
ByVal callback As AsyncCallback, ByVal asyncState As Object) _
As IAsyncResult
' Begin se comunica asíncronamente con un servicio Web XML
' diferente.
Return remoteService.BeginReturnedStronglyTypedDS(Author, _
callback, asyncState)
End Function
' Define el metodo End.
<WebMethod()> _
Public Function EndGetAuthorRoyalties(ByVal asyncResult As _
IAsyncResult) As AuthorRoyalties
' Devuelve el resultado asíncrono desde el otro Web service.
Return remoteService.EndReturnedStronglyTypedDS(asyncResult)
End Function
End Class
En la comunicación de forma as incrónica con un servicio web se s iguen los d os
modelos de diseño de invocación de métodos asincrónicos especificados por
.NET Framework.
Wsdl.exe y el modelo de diseño asincrónico de .NET Framework
Cuando la herramienta Lenguaje de descripción de servicios web (Wsdl.exe)
genera un a clase de proxy cliente par a tener ac ceso a un servic io web
especificado, proporciona dos mecanismos a la clase de proxy para comunicarse de
forma asincrónica con cada método de servicio web.
El primer mecanismo es el modelo Begin/End. El segundo m ecanismo es el
modelo de programación asincrónico orientado a eventos dispon ible en l a
versión 2.0 de .NET Framework.
El modelo de invocación Begin/End
ASP.Net
96
Wsdl.exe c rea automáticamente tres métodos para ca da operación (un méto do
de servicio web en AS P.NET) publicada en el servicio web. Un método es para el
acceso sincrónico; los otros dos son para el acceso asincrónico.
NOMBRE DE MÉTODO EN CLASE
DE PROXY DESCRIPCIÓN
<NameOfWebServiceMethod> Envía sincrónicamente un mensaje para el
método de servicio web denominado
<NameOfWebServiceMethod>.
Begin<NameOfWebServiceMethod> Comienza la comunicación asincrónica del
mensaje con un méto do de servici o web
denominado
<NameOfWebServiceMethod>. El
cliente indic a al métod o Begin que in icie
el procesamiento de la llamada del
servicio, pero que vuelva inmediatamente.
El val or devuel to no es el tipo de datos
especificado por el método de servicio
web, si no un tipo que implementa la
interfaz IAsyncResult.
End <NameOfWebServiceMethod> Finaliza una comuni cación asi ncrónica del
mensaje con un méto do de servici o web
denominado
<NameOfWebServiceMethod>,
devolviendo u n v alor q ue es e l re sultado
de la llamada del método de servicio web.
Los métodos Begin y End siguen la nomenclatura del modelo de diseño asincrónico
de .NET F ramework. El modelo de di seño indica que existen dos métodos
asincrónicos con nombre para cada método sincrónico.
ASP.Net
97
Implementar un cliente de servicios web que realiza una llamada al
método asincrónico mediante el modelo Begin/End
¿Cómo sabe un client e cuándo llamar a l método End ? Hay dos técnicas para
implementar un cl iente con el fin de dete rminar esto, como se define en .NET
Framework:
• La técnica de espera: usa uno de los métodos de la clase WaitHandle
para hacer que un cliente espere a que el método finalice.
La clase WaitHandle implementa método s que permiten espera r que se
señalen l os objetos d e si ncronización: WaitOne, WaitAnyy WaitAll. La
señal de un objeto de sincronización es una indicación de que los
subprocesos esperarán hasta el recurso especificado pueda tener acceso al
recurso. El cliente de servicios web tiene acceso a un objeto WaitHandle a
través de la propiedad AsyncWaitHandle del objeto IAsyncResult
devuelta por el método Begin.
• la técnica de devolución de llamada: pasa una función de devolución
de llamada al método Begin, al que se llama más tarde para recuperar
los resultad os cuando el método ha terminado de procesarse. Con esta
técnica, una f unción de dev olución de llam ada impl ementa el delegado
AsyncCallback, que exige la firma:
public void MethodName(IAsyncResult ar)
Si la devoluci ón de llamada requi ere un contexto de si ncronizado/afinidad del
subproceso, se envía a través de la infraest ructura de distribuidor de contextos. Es
decir, la devolución de llamada podría ejecutar de forma asincrónica con respecto a
su llamador para tales contexto s. É sa precisamente es la semántica del
calificador unidireccional en fi rmas de método. Es o significa que c ualquier
función de llamada a l método podría ejecutarse de form a sincrónica o as incrónica
con respecto al llamador remoto, y el llamador no podría hacer ni nguna suposición
sobre la realización de este tipo de llamada cuando el control de ejecución vuelva a
él.
La llamada al método End antes de que la operación asincrónica haya f inalizado
bloqueará el llamador . El compo rtamiento de llamarlo una segunda ve z co n el
mismo IAsyncResult devuelto por el método Begin es imprevisible.
ASP.Net
98
3. TRANSACCIONES EN SERVICIOS WEB XML
Las transacciones enlazan varias tareas.
Por ejemplo, imaginemos que una aplicac ión realiza dos tareas. Primero, crea una
nueva tabl a en una base de datos. Lu ego, llama un objeto esp ecializado para
recoger, dar formato e insertar los datos en la nueva tabla. Estas dos tareas están
relacionadas e in cluso son in terdependientes, de tal ma nera que s e desea evitar
crear una nueva tabla a menos que pueda llenarse de datos. La ejecución de ambas
tareas dentro del ámbito de una única transacción refuerzan la conexión entre ellas.
En caso de error en la segunda tarea, la primera vuelv e al punto anterior a la
creación de la nueva tabla.
Para asegurarse el comportamiento predecible, toda s las trans acciones deben
poseer las propiedades ACID básicas (atómico, coherente, aislado y
duradero). Estas prop iedades refuerzan la función de transacciones críticas p ara
una misión como proposiciones todos-o-ninguno, garantizando que un conjunto de
tareas relac ionadas tenga éxito o que produzca un error como una uni dad. En la
terminología del procesamiento de transacci ones, la transacción interrumpe o
procesa el procesamiento.
Todos los participantes deben garantizar para que se produzca una transacción que
cualquier cambio a los datos será permanente.
Los cambios deben co nservarse a pesar de bloqueos del sistema u otros eventos
imprevistos. Tan sólo produciéndose un error en uno de los part icipantes al realizar
la garantía, la transacción entera genera un error.
Todos los c ambios de los datos dentro del ámbito de la transac ción se deshacen
hasta un punto fijo concreto.
Una transacción se puede confinar a un re curso de dato único, com o una base de
datos o un a col a de mensajes. El Administrador de la Transacción proporcionado
por System.Transactions, que genera l a gananci a de rendimiento administra la
transacción local en este escenar io. Cont roladas por el recurso de datos, esta s
transacciones son eficaces y fáciles administrar.
Las transacciones distribuidas dan la capacidad para incorporar varias
operaciones distintas que se producen en sistemas diferentes en un paso único o
ASP.Net
99
producir un error en la acción. El coordinador de transacciones distribuidas de
Microsoft (MSDTC) que reside en cada sistema coordina las transacciones en este
escenario.
Al desarrollar una aplic ación transaccional utilizando las c lases proporcionadas por
System.Transactions, no nec esitamos preocuparnos por qué tipo de
transacciones necesita o el a dministrador de tran sacciones implicado. La
infraestructura System.Transactions administra auto máticamente éstos p ara
nosotros.
Cuando creamos una transacci ón, podemos especificar el nivel de aislamiento
que se aplica a la tr ansacción. El nive l de aislamient o, definido por la clase
IsolationLevel, determina qué nivel de otras transacciones de acceso tendrán los
datos afectados por su transacción.
La compatibilidad de transacciones con servicios web aumenta la compatibilidad
que se encuentra en Common Language Runtime, que se basa en el mismo
modelo de transacciones distribuidas que se encuentran en Microsoft Transaction
Server (MTS) y en los Servicios COM+.
El modelo se basa en decidir mediante una declaración si un objeto participa en una
transacción, en lugar de escrib ir el código concreto que se va a administrar para
confirmar y deshacer una transacción. En un servicio web XML creado con ASP.NET,
podemos declarar el comportamiento de las transacciones del servicio web
estableciendo la propiedad TransactionOption del atributo WebMethod
aplicada al método de servicio web.
Si se gener a una excepción mientras se está ejecutando un método de servic io
web, la transacción se anul a automáticamente; por el c ontrario, si no se genera
ninguna excepción, la transacción se confirma automáticamente.
La propiedad TransactionOption del atributo WebMethodAttribute especifica
cómo part icipa un método de serv icio web en una transacción. Aunque este nivel
declarativo representa la lógica de una transacción, es un paso que se ha quitado
de la trans acción física. Una transacción física se produce cuando un objet o
transaccional tiene acceso a un recurso de da tos, como una base de datos o una
cola de mensajes. La transacción asocia da al objeto pasa automáticamente a l
administrador de recursos adecuado.
Un proveedor de datos de .NET Framework, como el Proveedor de datos de .N ET
Framework para SQL Server o el Proveedor de datos de .NET Fr amework para
ASP.Net
100
OLE DB, b usca la transacción en el contexto del objeto y se incorpora en la
transacción a través d el Coordinador de transacciones distribuidas (DTC). Se
produce toda la transacción automáticamente.
Los métodos de servicio web sólo pueden participar en una transacción como la
raíz de una nueva tran sacción. Como la ra íz de una nue va transacc ión, todas las
interacciones con los admi nistradores de recursos, como los servidores que
ejecutan Microsoft SQ L Server, Message Queue Server de Micro soft (también
conocido como MSMQ) y Microsoft Host Integrati on Server manti enen l as
propiedades ACID exigidas para ejecutar aplicac iones distribuida s robustas. Los
métodos de servicio web que llaman a otro s métodos de servicio web participan en
transacciones diferent es, po rque las transacciones no pasan por los métodos d e
servicio web.
Para participar en una transacción de un método de servicio web
1. Declaramos un servicio web.
<%@ WebService Language="VB" Class="Orders" %>
2. Agregamos una directiva Assembly a System.EnterpriseServices.
<%@ Assembly
name="System.EnterpriseServices,Version=1.0.3300.0,Culture=neutral,PublicKeyToken=b03f5
f7f11d50a3a" %>
3. Agregue referencias a los espacio s de nombres System.Web.Services y
System.EnterpriseServices.
Imports System.Web.Services
Imports System.EnterpriseServices
4. Declare u n método de serv icio web, establec iendo la propiedad
TransactionOption del atributo WebMethodAttribute como
System.EnterpriseServices.TransactionOption.RequiresNew.
< WebMethod(TransactionOption:=TransactionOption.RequiresNew)> _
Public Function DeleteAuthor(lastName As String) As Integer
ASP.Net
101
4. PROTEGER SERVICIOS WEB XML . SOAP
La decis ión de qué implementación de seguridad es mejor para un Servic io W eb
comienza por el exam en de dos principios d e seguridad clave: autenticación y
autorización.
La autenticación es el proces o de validar una identidad basada en las
credenciales, como un nombre de usuari o y contras eña, contra una au toridad.
Cuando una identidad ha sido autenticada, la autorización determina si esa
identidad está autorizada para acceder a un recurso.
Los Servicios Web creados con ASP.NET pueden elegir sus opciones de seguridad
a partir de las opciones de autorización y autenticación proporcionadas por ASP.NET
o la seguridad personalizada basada en SOAP.
ASP.NET f unciona en combinación con los serv icios d e in formación de internet
(IIS) para proporcionar varias opciones de autenticación y autorización, utilizando
también las opciones de autenticación personalizada, como el uso de encabezados
SOAP. Además, ASP.NET proporciona la capacidad, conoci da como la
suplantación, de ejecutar una solicitud mediante las credenciales del cliente.
Como vemos tenemos varias opciones para elegir, pero ¿cómo saber cuál es la
correcta?, una de las cosas entr e la s que tendremos que elegir es el nivel de
seguridad y de rendimiento. Para algunos Servicios Web, es importante que las
credenciales del cliente se envíen a través de la red utilizando el cifrado, por lo que
es esencial un algoritmo que cifre las credenciales del cliente.
La siguiente tabla es un resumen de las opciones de autenticación disponibles para
los Servicios Web generados con ASP.NET.
OPCIONES DE AUTENTICACIÓN. DESCRIPCIÓN
Windows: Basic Se utilizará para la identificación no segura de clientes, ya que el
nombre de usuario y la contraseña se enví a en cadenas de
codificación de base 64 en texto si n formato. Las contraseñas y
nombres de usuario están codi ficados, pero no cifrados, en este
tipo de autenti cación. Un usuari o ma lintencionado determi nado,
equipado co n una herra mienta de s upervisión de l a red puede
interceptar nombres de usuario y contraseñas.
Windows: Basic Se utilizará para la identificación segura de clientes en escenarios
ASP.Net
102
sobre SSL de Intern et. El nombre de usuari o y contraseña se enví an a
través de l a red utilizando el cifrado de Capa d e sockets seguros
(SSL), en lugar del t exto s in fo rmato. Es r elativamente fá cil de
configurar y funci ona para l os escenarios de Inter net. Al ut ilizar
SSL, sin embargo, se degrada el rendimiento.
Windows:
autenticación
implícita
Se utilizará para la identificación segura de clientes en escenarios
de Intern et. Utili za un algoritmo hash para tra nsmitir así las
credenciales del cliente de una maner a cifrada de manera que l a
contraseña no se tr ansmite en tex to no ci frado. Además, la
autenticación implícita puede funcionar a través de los servidores
proxys. S in embar go, no se a dmite ampl iamente en otras
plataformas.
Windows: Windows
integrada
Utiliza NTLM o Kerberos. Utiliza un i ntercambio criptográfico con
el explorador web Microsoft Internet Explorer del usuario.
Windows:
certificados del
cliente
Se utilizará para la identificación segura de clientes en escenarios
de Int ernet e i ntranet. Exi ge a cad a cl iente que obt enga u n
certificado d e u na e ntidad e misora d e c ertificados d e mu tua
confianza. Los certi ficados están asi gnados opci onalmente a l as
cuentas de u suario, que son uti lizadas por IIS para autori zar el
acceso al Servicio Web.
Formularios No compatible con el Servicio Web. Éste es un sistema por el que
las solicitudes no autenticadas se redirigen a un formul ario HTML
utilizando redirección Http del cliente. La mayoría de los clientes
de Servicio Web no desearán proporcionar credenciales mediante
una i nterfaz de usuari o; deberá tra bajar sobre est a cuesti ón si
desea utilizar la autenticación de formularios.
Encabezados SOAP.
Personalizado
Útil para escenari os de Internet se guros y no seguros. Las
credenciales del usuari o se pasan den tro del encabezado S OAP
del mensaje SOAP. E l servi dor web, si n tener en cuenta la
plataforma que hosp eda el S ervicio Web, pro porciona una
implementación de autenticación personalizada.
Para todas las opcio nes enumeradas an teriormente, excepto para el uso de
encabezados SOAP , la con figuración de seguridad se especif ica utilizando u na
combinación de archivos de configuración e IIS.
ASP.Net
103
Autenticación de Windows
IIS y ASP.NET proporcionan la compatibilidad para autenticar las aplicac iones
web, in cluso los Serv icio Web, u tilizando la seguridad integrada en Windows.
Windows proporciona tres opciones para la au tenticación: Basic, Au tenticación
implícita y Windows integrada. Además, cada opción se puede utilizar con SS L. Ya
que todas las opciones de autenticación de Windows, excepto Basic, cifran los datos
en algún formulario, el ni vel de cifrado adicional proporc ionado por SSL se utiliza
normalmente sólo junto con Basic o Certificados del Cliente.
Sin tener en cue nta q ue opción de autenticación de Windows se u tiliza, los
procedimientos para preparar el Serv icio Web y el cli ente de serv icios w eb son
similares. No se n ecesita agregar nada de código a un Servicio Web para u tilizar la
autenticación de Wi ndows, cuando las opciones de autenticación se establecen en
un archi vo de confi guración e IIS. Se de be agregar u n código a un cliente de
servicios web para pasar las credenciales del cliente al Servicio Web.
Si SSL se el ige como la part e d el mecan ismo de au tenticación u tilizada po r u n
Servicio W eb, necesitamos configurarlo para la aplicación web que hospeda el
Servicio W eb o para el propi o Serv icio We b, ut ilizando IIS. L a descripción del
servicio y, por consiguiente, las clases de proxy generadas a partir de la descripción
del se rvicio ref lejarán que el Ser vicio Web utiliza SSL ( si se t iene acceso a l a
descripción del se rvicio y págin a de ay uda del s ervicio u tilizando SSL ). La
dirección URL al Servicio Web dentro de la descripción del servicio se
prefijará con Https.
Autenticación de certificados de cliente
Los certificados de cliente ayudan a propor cionar un mecanismo seguro para la
autenticación, ya que ex igen a los clien tes que envíen un do cumento electrónico,
denominado certificado de cliente, que identifica al cliente utilizando una conexión
SSL al servidor web. La conexión SSL cifra las credenciales del clien te contenidas
dentro del cert ificado de clien te como qu e se envían a través de la red. La
comunicación entre el cliente y el servidor web se ci fra utilizando una combinación
de las claves de cifrado enviadas por el cliente y las claves proporc ionadas por el
servidor web. Una vez est ablecida la com unicación, sólo los equipos servidores y
cliente pueden comunicarse entre sí utilizando esa conexión SSL.
ASP.Net
104
Opciones de la autorización para los servicios web de XML
El propósito de la autorización es determinar si una identidad se debería permitir
el t ipo solicitado de acceso a un recur so determinado. Hay dos maneras
fundamentales de autorizar el a cceso a un recurso determinado: autorización del
archivo y autorización de URL. Se pu ede u tilizar la au torización del arch ivo
siempre qu e se u tiliza la au tenticación de Win dows, y a qu e los permisos se
establecen en IIS en una base por archivo. La autorización de URL se puede utilizar
con cualquiera de los meca nismos de autenti cación integrados admitido por
ASP.NET. Con autorización de URL, l a configuración se hace a través de un archi vo
de configuración, donde se puede n conceder o denegar el acceso a l os usuarios a
cualquier archivo asociado a ASP.NET, incluso archivos .asmx, de manera selectiva.
Autenticación personalizada utilizando los encabezados SOAP
Los mecanismos de autenticación de Windows, incluso los certificados de
cliente, confían en el transporte HTTP, mientras que SOAP es
independiente del transporte. Los Servicio Web generados con ASP.NET utilizan
SOAP sobre Http, así como imp lementaciones HTTP-POST y HTTP-GET que
devuelven los documentos XML de no SOAP. Así que, una razón para crear un
mecanismo de aut enticación per sonalizada es desacoplar la autenticación del
transporte. Esto se pu ede l ograr pasando las credenciales de aute nticación en el
encabezado SOAP.
Los encabezados SOAP son una b uena manera de pasar fu era de banda o
información no relac ionada con la semántica de u n Serv icio Web. A diferencia del
elemento Body de un mensaje SOAP, que incluye los parámetros in y out para la
operación del Serv icio Web que son procesados por el método de servicio Web, el
elemento Header es o pcional y e s procesado así po r la infraestructura. Es decir,
procesado por una infraestructura desarrollada para proporcionar un mecanismo de
autenticación personalizada.
Para u tilizar los en cabezados SOAP para la au tenticación, un clien te de serv icios
web enviaría sus credenciales al Servic io Web agreg ando el encabezado SOAP
esperado, a la solic itud SOAP y rellenándol o con las credenciales del cliente. Pa ra
utilizar la a utenticación del en cabezado SOAP , un Serv icio Web de be h acer dos
cosas: especificar que espera el encabezado SOAP que contiene las credenciales de
autenticación y autorizar el acceso de cliente al Servicio Web.
ASP.Net
105
<%@ WebService Language="VB" Class="MyWebService" %>
Imports System.Web.Services
Imports System.Web.Services.Protocols
' Define a SOAP header by deriving from the SoapHeader base class.
Public Class MyHeader : Inherits SoapHeader
Public Username As String
Public Password As String
End Class
<WebService(Namespace:="http://www.ejemplo.com")> _
Public Class MyWebService
' Add a member variable of the type deriving from SoapHeader.
Public myHeaderMemberVariable As MyHeader
' Apply a SoapHeader attribute.
<WebMethod, SoapHeader("myHeaderMemberVariable")> _
Public Sub MyWebMethod()
' Process the SoapHeader.
If (myHeaderMemberVariable.Username = "admin") Then
' Do something interesting.
End If
End Sub
End Class
5. IMPLEMENTAR Y PUBLICAR SERVICIOS WEB XML
5.1 IMPLEMENTACION
Implementar un servicio web implica copiar el archivo .asmx y los
ensamblados usados por el servicio web que no se suministra como una parte de
Microsoft .NET Framework en un directorio virtual en un servidor web.
El descubrimiento de servicios web es el proceso de loca lizar e interrogar
descripciones de servicios web, que son un paso preliminar para tener acceso a un
servicio web. A t ravés del proceso de descubrimiento, los clien tes de serv icios web
pueden obten er in formación en t iempo de di seño de la existencia de u n serv icio
web, c uáles son sus funciones y cómo in teractuar correctamente con él, a este
proceso se conoce como la detección del servicio web.
ASP.Net
106
Se puede utilizar la herramienta Web Services Discovery (Disco.exe) desde el
símbolo del sistema para realizar la dete cción del serv icio w eb en una dirección
URL.
Disco /out:location /us ername:user /pas sword:mypwd /do main:mydomain
http://www.ejemplo.com/my.disco
Los servicios web se hacen disponibles a los usuari os u sando u n mecani smo de
descubrimiento que normalmente obtiene el formulario de un documento de
descubrimiento, u n d ocumento XML que puede con tiene ví nculos a otros
documentos de descubrimiento, esquemas XSD y descripciones del servicio en el
Lenguaje de descripción de servicios web (WSDL). Desde estos documentos
se pueden determinar qué servicios están disponibles para ellos.
Hay tres maneras que un cliente potencial d e servic ios web puede tener acceso a
un documento de descubrimiento:
• Archivo de descubrimiento estático: Pu blicaremos u n archivo de
descubrimiento, normalmente con una ex tensión de nombre de archivo
.disco. Los usuarios pueden examinar a un archivo de descubrimien to
específico o a la raíz de la aplicación web si la página web predeterminada
tiene un vínculo al archivo. Un archivo .disco puede contener referencias a
cualquier número de servicios web.
• ?cadena de consulta ?disco: Un servicio web que se ejecuta en ASP.NE T
puede tener un documento de descubrimiento generado dinámicamente
para él. Un documento de descubr imiento se genera aut omáticamente para
un servicio web cuando se ti ene acceso al mismo usando una dirección
URL con ?DISCO que se proporciona e n la cadena de consul ta. Por
ejemplo, si la direcció n URL a un servicio web es
www.pruebas.com/getquote.asmx, a continuación, se genera
automáticamente un documento de descubrimiento con una dirección URL
www. pruebas.com/getquote.asmx?DISCO. El documento de descubrimiento
sólo se aplica a ese servicio web.
• .Solicitud .vsdisco: Se puede activar el descubrimiento dinámico para
permitir a l as aplicac iones de clie nte de servicios w eb descu brir t odos los
servicios web disponibles en la carpeta y subcarpetas que corresponden a la
dirección URL de una solic itud. No es necesario crear ningún documento de
descubrimiento estático. Cuando s e activa el descubrimiento dinámico para
ASP.Net
107
un servidor web, si queremos gene rar un proxy de cliente podemos
especificar una dirección URL qu e haga referenci a a u n archi vo con una
extensión .vsdisco, como www. p ruebas.com/default.vsdisco, en el cuadro
de diálogo Agregar referencia Web.
Para implementar el serv icio web, crearemos u n directorio virtual en nuestro
servidor web y colocaremos el arc hivo .asmx del servicio web en ese directorio.
El directorio virtual también debería ser u na aplicación web de l os servicios de
Internet Information Server (IIS), aunq ue no es necesari o. Una
implementación típica tendría la siguiente estructura de directorios:
\Inetpub
\Wwwroot
\StockServices
StockServices.asmx
\Bin
Ensamblados usados por el servicio web que no forman parte
de Microsoft .NET Framework.
Al publicar un servicio web, los siguientes elementos se implementan a un servidor
web.
ELEMENTO DESCRIPCIÓN
Directorio de aplicación Web Actúa como el directorio raíz de su servicio web. Todos
los archivos restantes se colocan en este directorio.
Este di rectorio deberí a marcarse com o una apli cación
web de IIS.
Archivo
<MyXMLWebService>.asmx
Actúa como la di rección URL base para los clientes que
llaman al se rvicio web. El nombre del archi vo p uede
ser cualquier nombre de archivo válido.
Archivo
<MyXMLWebService>.disco
(Opcional). Actúa como mecani smo de descubri miento
para el servicio web XML. El archivo .di sco no se crea
automáticamente para un servicio web XML. El nombre
del a rchivo puede s er cu alquier n ombre de a rchivo
válido.
Archivo Web.config (Opcional). Si n ecesita in validar lo s p arámetros de
ASP.Net
108
configuración predeterminada, puede incluir un archivo
Web.config. Los servi cios web usan el archi vo de
configuración p ara pe rmitir la p ersonalización y
extensibilidad del sistema.
Por ej emplo, puede proporci onar un archi vo
Web.config específico del servicio web si éste re quiere
autenticación, p ero s i o tras a plicaciones we b d el
sistema no la necesitan.
Directorio \Bin Contiene los archivos binarios para el servicio web. Si
su clase de servicio web no está en el mismo archivo
que el archi vo . asmx, e l ensambl ado que conti ene l a
clase debe estar en el directorio \Bin.
Habilitar la detección de servicios web XML
Los servicios web se pueden p ublicar a los clientes potenciales de las maneras
siguientes:
• Usando un archivo de descubrimiento XML con una extensión de nombre de
archivo .disco.
• Usando una dirección URL que especifica una extensión .vsdisco.
• Usando un servicio web con una cadena de consulta ?DISCO.
5.2 PUBLICACIÓN
Publicar un documento de descubrimiento estático para un servicio web
1. Creamos un documento XML con cualquier editor, agregando el elemento
?xml version="1.0" ? en la primera línea.
2. En el documento XML agregamos un elemento discovery
<disco:discovery
xmlns:disco="http://schemas.xmlsoap.org/disco/">
</disco:discovery>
3. En e l elemento discovery, ag regamos referencias a descripciones de
servicios, esquemas XSD y otros documentos de descubrimiento.
ASP.Net
109
Podemos agregar tantas referencias co mo queramos exponer públic amente.
Las referencias de descripción de servicio se especifican en un documento de
descubrimiento agregando un elemento contractRef con el esp acio de
nombres XML http://schemas.xmlsoap.org/disco/scl/. Igualmente, las
referencias a otros documentos de descubrimiento y esquemas XSD se
especifican agregando discoveryRef y elementos XML schemaRef,
respectivamente. Para obtener refere ncias de esquemas XSD, s e debe
especificar el http://schemas.xmlsoap.org/disco/schema del espacio
de nombres XML. Pa ra los tres ti pos de documentos de referencia,
especificamos la ubicación del documento con el atributo ref. El ejemplo de
código siguiente tiene re ferencias a un docu mento de descubri miento, una
descripción de servicio y un esquema XSD.
<?xml version="1.0"?>
<discovery xmlns="http://schemas.xmlsoap.org/disco/">
<discoveryRef ref="/Folder/Default.disco"/>
<contractRef ref="http://MyWebServer/UserName.asmx?WSDL"
docRef="Service.htm"
xmlns="http://schemas.xmlsoap.org/disco/scl/"/>
<schemaRef ref="Schema.xsd"
xmlns="http://schemas.xmlsoap.org/disco/schema/"/>
</discovery>
Las referencias pueden ser relativa s al directorio donde reside el documento
de descubrimiento, como se muestra en el elemento discoveryRef o a un
URI, como se muestra en el elemento contractRef.
4. Implementamos el do cumento de de scubrimiento en u n serv idor w eb
copiándolo en un directorio virtual del mismo.
5. Opcionalmente, si queremos permitir a los posibles usuarios navegar a una
dirección URL especificando una a plicación IIS si n tener que especi ficar un
documento, podemos agregar un vínculo a la página predeterminada de la
aplicación IIS. Esto tiene la v entaja de que los posibles usuarios no tienen
que saber el nombre de ni ngún documento de descubrimiento. Los
usuarios pueden proporcionar a cont inuación direcciones URL c omo la
siguiente durante el proceso de descubrimiento:
http://MyWebServer/MyWebApplication
ASP.Net
110
Si la pág ina predeterminada de la aplicac ión web es una documento XML,
agregaremos un vínculo al documento de descubri miento en el elemento
head de la página web predeterminada para el servidor web. Por ejemplo:
<HEAD>
<link type='text/xml' rel='alternate' href='MyWebService.disco'/>
</HEAD>
Si la pág ina predeterminada de la aplicación web es una página HTML,
agregaremos un vínculo al documento de descubri miento en el elemento
de head de la pág ina web pr edeterminada para el servidor web. Por
ejemplo:
<?xml-stylesheet type="text/xml" alternate="yes"
href="MyWebService.disco" ?>
Habilitar el descubrimiento dinámico para un servicio web
Para activar la detección di námica en un servi dor web, modifique el archivo
machine.config agregando el s iguiente elemento <add>. Omita los salt os de
línea en el ejemp lo s iguiente cuando el atributo type deba estar en una línea
<configuration>
<system.web>
<httpHandlers>
<add verb="*" path="*.vsdisco"
type="System.Web.Services.Discovery.DiscoveryRequestHandler,
System.Web.Services, Version=1.0.3300.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
validate="false"/>
</httpHandlers>
</system.web>
</configuration>
ASP.Net
111
6. HERRAMIENTAS DE SERVICIOS WEB XML
6.1 WSDL.EXE
Esta herramienta genera código para serv icios web XML y clientes de servicios web
XML de ASP.N ET a pa rtir de archivos de contrato WSDL, esquemas XSD y
documentos de descubrimiento (.discomap).
Un archivo .wsdl es un documento XM L es crito con u na gramáti ca denomi nada
Lenguaje de descripción de servicios Web (WSDL). En este archivo se
describe cómo se comporta un se rvicio web XML y cómo se in struye a los clie ntes
para que interactúen con el servicio.
Cuando se utiliza Wsdl.exe para crear una clase de proxy, se crea un único
archivo de código fuente en el lenguaje de programación especificado. Durante el
proceso de generación del cód igo fuente para la c lase de proxy, la herramienta
determina el t ipo más adecuado para u tilizarlo con los o bjetos especif icados en la
descripción de servicio. En algunos ca sos, l a herrami enta usa un en foque de
denominador menos común para convertir los objetos a un tipo determinado. Como
consecuencia, es posible que el tip o generado en la clase de proxy no sea el que
deseamos o esperam os. Por ej emplo, cuando Wsdl.exe encuentra un tipo
ArrayList en una des cripción de servicio, crea Object Array en la clase de proxy
generada. Para garantizar que las conversi ones de tipo de objeto s ean correctas,
abriremos el archivo que contiene la c lase de proxy generada y cambiaremos los
tipos de objeto incorrectos al tipo de objeto esperado.
wsdl [options] {URL | path}
Los argumentos que tiene son:
• Dirección URL: Dirección URL de un archivo de contrat o WSDL (.wsdl), de
un archivo de esquemas XSD (.xs d) o de un documento de descubrimiento
(.disco). Hay que tener en cuenta que NO se puede especificar una dirección
URL de un documento de descubrimiento (.discomap).
• Ruta de acceso (path): Ruta d e acceso a un archivo local de contrato
WSDL (.wsdl), a un archi vo de esquema XSD (.xsd) o a un docum ento de
descubrimiento (.disco o .discomap).
ASP.Net
112
Las opciones que tenemos pueden ser:
OPCIÓN DESCRIPCIÓN
/appsettingurlkey:clave
O bien
/urlkey:clave
Especifica l a cl ave de co nfiguración q ue se usa para
leer el val or predet erminado de l a propi edad de
dirección URL cuando se genera código. Cuando se usa
la opci ón /parameters, este val or es el el emento
<appSettingUrlKey> y contiene una cadena.
/appsettingbaseurl:direcciónurlbase
O bien
/baseurl:direcciónurlbase
Especifica la di rección URL bas e que se uti liza al
calcular el fragmento de di rección URL. Esta
herramienta cal cula el fragmento de di rección URL
convirtiendo l a di rección URL re lativa desde el
argumento direcciónurlbase en la dirección URL que
contiene el documento WSDL. Con esta opción se debe
especificar l a opci ón /appsettingurlkey. Cuand o se
usa l a opción //parameters, este val or es el
elemento <appSettingBaseUrl> y conti ene una
cadena.
/d[omain]:dominio Especifica e l n ombre del d ominio q ue s e u tiliza para
conectarse a un servi dor que requi era autenti cación.
Cuando se usa la opción /parameters, este valor es el
elemento <domain> y contiene una cadena.
/l[anguage]:lenguaje Especifica e l le nguaje q ue s e u tiliza para la c lase d e
proxy gener ada. Como argumento d e l enguaje pu ede
especificar CS (C#; val or predeterminado), VB (Visual
Basic), J S ( JScript) o VJS (Vi sual J #). Tambi én se
puede especificar e l nombre compl eto de l a c lase que
implementa
System.CodeDom.Compiler.CodeDomProvider (Cl ase).
Cuando se usa la opción /parameters, este valor es el
elemento <language> y contiene una cadena.
/n[amespace]:espaciodenombres Especifica el espacio de nombres del proxy o pl antilla
generados. La opción predeterminada es el espacio de
nombres gl obal. Cua ndo se u sa l a opci ón
/parameters, este val or es el elemento
<namespace> y contiene una cadena. Este elemento
debe estar en el archivo de parámetros.
/nologo Suprime la presentación d e la p ortada d e in icio d e
ASP.Net
113
Microsoft. Cuando se uti liza l a opci ón / parameters,
este valor es el elemento <nologo> y contiene true o
false.
/order Genera i dentificadores de or den expl ícitos en
miembros de partícula.
/o[ut]:nombredearchivo o
nombrededirectorio
Especifica el archivo (o di rectorio) en el que se guarda
el códi go proxy generad o. Tambi én puede espe cificar
un directorio en el que se podrá crear este archivo. La
herramienta deri va el nombre de arc hivo
predeterminado del nomb re de s ervicio web XML. La
herramienta guarda l os conjuntos de datos generados
en vari os archivos. Cuando se usa l a opc ión
/parameters, este val or es el e lemento <out> y
contiene una cadena.
/parameters Lee las opciones de línea de comandos del archivo XML
especificado. Usaremos esta opción para pasar un gran
número de opciones de una vez a l a herramienta
Wsdl.exe. La forma abrevi ada es /par:. Los elementos
de opci ón se encu entran en un el emento
<wsdlParameters
xmlns="http://microsoft.com/webReference/">
.
/parsableerrors Muestra l os errores en u n formato simil ar al for mato
de los in formes de errores que usan los compiladores
de l enguajes. Cuando se usa l a opci ón /parameters,
este val or e s el el emento <parsableerrors> y es
true o false.
/p[assword]:contraseña Especifica la contraseña que se utiliza para conectarse
a u n s ervidor q ue re quiere a utenticación. Cu ando s e
usa la opción /parameters, este val or es el elemento
<password> y contiene una cadena.
/protocol:protocolo Especifica el protocol o que se i mplementa. Se puede
especificar SOA P (el val or pred eterminado), Http Get,
HttpPost o el protocol o personali zado que se
especifique en el archivo de configuración. Cuando se
usa la opción /parameters, este val or es el elemento
<protocol> y contiene una cadena.
ASP.Net
114
/proxy:direcciónURL Especifica l a di rección URL del servi dor proxy u sada
para las solicitudes HTTP. La opción predeterminada es
que se use la configuración del sistema proxy. Cuando
se usa l a opci ón / parameters, este val or es el
elemento <proxy> y contiene una cadena.
/proxydomain:dominio
O bien
/pd:dominio
Especifica el dominio que se usa para conectarse a un
servidor proxy que requiere autenti cación. Cuando se
usa la opción /parameters, este val or es el elemento
<proxydomain> y contiene una cadena.
/proxypassword:contraseña
O bien
/pp:contraseña
Especifica la contraseña que se usa para conectars e a
un servidor proxy que requiere autenticación. Cuando
se usa l a opci ón / parameters, este val or es el
elemento <proxypassword> y contiene una cadena.
/proxyusername:nombredeusuario
O bien
/pu:nombredeusuario
Especifica el nombre de usuari o qu e se usa para
conectarse a un serv idor proxy que requ iere
autenticación. Cuando se usa la opción /parameters,
este val or es el el emento <proxyusername> y
contiene una cadena.
/server Genera una clase abstrac ta para un s ervicio web XML
basada en c ontratos. El val or predet erminado es que
se generen c lases de proxy cli ente. Cuando se usa l a
opción /parameters, este val or e s un el emento
<style> que contiene el valor "server".
/serverInterface Genera i nterfaces para l a i mplementación en el
servidor de un servicio web ASP.NET. Para cada enlace
en l os docu mentos WS DL se genera una i nterfaz.
WSDL por sí sol o implementa el contrato WS DL (l as
clases que i mplementan la interfaz no deben i ncluir lo
siguiente en los métodos de clase: atributos de servicio
web o atri butos de s erialización que cambi en el
contrato WSDL). La forma abrevi ada es /si. Cuando se
usa la opción /parameters, este valor es un elemento
<style> que contiene el valor "serverInterface".
/sharetypes Activa la ca racterística de uso comparti do de tipos.
Esta caracter ística permi te crear un a rchivo de códi go
con una defini ción de t ipo úni ca para ti pos idénticos
que compar ten di stintos servi cios (el espacio de
ASP.Net
115
nombres, el nombre y l a firma de con exión deben ser
idénticos). Haga r eferencia a los s ervicios con
direcciones URL "http://" como parámetros de l ínea de
comandos o cree un do cumento di scomap para l os
archivos l ocales. Cua ndo se u sa l a opci ón
/parameters, este val or es el elemento
<sharetypes> y es true o false.
/u[sername]:nombredeusuario Especifica el nombre de usuari o qu e se uti liza para
conectarse a un servi dor que requi era autenti cación.
Cuando se usa la opción /parameters, este valor es el
elemento <username> y contiene una cadena.
/? Muestra l a s intaxis de c omandos y opciones par a l a
herramienta.
En este ejemplo en la línea de comandos creamos una clase de pro xy cliente e n
lenguaje Visual Basic de Microsoft para un servicio web XML ubicado en la dirección
URL especificada. La herramienta guarda la clase de pro xy cliente en el archivo
myProxyClass.vb.
wsdl /language:VB /out:myProxyClass.vb
http://hostServer/WebserviceRoot/WebServiceName.asmx?WSDL
En este código de ejemplo se muestra un archivo WSDL /parameters básico, que
sólo t iene escritos los elementos requerid os que se pueden usar en combinación
con un argumento URL en el símbolo del sistema.
<wsdlParameters xmlns="http://microsoft.com/webReference/">
<nologo>true</nologo>
<parsableerrors>true</parsableerrors>
<sharetypes>true</sharetypes>
</wsdlParameters>
Los documentos WSDL se agreg an al archivo WSDL /parameters mediante e l
elemento <documents>, como podemos ver en el siguiente ejemplo de código. Se
puede usar cualquier número de elementos <document> dentro del elemento
<documents>.
ASP.Net
116
<wsdlParameters xmlns="http://microsoft.com/webReference/">
<nologo>true</nologo>
<parsableerrors>true</parsableerrors>
<sharetypes>true</sharetypes>
<documents>
<document>http://www.ejemplo.com/service.asmx?WSDL</document>
</documents>
</wsdlParameters>
Este archi vo WSDL /parameters se muestra el uso de los e lementos
<codeGenerationOptions> y <style> dentro del elemento
<webReferenceOptions>. En este caso, el archivo permite e l nuevo estilo de
enlace de datos en el código proxy, y es pecifica una extensión de importador de
esquemas, que los resultados no deben ser detallados y que W sdl.exe debe c rear
un servidor proxy de cliente.
<wsdlParameters xmlns="http://microsoft.com/webReference/">
<nologo>true</nologo>
<parsableerrors>true</parsableerrors>
<sharetypes>true</sharetypes>
<documents>
<document>http://www.ejemplo.com/service.asmx?WSDL</document>
</documents>
<webReferenceOptions>
<verbose>false</verbose>
<codeGenerationOptions>properties newAsync enableDataBinding</codeGenerationOptions>
<schemaImporterExtension>
<type>MyNamespace.MyCustomImporterExtension,ExtensionLibrary</type>
</schemaImporterExtensions>
<style>client</style>
</webReferenceOptions>
</wsdlParameters>
6.2 DISCO.EXE
Esta herramienta permite descubrir d irecciones URL de servicios web XML ubicados
en un servi dor web y guardar los document os relacionados con cad a servicio Web
XML en un disco local.
El archivo .discomap pu blicado en un serv icio web XML es un documento X ML
que, por lo gen eral, contiene vínculos a ot ros recursos descritos en el servicio web
XML. Los s itios web que implementan un servicio web XML no necesitan ser
ASP.Net
117
compatibles con esta herramienta. Los servicios web XML se pueden crear para uso
privado.
Los archi vos .wsdl , .xs d, .di sco y .di scomap generados por esta h erramienta se
pueden u tilizar como entrada de la h erramienta L enguaje de d escripción de
servicios web (Wsdl.exe) para crear clientes de servicios web XML.
disco [options] URL
Solamente tiene un argumento y es la dirección URL para la que se descubren y
generan los documentos de descubrimiento publicados (archivos .wsdl, .xsd, .disco
y .discomap).
Las opciones que tiene son:
OPCIÓN DESCRIPCIÓN
/d[omain]:dominio Especifica el nombre del dominio que se
utiliza para con ectarse a u n serv idor prox y
que requiera autenticación.
/nosave Esta opción no g uarda los d ocumentos
descubiertos ni los resultados (archivo s
.wsdl, .xsd, .di sco y .discomap) en el disco.
El valor predetermina do es que se guarden
los documentos.
/nologo Suprime la presentación de la portada de
inicio de Microsoft.
/o[ut]:nombrededirectorio Especifica el di rectorio de resultados en el
que se guardan los documentos descubiertos.
El valor p redeterminado es e l director io
actual.
/p[assword]:contraseña Especifica la contraseña que se utiliza para
conectarse a un servidor proxy que requiera
autenticación.
ASP.Net
118
/proxy: Dirección URL Especifica la direcc ión URL del servidor proxy
utilizada para las solic itudes HTT P. E l v alor
predeterminado es que se use la
configuración del sistema proxy.
/proxydomain: dominio
O bien
/pd :dominio
Especifica el dominio que se usa para
conectarse a un servidor proxy que requiera
autenticación.
/proxypassword: contraseña
O bien
/pp: contraseña
Especifica la contrase ña que se usa para
conectarse a un servidor proxy que requiera
autenticación.
/proxyusername:
nombredeusuario
O bien
/pu: nombredeusuario
Especifica el nombre de usuari o que se usa
para conec tarse a un servidor proxy q ue
requiera autenticación.
/u[sername]:nombredeusuario Especifica el nombre de usuari o que se usa
para conec tarse a un servidor proxy q ue
requiera autenticación.
/? Muestra la sintaxis de comandos y opciones
de la herramienta.
En este ejemplo ve mos la línea de comando que busca documentos de
descubrimiento en la dirección URL especificada y los guarda en el directorio actual.
La herramienta muestra un mensaje de error si no descubre nuevos recursos en la
dirección URL especificada.
disco http://www.ejemplo.com/ejemploWebservice.disco
El siguiente comando busca documentos de descubrimiento en la dirección URL
especificada y los guarda en el directorio de resultados especificado.
disco /out:myDir http://www.ejemplo.com
ASP.Net
119
7. ESQUEMA DE CONFIGURACIÓN DE SERVICIOS WEB XML
El esquema de configuración de servicios web define elementos de archivos de
configuración que controlan el comportamiento de los servicios web ASP.NET y sus
clientes. El elemento principal es <webServices>.
Por defecto , el eleme nto <webServices> y sus descendientes se aplican a
cualquier serv icio w eb o clase de prox y a la qu e se aplica la con figuración. La
configuración se apl ica segú n el t ipo de aplicación, t al como se indica a
continuación:
• Aplicación web ASP.NET (servicio o cliente): E l elemento
<webServices> suele colocarse en un archivo Web.config.
• Aplicación .NET Framework independiente (sólo cliente): El elemento
<webServices> suele colocarse en el archivo de configuración de la
aplicación.
El elemento <webServices> y sus descendientes se aplican a los siguientes tipos
de clases:
• Una clase de servicio web que se deriva de WebService.
• Una clase de proxy de cliente que s e deri va indi rectamente de
WebClientProtocol.
Un elemento <webServices> puede aplicarse tanto a un servicio web como a un
cliente en el caso de que una aplicación web contenga ambas entidades.
ASP.Net
120
El esqueleto de un esquema de configuración sería el siguiente:
<configuration>
<system.web>
<webServices>
<protocols>
<add>
<remove>
<clear>
<serviceDescriptionFormatExtensionTypes>
<add>
<remove>
<clear>
<soapExtensionTypes>
<add>
<remove>
<clear>
<soapExtensionImporterTypes>
<add>
<remove>
<clear>
<soapExtensionReflectorTypes>
<add>
<remove>
<clear>
<wsdlHelpGenerator>
ASP.Net
121
Los elementos del esquema son:
ELEMENTO DESCRIPCIÓN
<add> para <protocols> Agrega un protocolo especificado que p uede
utilizar u n serv icio Web ASP .NET para recibi r
datos de solicitudes en viados por un cl iente y
devolver datos de respuesta.
<add> para
<serviceDescriptionForm
atExtensionTypes>
Agrega una cl ase especi ficada de extensi ón de
formato de descripción de servicio (SDFE) que
define cómo extender las descripciones de
servicio ( documentos WSDL) generadas para los
servicios Web.
<add> para
<soapExtensionTypes>
Agrega una clase especifi cada de extensión SOAP
que propo rciona procesamiento extendido de
mensajes SOAP en el servicio Web o en el cliente.
<add> para
<soapExtensionImporter
Types>
Agrega una clase especifi cada de importador de
extensión SOAP, que extiende el proceso de
generación de proxy d e cliente para el uso con
una extens ión de formato de descripción de
servicio (SDFE).
<add> para
<soapExtensionReflector
Types>
Agrega una clase especificada de reflector de
extensión SOAP, que extiende el proceso de
generación de descripción de servicio (documento
WSDL) para el uso con una extensión de formato
de descripción de servicio (SDFE).
<clear> Quita t odas las ref erencias a los e lementos
correspondientes a la etiqueta primaria.
<protocols> Especifica los protocolos que puede utilizar un
servicio W eb ASP.N ET para recibir datos de
solicitudes en viados por u n clien te, y dev olver
datos de respuesta. Un protocolo puede utilizarse
para asociar los datos de la solicitud con un
método y sus parámetros, así como para asociar
ASP.Net
122
los datos de la respuesta con el método y su valor
devuelto.
<remove> para
<protocols>
Quita un protocolo e specificado para controlar
datos de solicitud y respuesta desde el ámbito del
archivo de configuración.
<remove> para
<serviceDescriptionForm
atExtensionTypes>
Quita del ámbito del archivo de configuración una
clase espec ificada de extensión de formato de
descripción de servicio (SDFE).
<remove> para
<soapExtensionTypes>
Quita una cl ase de ex tensión SOAP especi ficada
del ámbito del archivo de configuración.
<remove> para
<soapExtensionImporter
Types>
Quita del ámbito del archivo de configuración una
clase especificada de im portador de extensión
SOAP.
<remove> para
<soapExtensionReflector
Types>
Quita del ámbito del archivo de configuración una
clase especificada de reflector de extensión SOAP.
<serviceDescriptionForm
atExtensionTypes>
Especifica las clases d e extensión de formato de
descripción de serv icio ( SDFE) utilizadas para
extender l os document os WSDL generados para
los servic ios Web. Las cl ases SDFE proporcionan
un medio de describir extensiones SOAP.
<soapExtensionImporter
Types>
Especifica clases de importador de extensión
SOAP, que extienden el proceso de generació n de
proxy de cliente. Para el uso con extensiones de
formato de descripción de servicio (SDFE).
<soapExtensionReflector
Types>
Especifica clases de ref lector de extensi ón SOAP,
que amplían el proces o de generación de
descripción de servicio (doc umento WSDL ). Para
el uso con extensiones de formato de descripción
de servicio (SDFE).
<soapExtensionTypes> Especifica las extensione s SOAP que se utilizan
para inspec cionar o modi ficar e l mensaje S OAP
ASP.Net
123
durante el procesamiento en el servicio Web o en
el cli ente. Las extensi ones SOAP aumentan l a
funcionalidad de los servicios web.
<webServices> Controla la con figuración de serv icios Web
implementados mediante ASP .NET, y l a de
clientes de servicios Web que se ejecutan en .NET
Framework.
<wsdlHelpGenerator> Especifica la página de Ayuda d el serv icio Web
(un archivo .aspx) que se muestra en el
explorador cuando éste navega directamente a
una página ASMX de servicios Web.
ASP.Net
124
EJERCICIOS DE REPASO DE LA UNIDAD DIDÁCTICA 2: REVISANDO EL
DOCUMENTO
ENUNCIADOS.
1. Al añadir un control personalizado en un web form tendremos que registrarlo con…
2. ¿Por qué se utiliza el archivo Global.asax?
3. ¿Puede haber más de un archivo machine.config en un sistema
4. Los controladores del servidor web se procesan en…
ASP.Net
125
SOLUCIONES A LOS EJERCICIOS DE REPASO. UNIDAD DIDÁCTICA 2
1. La frase correcta es: Todo lo anterior: A, B y C.
2. La respuesta correcta es: Porque se necesi ta pa ra i mplementar l os eventos a ni vel de
aplicación y de sesión
3. La respuesta correcta es: Verdadero
4. La respuesta correcta es: En el servidor.
ASP.Net
126
TEMA 3. FUNCIONALIDADES CON ASP .NET
LECCIÓN 1. MANEJO DE FUNCIONALIDADES CON ASP. NET
1. AGREGAR AJAX A SITIOS WEB
Las características de AJAX Asynchronous JavaScript And XML (JavaScript
asíncrono y XML) en ASP.NET permiten generar ap licaciones web enriquecidas
que tienen muchas ventajas frente a las aplicaciones web basadas c ompletamente
en servidor. Las aplicaciones habilitadas para AJAX ofrecen:
• Mayor eficacia, porque las partes importantes del proceso de una página
web se realizan en el explorador.
• Elementos de interfaz de usuario familiares, co mo indicad ores de
progreso, información sobre herramientas y ventanas emergentes.
• Actualizaciones parciales de la página, que actualizan sólo las partes de
la página web que han cambiado.
• Integración de clientes con los serv icios de aplicación de ASP.NET para la
autenticación de formularios, funciones y perfiles de usuario.
• Clases de proxy generadas automáticamente q ue simplifican las
llamadas a los métodos del servicio web desde el script de cliente.
• Un marco que permite personalizar los controles de servidor para
incluir funciones de cliente.
• Compatibilidad para los exploradores más popu lares y u tilizados
habitualmente, incluidos Microsoft Internet Explorer, Mozilla Firefox y Ap ple
Safari.
ASP.Net
127
Arquitectura de cliente y servidor de AJAX en ASP.NET
Figura 1.1
Area componentes
Los componentes de cliente habilitan comportamientos enriquecidos en el
explorador sin devoluciones de datos. Los componentes pertenecen a tres
categorías:
• Componentes, que so n objetos no visuales que encaps ulan el código,
como un objeto de temporizador.
• Comportamientos, que extienden el co mportamiento bási co de l os
elementos DOM existentes.
• Controles, que representan u n nuevo elemento DOM que tiene un
comportamiento personalizado.
El tipo de componente que utilicemos dependerá del tipo de comportamiento
de cliente q ue queramos. Por ejemplo, una marca de agua para un cuadro
ASP.Net
128
de texto existente se puede crear u tilizando un comportamiento asociado al
cuadro de texto.
Área Compatibilidad del explorador
La capa de compatibilidad para exploradores pr oporciona
compatibilidad para script ing de AJ AX para los ex ploradores u tilizados con
más frecuencia (incluidos Microsoft Internet Explorer, Mozilla Firefox y Apple
Safari). E sto permit e escribir e l mismo s cript in dependientemente del
explorador compatible al que esté destinado.
Área Conexión de red
La capa de conexión de red administra la comunicación entre el script del
explorador y los se rvicios y a plicaciones w eb. T ambién adm inistra las
llamadas asincrónicas a métodos remotos. En muchos es cenarios
habituales, como las a ctualizaciones parcial es de la pági na qu e utilizan el
control UpdatePanel, la capa de conexión de red se ut iliza automáticamente
y no es necesario escribir ningún código.
La capa de conexión de red también proporciona compat ibilidad para el
acceso a au tenticación de f ormularios basad a en serv idor, in formación de
funciones e in formación del p erfil en l os script s de cl iente. E sta
compatibilidad también está disponible para las aplicaciones web que n o se
crean u tilizando ASP. NET, siempre qu e la aplicac ión t enga el acceso a la
Microsoft AJAX Library.
Core Services
Área Servicios básicos
ASP.Net
129
Las bibliotecas de scripts de cliente de AJAX en ASP.NET están
compuestas por archivos JavaScript (.js) que proporcionan
características para la programación orientada a objetos. Estas
características habilitan un nivel alto de coherencia y modularidad en
el script ing de cliente. Los siguientes servicios básicos forman parte
de la arquitectura de cliente:
• Extensiones orientadas a objetos par a JavaScript, como
clases, espacios de nombres, cont rol de eventos, herencia, tipos
de datos y serialización de objetos.
• Una biblioteca de clases base, que incluye componentes como
generadores de cadenas y control extendido de errores.
• Compatibilidad para las bibliotecas de JavaScript
incrustadas en un ensambla do o proporcionadas como archivos
JavaScript (.js) independientes. Incrustar las bib liotecas de
JavaScript en un ensamblado puede facilitar la implementación de
aplicaciones y puede ayudar a resolv er los problemas de con trol
de versiones.
Área Depuración y control de errores
Los servicios básicos incluyen la clase Sys.Debug, que proporciona
métodos para mostra r objetos en formato leg ible a l final de una
página web. La clase también muestra los mensajes de
seguimiento de la traza, permit e u tilizar aserciones y permit e
irrumpir en el depurador. La API del objeto Error extendida
proporciona in formación ú til sobre las excepciones y admit e los
modos de lanzamiento y depuración.
Área Globalización
La arquitectura de serv idor y cliente de AJAX en ASP.NET dispone de
un modelo para localizar y globalizar los scripts de cliente. Esto
permite diseñar aplicaciones que utilizan una base de código única
para proporcionar la interfaz de usuario para muchas configuraciones
regionales (idio mas y refere ncias culturales). Por ejemp lo, la
arquitectura de AJAX permite al código JavaScript dar formato
automáticamente a los objetos Date o Number según la
ASP.Net
130
configuración de l a referencia cultural del explorador del usuario, sin
necesidad de una devolución de datos al servidor.
Area Compatibilidad para scripts
Las características d e AJAX en ASP .NET se implementan mediante la
compatibilidad para los scripts que se envían desde el s ervidor al c liente. E n
función de las caract erísticas qu e habilite mos, se enviarán diferentes scripts al
explorador. También p odemos cre ar scripts de cliente. En ese caso, podemos
utilizar t ambién est as caract erísticas par a admin istrarlos com o arch ivos .js
estáticos (en disco) o como archivos .js incrustados como r ecursos en un
ensamblado.
Las caracte rísticas de AJAX en A SP.NET incl uyen un m odelo para los modos de
lanzamiento y depuración. El modo de lanzamiento permite la comprobación
de errores y el control de excepciones op timizados para el rendi miento, con un
tamaño de script mínimo. El modo de depuración dispone de características de
depuración más sólidas, como la co mprobación de tipos y argumentos.,
minimizando el tamaño del código del lanzamiento.
La compatibilidad con scripts de AJAX en ASP.NET se utiliza para pr oporcionar dos
características importantes:
• Microsoft AJAX Library, que es un si stema de ti pos y un con junto de
extensiones JavaScript que propo rcionan espaci os de nombres, he rencia,
interfaces, enumeraciones, reflexión y características adicionales.
• Representación parcial de la página, que actualiza regiones de la página
utilizando una devolución de datos asincrónica..
La arquitec tura de A JAX en AS P.NET se ge nera sobre la base d el modelo de
localización de ASP .NET 2. 0. qu e proporci ona compat ibilidad adi cional par a los
archivos . js loca lizados qu e se incrustan en un ensambl ado o se p roporciona en
disco.
ASP.Net
131
Area Servicios Web
Con l a func ionalidad de AJAX en una página web ASP.NET , podemos utilizar el
script de cliente para llamar a servicios web ASP.NET (.asmx) y a servicios
de Windows Communication Foundation (WCF) (.svc). Las referencias d el
script nece sarias se agregan automáticame nte a la pá gina y, a s u vez, ge neran
automáticamente las clases de p roxy de ser vicio w eb q ue u tilice e n el scr ipt de
cliente para llamar al servicio web.
Area Servicios de aplicación
Los servicios de aplicación son servicios web integrados basados en la
autenticación de formularios, f unciones y perfiles de usuario de ASP.N ET. Estos
servicios se pueden llamar med iante un scr ipt en una pági na web habilitada para
AJAX, una aplicación cliente de Windows o un cliente compatible con WCF.
Area Controles de servidor
Los controles de servidor de AJAX es tán compuestos por código de servidor y
de cliente q ue se integ ra para gen erar un comportamiento de cliente enriquecido.
Cuando se agrega un control AJAX a una página web ASP.N ET, la página envía
automáticamente el script de cliente de soporte al explorador para la funcionalidad
de AJAX. Podemos proporcionar código de cliente adicion al para personalizar l a
funcionalidad de un control, pero no es necesario.
Los controles de servidor de AJAX en ASP.NET utilizados con más frecuencia son:
• ScriptManager: Administra los recursos del s cript para los componentes de
cliente, represen tación parcia l de la pág ina, loca lización, globaliz ación y
scripts de usuario personalizados. El control ScriptManager es necesario para
poder utilizar los controles UpdatePanel, UpdateProgress y Timer.
• UpdatePanel: Permite actualizar las partes seleccionadas de la pági na, en
lugar de actualizar la página entera u tilizando u na dev olución de dat os
sincrónica.
• UpdateProgress: Proporciona información del estado de las actualizaciones
parciales de la página en controles UpdatePanel.
ASP.Net
132
• Timer: Realiza devoluciones de datos en intervalos definidos. Puede utilizar
el con trol T imer para exponer la página en tera, o u tilizarlo con e l con trol
UpdatePanel para realizar actualizaciones parciales de la página a intervalos
definidos.
Crear un sitio Web habilitado para AJAX
1. En el menú Archivo, hacemos clic en NuevoSitio Web y aparece el
cuadro de diálogo siguiente
Figura 1.2
2. En Plantillas instaladas de Visual Studio, hacemos clic en Sitio Web de
ASP.NET.
3. En el cuadr o Ubicación, escriba el nombre de la carpe ta en la que desea
conservar las páginas de su sitio Web.
Por ejemplo, escribimos el nombre de carpeta C:\sitioweb
ASP.Net
133
4. En la list a Lenguaje, hacemos clic en el lenguaje de programación con el
que queramos trabajar, en nuestro caso Visual Basic-
5. Hacemos clic en Aceptar.
Se crea la carpeta y una página nueva denominada Default.aspx.
1. En el Explorador de soluciones, hacemo s clic con el botón secundario en el
nombre del sitio y hacemos clic en Agregar nuevo elemento.
Se abrirá el cuadro de diálogo Agregar nuevo elemento.
Figura 1.3
2. En Plantillas instaladas de Visual Studio, seleccione Web Forms.
3. Asignaremos a la nueva página el nombre ejemplo.aspx y desactivamos la
casilla Colocar el código en un archivo independiente.
4. Seleccionamos el idioma que queramos usar y hacemos clic en Agregar.
5. Cambiamos a la vista Diseño.
ASP.Net
134
6. En la ficha Extensiones AJAX del cuadro de herrami entas, hacemos doble
clic en el control ScriptManager para agregarlo a la página.
Figura 1.4
7. Arrastre un control UpdatePanel desde el cuadro de herramientas y lo
colocamos bajo el control ScriptManager.
El control UpdatePanel realiza las actualizaciones parciales de la página e identifica
contenido que se act ualiza independientemente del resto de la págin a. A partir de
aquí se añadir ía el có digo necesario como cualquier otro control para realiza r la
operativa que qeurramos en nuestra página
2. OBTENCIÓN DE ACCESO A DATOS
Las aplicaciones Web obtienen acceso normalmente a los orígenes de datos para el
almacenamiento y la recupera ción de datos dinámicos. Se puede escribir cód igo
para el acceso a los dat os utilizando clases del espacio de nombres System.Data
(normalmente denominado ADO .NET) y del espacio de nombres System.Xml.
Este enfoque era normal en versiones anteriores de ASP.NET.
Pero ASP.NET también permite realizar el enlace de dat os mediante declarac ión.
Este proceso n o requiere la existencia de código para los escenarios de datos más
comunes, entre los que se incluyen:
• Seleccionar y mostrar datos.
• Ordenar, paginar y almacenar datos en memoria caché.
ASP.Net
135
• Actualizar, insertar y eliminar datos.
• Filtrar datos utilizando parámetros en tiempo de ejecución.
• Crear escenarios de detalles maestros utilizando parámetros.
Incluye dos tipos de controles de servidor que participan en el modelo de enlace
de datos declarativo: controles de origen de datos y controles enlazados a
datos. Estos controles administran las tareas subyacentes requeridas por el modelo
Web sin es tado para mostrar y actualiz ar d atos en páginas Web ASP.NET. Por
tanto, no es estri ctamente necesari o cono cer los detalles del c iclo de vida d e la
solicitud de página si sólo se va a realizar el enlace de datos.
2.1 CONTROLES DE ORIGEN DE DATOS
Los controles de origen de datos so n co ntroles ASP.NET q ue administran las
tareas de conexi ón a un ori gen de datos y de lectura y escritura de datos. Estos
controles no represen tan ni nguna i nterfaz de usuari o, si no que actúan co mo
intermediarios entre un almacén de datos en part icular (como una base de datos,
un objeto comercia l o un archivo XML) y lo s demás controles de la página W eb
ASP.NET. Contienen u n conj unto de fu nciones para recuperar y m odificar datos,
entre las q ue se in cluyen la con sulta, la ord enación, la pagin ación, el f iltrado, la
actualización, la eliminación y la inserción.
Los controles de origen de datos tamb ién se pu eden ampliar para admit ir
proveedores de almacenamiento y acceso a datos adicionales. ASP.NET incluye los
controles de origen de datos siguientes:
CONTROL DE
ORIGEN DE DATOS DESCRIPCIÓN
AccessDataSource Permite trabajar con una base de datos de Microsoft
Access.
LinqDataSource Permite usar Language-Integrated Query (LINQ)
en una pá gina web ASP.N ET a través de marcado
declarativo para recuperar y modificar dat os de un
objeto de datos. Admi te la generaci ón automáti ca de
comandos de selecci ón, act ualización, in serción y
eliminación. E l con trol t ambién admit e ord enación,
ASP.Net
136
filtrado y paginación.
ObjectDataSource Permite trabajar con un objeto comercia l u otra clase y
crear aplicaciones Web basadas en objetos de nivel
medio para administrar los datos.
SiteMapDataSource Se utiliza con la navegación en el sitio ASP.NET.
SqlDataSource Permite trabajar con prove edores de datos
administrados de ADO.NET, que proporcionan acceso a
bases de d atos de Microsoft SQL Server, OLE DB,
ODBC u Oracle.
XmlDataSource Permite tr abajar con un archi vo XML, que es
especialmente útil para cont roles de servidor ASP.NET
jerárquicos tales como el control TreeView o Menu.
2.2 CONTROLES ENLAZADOS A DATOS
Los controles enlazados a datos representan datos como marcado al explorador
que realizó la solicitud. Un control enlazado a dat os se pu ede enlazar a u n control
de origen de datos y b uscar datos automáticamente en e l momento apropiado de l
ciclo de v ida de la s olicitud de página. Estos contro les pueden aprovechar las
ventajas de las funciones proporcionadas por un control de origen de datos entre
las que se incluyen la ordenación, la pag inación, el alma cenamiento en caché, el
filtrado, la actualización, la e liminación y la inserción. Establecen una conexión con
un control de origen de datos a través de su propiedad DataSourceID.
ASP.NET incluye los controles enlazados a datos que se describen en la ta bla
siguiente.
CONTROL
ENLAZADOS A
DATOS DESCRIPCIÓN
Controles de lista Representa los datos en una variedad de formato de listas.
Entre los con troles de lista se incluyen los c ontroles
ASP.Net
137
BulletedList, CheckB oxList, DropDownLi st, Li stBox y
RadioButtonList.
AdRotator Representa los anuncios de una página como una imagen en la
que los usuarios pueden hacer cl ic para i r a una di rección URL
asociada al anuncio.
DataList Representa los datos en una tabla. C ada elem ento se
representa utilizando una plantilla de elemento definida por el
usuario.
DetailsView Muestra un registro cada vez en disposición de tabla y permit e
editar, eliminar e insertar registros. También se puede realizar
la paginación a través de varios registros.
FormView Es si milar al control DetailsView, pero permi te def inir una
disposición de formato libre pa ra cada regist ro. El contro l
FormView es como un control DataList para un registro único.
GridView Muestra los dat os en una t abla e in cluye compat ibilidad para
editar, actualizar, eliminar, ordenar y paginar datos sin
necesidad de código.
ListView Permite definir el diseño de lo s datos con plantillas. Admit e
operaciones de ordenación au tomática, edi ción, in serción y
eliminación. T ambién pu ede h abilitar la pagin ación medi ante
un control DataPager asociado.
Menu Representa los datos en un menú dinámico jerárqu ico que
puede incluir submenús.
Repeater Representa los datos en una lista. C ada elem ento se
representa utilizando una plantilla de elemento definida por el
usuario.
TreeView Representa los datos en un árbol jerárquico de nodos q ue se
pueden expandir.
ASP.Net
138
2.3 LINQ
Language-Integrated Query (LINQ) proporciona un modelo d e programación
unificado para realizar consultas y actualizar datos de tipos diferentes de oríge nes
de datos y extiende directamente las f unciones de datos en l os lenguajes C # y
Visual Basic. LINQ aplica los prin cipios de la programación orientada a objetos
a los datos relacionales. Para trabajar co n LINQ, po demos uti lizar el control
LinqDataSource o crear directamente consultas LINQ para tener acceso a datos
desde una página web.
Si utilizamos LINQ en una aplicación web, es posible que tengamos que cambiar los
archivos de directivas para la seguridad de acceso del código.
Control LinqDataSource
El control LinqDataSource proporciona una manera fáci l de conectar a l os datos
de una base de datos o a una rec olección de datos e n memoria como una matriz.
Podemos escribir med iante declaración to das las condiciones neces arias para los
escenarios típicos como la recuperación, f iltrado, clasif icación y agru pación de
datos. El control crea dinámicamente las consultas LINQ a partir de los
valores proporcionados mediante declaración.
Al recupera r datos de una clase de contexto de dato s LINQ to SQL, tambi én
podemos configurar este control para administrar las operaciones de actualización,
inserción y el iminación. El control realiza estas tareas sin requerir que se escriban
comandos SQL para ello.
Para mostrar los datos en una página web, enl azaremos un control enlazado a
datos al control LinqDataSource, los controles GridView y DetailsView son
ejemplos de controles enlazados a datos.
En este ejemplo vemo s el m arcado de un control LinqDataSource que conecta con
la base de datos Ejmeplo. Devuelve los registros de la tabla Contactos c uya
propiedad correo tiene un valor igual a 1.
<asp:LinqDataSource
ContextTypeName="EjemploContext"
TableName="Contactos"
Where="Correo=1"
ID="LinqDataSource1"
runat="server">
</asp:LinqDataSource>
ASP.Net
139
Control ObjectDataSource
El control ObjectDataSource se u tiliza cu ando qu eremos interactuar con los
datos de una ma nera más compleja que la que permite el c ontrol
LinqDataSource. Por ejemp lo, puede crear un método de actualización que
permita establecer valores en tablas combinadas.
Este con trol se pu ede u tilizar con un a clase LINQ to SQL. Para ello,
estableceremos la propiedad TypeName en el nombre de la clas e de contexto de
datos. También establecermos los métodos SelectMethod, UpdateMethod,
InsertMethod y DeleteMethod en los métodos de la clase de contexto de datos
que realizan las operaciones correspondientes.
Si utilizamos la ejecución diferida de cons ultas con el control ObjectDataSource,
debemos crear un controlador de eventos para el evento ObjectDisposing para
cancelar la eliminación de la clas e de co ntexto de dato s. Este pas o es necesario
porque LINQ to SQL admite la ejecució n diferida, mientras que el control
ObjectDataSource intent a elim inar el con texto de dat os despu és de la operac ión
Select.
En este ejemplo vemos como cont rol Gr idView puede mostrar datos utilizando un
objeto ObjectDataSource en una página web ASP.NET.
<%@ Register TagPrefix="aspEjemplo" Namespace="Ejemplo.AspNet.VB"
Assembly="Ejemplo.AspNet.VB" %>
<%@ Page language="vb" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html >
<head>
<title>ObjectDataSource - Ejemplo</title>
</head>
<body>
<form id="Form1" method="post" runat="server">
<asp:gridview
id="GridView1"
runat="server"
datasourceid="ObjectDataSource1" />
<asp:objectdatasource
id="ObjectDataSource1"
ASP.Net
140
runat="server"
selectmethod="GetEmpleados"
typename="Ejemplo.AspNet.VB.EmployeeLogic" />
</form>
</body>
</html>
Consultas LINQ
Podemos incluir consultas LINQ en un a págin a w eb sin u tilizar un control de
origen de datos. Normalmente est as consultas se utilizan si nece sitamos utilizar un
operador de consulta que no está disponible en el control LinqDataSource. También
podemos utilizarlo si queremos mostra r datos de sólo lectura en un co ntrol
enlazado a datos sin el procesamiento necesario para crear un control de origen de
datos.
En este ejemplo siguie nte vemos cómo incl uir una co nsulta LI NQ en una página
web mostrando los resultados de la consulta en un control GridView.
Protected Sub Page_Load(ByVal sender As Object, _
ByVal e As System.EventArgs) Handles Me.Load
If Not IsPostBack Then
Dim dataContext As AdventureWorksDataContext = _
New AdventureWorksDataContext()
Dim query = From contact In dataContext.Contacts _
Where contact.EmailPromotion = 1 _
Select contact
GridView1.DataSource = query
GridView1.DataBind()
End If
End Sub
2.4. DATOS DINÁMICOS
Los datos dinámicos de ASP .NET son un marco que permite crear rápida mente
aplicaciones web ASP.N ET controladas por datos. Los datos dinámicos detectan
automáticamente el modelo de datos en tiempo de ejecución y determinan el
comportamiento de l a interfaz de usuario según el modelo de datos. Un marco
ASP.Net
141
con la técnica scaffolding pro porciona al instante un si tio web funci onal para
mostrar y modificar datos.
Scaffolding es un mecanismo que mejora el marco de páginas ASP.NET existente
mostrando dinámicamente página s basadas en el modelo de datos. Ofrece las
siguientes funciones:
• Poco o nada de código para crear una aplicación web controlada por datos.
• Un tiempo de desarrollo rápido.
• Una validación de datos integrada basada en el esquema de base de datos.
• La selección automátic a de datos crea da para cada clave externa o campo
booleano
Dicha técnica podrá personalizarse posteriormente mediante el uso de metadatos y
plantillas o la crea ción de páginas ASP.N ET es tándar par a invalidar el
comportamiento predeterminado. Las aplic aciones web ASP.NET existentes pueden
integrar con facilidad elementos de la lógica de scaffolding en las páginas web.
Los datos dinámicos permiten personalizar y ampliar la in terfaz de usuario que se
representa para mostrar y modificar camp os de datos. Se pueden aplicar las
siguientes posibles personalizaciones:
• Agregar metadatos personalizados a los campos de datos. Podemos
utilizar at ributos para asign ar met adatos a campos de dat os a f in de
personalizar cómo se represen ta la interfaz de usuario de ese campo de
datos para most rarlo y modif icarlo. P or ejemp lo, podemos u tilizar e l
atributo UIHintAttribute para asociar u na plan tilla de campo
personalizada a un campo de datos.
• Agregar información de tipo no intrínseca a los tipos de campo de
datos. Podemos utilizar atributos para asignar un tipo a un campo de dat os
que no proceda direct amente del origen de datos. Por ejemp lo, p odemos
utilizar e l atributo DataTypeAttribute para asociar u n t ipo ad icional, n o
intrínseco, a un campo de datos.
Los datos d inámicos admiten los modelos de datos de LINQ to SQL y Entity
Framework que se i ncluyen en NET Frame work. E stos model os conti enen tipos
CLR q ue los datos dinámicos utilizan para consultar la base de da tos y realizar
operaciones de creación, lectura, actualización y eliminación (CRUD).
ASP.Net
142
Al crear un nuevo proyecto en Visual Studio 2008, podemos seleccionar la plantil la
Clases de LINQ to SQL o Entity Data Model de ADO.NET. Esta selección
determina el tipo de modelo que utilizará el proyecto, es decir, el modelo de LIN Q-
to-SQL o Enti ty Fra mework. La función scaffolding de datos dinámicos
únicamente puede ad mitir uno de l os ti pos de modelo de datos en el mismo
proyecto.
En tiempo de ejecució n, los datos dinámi cos extraen automáticamente información
sobre el modelo de datos, por ejemplo las propiedades de campo de datos. A partir
de esta información, deduce có mo crear la interfaz de usuario para mostrar y
modificar datos. Para representar la interfaz de usuario, utiliza plantillas de campo.
Por ejemplo, los datos dinámicos utilizan la siguiente información para representar
la interfaz de usuario:
• Información sobre las asociaciones entre las tablas para mostrar
columnas de clave externa y navegar entre las tablas.
• Información del tipo de datos para agregar la validación a un campo
de datos. Por ejemplo, la in formación de colu mna n ula se pu ede u tilizar
para det erminar si se requ iere u n campo de dat os, y la in formación de
longitud se puede utilizar para restringir la longitud máxima de la entrada de
texto del usuario.
ASP.Net
143
LECCIÓN 2. OPTIMIZACION DE APLICACIONES ASP.NET
1. APLICAR SEGURIDAD EN APLICACIONES ASP.NET
ASP.NET junto co n Microsoft Internet Information Services (IIS), pued e
autenticar las credenciales del usuario como nombres y contraseña s mediante los
métodos de autenticación siguientes:
• Windows: básica, implícita, y Autenticación de Windows integrada
(NTLM o Kerberos).
• Autenticación mediante formularios, co n la que crea una pá gina de
inicio de sesión y se administra la autenticación en la aplicación.
• Autenticación mediante certificados de cliente
ASP.NET controla el acceso a la in formación de los sitios comparando las
credenciales autenticadas, o representacion es de las mismas, con l os permisos del
sistema de archivos de Microsoft Windows NT o con un archivo XML que contiene la
lista de usuari os autori zados, fu nciones autorizadas (grupos) o verbos HTTP
autorizados.
Relaciones entre los sistemas de seguridad de ASP.NET.
Figura 1.1
En esta imagen todos los clientes Web se comunican con las aplicaciones
ASP.NET a través de Microsoft Internet Information Services (IIS). IIS
autentica la solicitud si fuera necesario y, a continuación, busca el recurso solicitado
(como u na aplicac ión ASP .NET). Si el c liente está autorizado, el recurso estar á
disponible.
ASP.Net
144
Cuando se est á ejecu tando un a aplicación ASP. NET, podemos u tilizar la s
características de seguridad de AS P.NET integradasy también las características de
seguridad de .NET Framework.
La configuración de seguridad de ASP.NET se configura en los archivos
Machine.config y Web.config.
• En e l archivo Machine.config se gu arda la con figuración base y la
predeterminada se establecen, este archivo se ubica en el subdirectorio
Config de la instalación .NET Framework actual.
• En el archivo Web.config se puede establecer una configuración específica
del sitio y otra específica de la aplicación (incluidos los valores de reemplazo
del arch ivo M achine.config). Este archivo estará en los directorios raíz del
sitio Web y de la aplica ción. Los s ubdirectorios heredan las configuraciones
del directorio, a no ser que se reem placen por un arc hivo Web.config del
subdirectorio.
Hay tres subsecciones principales en un archivo Web.config: l as secciones
autenticación, autorización e identidad.
Los valores para cada elemento de segu ridad normalm ente se establecen en e l
archivo Machine.config y se r eemplazan según se a necesario en el archivo
Web.config en la aplicación . T odos los su bdirectorios h eredan aut omáticamente
estos valores, aunque los subdirectorios pueden tener sus propios archivos de
configuración que reemplazan valores heredados.
El ejemp lo siguiente muestra la sintaxis de las secciones de seguridad de un
archivo de configuración:
<authentication mode="[Windows|Forms| None]">
<forms name="name"
loginUrl="url"
protection="[All|None|Encryption|Validation]"
path="path" timeout="minutes"
requireSSL="[true|false]"
ASP.Net
145
slidingExpiration="[true|false]">
<credentials passwordFormat="[Clear|MD5|SHA1]">
<user name="********"
password="********"/>
</credentials>
</forms>
</authentication>
<authorization>
<allow users="comma-separated list of users"
roles="comma-separated list of roles" />
<deny users="comma-separated list of users"
roles="comma-separated list of roles" />
</authorization>
<identity impersonate ="[true|false]"
userName="domain\username"
password="password" />
<trust level="[Full|High|Medium|Low|Minimal]"
originUrl=""/>
<securityPolicy>
<trustLevel name="Full" policyFile="internal"/>
<trustLevel name="High" policyFile="web_hightrust.config"/>
ASP.Net
146
<trustLevel name="Medium" policyFile="web_mediumtrust.config"/>
<trustLevel name="Low" policyFile="web_lowtrust.config"/>
<trustLevel name="Minimal" policyFile="web_minimaltrust.config"/>
</securityPolicy>
Los valores predeterminados de estos elementos se incluyen en la tabla siguiente.
Valor predeterminado Descripción
<allow roles="" /> Una cadena vacía que indica q ue se permiten
todas las funciones de forma predeterminada.
<allow users="*" /> Una cadena vacía que indica que todos los
usuarios ti enen acceso (no se requi ere ni nguna
autenticación).
<authentication
mode="Windows" />
El t ipo de autenticación qu e det ermina el or igen
del va lor User actual. El valor predeterminado es
Windows.
<credentials
passwordFormat="SHA1" />
El algor itmo h ash qu e se u tiliza e n las
contraseñas. El valor predeterminado es SHA1.
<deny roles="" /> Una cadena vacía que indica que no se de niega
ninguna función de forma predeterminada.
<deny users="" /> Una cadena vacía que indica que no se de niega
ASP.Net
147
ningún usuario de forma predeterminada.
<forms
loginUrl="logon.aspx" />
Dirección URL a la que se dirige la so licitud si
establece la autenticación mode como Forms y si
la so licitud n o t iene u n v ale de au tenticación
válido.
<forms name=".ASPXAUTH"
/>
El nombre bajo el qu e la cook ie de au tenticación
de formularios se almace na en el equipo del
usuario.
<forms path="/" /> La ruta de acceso a la que se aplica la
autenticación de f ormularios. E l v alor
predeterminado es todas las rutas de a cceso
desde la raíz de la aplicación hacia abajo.
<forms protection="All" /> La seguridad que se ha aplicado al vale de
autenticación de f ormularios. Los valores incluyen
All, None, Encryption y Validation.
<forms timeout="30" /> El tiempo d e espera e n minutos antes de que el
vale de au tenticación de f ormularios expire y los
usuarios tengan que volver a autenticarse.
<forms requireSSL="false"
/>
Un valor booleano que indi ca si se requiere una
conexión SSL para t ransmitir la cook ie de
autenticación.
<forms Un valor booleano que indica si es tá habilitado el
ASP.Net
148
slidingExpiration="true" /> plazo de expiración.
<identity
impersonate="false" />
Un valor booleano que indica s i la suplantación
está habilitada.
<identity userName="" /> Una cadena vacía que indica que no se especif ica
ninguna i dentidad de us uario de fo rma
predeterminada.
<identity password="" /> Una cadena vacía que indica que no se especif ica
ninguna co ntraseña p ara l a identidad de usuari o
de forma predeterminada.
<trust level="Full"
originUrl="" />
La directiv a de seguridad que s e aplicará a la
aplicación.
<trustLevel name="Full"
policyFile="internal"/>
El archivo de directivas predeterminado para el
nivel de confianza Full.
<trustLevel name="High"
policyFile="web_hightrust.co
nfig"/>
El archivo de directivas predeterminado para el
nivel de confianza High.
<trustLevel name="Medium"
policyFile="web_mediumtrus
t.config"/>
El archivo de directivas predeterminado para el
nivel de confianza Medium.
<trustLevel name="Low" El archivo de directivas predeterminado para el
ASP.Net
149
policyFile="web_lowtrust.con
fig"/>
nivel de confianza Low.
<trustLevel name="Minimal"
policyFile="web_minimaltrus
t.config"/>
El archivo de directivas predeterminado para el
nivel de confianza Minimal.
1.1. SUPLANTACIÓN
El escenario de suplantación se basa en la au tenticación de Serv icios de
Microsoft Internet Information Server (IIS) y en la seguridad de acc eso a archivos
de Microsoft Windows para minimizar la programación de la segu ridad en la propia
aplicación ASP.NET.
Figura 1.2
1. Una solicitud de un cliente de red llega a IIS.
ASP.Net
150
2. IIS autentica al cl iente utilizando la seguridad básica, implícita o integrada
de Windows (NTLM o Kerberos).
3. Si se autentica al cliente, IIS pasa la solicitud autenticada a ASP.NET.
4. La aplicación ASP.NET suplanta al cliente que realiza la solicitud utilizando el
símbolo (token) de acc eso pasado desd e IIS, y se basa en los permisos d e
archivo NTF S para conceder acceso a los rec ursos. La a plicación ASP.N ET
sólo necesita comprobar que la su plantación está establecida en true en el
archivo de con figuración de ASP .NET; no s e requi ere ni ngún có digo de
seguridad de ASP.NET.
Si la suplantación no está habilitada, la aplicación se ejecuta con la identidad
de proceso de ASP.NET. En Microsoft Windows 2000 Ser ver y Wind ows XP
Professional, la identidad predetermina da es una cuenta l ocal denomi nada
ASPNET que se crea automáticamente al instalar ASP.NET. En Microsoft
Windows S erver 2003, la identidad pr edeterminada es la del grupo de
aplicaciones correspondiente a la aplicación IIS (de manera predeterminada,
la cuenta Servicio de red).
5. Si se concede el acceso, la aplicación ASP.NET devuelve el recurso solicitado
a través de IIS.
1.2. AUTENTICACIÓN DE FORMULARIOS
En el escenario de autenticación de formularios, una apl icación obti ene las
credenciales, como el nombre y la co ntraseña, di rectamente del usuari o y
determina por sí misma su autenticidad.
La aplicación NO u tiliza l a au tenticación de IIS, per o la con figuración de la
autenticación de IIS puede afectar a la au tenticación de formularios. Como norma,
cuando se utiliza la autenticación de f ormularios, se h abilita el acceso anónimo en
IIS. Por otr a parte, si l os usuari os no pasan l a autenti cación de IIS, no p ueden
ponerse en contacto c on l a apli cación pa ra proporci onar un nombre de usuari o y
una contraseña para la autenticación de formularios.
ASP.Net
151
Figura 1.3
1. Un usuario genera una solicitud de un recurso protegido.
2. IIS recibe la solicitud y, dado que el acceso anónimo de IIS está habilitado,
IIS no realiza ni nguna autenticación del usuario y la solicitud se pasa a la
aplicación ASP.NET.
3. Dado que el modo de autenticación de AS P.NET se ha establecido en
formularios, la apl icación ASP.NET examina la solicitud para obtener un vale
de autenticación de formularios (una cookie concreta). Si no hay ningún vale
de au tenticación asoci ado a la solic itud, ASP. NET rediri ge la sol icitud a la
página de inicio de sesión especificada en el arch ivo de configuración de la
aplicación.
4. En la página de inic io de sesión, el usua rio escri be las credenciales
requeridas, normal mente u n no mbre y una contras eña. El códi go de
aplicación comprueba las creden ciales para c onfirmar su autenticidad. Si se
autentican las credenciales, el cód igo de aplicación asocia a la respuesta un
ASP.Net
152
vale de au tenticación qu e represen ta las credenciales del usuario. (No se
incluye la con traseña.) Si se produ ce un error en la au tenticación, la
respuesta se devuel ve con un mensaje de acceso denegado o se vuelve a
mostrar el formulario de inicio de sesión.
El vale de autenticación emitido se incluirá en las solicitudes que se real icen
a la aplicac ión ASP .NET con post erioridad. ASP .NET examina la v alidez del
vale medi ante u na Comprobación de la Autenticación de Mensajes
(MAC).
5. Si se autentica al usua rio, ASP.NET compr ueba la autorización y puede
conceder acceso al recurso solicitado inicialmente, redirigi r la so licitud a
alguna otra página o redi rigirla a un módulo de auto rización personalizado,
donde se comprueba si las credenciales están autorizadas a tener acceso al
recurso protegido. Si s e produce un e rror de autorización, ASP.NET redirige
al usuario a la página de inicio de sesión.
Si se autoriza al usuario, se concede el ac ceso al rec urso protegido l a
aplicación puede requerir una prueba adicional de las credenciales antes de
autorizar el acceso al recurso proteg ido, dependiendo del diseño de la
aplicación.
2. MEJORA DEL RENDIMIENTO DE APLICACIONES DE ASP .NET
El modo en que se compila y se configura una aplicación afecta a su rendimiento.
Ahora veremos algunas sugerencias para que el conjunto de ap licaciones Web
funcione eficazmente:
• Si la aplicación Web es grande, hay que realizar una precompilación.
• Reciclar los procesos cuando ejecutemos aplicac iones Web ASP.NE T en
Internet Information Services 5.0.
• Si es necesario, ajustaremos el número de subprocesos de cada proceso
de trabajo de la aplicación. Para las aplicaciones que confíen en gran medida
en los recu rsos ex ternos, con sideraremos l a posibi lidad de h abilitar u na
matriz de procesos Web en los equipos con varios procesadores.
• Deshabilitar el modo de depuración.
ASP.Net
153
• Ajustar los archivos de configuración del servidor Web y de
aplicaciones con cretas para qu e se ajusten a nuestras necesidades,
mediante las técnicas siguientes:
a. Habilitando la au tenticación só lo para las apl icaciones qu e l a
necesiten.
b. Configurando la ap licación de f orma qu e utilice los valores d e
codificación de solicitudes y respuestas adecuados.
c. Quitar los módulos no usados de la canalización de procesamiento de
solicitudes.
Otra opció n para mejorar el r endimiento de la aplicac ión, es con figurar el
almacenamiento en caché en los niveles siguientes:
• Aplicación: En el archivo Web.config de una aplicación, podemos u tilizar
el elemento OutputCacheSection para controlar el almacenamiento en
caché de la aplicac ión complet a. C on est e elem ento podemos con figurar
perfiles de caché que se puedan aplicar a páginas individuales.
• Equipo: Podemos configurar las mismas opciones en el archivo
Machine.config que en el archivo Web.config.
• Página: El almacenamiento en caché se puede configurar en páginas
individuales aplican do los perfiles de caché definidos en un archivo de
configuración. También podemo s configurar propied ades de caché
individuales en la directiva @ OutputCache o mediante atributos en la
definición de clase de la página.
• Control: El almacenamiento en caché de un co ntrol de usuari o s e puede
configurar establ eciendo la directiva @ OutputCache en el archivo del
control de usuario o estableciendo el atributo PartialCachingAttribute en
la definición de clase del control.
ASP.Net
154
3. DEPURACIÓN EN ASP.NET
El código de aplicación puede contener distintos tipo s de errores. La mayoría d e
los errores de sintaxis se detectan dura nte la compilac ión. Sin embargo, hay tipos
de errores que requieren que se depure el código, es decir, que se examin e el
código mientras se ejecuta para validar que la ruta de acceso de ejecución y los
datos son los correctos.
El Kit de desarrollo de software de Windows (SDK) incluye una herramienta
denominada Visual Debugger que permite examinar una aplicación mientra s se
está ejecutando. Esta herramien ta se en cuentra en “%ProgramFiles%\Microsoft
Visual Studio 8\SDK\v2.0\GuiDebug\DbgCLR.exe”
Con el depurador podemos ver exactamente cómo funciona la ap licación
recorriendo cada instrucción a medida que se ejecuta y viendo los datos de c ada
variable. P ara u tilizar Visual D ebugger, lo abriremos y lo asoci aremos al pro ceso
que esté ejecutando las páginas de nuestra aplicación ASP.NET.
En las versiones 5.0 y 5.1 de Internet In formation Ser vices (IIS), y en IIS 6.0
cuando se ejecuta en el modo de aplicación de IIS 5.0, el proceso a l que se asocia
el depurador es el proceso de trabajo de ASP.NET (Aspnet_wp.exe).
En IIS 6.0 cuando se ejecuta en modo de aislamiento de proceso de trabajo, el
proceso al que se aso cia es el proceso de grupo de subprocesos (W3wp.exe).
Cuando el depurador está asociado a un proceso, pue de ver tod o lo que ocurre
durante ese proceso y el depurador vuel ve a asignar al cód igo orig inal las
instrucciones que se ej ecutan en el proceso, de forma que pueda ver cada línea de
código que se ejecuta.
Visual Debugger
Visual Debugger nos permite ex aminar el código mientras se está ejecutando e
incluye características que nos ayudan a depurar aplicaciones como son:
• Puntos de interrupción: Son lugares del código en los que el d epurador
detendrá la aplicac ión, lo que le permite ver el estado de datos actual de la
aplicación y, después, recorrer pas o a paso cada línea de código. Un punto
ASP.Net
155
de interrupción es una señal que indica al depurador que debe suspender
temporalmente la ejecución del programa en un punto determinado. Cuando
la ejecución se suspende en un punt o de interrupció n, se dice que el
programa s e encuentra en modo de interrupción. El paso al modo de
interrupción NO significa el fin de la ej ecución del programa. La ejecución
puede reanudarse en cualquier momento, así que más bien es un tiempo de
espera. Todos los e lementos, por ejemplo, permanecen en la memor ia (las
funciones, vari ables y objetos), pe ro se su spenden sus movimientos y
actividades. Duran te este ti empo podemos examinar sus posic iones y
estados pa ra buscar infracciones o e rrores y realizar ajustes en el
programa. Por ejemp lo, podemos cambiar el valor de una variable. Otra
acciós que podemos realizar es mover el punto de ejecución, con lo cual se
modifica la instrucción que se ejecuta rá a continuación cuando prosiga la
ejecución. En C++, C# y Visual Basic, podemos in cluso cambiar el código
gracias a una función denominada Editar y continuar. En lugar de
recorrer el código línea a línea o in strucción a instrucción, podemos dejar
que el pro grama se ejecute hasta en contrar un punto de interrupción, y
entonces c omenzar l a depuraci ón. Co n ello, el proces o de depuración se
acelera m ucho. Hay muchos lengua jes de progr amación q ue tiene
instrucciones o constru cciones que suspenden la ejecución y dejan e l
programa en modo de interrupción. Vi sual Basic, por ej emplo, incluye la
instrucción Stop. Lo s puntos de interrupción son distintos de estas
instrucciones, ya que NO son código fuente que haya que agregar al
programa. No hay que escribir u na instrucción de punto de interrupción en
una ve ntana de código fuente . L os pu ntos de in terrupción se sol icitan a
través de la interfaz del depurador, y es el depurador el que los establece
automáticamente. Para insertar un punto de in terrupción en una línea, sólo
tiene que hacer clic en el margen gris junto a la línea en cuestión.
• Recorrer paso a paso Una vez que se ha detenido en un punto de
interrupción, podemos ejecutar el códi go línea a línea (lo que se conoce
como recorrer paso a paso el cód igo). Visual Debugger incluye una serie de
características que nos ayudan a r ecorrer el c ódigo, como iteradores que le
permiten especificar c uántas veces hay que recorrer un bucle a ntes de
volver a detenerse.
• Vista de datos Visual Debugger tiene much as opciones diferentes para
ver y h acer u n segu imiento de los dat os mien tras la aplicac ión est á en
ASP.Net
156
ejecución. E l depurador nos pe rmite modificar los datos mientras la
aplicación está detenida en modo de interrupción y, después, seguir
ejecutando la aplicación con los datos modificados.
Vista de la ventana de depuración.
Figura 3.1
Configurar aplicaciones para depuración
Para h abilitar la depu ración para u na aplicación Web ASP .NET, t enemos que
configurar la aplicac ión para qu e se compil e en u na versión de depu ración. Una
versión de depuración incluye información que el depurador necesita para poder
recorrer el código y mostrar el contenido de las vari ables. La confi guración de una
aplicación Web para las v ersiones de depu ración se rea liza en la sección
Compilation del archivo Web.config de la aplicac ión. Como alternativa, si sólo
queremo depurar páginas indi viduales, podemos agregar debug=true a la
directiva @ Page en las páginas que desea depurar.
Depuración local y remota
Si estamos ejecutando un servidor Web localmente, como IIS, po demos depurar
aplicaciones que se ejecuten localmente en nuestro equipo, de forma que podamos
ver las páginas en un explorador.
Si no podemos ejecutar una página loca lmente, porque no podemos ejecutar un
servidor Web o porqu e la aplic ación n o est á dispon ible loca lmente, podemos
depurar una aplicac ión que se e jecute en otro servidor. Para poder realiz ar la
depuración de manera remota, tenemos instalar los componentes de depuración
remota de Visual Studio en el servidor remoto.
ASP.Net
157
Permisos para la depuración
La depuración de un proceso requiere más privilegios que su ejecución. Por
tanto, ade más de co nfigurar la aplica ción para la depuración, tenemos que
asegurarnos también de que disponemos de los permisos adecuados para asociarla
a un proceso con el f in de depurarla. Los administradores pueden depurar cualquier
proceso, pero los usuarios tienen permis o para depurar procesos que se ejecutan
bajo su propia identidad de us uario local, pero no puede n depurar l os procesos de
otro usuario.
ASP.Net
158
EJERCICIOS DE REPASO DE LA UNIDAD DIDÁCTICA 3: REVISANDO EL
DOCUMENTO
ENUNCIADOS.
1. Selecciona el control que no tiene una interfaz visible
2. Se puede escribir el código para acceso a los datos utilizando clases del espacio de
nombres…
3. Selecciona a qué categorías pertenecen los componentes de cliente…
4. El archivo web.config se guarda en el directorio raíz de…
ASP.Net
159
SOLUCIONES A LOS EJERCICIOS DE REPASO. UNIDAD DIDÁCTICA 3
1. La respuesta correcta es: Repeater
2. La respuesta correcta es: A y B.
3. La respuesta correcta es: Componentes, comportamientos y controles.
4. La respuesta correcta es: El sitio web y de la aplicación.
ASP.Net
160
PRÁCTICAS
ENUNCIADOS.
1. Creamos un servicio Web XML que nos da la información de nuestros
clientes. Una vez realizadas las pruebas del servicio y siendo éstas
correctas procedemos a su distribución en un directorio virtual nuevo en
nuestro ordenador de producción. ¿Qué mecanismo de distribución
deberíamos utilizar?
2. Creamos un servicio Web XML que procesa la información de las tarjetas
de crédito. Este servicio lo usarán ordenadores que corren con sistemas
operativos Microsoft Windows, Unix, o Linux. Deberemos asegurarnos
que los credenciales que el cliente pase al servicio sean seguros y no
sean comprometidos. Necesitamos configurar la autenticación de este
servicio. ¿Qué tipo de autenticación deberíamos utilizar?
ASP.Net
161
3. Creamos un servicio Web XML que usa la clase Trace para dar salida en
un fichero log los mensajes de error, mensajes de advertencia y
mensajes de información . Este servicio utiliza el objeto TraceSwitch
para filtrar las trazas de salida. La propiedad DisplayName del objeto
TraceSwitch contiene "ABSwitch". Todas las trazas aparecen en el
fichero log. Queremos mover este servicio a producción configurando el
servicio Web XML para que de salida solamente a los mensajes de error.
¿Qué deberíamos hacer?
4. Tenemos una aplicacion ASP.NET que se llama MyProject en nuestro maquina cliente. Esta aplicación tiene una página que se llama Calendario.aspx. que está cargada en un directorio virtual llamado Agenda, que es una subcarpeta del directorio MyProject. La página Calendario.aspx usa cookies para hacer trazas de las modificaciones de la agenda durante la seión de usuario, así que el usuario puede deshacer las modificaciones que sean necesarias. Al distribuir la aplicación en una máquina llamada TestKing1, necesitamos ver los valores de la cookie después de la secuencia de acciones para ayudar a identificar la causa del problema. Añadimos el siguiente elemento al fichero Web.config: <trace enabled=”true” pageOutput=”false”/> Queremos visualizar la información de salida de la traza en la máquina cliente. ¿Qué URL deberíamos usar?
ASP.Net
162
5. Al distribuir una aplicación cuando ocurre un error, el usuario es
redirigido a una página personalizada de errores que está especificada
en el fichero Web.config. Los usuarios informan que una página en
particular está generando errores varias veces. Necesitamos reunir
información detallada del error para esa página para asegurarnos que
los usuarios de la aplicación puedan continuar viendo la página de
errores. ¿qué deberíamos hacer?
6. En los elementos de un formulario se deben cumplir unas reglas. Indicar cuál de las siguientes no es correcta:
7. Si un módulo HTTP necesitara ser limpiado. ¿Qué metodo deberías incluir?
8. Para incluir un control de usuario en una página de formularios Web Forms, en la página Web ASP.NET contenedora, crearemos una directiva @ Register. Indicar que conjunto de atributos necesitaríamos tener en esta directiva?
ASP.Net
163
ASP.Net
164
SOLUCIONES A LAS PRÁCTICAS.
1. La respuesta correcta es: Setup de un proyecto web
2. La respuesta correcta es: Certificado de cliente
3. La respuesta correcta es: Añadir al fichero Web.config el segmento de código
siguiente:
<system.diagnostics><switches><add name="TestKSwitch" val ue="1"/>
</switches></system.diagnostics.
4. La respuesta correcta es:
HTTP://TestKing1/MyProject/Agenda/Calendario.aspx?trace.axd.
5. La respuesta correcta es:
En el fiche ro Web.config, cambiamos el atributo del elemento customErrors a
RemoteOnly y accedemos a la página desde el navegador del servidor
6. La respuesta correcta es:
La página puede contener varios elementos form
7. La respuesta correcta es:
Dispose()
8. La respuesta correcta es:
TagPrefix, TagName y src
ASP.Net
165
GLOSARIO
A
Aplicación Web ASP.Net
Aplicación que procesa las so licitudes HT TP (solic itudes web) y se ejecuta en
ASP.NET. Un a aplicació n Web ASP. NET pu ede in cluir págin as ASP .NET, serv icios
web, controladores HTTP y módulos HTTP.
Archivo de código subyacente (code-behind file)
Archivo de código que contiene la clase de página que implementa la lóg ica de
programa de una aplicación de Web Fo rms o de formularios Web Forms para
dispositivos móviles de ASP.NET
Archivo de configuración (configuration file)
Archivo XML con la ex tensión .config que contiene la con figuración de las opcion es
para una a plicación o sitio Web. Los arch ivos de confi guración comunes i ncluyen
Machine.config y Web.config.
ASP.Net
Conjunto de tecnologías de Mic rosoft .NET Framework para la creación de
aplicaciones y servicios web. Las páginas ASP.NET se ejecutan en el serv idor y
generan l enguaje de marcado (como HTML, WML o XML) q ue s e enví a a un
explorador móvil o de escrit orio. L as págin as ASP .NET u tilizan u n modelo d e
programación compilado y basado en eventos que mejora el rendimiento y permite
la separación de la lógica de aplicación y de la interfaz de us uario. Las páginas
ASP.NET y los arch ivos de serv icios web creados con AS P.NET contienen lógica de
servidor (en vez de lógi ca de cli ente) escrita en Visual Bas ic, C# o cualquier
lenguaje compatible con .NET. Las aplicaciones y los servicios w eb aprovechan las
características de Common Language Runtim e, como la seguridad de tipos, la
herencia, la interoperabilidad entre lenguajes, el control de versiones y la seguridad
integrada.
Autenticación
Proceso de detectar y comprobar la identi dad de un principal mediante el examen
de las credenciales del usuario y su consulta a una autoridad determinada
Autorización
Proceso de limitar derechos de acceso mediante l a concesi ón o negaci ón de
permisos específicos a una identidad autenticada o un principal
ASP.Net
166
C
Caché de ensamblados global (GAC)
Caché de c ódigo para todo el eq uipo que almacena los ensamblad os instalad os
específicamente para ser compartidos por varias ap licaciones del equipo. Las
aplicaciones imp lementadas en l a cach é de ensamblados global deben tener
nombres seguros
Caché del ensamblado
Caché de código utiliz ada para el almac enamiento simultáneo de ensamblados. La
caché consta de dos partes: la caché de ensamblados global contiene ensamblados
que se instalan explícitamente para co mpartirse entr e varias a plicaciones de l
equipo y la caché de descarga almacena código descargado desde Internet o desde
sitios de la intranet, aislado de la aplicación que causó la descarga, de forma que el
código descargado en nombre de una aplicación o de una página no afecte a o tras
aplicaciones.
Catálogo (catalog)
Archivos que se instalan en Windows Vista para que el reproductor multimedia sepa
cómo interpretar los archivos descargados de internet.
Clase
Tipo de referencia que encapsula datos (constantes y campos) y el comportamiento
(métodos, propiedad es, indizadores, ev entos, operadores, constructores de
instancia, constructores estáticos y destructores), y puede contener tipos anidados.
Los tipos d e clase admiten la herencia, un mecanismo mediante el cual una cl ase
derivada puede extender y es pecializar una clase base.
Clase de Código subyacente (code-behind class)
Clase a la que tiene acceso un archivo .aspx pero q ue reside en un archivo
independiente (como un archivo .dll o .cs). Por ejemplo, puede escribir una clase de
código sub yacente q ue crea un contro l de serv idor ASP .NET personalizado y
contiene código al que se llama desde un archivo .aspx, pero que no reside dentro
del archivo .aspx.
Código administrado
Código ejecutado por el entorno de Common Lang uage Runti me en l ugar de
ejecutarlo directamente el siste ma op erativo. Las aplicaciones de código
administrado obtienen servic ios de Common Lang uage Runt ime, como l a
ASP.Net
167
recolección au tomática de eleme ntos no ut ilizados, la comprobación del t ipo de
motor en tiempo de ej ecución y la compat ibilidad con la segu ridad, en tre ot ros.
Estos servicios ayudan a proporcionar un comportamiento uniforme independiente
de la plataforma y del lenguaje de las aplicaciones de código administrado.
Código no administrado
Código ejecutado directamente p or el sistema operativo, fuera del entorno de
Common L anguage R untime. El códi go no administrado debe suministrar sus
servicios propios de recolección de elementos no utilizados, comprobación de tipos,
compatibilidad con la s eguridad, etcétera, al contrario que el código administrado,
que recibe estos servicios de Common Language Runtime.
Common Language Runtime (CLR)
Motor que es el núcleo de la ejecución de código administrado. El motor en tiempo
de ejecució n proporciona al código admini strado servicios como integración entre
varios lenguajes, seguridad de acceso a código, administra ción de la duración de
los objetos, y compatibilidad con la depuración y la generación de perfiles.
Common Language Specification (CLS)
Subconjunto de carac terísticas d el lenguaje admi tidas por Common Langu age
Runtime, incl uyendo funciones c omunes de vari os l enguajes de programación
orientados a objetos. Se garan tiza qu e las herramientas y los componentes
compatibles con CLS pu eden in teroperar con otras herramientas y componentes
compatibles con CLS.
Consumidor (consumer)
En una conexión de elementos Web, control de servidor que recibe los datos de un
control de proveedor y lo proces a o pres enta. Un consumidor puede ser cualquier
tipo de control de servidor, pero se debe diseñar para qu e f uncione como un
consumidor. Un con sumidor debe tener un método de devolu ción de llamad a
especial marcado con un atri buto Con nectionConsumerAttribute en el có digo
fuente. Est e método recibe los datos del proveedor en el formulario de una
instancia de interfaz.
Control de origen de datos
Objeto que se puede agregar a una página Web ASP.N ET que encapsula la lógica
necesaria para conectarse a un origen de datos, como una base de datos o archivo
XML, y que puede ejecutar co nsultas o cual quier otro comando de acceso a datos.
ASP.Net
168
Un control de origen de datos pue de a su vez proporcionar datos a otros contr oles
en esa página.
Control de servidor ASP.NET
Componente del se rvidor que encapsula la interfaz de u suario y otra funcionalidad
relacionada. Un control de servido r ASP.NET deriva d irecta o indirec tamente de la
clase System.Web.UI.Control. E l supracon junto de controles de servidor ASP.NET
incluye controles de s ervidor Web, cont roles de servidor HTML y controles de
ASP.NET Mobile. La si ntaxis de páginas de un control de servidor ASP.NET incluye
un atributo runat="server" en la etiqueta del control.
Control de servidor HTML
Control de servidor ASP.NET que pertenece al espacio de nombres
System.Web.UI.HtmlControls. Un control de servidor HTML se asigna directamente
a un elemento HTML y se declara en una página ASP.NET como un elemento HTML
marcado por un atributo runat="server", por ejemplo.
Control de usuario
Control de serv idor creado de man era declarativa utilizando la mis ma sintaxis que
una página ASP.NET y guardado como archivo de texto con la extensión .ascx. Los
controles de usuari o permi ten di vidir y reu tilizar la f uncionalidad de página. Al
solicitarlo, el marco de trabajo de pági nas analiza un control de usuari o en una
clase der ivada de System.Web.UI.User Control y compila d icha clase en un
ensamblado qu e vu elve a u tilizar en solicit udes post eriores. L os con troles de
usuario son fáciles de desarrollar debido a su creación de estilos de página y a su
implementación sin previa compilación.
Control dinámico
Control de elem entos Web que se conserva en un almacén de personal ización; no
aparece en el marcad o declarat ivo de una página .aspx. Cua ndo se agrega a una
página, el control WebPartMa nager crea automáticamente una instancia del control
a partir del almacén de personalización en futuras solicitudes.
Control personalizado (custom control)
Control creado por un usuari o o por un pr oveedor de software tercero que no
pertenece a la bibliot eca de clases de .NET Framework. Se trata de un tér mino
genérico q ue también incluye los controle s de usuari o. En l os formul arios Web
Forms ( páginas ASP .NET) se ut ilizan con troles de serv idor personal izados. En las
ASP.Net
169
aplicaciones de los f ormularios W indows Forms se utilizan controles de cliente
personalizados.
Controles de elementos web
Forma general de hacer referencia a cualqu iera de los distintos tipos de controles
en el conjunto de controles de elementos Web
Control dinámico
Control de elem entos Web que se conserva en un almacén de personal ización; no
aparece en el marcad o declarat ivo de una página .aspx. Cua ndo se agrega a una
página, el control WebPartMa nager crea automáticamente una instancia del control
a partir del almacén de personalización en futuras solicitudes.
Controles de servidor de validación
Conjunto de controles de servidor, inclui do en ASP.NET, que comprueban los datos
proporcionados por el usuario. Los datos se comprueban a medida que llegan desde
los controles de servid or HTML y los cont roles de servid or Web (por ejemplo, un
formulario de página Web) utilizando requisitos def inidos por el pro gramador. Los
controles de validación ejecutan la comprobación de entrada en código del servidor.
Si el usua rio está trabajando con un explorador co mpatible c on D HTML, lo s
controles de v alidación t ambién pu eden realiz ar la v alidación med iante script de
cliente
D
Datos dinámicos
Marco que facilita la creación de aplicac iones web controladas por da tos. Los datos
dinámicos u tilizan págin as person alizables y plantillas de campo, scaf folding,
metadatos definibles por el usuario y una denominación basada en convención para
crear interfaces de usuario que muestran datos, permit en a los usuarios navegar
por las rela ciones entre las t ablas, así co mo modificar y crear dato s (operaciones
CRUD).
Devolución de datos asincrónica
Proceso de enviar los datos de la página web (además d el estado de vista y o tros
metadatos necesarios) desde el explorador al servidor s in una devolución de datos
completa y si n bl oquear al usuari o para qu e pueda conti nuar tra bajando en l a
ASP.Net
170
página. Las devoluciones de datos asincrón icas son una característica importante
de la tecnología de AJAX.
E
Encapsulación
Almacén de variables c reado en el servid or para el usuari o actual ; cada usuari o
mantiene un estado de sesi ón independiente en el serv idor. El estado de sesión s e
utiliza n ormalmente para almac enar in formación específ ica de l u suario en tre la s
devoluciones de datos
Enlace de datos
Proceso o método de configuración de co ntroles en un formul ario o pági na Web
para extraer datos de un origen de datos o escribir datos en él como una base de
datos, archivo XML, etc.
Ensamblado
Conjunto de uno o var ios archivos que pertenecen a una versión y se imp lementan
como unidad. Un ensa mblado es el b loque de creac ión principal de una aplicación
.NET Fram ework. Tod os los tipos y recurs os administrados se incluyen e n un
ensamblado y se marc an como accesibl es úni camente dentro del ensamblado o
bien como accesibles desde código de ot ros ensamblados. Los ensamblados
también juegan un papel clave en la seguridad. El sistema de seguridad de acceso a
código u tiliza in formación acerca del en samblado para determinar el conjunto de
permisos que se concede al código del ensamblado.
Espacio de nombres
Esquema de nombres lógico para agrupar los tipos relacionados. .N ET Framework
utiliza u n e squema de n ombres j erárquico p ara agru par los t ipos en cat egorías
lógicas de funcionalidad relacionada, como la tecnología ASP.NET o la funcionalidad
de interacción remota. Las herra mientas de diseño pueden utilizar espacios de
nombres para que los programadores pueda n examinar y hacer r eferencia más
fácilmente a los t ipos en el cód igo. Un ensamblado individual puede contener tipos
cuyos nombres jerárquicos tienen distintas raíces de espacio de nombres y una raíz
de espacio de nombres lóg ico puede ab arcar varios ensamblados. En .NET
Framework, un espacio de nombres es una comodidad para la no menclatura lógica
en tiempo de diseño, mientr as que un ensamblado establece el ámbito de nombres
para los tipos en tiempo de ejecución.
ASP.Net
171
Esquema [schema]
Colección de definiciones de clase que desc riben objet os administrados en un
entorno concreto.
Esquemas XML (XSD)
Lenguaje e stándar de World Wide Web Consortium (W3C ) ut ilizado para crear
documentos de esquema XML. El esquem a XML está formado por dos partes : un
conjunto de tipos pr edefinido ( por ej emplo, string, dateTi me, decimal) y un
lenguaje XML para de finir nuevo s ti pos (po r ejemplo, compl exType, minOccurs,
element). Estado de aplicación
Almacén de variables creado en el servidor para la aplicación actual y compartido
por t odos los u suarios. El est ado de aplic ación se ut iliza n ormalmente para
almacenar información utilizada por todos los usuarios, como la con figuración para
todas las aplicaciones.
Estado de control (control state)
Campo en una página Web AS P.NET que almacena los valores de propiedades
actuales para los con troles de ser vidor en la página. El estado de con trol se u tiliza
para volver a crear la página y restable cer la config uración anterior en cada
devolución de datos.
Estado de sesión
Almacén de variables c reado en el servid or para el usuari o actual ; cada usuari o
mantiene un estado de sesi ón independiente en el serv idor. El estado de sesión s e
utiliza n ormalmente para almac enar in formación específ ica de l u suario en tre la s
devoluciones de datos
Estado de vista
Campo en una pági na Web ASP. NET donde puede al macenar la configuración que
es necesaria conservar entre de voluciones de datos. También suele s ignificar
estado de control.
G
Globalización
Proceso de diseñar y programar un produc to de software de manera que f uncione
en varias configuraciones regionales. La globalización implica la identificación de las
configuraciones region ales que s e deben admitir, e l di seño de característic as
ASP.Net
172
compatibles con dicha s configura ciones re gionales y la escritura de código que
funcione igual de bien en cualquiera de las configuraciones regionales admitidas.
H
Host
En el modelo de programación de complementos de .NET Framework, es el
ensamblado de la aplicación host que se comunica con un complemento a través de
la canalización de comunicación
I
IntelliSense
Tecnología de Microsoft que permite an alizar el c ódigo fuente al mostrar
definiciones de clase y comentarios cuando el cursor se desplaza sobre una función.
IntelliSense también puede completar los nombres de función cua ndo se escriben
manualmente en el IDE.
Interface
Tipo de referencia que de fine un contrato. O tros ti pos impl ementan una i nterfaz
para garantizar que admiten ciertas oper aciones. L a in terfaz especifica los
miembros que las clases u otras interfaces que los implementan deben suministrar.
Al igual que las cl ases, las interfaces pueden contener como m iembros métodos,
propiedades, indizadores y eve ntos. Vea ta mbién: contrato, indizador, propiedad,
tipo de referencia.
Instancia
Para poder usar una cl ase u objeto, hay que crear una instancia del mismo. Es
decir, debemos declarar una variable y a esa variable asignarle el objeto o c lase
en cuestión para que podamos usarlo. Es como si tuviésemos que darle v ida al
objeto par poder usarlo
ASP.Net
173
L
Language Integrated Query (LINQ)
Sintaxis de cons ulta que defi ne u n co njunto de op eradores de consul ta que
permiten e xpresar operaciones d e cruce seguro, filtro y proy ección de manera
directa y declarativa en cualquier lenguaje de programación basado en .NET.
Lenguaje de definición de esquemas conceptuales (CSDL)
Lenguaje basado en XM L qu e se u tiliza para def inir t ipos de en tidades,
asociaciones, contenedores de entidades, conjuntos de e ntidades y conjuntos de
asociaciones de un modelo conceptual.
Lenguaje de definición de esquemas de almacenamiento (SSDL)
Lenguaje basado en XML qu e se u tiliza p ara def inir los t ipos de en tidades,
asociaciones, contenedores de entidades, conjuntos de e ntidades y conjuntos de
asociaciones de un mo delo de almacenamiento, que no rmalmente se corresponde
con un esquema de base de datos.
Lenguaje de descripción de servicios Web (WSDL, Web Services
Description Language)
Lenguaje de contrato basado en XML para describir los servicios de red ofrecid os
por un servidor
Lenguaje de marcado de aplicaciones extensible (XAML)
Lenguaje de marcado para la p rogramación declarativa de aplic aciones. XAML
simplifica la creación de una interfaz de usuario para el modelo de programación de
Windows Presentation Foundation. Puede crear elementos visibles de la interfaz de
usuario en el marcado declarativo XAML y, a continuación, separar l a definición de
la interfaz de usuario de la lóg ica en tiempo de ejecución util izando archivos de
código sub yacente, que se une n al marc ado mediante defini ciones de clases
parciales.
Lenguaje de marcado extensible (XML)
Subconjunto del Leng uaje de marcado gene ralizado estándar (SGML) opti mizado
para su uso a través del Web. XML propor ciona un método uniforme para describir
e intercambiar datos estructurados que es independiente de las apl icaciones o l os
proveedores.
ASP.Net
174
M
Metadatos
Información que describe todos los elementos administrados por Common
Language R untime: u n ensambl ado, el arch ivo cargabl e, el ti po, el método, etc.
Esto pu ede in cluir información n ecesaria par a la depu ración y la recolección de
elementos no utilizados, así como atributos de seguridad, cálculo de referencias de
datos, definiciones ex tendidas de clases y miembros, enlace de versión y otra
información requerida por el motor en tiempo de ejecución.
Método asincrónico
Llamada al método que devuelve inmediatamente al llamador sin tener en cuenta si
ha fi nalizado el procesami ento. Los resu ltados del procesamien to se dev uelven
mediante otra llamada en otro s ubproceso. Los mét odos asin crónicos liberan e l
llamador de tener que esperar hasta que el procesamiento haya finalizado
Método de extensión
Método estát ico qu e se pu ede in vocar u tilizando la sin taxis de lo s mét odos de
instancia. De hecho , los métodos de ex tensión permi ten extende r ti pos y ti pos
construidos existentes con otros métodos.
Modo clásico
En IIS 7.0, es una configuración en la que el procesamiento de solicitudes emula el
modelo utilizado en IIS 6.0. En el modo clásico, IIS recibe las solicitudes y las envía
a los comp onentes IS API con ar reglo a las extensi ones de nombre de archivo
asignadas. IIS y el proceso que administra la so licitud se e jecutan en procesos
independientes. Por ejemplo, la s solicitudes de recursos de ASP.NET se envían al
componente aspnet_isapi.dll.
Modo de presentación
Distintos estados de presentación que se pueden i ntroducir en una pági na de
elementos Web, que permiten a los usua rios modifica r una página de manera
especificada. Los estados establecidos que se incluyen con el control de elementos
Web son: catálogo, cone xión, di seño, edición y expl oración. El modo
predeterminado o normal para una página Web es explorac ión. Los programadores
pueden extender esta característica del modo de presentación agregando modos de
presentación person alizados, qu e requ ieren la ex tensión de la cl ase
WebPartManager
ASP.Net
175
Modo integrado
En IIS 7.0, configuración en l a que IIS y ASP.NET comparten el proc esamiento de
solicitudes en f unción de u na can alización qu e admi te t anto los compon entes
creados con .NET Framework como los componentes nativos. En el modo integrado,
los compon entes de ASP .NET, como los mó dulos HT TP, se pu eden u tilizar par a
administrar t odas las solicitudes w eb, in cluso aquéllas que no va n destinadas a
recursos de ASP.NET.
Módulo (HTTP)
Componente que se puede registrar como p arte de la duración de la solicitud d e
ASP.NET y que puede leer o cambiar la soli citud o la respuesta c uando se procesa.
Los módu los HT TP se u tilizan con f recuencia para rea lizar t areas e speciales qu e
necesitan supervisar cada solicitud, como estadísticas seguridad o del sitio.
M
Metadatos
Información que describe todos los elementos administrados por Common
Language R untime: u n ensambl ado, el arch ivo cargabl e, el ti po, el método, etc.
Esto pu ede in cluir información n ecesaria par a la depu ración y la recolección de
elementos no utilizados, así como atributos de seguridad, cálculo de referencias de
datos, definiciones ex tendidas de clases y miembros, enlace de versión y otra
información requerida por el motor en tiempo de ejecución.
Método asincrónico
Llamada al método que devuelve inmediatamente al llamador sin tener en cuenta si
ha fi nalizado el procesami ento. Los resu ltados del procesamien to se dev uelven
mediante otra llamada en otro s ubproceso. Los mét odos asin crónicos liberan e l
llamador de tener que esperar hasta que el procesamiento haya finalizado
Método de extensión
Método estát ico qu e se pu ede in vocar u tilizando la sin taxis de lo s mét odos de
instancia. De hecho , los métodos de ex tensión permi ten extende r ti pos y ti pos
construidos existentes con otros métodos.
Modo clásico
En IIS 7.0, es una configuración en la que el procesamiento de solicitudes emula el
modelo utilizado en IIS 6.0. En el modo clásico, IIS recibe las solicitudes y las envía
ASP.Net
176
a los comp onentes IS API con ar reglo a las extensi ones de nombre de archivo
asignadas. IIS y el proceso que administra la so licitud se e jecutan en procesos
independientes. Por ejemplo, la s solicitudes de recursos de ASP.NET se envían al
componente aspnet_isapi.dll.
Modo de presentación
Distintos estados de presentación que se pueden i ntroducir en una pági na de
elementos Web, que permiten a los usua rios modifica r una página de manera
especificada. Los estados establecidos que se incluyen con el control de elementos
Web son: catálogo, cone xión, di seño, edición y expl oración. El modo
predeterminado o normal para una página Web es explorac ión. Los programadores
pueden extender esta característica del modo de presentación agregando modos de
presentación person alizados, qu e requ ieren la ex tensión de la cl ase
WebPartManager
Modo integrado
En IIS 7.0, configuración en l a que IIS y ASP.NET comparten el proc esamiento de
solicitudes en f unción de u na can alización qu e admi te t anto los compon entes
creados con .NET Framework como los componentes nativos. En el modo integrado,
los compon entes de ASP .NET, como los mó dulos HT TP, se pu eden u tilizar par a
administrar t odas las solicitudes w eb, in cluso aquéllas que no va n destinadas a
recursos de ASP.NET.
Módulo (HTTP)
Componente que se puede registrar como p arte de la duración de la solicitud d e
ASP.NET y que puede leer o cambiar la soli citud o la respuesta c uando se procesa.
Los módu los HT TP se u tilizan con f recuencia para rea lizar t areas e speciales qu e
necesitan supervisar cada solicitud, como estadísticas seguridad o del sitio.
N
NET Framework
Componente integral de Windows que ad mite la cr eación, im plementación y
ejecución de la siguiente compilac ión de aplicaciones y servicios we b. Proporciona
un entorno de múl tiples lenguajes basado en estándar es y muy producti vo para
integrar las in versiones ex istentes con aplicacion es y serv icios d e la próx ima
generación, así como la agilidad necesaria para resolver los desafíos que suponen la
implementación y el funcionamiento de las aplicacion es para Internet. .N ET
ASP.Net
177
Framework se compone de tres par tes principales: Common Language Runtime, un
conjunto jerárquico de bibliotecas de clases uni ficadas y una versión de ASP
dividida en componentes que se denomina ASP.NET.
Nivel de comunicación asincrónica
Nivel de f uncionalidad de AJ AX qu e se encarga de la comunicación entre el
explorador y el servidor
P
Página ASP.NET
Componente de una aplicación ASP.NET.
Página de contenido (content Page)
Página Web que se configura para combinar se con una p ágina principal para crear
una página completa.
Paginación
Mecanismo que separa de forma automática el contenido de los formularios Web
Forms para disposit ivos móviles de ASP.NET en grupos más pequeños de página s
representadas destinadas a encajar co n un dispositivo específico. También
representa elementos de la in terfaz de u suario que se pu eden utilizar para bu scar
otras páginas.
Plantilla
Fragmento de página declarativo que se utiliza para proporcionar una interfaz visual
de un control de servidor ASP.NET con plantilla. Una plantilla contiene elementos de
presentación entre los que se incluyen texto literal, HTML y expresiones de enlace a
datos, así como elementos de sintaxis de clarativos que repres entan controles de
servidor ASP.NET. Una plantilla puede pers istir como un archivo de texto co n una
extensión .ascx. Vea también: control de servidor ASP.NET, control con plantilla.
R
Representación parcial de la página
Proceso de actualizar sólo una región de una página web durante una devolución de
datos asincrónica. Esta operació n se realiza normalmente con l os control es
ASP.Net
178
UpdatePanel. La repres entación parcial de página es una característica importante
de la tecnología de AJAX.
s
Scaffolding
Proceso de generación de pl antillas de página web basad as en esquemas de base
de dat os. En ASP.NET, los dat os dinámicos utilizan la t écnica de scaf folding para
facilitar la generación de interfaces de usuario basadas en web que permite a los
usuarios ver y actualizar una base de datos.
Seguimiento
Proceso de capturar y mostrar informació n de depuración sobre una página Web
cuando la página se está ejecutando. La i nformación de seguimiento incluye
encabezados HTTP y el estado de control. Puede mostrar el seguimiento genera do
en la página o en un visor de seguimiento independiente.
Servicio de aplicación
En ASP.NET, es una función integrada para tareas de ap licación comunes. ASP.NET
incluye serv icios de a plicación para la au tenticación ( pertenencia de ASP .NET),
información persistente de cada usuario (propiedades de perfiles), etc.
Servicios de aplicaciones cliente
En las apli caciones basadas en Win dows, es un a funcionalidad in tegrada qu e
permite obt ener acceso a los servicios de a plicaciones ASP .NET para t areas de
aplicación comunes, i ncluida l a confi guración de inicios de sesión remotos,
funciones y aplicaciones.
Servicios Web XML
Unidades de lóg ica de aplicacion es qu e proporcionan datos y servicios a otras
aplicaciones. L as aplica ciones obt ienen acceso a los se rvicios Web XML media nte
protocolos Web estándar y form atos de da tos como HTTP, XML y SOAP, con
independencia de cómo se imp lementa cada serv icio Web XML. Los serv icios Web
XML combinan los me jores aspectos del desarrollo basado en com ponentes y el
Web, por lo que so n una base fundamental del modelo de programación de
Microsoft .NET.
ASP.Net
179
SOAP
Protocolo simple basad o en XML para inte rcambiar información estructurada y de
tipos en el Web. El protocolo no contiene semántica de apl icación ni de transporte,
por lo que resulta muy modular y extensible.
T
Tipo parcial
Un tipo parcial es un tipo que se define de f orma que un ti po único, por ejempl o
una clase, puede dividirse en varios archivos.
V
Visual Studio SDK
Kit de desarrol lo de software qu e los soci os de VSIP u tilizan para ex tender e l
entorno integrado de desarrollo de Visual Studio.
W
WML
Lenguaje de marcado basado en XML que se utiliza para especificar el contenid o y
la interfaz de usuario de dispositivos de banda estrecha , incluidos los teléfonos
celulares y los localizadores (pager). WML es parte de WAP.