9. Taller de Formación.NET. Ing. Gustavo Guimerans A/C. Nicolás Sampietro A/C. Emiliano Martínez

Transcripción

1 9. Ing. Gustavo Guimerans A/C. Nicolás Sampietro A/C. Emiliano Martínez

2 Capa de acceso a datos 1 Introducción La capa que describe la agrupación lógica de las funcionalidades y componentes que acceden a los datos (fuentes de datos, como bases de datos relacionales o servicios web) en una aplicación se conoce como la capa de datos (data layer) Descripción General Este documento está basado en la segunda edición del libro Microsoft Application Architecture Guide [1]. Su lectura brinda una completa guía sobre el uso de las distintas tecnologías. Esta capa provee acceso a la información dentro del sistema y datos expuestos en la red. Expone interfaces genéricas que la capa de negocio puede consumir. La capa de datos usualmente incluye: Data Access components: estos componentes abstraen la lógica requerida para acceder a los almacenes de datos. Centralizan las funcionalidades comunes de acceso a datos con el objetivo de lograr una aplicación más simple de configurar y mantener.

3 Service agents: cuando un componente de negocio necesita acceder a datos que provee un servicio externo, es necesario implementar código. Los componentes que implementan esta actividad son los service agents. Permiten aislar la diversidad de requerimientos que imponen la llamada a estos servicios y brindan otros servicios como caching, soporte offline y un mapeo entre el formato de quien expone el servicio y la aplicación. 2 Consideraciones generales de diseño La capa de acceso a datos debe cumplir con los requerimientos de la aplicación: ser eficiente y segura, fácil de mantener y extender cuando hay cambios en los requerimientos de la capa de negocio. En este capítulo se describen los principales puntos generales a tener en cuenta al momento de diseñar la capa de acceso a datos. Elegir el tipo adecuado de tecnología depende de: el tipo de datos que se tengan que manejar, cómo se necesiten manipular. Abstraer. Implementar interfaces de acceso a datos con bajo acoplamiento. Encapsular las funcionalidades de acceso a datos en la capa de acceso a datos. La capa debe: Ocultar detalles de acceso a la fuente de datos. Ser responsable de: manejar las conexiones, generar consultas, mapear entidades de la aplicación a estructuras de datos. Decidir como mapear entidades de la aplicación a estructuras de datos. Dependerá básicamente del tipo de entidad que se use en la aplicación. Diseños comunes siguen enfoques: Patrones Domain Model Table Module. Frameworks Object/Relational Mapping (O/RM). Considerar estructuras de datos consolidadas. 555

4 Ej. Si se están exponiendo datos a través de servicios considerar Data Transfers Objects (DTOs). Decidir cómo se manejarán las conexiones. La capa de acceso a datos deberá crear y manejar todas las conexiones a fuentes de datos que requiera la aplicación. Es necesario elegir el método apropiado para almacenar y proteger la información de conexión, eventualmente mediante secciones encriptadas de archivos de configuración. Determinar cómo se manejarán las excepciones. La capa de acceso a datos deberá manejar las excepciones asociadas a operaciones CRUD (Create, Read, Update and Delete) con las fuentes de datos. Considerar riesgos de seguridad. Reducir tráfico muchas idas y vueltas. Considerar operaciones por lotes (batch) en simples sentencias SQL. Considerar los objetivos de escalabilidad y de performance. 3 Consideraciones especificas de diseño Al momento de desarrollar el diseño hay varios problemas comunes a considerarse. Estos problemas pueden categorizarse en aéreas especificas de diseño. Las aéreas donde más problemas existen son: Procesamiento por lotes (batch), Binary Large Objects (BLOBs), Conexiones, Formato de datos, Manejo de excepciones, Object Relational Mapping, Consultas, Procedimientos almacenados (Stored Procedures). Stored Procedures vs. Dynamic SQL Transacciones Validaciones XML. Por cada una de las aéreas, mencionadas anteriormente, existen varios puntos a considerar. A continuación se mencionan algunos ejemplos asociados a tecnologías específicas. En el capítulo 8 del libro [1] se describen cada uno de esos puntos. 3.1 Transacciones Microsoft SQL Server cada SQL ejecuta como una transacción individual (auto-commit transaction mode). Para clases del namespace System.Transactions, considerar usar el modo implícito provisto por el objeto TransactionScope. 3.2 XML Considerar usar XML readers y writers para acceder a datos XML (especialmente cuando sea mucho volumen). Si se desea interactuar con una base relacional, considerar usar objetos que soporten esa funcionalidad tales como ADO.NET DataSet. 4 Consideraciones tecnológicas 556 Una de las decisiones más importantes a tomar, al momento de implementar un sistema, pasa por la elección de la tecnología. La tecnología adecuada dependerá del tipo de aplicación y los requerimientos. A continuación, se mencionan casos concretos que ayudan a tomar una correcta decisión. Si se requiere soporte básico para consultas y parámetros, considerar directamente objetos ADO.NET.

