Qu es ndigo Seleccionar las mejores abstracciones para crear software es un proceso que no finaliza nunca.

Actualmente, los objetos constituyen el enfoque dominante en la creacin de la lgica empresarial de una aplicacin, pero el modelado de la comunicacin entre aplicaciones mediante objetos no ha obtenido los resultados deseados. Un enfoque ms adecuado consiste en modelar especficamente las interacciones entre fragmentos discretos de software como servicios. Ya hay bastantes medios para crear aplicaciones orientadas a objetos, pero la idea de considerar los servicios como unidades de creacin de software resulta ms novedosa. Por este motivo, en general apenas hay tecnologas disponibles diseadas especficamente para crear aplicaciones orientadas a servicios. El marco de Microsoft para crear aplicaciones orientadas a servicios, cuyo nombre en clave es Indigo, cambia esta situacin. Indigo permite a los desarrolladores que actualmente crean aplicaciones orientadas a objetos con .NET Framework crear tambin aplicaciones orientadas a servicios de una manera similar. Adems, para permitir que estas aplicaciones interaccionen de manera eficaz con el software que se ejecuta en Windows y en otras plataformas, Indigo implementa SOAP y otras tecnologas de servicios Web, lo que permite a los desarrolladores crear servicios confiables, seguros y transaccionales que pueden interoperar con software ejecutado en cualquier sistema.

La figura muestra una vista sencilla de un cliente y servicio de Indigo. Indigo proporciona los cimientos, implementados principalmente como un conjunto de clases que se ejecutan en Common Language Runtime (CLR), para crear los servicios a los que tendrn acceso los clientes. Un cliente y un servicio interactan a travs de SOAP, el protocolo nativo de Indigo y, aunque la figura muestra ambas partes creadas con Indigo, en realidad no es necesario. Indigo es una extensin que se basa en .NET Framework 2.0, cuyo lanzamiento est previsto para 2005 como parte de la versin Windows cuyo nombre clave es Longhorn, prevista para 2006. Tambin estar disponible en Windows XP y Windows Server 2003. Esta descripcin se basa en una versin preliminar de la primera Community Technology Preview de Indigo. Qu ofrece Indigo Un gran equipo de Microsoft ha dedicado aos a la creacin de Indigo. Este enorme esfuerzo no hubiera sido necesario si los problemas fueran sencillos de resolver o si sus soluciones fueran evidentes. Por tanto, Indigo es un importante componente de tecnologa. Hay tres aspectos que destacan, no obstante, como las caractersticas ms importantes de Indigo: la unificacin de varias tecnologas de Microsoft existentes, su compatibilidad con la interoperabilidad con otros proveedores y su orientacin explcita a servicios Unificacin de las tecnologas de computacin distribuida de Microsoft

Las primeras versiones de .NET Framework incluan varias tecnologas diferentes para crear aplicaciones distribuidas. La siguiente figura las muestra, junto con el motivo principal por el que un desarrollador utilizara dicha tecnologa. Para crear servicios Web bsicos interoperables, por ejemplo, la mejor opcin eran los servicios Web ASP.NET, a los que se suelen denominar ASMX. Para conectar dos aplicaciones basadas en .NET Framework, .NET Remoting era a veces el enfoque ms adecuado. Si la aplicacin requera transacciones distribuidas y servicios ms avanzados, era probable que su creador utilizara Enterprise Services, el sucesor de .NET Framework a COM+. Para aprovechar las especificaciones de servicios Web ms recientes, como WS-Addressing y WS-Security, un desarrollador podra crear aplicaciones que utilizaran Web Services Enhancements (WSE), la implementacin inicial de Microsoft de estas nuevas especificaciones. Por ltimo, para crear aplicaciones con colas y basadas en mensajes, un desarrollador basado en Windows podra utilizar Microsoft Message Queuing (MSMQ).

ASMX .NET Remoting Servicios Web interoperables Comunicacin .NET .NET Transacciones distribuidas, etc. Compatibilidad con X . . . X . .

Enterprise Services . . X .

WSE MSMQ Indigo . . . X . . . . X X X X

las .

especificaciones WS-* Mensajera en cola . . . . X X

Aunque todas estas opciones eran interesantes, esta diversidad resultaba bastante desconcertante para los desarrolladores. Por qu disponer de tantas opciones? Una solucin mejor consista en tener una nica tecnologa que resolviese todos estos problemas, como ha ocurrido con la llegada de Indigo. En vez de obligar a los desarrolladores a elegir una de varias posibilidades, Indigo les permite crear aplicaciones distribuidas que resuelven todos los problemas de los que antes se encargaban las tecnologas que subsume. Aunque Microsoft seguir ofreciendo compatibilidad con las tecnologas anteriores, la mayora de las nuevas aplicaciones que antes hubieran utilizado estas tecnologas ahora se crearn en Indigo. Interoperabilidad con las aplicaciones que no son de Microsoft Conseguir que la vida de los desarrolladores de Windows sea ms sencilla gracias a la unificacin de tecnologas diversas es una buena idea. Pero con el acuerdo universal sobre servicios Web entre los proveedores, tambin es posible resolver el eterno problema de la interoperabilidad entre aplicaciones. Al ser SOAP el mecanismo fundamental de comunicacin de Indigo, las aplicaciones de Indigo pueden comunicarse con software que se ejecuta en una gran variedad de contextos. Tal como vemos en la siguiente figura, una aplicacin creada en Indigo puede interactuar con todas las aplicaciones siguientes:

