Manual Asp .net

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


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


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 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”.



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.


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.


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, _


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, _


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:



<asp:textbox id="TextBox1" runat="Server" text="">

</asp:textbox>



<asp:textbox id="Textbox2" runat="Server" Text="" />



<asp:DropDownList id="DropDown1" runat="server">

<asp:ListItem Value="0">0</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, _


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.


<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.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.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.


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).


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


<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


<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.


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





<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.





<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


autenticación.

/proxypassword: contraseña

O bien

/pp: contraseña

Especifica la contrase ña que se usa para


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:


<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


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


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


Quita una cl ase de ex tensión SOAP especi ficada

del ámbito del archivo de configuración.

<remove> para


Types>


clase especificada de im portador de extensión

SOAP.

<remove> para


Types>


clase especificada de reflector de extensión SOAP.


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.


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).


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


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


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"/>


nivel de confianza High.

<trustLevel name="Medium"

policyFile="web_mediumtrus

t.config"/>


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"/>


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


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


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.


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


La página puede contener varios elementos form


Dispose()


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.

Date post:	06-Dec-2015
Category:	Documents
Upload:	sergio-ramirez-estrada
View:	99 times
Download:	4 times

Manual Asp .net

Documents