5 Si se requiere soporte para escenarios de acceso a datos más complejos o simplificar el código de acceso a datos, considerar utilizar el Enterprise Library Data Access Application Block. Para aplicaciones Web data driven con páginas basadas en el modelo de datos de la base de datos, considerar utilizar ASP.NET Dynamic Data. Para manipular datos con formato XML, considerar usar clases en el namespace System. Xml, o Linq to XML (XLinq). Con interfaces ASP.NET, considerar DataReader para acceder a los datos con la máxima performance de renderizado. Ideales para operaciones read-only, forward-only. Para acceder a SQL Server, considerar ADO.NET la namespace SqlClient para maximizar performance. En SQL Server 2008, considerar FILESTREAM para una mayor flexibilidad en el almacenamiento y para acceder a datos BLOB. Si se diseña una capa de negocio orientada a objetos en el patrón Domain Model, considerar un framework Object/Relation Mapping (O/RM), tal como el ADO.NET Entity Framework o el NHibernate framework de código libre. 5 Diseñando componentes de datos En lo que resta de la lección se revisarán los pasos para el diseño de componentes asociados a datos. El primer paso es identificar las restricciones asociadas a los datos que se accederán, lo cual ayudará a identificar la tecnología de acceso a datos adecuada. El siguiente paso consiste en decidir la estrategia de mapeo y el enfoque de acceso a datos que se desea implementar, esto consiste en identificar las entidades de negocio y la forma de representarlas. Luego se puede determinar cómo los componentes de acceso a datos se conectarán a la fuente de datos. Finalmente, se determina la estrategia para manejo de excepciones en el acceso a datos. Es importante conocer con cuáles tecnologías se cuenta en la plataforma y para qué escenarios es mejor una que otra. De esta manera, se pueden tomar otras decisiones necesarias (por ejemplo: capacitación sobre determinada tecnología). Por tal motivo, se incluye en esta guía una descripción de las tecnologías disponibles. El sitio web de la Microsoft Developer Network (MSDN) [2] es el lugar indicado para utilizar como referencia en todo momento de un proyecto en la plataforma Microsoft, principalmente al momento de desarrollar, en particular para la plataforma.net Framework, ya que, por ejemplo, cuenta con documentación y ejemplos. 5.1 Paso 1 Seleccionar la tecnología de acceso a datos En este paso es que se hace necesario conocer las tecnologías disponibles en la plataforma Microsoft, cuándo es recomendable su uso, escenarios comunes, así como sus ventajas y consideraciones. A continuación se pretende llegar a cubrir estos puntos. Dada la importancia que tienen hoy en día ADO.NET Entity Framework (EF) y LINQ se profundizará. ADO.NET Core. Brinda facilidades para recuperar, alterar y administrar información. Incluye proveedores para bases de datos SQL Server, OLE DB, Open Database Connectivity (ODBC), SQL Server Compact Edition y Oracle. ADO.NET Data Services Framework. Este framework permite exponer información de cualquier fuente de datos Linq, típicamente un Entity Data Model, mediante REST sobre HTTP. La información puede direccionarse mediante Uniform Resource Identifiers (URIs). 557

