Manual.NET 3.5 ( TS*): DESARROLLO de APLICACIONES de COMUNICACIÓN (SERVICIOS), 24 horas

Transcripción

1 Sé diferente, intégrate Mm076 Manual.NET 3.5 ( TS*): DESARROLLO de APLICACIONES de COMUNICACIÓN (SERVICIOS), 24 horas Autor: Orlando Gutiérrez Fecha: 18 / 11 / 2013 Todos los derechos reservados, prohibida la reproducción, Instituto Gala de Venezuela 1

2 INDICE Pag. 4 Pag. 13 Pag. 14 Pag. 16 Pag. 16 Pag. 19 Pag. 25 Pag. 28 Pag. 31 Pag. 33 Pag. 36 Pag. 40 Pag. 45 Pag. 54 Pag. 60 Pag. 67 Pag. 71 Pag. 74 Pag. 77 Pag. 78 Pag. 78 Pag. 78 Pag. 81 Pag. 86 Pag. 91 Pag. 93 Lección 1 Introducción a W.C.F Windows Communication Foundation Lección 2 Definir contratos de servicio Lección 3 Definir contratos de datos Lección 4 Definir contratos de operaciones Lección 5 Definir contratos de mensajes Lección 6 Procesar mensajes genéricos Lección 7 Crear y configurar los puntos finales del servicio Lección 8 Administrar la consistencia entre ciclo de vida, sesiones, concurrencia y enlaces Lección 9 Alojar un servicio en una aplicación administrada Lección 10 Alojar un servicio en un servidor Web Lección 11 Crear comportamientos personalizados Lección 12 Implementar el seguimiento del servicio de punto a punto Lección 13 Controlar la calidad del servicio Lección 14 Registrar los mensajes Lección 15 Configurar de forma dinámica el servicio utilizando el modelo de servicio Lección 16 Implementar inspectores Lección 17 Crear un proxy de servicio Lección 18 Configurar un punto final cliente Lección 19 Llamar un servicio con el proxy de servicio Lección 20 Procesar excepciones en los clientes Lección 21 Utilizar servicios no WCF Lección 22 Implementar la seguridad en el nivel de transporte Lección 23 Implementar la seguridad en el nivel de los mensajes Lección 24 Autenticar clientes Lección 25 Autorizar clientes Lección 26 Suplantar clientes Pag. 100 Lección 27 Administrar instancias Pag. 101 Lección 28 Administrar sesiones Todos los derechos reservados, prohibida la reproducción, Instituto Gala de Venezuela 2

3 Pag. 106 Lección 29 Administrar transacciones Pag. 109 Lección 30 Administrar la concurrencia Pag. 109 Lección 31 Administrar la consistencia entre instancias, sesiones, transacciones y concurrencia Todos los derechos reservados, prohibida la reproducción, Instituto Gala de Venezuela 3

4 LECCION 1 Introducción a W.C.F Windows Communication Foundation Qué es Windows Communication Foundation WCF? La aceptación global de servicios Web que incluye los protocolos estándar para la comunicación de aplicación a aplicación, ha cambiado el desarrollo de software. Por ejemplo, las funciones que proporcionan los servicios Web ahora incluyen seguridad, coordinación de transacciones distribuidas y una comunicación fiable. Las ventajas de los cambios en servicios Web se deberían reflejar en las herramientas y tecnologías que los programadores utilizan. Windows Communication Foundation (WCF) está diseñado para ofrecer un enfoque manejable a la informática distribuida, interoperabilidad ancha y asistencia directa para la orientación sobre el servicio. WCF simplifica el desarrollo de aplicaciones conectadas a través de un nuevo modelo de programación orientado a servicios. WCF admite muchos estilos de desarrollo de aplicaciones distribuidas proporcionando una arquitectura superpuesta. En su base, la arquitectura de canal de WCF proporciona primitivos asíncronos de paso de aprobación de mensajes sin tipo. Generados sobre esta base están las funciones de protocolos para un intercambio de datos de transacción seguro y fiable, así como una amplia variedad de opciones de codificación y transporte. El modelo de programación tipificada (llamado modelo de servicio) está diseñado para facilitar el desarrollo de aplicaciones distribuidas y proporcionar a los desarrolladores pericia en servicios Web ASP.NET, comunicación remota.net Framework y Enterprise Services, así como a aquellos que llegan a WCF con cierta experiencia en desarrollo. El modelo de servicio presenta una asignación sencilla de conceptos de servicios Web para aquellos de Common Language Runtime (CLR).NET Framework, incluyendo la asignación ampliable y flexible de mensajes para la implementación de servicios en lenguajes como Visual C# o Visual Basic. Incluye funciones de serialización que habilitan el acoplamiento separado y el control de versiones y proporciona integración e interoperabilidad con sistemas distribuidos.net Framework existentes, como Message Queue Server (MSMQ), COM+, servicios Web ASP.NET, Mejoras de servicios Web (WSE) y varias funciones más. Ejemplo del problema El siguiente ejemplo muestra algunos de los problemas que WCF resuelve. Una empresa financiera decide crear una nueva aplicación para realizar operaciones. Los creadores de esta aplicación financiera saben que la lógica empresarial que implementa debe ser accesible por otro software que se ejecute dentro y fuera de la compañía. De acuerdo con, deciden integrarlo en un estilo orientado a servicios, con la lógica de la aplicación expuesta a otro software a través de un conjunto bien determinado de servicios. Para implementar estos servicios y así comunica con otro software, la nueva aplicación utilizará WCF. Un intervalo de otras aplicaciones tendrá acceso probablemente a la aplicación financiera. Cuando está diseñado, sin embargo, los arquitectos de la aplicación financiera saben que se tendrá acceso a su lógica empresarial, como se muestra en la figura anterior, por tres otros tipos de software: Una aplicación cliente de centro de llamadas que se ejecuta en los escritorios de Windows que son utilizados por empleados en el centro de llamadas de la organización. Creada específicamente para el nuevo sistema financiera, esta aplicación también se generará utilizando.net Framework de Microsoft e WCF. Esta aplicación no es verdaderamente distinta de la nueva aplicación financiera, porque su único propósito es actuar como un cliente para el nuevo sistema. De una perspectiva orientada a servicios, es simplemente otro cliente para la lógica empresarial del sistema financiera. Todos los derechos reservados, prohibida la reproducción, Instituto Gala de Venezuela 4