y y y

Aplicaciones de Indigo ejecutadas en un proceso diferente del mismo equipo de Windows. Aplicaciones de Indigo ejecutadas en otro equipo de Windows. Aplicaciones creadas con otras tecnologas, como servidores de aplicaciones basados en Java 2, Enterprise Edition (J2EE), que admitan servicios Web estndar. Estas aplicaciones se pueden ejecutar en equipos de Windows o en equipos con otros sistemas operativos, como Sun Solaris, z/OS de IBM o Linux.

Las aplicaciones de Indigo tambin pueden interoperar con aplicaciones creadas en algunas de las tecnologas de .NET Framework anteriores a Indigo, por ejemplo ASMX, como se describe ms adelante. Para permitir una comunicacin ms amplia que la bsica, Indigo implementa un grupo de novedosas tecnologas de servicios Web a las que se denomina colectivamente como especificaciones WS-*. Estos documentos definen mtodos de varios proveedores para agregar transacciones, seguridad, mensajera confiable, etc. a servicios Web basados en SOAP. Todas estas especificaciones fueron definidas en un principio por Microsoft, IBM y otros proveedores mediante un trabajo conjunto. Tras estabilizarse, la propiedad suele transferirse a un organismo de normalizacin como OASIS (Organization for the Advancement of Structured Information Standards). Las especificaciones de servicios Web que admite la primera versin de Indigo incluyen WS-Addressing, WS-Policy, WS-MetadataExchange, WSReliableMessaging, WS-Security, WS-Trust, WS-SecureConversation, WS-Coordination, WSAtomicTransaction y MTOM (SOAP Message Transmission Optimization Mechanism). Cuando una aplicacin de Indigo se comunica con una aplicacin que se ejecuta en un sistema que no es Windows, se utiliza el protocolo estndar SOAP (tal vez con algunas extensiones WS-*), representadas en la conexin mediante la habitual codificacin de XML basado en texto. Cuando una aplicacin basada en Indigo se comunica con otra aplicacin basada en Indigo, no obstante, es conveniente optimizar esta comunicacin. Aunque se ofrecen todas las mismas caractersticas, incluidas las transacciones, seguridad y mensajera confiable, la codificacin de la conexin es una versin binaria optimizada de SOAP. Los mensajes siguen la estructura de datos de un mensaje SOAP, conocido como Infoset, pero la codificacin utiliza una

representacin binaria del Infoset en vez de los habituales corchetes angulares y el formato de texto del XML. Compatibilidad explcita con el desarrollo orientado a servicios La idea de considerar una aplicacin que proporciona y consume servicios no es muy nueva. La novedad consiste en centrarse directamente en los servicios y diferenciarlos de los objetos. Con este propsito, los creadores de Indigo han tenido muy en cuenta cuatro principios fundamentales a la hora de disear esta tecnologa: y Compartir el esquema, no la clase: a diferencia de las anteriores tecnologas de objetos distribuidos, los servicios interactan con los clientes slo mediante una interfaz XML bien definida. No se permiten algunos comportamientos como la transferencia de clases completas, mtodos y todo, a travs de los lmites de los servicios. Los servicios son autnomos: un servicio y sus clientes acuerdan la interfaz existente entre ellos, pero aparte de eso son independientes. Por tanto, se pueden escribir en diferentes lenguajes, utilizar diferentes entornos de ejecucin, como CLR y la mquina virtual Java, ejecutarse en diferentes sistemas operativos y diferir en otros aspectos. Los lmites son explcitos: un objetivo de las tecnologas de objetos distribuidos como COM distribuido (DCOM) era conseguir que los objetos remotos fueran lo ms similares posible a los objetos locales. Aunque este enfoque simplificaba el desarrollo en cierto modo al proporcionar un modelo de programacin comn, tambin ocultaba las diferencias inevitables entre objetos locales y objetos remotos. Los servicios evitan este problema al hacer ms explcitas las interacciones entre los servicios y sus clientes. No se intenta ocultar la distribucin. Utilizar compatibilidad basada en directivas: siempre que sea posible, la especificacin de las opciones que se utilizarn entre sistemas debe fundamentarse en mecanismos basados en directivas WS-Policy.