6 Los servicios Web pueden configurarse para que retornen los datos con formato Atom y JavaScript Object Notation (JSON). ADO.NET Entity Framework (EF): es un conjunto de tecnologías ADO.NET que permiten el desarrollo de aplicaciones orientadas a datos. Brinda una experiencia de acceso fuertemente tipada sobre base de datos relacionales. Mueve datos desde el modelo de almacenamiento o lógico (las estructuras físicas de las tablas relacionales) al modelo conceptual (que refleja los objetos de negocio). Introduce Entity Data Model a ADO.NET [4]. Soporta LINQ to Entities. Permite que los programadores trabajen: con datos en forma de objetos y propiedades específicos del dominio; por ejemplo, con clientes y direcciones, sin tener que pensar en las tablas y columnas de las bases en las que se almacenan sino que consultan las entidades y relaciones en el modelo de dominio (modelo conceptual), basados en EF para traducir esas operaciones en los comandos específicos del origen. El modelo conceptual, el modelo de almacenamiento y las asignaciones entre los dos se expresan en esquemas basados en XML y se definen en archivos de extensiones correspondientes: El Conceptual Schema Definition Language (CSDL) define el modelo conceptual. Es la implementación de EF del Entity Data Model. La extensión de archivo es.csdl. El Store Schema Definition Language (SSDL) define el modelo de almacenamiento. La extensión de archivo es.ssdl. El Mapping Specification Language (MSL) define las asignaciones entre los modelos conceptual y de almacenamiento. La extensión de archivo es.msl. Estos modelos y archivos de asignación permiten a EF transformar las operaciones de creación, lectura, actualización y eliminación de las entidades y relaciones del modelo conceptual en las operaciones equivalentes en el origen de datos [4]. A continuación se muestra un ejemplo de cómo se pueden consultar tanto entidades como asociaciones [5]. 558

7 ADO.NET Sync Services. Es un proveedor incluido en el Microsoft Sync Framework y se utiliza para implementar sincronización en bases de datos embebidas en ADO.NET. Language Integrated Query (LINQ). Brinda librerías para extender C# y Visual Basic con lenguaje nativo para consultas. Es, primero que nada, una tecnología de consultas soportada por diferentes assemblies a través del.net Framework, por ejemplo: LINQ to Entities está incluido en los assemblies ADO.NET Entity Framework. LINQ to XML está incluido en los assemblies System.Xml. LINQ to Objects está incluido en.net Framework core system assemblies. Las consultas pueden ser ejecutadas para diferentes formatos, entre ellos: DataSet (LINQ to DataSet). XML (LINQ to XML). objetos de memoria (LINQ to Objects). ADO.NET Data Services (LINQ to Data Services). datos relacionales (LINQ to Entities). LINQ to SQL brinda una solución a consultas fuertemente tipada para SQL Server. Todas las operaciones de consulta LINQ se componen de tres acciones distintas. [6] Obtención del origen de datos. Creación de la consulta. Ejecución de la consulta. 559

8 La elección de una apropiada tecnología de acceso a datos debe tomar en cuenta el tipo de datos y cómo se manipularán. Ciertas tecnologías son mejores para determinados escenarios Escenarios de uso de aplicaciones 560 La siguiente guía pretende ser útil al momento de mapear escenarios de uso de aplicaciones con las soluciones tecnológicas de acceso a datos disponibles. ADO.NET Entity Framework (EF). Si se desea: crear un modelo de datos y mapearlo a una base de datos relacional, mapear una clase a múltiples tablas usando herencia, realizar consultas relacionales a almacenes que no sean de la familia Microsoft SQL Server. EF es apropiado cuando se tiene un modelo de objetos y se necesita mapear a un modelo relacional usando un esquema flexible, y se necesita la flexibilidad de separar el esquema mapeado del modelo de objetos. Si se usa EF considerar usar: LINQ to Entities: si es necesario, realizar consultas sobre las entidades fuertemente tipadas. ejecutar consultas sobre los datos relacionales usando sintaxis LINQ. ADO.NET Data Services Framework. Esta construido sobre EF y permite exponer parte del modelo entidad mediante una interfaz REST (URIs). Considerar su uso si se está desarrollando un RIA o una aplicación cliente en N-capas y se desea acceder a datos mediante una interfaz centralizada de recursos. ADO.NET Core. Considerarla si se necesita o desea: Usar una API de bajo nivel para mayor control sobre los datos. Aprovechar lo existente y convertirse en proveedores de ADO.NET. Se está utilizando un acceso lógico a la base de datos. Es apropiado si no se necesita de las funcionalidades que ofrecen las otras tecnologías de acceso a datos o se está implementando una aplicación que debe soportar experiencia de acceso a datos sin conexión. ADO.NET Sync Services. Considerarla si se está diseñando una aplicación que: Debe soportar eventuales escenarios de conexión. Requiere colaboración entre bases de datos. Windows Mobile, para el sincronizado contra una base de datos centralizada. LINQ to Data Services. Si se: utilizan datos en el cliente que retornan de ADO.NET Data Services, desean realizar consultas usando sintaxis. LINQ desde el cliente o vía REST. LINQ to DataSets. Si se desea: ejecutar consultas sobre un DataSet, incluyendo consultas que realicen joins de tablas; usar un lenguaje de consultas común en vez de código iterativo. LINQ to Entities. Si se está utilizando: ADO.NET Entity Framework. Consultas sobre entidades fuertemente tipadas.

