Visual Basic .net

Plataforma Microsoft .NET Juan Francisco Adame Lorite Ingeniería de servicios de Internet (Julio 2003)

Juan Francisco Adame Lorite

Presentación La plataforma .NET de Microsoft es la última apuesta de esta compañía para la integración de servicios y aplicaciones de Internet. Es una plataforma hecha a la semejanza de la plataforma J2EE de Sun (no es un delito admitirlo, ni hace de menos al software de Microsoft). La plataforma de Sun ha sentado una buena base no sólo comercial sino de filosofía moderna de sistema de información, que Microsoft ha reutilizado para adecuar sus productos de desarrollo a un nuevo entorno. Microsoft ha intentado recuperar el tiempo perdido con este software. La plataforma está orientada a Internet y los entornos distribuidos. Por eso hace especial hincapié en la distribución de código en diferentes ubicaciones y a la comunicación de estas partes de código mediante objetos remotos o servicios Web entre otras tecnologías. La naturaleza distribuida de la plataforma obliga a hacer un especial esfuerzo en lo que a seguridad y confianza se refiere. Todo el código y servicios se desarrollan bajo unas características apropiadas de seguridad y confiabilidad. La plataforma se ha orientado mucho a nuevas tecnologías como XML ampliamente aceptadas por una gran parte del sector de las tecnologías de la información. Esto permite que las aplicaciones y servicios desarrollados en la plataforma sean fácilmente integrables con otros servicios y aplicaciones, incluso de otras plataformas. El ámbito de aplicación de la plataforma es muy extenso, desde servicios Web, aplicaciones Windows y aplicaciones Web hasta componentes y bibliotecas de todo tipo.

Estructura de la plataforma La plataforma se compone principalmente de dos partes: „ Common Language Runtime „ .NET Framework Class library El primero es el entorno de ejecución, es el cliente de la plataforma que analiza y ejecuta el código. Es el elemento análogo al JVM de Java (Java Virtual Machina), salvo con la diferencia que el código ejecutado si es binario compilado en este caso. El segundo es el conjunto de bibliotecas de la plataforma integradas en ella que permiten al desarrollador hacer uso de las principales funciones y características de la plataforma. Es el elemento análogo a las JFC de Java (Java Foundation Classes). A diferencia de la plataforma Java no existe un lenguaje definido para el desarrollo. Si bien todo código es traducido a una especie de metacódigo llamado MSIL, similar al Bytecode de Java; éste como en el caso de Java no es apto para el desarrollo. La plataforma sólo exige una serie de tipos, estructuras y formas comunes que todo lenguaje debe implementar y modelar de alguna manera en su sintaxis, que le permita compilar después su código a MSIL. Microsoft distribuye la plataforma con cuatro lenguajes de desarrollo: Visual Basic, Manager C++, C# y J#. Aunque actualmente muchos fabricantes han anunciado la salida al mercado de sus lenguajes de desarrollo para la plataforma .NET, como es el caso de Borland y Delphi. El Common Type System (CTS) define como son declarados, usados y administrados los diferentes tipos en tiempo de ejecución. Esto es muy útil porque define los tipos posibles y su forma lo que facilita la implementación de estos tipos en los diferentes lenguajes de la plataforma .NET. El CTS define los tipos nativos o de valor y los tipos referenciados (tanto a datos, como los delegados y eventos), los tipos miembro (métodos, funciones, constructores, atributos…) y sus

Juan Francisco Adame Lorite

modificadores, así como los delegados y eventos, arrays, interfaces, punteros… Todo lenguaje compatible o integrable en la plataforma debe ser concordante y coherente con estas especificaciones. Un resumen del CTS se puede encontrar en http://msdn.microsoft.com/library/default.asp?url=/library/enus/cpguide/html/cpconthecommontypesystem.asp La siguiente figura muestra el esquema de tipos que define el CTS:

Para permitir interactuar entre los elementos sin importar el lenguaje en que se implementan, estos elementos deben mostrar sólo aquellas características que son comunes a todos los lenguajes. Por este motivo el Common Language Specification (CLS) se define como requisito de interfaz (hacia dentro se puede utilizar el CTS completo) de todos los elementos de la plataforma. Para que dos elementos implementados en lenguajes distintos puedan interactuar entre sí, sus interfaces públicos deben cumplir los requisitos de tipos especificados en el CLS. El CLS es un subconjunto de especificaciones reducidas del CTS. El CLS permite a los desarrolladores de diferentes lenguajes compartir código y componentes. Un resumen del CLS se encuentra en http://msdn.microsoft.com/library/default.asp?url=/library/enus/cpguide/html/cpconwhatiscommonlanguagespecification.asp