La orientacin a servicios es un campo amplio, que abarca las aplicaciones orientadas a servicios y los conceptos, ms generales, de la arquitectura orientada a servicios (SOA). Indigo constituir los cimientos de aplicaciones orientadas a servicios creadas en Windows y, por lo tanto, ser fundamental para los trabajos realizados en SOA de muchas organizaciones. Creacin de un servicio de Indigo Como muestra la siguiente figura, todos los servicios de Indigo se crean mediante tres elementos: y y y Una clase de servicio, implementada en C#, en VB.NET o en otro lenguaje basado en CLR, que implementa uno o varios mtodos; Un entorno host, un proceso y un dominio de aplicacin, en el que se ejecuta el servicio; Uno o varios extremos que permiten a los clientes tener acceso al servicio.

Toda la comunicacin con un servicio de Indigo se realiza a travs de los extremos del servicio. Cada extremo especifica un contrato que identifica los mtodos a los que se puede tener acceso mediante este extremo, un enlace que determina cmo puede comunicarse un cliente con este extremo y una direccin que indica dnde se puede encontrar este extremo. Para entender Indigo es necesario comprender bien todos estos conceptos. Esta seccin los describe uno por uno, comenzando por las clases de servicio. Creacin de una clase de servicio Una clase de servicio de Indigo es una clase como cualquier otra, pero con algunas novedades, que permiten al creador de la clase definir uno o varios contratos que la clase implementa. Cada servicio de Indigo implementa al menos un contrato de servicio, que define las operaciones que el servicio expone. La clase de servicio tambin puede implementar explcitamente un contrato de datos, que define los datos que transmiten estas operaciones. Esta seccin estudia ambos, comenzando por los contratos de servicio. Definicin de contratos de servicio Todas las clases de servicio de Indigo implementan los mtodos que pueden utilizar los clientes. El creador de la clase de servicio determina los mtodos que se exponen como operaciones a las que el cliente puede llamar mediante su inclusin en un contrato de servicio. La definicin de los contratos de servicio, de hecho, el trabajar explcitamente con los servicios en general, es en gran medida una idea novedosa para el mundo .NET. Los creadores de Indigo necesitaban encontrar una manera de aplicar esta idea al CLR y los lenguajes de programacin que incluye. Afortunadamente, los creadores del CLR previeron la necesidad de este tipo de extensiones, por lo que incorporaron la posibilidad de utilizar atributos. Desde el punto de vista del desarrollador, los atributos son cadenas de caracteres, tal vez con propiedades asociadas, que pueden aparecer antes de una definicin de clase, una definicin de mtodo y otros lugares. Dondequiera que aparece un atributo, cambia ciertos aspectos del comportamiento del elemento al que est asociado. .NET Framework ha utilizado los atributos con distintos objetivos desde su lanzamiento inicial. Por ejemplo, para marcar que un mtodo es un servicio Web al que se puede llamar mediante SOAP en la tecnologa ASMX de Framework, dicho mtodo se precede con el atributo WebMethod. De manera similar, Enterprise Services utiliza el atributo Transaction para indicar que un mtodo requiere una transaccin. Indigo aplica esta idea a los servicios y establece una gama de atributos que permiten definir y controlar los servicios.

El atributo ms importante de Indigo es ServiceContract . De hecho, una clase de servicio de Indigo es sencillamente una clase que se marca con el atributo ServiceContract o que implementa una interfaz marcada con este atributo. A continuacin, podemos ver un sencillo ejemplo en C# que utiliza el primer mtodo: using System.ServiceModel; [ServiceContract] class Calculator { [OperationContract] private int Add(int a, int b) { return a + b; } [OperationContract] public int Subtract(int a, int b) { return a - b; } public int Multiply(int a, int b) { return a * b; } } El atributo ServiceContract y todos los dems atributos que Indigo utiliza se definen en el espacio de nombres System.ServiceModel, por lo que el ejemplo comienza con una instruccin using que hace referencia a este espacio de nombres. Todos los mtodos de una clase de servicio a los que el cliente puede llamar deben marcarse con otro atributo denominado OperationContract. Indigo expone todos los mtodos de una clase de servicio que aparecen precedidos por el atributo OperationContract como operaciones a las que se puede llamar mediante SOAP. En este ejemplo, tanto Add como Subtract estn marcados con este atributo por lo que quedan expuestos a los clientes de este servicio. Todos los mtodos de una clase de servicio que no estn marcados con OperationContract, como Multiply en el ejemplo anterior, no se incluirn en el contrato de servicio, por lo que los clientes de este servicio de Indigo no podrn llamarlos. Dos abstracciones bastante diferentes, servicios y objetos, se unen en Indigo. Es importante comprender que ambas se basan en contratos, de manera explcita o implcita, para definir lo que exponen al mundo exterior. Un objeto, especificado por alguna clase, define de forma efectiva un contrato que determina cules son los mtodos a los que puede llamar otro objeto de la misma aplicacin. El acceso a estos mtodos queda controlado por palabras clave del lenguaje como public y private. En la clase Calculator mostrada anteriormente, por ejemplo, otros objetos de la misma aplicacin pueden llamar a Subtract y Multiply, que son los dos mtodos pblicos de la clase. El contrato de objetos de esta clase expone nicamente estos dos mtodos. Mediante los atributos de Indigo, Calculator tambin define un contrato de servicio, como acabamos de ver. Este contrato tambin tiene dos mtodos, pero no coinciden con los del contrato de objetos. El atributo OperationContract controla si un cliente del servicio de Indigo puede llamar a un determinado mtodo, en vez de las palabras public y private. Como este atributo aparece nicamente en Add y Subtract, los clientes slo pueden llamar a estos dos mtodos. Los contratos de objetos y los contratos de servicios son completamente