9 consultas sobre datos relacionales usando sintaxis LINQ. LINQ to Objects. Consultas sobre: una colección, directorio de archivos, objetos en memoria usando sintaxis LINQ. LINQ to SQL. LINQ to Entities es la solución recomendada para utilizar LINQ en escenarios con una base de datos relacional. Si bien LINQ to SQL seguirá con soporte no será el foco de innovación o mejoras. Si ya se está utilizando LINQ to SQL se puede seguir usando. Para nuevas soluciones considerar el uso de LINQ to Entities en su lugar. LINQ to XML. Si se utilizan datos XML y se desea utilizar sintaxis LINQ para ejecutar consultas Beneficios y consideraciones de cada tecnología Acceso a datos Objeto-Relacional ADO.NET Entity Framework (EF) Beneficios Desacopla la estructura de datos del modelo de datos lógico. Entity SQL brinda un lenguaje consistente sobre todas las fuentes de datos y tipos de base de datos. Separa la metadata en capas de la arquitectura bien definidas. Brinda a los desarrolladores de la capa de negocios acceso a los datos sin necesidad de conocer particularidades (especificaciones) de la base de datos. Permite que el modelo sea mapeado a otras bases de datos. Consideraciones Requiere un cambio en el diseño de entidades y consultas si se trabajaba con un método tradicional. Tiene más niveles de abstracción que LINQ to DataSet. Se puede usar sin LINQ. Si la estructura de la base de datos cambia, es necesario regenerar el Entity Data Model y re-deployar las librerías del EF. LINQ to Entities Beneficios Una solución basada en LINQ para datos relacionales en el ADO.NET Entity Framework. Brinda acceso LINQ fuertemente tipado. El procesamiento se realiza del lado del servidor. Consideraciones Requiere ADO.NET Entity Framework. LINQ to SQL Beneficios 561

10 Lectura y escritura de modelo de datos como objetos cuando estos modelos coinciden. Brinda acceso LINQ fuertemente tipado. Procesamiento del lado del servidor. Consideraciones En.NET Entity Framework 4.0 se mapean consultas LINQ directamente a la base de datos en lugar de un provider. Trabaja solo con Microsoft SQL Server. Acceso a datos sin conexión. LINQ to DataSet Beneficios Permite realizar todo tipo de consultas sobre un DataSet. Consideraciones Todo el procesamiento se da en el cliente. ADO.NET Sync Services Beneficios Brinda sincronización entre bases de datos, escenarios de colaboración y sin conexión. La sincronización puede ejecutar en background. Consideraciones Hay que implementar el traqueo de cambios. Las grandes cantidades de datos pueden degradar notoriamente la performance. 562 SOA/Services ADO.NET Data Services Framework Beneficios Los datos pueden ser accedidos directamente mediante una URI usando un esquema REST y retornados tanto en formato Atom o JSON. El.NET Framework, Silverlight y las bibliotecas de cliente AJAX permiten trabajar directamente con objetos dando acceso LINQ a ADO.NET Data Services, así como una API para Windows Azure Tables, SQL Data Services, etc. Consideraciones Ideado para escenarios orientados a servicios. LINQ to Data Services Beneficios Permite crear consultas LINQ del lado del cliente y los datos se retornan de ADO.NET Data Services. Soporta consultas LINQ sobre datos REST. Consideraciones Requiere ADO.NET Data Services del lado del cliente. N-capas y genéricas ADO.NET Core Beneficios