5 .NET 3.5 ( TS*): DESARROLLO de APLICACIONES Una aplicación financiera existente generada en un servidor de J2EE que se ejecuta en un sistema que no sea Windows. Debido a una reciente fusión con otra empresa financiera, este sistema existente debe poder tener acceso a la lógica de la nueva aplicación para proporcionar una experiencia unificada a los clientes de las empresas fusionadas. Las aplicaciones de los socios que se ejecutan en una variedad de plataformas, cada una de ellas situada dentro de una empresa que tiene una organización empresarial con la empresa financiera. Los diversos requisitos de comunicación para la nueva aplicación financiera no son simples. Para las interacciones con la aplicación cliente del centro de llamadas, por ejemplo, el rendimiento es importante, mientras que la interoperabilidad es sencilla, porque ambos están generados en.net Framework. Para la comunicación con la aplicación existente basada en J2EE y con las aplicaciones de diversos socios, sin embargo, la interoperabilidad se vuelve el objetivo principal. Los requisitos de seguridad también son bastante diferentes. Varían según las aplicaciones locales basadas en Windows, una aplicación basada en J2EE que se ejecuta en otro sistema operativo y una variedad de aplicaciones de los socios que entran a través de Internet. Incluso los requisitos transaccionales podrían variar, permitiéndole únicamente a las aplicaciones internas realizar solicitudes transaccionales. Cómo se pueden cumplir estos distintos requisitos empresariales y técnicos sin exponer los creadores de la nueva aplicación a una complejidad inmanejable? WCF se ha diseñado para este escenario diverso pero realista y es la tecnología predeterminada para las aplicaciones de Windows que exponen y tienen acceso a los servicios. Resolver el problema La base para las nuevas aplicaciones basadas en Windows es.net Framework. Por lo tanto, WCF se implementa principalmente como un conjunto de clases encima de.net Framework CLR. Dado que extiende su entorno familiar, WCF permite que los programadores que crean aplicaciones orientadas a objetos utilizando.net Framework hoy, para también integrar las aplicaciones orientadas a servicios de una manera conocida. La figura muestra una vista de un cliente WCF y de un servicio. Los dos interactúan utilizando SOAP, WCF la representación del mensaje nativa, por lo que aunque la figura muestra ambas partes generadas en WCF, esto no se requiere. WCF se genera en.net Framework 2.0. Como el escenario descrito anteriormente sugiere, WCF hace frente a un intervalo de desafíos para hacer que las aplicaciones se comuniquen. Sin embargo, hay tres cosas que destacan como los aspectos más importantes de WCF: Unificación de las tecnologías de comunicación.net Framework existentes. Compatibilidad para interoperabilidad entre proveedores, incluyendo confiabilidad, seguridad y transacciones. Orientación explícita al servicio. La unificación de las tecnologías informáticas distribuidas de Microsoft En ausencia de WCF, el equipo de desarrollo que implementa la aplicación financiera necesitaría elegir la tecnología distribuida adecuada entre las múltiples opciones proporcionadas por.net Framework. Aunque se den los diversos requisitos de esta aplicación, ninguna tecnología única se ajustaría a ellos. En su lugar, es probable que la aplicación utilizarse varias tecnologías.net Framework existentes, como: ASP.NET Servicios Web (ASMX). Una opción para comunicarse con la aplicación financiera existente basada en J2EE y con las aplicaciones de los socios a través de Internet. Dado que los servicios Web básicos son suministrados hoy en día en la mayoría de las plataformas, esta fue la manera más directa de lograr la interoperabilidad entre proveedores antes del lanzamiento de WCF..NET Framework remoto. Una opción para la comunicación con la aplicación del centro de llamadas, porque ambos se generan en.net Framework. La comunicación remota está diseñada expresamente para la comunicación de.net a.net estrechamente acoplada, por lo que proporciona una experiencia de desarrollo sencilla y sin problemas para las aplicaciones en la red local. Todos los derechos reservados, prohibida la reproducción, Instituto Gala de Venezuela 5

6 .NET 3.5 ( TS*): DESARROLLO de APLICACIONES Enterprise Services. Utilizado por la aplicación financiera para administrar periodos de duración de objeto y definir las transacciones distribuidas. Estas funciones podrían ser útiles para comunicarlas e integrarlas con cualquiera de las otras aplicaciones de este escenario, pero Enterprise Services admite únicamente un conjunto limitado de opciones de comunicación. WSE. Se podría utilizar junto con ASMX para comunicarse con la aplicación financiera basada en J2EE y con las aplicaciones de los socios. Dado que implementa más recientemente los acuerdos de los servicios Web definidos, conocidos colectivamente como las especificaciones WS-*, WSE permite una seguridad más flexible en los servicios Web, con tal de que todas las aplicaciones implicadas sean compatibles con las versiones de estas nuevas especificaciones. Message Queuing de Microsoft (MSMQ). Se utiliza para comunicarse con aplicaciones de socios basadas en Windows que requieren la entrega de los datos garantizada, así como el desacoplamiento de cargas de trabajo y periodos de duración de la aplicación. La mensajería duradera que Message Queuing proporciona suele ser la mejor solución para las aplicaciones conectadas de manera intermitente. Generada en.net Framework, la aplicación financiera debe utilizar más de una de estas tecnologías de comunicación para cumplir con sus requisitos. Aunque esto es técnicamente posible, la aplicación resultante sería compleja de implementar y su mantenimiento sería todo un desafío. Con WCF, la solución es mucho más fácil de implementar. Como muestra la figura, WCF se puede utilizar para todas las situaciones descritas previamente. Por lo tanto, la aplicación financiera puede utilizar esta tecnología única para todas sus comunicaciones de aplicación a aplicación. A continuación se muestra WCF trata cada uno de estos requisitos: Dado que WCF puede comunicarse utilizando los servicios Web, la interoperabilidad con otras plataformas que también admiten SOAP, como los principales servidores de aplicaciones basados en J2EE, es sencilla. También puede configurar y extender WCF para comunicarse con los servicios Web utilizando los mensajes no basados en SOAP, por ejemplo, los formatos XML simples como RSS. El rendimiento es una preocupación primordial para la mayoría de los negocios. WCF se desarrolla con el objetivo de ser una de las plataformas de aplicación distribuidas más rápidamente desarrollada por Microsoft. Para permitir un rendimiento óptimo cuando ambas partes de una comunicación se generan en WCF, la codificación de la conexión utilizada en este caso es una versión binaria optimizada de un conjunto de información XML. Los mensajes todavía cumplen con la estructura de datos de un mensaje SOAP, excepto su codificación, que utiliza una representación binaria de esa estructura de datos en lugar del formato de corchetes angulares y texto estándar de la codificación de texto de XML 1.0. Al utilizar esta opción, tiene sentido para comunicarse con la aplicación cliente de centro de llamadas, porque también se ha generado en WCF y el rendimiento es una preocupación importante. La gestión de los periodos de duración de objetos, la definición de las transacciones distribuidas y otros aspectos de Enterprise Services son proporcionados ahora por WCF. Están disponibles para cualquier aplicación basada en WCF, lo que significa que la aplicación financiera puede utilizarlos con cualquiera de las otras aplicaciones con las que se comunica. Dado que admite un conjunto grande de las especificaciones de WS - *, WCF ayuda a proporcionar confiabilidad, seguridad y transacciones al comunicarse con cualquier plataforma que también admita estas especificaciones. La opción WCF para la mensajería en cola, integrada en Message Queuing, permite que las aplicaciones utilicen la puesta en cola persistente sin utilizar otro conjunto de interfaces de programación de aplicaciones. El resultado de esta unificación es una mayor funcionalidad y una complejidad significativamente reducida. Interoperabilidad con aplicaciones generadas en otras tecnologías Todos los derechos reservados, prohibida la reproducción, Instituto Gala de Venezuela 6