independientes y por tanto un mtodo como Add puede ser private aunque lleve el atributo OperationContract. El ejemplo que acabamos de ver muestra la manera ms sencilla de crear una clase de servicio de Indigo: basta con marcar una clase directamente con ServiceContract. Una vez hecho esto, el contrato de servicio de la clase se define implcitamente y consta de todos los mtodos de la clase marcados con OperationContract. Tambin es posible (y probablemente mejor en la mayora de los casos) especificar los contratos de servicio de manera explcita mediante un tipo interface del lenguaje. Empleando este mtodo, la clase Calculator podra tener el siguiente aspecto: using System.ServiceModel; [ServiceContract] public interface ICalculator { [OperationContract] private int Add(int a, int b); [OperationContract] public int Subtract(int a, int b); } class Calculator : ICalculator { private int Add(int a, int b) { return a + b; } public int Subtract(int a, int b) { return a - b; } public int Multiply(int a, int b) { return a * b; } } En este ejemplo, los atributos ServiceContract y OperationContract se asignan a la interfaz ICalculator y los mtodos que contiene en vez de a la clase Calculator propiamente dicha. El resultado es el mismo, no obstante, de manera que esta versin del servicio expone el mismo contrato de servicio que la anterior. El uso de interfaces explcitas como la anterior es ligeramente ms complicado, pero tambin ofrece una mayor flexibilidad. Por ejemplo, una clase puede implementar ms de una interfaz, lo que permite implementar por tanto ms de un contrato de servicio. Al exponer varios extremos, cada uno de ellos con un contrato de servicio diferente, una clase puede presentar diferentes grupos de servicios para diferentes clientes. Definicin de contratos de datos Una clase de servicio de Indigo especifica un contrato de servicio que define los mtodos que se exponen a los clientes del servicio. Todas estas operaciones tambin suelen implicar ciertos datos, lo que significa que un contrato de servicio tambin implica cierto contrato de datos que describa la informacin que se intercambiar. En algunos casos, este contrato de datos se define implcitamente como parte del contrato de servicio. Por ejemplo, en las clases Calculator

mostradas anteriormente, cada mtodo utiliza dos parmetros, ambos enteros, y devuelve un nico entero. Estos parmetros definen todos los datos que intercambia este servicio, por lo que constituyen el contrato de datos del servicio. Para servicios como este, en el que cada operacin utiliza nicamente tipos simples, tiene sentido definir los aspectos de los datos del contrato de manera implcita en el contrato de servicio. No es necesario nada ms. En una clase de servicio de Indigo, se define un contrato de datos utilizando el atributo DataContract. Una clase, estructura u otro tipo marcado con DataContract puede tener uno o varios de sus miembros precedido por el atributo DataMember, lo que indica que este miembro debe incluirse en un valor serializado de este tipo. Veamos un sencillo ejemplo: [DataContract] struct Customer { [DataMember] public string Name; int public age; [DataMember] private int CreditRating; } Cuando una instancia de este tipo Customer se pasa como parmetro en un mtodo marcado con OperationContract, slo se pasarn los campos marcados con el atributo DataMember (Name y CreditRating). El hecho de que un campo est etiquetado como public o private no tiene ningn efecto sobre cmo se serializar el campo. Al igual que ocurre con los mtodos, las palabras clave public y private son parte del contrato que define cmo otros objetos de la misma aplicacin pueden tener acceso a este tipo. DataMember, al igual que OperationContract, define cmo los clientes del servicio que implementa esta clase pueden tener acceso al tipo. Nuevamente, los dos son completamente diferentes. Un ltimo punto que merece la pena sealar acerca de los contratos de Indigo es que de manera predeterminada no hay nada que forme parte de un contrato de servicio o de un contrato de datos. Por el contrario, un desarrollador debe utilizar explcitamente los atributos ServiceContract y DataContract para indicar los tipos que tienen contratos definidos por Indigo y, a continuacin, especificar explcitamente las partes de dichos tipos que se exponen a los clientes de este servicio utilizando los atributos OperationContract y DataMember. Uno de los principios bsicos de los diseadores era que los servicios tuvieran lmites explcitos y, por tanto, Indigo es una tecnologa que permite elegir. Todo lo que un servicio pone a disposicin de sus clientes deber especificarse expresamente en el cdigo. Seleccin de un host Una clase que implementa un servicio de Indigo suele compilarse en una biblioteca. Por definicin, todas las bibliotecas necesitan un dominio de aplicacin host y un proceso de Windows en el que se ejecuten. Indigo ofrece dos opciones para alojar bibliotecas que implementen servicios. Una opcin consiste en utilizar el dominio de aplicacin host y el proceso que ofrece el servicio de activacin de Windows (WAS, Windows Activation Service), mientras que la otra permite que un servicio se aloje en cualquier dominio de aplicacin que se ejecute en cualquier proceso. Esta seccin describe ambas, comenzando por WAS. Alojamiento de un servicio mediante el servicio de activacin de Windows La manera ms sencilla de alojar un servicio de Indigo es utilizar WAS. (Tenga en cuenta que WAS no se admita en la primera Community Technology Preview de Indigo. En su lugar, los servicios de Indigo se podan alojar en Internet Information Server en Windows Server 2003 y Windows XP, aunque slo se admita SOAP a travs de HTTP en esta configuracin.) El uso de WAS es muy similar al mecanismo de alojamiento que IIS ofrece para ASMX. Entre otros