11 Incluye código manejado de proveedores para acceder a varios almacenes de datos. Brinda facilidades para manipulación de datos. Consideraciones El código se escribe directamente para determinados proveedores, reduciendo la reusabilidad. La estructura de la base de datos puede implicar la creación de un modelo nuevo. LINQ to Objects Beneficios Permite crear consultas LINQ sobre objetos en memoria. Puede ser utilizado: Sobre cualquier colección que soporte IEnumerable o IEnumerable<T>. Para consultar strings, metadata basada en reflection y directorio de archivos. Consideraciones Soporte para objetos que implementen IEnumerable. LINQ to XML Beneficios Permite crear consultas LINQ sobre datos XML. Se compara con Document Object Model (DOM). Consideraciones No está optimizado para dar soporte a seguridad Consideraciones generales. Si se necesita o se está buscando máxima Flexibilidad y Performance, considerar usar ADO.NET Core. Una solución basada en O/RM o con soporte a múltiples bases de datos, considerar el Entity Framework, escenarios sin conexión, considerar usar DataSets o el Sync Framework. Un escenario N-capas donde: los datos pasen entre las capas, Data Transfer Objects (DTO), centralizar recursos (REST), ADO.NET Data Services, centralizar operaciones (SOAP), Windows Comunication Fundation (WCF). SOA Exponiendo la base de datos como un servicio, ADO.NET Data Services, almacenando la información en la nube, SQL Data Services. Microsoft Windows Mobile, considerar la base de datos SQL Server Compact Edition y ADO.NET Sync Services para mantener la información en el dispositivo móvil y sincronizarla con un mecanismo basado en el servidor. 563

12 5.2 Paso 2 Seleccionar como recuperar y persistir objetos de negocio desde un almacén de datos Luego de identificar los requerimientos de la fuente de datos, el próximo paso consiste en seleccionar la estrategia para poblar los objetos o entidades de negocio desde los almacenes de datos y persistirlos en las fuentes de datos. El enfoque más común usa herramientas o frameworks Object/Relational Mapping (O/RM). Al momento de mapear esas entidades a estructuras de datos, el principal factor para decidir cómo realizar ese mapeo es el tipo de entidades que utiliza la aplicación. 5.3 Paso 3 Determinar cómo conectarse a la fuente de datos Una vez que se tiene el mapeo, es necesario identificar como conectarse a la fuente de datos, proteger las credenciales de los usuarios y realizar transacciones. A continuación, se muestran los principales puntos a considerar (cada uno incluye varias consideraciones para lograr el enfoque adecuado) Conexiones Conexiones a fuentes de datos son una parte fundamental de la capa de datos. Debe coordinar todas las conexiones a la fuente de datos. Asegurarse de abrir las conexiones a la fuente de datos tan tarde como sea posible y se cierran tan pronto como sea posible. De esta forma, se asegura que el bloqueo sobre recursos es tan corto como sea posible y se queda libre para otro proceso. Si no se tienen datos volátiles, usar concurrencia optimista para mitigar el costo de bloquear datos en la base (evitando overhead). Realizar transacciones a través de una conexión cuando sea posible. Esto permite características de ADO.NET sin la necesidad de servicios coordinadores de transacciones distribuidas. Si se usa un pool, realizar una prueba de carga con escenarios simultáneos y tunear la performance basado en los resultados. Por razones de seguridad, evitar el uso de System o User Data Source Name (DSN) para almacenar la información de conexión. Diseñar la lógica de re-intento para manejar situaciones donde la conexión a la fuente de datos se pierda o de time-out. Ejecutar comandos por lotes (batch) en la base de datos, en la medida que sea posible, para evitar tráfico excesivo ( idas y vueltas ). Otro aspecto importante a considerar son los requerimientos de seguridad para acceder a la fuente de datos. En otras palabras: cómo se autenticarán los componentes de acceso a datos con la fuente de datos? Y cuáles son los requerimientos de seguridad? Preferible Autenticación Windows que SQL Server. Si se utiliza Microsoft SQL Server considerar utilizar autenticación Windows con subsistema confiable Pooles de Conexión Los pooles de conexión permiten que aplicaciones vuelvan a usar conexiones de un pool, o crear una nueva y agregarla al pool si no hay una conexión disponible. Cuando una aplicación cierra la conexión esta se devuelve al pool, pero la conexión permanece abierta. Esto