Common Language Runtime (CLR) El Common Language Runtime (CLR) es un agente o cliente de la plataforma que gestiona los procesos de ejecución y los servicios de estos procesos. Es análogo al JVM de Java con la salvedad que se ejecuta código binario compilado específico y no código interpretado. La misión del CLR es efectuar la carga de este código, gestionar sus necesidades de memoria y recursos, comprobar el acceso y privilegios disponibles y requeridos para el código, comprobar la robustez y la seguridad de tipos concordantes con el CTS. El código es compilado haciendo referencia y uso del agente CLR, por lo que se denomina managed code (código administrado). El CLR se encarga de la gestión de memoria: reserva y liberación de recursos, referencias nulas, erróneas o zonas de tipo privado; tiempo de vida de los objetos y liberación de recursos automático, control y gestión de la seguridad. El CLR permite también la ejecución de código o partes del código de tipo no administrado (unmanaged code), cuando el código tiene los privilegios de seguridad necesarios para la ejecución de código no administrado (mucho más restrictivos que el código administrado). De esta manera es posible interactuar con antiguas bibliotecas como las del sistema (WIN32) o con tipos COM, que son código no administrado.

Juan Francisco Adame Lorite

La figura muestra el esquema de la estructura de la plataforma. El agente de ejecución (CLR) se ejecuta sobre el sistema operativo y es el único intérprete entre las aplicaciones de código administrado y el sistema operativo. El código administrado hace uso de las clases de la biblioteca .NET Framework y de las propias bibliotecas o externas del desarrollador. El código no administrado hace sin embargo uso directo del sistema operativo, sin pasar por la supervisión del CLR. Existe un segundo CLR que el es que ejecuta los servicios Web y aplicaciones ASP.NET; este agente CLR es específico para funcionar sobre Internet Information Server (IIS) y hace uso de las funcionalidades adicionales y restricciones de este entorno. En este caso el agente no se comunica con el sistema operativo si no que lo hace con éste último mediante el IIS. Puede encontrarse más información sobre el CLR en: http://msdn.microsoft.com/library/default.asp?url=/library/enus/cpguide/html/cpconcommonlanguageruntimeoverview.asp.

.NET Framework Class Library La .NET Framework Class Library es la biblioteca de la plataforma. La Framework ofrece un conjunto de clases, interfaces y tipos reusables con las funcionalidades más básicas y comunes de la plataforma. Contiene los tipos utilizados en el desarrollo de la plataforma. Permiten implementar: „ Aplicaciones de consola. (System.Console) Este espacio de nombres permite utilizar y hacer uso de los flujos de entrada, salida y error básicos de la aplicación. „ Aplicaciones basadas en formularios Windows. (System.Windows.Forms) Este espacio de nombres nos permite hacer uso de la GUI de Windows: ventanas, botones,… „ Aplicaciones Web ASP.NET y servicios Web (System.Web) Este espacio de nombres nos permite implementar aplicaciones Web basadas en formularios ASP y desplegar servicios Web. „ Acceso a fuentes de datos (System.Data) „ Acceso de ficheros y flujos (System.IO) „ …

Juan Francisco Adame Lorite

Además define interfaces de funcionalidades básicas como el IComparable para establecer los operadores de comparación de elementos, el IEnumerable para hacer uso de la colección en un bucle foreach, ICloneable para soportar el clonado de objetos,… y clases base como BaseCollection para implementar colecciones específicas de elementos mediante herencia. Puede encontrarse más información en: http://msdn.microsoft.com/library/default.asp?url=/library/enus/cpref/html/cpref_start.asp.

