En esta serie de articulos veremos los cambios mas importantes que se han aplicado dentro de este lenguaje.
TIPOS DE DATOS "VARIANT"
En Visual Basic 6.0, Variant es un tipo especial de datos "universal" que puede contener cualquier clase de datos excepto cadenas de longitud fija. La variable Object se utiliza como señalador a un objeto. Variant es el tipo de datos predeterminado.
En Visual Basic .NET, el tiempo de ejecución en lenguaje común (CLR) utiliza la variable Object para el tipo de datos universal. Visual Basic.NET podría haber seguido utilizando Variant como este tipo de datos, pero se decidió adoptar la convención de nomenclatura de CLR para evitar confusiones en el desarrollo entre distintos lenguajes. El sistema de tipos se simplifica al disponer de un único tipo de datos universal. El tipo de datos predeterminado es Object.
VB 6
Dim x As Variant
VB .NET
Dim x as Object
VARIABLES "INTEGER" Y "LONG"
En Visual Basic 6, las variables Long se almacenan como números de 32 bits con signo y las variables Integer como números de 16 bits.
En Visual Basic .NET, las variables Long se almacenan como números de 64 bits con signo, las variables Integer como números de 32 bits y las variables Short como números de 16 bits.
VB 6
Dim x as Integer
Dim y as Long
VB .NET
Dim x as Short
Dim y as Integer
TIPO DE DATOS "CURRENCY"
En Visual Basic 6, las variables Currency se almacenan como números de 64 bits en un formato de enteros, con una escala de 10.000 para ofrecer un número de punto fijo con 15 dígitos a la izquierda del punto decimal y 4 dígitos a la derecha. Esta representación ofrece un intervalo de -922,337,203,685,477.5808 a 922,337,203,685,477.5807
En Visual Basic .NET, el tipo de datos Currency no proporciona suficiente precisión para evitar errores de redondeo, por lo que Decimal se creó como su propio tipo de datos.
VB 6
Dim x as Currency
VB .NET
Dim x as Decimal
VARIABLE "DATE"
En Visual Basic 6, la variable Date se almacena internamente en un formato Double y se puede manipular asimismo como Double.Las variables Date se almacenan como números de puntos flotantes IEEE de 64 bits que representan fechas que abarcan desde el 1 de enero de 100 al 31 de diciembre de 9999 y horas desde las 0:00:00 hasta las 23:59:59. Cualquier valor de datos literal reconocible se puede asignar a las variables Date.Cuando otros tipos numéricos se convierten a Date, los valores que se muestran a la izquierda del decimal representan información sobre la fecha, mientras que los valores que aparecen a la derecha representan la hora. Medianoche es 0 y mediodía 0.5. Los números enteros negativos representan fechas anteriores al 30 de diciembre de 1899.
En Visual Basic .NET, las variables Date se almacenan internamente como enteros de 64 bits, de modo que no se pueden manipular directamente como Double. .NET Framework proporciona las funciones ToOADate y FromOADate para la conversión entre Double y Date. La representación de fechas como enteros simplifica y agiliza la manipulación de fechas.
VB 6
Dim dbl As Double
Dim dat As Date
Dbl = dat
VB .NET
Dim dbl As Double
Dim dat As Date
Dbl = dat.ToOADate
Lo dejamos aca...continuamos la proxima semana...Saludos.
En esta serie de articulos, veremos en profundidad la serializacion de objetos en ambientes .NET
Serialización selectiva
Normalmente una clase contiene campos que no deberían serializarse. Por ejemplo, imagine que una clase almacena un Id. de subproceso en una variable miembro. Al deserializar la clase, puede que no se ejecute el subproceso almacenado para el Id. cuando la clase se serializó; por consiguiente, no tiene sentido serializar este valor. Para evitar que las variables miembro se serialicen, deben marcarse con el atributo NonSerialized:
[Serializable]
public class MyObject
{
public int n1;
[NonSerialized] public int n2;
public String str;
}
Serialización personalizada
Se puede personalizar el proceso de serialización implementando la interfaz ISerializable en un objeto. Esto resulta especialmente útil en los casos en los que el valor de una variable miembro no es válido tras la deserialización, pero es necesario proporcionar la variable con un valor con el fin de reconstruir el estado completo del objeto. La implementación de ISerializable supone implementar el método GetObjectData y un constructor especial que será utilizado al deserializar el objeto. En el siguiente ejemplo de código se muestra cómo implementar ISerializable en la clase MyObject desde una sección anterior.
[Serializable]
public class MyObject : ISerializable
{
public int n1;
public int n2;
public String str;
public virtual void GetObjectData(SerializationInfo info,
StreamingContext context)
{
info.AddValue("i", n1);
info.AddValue("j", n2);
info.AddValue("k", str);
}
}
Al llamar a GetObjectData durante la serialización, deberá llenar el objeto SerializationInfo proporcionado con la llamada al método. Para ello, simplemente agregue las variables que se van a serializar como pares de nombres/valores. Se puede utilizar como nombre cualquier texto. Ahora tiene la libertad de decidir qué variables miembro se agregan a SerializationInfo, siempre que se serialicen datos suficientes para recuperar el objeto durante la deserialización. Las clases derivadas deben llamar al método GetObjectData en el objeto base si éste implementa ISerializable.
Es importante hacer hincapié en la necesidad de implementar ambos GetObjectData, así como el constructor especial cuando se agrega ISerializable a una clase. El compilador le advertirá si falta GetObjectData, pero dado que es imposible forzar la implementación de un constructor, no recibirá advertencias si el constructor está ausente y se enviará una excepción cuando intente deserializar la clase sin el constructor. El diseño actual se vió favorecido antes del método SetObjectData para solucionar posibles problemas de seguridad y control de versiones. Por ejemplo, un método SetObjectData debe ser público si está definido como parte de una interfaz, por tanto los usuarios deben escribir código para evitar que el método SetObjectData sea llamado varias veces. Es fácil imaginar los problemas que puede ocasionar una aplicación dañina que llama al método SetObjectData en un objeto en proceso de ejecutar una operación.
Durante la deserialización, se pasa el objeto SerializationInfo a una clase mediante el constructor proporcionado para dicho fin. Al deserializar el objeto, se ignoran todas las restricciones de visibilidad en el constructor, de forma que se puede marcar la clase como pública, protegida, interna o privada. Se recomienda proteger al constructor a no ser que la clase esté sellada, en cuyo caso éste deberá marcarse como privado. Para restaurar el estado del objeto, sólo hay que recuperar los valores de las variables de SerializationInfo con los nombres utilizados durante la serialización. Si la clase base implementa ISerializable, debe llamarse al constructor base para permitir que el objeto base restaure sus variables.
Al derivar una clase nueva de una que implementa ISerializable, la clase derivada debe implementar tanto el constructor como el método GetObjectData si tiene variables que necesitan serializarse. El miniprograma de código siguiente muestra cómo realizar este procedimiento utilizando la clase MyObject, mostrada previamente.
[Serializable]
public class ObjectTwo : MyObject
{
public int num;
public override void GetObjectData(SerializationInfo si,
StreamingContext context)
{
base.GetObjectData(si,context);
si.AddValue("num", num);
}
}
No olvide llamar a la clase base en el constructor de deserialización. De lo contrario, el constructor de la clase base no será llamado nunca y el objeto no se construirá totalmente tras la deserialización.
Los objetos se reconstruyen desde el interior. Durante la serialización, los métodos de llamada pueden ocasionar efectos secundarios no deseados, ya que es probable que éstos hayan llamado a referencias de objetos que no han sido deserializados antes de la llamada. Si la clase que se está deserializando implementa IDeserializationCallback, el método OnSerialization será llamado automáticamente cuando la totalidad del gráfico del objeto se deserialice. En este punto, se han restaurado todos los objetos secundarios mencionados. Una tabla hash es un ejemplo típico de una clase difícil de deserializar sin utilizar la escucha de evento descrito anteriormente. Resulta fácil recuperar los pares clave/valor durante la deserialización. Sin embargo, la agregación de estos objetos en la tabla hash puede ocasionar problemas, dado que no existe garantía de que las clases derivadas de la tabla se hayan deserializado. Por tanto, no es recomendable utilizar los métodos de llamada en una tabla hash.
Pasos en el proceso de serialización
Cuando se llama al método Serialize en un formateador, la serialización del objeto funciona según las siguientes reglas:
Se realiza una comprobación para determinar si el formateador tiene un selector suplente. Si es así, compruebe que éste controla objetos del tipo especificado. Si éste es el caso, se llama a ISerializable.GetObjectData en el selector suplente.
Si no existe un selector suplente o no controla el tipo especificado, se realizará una comprobación para determinar si el objeto está marcado con el atributo Serializable. En caso contrario, se utilizará SerializationException.
Si está marcado correctamente, compruebe si el objeto implementa ISerializable. Si es así, se llamará a GetObjectData en el objeto.
Si no implementa ISerializable, se utilizará la norma de serialización predeterminada, que consiste en serializar todos los campos no marcados como NonSerialized. Control de versiones
.NET Framework admite el control de versiones y la ejecución página tras página. Todas las clases funcionarán en las distintas versiones si no se cambian las interfaces. Dado que las serializaciones tratan con variables miembro y no interfaces, preste atención al agregar o eliminar variables miembro en clases que se serializarán en las distintas versiones. Éste es el caso para clases que no implementan ISerializable. Cualquier cambio de estado en la versión actual, como la agregación de variables miembro, el cambio del tipo de variables o de sus nombres, significará que los objetos existentes del mismo tipo no podrán deserializarse correctamente si se serializaron en una versión anterior.
Si el estado de un objeto requiere cambiar versiones, los autores de clase tienen dos posibilidades:
Implementar ISerializable, lo que permite tomar un control preciso de los procesos de serialización y deserialización. Como resultado, se podrá agregar e interpretar correctamente el estado futuro durante la deserialización.
Marcar las variables miembro no esenciales con el atributo NonSerialized. Esta opción sólo debe utilizarse cuando se esperen cambios mínimos entre las diferentes versiones de una clase. Por ejemplo, al agregar una nueva variable a una versión posterior de una clase, la variable no puede marcarse como NonSerialized con el fin de asegurar que se mantenga compatible con las versiones anteriores. Instrucciones de serialización
Utilice la serialización al diseñar nuevas clases, dado que una clase no puede serializarse tras compilarse. Algunas preguntas importantes: ¿debo enviar esta clase a los dominios de la aplicación?, ¿se utilizará esta clase con servicio remoto en algún momento?, ¿qué harán los usuarios con esta clase? Quizás deriven una nueva clase de la mía que necesita serializarse. Cuando tenga dudas, marque la clase como serializable. Es aconsejable marcar todas las clases como serializables a no ser que:
No se extiendan por ningún dominio de la aplicación. Si la serialización no es necesaria y la clase debe cruzar por un dominio de aplicación, derive la clase de MarshalByRefObject.
La clase almacena punteros especiales que sólo se aplican a la instancia actual de la clase. Si una clase contiene memoria no administrada o identificadores de archivos, por ejemplo, asegúrese de que estos campos estén marcados como NonSerialized o no deserialice la clase en ningún caso.
Algunos de los miembros de datos contienen información sensible. En este caso, será recomendable implementar ISerializable y serializar sólo los campos requeridos.
Definición de XML Web Services
Los servicios XML Web Services son los elementos fundamentales en la evolución hacia la computación distribuida a través de Internet. Se están convirtiendo en la plataforma de integración de aplicaciones gracias a los estándares abiertos y al énfasis en la comunicación y colaboración entre personas y aplicaciones. Las aplicaciones se crean utilizando los servicios XML Web Services múltiples de origen distinto que funcionan conjuntamente, sin importar su ubicación o la forma en que se implementaron.
Existen tantas definiciones de los servicios XML Web Services como empresas que los diseñan. Sin embargo la idea general es:
Los servicios XML Web Services ofrecen funciones muy útiles a usuarios del medio Web ya que emplean un protocolo Web estándar que, en casi todos los casos, es SOAP.
Los servicios XML Web Services permiten describir sus interfaces con suficiente detalle para que el usuario diseñe una aplicación cliente que permita comunicarse con ellas. Esta descripción se proporciona normalmente en un documento XML denominado WSDL (lenguaje de descripción de servicios Web).
Los servicios XML Web Services se registran para que los futuros usuarios los encuentren fácilmente. Este registro se realiza a través de UDDI (descripción, descubrimiento e integración universales).
En este artículo comentaré estas tres tecnologías pero primero quiero explicar por qué son tan importantes los servicios XML Web Services.
Una de las principales ventajas de la arquitectura de los servicios XML Web Services es que permite que los programas escritos en lenguajes y plataformas diferentes puedan establecer comunicación entre sí de forma estándar. Seguro que los programadores que trabajan en esta industria desde hace tiempo se preguntarán:¿No era esto lo mismo que nos prometieron con CORBA y, anteriormente, con DCE? ¿Cómo es posible que los servicios XML Web Services sean diferentes?" La primera ventaja de los servicios XML Web Services es que SOAP es bastante menos complejo que sus antecesores, de modo que resulta más fácil que una implementación cumpla con los estándares de SOAP. Paul Kulchenko publica una lista de implementaciones SOAP en: http://www.soapware.org/directory/4/implementations (en inglés) que contiene al menos 79 entradas. Las grandes empresas de software diseñan implementaciones SOAP pero también existen otras muchas construidas y mantenidas por un único programador. Otra ventaja importante es que los servicios XML Web Services funcionan con protocolos Web estándar, como XML, HTTP y TCP/IP. Muchas empresas disponen ya de una infraestructura Web, así como de personal y conocimientos para mantenerla, de modo que el coste de entrada a estos servicios es mucho menor que con las tecnologías antecesoras.
He definido antes un servicio XML como un servicio de software que se muestra en Web a través de SOAP, se describe con un archivo WSDL y se registra en UDDI. La siguiente pregunta lógica es: "¿Qué se puede hacer con los servicios XML Web Services?" Los primeros servicios solían ser fuentes de información que podían incorporarse fácilmente en aplicaciones para cotizaciones bursátiles, previsión del tiempo, resultados deportivos, etc. Resulta fácil imaginar el tipo de aplicaciones que podían crearse para analizar e incluir información importante y presentarla en modos diferentes. Por ejemplo, en una hoja de cálculo de Microsoft® Excel en la que se resumiría la siguiente información: acciones, plan de pensiones, cuentas bancarias, préstamos, etc. Si esta información estuviera disponible a través de servicios XML Web Services, Excel podría actualizarla continuamente. Parte de dicha información sería gratuita y otra necesitaría que el usuario se subscribiera al servicio. La mayor parte de esta información está disponible ahora en Internet. Sin embargo, los servicios XML Web Services posibilitan que sea más fácil y fiable tener acceso a ella.
La exposición de aplicaciones existentes como servicios XML Web Services permitirá que los usuarios creen aplicaciones más potentes que utilicen estos servicios XML Web como elementos constituyentes. Por ejemplo, un usuario puede desarrollar una aplicación de compra para obtener automáticamente de varios fabricantes información sobre precios, permitir seleccionar un fabricante, enviar el pedido de compra y realizar un seguimiento hasta el momento de recibir el envío. Es posible que la aplicación del fabricante, además de exponer sus servicios en Web, utilice los servicios XML Web Services para comprobar el crédito del cliente, cargar el importe del envío en su cuenta y enviar el pedido a través de una empresa de transportes.
En el futuro, algunos de los servicios XML Web Services más interesantes admitirán aplicaciones que utilicen el medio Web para realizar tareas que no pueden realizarse actualmente. Por ejemplo, uno de los servicios que el proyecto Microsoft .NET My Services admitirá es un servicio de calendario. Así, si su dentista y mecánico expusieran sus calendarios mediante este servicio XML Web, usted podría concertar citas en línea desde su calendario para una limpieza dental y mantenimiento rutinario. Y es fácil imaginar los cientos de aplicaciones que podrían diseñarse cuando se tiene el conocimiento para programar el medio Web.
Para obtener más información sobre los servicios XML Web Services y las aplicaciones que le ayudan a crearlos, consulte la página principal de los servicios Web en MSDN.
SOAP
SOAP es el protocolo de comunicaciones para los servicios XML Web Services. Cuando se describe SOAP como un protocolo de comunicaciones, muchas personas piensan en DCOM o CORBA y se preguntan "¿Cómo realiza SOAP la activación de objetos?" o "¿Qué servicio de nombres utiliza SOAP?" Mientras es posible que una implementación SOAP incluya estos datos, el estándar SOAP no los especifica. SOAP define el formato XML para mensajes. Si tiene un fragmento creado correctamente en XML e incluido en un par de elementos SOAP, dispondrá ya de un mensaje SOAP. Sencillo, ¿verdad?
Existen otras partes en la especificación SOAP que describen cómo representar los datos de un programa como XML y cómo utilizar SOAP para realizar llamadas a procedimiento remoto (RPC). Estas partes opcionales de la especificación se utilizan para implementar aplicaciones estilo RPC en las que el cliente envía un mensaje SOAP que contiene una función a la que se puede llamar, además de los parámetros para pasar a la función. El servidor, por su parte, devuelve un mensaje con los resultados de la función ejecutada. Casi todas las implementaciones actuales de SOAP admiten aplicaciones RPC porque los programadores que trabajan con aplicaciones COM o CORBA conocen el estilo RPC. SOAP admite también aplicaciones con estilo de documento en las que los mensajes SOAP cubren un documento XML. Las aplicaciones SOAP con estilo de documento son muy flexibles. Muchos nuevos servicios XML Web Services aprovechan esta flexibilidad para diseñar servicios que sería difícil implementar mediante RPC.
La última parte opcional de la especificación SOAP define los contenidos de un mensaje HTTP que contiene un mensaje SOAP. Este enlace HTTP es importante porque casi todos los sistemas operativos actuales, y otros no tan actuales, admiten HTTP. Este enlace es opcional pero casi todas las implementaciones SOAP lo admiten porque es el único protocolo estandarizado para SOAP. Por esta razón, existe la falsa idea general de que SOAP necesita HTTP. Algunas implementaciones admiten MSMQ, series MQ, SMTP o TCP/IP. Sin embargo, la mayoría de los servicios XML Web Services utilizan HTTP porque es ubicuo. Dado que HTTP es un protocolo imprescindible para el medio Web, muchas empresas disponen de infraestructuras de redes que lo admiten y personal con conocimientos y experiencia para gestionarlo. En la actualidad ya se encuentran disponibles la seguridad, el control y la infraestructura de equilibrio de cargas para HTTP.
A la hora de empezar a trabajar con SOAP, es importante entender la diferencia entre la especificación SOAP y la variedad de implementaciones de esta especificación. Muchos programadores que utilizan SOAP no escriben mensajes SOAP directamente, sino que utilizan un SOAP Toolkit para crear y analizar mensajes SOAP. Generalmente, estos kits de herramientas traducen llamadas de función de algún tipo de lenguaje a un mensaje SOAP. Por ejemplo, Microsoft SOAP Toolkit 2.0 traduce llamadas de función COM a SOAP y el kit de herramientas de Apache traduce funciones de llamadas JAVA a SOAP. Los tipos de llamadas de función y los tipos de datos de los parámetros admitidos varían en cada implementación SOAP, de forma que es posible que una función que trabaja con un kit de herramientas no funcione con otro. Esto no es una limitación de SOAP, sino de la implementación específica que utilice en cada caso.
La característica más notable de SOAP es que se ha implementado en diferentes plataformas de hardware y software, lo que significa que puede utilizarse para enlazar sistemas dispares dentro y fuera de su empresa. En el pasado se realizaron muchos intentos para conseguir un protocolo de comunicaciones común que pudiera usarse en la integración de sistemas. Sin embargo, ningún intento se ha generalizado tanto como SOAP. ¿Por qué? Porque SOAP es más pequeño y sencillo de implementar que muchos de los protocolos anteriores. Por ejemplo, se tardaron años en implementar DCE y CORBA, de modo que sólo unas pocas implementaciones llegaron a comercializarse. Por su parte, SOAP utiliza analizadores XML y bibliotecas HTTP existentes para realizar la mayor parte del trabajo más complicado; por ello, una implementación SOAP puede estar terminada en cuestión de meses. Ésta es la razón por la que hay disponibles más de 70 implementaciones SOAP. No obstante, SOAP no consigue los mismos resultados que DCE o CORBA pero su sencillez y características posibilitan que esté disponible rápidamente.
La ubicuidad de HTTP y la sencillez de SOAP los convierte en una base perfecta para implementar servicios XML Web Services que pueden llamarse desde prácticamente cualquier entorno. Para obtener más información sobre SOAP, consulte la página principal de SOAP en MSDN.
Aspectos sobre la seguridad
Una de las primeras preguntas que se cuestiona un usuario nuevo es cómo protege SOAP la seguridad. En los primeros momentos de su desarrollo, SOAP era considerado como un protocolo basado en HTTP y, por tanto, se asumía que la seguridad de HTTP sería adecuada para SOAP. Además, existen miles de aplicaciones Web que se ejecutan actualmente utilizando la seguridad de HTTP. Por esta razón, el estándar SOAP actual supone que la seguridad es un problema de transporte y no comenta nada sobre los problemas de seguridad.
La seguridad empezó a ser un problema en el momento en que SOAP se convirtió en un protocolo más generalizado que se ejecutaba en múltiples medios de transporte. Por ejemplo, HTTP proporciona diferentes modos de autenticar qué usuario realiza una llamada SOAP. Pero, ¿cómo se propaga esa identidad al dirigirse el mensaje desde HTTP a un transporte SMTP? SOAP se diseñó como un protocolo de base; afortunadamente existen especificaciones en los textos para diseñar en SOAP que proporcionan más características de seguridad para servicios Web. El artículo sobre la especificación WS-Security define sistemas de cifrado completos y el artículo WS-License define técnicas que protegen la identidad de la persona que llama y aseguran que sólo usuarios autorizados puedan utilizar un servicio Web.
WSDL
WSDL es el acrónimo de Web Services Description Language (lenguaje de descripción de servicios Web). Para nuestros objetivos, se puede definir un archivo WSDL como un documento XML que describe un conjunto de mensajes SOAP y la forma en la que éstos se intercambian. En otras palabras, WSDL es a SOAP lo que IDL es a CORBA o a COM. WSDL es XML (es decir, se puede leer y modificar en gran parte de los casos) y es generado y utilizado por software.
Para comprobar el valor WSDL, imagine que desea llamar a un método SOAP que le proporciona uno de sus socios comerciales. Podría solicitarle algunos ejemplos de mensajes SOAP y escribir su propia aplicación para crear y utilizar mensajes que se mostraran de forma similar a los ejemplos. Esto, sin embargo, puede dar lugar a errores. Por ejemplo, si ve el Id. 2837 de un cliente, supondrá que es un número entero en lugar de una cadena. WSDL especifica qué debe contener un mensaje de solicitud y cómo se verá el mensaje de respuesta en una notación clara.
La notación que utiliza un archivo WSDL para describir formatos de mensaje se basa en el estándar XML. Esto significa que es un idioma de programación neutral y basado en estándares, lo cual es perfecto para describir interfaces de servicios XML Web Services que pueden abrirse desde una gran variedad de plataformas y lenguajes de programación. Además de describir el contenido de un mensaje, WSDL define el lugar en el que está disponible el servicio y qué protocolo de comunicaciones se utiliza para hablar al servicio. Esto significa que el archivo WSDL define todos los elementos necesarios para escribir un programa que pueda funcionar con un servicio XML Web. Existen varias herramientas disponibles para leer un archivo WSDL y generar el código necesario para establecer comunicación con un servicio XML Web. Algunas de las herramientas más útiles se encuentran en Microsoft Visual Studio® .NET.
Muchos de los actuales SOAP Toolkits incluyen herramientas para generar archivos WSDL desde interfaces de programas existentes. Sin embargo, hay pocas herramientas para escribir WSDL directamente y la compatibilidad para WSDL no es tan general como debería ser. No debería pasar mucho tiempo para que las herramientas que facilitan la creación de archivos WSDL, y posteriormente generan proxies y etiquetas como las herramientas COM IDL, formen parte de muchas implementaciones SOAP. En esa etapa, WSDL será el medio preferido para crear interfaces SOAP para los servicios XML Web Services.
Puede consultar una descripción excelente de WSDL y encontrar la especificación de WSDL en http://www.w3.org/TR/wsdl.
UDDI
UDDI (descripción, descubrimiento e integración universales) constituye las páginas amarillas de los servicios Web. Como en las páginas amarillas en papel, es fácil buscar una empresa que ofrece los servicios que necesita, leer acerca del servicio ofrecido y ponerse en contacto con una persona para solicitar más información. Por supuesto, puede ofrecer un servicio Web sin tener que registrarlo en UDDI, al igual que si, por ejemplo, abriera un negocio en el sótano de su casa y confiara en la publicidad del "boca a boca". Si quisiera ampliar sus expectativas en el mercado, necesitaría UDDI para que sus clientes lo encontraran.
Una entrada en un listín UDDI es un archivo XML que describe un negocio y los servicios que ofrece. Cada entrada tiene tres partes. Las "páginas blancas" describen los datos de la empresa, como nombre, dirección, información de contacto, etc. Las "páginas amarillas" incluyen las categorías industriales basadas en taxonomías estándares, como la NAICS (North American Industry Classification System) y la SIC (Standard Industrial Classification). Las "páginas verdes" describen la interfaz del servicio con información suficiente para que alguien escriba una aplicación para usar un servicio Web. Los servicios se definen por un documento UDDI denominado Type Model o tModel. En muchos casos, tModel contiene un archivo WSDL que describe una interfaz SOAP a un servicio XML Web; tModel es suficientemente flexible para describir prácticamente cualquier tipo de servicio.
El listín UDDI incluye también diferentes formas de búsqueda de servicios para que puede diseñar sus propias aplicaciones. Por ejemplo, puede buscar proveedores de un servicio en una ubicación concreta o negocios de un tipo determinado. El listín UDDI le proporcionará la información, personas de contacto, enlaces y datos técnicos para que evalúe los servicios que satisfacen sus necesidades.
UDDI permite buscar negocios de los que desee obtener servicios Web. Si conoce con quién quiere realizar negocios pero desconoce los servicios que ofrece el artículo WS-Inspection permite examinar una recopilación de los servicios XML Web Services ofrecidos en un servidor determinado para buscar los que satisfagan sus necesidades.
Si desea ver más información sobre UDDI, consulte http://www.uddi.org/about.html (en inglés).
Conclusión
Hemos comentado cómo hablar con los servicios XML Web Services (SOAP), cómo se describen estos servicios (WSDL) y cómo encontrarlos (UDDI). Éstas son las especificaciones básicas que proporcionan los pilares para la integración y agregación de una aplicación. A partir de aquí, las empresas construyen soluciones y obtienen resultados reales.
Si bien se han realizado muchos progresos para convertir los servicios XML Web Services en una realidad, queda mucho por hacer. Actualmente, las personas obtienen resultados satisfactorios de estos servicios pero quedan aspectos pendientes como la seguridad, la administración operativa, las transacciones, el intercambio seguro de mensajes, etc. La arquitectura global de los servicios XML Web Services ayudará a que estos servicios avancen al siguiente nivel proporcionándoles un modelo coherente y general para agregar nuevas capacidades avanzadas a estos servicios para que sean modulares y ampliables.
Los módulos para seguridad (WS-Security y WS-License) mencionados anteriormente forman parte de las especificaciones en la arquitectura global de servicios Web. Las necesidades de la administración operativa, como el enrutamiento de mensajes entre varios servidores y la configuración dinámica de éstos para procesar, forman también parte de la arquitectura global de los servicios Web, y los cumple WS-Routing y WS-Referral. A medida que crezca la arquitectura global de los servicios Web, se irán introduciendo especificaciones para éstas y otras necesidades.
Hoy definiremos un aspecto de vital importancia para el funcionamiento del .NET. El SOAP (Simple Object Access Protocol) es un protocolo estándar creado por Microsoft, IBM y otros, está actualmente bajo el auspicio de la W3C que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML.
SOAP es el protocolo de comunicaciones para los servicios XML Web Services. Cuando se describe SOAP como un protocolo de comunicaciones, muchas personas piensan en DCOM o CORBA y se preguntan "¿Cómo realiza SOAP la activación de objetos?" o "¿Qué servicio de nombres utiliza SOAP?" Mientras es posible que una implementación SOAP incluya estos datos, el estándar SOAP no los especifica. SOAP define el formato XML para mensajes. Si tiene un fragmento creado correctamente en XML e incluido en un par de elementos SOAP, dispondrá ya de un mensaje SOAP. Sencillo, ¿verdad? Existen otras partes en la especificación SOAP que describen cómo representar los datos de un programa como XML y cómo utilizar SOAP para realizar llamadas a procedimiento remoto (RPC). Estas partes opcionales de la especificación se utilizan para implementar aplicaciones estilo RPC en las que el cliente envía un mensaje SOAP que contiene una función a la que se puede llamar, además de los parámetros para pasar a la función. El servidor, por su parte, devuelve un mensaje con los resultados de la función ejecutada. Casi todas las implementaciones actuales de SOAP admiten aplicaciones RPC porque los programadores que trabajan con aplicaciones COM o CORBA conocen el estilo RPC. SOAP admite también aplicaciones con estilo de documento en las que los mensajes SOAP cubren un documento XML. Las aplicaciones SOAP con estilo de documento son muy flexibles. Muchos nuevos servicios XML Web Services aprovechan esta flexibilidad para diseñar servicios que sería difícil implementar mediante RPC. La última parte opcional de la especificación SOAP define los contenidos de un mensaje HTTP que contiene un mensaje SOAP. Este enlace HTTP es importante porque casi todos los sistemas operativos actuales, y otros no tan actuales, admiten HTTP. Este enlace es opcional pero casi todas las implementaciones SOAP lo admiten porque es el único protocolo estandarizado para SOAP. Por esta razón, existe la falsa idea general de que SOAP necesita HTTP. Algunas implementaciones admiten MSMQ, series MQ, SMTP o TCP/IP. Sin embargo, la mayoría de los servicios XML Web Services utilizan HTTP porque es ubicuo. Dado que HTTP es un protocolo imprescindible para el medio Web, muchas empresas disponen de infraestructuras de redes que lo admiten y personal con conocimientos y experiencia para gestionarlo. En la actualidad ya se encuentran disponibles la seguridad, el control y la infraestructura de equilibrio de cargas para HTTP. A la hora de empezar a trabajar con SOAP, es importante entender la diferencia entre la especificación SOAP y la variedad de implementaciones de esta especificación. Muchos programadores que utilizan SOAP no escriben mensajes SOAP directamente, sino que utilizan un SOAP Toolkit para crear y analizar mensajes SOAP. Generalmente, estos kits de herramientas traducen llamadas de función de algún tipo de lenguaje a un mensaje SOAP. Por ejemplo, Microsoft SOAP Toolkit 2.0 traduce llamadas de función COM a SOAP y el kit de herramientas de Apache traduce funciones de llamadas JAVA a SOAP. Los tipos de llamadas de función y los tipos de datos de los parámetros admitidos varían en cada implementación SOAP, de forma que es posible que una función que trabaja con un kit de herramientas no funcione con otro. Esto no es una limitación de SOAP, sino de la implementación específica que utilice en cada caso.La característica más notable de SOAP es que se ha implementado en diferentes plataformas de hardware y software, lo que significa que puede utilizarse para enlazar sistemas dispares dentro y fuera de su empresa. En el pasado se realizaron muchos intentos para conseguir un protocolo de comunicaciones común que pudiera usarse en la integración de sistemas. Sin embargo, ningún intento se ha generalizado tanto como SOAP. ¿Por qué? Porque SOAP es más pequeño y sencillo de implementar que muchos de los protocolos anteriores. Por ejemplo, se tardaron años en implementar DCE y CORBA, de modo que sólo unas pocas implementaciones llegaron a comercializarse. Por su parte, SOAP utiliza analizadores XML y bibliotecas HTTP existentes para realizar la mayor parte del trabajo más complicado; por ello, una implementación SOAP puede estar terminada en cuestión de meses. Ésta es la razón por la que hay disponibles más de 70 implementaciones SOAP. No obstante, SOAP no consigue los mismos resultados que DCE o CORBA pero su sencillez y características posibilitan que esté disponible rápidamente.La ubicuidad de HTTP y la sencillez de SOAP los convierte en una base perfecta para implementar servicios XML Web Services que pueden llamarse desde prácticamente cualquier entorno. Para obtener más información sobre SOAP, consulte la página principal de SOAP en MSDN.Aspectos sobre la seguridadUna de las primeras preguntas que se cuestiona un usuario nuevo es cómo protege SOAP la seguridad. En los primeros momentos de su desarrollo, SOAP era considerado como un protocolo basado en HTTP y, por tanto, se asumía que la seguridad de HTTP sería adecuada para SOAP. Además, existen miles de aplicaciones Web que se ejecutan actualmente utilizando la seguridad de HTTP. Por esta razón, el estándar SOAP actual supone que la seguridad es un problema de transporte y no comenta nada sobre los problemas de seguridad. La seguridad empezó a ser un problema en el momento en que SOAP se convirtió en un protocolo más generalizado que se ejecutaba en múltiples medios de transporte. Por ejemplo, HTTP proporciona diferentes modos de autenticar qué usuario realiza una llamada SOAP. Pero, ¿cómo se propaga esa identidad al dirigirse el mensaje desde HTTP a un transporte SMTP? SOAP se diseñó como un protocolo de base; afortunadamente existen especificaciones en los textos para diseñar en SOAP que proporcionan más características de seguridad para servicios Web. El artículo sobre la especificación WS-Security define sistemas de cifrado completos y el artículo WS-License define técnicas que protegen la identidad de la persona que llama y aseguran que sólo usuarios autorizados puedan utilizar un servicio Web.
En esta serie de artículos nos iremos adentrando en el fascinante mundo del .NET
Introduccion a .NET
.NET es un proyecto de Microsoft para crear una nueva plataforma de desarrollo de software con énfasis en transparencia de redes, con independencia de plataforma y que permita un rápido desarrollo de aplicaciones. Basado en esta plataforma, Microsoft intenta desarrollar una estrategia horizontal que integre todos sus productos, desde el Sistema Operativo hasta las herramientas de mercadeo.
.NET podría considerarse una respuesta de Microsoft al creciente mercado de los negocios en entornos Web, como competencia a la plataforma Java de Sun Microsystems.
A largo plazo Microsoft pretende reemplazar la Interfaz de Programación de Aplicaciones (API por sus siglas en inglés) Win32 o Windows API con la plataforma .NET. Esto debido a que la API Win32 o Windows API fue desarrollada sobre la marcha, careciendo de documentación detallada, uniformidad y cohesión entre sus distintos componentes, provocando múltiples problemas en el desarrollo de aplicaciones para el sistema operativo Windows. La plataforma .NET pretende solventar la mayoría de estos problemas proveyendo un conjunto único y expandible con facilidad, de bloques interconectados, diseñados de forma uniforme y bien documentados, que permitan a los desarrolladores tener a mano todo lo que necesitan para producir aplicaciones sólidas.
Debido a las ventajas que la disponibilidad de una plataforma de este tipo puede darle a las empresas de tecnología y al público en general, muchas otras empresas e instituciones se han unido a Microsoft en el desarrollo y fortalecimiento de la plataforma .Net, ya sea por medio de la implementación de la plataforma para otros sistemas operativos aparte de Windows (Proyecto Mono de Ximian/Novell para Linux/MacOS X/BSD/Solaris), el desarrollo de lenguajes de programación adicionales para la plataforma (ANSI C de la Universidad de Princeton, NetCOBOL de Fujitsu, Delphi de Borland, entre otros) o la creación de bloques adicionales para la plataforma (como controles, componentes y librerías de clases adicionales); siendo algunas de ellas iniciativas de distribución gratuita bajo la licencia GNU.
Con esta plataforma Microsoft incursiona de lleno en el campo de los Servicios Web y establece el XML como norma en el transporte de información en sus productos y lo promociona como tal en los sistemas desarrollados utilizando sus herramientas.
.NET intenta ofrecer una manera rápida y económica pero a la vez segura y robusta de desarrollar aplicaciones - o como la misma plataforma las denomina, soluciones - permitiéndo a su vez una integración más rápida y ágil entre empresas y un acceso más simple y universal a todo tipo de información desde cualquier tipo de dispositivo.
Conoceremos las distintas versiones de Visual Studio .NET y los requisitos de instalación; comentaremos algunos trucos y finalmente instalaremos paso a paso Visual Studio .NET.En esta sección veremos conceptos básicos de programación utilizando Visual Studio .NET y ASP .NET Web Matrix.3.2.1. Programación Orientada a Eventos, Formularios y Controles.
En esta sección veremos el concepto de programación orientada a eventos; cómo crear formularios y controles.3.2.1.1. Objetos, Métodos, Propiedades y Eventos.Para escribir aplicaciones en Visual Studio .NET o en Web Matrix usted va a trabajar con objetos, métodos, propiedades y eventos. Definamos estos conceptos:
Objetos:Son los ladrillos de construcción de las aplicaciones de Visual Basic.Son los elementos programables que usted utiliza para hacer su aplicación.Para poder interactuar con los objetos usted utiliza las propiedades, métodos y eventos.Para entender mejor estos conceptos vamos a hacer una analogía entre un objeto físico, un reloj despertador, un objeto de Visual Basic .NET, y un formulario.
Propiedades: Las propiedades son las caractersticas de un objeto.Por ejemplo, las propiedades de un reloj despertador pueden ser su altura, ancho y color. Un formulario en Visual Basic también tiene sus propiedades como por ejemplo, altura, ancho y color.
Métodos: Los métodos son las cosas que los objetos pueden hacer.Por ejemplo, con un reloj despertador usted podrá modificar la hora y modificar los minutos. Los métodos de los formularios son las cosas que éstos pueden hacer tales como mostrarse y ocultarse.
Eventos: Los eventos son las acciones a las que un objeto puede responder.Por ejemplo, el reloj despertador puede responder al evento de alarma emitiendo sonidos. Cuando un usuario cierra un formulario, el formulario responde a un evento llamado closed que ejecuta el código que el programador puso en el evento.
¿Qué es la programación manejada por eventos?
Las aplicaciones en Visual Studio .NET y Web Matrix son manejadas por Eventos. Hay otros paradigmas de programación, uno de ellos es la programación procedural.
Programación Procedural: En este modelo el programa principal controla el flujo lógico de ejecución de un programa, por ejemplo, la manera en que la información es ingresada por el usuario.
Programación Manejada por Eventos: El usuario genera eventos como mover el mouse o presionar una tecla y esto provoca la ejecución del segmento de código asociado al evento. Por ejemplo, como se puede ver en la imagen, cuando un usuario hace clic en el botón del formulario se ejecuta el código que el programador de la aplicación haya puesto. Es decir, depende de la acción del usuario la ejecución de ese código.
Clases: Las Plantillas de los Objetos.
Clase: De la misma manera que el plano de una casa describe los elementos que hacen la casa como ventanas o puertas, una clase es una representacin simbólica de objetos. Una clase define las propiedades y operaciones que cualquier miembro de ella deber tener.
Objeto: Es una instancia de una clase. Usted utiliza una clase para crear los objetos que necesite. De la misma manera que se usa un plano para construir una casa.
Ejemplos:Cada formulario que usted usa en una aplicación de Visual Studio .NET o Web Matrix es un objeto. La clase a partir de la cual se generó el formulario es la clase Form.Cada control que usted pone en un formulario es un objeto. La clase de la cual deriva se llama clase Control.
Clases: Describen las propiedades, métodos y eventos de los objetos que son miembros de ella.Propiedades: Son las características de un objeto como por ejemplo su tamaño, color o forma.Métodos: Son la acciones que un objeto puede hacer. En el caso de un formulario, por ejemplo, Cerrar y Ocultar.Eventos: Son las acciones que un objeto reconoce y como resultado de ello ejecuta código asociado. Por ejemplo, un control en un formulario que reconoce que el usuario hizo clic sobre él y por lo tanto cierra la ventana.De la misma manera que usted puede usar los componentes de una radio, por ejemplo el volumen, sin necesidad de saber cómo son los circuitos electrónicos; en un programa los objetos son usados y el programador no necesita saber cómo fue escrito el código.Por ejemplo, usted pone en un formulario un control, escribe código en el evento clic y ejecuta el programa. Durante la ejecución al hacer clic en el control, el control responde al evento clic y ejecuta el código asociado. Usted esta usando un objeto pero no necesita saber cómo está escrito. La clase control fue escrita por Microsoft y usted la utiliza para crear objetos de tipo control.Esto es muy importante. Convierte a los objetos en cajas negras donde lo que interesa es lo que hace y no cómo está implementado. Es decir, se encapsula la complejidad y además permite la reusabilidad del código ya que usted no tiene que volver a escribir el código del objeto cada vez que lo utiliza. ¡Imagine si usted tuviera que conocer cómo trabaja cada función del sistema operativo y tuviera que escribir el código cada vez para poder hacer alguna operación!
Christian Estay es estudiante de Ingenieria Informatica, esta afiliado al programa "Desarrollador 5 Estrellas" de Microsoft, y es participante activo en la comunidad MSDN Chile.