7 Aunque WCF introduce un nuevo entorno de desarrollo para las aplicaciones distribuidas, está diseñado para interoperar bien con aplicaciones que no sean de tipo WCF. Hay dos aspectos importantes en relación con la interoperabilidad WCF: la interoperabilidad con otras plataformas y la interoperabilidad con las tecnologías de Microsoft que precedieron a WCF. La sección siguiente describe ambos tipos. Interoperabilidad con otras plataformas de los servicios Web Las empresas hoy en día suelen tener los sistemas y aplicaciones que han adquirido a un amplio abanico de proveedores. En la aplicación financiera, por ejemplo, se requiere establecer comunicación con algunas otras aplicaciones de software escritas en varios lenguajes que se ejecutan en varios sistemas operativos. Debido a que el mecanismo de comunicación fundamental de WCF es un servicio Web basado en SOAP, las aplicaciones basadas en WCF pueden comunicarse con otro software que se ejecute en una variedad de contextos. Una aplicación generada en WCF puede interactuar con todo lo siguiente: Las aplicaciones basadas en WCF que se ejecutan en un proceso diferente en el mismo equipo de Windows. Las aplicaciones basadas en WCF que se ejecutan en otro equipo de Windows. Las aplicaciones generadas en otras tecnologías, como servidores de aplicaciones de J2EE, que son compatibles con los servicios Web estándar. Estas aplicaciones se pueden estar ejecutando en equipos con Windows o en los equipos que ejecutan otros sistemas operativos. Para permitir más que únicamente la comunicación básica, WCF implementa tecnologías de servicios Web definidas por las especificaciones de WS-*. Todas estas especificaciones fueron definidas originalmente por Microsoft, IBM y otros proveedores que trabajan juntos. Cuando las especificaciones se estabilizan, la propiedad pasa a menudo a los organismos de creación de estándares, como el World Wide Web Consortium (W3C) u OASIS (Organization for the Advanced of Structures Information Standards, Organización para el avance de estándares de información estructurada). Estas especificaciones tratan varias áreas, incluidas la mensajería básica, la seguridad, la confiabilidad, las transacciones y el trabajo con los metadatos de un servicio. Agrupadas por función, estas especificaciones abarcan: Mensajería: SOAP es la base para los servicios Web y define un sobre básico que contiene las secciones de encabezado y de cuerpo. WS-Addressing define las sumas al encabezado SOAP para direccionar mensajes SOAP, que evita que SOAP confíe en el protocolo de transporte subyacente, como HTTP, para realizar el direccionamiento de la información. El mecanismo de optimización de transmisión del mensaje (MTOM) define un formato de transmisión optimizado para los mensajes SOAP con mucho contenido de datos binarios basado en la especificación del Empaquetado optimizado de XML binario (XOP). Metadatos: el lenguaje de descripción de servicios web (WSDL) define un lenguaje estándar para especificar servicios y varios aspectos sobre cómo se pueden utilizar esos servicios. WS-Policy permite la especificación de aspectos más dinámicos del comportamiento de un servicio que no se pueden expresar en WSDL, como una opción de seguridad preferida. WS-MetadataExchange permite que un cliente solicite directamente información descriptiva sobre un servicio, como su WSDL y sus directivas, utilizando SOAP. Seguridad: WS-Security, WS-SecureConversation, WS-Trust y WS-Federation todos definen las sumas a los mensajes SOAP para proporcionar autenticación, integridad de datos, privacidad de datos y otras características de seguridad. Confiabilidad: la mensajería WS-Reliable define las sumas al encabezado SOAP que permiten la comunicación confiable de un extremo a otro, incluso cuando se deben atravesar uno o más intermediarios de los servicios Web. Transacciones: se genera en WS-Coordination, la transacción WS-Atomic permite coordinar las transacciones de la confirmación en dos fases en el contexto de conversaciones de servicios Web. La aplicación financiera probablemente utilizaría algunos de estas tecnologías más avanzadas. Por ejemplo, WS- Addressing es esencial cada vez que SOAP se utiliza sobre un mecanismo de transporte distinto de HTTP, que podría ser el caso para la comunicación con la aplicación cliente de centro de llamadas basada en.net Framework. WCF confía en WS-Policy y en WS-Metadata Exchange para detectar si el sistema con el que está comunicando también está utilizando WCF y para otras cosas. La comunicación confiable es esencial para la mayoría de las Todos los derechos reservados, prohibida la reproducción, Instituto Gala de Venezuela 7

8 situaciones, por lo que es probable que la Mensajería de WS-Reliable se utilizase para interactuar con muchas de las otras aplicaciones en este escenario. De igual forma, también podría utilizar WS-Security y las especificaciones relacionadas para proteger la comunicación con una o más aplicaciones, porque todas requerirían algún tipo de protección contra el acceso no autorizado o alguna modificación de mensajes e interceptación. Para las aplicaciones que requieren la integración de la transacción con el sistema financiero sería esencial WS-Atomic Transaction. Finalmente, MTOM se podría utilizar cuando fuese necesario un formato de conexión optimizado para los datos binarios (por ejemplo, para las imágenes de ejemplos rápidos) y ambos lados de la comunicación admitieran esta opción. El punto clave es que WCF implementa los servicios Web interoperables que se completan con seguridad multiplataforma, confiabilidad, transacciones y otros servicios. Para proporcionar el rendimiento máximo, la comunicación de WCF a WCF se puede optimizar significativamente, pero el resto de las comunicaciones utilizan los protocolos de servicios Web estándar. De hecho, es posible que una aplicación única exponga sus servicios a ambos tipos de clientes. Interoperabilidad con tecnologías de Microsoft Muchos clientes de Microsoft han realizado inversiones significativas en las tecnologías.net Framework que incluye WCF. Proteger esas inversiones fue un objetivo fundamental de los diseñadores de WCF. Al instalar WCF, no se interrumpe la tecnología existente, así que no hay ningún requisito para que las organizaciones cambien las aplicaciones existentes para que la utilicen. Se proporciona una ruta clara de acceso para la actualización, sin embargo y cuando sea posible, WCF interopera con esas tecnologías anteriores. Por ejemplo, WCF y ASMX utilizan SOAP, por lo que las aplicaciones basadas en WCF pueden interoperar directamente con aquellas integradas en ASMX. Las aplicaciones Enterprise Services existentes también se pueden ajustar con interfaces WCF, permitiéndoles interoperar con aplicaciones generadas en WCF. Y como la puesta en cola persistente en WCF confía en MSMQ, las aplicaciones basadas en WCF pueden interoperar directamente con aplicaciones que no estén basadas en WCF generadas utilizando las interfaces nativas de MSMQ. En la aplicación financiera, el software generado utilizando cualquiera de estas tecnologías anteriores podría conectarse directamente a los servicios basados en el nuevo sistema de WCF y utilizarlos. Sin embargo, la interoperabilidad no siempre es posible. Por ejemplo, aunque WSE 1.0 y WSE 2.0 implementan algunas de las mismas especificaciones de WS-* que WCF, estas tecnologías anteriores implementan versiones anteriores de las especificaciones. La versión 3.0 de WSE permite la interoperabilidad con WCF, pero las versiones anteriores no. Interoperabilidad con otros protocolos de XML El futuro de Internet no es predecible y las tecnologías utilizadas hoy en día pueden evolucionar o ser reemplazadas. Hoy en día, una tendencia popular para generar aplicaciones Web céntricas (llamada por muchos "Web 2.0"), es un modelo de aplicación basado en la comunicación utilizando únicamente formatos XML simples que no se basan en SOAP y que confían exclusivamente en HTTP como transporte y como protocolo de aplicación. Por ejemplo, el estilo arquitectónico de Representational State Transfer (REST) no tiene ninguna noción de operaciones definidas por el usuario para tratar con datos. En su lugar, el estado de la aplicación está asociado a métodos de URL de HTTP y HTTP (como PUT, POST, DELETE y GET). Este enfoque está en contraste con la creación de procedimientos definidos por el usuario o funciones con las que está familiarizada la mayoría de los programadores en un entorno empresarial. Sin embargo, el enfoque REST tiene valor en escenarios donde los servicios deben funcionar como el servidor de las aplicaciones de la Web 2.0. REST es simplemente un ejemplo de una tecnología de la Web 2.0 en evolución. La flexibilidad se exige para cubrir con cambios imprevisibles en este entorno de modelos de programación experimentales, de reinterpretación constante y refinamiento de los estándares. WCF es flexible. Por ejemplo, mientras WCF utiliza SOAP como una estructura subyacente, no se enlaza para utilizar SOAP para la comunicación de la conexión. De hecho, WCF se puede configurar para procesar datos XML "sin formato" que no se ajustan en un sobre SOAP. WCF también se puede extender para admitir los formatos XML concretos, como ATOM (un estándar popular de RSS) e incluso formatos que no sean XML, como JavaScript Object Notation (JSON). Esta flexibilidad asegura que el código escrito hoy será válido en el futuro, aun cuando los protocolos cambien o sean reemplazados. Por consiguiente, WCF se ha diseñado para el presente y el futuro. Términos de WCF Entre otros conceptos y términos usados en la documentación de WCF se incluyen los siguientes. mensaje Un mensaje es una unidad autónoma de datos que pueden estar compuestos de varias partes, incluyendo un cuerpo y encabezados. servicio Un servicio es una construcción que expone uno o más extremos, y en la que cada extremo expone una o más operaciones de servicio. extremo Todos los derechos reservados, prohibida la reproducción, Instituto Gala de Venezuela 8