El proceso de ejecución administrado El proceso de ejecución de un proceso de la plataforma .NET es el siguiente: El compilador del lenguaje específico elegido para el desarrollo compila el código fuente al lenguaje intermedio MSIL. Este código MSIL junto con los recursos de otros tipos necesarios para la ejecución y los metadatos del código son encapsulados en un archivo Portable Executable (PE). El siguiente cuadro muestra un ejemplo de código MSIL: .method public hidebysig instance class System.Object Pop() il managed { // Code size 43 (0x2b) .maxstack 4 .locals ([0] class System.Object V_0, [1] int32 V_1) IL_0000: ldarg.0 IL_0001: ldfld int32 Stack::m_size IL_0006: brtrue.s IL_000e IL_0008: newobj instance void ['mscorlib']System.NullReferenceException::.ctor() IL_000d: throw IL_000e: ldarg.0 IL_000f: ldfld class System.Object[] Stack::m_stack IL_0014: ldarg.0 IL_0015: dup IL_0016: ldfld int32 Stack::m_size IL_001b: ldc.i4.1 IL_001c: sub IL_001d: dup IL_001e: stloc.1 IL_001f: stfld int32 Stack::m_size IL_0024: ldloc.1 IL_0025: ldelem.ref IL_0026: stloc.0 IL_0027: br.s IL_0029 IL_0029: ldloc.0 IL_002a: ret } // end of method 'Stack::Pop'

En el momento en que se solicita la ejecución del fichero PE el compilador Just In Time (JIT) extrae el código MSIL y con ayuda de los metadatos compila a código binario dependiente de la máquina. Ese código binario se almacena en un caché de binarios para futuras ejecuciones. El agente CLR toma ahora el control sobre la ejecución de la aplicación. Primero comprueba que recursos y privilegios requiere la aplicación (de acceso a memoria o disco, de código no administrado, de seguridad y concordancia de tipos,…), estos se obtienen de los metadatos del código. Si el usuario que ejecuta y el código ejecutado tienen los suficientes permisos y privilegios exigidos se procede a la ejecución, si no se produce una excepción y no se ejecuta el código. Durante la ejecución el CLR proporciona y administra los recursos de la aplicación, gestiona el tiempo de vida de sus objetos, comprueba la seguridad y concordancia de los tipos, dispara excepciones,… Existe más información sobre los ficheros PE en: http://www.windowsitlibrary.com/Content/356/11/1.html.

Juan Francisco Adame Lorite

El recolector de basura En los lenguajes orientados a objetos el tiempo de vida de los mismos ya era controlado por el compilador, pero aún así había ocasiones en que esto no era suficiente y parte de la memoria podía quedar desreferenciada y no era liberada. Java resolvió este problema con el recolector de basura (Garbage Collector, GC) y la plataforma .NET hace uso del mismo concepto. El tiempo de vida de toda instancia de una clase (objeto) es el tiempo transcurrido entre la llamada a su constructor y la llamada a su destructor y la liberación de los recursos de los que hacía uso. El momento de creación es controlado en el código por el usuario. Sin embargo, la destrucción del objeto no la lleva a cabo el usuario, el CLR ejecuta cada cierto tiempo un agente llamado recolector de basura que comprueba que elementos no están ya referenciados para liberar los recursos que consumen (principalmente de memoria). La afirmación de que la destrucción de recursos no está controlada por el usuario no es del todo cierta, aquellos recursos que implementen el interfaz IDisposable poseen el método Dispose que libera los recursos que posea la instancia sin necesidad de llamar al recolector (sólo los recursos asociados, la propia instancia es eliminada por el recolector de basura). Los objetos de tipo no nativo o de valor, son llamados objetos referenciados, son instancias de clases. El elemento de código es una referencia al heap del proceso donde se almacena realmente la instancia. Cada cierto tiempo el GC inicia el proceso de recolección de basura, primero comprueba que elementos del heap no están apuntados por ninguna referencia del código o que referencias están fuera ya del ámbito de ejecución actual. Todos esos elementos son eliminados del heap. Si el número de elementos eliminado es muy alto, la memoria se compacta para aprovechar el espacio y se actualizan las referencias en el código. Es por este motivo muy importante hacer uso del operador fixed cuando trabajemos con punteros en código no administrado, para informar al GC que el elemento referenciado apuntado no debe moverse en el proceso de compactación a fin de que el puntero no referencie de forma errónea. Puede verse un ejemplo de programación no administrada donde se comprueba este efecto en: http://www.codeproject.com/csharp/unsafe_prog.asp. También es posible que existan elementos muy grandes en el heap, cuando esto es así la compactación del heap se hace muy lenta y costosa y repercute en el rendimiento de la aplicación. Estos elementos muy grandes son almacenados en un heap especial que no es compactado nunca. Para mejorar la eficiencia del recolector de basura, existen tres niveles en el heap en los que se distribuyen los objetos según su tiempo de vida, de más jóvenes a más antiguos. Cuando no hay espacio en el heap de nivel 0 para almacenar un nuevo elemento, se llama al GC y todos los objetos que sobrevivan al proceso de recolección y/o compactación se pasan al nivel 1. Cuando el nivel 1 se colapse se repite el mismo proceso y se pasarían al nivel 2. El nivel 2 es el de mayor nivel. Esto es muy eficiente porque los elementos tienen tiempos de vida parecidos según el ámbito de código al que pertenecen (por ejemplo todas las variables locales de un método) y de esta manera se eliminan a la vez afectando a un solo nivel del heap. Más información sobre el recolector de basura en: http://msdn.microsoft.com/msdnmag/issues/1100/GCI/default.aspx. http://www.yasd.com/tutorials/c_sharp/chap17_1.htm.

Assemblies Los assemblies (ensamblados) son los bloques básicos de las aplicaciones, ellos son la unidad fundamental de despliegue, control de versiones, reutilización, ámbito y permisos de seguridad. Un assembly es una colección de tipos y de recursos integrados de manera y forma que son la unidad lógica de funcionalidad.

Juan Francisco Adame Lorite

El assembly provee al CLR de la información necesaria en forma de metadatos de los tipos implementados y su interpretación, por lo que un tipo no puede existir fuera del contexto de un assembly. El assembly es el elemento básico de salida del compilador. Es el elemento ejecutado por el CLR. Todo assembly contiene una versión, assemblies con versiones distintas son distintos para el CLR. El origen, el autor y la versión del assembly se pueden garantizar mediante firmado. El assembly es la unidad de seguridad de código básica, los privilegios se le conceden al código en función del origen, autor, versión,… del assembly. El assembly es la entidad de ámbito básica, dos tipos iguales en assemblies distintos son tipos distintos, un tipo no tiene sentido fuera del contexto de un assembly. Un assembly se compone de: „ Por un manifiesto en forma de metadatos del assembly: nombre, versión, cultura, firma,… „ Metadatos del código, donde se definen los tipos de forma concordante con el CTS. „ Código MSIL. „ Un conjunto de recursos, aunque éstos pueden ser separados del assembly en módulos para facilitar la descarga del assembly.

Los assemblies compartidos se despliegan en el Global Assembly Cache (GAC). Estos assemblies deben estar firmados. Dos versiones de un mismo assembly pueden desplegarse en el GAC y la adecuada es escogida por el CLR. Las assemblies declaran con que versiones anteriores son compatibles para poder ser escogidas por el CLR cuando la versión exacta no exista en el GAC. Se puede encontrar más información sobre assemblies en: http://msdn.microsoft.com/library/default.asp?url=/library/enus/cpguide/html/cpconassemblies.asp.

Metadatos Los metadatos son información declarativa que define y especifica el código del assembly. Los metadatos añaden información adicional a la deducible del código, o definen esta información para que evitar que tenga que ser deducida del código (por un elemento o agente que no entienda ese lenguaje, por ejemplo). Los metadatos facilitan la interacción entre diferentes lenguajes. Estos metadatos definen los tipos del assembly para que puedan ser utilizados por otros lenguajes. Así al leer el interfaz de los tipos desde los metadatos el lenguaje no debe saber en que fue realizado pues sólo se limita a lo que los metadatos le indican. Los metadatos definen cada tipo y miembro del código de una manera neutral. Los metadatos almacenan la siguiente información: „ Descripción del assembly: • Identidad (nombre, versión, cultura, llave pública de firmado)

Juan Francisco Adame Lorite

• Los tipos exportados • Otros assemblies de los que este depende y sus versiones • Permisos y privilegios necesarios para ejecutar „ Descripción de tipos: • Nombre, visibilidad, clases base e interfaces implementados • Miembros: atributos, propiedades, campos, eventos, tipos anidados „ Atributos: • Información descriptiva adicional que modifica la definición, interpretación o modelado de tipos y miembros Los metadatos de este último tipo se introducen en el código mediante los atributos: [WebMethod(Description="Put in your search string then press Invoke.")] public DataSet Search(string searchParam) { … } [Serializable] public class Searcher { … }

Seguridad en la plataforma .NET Existen 3 mecanismos de seguridad en la plataforma .NET. Cada uno de ellos es definido en función de unos elementos y es gestionado de distinta manera: „ Identity. Los privilegios se asignan en función de los metadatos de identidad (nombre, versión, cultura, autor, clave pública de firmado,…) del assembly a ejecutar. „ Code Access Security. Dentro de la descripción en metadatos del assembly entre los metadatos descriptivos y los atributos se indican que privilegios y permisos requiere el assembly para ejecutar y cuales, aún teniéndolos, no desea que se le asignen. „ Role-based security. La aplicación corre sobre un sistema en que cada usuario posee unos privilegios y permisos. Estos privilegios y permisos se definen por el administrador. La ejecución final de la aplicación o servicio, y los permisos y privilegios con que ésta corra dependerán de estos tres elementos (de la intersección de ellos). Si un elemento de código necesita un permiso para ejecutar, ese permiso debe de estar asignado tanto a ese elemento como a todos los que le llaman. Es decir los privilegios deben estar otorgados en todos los assemblies que se llaman. Por ejemplo, si el assembly A llama o hace uso del assembly B y este último requiere del permiso P, sólo ejecutará si A también tiene asignado este permiso. Se puede encontrar más información sobre seguridad en la plataforma .NET en: http://msdn.microsoft.com/library/default.asp?url=/library/enus/cpguide/html/cpconnetframeworksecurity.asp.

Identity security Es el mecanismo encargado de otorgar permisos y privilegios en función de los metadatos de identidad del assembly. El ámbito, el conjunto de código y la unidad básica de granulado es el assembly. El equipo tiene asignadas unas políticas de seguridad. En estas políticas se definen que privilegios se asignan a cada assembly en función de algunos o algún metadato de identidad. Por ejemplo, los assemblies cuya zona de origen (lugar donde se ubica el assembly) sea Internet no perteneciente a los sitios seguros de Internet Explorer, no tendrá privilegios para escribir en disco, ver propiedades del sistema,… Estos metadatos de identidad pueden ser el nombre del assembly, la

Juan Francisco Adame Lorite

versión, el autor del assembly (se comprueba por la clave pública de firmado), la zona de ubicación del assembly, la URL de ubicación del assembly,… Puede que un assembly esté afectado por más de una de estas reglas de seguridad, si es así el assembly recibe los permisos de ejecución unión de todos los otorgados por cada regla. Además se definen tres diferentes políticas y una cuarta opcional. Se denominan de empresa, de equipo, de usuario y de dominio de la aplicación. La primera es común para todo el dominio, la segunda es común para todo el equipo, la tercera es propia de cada usuario y la cuarta de cada dominio de aplicación (de cada aplicación, ésta es opcional). Los privilegios resultantes para cada assembly son la intersección de los otorgados por cada política. En el siguiente ejemplo podemos observar que el código con clave pública de firmado dada, cuyo nombre de assembly sea Microsoft.App y que el autor sea Microsoft recibirá por un lado permisos de lectura en el directorio c:\Microsoft y por el otro de escritura en dicho directorio. La aplicación tendrá privilegios de lectura y escritura en el directorio a no ser que alguna de las otras dos políticas (empresa o usuario) no los tenga:

Code access security Los privilegios y permisos de acceso al código se definen específicamente en el código, en los metadatos del propio assembly. Lo que se definen van a ser dos cosas, los privilegios que se exigirán estar otorgados para la ejecución de la aplicación y en segundo lugar los que se denegarán en la ejecución si ya estuviesen otorgados. Por ejemplo, mi aplicación puede requerir para ejecutarse correctamente permisos de escritura en el directorio C:\MyApp, luego no se ejecutará si la seguridad de tipo Identity no le ha otorgado este permiso. De la misma manera mi aplicación no va a hacer uso de otro directorio que no sea ese, luego puedo denegar el acceso de cualquier tipo a cualquier otra parte del disco, y aunque la seguridad de tipo Identity le haya otorgado este permiso la aplicación no lo poseerá y será más segura (frente a bugs que pueda alguien aprovechar de forma maliciosa, por ejemplo). Estos permisos se establecen en los metadatos del assembly en dos puntos: en el código (imperativos), o en los metadatos de descripción del assembly (declarativos). Los permisos declarativos se declaran como atributos en el código también, pero en el assembly los almacenan en los metadatos de descripción del mismo. Hacen referencia a todo el assembly, no a una parte del código. Indican que

Juan Francisco Adame Lorite

permisos son necesarios para ejecutar el assembly (si no, el CLR no lo ejecuta) y cuales se deniegan (aunque la seguridad de tipo Identity los haya otorgado la aplicación no los poseerá). Se comprueban en tiempo de carga antes de ejecutar la aplicación. También es posible solicitar permisos de forma optativa, si no se otorgan se procederá a ejecutar la aplicación en este caso y deberemos comprobar si han sido otorgados de forma imperativa //If it is not granted the application will fail to start [assembly : UIPermissionAttribute (SecurityAction.RequestMinimum)] //If it is not granted the application will still run [assembly : SecurityPermissionAttribute (SecurityAction.RequestOptional ,Flags=SecurityPermissionFlag.UnmanagedCode)] // The entire assembly will be blocked from accessing this drive. [assembly : FileIOPermissionAttribute (SecurityAction.RequestRefuse ,Read=“C:\\”)]

Los permisos imperativos o solicitados de forma imperativa se solicitan en el propio código y se comprueba si se han otorgado mediante el código. Son por lo tanto específicos a una parte del código y al desarrollo particular de la ejecución de la aplicación. Se comprueban en tiempo de ejecución. try { FileIOPermission myPermission = new FileIOPermission (FileIOPermissionAccess.AllAccess,@"c:\\"); myPermission.Demand(); } catch (SecurityException ex) { MessageBox.Show(“Security Exception: “+ex.Message); }

Role-based security Hasta ahora solo hemos comprobado los privilegios de las entidades de código. Pero además de estos permisos y privilegios existe un elemento más que influye en estos: el usuario de la aplicación. Aparecen entonces dos nuevos elementos en la arquitectura el autentificador y el autorizador. El autentificador es el elemento que indica que usuario es el que está accediendo a la aplicación o servicio. En el caso de aplicaciones de formularios Windows es el propio sistema operativo Windows, en el caso de servicios Web y aplicaciones Web es el Internet Information Server. Aunque en ambos se casos se puede buscar una vía alternativa de autentificación propia. El autorizador es el elemento que se encarga de otorgar permisos y privilegios en función del usuario autentificado. La autorización se realiza de forma imperativa en el código haciendo uso de las clases Identity que define la identidad del usuario y Principal que define su pertenencia a grupos. Cada autentificador declara subtipos (el sistema operativo Windows define WindowsPrincipal y WindowsIdentity) de estos que se pueden instanciar en la ejecución del código para saber que usuario está ejecutando ese código y autorizarle o no. WindowsIdentity MyIdentity = WindowsIdentity.GetCurrent(); If (MyIdentity.IsGuest) {…} If (MyIdentity.IsAnonymous) {…} If (MyIdentity.IsSystem) {…} String Str=MyIdentity.AuthenticationType; Str=MyIdentity.Name; WindowsPrincipal MyPrincipal = new WindowsPrincipal(MyIdentity); If (MyPrincipal.IsInRole(“Administradores”)) {…}

Juan Francisco Adame Lorite

Seguridad en ASP.NET

Esta figura muestra el proceso de autentificación y autorización en aplicaciones ASP.NET y servicios Web. Toda petición pasa por un proceso doble de autentificación y autorización, el del Internet Information Server y el del agente CLR de ASP.NET. En los puntos 2 y 3 se autentifica y autoriza al usuario para acceder a un recurso que a continuación se comprueba es una aplicación ASP.NET o servicio Web por lo que se pasa la ejecución de la aplicación al agente CLR de ASP.NET. Este agente provee de nuevos mecanismos de autentificación y autorización específicos, 5 y 6, que son controlados por el propio código de la aplicación o servicio. Finalmente es posible que se intente acceder a un nuevo recurso que requiera autentificación y autorización, punto 7, en ese caso se hace uso de la propia del agente CLR ASP.NET, se utiliza la propia identidad obtenida en 5 o se impersonaliza con una identidad específica. La arquitectura habitual de una aplicación ASP.NET o servicio Web, es la de autentificarse en 2 como usuario anónimo, y que el IIS permita en 3 el acceso anónimo al recurso ASP.NET. En 4 observamos que la identidad que se pasa al agente CLR ASP.NET es la definida como usuario anónimo de IIS (IUSR_MACHINE). Es en 5 donde se realiza la autentificación real por diferentes medios como el servicio Passport de Microsoft, haciendo uso de la de Windows (siempre será el usuario anónimo de acceso por IIS que es la pasada al agente CLR ASP.NET) o mediante formularios Web, en la que el código define la propia identidad y principal del usuario. En 6 el código autoriza a la identidad obtenida del punto 5. Y el acceso a recursos externos, punto 7, se realiza mediante autentificación Windows (usuario anónimo) o impersonalizando la petición a un usuario que sabemos tiene acceso al recurso.

Nuevas aplicaciones y tecnologías Aplicaciones de formularios Windows Conserva la GUI habitual de coger y arrastrar elementos para diseñar el aspecto de los formularios. No hay cambios significativos salvo que el sistema de

Juan Francisco Adame Lorite

mensajes de las aplicaciones MFC y Windows API 32 se sustituye por el concepto de evento y delegado. public class EventIssuer { public delegate void EventDelegate(object from, EventArgs args); public event EventDelegate myEvent; public void issueEvent(EventArgs args) { myEvent(this, args); } } … EventIssuer ei; ei.myEvent += new EventIssuer.EventDelegate(handleEvents); … Public void handleEvents(object sender, System.EventArgs e){ …//Acción a realizar cuando se lance el evento } this.button1.Click += new System.EventHandler(this.button1_Click); … private void button1_Click(object sender, System.EventArgs e) { net.xmethods.www.CurrencyExchangeService Servicio = new net.xmethods.www.CurrencyExchangeService(); float num = (float) Servicio.getRate("euro","us"); label1.Text=num.ToString(); }

Más información en la página: http://msdn.microsoft.com/library/default.asp?url=/library/enus/vbcon/html/vboricreatingstandaloneappsvb.asp.

Servicios Web Es el nuevo tipo de aplicación soportado por la plataforma. Microsoft se ha orientado claramente a esta tecnología con la plataforma .NET y es la principal innovación. Definido bajo los estándares de SOAP para el intercambio de objetos mediante mensajería XML, de WSDL para la definición de interfaces de servicios Web y de UDDI para la publicación de servicios. Al acogerse a estándares no propietarios y adoptados por las otras plataformas (J2EE en especial) esta plataforma se puede integrar con otras mediante esta tecnología. El servicio Web es un subtipo de la clase System.Web.Services.WebService y que indica que métodos exporta mediante el atributo WebMethod. Esto permite crear automáticamente el archivo WSDL, mediante la firma de cada método definido como servicio, y la publicación en el directorio UDDI. namespace MyWebService { using System; using System.Web.Services; public class MyStringReverse: WebService { [WebMethod(Description="Reverse String")] public String ReverseString ( String InString ) { // Check null String if ( InString == null ) return null; Int32 intSize = InString.Length; char[] arrayInString = InString.ToCharArray(); char[] arrayOutString = new char[intSize]; for (Int32 i = 0 ; i < intSize ; ++i) arrayOutString[i] = arrayInString[intSize-i-1]; return new String(arrayOutString); } } }

La aplicación cliente, es decir la que hace uso del servicio Web, hace peticiones a través de una clase proxy. Es una clase que tiene el mismo interfaz

Juan Francisco Adame Lorite

que el servicio Web pero cuya implementación de cada método son las llamadas al servicio Web. Esta clase se genera automáticamente desde el archivo WSDL. //-----------------------------------------------------------------------------// // This code was generated by a tool. // Runtime Version: 1.0.2914.16 // // Changes to this file may cause incorrect behavior and will be lost if // the code is regenerated. // //-----------------------------------------------------------------------------// // This source code was auto-generated by wsdl, Version=1.0.2914.16. // using System.Diagnostics; using System.Xml.Serialization; using System; using System.Web.Services.Protocols; using System.Web.Services; [System.Web.Services.WebServiceBindingAttribute(Name="MyClassSoap", Namespace="http://tempuri.org/")] public class MyClass : System.Web.Services.Protocols.SoapHttpClientProtocol { [System.Diagnostics.DebuggerStepThroughAttribute()] public MyClass() { this.Url = "http://localhost/ASP.NET/MyWebService.asmx"; } [System.Diagnostics.DebuggerStepThroughAttribute()] [System.Web.Services.Protocols.SoapDocumentMethodAttribute("http://tempuri.org/Add ", Use=System.Web.Services.Description.SoapBindingUse.Literal, ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Wrapped)] public int Add(int a, int b) { object[] results = this.Invoke("Add", new object[] { a, b}); return ((int)(results[0])); } [System.Diagnostics.DebuggerStepThroughAttribute()] public System.IAsyncResult BeginAdd(int a, int b, System.AsyncCallback callback, object asyncState) { return this.BeginInvoke("Add", new object[] { a, b}, callback, asyncState); } [System.Diagnostics.DebuggerStepThroughAttribute()] public int EndAdd(System.IAsyncResult asyncResult) { object[] results = this.EndInvoke(asyncResult); return ((int)(results[0])); } }

La aplicación cliente sólo debe instanciar la clase proxy y llamar al método que se precise. De forma síncrona: MyClass mycls = new MyClass(); int x = Int32.Parse(a.Text); int y = Int32.Parse(b.Text); Message.Text = mycls.Add( x, y).ToString() ;

O asíncrona: class TestCallback { public static void Main() { //Create AsyncCallback delegate for the BeginAdd method. AsyncCallback objCallBack = new AsyncCallback(TestCallback.FactorizeCallback1); // Begin the Asynchronous call to the Web Service Calc1 objCalcService = new Calc1();

Juan Francisco Adame Lorite

IAsyncResult objAsyncResult = objCalcService.BeginAdd(5, 5, objCallBack, objCalcService); ... // Other tasks // Keep track how long it takes to complete the async call while (objAsyncResult.IsCompleted == false) { ... // Task when finalized } } // Callback function invoked by the proxy class when the asynchronous operation completes public static void FactorizeCallback1(IAsyncResult objAsyncResult) { // Use the AsyncState property to get the Web Service proxy object Calc1 objCalcService = (Calc1) objAsyncResult.AsyncState; // Get the completed results. int results = objCalcService.EndAdd(objAsyncResult); } }

Se comprueba que la plataforma no sólo está orientada a los servicios Web, sino que además el entorno de desarrollo permite un despliegue muy rápido de estos servicios incrementando la productividad en estas tareas. Más información en la página: http://msdn.microsoft.com/library/default.asp?url=/library/enus/cpguide/html/cpconwebservicesoverview.asp.

Aplicaciones ASP.NET Las aplicaciones Web también han sufrido un gran cambio. Hay muchas diferencias entre el lenguaje de scripting ASP antiguo y el moderno ASP.NET. Las aplicaciones ASP.NET se pueden implementar en cualquier lenguaje de la plataforma .NET y hacer uso de toda la biblioteca .NET FrameWork Class Library. El nivel de presentación se separa del funcional, cada uno se implementa en un archivo distinto. Se puede trabajar diseño y funcionalidad de forma separada. El modelo de interacción de la GUI es idéntico al modelo de eventos y delegados de los formularios Windows, lo que da mucha más flexibilidad y funcionalidad a las aplicaciones Web. El código client-side y server-side se desarrolla en el mismo entorno. El código no es un script interpretado es código binario compilado de la misma manera que se ejecuta el resto de código en la plataforma .NET como se explicó al comienzo del trabajo. Esto da mucha más eficiencia y rapidez a servicios Web y aplicaciones Web. Más información en la página: http://msdn.microsoft.com/library/default.asp?url=/library/enus/cpguide/html/cpconcreatingaspwebapplications.asp.

ADO.NET Es el nuevo interfaz de acceso a fuentes de datos, posee cuatro implementaciones del tipo abstracto de base: „ OLEDB: para ficheros CSV, Excel, Access,… „ ODBC: para bases de datos con conectividad ODBC „ SQL: para SQL Server versión 7 o mayor „ Oracle: para Oracle Database versión 8 o mayor Así mismo, se conserva el escenario clásico conectado y se añade uno nuevo, el escenario no conectado. Más información sobre ADO.NET en: http://msdn.microsoft.com/library/default.asp?url=/library/enus/cpguide/html/cpconaccessingdatawithadonet.asp.

Juan Francisco Adame Lorite

ADO.NET: Escenario conectado Es el escenario clásico de acceso a las fuentes de datos. Primero se establece una conexión, se ejecuta un comando SQL y se leen los datos devueltos con un reader. En este escenario las relaciones entre elementos y las restricciones e integridad se comprueban en la fuente de datos. Cuando se produce un error, éste se propaga hasta la aplicación cliente, siendo este proceso más lento. El interfaz es el interfaz de la fuente de datos, hacemos peticiones en el lenguaje de la fuente de datos. Un cambio de fuente de datos podría provocar un cambio en todas las consultas de la aplicación cliente. Se requiere una conexión continúa con la fuente de datos, situación que no es posible en muchos casos como en los dispositivos portátiles.

El siguiente es un ejemplo de código: public void ReadMyData(string myConnString) { string mySelectQuery = "SELECT OrderID, CustomerID FROM Orders"; SqlConnection myConnection = new SqlConnection(myConnString); SqlCommand myCommand = new SqlCommand(mySelectQuery,myConnection); myConnection.Open(); SqlDataReader myReader; myReader = myCommand.ExecuteReader(); // Always call Read before accessing data. while (myReader.Read()) { Console.WriteLine(myReader.GetInt32(0)+myReader.GetString(1)); } // Always call Close when done reading. myReader.Close(); // Close the connection when done with it. myConnection.Close(); }

ADO.NET: Escenario no conectado El escenario no conectado es apropiado para las situaciones en las que el cliente no está conectado directamente, o las solicitudes son esporádicas y no podemos copar el recurso de la conexión continuamente. La idea de este escenario es modelar en la aplicación parte de la base de datos, trabajar sobre este modelo y actualizar la base de datos con los cambios al finalizar. El objeto que modela la base de datos, sus tablas, sus relaciones entre tablas y restricciones de las columnas es el DataSet. Su estructura se define con un documento XML que define todos estos elementos. El elemento que rellena el DataSet y actualiza los cambios sufridos en él es el DataAdapter. El DataAdapter posee los métodos Select para rellenar el DataSet consultando datos a la fuente de datos y los métodos Update, Insert y Delete para reflejar los cambios sufridos en el DataSet en la fuente de datos. Inicialmente deberemos rellenar el DataSet con las filas y tablas que deseemos, el método Select del DataAdapter elige que filas y tablas se cargan. A continuación podemos trabajar con las filas y tablas del DataSet sin necesidad de que haya conexión con la fuente de datos. El DataSet comprueba que las restricciones de tablas (relaciones) y columnas (constraints) definidas en su esquema se conserven. Cuando finalicemos, las filas creadas estarán marcadas como tales y se actualizarán en la fuente de datos mediante el método Insert, las

Juan Francisco Adame Lorite

modificadas con el método Update y las borradas con el método Delete del DataAdapter. Existe un problema añadido en este escenario no existente en el anterior, durante el tiempo que no hay conexión se producen actualizaciones en la fuente de datos que pueden provocar incoherencias al actualizar el DataSet. Esas incoherencias se detectan y pueden ser subsanadas.

El siguiente es un ejemplo de código: string cString = "user id=sa;password=;initial catalog=northwind;data source=MyComputerName\\NetSDK;Connect Timeout=5"; SqlConnection myConnection = new SqlConnection(cString); // Create a SqlDataAdapter. SqlDataAdapter myAdapter = new SqlDataAdapter(); myAdapter.TableMappings.Add(“TSuppliers", "Suppliers"); myConnection.Open(); SqlCommand myCommand = new SqlCommand("SELECT * FROM TSuppliers",myConnection); myCommand.CommandType = CommandType.Text; myAdapter.SelectCommand = myCommand; ds = new DataSet("Customers"); myAdapter.Fill(ds); // Create a second Adapter and Command. SqlDataAdapter adpProducts = new SqlDataAdapter(); adpProducts.TableMappings.Add(“TProducts", "Products"); SqlCommand cmdProducts = new SqlCommand("SELECT * FROM TProducts", myConnection); adpProducts.SelectCommand = cmdProducts; adpProducts.Fill(ds); myConnection.Close(); // Create a FK relation between both tables System.Data.DataRelation dr; System.Data.DataColumn dc1; System.Data.DataColumn dc2; // Get the parent and child columns of the two tables. dc1 = ds.Tables["Suppliers"].Columns["SupplierID"]; dc2 = ds.Tables["Products"].Columns["SupplierID"]; dr = new System.Data.DataRelation("suppliers2products", dc1, dc2); ds.Relations.Add(dr); // Get supplier from suppliers' table DataView suppliers = new DataView(); suppliers.Table = ds.Tables["Suppliers"]; suppliers.RowFilter = "Name = 'The supplier'"; int ID = suppliers[0]["SupplierID"]; // Create a new row in products' table DataRow fila = ds.Tables["Products"].NewRow(); fila["SupplierID"]=ID; ... fila["Name"]=@"products' name"; ds.Tables["Products"].Rows.Add(fila); // Update Changes DataSet changes = ds.GetChanges(); myAdapter.Update(changes); adpProducts.Update(changes); // Check conflicts and errors if (ds.HasErrors){ DataRow[] errores = ds.Tables["Products"].GetErrors(); ... // Fixing conflicts } else ds.AcceptChanges();

Referencias „ „

Programming C#, 3ª edición; Jessy Liberty; O’Reily C# in a Nutshell, marzo 2002; Peter Drayton, Ben Albahari & Ted Neward; O’Reily

Juan Francisco Adame Lorite

„ „

„

„

„

„

.NET Framework Essentials; junio 2001, Thuan Thai & Hoang Lam, O’Reily Plataforma .NET • http://msdn.microsoft.com/library/default.asp?url=/library/en -us/cpguide/html/cpconinsidenetframework.asp C# • http://www.codeproject.com • http://msdn.microsoft.com/library/default.asp?url=/library/en -us/csref/html/vcoriCSharpTutorials.asp ASP.NET • http://www.asp.net • http://www.4guysfromrolla.com/ • http://411asp.net/ Servidores gratuitos ASP.NET, para probar: • http://europe.webmatrixhosting.net/ • http://dotnetplayground.com/ Y las específicas de cada capítulo

Juan Francisco Adame Lorite