13 significa que ADO.NET no necesita crear una nueva conexión y abrirla contra la fuente de datos todo el tiempo. Si bien consumen recursos, reducen los delays asociados al acceso a datos y hacen que las aplicaciones corran más eficientes cuando hay conexiones disponibles Transacciones y concurrencia Considerar formar transacciones con las operaciones críticas para el negocio. En general, se pueden seleccionar entre tres tipos de transacciones: System.Transactions namespace classes, brindadas como parte del.net Framework con soporte a transacciones implícitas y explicitas. Considerar su uso si se está desarrollando una aplicación nueva que requiera soporte de transacciones. Para la mayoría de las transacciones, el enfoque recomendado es usar el modelo implícito que brinda el objeto TransactionScope en el namespace System.Transaction. Si bien no son tan rápidas como las manuales, o explicitas, son más fáciles de desarrollar y se logran soluciones flexibles y mantenibles. ADO.NET Transactions basadas en una conexión simple. Este es el enfoque más eficiente para transacciones controladas por clientes en un único almacén de datos. Considerar su uso si se está extendiendo una aplicación que ya utilizaba esta tecnología o se esté desarrollando para un entorno que no soporte la versión 2.0 del Framework.NET T-SQL (Database) Transactions controladas por comandos ejecutados en la base de datos. Son más eficientes para transacciones controladas por el servidor en un único almacén de datos, donde la base de datos gestiona toda la transacción. Considerar esta tecnología en el desarrollo de stored procedures que encapsulan todos los cambios que debe manejar la transacción o que usan varias aplicaciones, y los requerimientos de la transacción se pueden encapsular en él. 5.4 Paso 4 Determinar la estrategia para manejo de errores en el acceso a fuentes de datos No deberían pasar para otra capa, salvo que afecten a la aplicación o alguna funcionalidad. 5.5 Paso 5 Diseñar Service Agent Objetcts (opcional) Objetos que manejan la semántica de comunicación con servicios externos. 6 Bibliografía Microsoft, Microsoft Application Architecture Guide, 2nd Edition. Patterns & Practices, Sitio Web de la MSDN. [Online]. Available: [Accessed: 01- Oct-2011]. Tutorial rápido (Entity Framework) [Online]. Available: [Accessed: 5-Aug-2011]. Información general de Entity Framework [Online]. Available: com/es-es/library/bb aspx [Accessed: 5-Aug-2011]. Consultar entidades y asociaciones. [Online]. Available: [Accessed: 22-Aug-2011]. Introducción a las consultas LINQ. [Online]. Available: [Accessed: 1-Jul-2011]. 565

14 Windows Communication Foundation Qué es Windows Comunication Foundation (WCF) 566 El uso global de Web Services ha cambiado la forma en que se desarrollan las aplicaciones. Por ejemplo, las funciones que los Web Services proveen en la actualidad incluyen: seguridad, coordinación de transacciones distribuidas y comunicaciones confiables. Windows Communication Foundation (WCF) esta diseñado para ofrecer un enfoque administrable a la computación distribuida, la interoperabilidad y, en definitiva, la arquitectura orientada a servicios. En otras palabras Windows Communication Foundation (WCF) es un framework 1 para la creación de aplicaciones basadas en servicios. Utilizando WCF se puede enviar información como mensajes asíncronos desde un lugar a otro. Este lugar se denomina endpoint. Un endpoint son lugares donde los mensajes son enviados o recibidos (o ambos) y definen toda la información necesaria para el intercambio de mensajes. Un endpoint puede ser parte de un servicio alojado en el Internet Information Server (IIS) o puede ser un servicio alojado en una aplicación. Un endpoint puede ser un cliente de un servicio que solicita información a otro endpoint. Los mensajes pueden ser tan simples como un único carácter o palabra enviado como un XML o tan complejos como una secuencia de datos binarios. Algunos escenarios de ejemplo pueden ser los siguientes: Un servicio de seguridad que procesa transacciones bancarias. Un servicio que provee información a otros servicios, como ser reportes de tráfico o algún otro servicio de monitoreo. Un servicio de chat que permite a dos personas comunicarse o intercambiar información en tiempo real. La inclusión de esta tecnología no implica que antes de su existencia no se podían desarrollar este tipo de servicios, todo lo contrario, pero WCF hace que el desarrollo de los endpoints sea mucho más sencillo. En resumen, WCF esta diseñado para ofrecer un enfoque más sencillo a la creación de Web Services (servicios web) y clientes de Web Services. Ejemplo ilustrativo de la utilización de WCF El siguiente ejemplo ilustra algunos de los problemas que WCF aborda. Una compañía de renta de autos decide crear una nueva aplicación de reservas. Los diseñadores de esta nueva aplicación saben que la lógica de negocio debe ser accedida por otras aplicaciones ejecutadas 1 En el desarrollo de software, un framework o infraestructura digital, es una estructura conceptual y tecnológica de soporte definido, normalmente con artefactos o módulos de software concretos, con base a la cual otro proyecto de software puede ser más fácilmente organizado y desarrollado.

