Clase xiii
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
718
On Slideshare
718
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Básicamente la Arquitectura se centra en un arquitectura de 3 capas. 1. La capa de presentación que en este caso esta formada por los Componentes de IU, y los componentes de proceso de IU. Los componentes de IU pueden ser vistos como la parte con la cual interactuar el usuario. Las ventanas o páginas web, por decirlo de alguna manera. Los componentes de proceso de IU podríamos asociarlos a clases de tipo controladora en UML. Es decir estos encapsulan lógica de navegación y control de eventos de la interfase. 2. La capa de negocios encapsula lógica de negocios. Los servicios de esta capa son encapsulados en tres tipos de componentes, dos de los cuales se tocan en este ejercicio. Las entidades empresariales, que representan objetos que van a ser manejados o consumidos por toda la aplicación, estos podrían ser un modelo de objetos, xml, datasets con tipo, estructuras de datos, que permitan representar objetos que han sido identificados durante el modelamiento. Los otros tipos de objetos son los componentes empresariales que contienen lógica de negocio, y en algunos casos al usar COM+ son los objetos raíz que inician las transacciones. 3. La capa de acceso a datos que contiene clases que interactúan con la base de datos. Estas clases surgen como una necesidad de mantener la cohesión o clases altamente especializadas que ayuden a reducir la dependencia entre las clases y capas. Aquí podemos encontrar también una clase con métodos estáticos que permiten uniformizar las operaciones de acceso a datos a través de un único conjunto de métodos, esta clase es el SQLHelper que también se usa en este proyecto
  • Muchas tecnologías de cliente ligero pertenecen al lado servidor, y los marcos y plataformas de servidor Web (ASP, ASP.NET, JSP, etc.) entre los que se puede elegir es elevado. Cada uno presenta características especiales que intentan hacer más fácil la creación de aplicaciones de cliente ligero, pero todos ellos ofrecen la interfaz de usuario en un explorador en el cliente mediante una serie de páginas HTML. Una aplicación de cliente ligero se puede definir de forma simple como la aplicación que utiliza un explorador para proporcionar el entorno de ejecución de su interfaz de usuario (definida con HTML). Además de proporcionar la interfaz y de permitir que el usuario interactúe con ella, el explorador también ofrece capacidades genéricas de seguridad, administración de estados y control de datos, junto con el entorno de ejecución para cualquier lógica del lado cliente. El explorador generalmente facilita a este último un motor de secuencias de comandos y capacidad para alojar otros componentes ejecutables como subprogramas Java, controles ActiveX y .NET, entre otros, (aunque la mayoría de las definiciones de tecnologías de cliente ligero no consideran a estos componentes ejecutables como tales; véase la sección dedicada a las aplicaciones híbridas más adelante). Una aplicación que se haya diseñado para utilizar una capa de presentación de cliente ligero se compone de páginas, cada una de las cuales se "implementa" en el cliente a petición. Cada página contiene la descripción de la interfaz de usuario y, generalmente, parte de la lógica de secuencias de comandos del lado cliente y una pequeña cantidad de datos e información de estado (Viewstate, cookies, islas de datos XML, etc.). En la figura 1 se muestra una representación esquemática de una arquitectura de capa de presentación de cliente ligero. El explorador tiene capacidad limitada para interactuar con el entorno de cliente (el hardware y otras aplicaciones de software que se ejecuten en él). Proporciona un mecanismo para guardar pequeñas cantidades de datos en el cliente (mediante cookies) y, en ocasiones, permite almacenar páginas en caché, si bien, estas características normalmente son de uso limitado, excepto cuando se trata de seguimiento o administración simple de sesiones y de capacidades rudimentarias sin conexión de sólo lectura, respectivamente. El explorador también ofrece la infraestructura de seguridad para que se pueda asignar a las distintas aplicaciones (páginas) más o menos permisos para hacer cosas distintas con el estado (como las cookies), alojar componentes y ejecutar secuencias de comandos. Internet Explorer implementa todas estas capacidades con el uso de distintas zonas, sitios de confianza, valoraciones, etc. En un intento de proporcionar una interfaz de usuario enriquecida y con un mayor nivel de respuesta, algunas aplicaciones Web han recurrido a DHTML y otras tecnologías similares. Aunque no se consideran tecnologías estándar en el sentido de que no todos los exploradores las admiten de la misma forma, ofrecen capacidad para incluir elementos de interfaz de usuario más avanzados (menús desplegables, operaciones de arrastrar y colocar, entre otros) en una página Web. Otras aplicaciones Web han recurrido a alojar componentes complejos dentro de la página como subprogramas Java, controles ActiveX y .NET. Estos componentes ofrecen bien una interfaz de usuario con mayor nivel de respuesta, bien lógica del lado cliente que no se puede implementar en secuencias de comandos o por razones de seguridad. Es en este punto donde el cliente ligero comienza a mezclarse con el cliente inteligente conduciendo a lo que se conocen como aplicaciones híbridas. Aunque es posible utilizar estas aplicaciones híbridas para equilibrar los puntos débiles y fuertes de cada enfoque, en este documento, el término cliente ligero se define como una aplicación Web genérica que no emplea tales componentes sino las características básicas que ofrece el entorno del explorador. Las aplicaciones híbridas se describirán en una sección posterior, junto con las aplicaciones de cliente inteligente, dado que precisan utilizar capacidades de estas últimas para evitar problemas de administración y funcionamiento.
  • La capa de presentación en las arquitecturas de n capas realizadas con ASP.NET 2.0, estará compuesta de controles de visualiación y controles de enlace a la capa de acceso a datos. Para que los controles de visualización de datos como el GridView, el FormView y el DetailsView, puedan intervenir en una arquitectura de tres capas, deben ser enlazados a clases que representan los objetos de acceso a los datos mediante objetos data source como el control ObjectDataSource. ObjectDataSource: En ASP.NET dicho control representa un objeto de capa media, el cual tiene la capacidad de recibir y actualizar datos. El control ObjectDataSource actúa como una interfase media para controles que limitan con los datos como por ejemplo los GridView, FormView o DetailsView y habilita estos controles para mostrar y editar datos desde la capa de negocios sobre una pagina Web ASP.NET. La mayoria de los controles de acceso a datos de ASP.NET, como el SqlDataSource, son usados en arquitectura de aplicaciones de dos capas donde la capa de presentación (la pagina Web ASP.NET) se comunica directamente con los datos (una base de datos, un archivo XML, etc). Sin embargo, una practica común en el diseño de una aplicación es separar la capa de presentación de la lógica de negocio y encapsular la lógica del negocio en objetos de negocios. Estos objetos de negocios forman una capa entre la capa de presentación y la capa de datos, resultando una arquitectura de 3 capas. El control ObjectDataSource soporta la arquitectura de 3 capas, proveyendo una manera de vincular datos sobre la pagina a un objeto de negocio de capa media. El ObjectDataSource trabaja con objetos de negocios de capa media para la selección, inserción, modificación, eliminación, y filtrado de datos sin la necesidad de declarar gran cantidad de información.
  • La propiedad TypeName require que se le indique el nombre de la clase DAL de la entidad de negocio que manejará el control. Por ejemplo si se utilizase el control como intermediario para mostrar la lista de productos en un GridView, el nombre de la clase que contiene la lógica de acceso a datos podría ser ProductsDAL. Las propiedades SelectMethod , UpdateMethod, InsertMethod y DeleteMethod , se utilizan para indicar qué método de la clase definida en TypeName , implementarán las operaciones de Select, Update y Delete para los datos.
  • Las propiedades XxxParameters permiten identificar los parámetros que serán pasados a los métodos Insert, Delete, Select y Update definidos en InsertMethod , DeleteMethod, SelectParameters y UpdateMethod . Los métodos implementados en la clase DAL indicada en TypeName , recibirán estos parámetros y los utilizarán para realizar las operaciones contra el data storage.
  • En el ejemplo se visualizan los tags que mantienen las propiedades del control y cómo se definen los UpdateParameters de UpdateProduct.
  • En el ejemplo se visualiza un posible código que implementa el método de la clase DAL asociado a la propiedad UpdateMethod del control.
  • La configuración del ObjectDataSource se realiza de forma automática mediante un asistente que lo guía en la configuración de todas las propiedades necesarias. Antes de utilizar el asistente, asegúrese de que el objeto que implementará la capa de acceso a datos, y el objeto de negocios, ya se encuentren diseñados e implementados. El primer paso del asistente le preguntará cuál es el objeto de negocio que desea utilizar. Deberá seleccionar la clase que posea los métodos necesarios para el select, insert, delete y update de los datos, por ejemplo OrderDetailsDAL.
  • El segundo paso del asistente le dará la posibilidad de seleccionar los métodos de la clase definida en el paso anterior, que serán utilizados para las operaciones de select, update, insert y delete de los datos.
  • Por último, si el método que implementa el select posee algún parámetro, por ejemplo se espera obtener un conjunto de valores que cumplan una condición, deberá definir los valores de cada parámetro del select.
  • Los controles de visualización de datos como el GridView, poseen propiedades que les permiten ser enlazados a controles de acceso a datos como el ObjectDataSource. Las propiedades más significativas son: DataSourceID representa un objeto que implementa IDataSource, como por ejemplo una instancia el control ObjectDataSource. DataMember representa una tabla o vista asociada al DataSourceID indicado si correspondiese. DataKeys contiene una lista separada por comas de los campos clave del data source asociado.
  • La capa de negocios estará compuesta por clases que representan las entidades de negocio que intervienen en el dominio de la solución final. Por ejemplo, se generará una clase Products para mantener la información y realizar las operaciones comunes a los productos que intervienen en los procesos de negocio de la solución. Existirá una clase Orders para las ordenes de compra, y así sucesivamente.
  • Los componentes DAL (Data Access Layer) estarán representados por clases .NET que contarán con la lógica suficiente para conectarse con un data storage mediante algún proveedor de datos. Existirá una clase DAL por cada entidad de negocio definida en la capa de negocio. Por ejemplo, si se definieron las entidad Products, Employees y Orders en la capa de negocio, en la capa de acceso a datos existirán las clases ProductsDAL, EmployeesDAL y OrdersDAL, cada una con la interfase suficiente para realizar las operaciones de acceso, modificación y eliminación de datos en el data storage.
  • El data storage es el origen y destino de los datos que maneja la aplicación. Puede ser una base de datos relacional, un archio de texto plano o un archivo .xml entre otros.
  • El Namespace System.Globalization contiene clases que definen el espacio de trabajo del usuario, incluyendo el lenguaje, configuración regional, el calendario que se utilizara, los patrones para la fecha, hora, numero, y moneda. Estas clases son muy utilizadas para escribir aplicaciones mas globalizadas. Clases como StringInfo y TextInfo proveen funcionalidades avanzadas de globalización como el soporte para la ayuda en el idioma especifico y el procesamiento de los elementos de texto.
  • Una aplicación globalizada debería estar disponible para mostrar y usar calendarios basados en la actual cultura. El .NET Framework provee la clase Calendar la cual posee las siguientes implementaciones: GregorianCalendar, HebrewCalendar, HijriCalendar, JapaneseCalendar, JulianCalendar, KoreanCalendar, TaiwanCalendar, y ThaiBuddhistCalendar. La clase CultureInfo tiene la propiedad CultureInfo.Calendar que especifica el actual calendario. Algunas culturas soportan mas de un calendario. La propiedad CultureInfo.OptionalCalendars especifica los calendarios opcionales soportadas por la cultura actual. El código de ejemplo del slide muestra como crear un objeto CultureInfo para las culturas “th-TH” (Tailandés en Tailandia) y “ja-JP” (Japonés en Japón) y muestra los calendarios por defecto y opcionales para cada cultura. Nótese que el GregorianCalendar esta dividido en subtipos. La propiedad GregorianCalendar.CalendarType especifica el subtipo Gregorian para el calendario. En este ejemplo, cada vez el calendario es determinado a Gregorian, el valor CalendarType es recibido y mostrado.
  • La clase NumberFormatInfo define como son formateados y mostrados los datos numéricos, moneda, separador decimal y otros símbolos numéricos según la cultura configurada. Por ejemplo, el numero 10000,50 es formateado como 10,000.50 para la cultura “en-US” y 10.000,50 para la cultura “es-AR”. Una instancia de NumberFormatInfo puede ser creada para una cultura especifica o para una variante de la cultura, pero no para una cultura neutral. El ejemplo del slide muestra el uso de un Entero para especificar CurrentCulture usando el formato estándar de moneda con NumberFormatInfo.
  • Clase DateTimeFormatInfo Esta clase contiene información, para los patrones de fecha, hora, designación de AM/PM Para crear un DateTimeFormatInfo para una cultura especifica, cree un CultureInfo para la cultura y reciba la propiedad CultureInfo.DateTimeFormat . Para crear un DateTimeFormatInfo para la cultura actual, use la propiedad CultureInfo . En algunos casos el usuario podría querer sobrescribir algunos valores que estén configurados en las opciones de Configuración Regional dentro del Panel de Control . Por ejemplo, el usuario querría ver la fecha en un formato diferente a la actual configuración estándar del sistema. Si la propiedad CultureInfo.UseUserOverride es configurada en Verdadero, las propiedades de las instancias CultureInfo.DateTimeFormat, CultureInfo.NumberFormat, CultureInfo.TextInfo son recibidas desde la configuración del usuario. Si la configuración del usuario son incompatibles con la cultura asociada con CultureInfo (por ejemplo, si el calendario asociado no es uno de los calendarios opcionales), el resultado de los métodos y valores de las propiedades son indefinidos. Los valores de DateTime son formateados usando patrones estándares o personalizados almacenados en las propiedades de DateTimeFormatInfo .
  • El código del slide anterior produce la salida vista en el slide actual
  • En la presentación actual se muestra los valores de RegionInfo , los valores devueltos de una comparación a través de RegionInfo con otro RegionInfo creado usando CultureInfo .
  • Localización es un proceso intermedio para verificar que una aplicación globalizada esta lista para la localización. Una aplicación esta lista para la localización si el código de ejecución de la aplicación ha sido claramente separado de los recursos de localización de la aplicación. El runtime tiene un completo soporte para la utilización separada del código y de los recursos. El código ejecutable esta localizado en el assembly principal de la aplicación y solo los recursos están localizados en los archivos de recursos de la aplicación. Usted debería proceder al paso de la localización solo después de haber verificado que la aplicación globalizada esta lista para la localización. Una aplicación que esta lista para la localización esta separada en dos bloques conceptuales, un bloque que contiene todos los elementos de la interfase del usuario y otro bloque que contiene el código ejecutable. El bloque de la interfase del usuario contiene solo elementos localizables, como mensajes de error, caja de diálogos, menúes, etc. El bloque del código solo contiene el código de la aplicación para ser utilizada por todas las culturas soportadas. El runtime soporta el modelo de assembly satelital el cual separa el código ejecutable de la aplicación del código de los recursos. Para cada versión localizada de su aplicación, se agrega un assembly satelital que contiene toda el bloque de la interfase del usuario dentro del lenguaje apropiado para la cultura de destino. El bloque de código para todas las culturas debería ser el mismo. La combinación de la versión localizada del bloque de la interfase del usuario con el bloque del código produce una versión localizada de la aplicación. El .NET Framework SDK aporta un Windows Forms Resuorce Editor (Winres.exe) que permite que usted localice rápidamente el Windows Forms para la cultura de destino.
  • La encriptación ayuda a proteger la información de ser vista o modificada y ayuda a crear canales de comunicación encriptados sobre canales que de otra manera serían inseguros. Por ejemplo, la información puede ser encriptada usando un algoritmo criptográfico, transmitido en un estado encriptado, y luego desencriptado por en el lugar deseado. Si alguien no deseado intercepta la información, será difícil de descifrar.
  • En una situación típica donde se usa la criptografía, 2 partes (Juan y Pedro) se comunican sobre un canal inseguro. Juan y Pedro se quieren asegurar de que su conversación sea incomprensible para cualquiera que pudiera estar escuchando. Además, como Juan y Pedro están en ubicaciones remotas, Juan debe estar seguro de que la información que recibe de Pedro no fue modificada por nadie durante la transmisión. Además, Juan debe estar seguro de que la información realmente se origina de Pedro y no de cualquiera que esté interpretando a Pedro. Para alcanzar estos objetivos, se puede usar una combinación de algoritmos y prácticas conocidas como primitivas de la criptografía para crear un esquema encriptado.
  • Secret-key encryption (criptografía simétrica): realiza una transformación de la información, evitando que sea leida por terceras partes. Este tipo de encriptación usa una clave secreta compartida para encriptar y desencriptar la información. Se debe proteger la clave porque cualquiera que la tengo puede desencriptar la información. Se lo llama criptografía simétrica porque la misma clave se usa para encriptar y desencriptar. Estos algoritmos son extremadamente rápidos (comparados con los Public-Key) y sirven para realizar transformaciones criptográficas en grandes cantidades de información. Las clases de Secret-Key provistas en BCL usan un modo encadenado llamado cipher block chaining (CBC), el cual usa una clave y un vector de inicialización para realizar las transformaciones criptográficas en la información. Public-key encryption (criptografía asimétrica): usa una clave privada que debe ser secreta para los usuarios no autorizados y una clave pública que puede ser conocida por cualquiera. La clave pública y la clave privada están matemáticamente enlazadas; la información encriptada con la clave pública puede ser desencriptada con la clave privada, y la información firmada con la clave privada puede ser verificada solo con la clave pública. Esta puede hacerse pública a cualquiera; es usada para encriptar información para ser enviada al propietario de la clave privada. Las dos claves son únicas para la sesión de comunicación. Estos algoritmos con conocidos con criptografía asimétrica porque una clave se necesita para encriptar la información mientras otra se requiere para desencriptarla. Cryptographic signing: ayuda a verificar que la información se genera de una parte específica creando una firma digital que es única para esa parte. Este proceso también usa funciones de hash. La firma digital autentifica la identidad de quien envía y ayuda a proteger la integridad de la información. Usando la clave pública creada por Juan, por ejemplo, el receptor de la información de Juan puede verificar que Juan fue quién lo envió comparando la firma digital con la información y clave pública de Juan. Para usar la criptografía Public-Key para firmar digitalmente un mensaje, Juan primero aplica un algoritmo de hash al mensaje para crear un resumen del mensaje. Este resumen es una representación de la información compacta y única. Juan encripta el resumen con su clave privada para crear su firma personal. Al recibir el mensaje y la firma, Pedro desencripta la firma usando la clave pública de Juan para recuperar el resumen del mensaje y hacer hash al mensaje usando el mismo algoritmo de hash que Juan utilizó. Si el resumen del mensaje de Pedro concuerda exactamente con el resumen recibido de Juan, Pedro puede estar seguro de que el mensaje provino de el poseedor de la clave privada y que la información no fue modificada. Si Pedro confía en que Juan es el poseedor de la clave privada, entonces sabe que el mensaje vino de Juan. Cryptographic hashes: mapean valores binarios de una longitud arbitraria a pequeños valores binarios de una longitud fija, conocidos como “hash values”. Un hash value es una representación numérica única y extremadamente compacta de un pedazo de información. Si se hace hash de un párrafo de texto plano y se cambia aunque sea una letra del párrafo, un hash subsecuente producirá un valor diferente. Es computacionalmente improbable encontrar 2 distintas entradas que hacen hash al mismo valor.
  • .NET Framework provee las siguientes clases para implementar los algoritmos de hashing : SHA1Managed, SHA256Managed, SHA384Managed y SHA512Managed: el hash es usado como un único valor de un tamaño fijo que representa una gran cantidad de información. Los hashes de dos conjuntos de información si y solo si la información también corresponde. Pequeños cambios a la información resultan en grandes e impredecibles cambios en el hash. Tamaño de hash: SHA1Managed: 160 bits. SHA256Managed: 256 bits. SHA384Managed: 384 bits. SHA512Managed: 512bits. MD5CryptoServiceProvider: Cualquier miembro público estático de este tipo es libre de thread. Cualquier miembro de instacia no están garantizados como libres de thread. MACTripleDES: un MAC puede ser utilizado para determinar si un mensaje enviado por un canal inseguro ha sido manipulado. El que envia y el que recibe comparten una clave secreta. El que envía computa el MAC para la información original, y envía ambos como un solo mensaje. El receptor re computa el MAC en el mensaje recibido, y chequea que el MAC computado coincida con el MAC transmitido. Cualquier cambio en la información del MAC provocara que la información no concuerde, porque el para cambiar el mensaje y reproducir el MAC correcto se necesita conocer la clave secreta. Por eso, si el código coincide, el mensaje es autenticado. MACTripleDES usa una clave de 8, 16 or 24 bytes, y produce una secuencia de hash de 8 bytes. HMACSHA1: computa un HMAC (Hash-based Message Authentication Code) usando la función hash SHA1. Criptografía simétrica DES Usa claves de 56 bits. Fue diseñado hace 25 años y es vulnerale a ataques de fuerza bruta en los cuales el atacante intenta todos los valores de las claves. RC2 Usa una clave de longitud variable (desde 8 bits hasta 128 bits) y un block de 64 bits. Este algoritmo es fácil de implementar en una computadora de 16 bit y y fue diseñado para la encriptar en masa. Triple-DES Es una variante de DES que usa DES tres veces con tres claves diferentes. Triple-DES es más fuerte que DES, pero es más lento que otros block ciphers. Rijndael (o AES ) Usa un block de 128-bit, y claves de 128, 192 y 256 bit. Este algoritmo funciona muy bien en implementaciones de hardware y software. Implementación en el .NET Framework DESCryptoServiceProvider: define una envoltura de objeto para acceder a la versión CSP (cryptographic service provider) del algoritmo DES (Data Encryption Estándar). Esta clase no puede ser heredada. RC2CryptoServiceProvider: define una envoltura de objeto para acceder a la implementación CSP (cryptographic service provider) del algoritmo RC2. Esta clase no puede ser heredada. RijndaelManaged: accede a la versión manejada del algoritmo Rijndael. TripleDESCryptoServiceProvider: define una envoltura de objeto para acceder a la versión CSP (cryptographic service provider) del algoritmo TripleDES. Esta clase no puede ser heredada. Criptografía asimétrica: Clases RSA, DSA: ambas clases se utilizan para implementar los algoritmos RSA y DSA.
  • Ejemplo de código que muestra cómo encriptar información que recibe el procedimiento. En el ejemplo se define un archivo de entrada y uno de salida, se toma la información del archivo de entrada y se la encripta usando el algoritmo TripleDES . Mediante la clase CryptoStream se guardan los datos encriptados en el archivo de salida.
  • Declaración de una clase SHA512Managed
  • La mayoría de los algoritmos criptográficos necesitan utilizar números generados al azar. Por ejemplo, las claves criptográficas tienen que ser completamente conseguidas al azar para que sean casi imposibles de reproducir. Las clases en .NET Framework como RandomNumberGenerator usan generadores de números al azar para generar claves criptográficas.
  • Evolución de las aplicaciones distribuidas Antes de las computadoras personales, no existía la noción de aplicaciones distribuidas. El usuario se sentaba delante de una terminal e interactuaba con el mainframe. Más allá de que las terminales pudieran estar en diferentes lugares físicos, el procesamiento se realizaba en la computadora central. Con la aparición de las mini-computadoras y las computadoras personales, fue conveniente descentralizar el procesamiento y el almacenamiento de los datos. Las mayores circunstancias que apoyaron la descentralización del procesamiento y almacenamiento de datos incluyen: Costo de los mainframes Una de las principales causas fue el costo de los mainframes. Tanto el costo inicial, como el riesgo de tener centralizado el costo que produciría un fallo en el sistema, ambos, son un riesgo que muchas compañías no podían asumir. Propiedad de los datos Un factor importante que condujo a la descentralización, fue que los departamentos, divisiones o sitios propietarios de los datos, no quisieron delegar la responsabilidad de manejar sus datos a alguna otra ubicación centralizada. Seguridad Otro factor importante fue la seguridad. Para las organizaciones, existe una gran cantidad de datos que deben ser de fácil acceso, pero hay otros que deben estar segurizados. Implementar diferentes mecanismos de seguridad a cada dato, es mucho más fácil con sistemas segmentados físicamente. Aplicaciones distribuidas como proveedores de servicios Los factores anteriores, permitieron emerger un nuevo patrón de diseño de aplicaciones, conocido como aplicaciones distribuidas. En lugar de ver las aplicaciones distribuidas como una unidad lógica, se empezaron a ver como componentes distribuidos de una aplicación como proveedores de servicios. El concepto de funcionalidad distribuida, trajo la promesa de la reutilización. Los desarrolladores pueden usar cada conjunto de funcionalidad distribuida como building block de aplicaciones mucho mayores. Existen, sin embargo, varios problemas en este tipo de arquitectura, algunos de ellos serán explicados más adelante en este módulo. Aplicaciones distribuidas en la Web Aún siendo que Internet existe desde hace más de veinte años, es a partir de mediados de los 90 que proveen infraestructura para aplicaciones distribuidas. La adopción de un conjunto de tecnologías estándares, no propietarias, para enviar y recibir información por Internet, permitieron que la misma sea una plataforma viable para las aplicaciones distribuidas.
  • Problemas de las aplicaciones distribuidas tradicionales El desarrollo de aplicaciones distribuidas requiere nuevas técnicas de diseño y nuevos modelos. Esto conlleva nuevos tipos de problemas. En esta sección, usted verá las características que debe considerar cuando diseñe aplicaciones distribuidas. Adicionalmente, verá dos tipos de arquitecturas realizadas para permitir el desarrollo de aplicaciones distribuidas: Arquitecturas Remote Procedure Call (RPC-based). Arquitecturas basadas en mensajes. Serán discutidos los problemas de ambas arquitecturas. Finalizando, se revisarán los estándares de la Web y su efecto en las aplicaciones distribuidas.
  • Consideraciones de diseño para las Aplicaciones distribuidas Hay varios problemas comunes que usted debe considerar al diseñar una aplicación distribuida. Diferentes sistemas operativos soportan diferentes tipos de datos. En ocasiones no existe un 100% de compatibilidad entre diferentes sistemas operativos. Por consiguiente, usted debe considerar cómo ocuparse de los tipos de datos que no son compatibles entre los diferentes sistemas. Debido a que los componentes de aplicaciones distribuidas son a menudo remotos, existe un mayor número de lugares donde puede fallar el sistema. El fallo en uno de sus componentes puede causar problemas en toda la aplicación. Por consiguiente, usted debe considerar cómo manejar los fallos en el servidor y la pérdida de respuesta del mismo. Si un servidor está guardando el estado de un cliente, y el cliente falla, entonces usted debe considerar cómo el servidor se notificará de esta situación. Usted también debe considerar si es necesario liberar los recursos en el servidor que estaban siendo usados por el cliente. Si un método remoto se llama y no hay ninguna contestación del servidor, es posible que no sea conveniente reintentar la llamada nuevamente. Por ejemplo, si se envía al servidor una orden de compra y el mismo la recibe pero se pierde la respuesta al cliente, no es conveniente volver a mandar desde el cliente la orden de compra al servidor. En las aplicaciones distribuidas, existen más riesgos de seguridad. No sólo debe considerarse autenticación y autorización, sino también la seguridad de las comunicaciones entre el cliente y el servidor, y la posibilidad de diferentes ataques a las partes de la aplicación como por ejemplo denial-of-service. Una característica adicional a considerar a la hora de desarrollar aplicaciones distribuidas, es la sincronización de los relojes de los diferentes equipos para asegurar la integridad de los datos del negocio.
  • Arquitecturas basadas en RPC Las arquitecturas basadas en RPC, son la primer opción al considerar una solución basada en aplicaciones distribuidas. El remote procedure call (RPC) es una invocación a un procedimiento o función que reside en un sistema remoto. Un RPC se ve como una llamada normal a un método local desde el código cliente. Un RPC provee: Ubicación transparente. El programador no necesita conocer la ubicación real del proveedor del servicio. Modelo de programación conocido. Muchos programadores están acostumbrados a usar cierta forma para llamar a procedimientos. La infraestructura RPC genera un stub que actúa como representante del procedimiento remoto y realiza un marshal de los argumentos del procedimiento a un buffer que puede ser transmitido por la red hacia el servidor RPC. En el servidor RPC, el stub obtiene los argumentos en el proceso del lado del servidor, y los argumentos son pasados a la función que fue originalmente invocada. Cualquier valor de retorno es enviado al cliente de forma similar. En el modelo RPC, una aplicación establece una conversación con el servidor RPC apropiado. La llamada a una función mediante RPC, es muy similar a la llamada a una función local. La llamada mediante RPC es sincrónica, de forma que el thread de ejecución se bloquea hasta recibir la respuesta del servidor. Para muchos programadores, este es un modelo de programación donde se encuentran cómodos. De todas formas, el modelo sincrónico como primer capa de las aplicaciones distribuidas, introduce varios problemas. El primer problema inherente a las arquitecturas basadas en RPC es el discovery. ¿Cómo puede la aplicación cliente, encontrar la información necesaria para conectarse al endpoint que provee los servicios requeridos? La forma más simple, y usada en la mayoría de las aplicaciones, es poner esta ubicación de forma estática (hard-code). Esta no es una solución óptima debido a que dificulta las capacidades de versatilidad de la aplicación como puede ser la tolerancia a fallos. A medida que la aplicación utilice mayor cantidad de servicios distribuidos, aumenta la posibilidad de que alguno no se encuentre disponible. Las implementaciones típicas no toleran cambios en el ambiente de deployment por tener sus ubicaciones de forma estática y de esta forma no aseguran una disponibilidad alta frente a fallos de alguno de sus servidores. Indicar de forma estática la ubicación de las aplicaciones, resulta en otro problema. No es simple para las aplicaciones basadas en RPC realizar un balanceo de carga dinámico. Las aplicaciones no pueden redirigirse a un servidor alternativo cuando el principal falla. La ponderación de los requests, es generalmente imposible, debido a que todos los requests, por defecto, son atendidos con el modelo first-come, first-serve. Si un servidor está sobrecargado de trabajo, un cliente con alta prioridad estará sujeto a tiempos e respuesta inaceptables. Otro problema de las aplicaciones basadas en RPC en la inhabilidad para controlar picos en la carga de transacciones, con las posibles siguientes consecuencias: Interrupciones temporales del servidor debido a problemas en el servidor. Falla de una acción debido a que el recurso requerido (por ejemplo una conexión a una base de datos) está sobrecargado. La necesidad de adquirir mayor equipamiento de hardware que el requerido para la carga normal debido a los picos de carga.
  • Arquitecturas basadas en mensajes Otra posible arquitectura que puede ser utilizada para desarrollar aplicaciones distribuidas es la arquitectura basada en mensajes. Un Middleware orientado a mensajes, provee a las aplicaciones, servicios de comunicación interproceso usando tecnología de message queuing para garantizar el nivel de servicio a las aplicaciones críticas. La tecnología de queuing realiza un track del mensaje a lo largo de todas las secciones recorridas, como si se tratase de una compañía de entrega de correspondencia que realizase un tracking del estado y ubicación de cada entrega. Esta tecnología de queuing asegura que cualquier problema sea rápidamente detectado y en consecuencia pueda solucionarse rápidamente sin intervención del usuario. Las aplicaciones desarrolladas sobre arquitecturas basadas en mensajes, comúnmente son desarrolladas utilizando productos realizados específicamente para esa arquitectura, como es el caso de Microsoft Message Queuing (MSMQ). Las principales características de esta tecnología son su comportamiento asincrónico y que está basada en intercambio de mensajes en lugar de llamadas a procedimientos. Ambas características poseen algunas ventajas, tales como: Los mensajes pueden ser distribuidos basándose en la carga y prioridad. Las llamadas asincrónicas permiten a los clientes seguir realizando tareas productivas mientras esperan la respuesta del mensaje. Igualmente, estas características presentan ciertos problemas. Debido a que los sistemas basados en mensajes, transmiten mensajes, una de las mayores tareas del programador es el packing y el unpacking del contenido. Luego de realizar el unpacking del mensaje, adicionalmente la aplicación debe validar el contenido del mismo. Cuanto más compleja y flexible sea la aplicación basada en mensajes, más difícil serán el unpacking y validación de los mismos. Muchos de los sistemas basados en mensajes, son desarrollados utilizando tecnología propietaria. Esto conlleva a que todos los puntos que participan de la operación distribuida, deben: Utilizar software de message queuing. Utilizar software para operar entre diferentes ambiente de mensajería. Aún cuando los requisitos previos son satisfechos, la solución resultante tiende a ser difícil de implementar y muy costosa. Por esto, las soluciones basadas en mensajes, no son un camino estándar para implementar aplicaciones distribuidas. Adicionalmente, muchas aplicaciones están envueltas en procesos de workflow conformados por una secuencia de mensajes que se intercambian entre múltiples computadoras. Debido a que los mensajes son enviados de forma asíncrona, debe crearse un layer sobre el protocolo de mensajería, que realice el track de la secuencia de los mensajes.
  • Estándares Web Ambas arquitecturas, RPC y mensajes, fueron implementadas de forma satisfactoria por muchas organizaciones, pero ambas tienen una gran cantidad de problemas. En esta sección se verá cómo los estándares Web, resuelven muchos de los problemas de los legacy y actuales modelos de objetos distribuidos. Modelos de objetos distribuidos, tales como Distributed Component Object Model (DCOM), Java Remote Method Invocation (RMI), y Common Object Request Broker Architecture (CORBA), sufren la limitación de utilizar protocolos binarios. Algunos de los problemas inherentes a utilizar protocolos binarios son: Firewalls. El principal problema es que los protocolos binarios son punto-a-punto. Como resultado, cualquier comunicación con un endpoint que se encuentre detrás de un firewall, requiere que el administrador del firewall abra un conjunto de puertos para permitir el intercambio. Para muchas organizaciones, este es un riesgo de seguridad inaceptable. Interoperabilidad. Otro problema es la interoperabilidad entre sistemas diferentes. Cada modelo de objetos utiliza su protocolo propietario. Es posible proveer software para traducir entre protocolos diferentes. Igualmente esta traducción generalmente origina pérdida de información. Como resultado, muchas organizaciones utilizan un solo modelo de objetos distribuidos para implementar sus aplicaciones. Por consiguiente, las aplicaciones distribuidas se separan en grandes grupos dependiendo del modelo de objetos distribuidos que adoptan. Si un potencial socio de negocios, utiliza un modelo de la competencia, esto originará grandes problemas. Formato de datos. Otro problema con los protocolos binarios, es el encoding de los datos transmitidos. Cada protocolo codifica los datos de forma distinta, lo que resulta en un gran overhead cuando deben decodificarse grandes cantidades de datos que fueron codificados en múltiples y diferentes formas incompatibles. Debido a estos problemas, surge la necesidad de utilizar un protocolo que sea fácilmente parseable y transformable en cuando al encoding de los datos. Aquí surge el World Wide Web (WWW) proveyendo una solución universal, fácilmente usable por cualquiera. Los protocolos Transmission Control Protocol (TCP) e Internet Protocol (IP) fueron creados originalmente para comunicar diferentes redes. Luego esta red de redes se comenzó a llamar Internet. Luego, hacia 1990, Tim Berners-Lee, un científico del CERN, inventó la World Wide Web, también llamada Web. La Web es una red interconectada global de documentos de hypertext. Emergen de este esfuerzo, dos tecnologías revolucionarias: Hypertext Markup Language (HTML) y Hypertext Transfer Protocol (HTTP). HTML es un lenguaje que define cómo agregar markups (en forma de tags) a un documento de texto para proveer información a un Web browser. Los documentos con tags HTML son llamados documentos hypertext. HTTP es el protocolo utilizado para pedir y recibir documentos hypertext en la Web. Un punto importante a tener en cuenta es que HTTP no se limita sólo a documentos HTML. Por ejemplo, pueden intercambiarse documentos XML usando HTTP. A medida que la popularidad de la Web fue creciendo, el protocolo HTTP fue universalmente adoptado. Usar HTTP sortea uno de los obstáculos de los modelos de objetos distribuidos, brindar una forma segura de comunicación. Sin embargo, HTML no permitía definir la estructura de los datos del documento, de esta forma es que en 1996 nace un lenguaje que permite definir las estructuras conocido como Extensible Markup Language (XML). Algunas características del XML son: Fácilmente utilizable en Internet. Inequívoco. Fácil de crear. Fácil para procesar y para el parsing. Extensible, independiente de la plataforma y soporte para localización. La adopción rápida del XML es la evidencia de su usabilidad como formato universal de datos. Otra contribución de la Web es el Web server. Los Web servers se comunican típicamente utilizando HTTP, lo cual es seguro y ampliamente adoptado. Un rol importante del Web server es ser el gateway de la organización. Mediante mecanismos de extensión de HTTP, los Web servers pueden realizar forward de request hacia los request handler correspondientes. El Web server se desentiende de cómo el request handler interpreta el request HTTP. Esto es así debido a que es responsabilidad del handler, procesar el request y generar el response HTTP. El Web server envía el response proporcionado por el handler, hacia el cliente. Los Web servers pueden realizar el forward de requests de cualquier tipo de servicio que el request HTTP describe y cuyo resultado puede empaquetarse en un response HTTP. Y todo esto sin necesidad de bajar el nivel de seguridad de los firewalls. Sin embargo, debido a que Internet es una infraestructura pública, cualquier comunicación es potencialmente vulnerable a intercepción, modificación, spoofing (técnica utilizada para obtener acceso no autorizado a un equipo), y otras vulnerabilidades relacionadas al acceso. Adicionalmente, actualmente la mayoría de las conexiones a Internet son lentas, y esto introduce la problemática de la performance. Por ejemplo si una aplicación interactiva requiere una gran cantidad de comunicaciones con el servidor, la misma puede perder su interactividad por problemas de ancho de banda. Los problemas de performance, seguridad y disponibilidad del servicio, indican que en muchos escenarios, la mejor opción es crear aplicaciones para redes privadas.
  • Introducción a los Web Services Los problemas de los modelos de objetos distribuidos, llevaron a buscar alternativas. Con la rápida adopción de las soluciones basadas en Web, es natural que se hayan empezado a utilizar los estándares Web. Esto condujo la evolución a los Web Services. Un Web service es una URL que expone un conjunto de funcionalidad a ser utilizada a través de la red y sirve para desarrollar aplicaciones distribuidas. Un ejemplo de Web service es Microsoft Passport. Passport provee servicios de autenticación accesibles a través de HTTP. En este manual, todas las referencias a Web services son específicas a XML Web Services. Pueden existir otros tipos de Web services como por ejemplo HTTP listeners personalizados, sin embargo no son populares y estándares como los XML Web Services. Los Web services se reposan en tecnologías como HTTP, XML y Simple Object Access Protocol (SOAP, un protocolo liviano para el canal HTTP que utiliza XML como formato de datos). El desarrollo de estas tecnologías está supervisada por el World Wide Web Consortium (W3C). Así como los componentes, los Web services son black boxes. Encapsulan la implementación, y proveen una interfase para su utilización. Usted puede aplicar los Web services a varios niveles de complejidad. Puede realizar una funcionalidad simple o puede exponer todo el workflow de una aplicación específica a través de Web services. Los Web services pueden proveer un acceso conveniente a un conjunto estático de información. Por ejemplo, un Web service puede permitir a un cliente, obtener datos demográficos de una ciudad específica. Alternativamente, los desarrolladores pueden usar los Web services para implementar aplicaciones altamente interactivas. Por ejemplo, una Web de viajes puede desarrollarse íntegramente mediante varios Web services. Los usuarios pueden usar los Web services para realizar las reservaciones de los hoteles y el alquiler de los automóviles. Un Web service puede agregar otros Web services para proveer un conjunto de servicios sofisticados. Por ejemplo un Web service desarrollado para una aplicación de ventas, puede usar otro Web service para verificar los datos de la tarjeta de crédito del usuario. En el futuro, un gran número de Web services permitirán interconectar varias aplicaciones y deberán cumplir con métricas de disponibilidad, performance, costo y calidad. ¿Por qué los Web services serán efectivos donde otras tecnologías fallaron? Serán sus principales características las que permitirán que esto ocurra. Los Web services serán invocados a través de SOAP. Debido a que SOAP es independiente de la plataforma, los desarrolladores no necesitarán pensar en construir puentes entre DCOM y CORBA, u otros protocolos. Cualquier Web service podrá interoperar con otros. Adicionalmente, debido a que los Web Services se comunican sobre HTTP y XML, cualquier nodo de red que soporte estas tecnologías, puede realizar el host y acceder a los Web services. Los desarrolladores pueden escribir Web services en cualquier lenguaje, por consecuencia no necesitan aprender nuevos lenguajes o utilizar un lenguaje único para crear o usar Web services. Es muy simple exponer componentes y librerías existentes como Web services. Los vendedores, como Microsoft, proveen herramientas para realizar esto de forma sencilla. Muchas compañías tienen un gran número de componentes y librerías. Es mucho más efectivo desde el punto de vista del costo, reusar los componentes existentes frente a reimplementarlos. Todos los vendedores más importantes soportan tecnologías relacionadas con los Web services, específicamente, HTTP, XML y SOAP. El soporte universal a estos estándares no tiene precedentes. Este tipo de soporte transforma la tarea de intercomunicar sistemas en algo mucho más simple. Por ejemplo un componente escrito en C# expuesto por un Web service, puede ser utilizado fácilmente por una aplicación Common Gateway Interface (CGI) escrita en C++, si la misma es capaz de realizar request SOAP y procesar los resultados de forma correcta.
  • Escenarios comunes a los Web services Existen muchos escenarios donde los Web services son una opción apropiada. Los proveedores de aplicaciones (Application Service Providers – ASP) que realizan el host de aplicaciones que luego cobran a sus clientes. Desde el punto de vista del cliente, estas aplicaciones cumplen con las siguientes características: La aplicación que el ASP hosts, es vista como un portal. La aplicación que el ASP hosts, existe en un ambiente aislado. Cada cliente tiene su propia instancia de la aplicación. Los clientes no comparten sus datos con otros clientes. Desde la perspectiva del ASP, todas las aplicaciones deben cumplir al menos los siguientes criterios: Las instancias de la aplicación deben poder ser configuradas de forma independiente para cada cliente, incluso si comporten el mismo hardware. Esto incluye configuraciones de seguridad. La aplicación debe permitir mecanismos que midan el tiempo de uso de la misma con el objeto de conocer el monto que debe cobrarse a cada cliente. Es también usado cuando el ASP y la aplicación, proveen interfaces estándar para interacción mutua Es obvio que los Web services son una potencial buena opción para realizar aplicaciones pensadas para hosting. Otro potencial de los Web services, es integrar aplicaciones. Escenarios de integración generalmente se caracterizan por un bajo acoplamiento.
  • Descripción de las arquitecturas de los Web services Los elementos básicos de la arquitectura de los Web services son: El Web service provider, que es un nodo de red que realiza el hosting del Web service. El Web service consumer, que es un nodo de red que realiza el hosting de cualquier cliente que puede comunicarse usando HTTP. Los clientes incluyen browsers, aplicaciones de consola, y aplicaciones GUI. El Web service broker, que es un nodo de red que realiza el hosting de un registro global de Web services disponibles. Todos estos nodos de red, son capaces de comunicarse entre sí, típicamente mediante TCP/IP. El resto de este módulo se concentra en cómo los elementos de la arquitectura de los Web services se corresponden con los elementos de la arquitectura orientada a servicios. Web Services como implementación de la arquitectura orientada a servicios En una solución basada en Web services, los tres nodos de red definidos en la arquitectura orientada a servicios (SOA – Service Oriented Architecture) corresponden a los tres elementos de los Web services. El rol de service broker es implementado por un nodo que realiza el host del registro UDDI (Universal Description, Discovery and Integration). El rol de service provider es implementado por nodos que exponen Web services mediante páginas ASP.NET con extensión .asmx. El punto de entrada a los Web services implementados mediante ASP.NET, son las páginas Web con extensión .asmx. El rol de service consumers es implementado por cualquier nodo que pueda comunicarse mediante SOAP o HTTP, entender la interfase que el servicio expone y proveer las credenciales de autenticación necesarias.
  • El modelo de programación de los Web Services Para implementar o usar correctamente Web services, es importante conocer las características principales de su modelo de programación. Es importante entender también, algunas de las ramificaciones de este modelo. La primera característica del modelo es el protocolo de comunicación, normalmente HTTP. Sin embargo, HTTP no soporta intrínsicamente el modelo de invocación de métodos. Debido a esta restricción, los consumers generalmente usan SOAP XML sobre HTTP para invocar a los métodos de los Web services. Por esto es importante para el desarrollador, conocer cómo funcionan HTTP y SOAP. Muchos desarrolladores están familiarizados con el modelo statefull. En otras palabras, una instancia de la clase es creada y muchas operaciones son realizadas sobre la misma. Entre cada invocación a un método, el objeto mantiene el estado. En un ambiente stateless, el objeto no retiene el estado entre las llamadas. Cualquier información que deba mantenerse debe almacenarse en una cookie o en una base de datos. Los Web services no son objetos tradicionales. Cuando usa ASP.NET para implementar Web services, usted puede usar una clase C# para implementarlo. Esta clase es referenciada por una página ASP.NET con la extensión .asmx. Cuando la página es procesada, una instancia de esa clase es creada. El tiempo de vida de esta página se relaciona al tiempo de vida del objeto resultante, el cual es diferente en cada invocación a un método. Como resultado, las clases que implementan Web services son stateless. Si bien realizar aplicaciones stateless al principio es más complicado, los sistemas stateless pueden escalarse fácilmente. En una aplicación no distribuida, si alguno de los recursos de software requeridos, tales como DLL, está disponible cuando la aplicación se ejecuta, continuará estando disponible durante todo el tiempo de ejecución. Usualmente, continuará estando disponible para los futuros usos de la aplicación. Para las aplicaciones distribuidas, especialmente las que utilizan recursos a través de Internet, existe una mayor posibilidad de que los recursos no estén disponibles. Por ello, las aplicaciones implementadas usando Web services, deben ser más flexibles frente a la posibilidad de que los recursos no se encuentren disponibles, incluso en tiempo de ejecución. Como consecuencia, las soluciones basadas en Web services, deben tener bajo acoplamiento y de esta forma reconfigurarse dinámicamente si un recurso no está disponible. Las aplicaciones con bajo acoplamiento, adicionalmente tienen la ventaja de permitir failover debido a que los consumers no tienen afinidad con una instancia particular del Web service. El formato universal de datos usado en los Web services es XML. Las siguientes son algunas de las áreas donde XML es usada en los Web services: El protocolo SOAP está basado en XML. Las descripciones de los Web services son documentos XML. Los datos retornados por los Web services, son documentos XML. Los Web services son registrados en UDDI mediante documentos XML. Las aplicaciones ASP.NET son configuradas usando archivos XML.
  • Fundamentos de HTTP El HTTP es un protocolo estándar de la World Wide Web Consortium (W3C) para transmitir documentos en Internet. Los Web services usan HTTP para comunicación. Es un protocolo genérico, stateless, que puede ser usado para muchas tareas adicionales a su original hypertext.
  • Los métodos GET y POST Los métodos GET y POST del request, son ideales para comunicarse a un Web service. Estos métodos fueron realizados para enviar datos al Web server y obtener un recurso específico del mismo. Es posible realizar un modelo de llamadas a funciones al principio de estos métodos, que es exactamente lo que el modelo de Web services requiere. Considere el siguiente request HTTP-GET: GET /Trading/GetStockPrice.asp?Symbol=MSFT HTTP/1.1 Host: localhost La característica más importante del request es el querystring. El querystring es la porción del URI que sigue al signo de pregunta, y consiste en un conjunto de pares nombre/valor en el encoding URL. En el request HTTP-GET, típicamente no hay cuerpo de mensaje, sólo el response del request HTTP-GET y una respuesta estándar HTTP como se mostró anteriormente. Considere el siguiente request HTTP-POST: POST /Trading/GetStockPrice.asp HTTP/1.1 Host: localhost Content-Type: application/x-www-form-urlencoded Content-Length: 11 Symbol=MSFT En el código anterior, no hay querystring como parte del URI. Esto es porque la información del request está en el cuerpo del mensaje. Esta característica del HTTP-POST, lo hace conveniente para pasar grandes cantidades de datos al servidor, en contraste de los 1024 bytes de restricción del querystring.
  • Esencias del XML XML es usado para implementar Web services de varias formas. Esto incluye usar XML como formato entre el Web service consumer y el Web service, el uso de XML para describir la interfase del Web service, etc. Es recomendable que el desarrollador del Web services tenga un sólido conocimiento de XML. Esta lección se centra en describir los tipos de datos usados por el XML schema, y cómo controlar la serialización XML mediante el .NET Framework.
  • Descripción de XML Luego del prologo del documento, los documentos XML tienen elementos root y child. Cada uno de estos elementos puede tener atributos que proveen mayor información. Una confusión común es cuándo usar elementos y cuándo atributos. No existen reglas absolutas para esta elección. Sin embargo la siguiente tabla muestra algunas diferencias entre elementos y atributos: Característica Elementos Atributos Puede tener nodos child Sí No Están ordenados Sí No Pueden repetirse Sí No Pueden indexarse Sí No Pueden tener tipos Sí Sí Pueden tener valores por defecto No Sí Cuando se describen los datos que su Web service consume o retorna, es importante conocer las diferencias entre elementos y atributos para que usted pueda usarlos apropiadamente en sus documentos XML. Elementos y atributos Todos los documentos XML deben estar well-formed. Para que un documento esté well-formed, debe adherir a las siguientes reglas: Debe tener un solo elemento root. Los documentos XML son trees, y no forests. Todos los elementos deben cerrarse, contrariamente a HTML, donde muchos elementos (por ejemplo <BR>) no requieren cerrarse. Deben ser consistentes la apertura y cierre de los elementos en cuando a mayúsculas y minúsculas. Muchos browsers permiten inconsistencias en el HTML (por ejemplo <table> y </TABLE>), pero esto no está permitido en XML. Los elementos deben estar anidados correctamente. Los valores de atributos deben estar encerrados en comillas. Muchos browsers permiten valores de atributos sin comillas, pero entonces el documento XML no está well-formed. Un atributo no puede repetirse en el elemento. El resto de este tópico se focaliza en cómo XML es usado en los Web services. Para usar correctamente un Web service, usted debe conocer las operaciones que el mismo soporta y la estructura de los documentos (o mensajes) que cada operación consume o produce. Esta información está definida en un documento conocido como descripción del servicio, que describe al Web service. Este documento es creado usando Web Service Description Language (WSDL) que es un lenguaje basado en XML. Dentro de los documentos WSDL, se definen esquemas XML que describen los tipos de datos y las estructuras del documento. Los esquemas XSD validan a los documentos XML de forma mecánica. Esto libera al programador de errores en el parsing de estructuras complejas.
  • Serialización XML en el .NET Framework Cuando implementa Web services usando Visual Studio .NET y .NET Framework, es conveniente definir la interfase del servicio (los métodos que son expuestos) usando tipos nativos de .NET. El formato nativo de serialización de los objetos .NET es XML. Sin embargo, en ocasiones el maping por defecto de los objetos a elementos, no es el requerido por usted. En este caso usted debe indicar al serializador, cómo convertir el gráfico de objetos en un documento XML con la estructura requerida. El namespace System.Xml.Serialization en el .NET Framework, provee clases que usted puede usar para modificar la forma en que los objetos son serializados. Cuando implemente un Web service mediante ASP.NET, generalmente no manipulará la serialización de los objetos directamente. En su lugar, utilizará las clases atributo que se encuentran en System.Xml.Serialization para controlar la serialización. Considere el siguiente ejemplo: 1. <XmlRoot("account")> _ 2. Public Class Acct 3. <XmlElement("description")> Public Description As String 4. <XmlElement("number")> Public Number As String 5. <XmlElement("type")> Public Type As String 6. <XmlElement("balance")> Public Balance As Decimal 7. <XmlAttributeAttribute("status")> Public Status As String 8. End Class 'Acct 9. ... 10. 11. Public Function GetAllAccounts() As _ 12. <XmlArray("AccountList"), XmlArrayItem("Account")> Acct() ... Las clases atributo usadas en el código anterior, son explicadas en los siguientes párrafos. En el .NET Framework, las clases atributo tienen el formato XXXXAttribute. Sin embargo al usar los compiladores .NET, no es necesario que los desarrolladores agreguen el sufijo Attribute en el código. Cada documento XML debe tener un único elemento root. El atributo XmlRoot permite que usted controle qué root debe generarse. Por ejemplo, usted puede indicar el nombre del elemento mediante la propiedad ElementName . Sólo puede aplicar el atributo XmlRoot a las clases. Usted puede aplicar el atributo XmlElement a campos o propiedades públicas para controlar las características del elemento XML, tales como nombre y namespace. Si aplica XmlElement a un campo o propiedad que retorne un array, los items son generados como una secuencia de elementos XML. Si usted no aplica XmlElement a ese campo o propiedad, los ítems del array son generados como secuencias de elementos child, anidados bajo el elemento que es nombrado luego del campo o propiedad. Por defecto, el serializador XML serializa los campos y propiedades públicas como elementos XML. Cuando usted aplica el atributo XmlAttribute a un campo o propiedad pública, el serializador lo serializa como un atributo XML. Los atributos sólo pueden ser tipos simples. Por ello solo puede aplicar el atributo XmlAttribute a tipos primitivos. Serialización de Arrays Cuando usted aplica el atributo XmlArray a miembros de una clase, el serializador XML genera una secuencia anidada de elementos XML. Por ejemplo, si aplica XmlArray a un miembro público que devuelve un array de las cuentas de un usuario. Por defecto el nombre del elemento XML es el del miembro publico, sin embargo usted puede indicarlo mediante la propiedad ElementName del atributo XmlArray . Para un control más preciso del XML resultante, puede usar la clase XmlArrayItem . Esto le permite asegurarse que los arrays que contienen objetos derivados del tipo base array, sean serializados correctamente. Por ejemplo, suponga que la clase acct existe, así como también las clases chekingAcct y savingAcct que derivan de acct . Luego suponga que la clase bankCustomer , tiene un miembro público que retorna un array de objetos account . Para permitir que la clase XmlSerializer serialice ambas clases chekingAcct y savingAcct , debe aplicar XmlArrayItem dos veces, una por cada tipo aceptado. Conceptos generales En el contexto de XML, el .NET Framework y los Web services, existen algunos conceptos que debe tener presente. Uso de POST/GET versus SOAP Actualmente, cuando usa [ return:XmlArrayItem ]; el nombre del ítem del array es modificado cuando usa SOAP, pero no cuando usa GET o POST. Entonces, el XML resultante será diferente dependiendo de si el consumer usa POST/GET o HTTP. El siguiente código muestra cómo controlar los nombres de los elementos XML cuando se serializa un array: Public Function GetAllAccounts() As _ <XmlArrayItem(ElementName:="savingsAcct", _ Type:=GetType(SavingsAcct)), _ XmlArrayItem(ElementName:="creditCardAcct", _ Type:=GetType(CreditCardAcct))> Acct() Serialización de propiedades Cuando un objeto es serializado, sólo las propiedades públicas de lectura/escritura son serializadas. En otras palabras, no existe forma de serializar una propiedad de solo lectura.
  • Fundamentos de SOAP Simple Object Access Protocol (SOAP) es un protocolo para intercambiar información en ambientes distribuidos y descentralizados. Es un protocolo basado en XML que consiste en dos partes: Un envelope para manejar la extensibilidad y modularidad. Un mecanismo de encoding para representar tipos dentro del envelope. Usted puede usar SOAP en combinación con muchos otros protocolos. Sin embargo, el único protocolo actualmente definido es HTTP y HTTP Extension Framework (HTTP-EF).
  • Descripción de SOAP Intercambiar mensajes SOAP provee una forma ampliamente aceptada para comunicar Web services. Sin embargo, antes de que implemente y use Web services que se comunican mediante SOAP, es importante que entienda la estructura del mensaje SOAP y la operación básica del protocolo. Los mensajes SOAP son una transmisión unilateral del sender hacia el receiver. SOAP no define ninguna semántica de aplicación tales como modelo de programación o semántica de implementación. Sin embargo, los Web services requieren el modelo request/response. La solución es mandar el mensaje SOAP en el body del request y del response HTTP. Esta solución provee del modelo requerido por los Web services. Usted puede optimizar las implementaciones de SOAP, explotando las características únicas de los sistemas de red. Por ejemplo, HTTP permite que el mensaje SOAP sea enviado dentro del request y la respuesta SOAP dentro del response, todo usando la misma conexión creada por el request. SOAP consiste en cuatro partes: El envelope SOAP, que define qué hay en el mensaje, quién puede procesar el mensaje, y cuándo el mensaje es opcional o no. Las reglas de encoding SOAP, que definen el mecanismo de serialización para intercambiar instancias de tipos de datos definidos en la aplicación. La representación SOAP RPC, que define la convención para representar remote procedure calls y responses. El protocol bindings, que describe cómo usar SOAP en HTTP ya sea con o sin HTTP-EF. Como desarrollador, usted debe estar familiarizado con los detalles del SOAP envelope. Sin embargo puede ignorar los detalles del encoding y del RPC debido a que el .NET Framework administra estos detalles.
  • Documentos WSDL Para usar o consumir un Web service, usted primero debe entender cómo interactuar con él. WSDL es usado para describir un Web service en los términos de mensajes que recibe y envía. En otras palabras, el archivo XML WSDL, actúa como contrato entre el Web service consumer (el cliente) y el Web service. En el documento WSDL, usted provee definiciones abstractas de los tipos que son usados en las operaciones y los documentos que son intercambiados en cada operación. WSDL puede describir endpoints y sus operaciones, sin especificar el formato del mensaje o los protocolos de red a los cuales el endpoint está asociado. La única asociación de protocolo que es analizada en esta sección es SOAP 1.1 y HTTP-GET/POST. Como Web service consumer, es importante que usted esté familiarizado con WSDL para entender el contrato definido en el documento WSDL. Adicionalmente, cuando usted implemente un Web service, tal vez no use una herramienta que genere automáticamente el archivo WSDL. En su lugar, usted puede elegir generar el archivo WSDL por defecto, y luego realizarle algunas modificaciones. Nuevamente, para esta tarea, necesita entender WSDL. Qué es WSDL El documento WSDL es una lista de definiciones. En el archivo WSDL, el elemento root es llamado definitions . Este elemento contiene cinco elementos child primarios que son usados para definir el Web service. Los siguientes cinco elementos aparecen dentro del elemento definitions en el archivo WSDL, en el orden especificado: El elemento types define los tipos de datos que son usados para intercambiar mensajes. El elemento message describe el mensaje a comunicar. El elemento portType identifica un conjunto de operaciones y los mensajes relacionados a las mismas. El elemento binding específica los detalles del protocolo para las operaciones del servicio y describe cómo trasladar el contenido abstracto de esos mensajes a un formato concreto. El elemento service agrupa un conjunto de puertos. El siguiente ejemplo describe un Web service para el cual se desea crear un archivo WSDL. <XmlRoot("account")> _ Public Class Acct <XmlElement("description")> Public Description As String <XmlElement("number")> Public Number As String <XmlElement("type")> Public Type As String <XmlElement("balance")> Public Balance As Decimal <XmlAttribute("status")> Public Status As String End Class 'Acct Public Class TheBank <WebMethod()> _ Public Function GetAccount(acctNumber As String) As Acct Dim a As New Acct() a.Description = "Adam's savings acct" a.Balance = 10000D a.Number = "1234-XX" a.Status = "active" a.Type = "SV" Return a End Function 'GetAccount End Class 'TheBank Ahora veremos cómo definir un documento WSDL que describa el Web service de ejemplo anterior. Primero, usted define los tipos que son usados en el intercambio de los mensajes. El parámetro acctNumber es definido de la siguiente forma: ... <types> ... <s:complexType> <s:sequence> <s:element minOccurs="1" maxOccurs="1" name="acctNumber" nillable="true" type="s:string" /> </s:sequence> </s:complexType> ... </types> La definición de tipo de la clase Acct , que retorna el método GetAccount , es un poco más compleja que la definición anterior. La definición de tipo para esta clase podría ser la siguiente: <s:complexType name="Acct"> <s:sequence> <s:element minOccurs="1" maxOccurs="1" name="description" type="s:string" /> <s:element minOccurs="1" maxOccurs="1" name="number" type="s:string" /> <s:element minOccurs="1" maxOccurs="1" name="type" type="s:string" /> <s:element minOccurs="1" maxOccurs="1" name="balance" type="s:decimal" /> </s:sequence> <s:attribute name="status" type="s:string" /> </s:complexType> La definición de tipo anterior representa un documento XML con la siguiente estructura: <?xml version="1.0" encoding="utf-8"?> <account status="active"> <description>Adam's savings acct</description> <number>1234-XX</number> <type>SV</type> <balance>10000</balance> </account> Luego, debemos definir la estructura de los mensajes que son intercambiados. En este ejemplo, el nombre del método es GetAccount y usamos la siguiente convención de nombres: El mensaje entrante tiene le mismo nombre que el método. El mensaje saliente tiene el nombre del método más la palabra Response. Una forma de crear la definición del mensaje es la siguiente: <s:element name="GetAccount"> <s:complexType> <s:sequence> <s:element minOccurs="1" maxOccurs="1" name="acctNumber" nillable="true" type="s:string" /> </s:sequence> </s:complexType> </s:element> <s:element name="GetAccountResponse"> <s:complexType> <s:sequence> <s:element minOccurs="1" maxOccurs="1" name="account" type="s0:Acct" /> </s:sequence> </s:complexType> </s:element> Todas estas definiciones están anidadas dentro del elemento types . Además de definir los tipos de datos que son pasados a y desde los Web services cuando se invoca a sus métodos, adicionalmente debe definirse los mensajes de request y response. Debido a que los mensajes son independientes del protocolo, usted puede usar mensajes con HTTP-GET/POST, SOAP, o cualquier otro protocolo que el Web service provider soporte. Si usa SOAP, el elemento message no incluye los elementos Envelope y Fault . Puede darle nombres convenientes a los mensajes, debido a que WSDL no define una convención de nombres para los mismos. El elemento message contiene cero o más elementos child llamados part . El mensaje de request contiene todos los parámetros in e inout, y el mensaje de response contiene todos los parámetros out e inout, y el valor de retorno. Cada elemento part debe tener un nombre y tipo de dato que usted puede asociar con los tipos de datos definidos en la implementación del servicio. Para continuar con el ejemplo anterior, usted puede definir los mensajes request y response como sigue: <message name="GetAccountIn"> <part name="parameters" element="s0:GetAccount" /> </message> <message name="GetAccountOut"> <part name="parameters" element="s0:GetAccountResponse" /> </message> En el código anterior, los valores de atributo s0:GetAccount y s0:GetAccountResponse se refieren a los tipos definidos en el elemento types . Un Web service provider (un nodo de red que es un Web server) puede exponer múltiples Web services. Un único Web service puede soportar invocación a sus métodos mediante varios protocolos. El formato de los datos que son intercambiados entre el Web service consumer y el Web service, puede depender del protocolo usado para invocar a los métodos del Web service. Por esto, debe existir una forma de asociar las operaciones a los endpoints desde los cuáles se pueden acceder. Usted puede realizar este tipo de asociación mediante el elemento portType . El siguiente código XML muestra la operación GetAccount y el portType con el cual está asociada: <portType name="BankService"> <operation name="GetAccount"> <input message="s0:GetAccountIn" /> <output message="s0:GetAccountOut" /> </operation> </portType> En el ejemplo anterior, los elementos input y output indican los nombres de los mensajes de request y response. Luego de definir el puerto lógico, debe definir cómo el Web service consumer puede conectarse al puerto en el cual la operación GetAccount está disponible. Esto significa asociar la operación con el protocolo y especificar información específica del protocolo para realizar la asociación. Para realizar esto, debe usar el elemento binding . El siguiente código XML, muestra una definición de conexión SOAP para la operación GetAccount : <binding name="BankService" type="s0:BankService"> <soap:binding transport =! "http://schemas.xmlsoap.org/soap/http" style="document" /> <operation name="GetAccount">b <soap:operation soapAction = ! "http://woodgrovebank.com/GetAccount" style="document" /> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal" /> </output> </operation> </binding> El ejemplo anterior permite realizar una conexión usando SOAP. Provee información para el SOAPAction header. Adicionalmente indica que el encoding del documento es document y no rpc , y que el parámetro encoding style es literal y no encoded . Usted puede darle al binding, cualquier nombre que crea conveniente. Todo lo que resta para crear el archivo WSDL es definir el endpoint para cada uno de los protocolos que pueden usarse para acceder al Web service. Para definir los endpoints, usará el elemento service . El siguiente código XML define un servicio bancario y especifica los puertos que pueden usarse para acceder a las operaciones del servicio: <service name="BankService"> <port name="BankService" binding="s0:BankService"> <soap:address location =! "http://localhost/woodgrove/Bank.asmx" /> </port> </service>
  • Web Service Discovery En el tópico anterior, usted vio cómo escribir documentos WSDL. Debido a que el documento WSDL indica el formato de los mensajes que el Web service intercambia con el consumer, usted debe implementar el consumer de acuerdo con lo indicado en este documento. Si usted aún no posee el documento, debe poder localizarlo. El proceso mediante el cual usted localiza un Web service y sus descripciones, y cómo interactuar con él, es conocido como Web service discovery. En esta sección, usted aprenderá cómo localizar documentos WSDL.
  • Introduciendo Disco No es común que un Web service provider publique la descripción de todos sus Web services mediante un Web service broker. Sin embargo, los desarrolladores del Web service consumer, deben poder descubrir la descripción de los servicios. Disco es un mecanismo para enumerar los Web services disponibles en un endpoint determinado y localizar los contratos de estos Web services. Disco es una solución propietaria de Microsoft al problema estático de discovery. En el futuro se proveerá una solución estándar de la industria. Un Web server que provea acceso a los Web services no es requerido para soportar discovery. Otro servidor puede ser el responsable de proveer los contratos o el Web service puede haber sido creado para uso privado únicamente y no necesita un mecanismo de discovery. El Web service provider puede mantener disponible información de discovery para los desarrolladores de los Web service consumers. Puede hacer esto estática o dinámicamente generando un documento que contenga un link al documento WSDL para todos los Web services que el provider posea. El discovery estático es posible cuando la ubicación del documento discovery (generalmente con extensión .disco) ya se conoce. El discovery estático significa obtener el documento de discovery e interpretar sus contenidos.
  • El rol del Web service broker es esencial en la arquitectura de los Web services para permitir a los potenciales clientes descubrir fácilmente un Web service. Los registros UDDI cumplen el rol de Web service broker. En esta sección, usted aprenderá acerca de UDDI y las especificaciones asociadas. Qué es UDDI? Antes de aprender cómo publicar y descubrir programáticamente Web services, es importante entender las funciones de UDDI desde el punto de vista del programador. UDDI es una colección de especificaciones para distribuir información basada en Web, de los Web services. Estas especificaciones están separadas en varias categorías. Las especificaciones UDDI Programmers API Specification y UDDI Data Structure Specification son de especial interés para el desarrollador. Toda la información referente a estas dos especificaciones se basa en la versión 2.0. La UDDI Programmers API Specification define funciones que proveen un modelo simple de request/response para acceder a los registros UDDI. Existen dos tipos de API definidas en la referencia API: La API publishers que permite publicar datos en el registro. La API inquiry que permite leer información del registro. La Programmers API Specification define aproximadamente 40 mensajes SOAP que son usados para obtener información y publicar funciones en el registro UDDI. La UDDI Data Structure Specification contiene el detalle de cada una de las estructuras XML asociadas a los mensajes de la Programmers API Specification. UDDI es también un conjunto de implementaciones de especificaciones que permiten a los negocios registrar información acerca de los Web services que ellos ofrecen para que otros negocios puedan encontrarlas. Estas implementaciones son accesibles públicamente. Adicionalmente, los registros UDDI están disponibles a sí mismos como Web services. Porqué usar UDDI? UDDI genera transacciones permitiendo a las compañías encontrarse unas con otras en la Web y comunicar sus sistemas para e-commerce. UDDI es comúnmente comparado con las páginas blancas y amarillas del la guía telefónica debido a que permite a los negocios listarse a sí mismos por nombre, producto, ubicación, o los Web services que ellos ofrecen. Mediante la registración de los productos de su compañía en el registro UDDI, usted puede: Describir y listar las bases para que sus partners de negocios interactúen con usted. Hacer visible su compañía y accesible a búsquedas de potenciales compradores y marketplaces alrededor del mundo. Hacer la integración de los negocios significativamente más fácil y más dinámica para las compañías que decidan realizar transacciones con usted. UDDI puede proveer respuestas a preguntas tales como: ¿Qué Web service provee un negocio específico? ¿Cuales son todas las ubicaciones de un Web service específico? ¿Cuál es la información de binding actual (tal como protocolos soportados) para una ubicación específica de un Web service? Otras posibles consultas, tales como comparación de precios de Web services, o proximidad geográfica, no son parte de la especificación UDDI. Actualmente, tales consultas adicionales y metadatos asociados, son considerados valores agregados que los vendors ofrecen e implementan
  • Creando un proyecto Web service En esta sección, verá cómo crear Web services. Examinando las partes de un proyecto Web service Los ASP.NET Web services, son aplicaciones ASP.NET, por esto, hay muchos elementos en común entre ambos. Este tópico examina varias partes de los proyectos ASP.NET Web services. Por defecto, un conjunto de referencias a namespaces son incluidas en el proyecto base. Este conjunto incluye System , System.Data , System.Web , System.Web.Services , y System.XML . El namespace System contiene clases que definen valores y tipos de datos comúnmente usados, eventos y event-handlers, interfases, atributos y procesamiento de excepciones. El namespace System.Data consiste principalmente, en clases que conforman la arquitectura ADO.NET. La clase DataSet juega un rol central en esta arquitectura. El DataSet es un cache en memoria de datos obtenidos de muchos posibles orígenes, tales como bases de datos o documentos XML. El DataSet puede leer y escribir datos como documentos XML. En formato XML, cualquier aplicación puede usar DataSets sobre cualquier plataforma que soporte XML. El namespace System.Web , provee clases e interfases que facilitan la comunicación entre el browser y el servidor. Este namespace incluye las clases HttpRequest y HttpResponse . System.Web adicionalmente provee clases para el manejo de cookies, transferencia de archivos, información de excepciones y control para el output cache. System.Web.Services consiste en clases que ayudan a construir y usar Web services. Una de las clases más importantes es la clase WebService . Si el Web service necesita acceder a recursos intrínsicos de ASP.NET, entonces la clase que implementa las operaciones del Web service debe heredar de WebService . System.XML expone clases XML que proveen soporte estándar para procesar XML. Usted puede encontrar las clases que encapsulan el soporte a SOAP en el namespace System.Web.Services.Protocols . El archivo .asmx es el front-end del Web service implementado mediante ASP.NET. La forma a la que acceda a este archivo mediante HTTP, determina el tipo de respuesta que generará. Por defecto, el archivo .asmx contiene una clase similar al siguiente ejemplo: public class Service : System.Web.Services.WebService La clase contiene la implementación de un WebMethod similar al siguiente: [WebMethod] public string HelloWorld() { return "Hello World"; } Cuando usted realiza un request a un archivo .asmx desde un browser sin indicar query string, el archivo resultante es una página generada automáticamente que actúa de ayuda del Web service. Si realiza un pedido HTTP-GET sin indicar query string, el resultado será el mismo. La página de ayuda enumera todos los métodos disponibles en el Web service. Contiene links a cada uno de estos métodos que abren la página de ayuda individual de cada uno. Adicionalmente contiene un link al documento que describe al Web service. Para acceder a la página de ayuda del Web service, navegue a la URL base del Web service desde el browser. Use el siguiente formato: http:// servername / projectname / webservicename .asmx La siguiente tabla describe las partes de la URL anterior: Servername: El server en el cual el Web service reside. Projectname: El nombre del proyecto del Web service y cualquier información adicional necesaria para el acceso. Webservicename.asmx: El nombre del archivo .asmx del Web service. La página de ayuda de los métodos del Web service, provee información adicional referente a cada método particular. La página permite adicionalmente, invocar al método siempre que el mismo permita la invocación mediante HTTP-POST. Ejemplos de mensajes de request y response son mostrados al final de la página de ayuda. La descripción del Web service, es un documento WSDL. La página de ayuda del Web service provee un link a este documento. Adicionalmente puede acceder a la descripción mediante el browser indicando la URL del Web service más el query string WSDL como se muestra en el siguiente ejemplo: http:// servername / projectname / webservicename .asmx?WSDL Adicionalmente al conjunto de referencias y al archivo .asmx, el proyecto cuenta con otras entradas. Global.asax El archivo Global.asax es un archivo opcional que contiene el código para responder a los eventos a nivel de aplicación, ejecutados por ASP.NET o la clase HttpModule . Este archivo reside en el directorio root de la aplicación ASP.NET. En tiempo de ejecución, se realiza el parse y la compilación del Global.asax en una clase .NET que hereda de HttpApplication . El Global.asax se configura a sí mismo para ignorar cualquier request directo a su URL. Por esto, usuarios externos no pueden acceder a este archivo. Cuando usted guarda los cambios en el Global.asax, el ASP.NET detecta que el archivo ha cambiado, completa todos los request pendientes, ejecuta el evento Application_OnEnd para cualquier listener activo, y reinicia el application domain. Esta secuencia de acciones reinicia la aplicación, cierra las sesiones del browser y elimina toda información de estado existente de la memoria. Cuando llega un nuevo request desde el browser, el ASP.NET realiza el parse, recompila nuevamente el Global.asax, y ejecuta el evento Application_OnStart . Web.config Es necesario para los desarrolladores poder incluir variables de configuración fuera del código de la aplicación para modificarlos sin volver a compilar el código. Para ello existe el archivo Web.config. La siguiente lista incluye las características del Web.config: Es un archivo XML. Usted puede usar cualquier editor estándar o un parser XML para crear y editar este archivo. Aplica configuraciones para el directorio en el cual se encuentra y todos los sub-directorios. Si existiese un archivo de configuración en un sub-directorio, heredaría y sobre-escribiría los valores del parent. Existe un archivo de configuración ASP.NET principal para todo el Web server llamado Machine.config el cual se encuentra en C:\\WINNT\\Microsoft.NET\\Framework\\ version \\CONFIG. En tiempo de ejecución, ASP.NET computa el Web.config para conocer los valores de configuración de la aplicación. Estos valores se ingresan en cache para los request subsiguientes. ASP.NET detecta cambios en el Web.config y automáticamente los aplica a los recursos afectados. El servidor no necesita reiniciarse para aplicar los nuevos cambios. El Web.config es extensible. Usted puede definir nuevos parámetros de configuración y escribir configuration handlers para procesarlos. ASP.NET protege al Web.config de accesos externos configurando Internet Information Services (IIS) para denegar el acceso a los archivos de configuración desde el browser. Se devuelve el error de acceso HTTP número 403 (forbidden) cuando se intenta acceder directamente.
  • Implementando métodos en los Web Services Luego de crear el proyecto Web service, el siguiente paso es definir sus operaciones. En esta sección, aprenderá a exponer métodos como operaciones del Web service, a controlar la serialización de los mismos y finalmente a implementar diferentes tipos de parámetros en las operaciones. Exponer métodos en el Web service Se exponen los métodos del Web service, agregando el atributo WebMethod a los métodos. Para exponer un método debe indicar que el método es público y agregar el atributo WebMethod : [WebMethod] public Account GetAccount( int AccountId ) { … }
  • Usted puede configurar propiedades del atributo WebMethod para determinar el comportamiento del método del Web service. El atributo WebMethod contiene las siguientes propiedades: BufferResponse CacheDuration Description EnableSession MessageName La propiedad BufferResponse activa el buffering de las respuestas del método. Cuando está en true , el valor por defecto, ASP.NET carga en el buffer la respuesta entera del método antes de generar el response. El buffer aumenta la velocidad minimizando la comunicación entre el IIS process y el worker process. Cuando el valor es false , ASP.NET realiza el buffer de la respuesta en bloques de 16KB. Si el método devuelve una gran cantidad de datos provenientes por ejemplo de una base de datos, y usted no quiere esperar a enviar el primer registro recién cuando ya se disponga del último, entonces esta propiedad debería tener el valor false. Usted puede indicar el valor de esta propiedad en el atributo WebMethod como se muestra en el siguiente ejemplo: WebMethod(BufferResponse := false) La propiedad CacheDuration activa el cache de los resultados del método. Esto es conocido como output caching. El valor de esta propiedad indica el tiempo de duración (en segundos) para el cual ASP.NET debe realizar el cache del response. El valor por defecto, que es cero, desactiva el cache. La propiedad Description provee una descripción del método que aparecerá en la página de help del Web service. El valor por defecto es un string vacío. La propiedad EnableSession permite activar el session state para el método. Si un método soporta session state, puede acceder a la session mediante la propiedad HttpContext.Current.Session o mediante la propiedad WebService.Session si el método hereda de la clase WebService . El valor por defecto es false . La propiedad MessageName permite indicar alias a los métodos sobrecargados. El valor por defecto es el nombre del método. Si usted cambia esta propiedad, el mensaje SOAP reflejará el cambio. La propiedad TransactionOption permite que el método participe como creador de una transacción Microsoft Distributed Transaction Coordinator (MS DTC). El método sólo posee dos comportamientos, los cuales pueden ser establecidos mediante los valores de la enumeración System.EnterpriseServices.TransactionOption : El método no soporta transacciones ( Disabled , NotSupported , Supported ) El método inicia una nueva transacción ( Required , RequiresNew ) El valor por defecto es Disabled . Antes de usar esta propiedad, deberá agregar una referencia a EnterpriseServices.dll en su proyecto. Este assembly contiene el namespace System.EnterpriseServices , el cual posee métodos y propiedades que exponen el modelo de transacciones distribuidas de los servicios de Microsoft Component Object Model (COM+). La clase System.EnterpriseServices.ContextUtil , permite votar a favor o en contra de la transacción mediante SetAbort y SetComplete .
  • Autenticación vs. Autorización Antes de que usted pueda asegurar los Web services, debe comprender las diferencias entre autenticación y autorización. Autenticación es el proceso de descubrimiento y verificación de la identidad del usuario examinando sus credenciales, y luego validando esas credenciales con alguna autoridad de autenticación. Actualmente las aplicaciones usan una variedad de mecanismos de autenticación, y usted puede usar algunos de ellos con la seguridad basada en roles de Microsoft .NET Framework. Ejemplos de mecanismos comúnmente usados son los mecanismos de autenticación del sistema operativo (NTLM o Kerberos), Microsoft Passport, y mecanismos a nivel de aplicación. Autorización es el proceso de determinar cuándo y dónde el usuario tiene permitido realizar una operación. La autorización ocurre luego de la autenticación y utiliza la información de identidad del usuario y rol para determinar los recursos a los cuales tiene acceso. Usted puede usar el .NET Framework para implementar autorización .
  • Tipos de autenticación El primer paso al implementar seguridad en cualquier aplicación es autenticar a los usuarios. Implementando un robusto mecanismo de autenticación no es fácil, pero es posible. Es recomendable que usted utilice los servicios de autenticación de la plataforma. En este caso la plataforma es el sistema operativo Windows, el IIS, el .NET Framework y el CLR. IIS ofrece los siguientes tres mecanismos de autenticación: Basic Digest Integrated Windows Usted podrá aprender los detalles de estos mecanismos de autenticación y cómo usarlos para asegurar un Web service, más adelante en este curso. ASP.NET soporta autenticación mediante Forms La autenticación Forms es un mecanismo con el cual los request no autenticados son redireccionados a un formulario HTML mediante redirección http del lado del cliente. El usuario provee credenciales en el formulario y luego realiza el submit del mismo. Si la aplicación Web autentica las credenciales del usuario, las envía en un form al cliente para que los próximos request utilicen este form en los headers del request. El handler ASP.NET autentica y autoriza estos requests usando el método de autenticación que la aplicación indique. Debido a que no es recomendable usar la autenticación Forms con los Web services, este módulo no lo cubre en detalle. Tal vez sea posible usar Passport en los Web services en un futuro cercano. Si usted no desea usar mecanismos de autenticación built-in, entonces puede implementar autenticación personalizada. Usted debe pasar las credenciales del usuario en los parámetros de cada llamada a un método del Web service. En esta situación, usted necesita otra forma de pasar las credenciales. Los SOAP headers son una alternativa válida para realizar esta tarea. El Web service consumer puede agregar las credenciales del usuario en el SOAP header. El Web service entonces podrá obtener la información y realizar los mecanismos de autenticación personalizados.
  • Tipos de autorización ASP.NET, el .NET Framework y la plataforma Windows, proveen varias técnicas para autorizar el acceso a un recurso del sistema. Los recursos a los cuales se tiene acceso son la intersección de los recursos autorizados a: El usuario mediante el sistema de seguridad de Windows NT. El assembly mediante la seguridad de acceso del código. Opcionalmente, los roles del usuario mediante la seguridad basada en roles. El fólder que contiene el root de la aplicación ASP.NET es el root del namespace URI. Usted puede configurar la aplicación ASP.NET para restringir el acceso al namespace URI de la aplicación basándose en la identidad del usuario o del rol. Por ejemplo, usted puede restringir el acceso a los subfolders de la aplicación. Analizaremos ahora, cada una de estas técnicas de seguridad en mayor detalle. Windows NT provee características de seguridad basadas en la identidad del usuario que previenen el acceso no autorizado a los recursos del sistema. Estas características son autenticación de usuario y control de acceso basado en objetos. Es importante notar que con seguridad Windows, luego de que el usuario es autenticado, la mayoría del código que el usuario ejecuta, tiene acceso a todos los recursos sobre los cuales el usuario tiene acceso. Los administradores de Windows pueden crear listas de control de acceso discrecionales (DACL) que controlan el acceso a los recursos u objetos de la red. Los administradores pueden asignar DALCs para permitir a usuarios y grupos el acceso a los objetos tales como archivos, impresoras o servicios. La seguridad basada en roles es un sistema especial donde la identidad del usuario no es importante. Lo importante son los roles lógicos que el usuario puede asumir. La seguridad basada en roles usa los roles asociados a los usuarios para tomar decisiones acerca de la autorización. La seguridad de acceso del código es un mecanismo que usted puede usar para prevenir que el código acceda a recursos protegidos. Tal como la seguridad de roles, la seguridad de código requiere que previamente el usuario sea autenticado.
  • Limitaciones de los Web services El desarrollo de Web services consiste en las siguientes tres etapas: Etapa 1: Integración de aplicaciones empresariales Las organizaciones inicialmente usan Web services para integrar aplicaciones internas. Los Web services les permiten exponer aplicaciones legacy hacia aplicaciones de negocios en ambientes heterogéneos sin necesidad de reescribir mucho código. Etapa 2: Interoperabilidad con Partners El siguiente paso para muchas organizaciones es integrar uno o dos partners fuera de la organización. Etapa 3: Interoperabilidad a través de muchas organizaciones A medida que los Web services se vuelven más globales y sofisticados, es importante proveer capacidades adicionales para disponibilidad, seguridad y estabilidad. Las etapas 1 y 2 existen actualmente, pero la etapa 3 depende de las tecnologías y especificaciones que están emergiendo. Actualmente, la falta de especificaciones ampliamente adoptadas sobre seguridad, routing, y otras capacidades, limita la integración de las aplicaciones entre las organizaciones. Por ejemplo, si usted diseña un Web service que envía el nombre de usuario y contraseña encriptados mediante un algoritmo personalizado en el header del mensaje SOAP, necesitará que los clientes posean el assembly correspondiente para encriptar dicha información. Si bien esto es posible, usted está pidiendo que cada uno de sus clientes instale ese assembly en sus equipos. Claramente esta no es la mejor opción en cuando a seguridad y negocio. A medida que los Web services se vuelven mas complejos, los desarrolladores requieren capacidades avanzadas que los estándares base no soportan. Estas capacidades incluyen: Seguridad. Arquitectura de seguridad para implementar a través de organizaciones. Routing. Habilidad para configurar en path del mensaje, incluso dinámicamente para asegurar escalabilidad y tolerancia a fallos. Mensajería confiable. Seguridad de que el mensaje se entregó, a través de diferentes escenarios. Transacciones. Servicios de compensación de transacciones para ejecutar transacciones entre las organizaciones. Actualmente, en ausencia de estándares para estas capacidades, los desarrolladores deben implementar soluciones específicas que incurren en gran cantidad de tiempo y costos.
  • Descripción de la arquitectura GXA La familia de protocolos GXA se basa en un conjunto de principios de diseño compartidos. Estos principios actúan como directrices para todos los protocolos GXA y tienen influencia tanto en su diseño como en su aplicación. Estos principios incluyen: Descentralización y federación Un aspecto fundamental en todo el desarrollo de Web services es el concepto de acuerdo obligado. El hecho de que dos partes deben ponerse de acuerdo únicamente en la sintaxis y semántica de los mensajes es lo que hace tan atractivos a los Web services. Las dos partes son libres de discrepar vehementemente respecto al lenguaje de programación, sistema operativo, máquinas virtuales o bases de datos, siempre que puedan llegar a un acuerdo sobre qué mensajes serán intercambiados. Los protocolos GXA han sido diseñados teniendo presente el acuerdo obligado. Concretamente, las piezas del núcleo de la infraestructura de GXA (routing, seguridad) asumen que es poco viable introducir una autoridad centralizada. Por ello, la presencia de una autoridad centralizada se considera una excepción más que una regla; por defecto, se asume la descentralización. Para permitir que esta aproximación descentralizada funcione sin el consiguiente caos, GXA se construye sobre la naturaleza jerárquica del mecanismo URI para actuar como un "federador" de organizaciones dispares y autónomas. Esta aproximación se beneficia del espacio de nombres existente en el que se basan Internet y XML, y puede observarse en la arquitectura de routing de GXA y en su marco de trabajo de políticas. Modularidad Una clave del éxito de SOAP ha sido su modularidad. En vez de intentar especificar una pila de protocolos completa, SOAP se ha forjado un pequeño pero importante nicho (procesamiento de mensajes XML). Esta modularidad estaba implícita en el diseño de SOAP, y se hizo explícita en SOAP/1.1. La modularidad de SOAP ha permitido adaptarlo a protocolos de transporte arbitrarios (por ejemplo, TCP, HTTP, SMTP), algunos de los cuales no existían durante la fase de diseño de SOAP (por ejemplo, BEEP, Jabber). GXA se construye sobre el modelo de extensibilidad de SOAP. Por ello, GXA se beneficia totalmente del modelo de procesamiento de mensajes de SOAP, incluyendo el soporte para mensajes multi-actor y los intermediarios SOAP. En lugar de intentar "hervir el océano", las especificaciones GXA individuales suelen ser breves y concisas, proporcionando una solución concreta y específica al espacio del problema relacionado. La naturaleza de concreción de los protocolos GXA les permite ser utilizados como bloques de construcción de protocolos. Esta capacidad de composición nos permite combinar protocolos GXA ubicuos (por ejemplo, WS-Security, WS-Routing) en un único mensaje. A diferencia de protocolos largos y monolíticos, GXA puede ser adoptado gradualmente, o en bloque. Si nuestra aplicación no necesita un protocolo GXA particular, es razonable no utilizarlo aunque sí utilicemos otras partes de la arquitectura. La inherente modularidad y capacidad de composición de GXA puede hacerse manejable mediante el uso de formatos de metadatos extendidos, que expresan las capacidades y requerimientos de un Web service determinado. En conjunto, estas capacidades y requisitos son a los que hacen referencia las políticas. La especificación WS-Policy mencionada en la guía de seguridad en Web services de IBM/Microsoft Security in a Web Services World: A Proposed Architecture and Roadmap , es un ejemplo de metadatos orientados a políticas. Permitiendo especificar varios aspectos de la transferencia de mensajes mediante políticas, las aplicaciones pueden "enlazarse tardíamente" (late-bind) contra un Web service. Este acoplamiento débil se consigue mediante la intersección de políticas, en las que los requerimientos y capacidades de cada parte se utilizan para encontrar una base común con la que todas las partes puedan convivir. Una "prueba existencial" de la capacidad de composición de los protocolos GXA es que varios protocolos GXA pueden componerse entre sí. Por ejemplo, cuando se recibe la actualización de una política de routing WS-Referral, ¿cómo sabe el receptor si puede confiar en la declaración de la política? En lugar de inventar un mecanismo de seguridad específico de routing, WS-Referral simplemente delega la seguridad a nivel de mensaje a un protocolo externo, probablemente WS-Security. Modelo de datos basado en XML Como GXA está basado en SOAP, los protocolos GXA se especifican en términos del modelo de datos para XML. Este modelo de datos (denominado XML Information Set, o Infoset) tiene la ventaja de un amplio soporte del mercado, tanto en cuanto a plataforma como de soporte de herramientas. Al definir GXA en términos de Infosets XML, un protocolo GXA tiene una obvia y natural representación en XML 1.0, la sintaxis de transferencia por defecto para la información basada en XML. Basarse en Infosets también permite a GXA trabajar con arquitecturas basadas en XML de alto rendimiento que no dependen de transferir XML 1.0, como tuberías de procesamiento XML, entornos de programación basados en XML y bases de datos que soportan XML "de modo nativo". Neutral respecto del transporte GXA se especifica completamente a nivel de intercambio de mensajes SOAP. Aunque HTTP ha demostrado ser un protocolo de transporte útil para crear Web services XML, GXA no depende ni de la sintaxis ni de la semántica HTTP. Por ello, los protocolos GXA (como el propio SOAP) están diseñados para trabajar a nivel de mensaje independiente del transporte subyacente. Otro aspecto de la neutralidad de transporte de GXA es que no asume patrones de mensajes del tipo envío/respuesta RPC. Los protocolos GXA han sido diseñados para permitir el transporte de información de control fuera de banda (por ejemplo, handshakes de seguridad, intercambio de políticas) bien como parte del intercambio de mensajes a nivel de aplicación, o como canales independientes establecidos por los componentes de infraestructura (por ejemplo, servidores de autentificación, directorios, etc.). Neutral respecto del dominio de aplicación Quizá el principio de diseño más importante de GXA es que los protocolos GXA tienden a ser soluciones de propósito general a problemas globales que abarcan dominios de aplicación. Como es difícil llegar a un acuerdo, resulta más manejable acordar una única solución global para cualquier dominio de aplicación que definir un estándar de seguridad específico para las aplicaciones de cadena de suministro, otro para aplicaciones de agenda, etc. Acordar un estándar común de propósito general no implica que determinados dominios de aplicación no puedan tener sus propios requerimientos específicos. Por esta razón, los protocolos y esquemas GXA proporcionan un mecanismo de extensibilidad consistente y bien definido. Esto permite utilizar un protocolo GXA como una "base" que proporciona la mayor parte de lo que se necesita, a la vez que posibilita la especialización específica de un dominio. GXA proporciona una plataforma de protocolos para construir aplicaciones basadas en Web services. La funcionalidad del núcleo de esa plataforma incluye: Red virtual independiente de la aplicación El valor primordial de GXA es que proporciona una red virtual sobre transportes y protocolos de red arbitrarios. El protocolo GXA que proporciona este "tono de llamada de Web service" es WS-Routing. WS-Routing abstrae el direccionamiento y routing específico del protocolo tras un esquema de direccionamiento uniforme basado en URI. WS-Routing aprovecha el concepto de "intermediario SOAP" definido en SOAP/1.2, permitiendo a los mensajes fluir a través de uno o más nodos de routing antes de llegar al destinatario final del mensaje. Como WS-Routing funciona sobre transportes arbitrarios, cada salto puede utilizar un transporte subyacente distinto, lo que permite a dos extremos comunicarse aunque no haya disponible ningún protocolo de transporte común. Como los mensajes que utilizan WS-Routing pueden enviarse sobre múltiples transportes salto-a-salto, WS-Routing por sí mismo sólo puede garantizar funcionalidad a nivel de datagrama cuando se halla presente un intermediario. Para obtener transmisión fiable extremo-a-extremo en todos los casos, Microsoft está actualmente definiendo un protocolo de mensajería fiable para ofrecer una entrega fiable y ordenada de mensajes sobre transportes arbitrarios. Este protocolo se basa en lecciones aprendidas de TCP, y resulta adecuado tanto para la entrega de mensajes transitoria, como para escenarios de almacenamiento y reenvío duraderos. Resulta tentador echar un vistazo a la virtualización de red de GXA y preguntarse: "¿por qué no utilizar simplemente TCP/IP?". La principal razón es que es extremadamente difícil implementar optimizaciones independientes de la aplicación en la mayor parte de pilas TCP/IP comerciales. Expresando el protocolo de red en términos de XML, resulta más fácil desarrollar infraestructura independiente de la aplicación (por ejemplo, routers, gateways, brigdes) que se beneficie de las herramientas y tecnologías existentes basadas en XML. Además, como pueden implementarse nuevos algoritmos de routing o heurísticas de retransmisión con código en modo usuario utilizando herramientas accesibles, la innovación en protocolos ya no requiere manipulaciones en el núcleo a bajo nivel. Seguridad orientada a mensajes Una vez formalizada la noción de intermediario por parte de SOAP, la capacidad de depender de la seguridad a nivel de transporte ya no resulta razonable. Como un intermediario puede necesitar procesar un mensaje antes de reenviarlo al siguiente (o al último destinatario), la seguridad del Web service necesita ser explícitamente consciente de la "naturaleza SOAP" subyacente del mensaje. Este conocimiento lo proporciona WS-Security, el protocolo básico de seguridad de GXA. WS-Security proporciona un mecanismo basado en SOAP para firmar y sellar porciones de un mensaje SOAP. Específicamente, WS-Security define una cabecera SOAP que transmite el token de seguridad del remitente. Este token representa una o más declaraciones que el remitente afirma que son ciertas. El receptor del mensaje utiliza estas declaraciones para determinar si el mensaje puede ser procesado. Si el remitente carece de las declaraciones requeridas, el mensaje será rechazado con un código de fallo conocido. De lo contrario, el mensaje será procesado como sería de esperar. WS-Security no impone un formato específico para el token de seguridad. Por el contrario, se soportan formatos específicos a través de un elemento de extensibilidad en la cabecera de seguridad. WS-Security predefine el formato del elemento para los diversos protocolos (por ejemplo, X509, Kerberos) de uso más generalizado. El token de seguridad que aparece en una cabecera WS-Security se utiliza (al menos) para dos propósitos: firmar y sellar. WS-Security permite firmar y sellar porciones de un mensaje SOAP. Firmar un mensaje garantiza: (a) que el remitente es de hecho quién tiene posesión del token de seguridad y (b) que las porciones firmadas del mensaje no han sido alteradas. Sellar un mensaje encripta su contenido utilizando una clave conocida únicamente por el remitente y el receptor. WS-Security simplemente proporciona un marco de trabajo para firmar y sellar, y delega a protocolos definidos externamente, como XML Signature o XML Encryption, para la algorítmica. Esto permite a WS-Security adaptarse a nuevos algoritmos a medida que van siendo desarrollados. Soporte para seguridad federada WS-Security es una especificación base y representa la mínima funcionalidad necesaria para enviar un mensaje seguro. WS-Trust definirá protocolos para emitir tokens de seguridad y gestionar relaciones de confianza. WS-Privacy proporcionará un marco de trabajo para generar sentencias sobre requerimientos y preferencias de privacidad de información. WS-Authorization proporcionará mecanismos para descubrir los requerimientos de declaración/privilegio de un servicio. WS-Federation definirá los protocolos necesarios para intermediar relaciones de confianza entre organizaciones autónomas y tecnologías de autenticación. WS-SecureConversation proporcionará el protocolo para establecer un contexto de comunicaciones seguro, incluyendo el establecimiento de una clave de sesión segura y apropiada para sellar el contenido de los mensajes. Finalmente, WS-Policy proporcionará un marco de trabajo de propósito general para descubrir las capacidades y requerimientos de un servicio. Acuerdo distribuido Desde los albores de SOAP, los usuarios se han preguntado qué papel tienen las transacciones en el mundo de los Web services. Para abordar las necesidades de una amplia gama de aplicaciones, Microsoft está definiendo un marco de trabajo para desarrollar protocolos sobre acuerdos distribuidos basados en GXA. Este marco de trabajo no dicta un protocolo de acuerdo específico (por ejemplo, commit en dos fases); en lugar de ello, simplemente define un marco de trabajo común para que varias partes establezcan interés mutuo para facilitar el trabajo coordinado. Metadatos extendidos y descubrimiento GXA presupone un mundo en el que los metadatos son de alta fidelidad y ubicuos. Para ello, Microsoft está desarrollando actualmente un marco de trabajo de metadatos basado en XML que permite realizar declaraciones arbitrarias sobre las diversas entidades que componen una aplicación de Web service. Este marco de trabajo se utiliza para expresar capacidades, preferencias y requerimientos para puntos extremos y para mensajes. WS-Referral es la primera aplicación de este marco de trabajo, y próximas especificaciones generalizarán el papel de los metadatos a otros dominios .
  • Timeline de las especificaciones WS-*
  • Timeline de los Frameworks que implementaron o implementarán las especificaciones WS-*
  • Cuando Microsoft presentó la versión 1.0 de Web Services Enhancements (WSE) para habilitar la seguridad, el enrutamiento y los datos adjuntos en un producto compatible, también se incluyó un grado de compatibilidad importante para los servicios Web avanzados. Web Services Enhancements 2.0 evoluciona desde la simple compatibilidad de los protocolos de base hasta una compatibilidad donde se integra la funcionalidad principal con el sistema operativo; asimismo, incorpora mejoras añadidas sobre recursos de directivas, confianza y tokens de contexto. WSE aún es una extensión de la compatibilidad de .NET Framework para la creación y uso de servicios Web, aunque WSE 2.0 permite nuevos modelos de programación. La anterior compatibilidad con servicios Web se ha basado en los Servicios de Internet Information Server (IIS) como su host de servidor HTTP; WSE 2.0 dispone ahora de compatibilidad para enviar mensajes a través del protocolo TCP/IP o dentro de un proceso. Esto proporciona la capacidad de enviar mensajes desde un servidor a un cliente, entre iguales, de forma unidireccional y asincrónicamente.
  • Algunas carcaterísticas WSE 2.0 soporta las siguientes funciones: Token-issuing framework (WS-Trust, WS-SecureConversation) . Provee herramientas que se construyen sobre WS-Security y define las extensiones para solicitar y publicar muestras de seguridad y mantener las relaciones de confianza y las conversaciones seguras. Autorización integrada en la seguridad de Windows . Facilita a las empresas utilizar sus credenciales existentes de dominio de Windows cuando accedan a los servicios Web o integrar su propio motor de control de acceso. Declarative programming model (WS-Policy, WS-SecurityPolicy) . Facilita a los desarrolladores políticas de autor que funcionan con un componente en tiempo real, responsable de procesar los encabezados SOAP en los servicios Web que contienen información sobre la seguridad y la ruta y desempeñan un papel importante en los mensajes entrantes y salientes. Por ejemplo, en tiempo real puede automáticamente firmar y encriptar un mensaje basado en una política de autoridad sin que el desarrollador tenga que escribir el código. Modelo de objetos basados en mensajes (WS-Addressing) . Provee a los clientes de un modelo de programación basado en mensajes sobre TCP/IP y HTTP, permitiéndoles explorar otro tipo de aplicaciones basadas en SOAP tales como, por ejemplo, peer-to-peer
  • El soporte de transacciones está documentado dentro de GXA mediante tres principales especificaciones recientes (Agosto de 2005) que reemplazan a la especificación WS-Transaction existente. Estas tres especificaciones, aún no han sido implementadas por ningún Framework, se espera que las próximas versiones de WSE (WSE 3.0) incorpore estas especificaciones. Igualmente las mismas formarán parte desde el inicio, del tan esperado Indigo. WS-Coordination Esta especificación describe un framework extensible para proveer protocolos de coordinación de acciones entre aplicaciones distribuídas. Esta especificación permite que un servicio de aplicación genere un contexto necesario para propagar una actividad a otros servicios. El framework permite a las transacciones existentes, los workflows y otros procesos, ocultar sus protocolos propietarios, y operar en un ambiente heterogéneo. WS-AtomicTransaction Esta especificación provee la definición de cómo deben implementarse las transacciones atómicas que serán implementadas con el framework extensible de coordinación descrito en la especificación WS-Coordination. La especificación declara tres posibles acuerdos para la coordinación de las transacciones atómicas: completion, volatile two-phase commit, y durable two-phase commit. Los desarrolladores puede usar cualquiera de estos protocolos cuando necesiten realizar aplicaciones donde se implementen actividades distribuídas de corta duración en donde todo o nada debe ser procesado. WS-BussinessActivity Esta especificación provee la definición de la coordinación de actividades de negocio que se utilizarán en conjunto a WS-Coordination. La especificación define dos posibles protocolos de acuerdo de coordinación: BusinessAgreementWithParticipantCompletion, y BusinessAgreementWithCoordinatorCompletion. Los desarrolladores pueden usar cualquiera de estos protocolos cuando necesiten generar aplicaciones que implementen actividades de negocio de larga duración. De esta forma, las transacciones también podrán ser implementadas entre los servicios Web y utilizando protocolos estándares, gracias a la iniciativa GXA. Nota al instructor: En los materiales del módulo, se incorporan los documentos completos de las tres especificaciones.