9 Un extremo es una construcción en la que se envían o reciben mensajes (o ambos). Comprende una ubicación (una dirección) que define dónde se pueden enviar mensajes, una especificación del mecanismo de comunicación (un enlace) que describe cómo se deberían enviar los mensajes, y una definición para un conjunto de mensajes que se puede enviar o se puede recibir (o ambos) en esa ubicación (un contrato de servicio) que describe qué mensajes se pueden enviar. Un servicio de WCF se expone al mundo como una colección de extremos. extremo de aplicaciones Un extremo expuesto por la aplicación y que corresponde a un contrato de servicios implementado por la aplicación. extremo de infraestructura Un extremo que expone la infraestructura para facilitar la funcionalidad necesaria o proporcionada por el servicio que no se relaciona con un contrato de servicios. Por ejemplo, un servicio podría tener un extremo de la infraestructura que proporciona información de metadatos. dirección Una dirección especifica la ubicación donde se reciben los mensajes. Se especifica como un identificador uniforme de recursos (URI). La parte del esquema URI nombra el mecanismo de transporte que se ha de utilizar para alcanzar la dirección, como HTTP y TCP. La parte jerárquica del URI contiene una ubicación única cuyo formato depende del mecanismo de transporte. La dirección del extremo le permite crear direcciones únicas de extremo para cada extremo en un servicio o bajo ciertas condiciones compartir una dirección a lo largo de los extremos. El siguiente ejemplo muestra una dirección que utiliza el protocolo HTTPS con un puerto no predeterminado: enlace Un enlace define cómo se comunica un extremo con el mundo. Consta de un conjunto de componentes llamados elementos de enlace que se "apilan" uno sobre el otro para crear la infraestructura de comunicaciones. Como poco, un enlace define el transporte (como HTTP o TCP) y la codificación que se utiliza (como texto o binario). Un enlace puede contener elementos de enlace que especifican detalles como los mecanismos de seguridad utilizados para proteger los mensajes o el patrón de mensaje utilizado por un extremo.. elemento de enlace Un elemento de enlace representa una parte determinada del enlace, como un transporte, una codificación, una implementación de un protocolo del nivel de infraestructura (como WS- ReliableMessaging), o cualquier otro componente de la pila de comunicaciones. comportamientos Un comportamiento es un componente que controla varios aspectos en tiempo de ejecución de un servicio, un extremo, una operación determinada o un cliente. Los comportamientos están agrupados en función del ámbito: los comportamientos comunes afectan globalmente a todos los extremos, los comportamientos de servicios sólo afectan a los aspectos relacionados con servicios, los comportamientos de extremos sólo afectan a las propiedades relacionadas con los extremos y los comportamientos de operaciones afectan a las operaciones determinadas. Por ejemplo, un comportamiento del servicio está limitando que especifica cómo un servicio reacciona cuando un exceso de mensajes amenaza agobiar sus funciones del control. Un comportamiento de extremos, por otro lado, sólo controla los aspectos pertinentes a los extremos, como, por ejemplo, cómo y dónde encontrar una credencial de seguridad. enlaces proporcionados por el sistema WCF incluye varios enlaces proporcionados por el sistema. Éstas son colecciones de elementos de enlace que se optimizan para escenarios concretos. Por ejemplo, el WSHttpBinding está diseñado para la interoperabilidad con servicios que implementan varias especificaciones WS - *. Estos enlaces predefinidos ahorran tiempo al presentar sólo las opciones que se pueden aplicar correctamente al escenario en cuestión. Si un enlace predefinido no cumple sus requisitos, puede crear su propio enlace personalizado. configuración frente a codificación El control de una aplicación puede realizarse mediante codificación, configuración o a mediante una combinación de ambos. La configuración tiene la ventaja de que permite a alguien que no sea el programador (por ejemplo, un administrador de redes) establecer parámetros de servicios y clientes después de que el código esté escrito y sin tener que volver a compilar. La configuración no sólo le permite establecer valores como direcciones de extremos, sino que también proporciona control adicional al permitirle agregar extremos, enlaces y comportamientos. La codificación permite al desarrollador retener un control estricto sobre todos los componentes del servicio o cliente, y cualquier ajuste realizado a través de la configuración se puede inspeccionar y, si fuese necesario, podría invalidarse mediante el código. operación de servicio Una operación de servicio es un procedimiento definido en el código de un servicio que implementa la funcionalidad de una operación. Esta operación se expone a los clientes como métodos en un cliente de WCF. El método puede devolver un valor y puede tomar un número opcional de argumentos, o no tomar ningún argumento y no devolver ninguna respuesta. Por ejemplo, una operación que funciona como un simple "Hola" se puede utilizar para notificar acerca de la presencia de un cliente y para comenzar una serie de operaciones. contrato de servicio Todos los derechos reservados, prohibida la reproducción, Instituto Gala de Venezuela 9