15 dentro y afuera de la compañía. En consecuencia, deciden diseñar una arquitectura orientada a servicios, con la lógica de la aplicación expuesta a través de un conjunto bien definido de servicios. Los diseñadores saben que, al momento de crear la aplicación, la misma será accedida por, al menos, otras tres aplicaciones. 1. Una aplicación cliente de call center que se ejecuta en máquinas cuyo sistema operativo es Windows y es usada por empleados dentro de la organización. Esta aplicación será creada especialmente para el nuevo sistema de reserva y usará también el framework.net y WCF. 2. Una aplicación existente de reservas hecha en J2EE ejecutando en un servidor Windows dentro de la compañía. Debido a una reciente asociación con otra firma de renta de autos la aplicación existente debe poder acceder a la lógica de la nueva aplicación y proveer a los clientes una experiencia unificada. 3. Aplicaciones de firmas de socios ejecutando en un conjunto variado de plataformas, esto incluye: agencias de viaje, aerolíneas y cualquier compañía que tenga la necesidad de crear reservas de renta de autos. Este es un escenario perfectamente realista y representa algunos desafíos. Para la interacción con el Call Center, por ejemplo, la velocidad de respuesta es importante, mientras que la interoperabilidad es directa (comunicación.net a.net). Para la comunicación con la aplicación existente de reservas hecha en J2EE o las aplicaciones de las firmas socios, la interoperabilidad se convierte en el objetivo primario. Los requerimientos de seguridad son también muy diferentes, desde una comunicación entre máquinas en una intranet Windows (Active Directory) a máquinas ejecutando en lugares remotos en otros sistemas operativos. WCF esta diseñado para abordar éste y otros escenarios diversos pero realistas. 567

16 Arquitectura de una aplicación típica WCF Arquitectura típica de una aplicación empresarial, mostrando la capa de servicios. La capa de servicios comúnmente debe incluir: 568 Interfaz de servicios. El servicio expone una interfaz donde los mensajes entrantes son enviados. La interfaz de servicios se puede pensar como una fachada que expone la lógica de negocio implementada en la aplicación. Tipos de mensajes. Cuando se intercambian datos a través de la capa de servicios las estructuras de datos son empaquetados en mensajes que soportan distintos tipos de operación. La capa de servicios, típicamente, va a definir tipos de datos y contratos que se usan en los mensajes. Comenzar a trabajar con WCF A lo largo de este documento vamos a repasar ordenadamente los pasos que se necesitan para crear aplicaciónes WCF y sus clientes. Un servicio es una entidad que expone uno o mas endpoints cada uno de los cuales expone una o más operaciones de servicio. El endpoint de un servicio especifica la dirección (Address) donde el servicio puede ser ubicado, un elemento (Binding) que indica el tipo de comunicación que se va a establecer y un contrato (Contract) que define la funcionalidad que provee el servicio a sus clientes.