puntos en comn, ambos se basan en el concepto de directorio virtual, que no es ms que un alias ms corto de una ruta de directorio real del sistema de archivos de Windows. Para ver cmo funciona el alojamiento en WAS, supongamos que alguna de las clases Calculator antes mostradas se compila en una biblioteca llamada calc.dll y, a continuacin, se coloca en el directorio virtual calculator de un sistema que ejecuta Windows Server 2003. Para indicar que el servicio de Indigo implementado en calc.dll debe alojarse en WAS, un desarrollador crea un archivo en el directorio virtual calculator con la extensin .svc (que corresponde, por supuesto, a "servicio"). Para nuestro sencillo ejemplo, este archivo podra llamarse calc.svc y slo contendra lo siguiente: %@Service language=c# class="Calculator" % Una vez hecho esto y definido un extremo como se explica en la siguiente seccin, una solicitud de un cliente a uno de los mtodos del servicio Calculator crear automticamente una instancia de esta clase para que ejecute la operacin especificada. Dicha instancia se ejecutar en un dominio de aplicacin creado dentro del proceso estndar que ofrece WAS. Alojamiento de un servicio en un proceso cualquiera Aunque utilizar WAS para que proporcione un proceso para alojar un servicio de Indigo es la opcin ms sencilla, con frecuencia las aplicaciones necesitan exponer servicios desde su propio proceso en vez de utilizar el que ofrece Windows. Afortunadamente, no es difcil hacerlo. El siguiente ejemplo muestra cmo crear un proceso que aloje cualquier de las clases Calculator definidas anteriormente: using System.ServiceModel; public class CalculatorHost { public static void Main() { ServiceHost<Calculator> s1 = new ServiceHost<Calculator>(); s1.Open(); Console.Writeline("Press ENTER to end service"); Console.Readline(); } } Como la clase CalculatorHost incluye un mtodo Main, se ejecutar como un proceso diferente. Para alojar el servicio de ejemplo Calculator, este mtodo debe crear una nueva instancia de la clase ServiceHost<T>, pasando la clase Calculator. (Observe que esta clase estndar de Indigo es un componente genrico, como indican los < y > que rodean a su parmetro. Los componentes genricos son una nueva caracterstica del lenguaje en la versin 2.0 de C#, Visual Basic .NET y otros lenguajes basados en la versin 2.0 de .NET Framework.) Una vez que se crea una instancia de esta clase, para que el servicio est disponible basta con llamar al mtodo Open de dicha instancia. Indigo dirigir automticamente las solicitudes de los clientes a los mtodos apropiados de la clase Calculator. Para permitir que un servicio de Indigo pueda procesar las solicitudes de sus clientes, el proceso que lo aloja debe seguir ejecutndose, lo que no supone un problema con los servicios alojados por WAS, ya que el proceso estndar WAS garantiza esto. No obstante, una aplicacin host debe resolver este problema por s misma. En este sencillo ejemplo, se mantiene ejecutando el proceso mediante el sencillo mecanismo de esperar una entrada por parte de un usuario de la consola.

Definicin de extremos Junto con la definicin de las operaciones de una clase de servicio de Indigo y la especificacin de un proceso host que ejecute dichas operaciones, un servicio de Indigo debe exponer uno o varios extremos. Todos los extremos especifican los tres elementos siguientes: y Un nombre de contrato que indica el contrato de servicio que esta clase de servicio de Indigo expone mediante este extremo. Una clase marcada con ServiceContract que no implementa ninguna interfaz explcita, como Calculator en el primer ejemplo mostrado anteriormente, slo puede exponer un contrato de servicio. En este caso, todos sus extremos expondrn el mismo contrato. Si una clase implementa explcitamente dos o ms interfaces marcadas con ServiceContract, no obstante, extremos diferentes pueden exponer contratos diferentes. Una direccin que indica dnde se puede encontrar este extremo. Las direcciones son direcciones URL que identifican a un equipo y un extremo concreto de dicho equipo Un enlace que determina cmo se puede tener acceso a ese extremo. El enlace determina la combinacin de protocolos que se puede utilizar para tener acceso a ese extremo justo con otros datos, como si la comunicacin es confiable y los mecanismos de seguridad que es posible utilizar. Imaginemos, por ejemplo, que el creador de un servicio desea permitir a los clientes que obtengan acceso al servicio mediante SOAP a travs de HTTP o SOAP a travs de TCP. Al ser cada uno de estos un enlace diferente y, por tanto, el servicio debera exponer dos extremos, uno con un enlace de SOAP a travs de HTTP y el otro con un enlace de SOAP a travs de -TCP.