10 El contrato de servicio une varias operaciones relacionadas en una unidad funcional única. El contrato puede definir ajustes de servicio, tales como el espacio de nombres del servicio, un contrato de devolución de llamada correspondiente y otros ajustes de este tipo. En la mayoría de los casos, el contrato se define mediante la creación de una interfaz en el lenguaje de programación que elija y la aplicación del atributo ServiceContractAttribute a la interfaz. El código de servicio real resulta mediante la implementación de la interfaz. contrato de operación Un contrato de operación define los parámetros y el tipo de valor devuelto de una operación. Al crear una interfaz que define el contrato de servicio, se significa un contrato de operación mediante la aplicación del atributo OperationContractAttribute a cada definición de método que forma parte del contrato. Las operaciones se pueden modelar como tomar un mensaje único y devolver un mensaje único, o como tomar un conjunto de tipos y devolver un tipo. En el último caso, el sistema determinará el formato de los mensajes que han de intercambiarse para esa operación. contrato de mensaje Un contrato de mensaje describe el formato de un mensaje. Por ejemplo, declara si los elementos del mensaje deberían ir en encabezados frente al cuerpo, qué nivel de seguridad debería aplicarse a qué elementos del mensaje, etc. contrato de error Un contrato de error puede estar asociado a una operación de servicio para denotar errores que se pueden devolver al llamador. Una operación puede tener cero o más errores asociados a ella. Estos errores son errores de SOAP que se modelan como excepciones en el modelo de programación. contrato de datos Los tipos de datos que utiliza un servicio se deben describir en metadatos para permitir a otros interoperar con el servicio. Las descripciones de los tipos de datos se conocen como el contrato de datos y los tipos se pueden utilizar en cualquier parte de un mensaje, por ejemplo, como parámetros o tipos de valores devueltos. Si el servicio sólo utiliza tipos simples, no hay ninguna necesidad de utilizar explícitamente contratos de datos. alojamiento Un servicio se debe alojar en algún proceso. Un host es una aplicación que controla la duración del servicio. Los servicios pueden autoalojarse o un proceso de alojamiento existente puede administrarlos. servicio autoalojado Un servicio autoalojado es aquel que se ejecuta dentro de una aplicación de proceso que el desarrollador creó. El desarrollador controla su duración, establece las propiedades del servicio, abre el servicio (que lo establece en un modo de escucha) y cierra el servicio. proceso de alojamiento Un proceso de alojamiento es una aplicación que está diseñada para alojar servicios. Entre ellos se incluyen Internet Information Services (IIS), Windows Activation Services (WAS) y Windows Services. En estos escenarios alojados, el host controla la duración del servicio. Por ejemplo, mediante IIS puede preparar un directorio virtual que contenga el ensamblado de servicio y archivo de configuración. Cuando se recibe un mensaje, IIS inicia el servicio y controla su duración. creación de instancias Un servicio tiene un modelo de creación de instancias. Hay tres modelos de creación de instancias: "único" en el que un objeto CLR único repara todos los clientes; "por llamada", en el que un nuevo objeto CLR se crea para administrar cada llamada de cliente; y "por sesión", en la que se crea un conjunto de objetos CLR, uno para cada sesión individual. Para elegir un modelo de creación de instancias se han de tener en cuenta los requisitos de aplicación y el patrón de uso esperado del servicio. aplicación de cliente Una aplicación de cliente es un programa que intercambia mensajes con uno o más extremos. La aplicación de cliente comienza creando una instancia de un cliente de WCF y llamando métodos del cliente de WCF. Es importante tener en cuenta que una única aplicación pueda ser cliente y servicio. canal Un canal es una implementación concreta de un elemento de enlace. El enlace representa la configuración y el canal es la implementación asociada a esa configuración. Hay por consiguiente, un canal asociado a cada elemento de enlace. Los canales se apilan uno sobre otro para crear la implementación concreta del enlace: la pila de canales. cliente WCF Un cliente de WCF es una construcción de la aplicación cliente que expone las operaciones de servicio como métodos (en el lenguaje de programación.net Framework de su elección, como Visual Basic o Visual C#). Cualquier aplicación puede alojar a un cliente de WCF, incluso una aplicación que aloje un servicio. Por consiguiente, es posible crear un servicio que incluya clientes de WCF de otros servicios. Un cliente de WCF se puede generar automáticamente utilizando ServiceModel Metadata Utility Tool (Svcutil.exe) y señalándolo hacia un servicio en ejecución que publique metadatos. metadatos Los metadatos de un servicio describen las características del servicio que una entidad externo necesita entender para comunicarse con el servicio. ServiceModel Metadata Utility Tool (Svcutil.exe) puede Todos los derechos reservados, prohibida la reproducción, Instituto Gala de Venezuela 10

11 utilizar los metadatos para generar un cliente de WCF y la configuración que lo acompaña que puede usar una aplicación cliente para interactuar con el servicio. Los metadatos expuestos por el servicio incluyen documentos de esquema XML, que definen el contrato de datos del servicio, y documentos WSDL, que describe los métodos del servicio. Cuando se habilita, WCF genera automáticamente los metadatos para el servicio mediante la inspección del servicio y sus extremos. Para publicar los metadatos desde un servicio, debe permitir explícitamente al comportamiento de los metadatos. seguridad La seguridad en WCF incluye confidencialidad (cifrado de mensajes para evitar las escuchas no autorizadas), integridad (los recursos para la detección de manipulación del mensaje), autenticación (los recursos para la validación de servidores y clientes) y autorización (el control del acceso a los recursos). Estas funciones se proporcionan mediante la reutilización de mecanismos de seguridad existentes, como TLS sobre HTTP (también conocido como HTTPS) o la implementación de una o más de las numerosas especificaciones de seguridad WS - *. modo de seguridad de transporte La seguridad se puede proporcionar mediante uno de estos tres modos: modo de transporte, modo de seguridad de mensaje y transporte con modo de credencial de mensajes. El modo de seguridad de transporte especifica que los mecanismos de la capa de transporte (como HTTPS) proporcionan la confidencialidad, integridad y autenticación. Al utilizar un transporte como HTTPS, este modo tiene la ventaja de ser eficaz en su rendimiento y bien entendido debido a su predominio en Internet. La desventaja es que este tipo de seguridad se aplica por separado en cada salto en la ruta de comunicación, provocando que la comunicación sea susceptible a un ataque tipo man in the middle. modo de seguridad de mensajes El modo de seguridad de mensajes especifica que la seguridad se proporciona mediante la implementación de una o más especificaciones de seguridad, como la especificación denominada "Seguridad de los servicios Web: seguridad de mensajes SOAP (disponible en LinkId=94684). Cada mensaje contiene los mecanismos necesarios para proporcionar la seguridad durante su tránsito y para permitir que los receptores detecten la manipulación y el descifrado de mensajes. En este sentido, la seguridad se encapsula dentro de cada mensaje, proporcionando una seguridad de extremo a extremo en varios saltos. Dado que la información de seguridad se vuelve parte del mensaje, también es posible de incluir varios tipos de credenciales con el mensaje (se las conoce como demandas). Este enfoque también tiene la ventaja de permitir al mensaje viajar de manera segura en cualquier transporte, incluidos varios transportes entre su origen y destino. La desventaja de este enfoque es la complejidad de los mecanismos de cifrado empleados, que afectan al rendimiento. transporte con modo de seguridad de credencial de mensajes Este modo utiliza la capa de transporte para proporcionar la confidencialidad, autenticación e integridad de los mensajes, mientras que cada uno de los mensajes puede contener varias credenciales (demandas) requeridas por los receptores del mensaje. WS-* Modo abreviado para el creciente conjunto de especificaciones de servicios Web (WS), tales como WS- Security, WS-ReliableMessaging, etc., que se implementan en WCF. Arquitectura de Windows Communication Foundation El gráfico siguiente muestra las capas principales de la arquitectura Windows Communication Foundation (WCF). Arquitectura de WCF Todos los derechos reservados, prohibida la reproducción, Instituto Gala de Venezuela 11

12 Ciclo de vida de una aplicación WCF Las tareas básicas que se van a realizar son, en orden: 1. Definir el contrato de servicios. Un contrato de servicios especifica la firma de un servicio, los datos que intercambia y otros datos necesarios contractualmente. 2. Implementar el contrato de servicio. Para implementar un contrato de servicios, cree la clase que implementa el contrato y especifique comportamientos personalizados que debería tener el tiempo de ejecución. 3. Configure el servicio especificando información de extremo y otra información de comportamiento. 4. Hospede el servicio en una aplicación. 5. Generación de una aplicación de cliente. Todos los derechos reservados, prohibida la reproducción, Instituto Gala de Venezuela 12

13 LECCION 2 Definir contratos de servicio Los contratos definen varios aspectos del sistema de mensajes. El contrato de servicios especifica las firmas de método actuales del servicio y se distribuye como una interfaz en uno de los lenguajes de programación compatibles, como Visual Basic o Visual C#. El contrato de servicio une varias operaciones relacionadas en una unidad funcional única. El contrato puede definir ajustes de servicio, tales como el espacio de nombres del servicio, un contrato de devolución de llamada correspondiente y otros ajustes de este tipo. En la mayoría de los casos, el contrato se define mediante la creación de una interfaz en el lenguaje de programación que elija y la aplicación del atributo ServiceContractAttribute a la interfaz. El código de servicio real resulta mediante la implementación de la interfaz. Al crear un servicio WCF básico, la primera tarea es definir un contrato. El contrato especifica qué operaciones admite el servicio. Una operación se puede considerar un método de servicio web. Los contratos se crean mediante la definición de una interfaz de C++, C# o VB. Cada método de la interfaz se corresponde con una operación de servicio concreta. Cada interfaz debe tener ServiceContractAttribute aplicado y cada operación debe tener OperationContractAttribute aplicado. Si un método de una interfaz que tiene ServiceContractAttribute no tiene OperationContractAttribute, no se expone ese método. Ejemplo Este ejemplo muestra un contacto del servicio con operaciones de servicio unidireccionales. El cliente no espera a que se completen las operaciones de servicio como en el caso de las operaciones de servicio bidireccionales. Este ejemplo utiliza el enlace wshttpbinding. El servicio en este ejemplo es una aplicación de consola autohospedada que le permite observar el servicio que recibe y procesa las solicitudes. El cliente es también una aplicación de consola. Para crear un contrato de servicio unidireccional, defina su contrato de servicio, aplique la clase OperationContractAttribute a cada operación y establezca IsOneWay en true, tal y como se muestra en el código de ejemplo siguiente: [ServiceContract(Namespace=" public interface IOneWayCalculator [OperationContract(IsOneWay=true)] void Add(double n1, double n2); [OperationContract(IsOneWay = true)] void Subtract(double n1, double n2); [OperationContract(IsOneWay = true)] void Multiply(double n1, double n2); [OperationContract(IsOneWay = true)] void Divide(double n1, double n2); Para mostrar que el cliente no espera a que las operaciones de servicio se completen, el código de servicio en este ejemplo implementa un retraso de cinco segundos, tal y como se muestra en el código de ejemplo siguiente: / This service class implements the service contract. // This code writes output to the console window. [ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple, InstanceContextMode = InstanceContextMode.PerCall)] public class CalculatorService : IOneWayCalculator public void Add(double n1, double n2) Console.WriteLine("Received Add(0,1) - sleeping", n1, n2); System.Threading.Thread.Sleep(1000 * 5); double result = n1 + n2; Console.WriteLine("Processing Add(0,1) - result: 2", n1, n2, result);... Cuando el cliente llama al servicio, la llamada se devuelve sin esperar a que la operación de servicio se complete. Al ejecutar el ejemplo, las actividades del servicio y del cliente se muestran en las ventanas de la consola del cliente y del servicio. Puede ver los mensajes recibidos por el servicio desde el cliente. Presione ENTRAR en cada ventana de la consola para cerrar el servicio y el cliente. Todos los derechos reservados, prohibida la reproducción, Instituto Gala de Venezuela 13

14 El cliente finaliza delante del servicio, mostrando que un cliente no espera a que las operaciones de servicio unidireccional se completen. El resultado del cliente es el siguiente: Add(100,15.99) Se muestra el siguiente resultado del servicio: The service is ready. Press <ENTER> to terminate service. Received Add(100,15.99) - sleeping Processing Add(100,15.99) - result: El contrato de servicios y el contrato de datos se definen en el archivo de código fuente generatedclient.cs, que genera Service Metadata Utility Tool (Svcutil.exe) desde los metadatos del servicio. LECCION 3 Definir contratos de datos Los contratos definen varios aspectos del sistema de mensajes. El contrato de datos describe cada parámetro que constituye cada mensaje que un servicio puede crear o utilizar. Los documentos de Lenguaje de definición de esquemas XML (XSD) definen los parámetros de mensaje, permitiendo a cualquier sistema que entienda XML procesar los documentos. Los contratos de datos le permiten pasar los datos estructurados hacia y desde los servicios Se deben aplicar los atributos DataContractAttribute y DataMemberAttribute Ejemplo DataContractAttribute y los atributos DataMemberAttribute se han aplicado a la definición de la clase ComplexNumber para indicar qué campos de la clase se pueden pasar a través de la conexión entre el cliente y el servicio, como se muestra en el código muestra siguiente. [DataContract(Namespace=" public class ComplexNumber [DataMember] public double Real = 0.0D; [DataMember] public double Imaginary = 0.0D; public ComplexNumber(double real, double imaginary) this.real = real; this.imaginary = imaginary; El contrato de servicios para este servicio utiliza números complejos, como se muestra en el código muestra siguiente. // Define a service contract. [ServiceContract(Namespace=" public interface ICalculator [OperationContract] ComplexNumber Add(ComplexNumber n1, ComplexNumber n2); [OperationContract] ComplexNumber Subtract(ComplexNumber n1, ComplexNumber n2); [OperationContract] ComplexNumber Multiply(ComplexNumber n1, ComplexNumber n2); Todos los derechos reservados, prohibida la reproducción, Instituto Gala de Venezuela 14

15 [OperationContract] ComplexNumber Divide(ComplexNumber n1, ComplexNumber n2); La implementación del servicio calcula y devuelve los resultados adecuados, aceptando y devolviendo números del tipo ComplexNumber. // This is the service class that implements the service contract. public class CalculatorService : ICalculator public ComplexNumber Add(ComplexNumber n1, ComplexNumber n2) return new ComplexNumber(n1.Real + n2.real, n1.imaginary + n2.imaginary); public ComplexNumber Subtract(ComplexNumber n1, ComplexNumber n2) return new ComplexNumber(n1.Real - n2.real, n1.imaginary - n2.imaginary); public ComplexNumber Multiply(ComplexNumber n1, ComplexNumber n2) double real1 = n1.real * n2.real; double imaginary1 = n1.real * n2.imaginary; double imaginary2 = n2.real * n1.imaginary; double real2 = n1.imaginary * n2.imaginary * -1; return new ComplexNumber(real1 + real2, imaginary1 + imaginary2); public ComplexNumber Divide(ComplexNumber n1, ComplexNumber n2) ComplexNumber conjugate = new ComplexNumber(n2.Real, -1*n2.Imaginary); ComplexNumber numerator = Multiply(n1, conjugate); ComplexNumber denominator = Multiply(n2, conjugate); return new ComplexNumber(numerator.Real / denominator.real, numerator.imaginary); La implementación del cliente también utiliza números complejos. El contrato de servicios y el contrato de datos se definen en el archivo de código fuente generatedclient.cs, que genera Service Metadata Utility Tool (Svcutil.exe) desde los metadatos del servicio (Esto se revisará más adelante en los proxys). Al ejecutar el ejemplo, las solicitudes y respuestas de la operación se muestran en la ventana de la consola del cliente. Presione Entrar en la ventana de cliente para cerrar el cliente. Add(1 + 2i, 3 + 4i) = 4 + 6i Subtract(1 + 2i, 3 + 4i) = i Multiply(2 + 3i, 4 + 7i) = i Divide(3 + 7i, i) = i Press <ENTER> to terminate client. Todos los derechos reservados, prohibida la reproducción, Instituto Gala de Venezuela 15

16 LECCION 4 Definir contratos de operaciones Un contrato de operación define los parámetros y el tipo de valor devuelto de una operación. Al crear una interfaz que define el contrato de servicio, se coloca la firma de un contrato de operación mediante la aplicación del atributo OperationContractAttribute a cada definición de método que forma parte del contrato. Las operaciones se pueden modelar como tomar un mensaje único y devolver un mensaje único, o como tomar un conjunto de tipos y devolver un tipo. En el último caso, el sistema determinará el formato de los mensajes que han de intercambiarse para esa operación. Las operaciones son los métodos en los contratos de servicios. Se basan en el modelo de interfaces. En la Sección de Contrato de Servicios se ejemplificaron claramente los contratos de operaciones LECCION 5 Definir contratos de mensajes La capa de la mensajería se crea de canales. Un canal es un componente que procesa un mensaje de alguna manera, por ejemplo, autenticando un mensaje. Un conjunto de canales también se conoce como una pila de canales. Los canales funcionan en los mensajes y encabezados del mensaje. Esto es diferente de la capa en tiempo de ejecución del servicio, que se ocupa principalmente de procesar el contenido de los cuerpos de los mensajes. Hay dos tipos de canales: canales de transporte y canales de protocolo. Los canales de transporte leen y escriben mensajes de la red (o algún otro punto de la comunicación con el mundo externo). Algunos transportes utilizan un codificador para convertir los mensajes (que se representan como conjuntos de información XMLs) hacia y desde la representación de la secuencia de bytes utilizada por la red. Son ejemplos de transportes HTTP, canalizaciones con nombre, TCP y MSMQ. Son ejemplos de codificaciones XML y binario optimizado. Los canales de protocolo implementan protocolos de procesamiento de mensajes, a menudo leyendo o escribiendo encabezados adicionales en el mensaje. Los ejemplos de tales protocolos incluyen WS-Security y WS-Reliability. La capa de la mensajería muestra los posibles formatos y modelos de intercambio de los datos. WS-Security es una implementación de la especificación WS-Security que habilita la seguridad en la capa del mensaje. El canal de mensajería WS-Reliable habilita la garantía de entrega del mensaje. Los codificadores presentan una variedad de codificaciones que se pueden utilizar para satisfacer las necesidades del mensaje. El canal HTTP especifica que el Protocolo de transporte de hipertexto se utiliza para la entrega del mensaje. El canal TCP especifica de manera similar el protocolo TCP. El canal de flujo de transacciones rige los modelos de mensajes de transacción. El canal de la canalización con nombre habilita la comunicación entre procesos. El canal de MSMQ habilita la interoperación con aplicaciones MSMQ. Los contratos definen varios aspectos del sistema de mensajes. El contrato del mensaje define partes específicas del mensaje utilizando los protocolos SOAP y permite el control más fino sobre las partes del mensaje, cuando la interoperabilidad exige tal precisión. Estos contratos trabajan con los atributos MessageContractAttribute, MessageHeaderAttribute y MessageBodyMemberAttribute Ejemplo El ejemplo de contrato de mensaje predeterminado muestra un servicio donde un mensaje personalizado definido por el usuario se pasa a las operaciones de servicio y desde ellas. Este ejemplo implementa una interfaz de calculadora como un servicio con tipos. En lugar de las operaciones de servicio individuales para la suma, resta, multiplicación, este ejemplo pasa un mensaje personalizado que contiene a los operandos y el operador, y devuelve el resultado del cálculo aritmético. El cliente es un programa de la consola (.exe) e Internet Information Services (IIS) hospeda la biblioteca de servicio. La actividad del cliente es visible en la ventana de la consola. En el servicio, se define una única operación de servicio que acepta y devuelve mensajes personalizados de tipo MyMessage. Aunque en este ejemplo los mensajes de solicitud y respuesta son del mismo tipo, podrían ser desde luego contratos de mensaje diferentes si fuera necesario. Todos los derechos reservados, prohibida la reproducción, Instituto Gala de Venezuela 16

17 [ServiceContract(Namespace=" public interface ICalculator [OperationContract(Action=" ReplyAction=" MyMessage Calculate(MyMessage request); Se define el mensaje personalizado MyMessage en una clase anotada con los atributos MessageContractAttribute, MessageHeaderAttribute y MessageBodyMemberAttribute. Sólo se usa el tercer constructor en este ejemplo. Utilizar los contratos de mensaje le permite ejercer control completo sobre el mensaje SOAP. En este ejemplo, el atributo MessageHeaderAttribute se utiliza para colocar Operation en un encabezado SOAP. Los operandos N1, N2 y Result aparecen dentro del cuerpo de SOAP porque tienen el atributo MessageBodyMemberAttribute aplicado. [MessageContract] public class MyMessage private string operation; private double n1; private double n2; private double result; //Constructor - create an empty message. public MyMessage() //Constructor - create a message and populate its members. public MyMessage(double n1, double n2, string operation, this.n1 = n1; this.n2 = n2; this.operation = operation; this.result = result; double result) //Constructor - create a message from another message. public MyMessage(MyMessage message) this.n1 = message.n1; this.n2 = message.n2; this.operation = message.operation; this.result = message.result; [MessageHeader] public string Operation get return operation; set operation = value; [MessageBodyMember] public double N1 get return n1; set n1 = value; [MessageBodyMember] public double N2 get return n2; set n2 = value; Todos los derechos reservados, prohibida la reproducción, Instituto Gala de Venezuela 17

18 [MessageBodyMember] public double Result get return result; set result = value; La clase de implementación contiene el código para la operación de servicio Calculate. La clase CalculateService obtiene los operandos y el operador del mensaje de solicitud y crea un mensaje de respuesta que contiene el resultado del cálculo solicitado, tal y como se muestra en el código de ejemplo siguiente. // Service class which implements the service contract. public class CalculatorService : ICalculator // Perform a calculation. public MyMessage Calculate(MyMessage request) MyMessage response = new MyMessage(request); switch (request.operation) case "+": response.result = request.n1 + request.n2; break; case "-": response.result = request.n1 - request.n2; break; case "*": response.result = request.n1 * request.n2; break; case "/": response.result = request.n1 / request.n2; break; default: response.result = 0.0D; break; return response; El código de cliente generado para el cliente se creó con la herramienta Service Metadata Utility Tool (Svcutil.exe). La herramienta crea automáticamente los tipos de contratos de mensaje en el código de cliente generado si es necesario. La opción de comando /messagecontract puede especificarse para forzar la generación de los contratos de mensaje. svcutil.exe /n:" /o:client\generatedclient.cs El código de ejemplo siguiente muestra el cliente mediante el mensaje MyMessage. // Create a client with given client endpoint configuration CalculatorClient client = new CalculatorClient(); // Perform addition using a typed message. MyMessage request = new MyMessage(); request.n1 = 100D; request.n2 = 15.99D; request.operation = "+"; MyMessage response = ((ICalculator)client).Calculate(request); Console.WriteLine("Add(0,1) = 2", request.n1, request.n2, response.result); Todos los derechos reservados, prohibida la reproducción, Instituto Gala de Venezuela 18

19 Al ejecutar el ejemplo, se muestran los cálculos en la ventana de la consola del cliente. Presione ENTRAR en la ventana de cliente para cerrar el cliente. Add(100,15.99) = Subtract(145,76.54) = Multiply(9,81.25) = Divide(22,7) = Press <ENTER> to terminate client. En este punto, los mensajes definidos por el usuario personalizados han pasado entre la operación de cliente y de servicio. El contrato del mensaje definió que los operandos y los resultados estuvieran en el cuerpo del mensaje y que el operador estuviera en un encabezado del mensaje. Se puede configurar el registro de mensajes para observar esta estructura de mensaje. LECCION 6 Procesar mensajes genéricos Especificación de transferencia de datos en contratos de servicio Windows Communication Foundation (WCF) se puede ver como una infraestructura de mensajería. Las operaciones de servicio pueden recibir mensajes, procesarlos y enviarles mensajes. Los mensajes se describen mediante contratos de operaciones. Por ejemplo, considere el siguiente contrato: [ServiceContract] public interface IAirfareQuoteService [OperationContract] float GetAirfare(string fromcity, string tocity); Aquí, la operación GetAirfare acepta un mensaje con información sobre fromcity y tocityy, a continuación, devuelve un mensaje que contiene un número. Descripción de mensajes mediante parámetros La manera más simple de describir un mensaje consiste en utilizar una lista de parámetros y el valor devuelto. En el ejemplo anterior, los parámetros de cadena fromcity y tocity se utilizaron para describir el mensaje de solicitud y el valor devuelto flotante se utilizó para describir el mensaje de respuesta. Si el valor devuelto por sí solo no es suficiente para describir un mensaje de respuesta, se pueden utilizar parámetros out. Por ejemplo, la siguiente operación tiene fromcity y tocity en su mensaje de solicitud y un número junto con una moneda en su mensaje de respuesta: [OperationContract] float GetAirfare(string fromcity, string tocity, out string currency); Además, puede utilizar parámetros de referencia para hacer que un parámetro forme parte tanto del mensaje de solicitud como del de respuesta. Los parámetros deben ser de tipos que se pueden serializar (convertidos a XML). De manera predeterminada, WCF utiliza un componente llamada la clase DataContractSerializer para realizar esta conversión. Se admite la mayoría de datos primitivos (como int, string, float, y DateTime). Los tipos definidos por el usuario deben tener normalmente un contrato de datos. public interface IAirfareQuoteService [OperationContract] float GetAirfare(Itinerary itinerary, DateTime date); [DataContract] public class Itinerary [DataMember] public string fromcity; [DataMember] public string tocity; Todos los derechos reservados, prohibida la reproducción, Instituto Gala de Venezuela 19

20 De vez en cuando, el DataContractSerializer no es adecuado para serializar sus tipos. WCF admite un motor de serialización alternativo, XmlSerializer, que también puede utilizar para serializar parámetros. XmlSerializer le permite utilizar más control sobre el XML resultante mediante atributos como el XmlAttributeAttribute. Para pasar a utilizar XmlSerializer para una operación determinada o para el servicio completo, aplique el atributo XmlSerializerFormatAttribute a una operación o un servicio. Por ejemplo: [ServiceContract] public interface IAirfareQuoteService [OperationContract] [XmlSerializerFormat] float GetAirfare(Itinerary itinerary, DateTime date); public class Itinerary public string fromcity; public string tocity; [XmlAttribute] public bool isfirstclass; Para aislar los nombres de parámetro.net de los nombres de contrato, puede utilizar el atributo MessageParameterAttribute y utilizar la propiedad Name para establecer el nombre de contrato. Por ejemplo, el contrato de operación siguiente es equivalente al ejemplo mostrado anteriormente. [OperationContract] public float GetAirfare( [MessageParameter(Name= fromcity )] string origincity, [MessageParameter(Name= tocity )] string destinationcity); Descripción de mensajes vacíos Un mensaje de solicitud vacío se puede describir no teniendo ninguna entrada ni parámetro de referencia. Por ejemplo: [OperationContract] public int GetCurrentTemperature(); Un mensaje de respuesta vacío se puede describir teniendo un tipo de valor devuelto void y ningún resultado ni parámetro de referencia. Por ejemplo: [OperationContract] public void SetTemperature(int temperature); Esto es diferente de una operación unidireccional, como: [OperationContract(IsOneWay=true)] public void SetLightbulbStatus(bool ison); La operación SetTemperatureStatus devuelve un mensaje vacío. Puede devolver en su lugar un error si hay un problema al procesar un mensaje de entrada. La operación SetLightbulbStatus no devuelve nada. No hay ninguna manera de comunicar una condición de error de esta operación. Descripción de mensajes mediante el uso de contratos de mensaje Puede desear utilizar un tipo único para representar el mensaje completo. Aunque es posible de utilizar un contrato de datos para este propósito, la manera recomendada para ello consiste en utilizar un contrato de mensaje; esto evita niveles innecesarios de ajuste en el XML resultante. Además, los contratos de mensaje le permiten ejercer más control sobre los mensajes resultantes. Por ejemplo, puede decidir qué partes de información deberían estar en el cuerpo del mensaje y cuáles deberían estar en los encabezados del mensaje. En el siguiente ejemplo se muestra el uso de contratos de mensaje. [ServiceContract] public interface IAirfareQuoteService [OperationContract] Todos los derechos reservados, prohibida la reproducción, Instituto Gala de Venezuela 20