17 Esto es comúnmente llamado el ABC : Address Binding Contract Veamos ahora cómo definir un servicio WCF con un contrato, cómo implementar el servicio, cómo configurarlo y, por último, cómo ejecutarlo. Esto se desarrollará en seis pasos. 1. Cómo definir un contrato de un servicio WCF Cuando se crea un servicio básico en WCF la primera tarea es definir el contrato. El contrato especifica cuáles operaciones tendrá el servicio. Los contratos son creados definiendo una interfaz en C++, C# o Visual Basic. Cada método en la interfaz corresponde a una operación específica del servicio. Cada interfaz debe contener el atributo ServiceContractAttribute y cada operación debe contener el atributo OperationContractAttribute. Si un método dentro de una interfaz no contiene el atributo antes mencionado, dicho método no será expuesto por el servicio. Los pasos para la creación del contrato son los siguientes: 1. Abra Visual Studio 2010 como administrador haciendo clic con el botón secundario en el programa en el menú Inicio y seleccionando Ejecutar como Administrador. 2. Cree un nuevo proyecto de aplicación de consola. Haga clic en el menú Archivo y seleccione Nuevo, Proyecto. En el cuadro de diálogo Nuevo proyecto, seleccione Visual C#. Elija la plantilla Aplicación de consola y denomínela Service. Use la ubicación predeterminada. 3. En un proyecto, Visual Studio crea un archivo denominado Program.cs. Esta clase contendrá un método vacío denominado Main(). 4. Cambie el espacio de nombres (namespace) Service predeterminado a Microsoft.ServiceModel.Samples. Para ello, haga clic con el botón secundario en el proyecto en el Explorador de soluciones y seleccione Propiedades. Asegúrese de que esté seleccionada la pestaña Aplicación situada a la izquierda del cuadro de diálogo Propiedades. Luego, escriba Microsoft.ServiceModel.Samples en el cuadro de edición que tiene la etiqueta Espacio de nombres predeterminado. Haga clic en el menú Archivo y seleccione Guardar todo para guardar los cambios. 5. Luego, cambie el espacio de nombres en el archivo Program.cs generado a Microsoft. ServiceModel.Samples como se muestra en el siguiente ejemplo: 569

18 6. Agregue una referencia a System.ServiceModel.dll al proyecto. a. En el Explorador de soluciones, haga clic con el botón secundario en la carpeta Referencias bajo la carpeta del proyecto y elija Agregar referencia. b. Seleccione la pestaña.net en el cuadro de diálogo Agregar referencia y desplácese hacia abajo hasta que vea System.ServiceModel (versión ), selecciónelo y haga clic en Aceptar. 7. Agregue una instrucción using para el espacio de nombres System.ServiceModel.using System.ServiceModel. 8. Defina una nueva interfaz denominada ICalculator y aplique el atributo ServiceContractAttribute a la interfaz con un valor de Namespace de Samples. Especificar el espacio de nombres explícitamente es un procedimiento recomendado porque evita que el valor de espacio de nombres predeterminado se agregue al nombre del contrato. 9. Declare un método para cada una de las operaciones que el contrato ICalculator expone (suma, resta, multiplicación y división) dentro de la interfaz y aplique el atributo OperationContractAttribute a cada método que desee exponer como parte del contrato público de WCF. El siguiente código unificará el resultado obtenido al realizar cada uno de los pasos detallados anteriormente: 570

19 2. Cómo implementar un contrato de servicio de Windows Communication Foundation Ésta es la segunda de las seis tareas que son necesarias para crear un servicio básico en Windows Communication Foundation (WCF) y un cliente que llame al servicio. La creación de un servicio WCF requiere que se cree primero el contrato, que se define mediante una interfaz, esta tarea fue realizada en la sección anterior. El siguiente paso, mostrado en este ejemplo, es implementar la interfaz. Esto implica la creación de una clase denominada CalculatorService que implemente la interfaz ICalculator definida por el usuario. Los pasos para la implementación de la interfaz son los siguientes: 1. Cree una nueva clase denominada CalculatorService en el mismo archivo donde definió la interfaz ICalculator. CalculatorService implementa la interfaz ICalculator. public class CalculatorService: ICalculator 2. Implemente cada método definido en la interfaz ICalculator dentro de la clase CalculatorService. El siguiente ejemplo de código muestra la interfaz que define el contrato de servicio y la implementación de la interfaz. Es decir, se despliega tanto el código escrito en la sección anterior como en la presente: 571

20 Ahora, el contrato de servicio se ha creado e implementado. Compile la solución para asegurarse de que no hay ningún error de compilación y, a continuación, continúe en Procedimiento para hospedar y ejecutar un servicio básico de Windows Communication Foundation para ejecutar el servicio. 572 Para compilar el código diríjase al menú Generar, haga clic en Generar solución.