y y

Los enlaces son una parte fundamental de cmo se lleva a cabo la comunicacin. Para facilitar su uso, Indigo incluye un conjunto de enlaces predefinidos, cada uno de los cuales especifica un determinado grupo de opciones. Este conjunto incluye: y BasicProfileHttpBinding: cumple el perfil bsico 1.0 de la organizacin Web services Interoperability (WS-I), que especifica SOAP a travs de HTTP. Este es el enlace predeterminado del enlace si no se especifica otro explcitamente. BasicProfileHttpsBinding: cumple el perfil 1.0 de seguridad bsico de WS-I, que especifica el SOAP a travs de HTTPS. WsHttpBinding: admite transferencia confiable de mensajes con WS-ReliableMessaging, seguridad con WS-Security y transacciones con WS-AtomicTransaction. Este enlace permite la interoperabilidad con otras implementaciones de servicios Web que tambin admiten estas especificaciones. WsDualHttpBinding: igual que WsHttpBinding, pero tambin admite la interaccin mediante contratos dplex. Mediante este enlace, tanto servicios como clientes pueden recibir y enviar mensajes. NetTcpBinding: enva SOAP con codificacin binaria, incluida la compatibilidad con la transferencia confiable de mensajes, seguridad y transacciones, directamente a travs de TCP. Este enlace slo se puede utilizar para la comunicacin de Indigo a Indigo. NetNamedPipeBinding: enva SOAP con codificacin binaria a travs de canalizaciones con nombre. Este enlace slo se puede utilizar para la comunicacin de Indigo a Indigo entre procesos que se encuentren en el mismo equipo de Windows. NetMsmqBinding: enva SOAP con codificacin binaria a travs de MSMQ, como se describe anteriormente. Este enlace slo se puede utilizar para la comunicacin de Indigo a Indigo.

y y

La figura anterior muestra valores de ejemplo para cada uno de los tres elementos de un extremo para el primer servicio Calculator que se mostraba anteriormente. El nombre del contrato de servicio es Calculator, que es el nombre de la clase que implementa este servicio, y el enlace es BasicProfileHttpBinding. Si suponemos que este servicio se aloja mediante WAS, se ha instalado en el directorio virtual calculator descrito anteriormente y se ejecuta en un equipo llamado qwickbank.com, la direccin podra ser http://www.qwickbank.com/calculator/calc.svc. A diferencia de los contratos, los extremos no se definen utilizando atributos. Aunque es posible crear extremos mediante programacin, el mtodo ms habitual probablemente consiste en utilizar un archivo de configuracin asociado al servicio. Los servicios alojados en WAS utilizan el archivo web.config, mientras que los servicios alojados de manera independiente utilizan el archivo de configuracin asociado a la aplicacin en la que se ejecutan (al que suele hacerse referencia como app.config, aunque el nombre de archivo real puede variar). Si se utiliza para la primera clase de servicio Calculator mostrada anteriormente, este archivo de configuracin podra tener el siguiente aspecto: <configuration> <system.serviceModel> <services> <service serviceType="Calculator"> <endpoint contractType="Calculator" bindingType="basicProfileHttpBinding /> </service> </services> </system.serviceModel> </configuration> El elemento system.serviceModel contiene la informacin de configuracin de todos los servicios que implementa una aplicacin de Indigo. Este elemento contiene un elemento services que puede contener uno o varios elementos service. Este sencillo ejemplo slo tiene un nico servicio, por lo que service slo aparece una vez. El atributo serviceType del elemento service identifica la clase de servicio que implementa el servicio al que se aplica esta configuracin, que en este caso es Calculator. Cada elemento service puede contener uno o varios elementos endpoint, cada uno de los cuales especifica un determinado extremo mediante el que se puede obtener acceso a este servicio de Indigo. En este ejemplo, el servicio slo expone un nico extremo y, por tanto, slo aparece un nico elemento endpoint. El nombre del contrato de este extremo es Calculator, que es el nombre de la clase que lo implementa. Si este archivo de configuracin fuese para la segunda clase de servicio Calculator mostrada anteriormente, que defina el contrato de servicio mediante una interfaz

explcita, el valor del atributo serviceType seguira siendo el mismo, pero el valor de contractType pasara a ser ICalculator, que es el nombre de esta interfaz explcita. El enlace especificado aqu es basicProfileHttpBinding, aunque al ser el predeterminado, se podra haber omitido. Si suponemos adems que Calculator es un servicio alojado en WAS, se creara una direccin automticamente, por lo que no sera necesario especificar una en este archivo de configuracin. Creacin de un cliente de Indigo Si crear un servicio bsico de Indigo no es muy complicado, crear un cliente de Indigo es todava ms sencillo. Basta con crear un emplazamiento local para dicho servicio, llamado proxy, que se conectar a un extremo concreto en el servicio de destino y, a continuacin, invocar las operaciones del servicio a travs de este proxy. La siguiente figura muestra el aspecto de todo esto.

