Académique Documents
Professionnel Documents
Culture Documents
Microsoft .NET
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
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/en-
us/cpguide/html/cpconwhatiscommonlanguagespecification.asp
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
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
[Serializable]
public class Searcher
{ … }
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:
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
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;
[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.
//------------------------------------------------------------------------------
// <autogenerated>
// 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.
// </autogenerated>
//------------------------------------------------------------------------------
//
// 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
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/en-
us/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/en-
us/cpguide/html/cpconaccessingdatawithadonet.asp.
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.
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