Transcript

  • 1. Clase XIII •[nombre instructor] •[fecha]
  • 2. Agenda ASP.NET & ADO.NET  Arquitectura n capas  Capa de presentación  Capa de negocios  Capa de acceso a datos  Data Storage Base Class Library  Globalización  Localización  Encriptación WebService’s  Aplicaciones Distribuidas  Tecnologías subyacentes  Usando XML Web Services  Seguridad  GXA
  • 3. Agenda ASP.NET & ADO.NET  Arquitectura n capas  Capa de presentación  Capa de negocios  Capa de acceso a datos  Data Storage Base Class Library  Globalización  Localización  Encriptación WebService’s  Aplicaciones Distribuidas  Tecnologías subyacentes  Usando XML Web Services  Seguridad  GXA
  • 4. Arquitectura n capasADO.NET & ASP.NET
  • 5. Capa de presentación  Interfase grafica que el usuario observa, normalmente conocida como UI  Compuesta por Web Form, Win Form, etc, dependiendo del tipo de aplicación que se este realizandoADO.NET & ASP.NET
  • 6. Capa de Presentación  Controles ASP.NET para el data binding de la capa de presentación  ObjectDataSource  Provee una estructura de:  Ordenación  Paginación  Filtrado  CachingADO.NET & ASP.NET  GridView  DropDownList  FormView  DetailsView
  • 7. Utilizando ObjectDataSource  Propiedades:  TypeName  SelectMethod  UpdateMethod  DeleteMethod  InsertMethodADO.NET & ASP.NET
  • 8. Utilizando ObjectDataSource  Propiedades (continuación)  InsertParameters  DeleteParameters  UpdateParameters  SelectParametersADO.NET & ASP.NET
  • 9. ADO.NET & ASP.NET Ejemplo
  • 10. Ejemplo : Implementación de UpdateProductADO.NET & ASP.NET
  • 11. Utilizando ObjectDataSourceADO.NET & ASP.NET
  • 12. Utilizando ObjectDataSourceADO.NET & ASP.NET
  • 13. Utilizando ObjectDataSourceADO.NET & ASP.NET
  • 14. Controles de Visualización  Propiedades  DataSourceID  DataMember  DataKeysADO.NET & ASP.NET
  • 15. ADO.NET  Capa de negocios  Componentes que representan entidades de negocio  Componentes de integraciónADO.NET & ASP.NET
  • 16. ADO.NET  Capa de acceso a datos  Componentes DALADO.NET & ASP.NET
  • 17. ADO.NET  Data storage  Compuesto por las bases de datos donde se almacena la información:  Microsoft SQL Server 2005  Oracle Database  Archivos XMLADO.NET & ASP.NET
  • 18. Agenda ASP.NET & ADO.NET  Arquitectura n capas  Capa de presentación  Capa de negocios  Capa de acceso a datos  Data Storage Base Class Library  Globalización  Localización  Encriptación WebService’s  Aplicaciones Distribuidas  Tecnologías subyacentes  Usando XML Web Services  Seguridad  GXA
  • 19. Globalización Esta enmarcada en el Namespace Globalization  CultureInfo  Calendar  TextInfo  StringInfo  RegionInfo  DateTimeFormatInfo  RegionInfo  NumberFormatInfo
  • 20. Calendar
  • 21. Ejemplo: Configuración del calendario(cont.)
  • 22. Ejemplo: Configuración del calendario(cont.)
  • 23. NumberFormatInfo
  • 24. DateTimeFormatInfo
  • 25. DateTimeFormatInfoResultado del código anterior
  • 26. RegionInfo
  • 27. Localización Traducción de la aplicación al idioma especificado Detección de la configuración actual
  • 28. Modelo de Criptografía de .NETFramework Provee implementación de muchos algoritmos criptográficos estándar Algoritmos fáciles de usar y con las propiedades por defecto más seguras
  • 29. Objetivos de la encriptación Confidencialidad: ayuda a proteger la identidad o información de un usuario. Integridad de datos: ayuda a mantener la información sin cambios indeseados. Autenticación: para asegurarse que la información se origina en un lugar particular
  • 30. Primitivas de la criptografía Secret-key encryption (criptografía simétrica) Public-key encryption (criptografía asimétrica) Cryptographic signing Cryptographic hashes
  • 31. Algoritmos Criptográficos Algoritmos de Hashing  HMACSHA1  MACTripleDES  MD5CryptoServiceProvider  SHA1Managed  SHA256Managed  SHA384Managed  SHA512Managed Algoritmos de criptografía simétrica  DES, RC2, Triple-DES, and Rijndael (or AES) Algoritmos de criptografía asimétrica  RSA, DSA
  • 32. Ejemplo de TripleDESCryptoServiceProviderprivate static void EncryptData(String inName, String outName, byte[] tdesKey, byte[] tdesIV){ FileStream fin = new FileStream(inName, FileMode.Open, FileAccess.Read); FileStream fout = new FileStream(outName, FileMode.OpenOrCreate, FileAccess.Write); fout.SetLength(0); byte[] bin = new byte[100]; long rdlen = 0; long totlen = fin.Length; int len; TripleDESCryptoServiceProvider tdes = new TripleDESCryptoServiceProvider(); CryptoStream encStream = new CryptoStream(fout, tdes.CreateEncryptor(tdesKey, tdesIV), CryptoStreamMode.Write); // Lee del archivo de entrada, encripta, y guarda en el archivo de salida while(rdlen < totlen) { len = fin.Read(bin, 0, 100); encStream.Write(bin, 0, len); rdlen = rdlen + len; Console.WriteLine("{0} bytes procesados", rdlen); } encStream.Close();}
  • 33. Ejemplo de SHA512Managedbyte[] data = new byte[DATA_SIZE];byte[] result;SHA512 shaM = new SHA512Managed();result = shaM.ComputeHash(data);
  • 34. Random Number Generation Es necesario para muchas operaciones criptográficas Debe generar salidas con una probabilidad p < .05 public sealed class RNGCryptoServiceProvider : RandomNumberGenerator
  • 35. Laboratorio •Globalización
  • 36. Agenda ASP.NET & ADO.NET  Arquitectura n capas  Capa de presentación  Capa de negocios  Capa de acceso a datos  Data Storage Base Class Library  Globalización  Localización  Encriptación WebService’s  Aplicaciones Distribuidas  Tecnologías subyacentes  Usando XML Web Services  Seguridad  GXA
  • 37. Evolución de las aplicaciones distribuidas  Qué es una aplicación distribuída?  Por qué necesitamos aplicaciones distribuídas?  Aplicaciones distribuidas como proveedores de serviciosAplicaciones Distribuidas  Aplicaciones distribuidas en la Web
  • 38. Problemas de las aplicaciones distribuidas tradicionales  Consideraciones de diseño para las Aplicaciones distribuidas  Arquitecturas basadas en RPC  Arquitecturas basadas en mensajes  Estándares WebAplicaciones Distribuidas
  • 39. Consideraciones de diseño para las Aplicaciones distribuidas  Tipos de datos que no son compatibles entre diferentes sistemas  Fallas del sistema o pérdidas del response  Fallas de los clientesAplicaciones Distribuidas  Reintentos de llamada  Seguridad  Sincronización de la hora entre diferentes sistemas
  • 40. Arquitecturas basadas en RPC  Qué es RPC?  El RPC es una invocación a un procedimiento o función que reside en un sistema remoto  Llamadas sincrónicas a funciones Problemas de las arquitecturas RPCAplicaciones Distribuidas 
  • 41. Arquitecturas basadas en mensajes  Mensajería asincrónica  Problemas de las arquitecturas basadas en mensajesAplicaciones Distribuidas
  • 42. Estándares Web  Problemas de los protocolos binarios  Protocolos Web y formato de datos  HTML  HTTP  XMLAplicaciones Distribuidas  Problemas de la Web  Seguridad  Performance
  • 43. Introducción a los Web Services  Qué son los Web Services?  Basados en tecnologías de Internet  Building blocks  El futuro de las aplicacionesAplicaciones Distribuidas distribuídas
  • 44. Escenarios comunes a los Web services  Aplicaciones ASP/Hosted Suscriptores Application Service Application Hosting Provider Provider/Infrastructure Service Provider Aplicación UI MediciónAplicaciones Distribuidas Web Service Soporte  Integración de la aplicación
  • 45. Web Services como implementación de la arquitectura orientada a servicios UDDIAplicaciones Distribuidas SOAP SOAP IIS SOAP Web Service Cliente
  • 46. El modelo de programación de los Web Services  Protocolos Web  Stateless  Bajo acoplamiento  Formato de datos UniversalAplicaciones Distribuidas
  • 47. Resumen  Evolución de las aplicaciones distribuidas  Problemas de las aplicaciones distribuidas tradicionales  Introducción a los Web ServicesAplicaciones Distribuidas  Stack de la tecnología Web y .NET  Escenarios comunes a los Web services
  • 48. Agenda ASP.NET & ADO.NET  Arquitectura n capas  Capa de presentación  Capa de negocios  Capa de acceso a datos  Data Storage Base Class Library  Globalización  Localización  Encriptación WebService’s  Aplicaciones Distribuidas  Tecnologías subyacentes  Usando XML Web Services  Seguridad  GXA
  • 49. Fundamentos de HTTP  Descripción de HTTP  Estructuras del HTTP Request y Response  Los métodos GET y POSTTecnologías Subyacentes
  • 50. Los métodos GET y POST  HTTP-GET Ejemplo GET /Trading/GetStockPrice.asp?Symbol=MSFT HTTP/1.1 Host: localhost  HTTP-POSTTecnologías Subyacentes Ejemplo POST /Trading/GetStockPrice.asp HTTP/1.1 Host: localhost Content-Type: application/x-www-form-urlencoded Content-Length: 11 Symbol=MSFT
  • 51. Esencias del XML  Descripción de XML  Fundamentos de XSD  Serialización XML en el .NET FrameworkTecnologías Subyacentes
  • 52. Descripción de XML  Elementos y atributos  Documentos Well-formed  SchemasTecnologías Subyacentes
  • 53. Serialización XML en el .NET Framework  Caveats  POST/GET vs. SOAP System.Xml.Serialization  Property XmlRootAttribute serializatio nTecnologías Subyacentes XmlElementAttribute XmlAttributeAttribute XmlArrayAttribute XmlArrayItemAttribute
  • 54. Fundamentos de SOAP  Descripción de SOAP  Estructura de los mensajes SOAPTecnologías Subyacentes
  • 55. Descripción de SOAP  Mensajes SOAP  Partes del mensaje SOAP  SOAP envelope  SOAP encoding rules  SOAP RPC representationTecnologías Subyacentes  Protocol bindings for HTTP and HTTP-EF
  • 56. Agenda ASP.NET & ADO.NET  Arquitectura n capas  Capa de presentación  Capa de negocios  Capa de acceso a datos  Data Storage Base Class Library  Globalización  Localización  Encriptación WebService’s  Aplicaciones Distribuidas  Tecnologías subyacentes  Usando XML Web Services  Seguridad  GXA
  • 57. Documentos WSDL  Qué es WSDL? Web Service Web Service ConsumerUsando XML Web Services  Estructura de un documento WSDL El elemento binding  El elemento types El elemento service  El elemento message 
  • 58. Web Service Discovery  Introduciendo DiscoUsando XML Web Services Web Service Web Service Consumer
  • 59. Introduciendo Disco  Qué es Disco?Usando XML Web Services
  • 60. Qué es UDDI? Por qué usar UDDI?  Una colección de especificaciones  Para distribuir información de registro de los Web services - UDDI Programmer’s API Specification - UDDI Data Structure SpecificationUsando XML Web Services  Implementación del registro UDDI  Implementaciones de las especificaciones
  • 61. Creación de un Web ServiceUsando XML Web Services
  • 62. Implementando métodos en los Web ServicesUsando XML Web Services
  • 63. Exponinendo métodos Web  Configurando las propiedades del atributo WebMethod  BufferResponse  CacheDuration  DescriptionUsando XML Web Services  EnableSession  MessageName  TransactionOption
  • 64. Usando XML Web Services Ejemplo Web Service
  • 65. Laboratorio •Implementando un Web Service
  • 66. Laboratorio •Consumiendo un Web Service
  • 67. Agenda ASP.NET & ADO.NET  Arquitectura n capas  Capa de presentación  Capa de negocios  Capa de acceso a datos  Data Storage Base Class Library  Globalización  Localización  Encriptación WebService’s  Aplicaciones Distribuidas  Tecnologías subyacentes  Usando XML Web Services  Seguridad  GXA
  • 68. Authentication vs. Authorization  Authentication  Buscar y verificar la identidad del usuario  Authorization  Identificar si el usuario tiene permisos para los pedidos realizadosSeguridad en Web Services
  • 69. Tipos de Autenticación IIS ASP.NET Forms SOAP headerSeguridad en Web Services
  • 70. Tipos de Autorización Windows NT Role-based Code access securitySeguridad en Web Services
  • 71. Resumen  Authentication vs. Authorization  Tipos de Autenticación  Tipos de AutorizaciónSeguridad en Web Services
  • 72. Agenda ASP.NET & ADO.NET  Arquitectura n capas  Capa de presentación  Capa de negocios  Capa de acceso a datos  Data Storage Base Class Library  Globalización  Localización  Encriptación WebService’s  Aplicaciones Distribuidas  Tecnologías subyacentes  Usando XML Web Services  Seguridad  GXA
  • 73. Limitaciones de los Web Services  Actualmente los Web Services se usan para:  Integrad aplicaciones empresariales  Interoperar con parters de negocio  En el futuro necesitarán:  Interoperar a través de múltiples organizaciones  Problemas que los estándares principales (SOAP, WSDL, UDDI) no resuelven  Cómo implementar seguridad?  Cómo agregar o quitar dinámicamente un path?  Cómo realizar transacciones de largaGXA duración?
  • 74. Descripción de Global XML Web Services Architecture Consideraciones de diseño de GXA  Propósito general  Modular  Basado en  Federated estándares Algunas especificaciones  WS-Routing  WS-Referral  WS-Security  WS-License  WS-TransactionsGXA
  • 75. Especificaciones WS-* Evolve and Extend Secure, Reliable, Transacted Fundamentals WS-I formed WS-I formed WS-I BP 1.0 WS-I BP 1.0 Interoperability Interoperability A fecha de Feb/2004 Security Roadmap SRT Web Services Whitepaper Whitepapers Security Roadmap SRT Web Services Whitepaper Whitepapers Reliable Messaging Roadmap Reliable Messaging Roadmap WS-Coordination WS-AtomicTransaction Transactions WS-Coordination WS-AtomicTransaction Transactions WS-Transaction WS-Transaction WS-BusinessActivity WS-BusinessActivity WS-ReliableMessaging WS-ReliableMessaging Reliability Reliability WS-Security WS-Security WS-Federation Security WS-Federation Security WS-Federation Active Requestor Profile WS-Federation Active Requestor Profile WS-Trust WS-Trust WS-Security Addendum WS-Security Addendum WS-Security SOAP Message Security WS-Security SOAP Message Security WS-Security Profile for WS-Security Profile for WS-Security Username Token Profile WS-Security Username Token Profile Tokens Tokens WS-Security X.509 Certificate Token Profile WS-Security X.509 Certificate Token Profile WS-Security Kerberos Binding WS-Security Kerberos Binding UDDI 1.0 UDDI 2.0 UDDI 3.0 WS-Policy 1.1 Metadata UDDI 1.0 UDDI 2.0 UDDI 3.0 WS-Policy 1.1 Metadata WS-PolicyAttachments 1.1 WS-PolicyAttachments 1.1 WSDL WSDL WS-Inspection WS-Inspection WS-PolicyAssertions 1.1 WS-PolicyAssertions 1.1 WS-Policy WS-Policy WS-Discovery WS-Discovery WS-PolicyAttachments WS-PolicyAttachments WS-MetadataExchange WS-MetadataExchange WS-PolicyAssertions WS-PolicyAssertions WS-SecurityPolicy WS-SecurityPolicy SOAP 1.1 SOAP 1.2 Messaging SOAP 1.1 SOAP 1.2 Messaging WS-Referral WS-Referral WS-Addressing WS-Addressing WS-Routing WS-Routing WS-Eventing WS-Eventing SOAP Messages SOAP Messages DIME WS-Attachments MTOM with Attachments DIME WS-Attachments MTOM with AttachmentsGXA 2000 2001 2002 2003 2004 2005
  • 76. Especificaciones WS-* Aplicaciones Aplicaciones WS-Discovery WS-Federation WS-MetadataExchange WS-BusinessActivity WS-AtomicTransaction Metadatos WS-Trust WS-Policy Seguridad WS-SecureConversation Fiabilidad WS-ReliableMessaging Transaccional WS-Coordination WS-Transaction WS-Inspection WS-Security UDDI WSDL SOAP XSD “Indigo” WS-Routing WS-Addressing Mensajería WS-Referral WS-Attachments MTOM WS-Eventing DIME ASP.NET Web Services .NET FX 1.0 / 1.1 WSE 1.0 XML WSE 2.0 TCP HTTP Transportes Transportes in-processGXA
  • 77. WSE 2.0 – Algunas características  Token-issuing framework  Autorización integrada en la seguridad de Windows  Declarative programming model  Modelo de objetos basados en mensajesGXA
  • 78. Transacciones  WS-Coorination  WS-AtomicTransaction  WS-BussinessActivityGXA
  • 79. ResumenGXA
  • 80. Exámen Próxima clase: Exámen presencial de “2da Estrella” (Lenguaje a Elección)