Para crear un proxy es necesario saber exactamente el contrato que expondr el extremo de destino y, a continuacin, utilizar esta definicin del contrato para generar el proxy. En Indigo, este proceso se realiza mediante una herramienta denominada svcutil. Si el servicio se implementa utilizando Indigo, svcutil puede obtener acceso a la DLL del servicio para detectar el contrato y generar un proxy. Si slo est disponible la definicin WSDL del servicio, svcutil puede leerla para generar un proxy. Si slo el propio servicio est disponible, svcutil puede obtener acceso a l directamente mediante WS-MetadataExchange o un sencillo HTTP GET para adquirir la definicin de interfaz de WSDL del servicio y, a continuacin, generar el proxy. Independientemente de cmo se genere, el cliente puede crear una nueva instancia del proxy y, a continuacin, invocar los mtodos del servicio mediante dicha instancia. A continuacin, podemos ver un sencillo ejemplo de un cliente para la clase Calculator: using System.ServiceModel; using Indigo.Example; // namespace for generated proxy class public class CalculatorClient { public static void Main() { CalculatorProxy p = new CalculatorProxy(); Console.WriteLine("7 + 2 = {0}", p.Add(7, 2)); Console.WriteLine("7 - 2 = {0}", p.Subtract(7, 2)); p.Close(); } }

Hay un detalle ms que debe especificar el cliente: el extremo exacto mediante el que desea llamar a las operaciones. Al igual que ocurre con los servicios, el cliente debe especificar el contrato del extremo, su enlace y su direccin, lo que se suele hacer en el archivo de configuracin. De hecho, si hay suficiente informacin disponible, svcutil generar automticamente el archivo de configuracin de cliente adecuado para el servicio de destino. Otros aspectos de Indigo Los conceptos bsicos de los servicios y los clientes son esenciales para todas las aplicaciones de Indigo. Sin embargo, la mayora de estas aplicaciones utilizarn tambin otros aspectos de esta tecnologa. Esta seccin trata algunas de las caractersticas adicionales que Indigo ofrece a las aplicaciones creadas con l. Control del comportamiento local Muchos aspectos de Indigo, como los contratos, los enlaces, etc. estn relacionados con la comunicacin entre un servicio y sus clientes. Sin embargo, hay otras partes del comportamiento de un servicio que son bsicamente locales. Por ejemplo, cmo se controla la duracin de la instancia de un servicio y cmo se administra el acceso simultneo a dicha instancia. Para permitir que los desarrolladores puedan controlar comportamientos como estos, Indigo define dos atributos principales, ambos con varias propiedades. Uno de estos atributos, ServiceBehavior, se puede aplicar a las clases que tambin estn marcadas con el atributo ServiceContract. El otro, OperationBehavior, se puede aplicar a los mtodos de una clase de servicio que tambin est marcada con el atributo OperationContract. El atributo ServiceBehavior tiene varias propiedades que afectan al comportamiento del servicio de manera global. Por ejemplo, se puede utilizar una propiedad denominada ConcurrencyMode para controlar el acceso simultneo al servicio. Si se establece en Single, Indigo entregar nicamente una solicitud de cliente a este servicio a la vez, es decir, el servicio tendr un nico subproceso. Si se establece en Multiple, Indigo entregar ms de una solicitud de cliente a la vez al servicio, cada uno de ellos ejecutndose en un subproceso diferente. De manera similar, la propiedad InstanceMode de ServiceBehavior se puede utilizar para controlar cmo se crean y destruyen las instancias de un servicio. Si InstanceMode se establece en PerCall, se crear una nueva instancia del servicio para tratar cada solicitud de cliente, la cual se destruir cuando finalice la solicitud. Si se establece en PrivateSession, no obstante, la misma instancia del servicio se utilizar para tratar todas las solicitudes procedentes de un determinado cliente. Imaginemos, por ejemplo, que su creador ha decidido que la clase Calculator debe tener varios subprocesos y utilizar la misma instancia para todas las llamadas de un determinado cliente. La definicin de la clase tendra el siguiente aspecto: using System.ServiceModel; [ServiceContract] [ServiceBehavior( ConcurrencyMode=Multiple, InstanceMode=PrivateSession)] class Calculator { ... } De manera similar, las propiedades del atributo OperationBehavior permiten controlar el comportamiento de suplantacin del mtodo que implementa esta operacin, sus requisitos transaccionales (descritos ms adelante) y otros detalles. Opciones de mensajera

Los sencillos ejemplos que se muestran en este artculo suponen que se utiliza un mtodo de llamada a procedimiento remoto (RPC) sincrnico para la interaccin entre cliente y servicio. Indigo admite esta opcin, pero no es la nica posibilidad. SOAP es un protocolo orientado a mensajes, lo que implica que puede admitir varios modelos de programacin. De hecho, Indigo admite varias posibilidades, entre ellas: y y y y RPC tradicional, que bloquea las llamadas que incluyen listas de parmetros con tipo; RPC asincrnica, que no bloquea las llamadas que incluyen listas de parmetros con tipo; Mensajera tradicional, que no bloquea las llamadas que incluyen un nico parmetro de mensaje; RPC basada en mensajes, que bloquea las llamadas que incluyen un nico parmetro de mensaje.

Adems, aunque es necesario para la mayora de las aplicaciones distribuidas, la especificacin SOAP no trata en ningn momento la confiabilidad. Una manera habitual de garantizar la confiabilidad consiste en utilizar SOAP nicamente en escenarios de punto a punto y emplear TCP para garantizar la entrega de solicitudes y respuestas, lo cual es suficiente en algunos casos y es lo que se hace cuando se utiliza BasicProfileHttpBinding. Sin embargo, tambin hay muchos casos en los que no es suficiente. Por ejemplo, qu ocurre si se obtiene acceso a un servicio mediante varios intermediarios SOAP? Las garantas de confiabilidad que ofrece TCP no son suficientes en este caso para garantizar la confiabilidad de un extremo a otro. Para resolver este problema, Indigo implementa la especificacin WSReliableMessaging. Si se elige un enlace como WsHttpBinding, que utiliza WSReliableMessaging, un servicio y su cliente pueden garantizar una comunicacin confiable de un extremo a otro aunque sea a travs de varios intermediarios SOAP. Seguridad La exposicin de servicios en una red, aunque sea una red interna, normalmente requiere ciertas medidas de seguridad. Cmo puede el servicio comprobar la identidad del cliente? Cmo se pueden proteger los mensajes enviados al servicio o desde l de alteraciones malintencionadas y ojos indiscretos? Y cmo se puede limitar el acceso a un servicio para que nicamente los usuarios autorizados puedan utilizarlo? Sin alguna solucin a estos problemas, resulta demasiado peligroso exponer numerosos tipos de servicios. Sin embargo, la creacin de aplicaciones seguras puede resultar complicada. Lo ideal sera que hubiese maneras directas de tratar escenarios habituales de seguridad, junto con un control ms preciso para las aplicaciones que lo requieran. Para lograrlo, Indigo ofrece funciones de seguridad bsicas de autenticacin, integridad de los mensajes, confidencialidad de los mensajes y autorizacin. El mtodo de Indigo para tratar los primeros tres aspectos se basa principalmente en los enlaces y entre las opciones del desarrollador se encuentran las siguientes: y Seleccionar un enlace estndar que admita seguridad. Las aplicaciones que necesiten slo seguridad basada en el transporte, por ejemplo, pueden utilizar un enlace como BasicProfileHttpsBinding. Este mtodo es suficiente para solicitudes que vayan directamente de un cliente a un servicio sin atravesar ningn intermediario, como servidores proxy HTTP u otros nodos SOAP. Las aplicaciones que requieren seguridad de un extremo a otro para mensajes que atraviesan varios intermediarios SOAP pueden utilizar en su lugar un enlace que admita seguridad WS-Security, como WsHttpBinding. Seleccionar un enlace estndar que admita seguridad y, a continuacin, personalizarlo cambiando uno o varios de los valores predeterminados. Por ejemplo, el mecanismo de autenticacin que utiliza un enlace como WsHttpBinding se puede cambiar si se desea.

Crear un enlace personalizado que ofrezca exactamente las caractersticas que un desarrollador necesita. Aunque este proceso no es apto para cardiacos, puede ser la solucin adecuada para ciertos escenarios avanzados. Seleccionar un enlace estndar que no admita seguridad, como BasicProfileHttpBinding. Aunque no aplicar ninguna seguridad es una prctica bastante peligrosa en general, es posible que sea la mejor opcin en ciertas situaciones.

Un servicio de Indigo tambin puede controlar los clientes autorizados a utilizar sus servicios. En general, Indigo admite nicamente los mecanismos de autorizacin que incluye .NET Framework. Un servicio puede utilizar el atributo estndar PrincipalPermission, por ejemplo, para definir quin tiene permiso para obtener acceso a l. Permitir a los desarrolladores que creen aplicaciones seguras sin exponerles a una complejidad desorbitada ha sido todo un reto en el pasado. Al proporcionar un mtodo directo para los casos ms habituales y un control preciso para situaciones ms complejas, Indigo intenta lograr este objetivo de una manera viable y eficaz. CONCLUSIN Indigo es la unificacin de varias tecnologas, que nos permite desarrollar sistemas distribuidos de una manera ms sencilla, que integra diversas funciones que hace un tiempo atrs existan por separado y no era muy sencillo su utilizacin, ahora en la actualidad se lo conoce como WCF, siendo esta una versin ms avanzada y con mejoras que benefician a los desarrolladores, permitiendo la creacin de clientes y servicios, incluyendo la seguridad en los diferentes procesos que tiene la transferencia de informacin.