Presentación de Indigo: un aspecto temprano

 

David Chappell
Chappell & Associates

Febrero de 2005

Resumen: Proporciona información general sobre la arquitectura del modelo de programación unificado de Microsoft "Indigo" para crear aplicaciones orientadas a servicios. En el documento se explica la relación de Indigo con las tecnologías de aplicaciones distribuidas existentes en .NET Framework, los conceptos básicos de la creación y el consumo de servicios indigo, y una visión general de las funcionalidades de Indigo, incluida la seguridad, la mensajería confiable y la compatibilidad con transacciones. (24 páginas impresas)

Nota Este artículo se basa en una versión preliminar de Community Technology Preview (CTP) de Indigo. Tenga en cuenta que las características y los detalles de implementación están sujetos a cambios a medida que Indigo avanza a través del ciclo del producto.

Contenido

¿Qué es Indigo?
Qué proporciona Indigo
Creación de un servicio indigo
Creación de un cliente indigo
Otros aspectos de Indigo
Coexistencia y migración
Conclusiones
Acerca del autor

¿Qué es Indigo?

Elegir las mejores abstracciones para compilar software es un proceso continuo. Los objetos son el enfoque dominante hoy en día para compilar la lógica de negocios de una aplicación, pero el modelado de la comunicación de aplicación a aplicación mediante objetos no ha sido tan exitoso. Un mejor enfoque es modelar explícitamente las interacciones entre fragmentos discretos de software como servicios. Ya existe mucha compatibilidad para compilar aplicaciones orientadas a objetos, pero pensar en los servicios como un bloque de creación de software fundamental es una idea más reciente. Por este motivo, las tecnologías diseñadas explícitamente para crear aplicaciones orientadas a servicios no han estado ampliamente disponibles.

El marco de Microsoft para compilar aplicaciones orientadas a servicios, denominadas Indigo, cambia esto. Indigo permite a los desarrolladores que actualmente crean aplicaciones orientadas a objetos mediante .NET Framework para compilar también aplicaciones orientadas a servicios de una manera familiar. Y para permitir que esas aplicaciones interactúen eficazmente con el software que se ejecuta en Windows y en otras plataformas, Indigo implementa SOAP y otras tecnologías de servicios web, lo que permite a los desarrolladores crear servicios confiables, seguros y transaccionales que pueden interoperar con software que se ejecuta en cualquier sistema.

En la ilustración anterior se muestra una vista sencilla de un cliente y un servicio indigo. Indigo proporciona una base, implementada principalmente como un conjunto de clases que se ejecutan en Common Language Runtime (CLR), para crear servicios a los que acceden los clientes. Un cliente y un servicio interactúan a través de SOAP, el protocolo nativo de Indigo, por lo que aunque la figura muestre ambas partes basadas en Indigo, esto no es necesario.

Indigo se basa en y amplía .NET Framework 2.0, que está programado para su lanzamiento en 2005. Indigo se enviará como parte del código de lanzamiento de Windows denominado Longhorn, programado para 2006, y también estará disponible en Windows XP y Windows Server 2003. Esta descripción se basa en una versión preliminar de la primera versión preliminar de Community Technology Preview de Indigo. Tenga en cuenta que es probable que algunos cambios (casi seguros, de hecho) antes de que se envíe la versión final.

Qué proporciona Indigo

Muchas personas de Microsoft han dedicado años de su vida a crear Indigo. Este nivel de esfuerzo no habría sido necesario si los problemas resueltos fueran simples o si sus soluciones fueran obvias. En consecuencia, Indigo es una parte sustancial de la tecnología. Sin embargo, tres cosas destacan como aspectos más importantes de Indigo: su unificación de varias tecnologías de Microsoft existentes, su compatibilidad con la interoperabilidad entre proveedores y su orientación explícita al servicio. En esta sección se examina cada uno de ellos.

Unificación de las tecnologías informáticas distribuidas de Microsoft

Las versiones iniciales de .NET Framework incluían varias tecnologías diferentes para crear aplicaciones distribuidas. En la ilustración siguiente se muestra cada una de ellas, junto con la razón principal por la que un desarrollador normalmente usaría esa tecnología. Para crear servicios web interoperables básicos, por ejemplo, la mejor opción era ASP.NET servicios web, más comúnmente conocidos como ASMX. Para conectar dos aplicaciones basadas en .NET Framework, .NET Remoting a veces era el enfoque correcto. Si una aplicación requería transacciones distribuidas y otros servicios más avanzados, es probable que su creador use Enterprise Services, el sucesor de .NET Framework en COM+. Para aprovechar las especificaciones de servicios web más recientes, como WS-Addressing y WS-Security, un desarrollador podría compilar aplicaciones que usaran mejoras de servicios web (WSE), la implementación inicial de Microsoft de estas especificaciones emergentes. Y para crear aplicaciones en cola basadas en mensajes, un desarrollador basado en Windows usaría Microsoft Message Queuing (MSMQ).

	ASMX	.NET Remoting	Enterprise Services	WSE	MSMQ	Indigo
Servicios web interoperables	x					x
.NET: comunicación de .NET		x				x
Transacciones distribuidas, etc.			x			x
Compatibilidad con especificaciones WS-*				x		x
Mensajería en cola					x	x

Todas estas opciones tenían valor, pero la diversidad era ciertamente confusa para los desarrolladores. ¿Por qué hay tantas opciones? Una mejor solución sería tener una tecnología que solucione todos estos problemas. Con la llegada de Indigo, esa tecnología ha aparecido. En lugar de forzar a los desarrolladores a elegir una de varias posibilidades, Indigo les permite crear aplicaciones distribuidas que aborden todos los problemas resueltos por las tecnologías que subsumen. Aunque Microsoft seguirá admitiendo estas tecnologías anteriores, la mayoría de las nuevas aplicaciones que habrían usado previamente cualquiera de ellas se compilarán en Indigo.

Interoperabilidad con aplicaciones que no son de Microsoft

Facilitar la vida a los desarrolladores de Windows mediante la unificación de tecnologías dispares es algo bueno. Sin embargo, con el acuerdo universal entre los proveedores de servicios web, también se puede resolver el problema de interoperabilidad de aplicaciones de larga duración. Dado que el mecanismo de comunicación fundamental de Indigo es SOAP, las aplicaciones Indigo pueden comunicarse con otro software que se ejecuta en una variedad de contextos. Como se muestra en la ilustración siguiente, una aplicación basada en Indigo puede interactuar con lo siguiente:

• Aplicaciones indigo que se ejecutan en un proceso diferente en la misma máquina Windows.
• Aplicaciones indigo que se ejecutan en otra máquina Windows.
• Aplicaciones basadas en otras tecnologías, como servidores de aplicaciones basados en Java 2, Enterprise Edition (J2EE), que admiten servicios web estándar. Estas aplicaciones se pueden ejecutar en máquinas Windows o en máquinas con otros sistemas operativos, como Sun Solaris, z/OS de IBM o Linux.

Las aplicaciones indigo también pueden interoperar con aplicaciones basadas en algunas de las tecnologías de .NET Framework que preceden a Indigo, como ASMX, como se describe más adelante.

Para permitir más que solo la comunicación básica, Indigo implementa un grupo de tecnologías de servicios web más recientes denominadas colectivamente especificaciones WS-*. Estos documentos definen formas de varios proveedores para agregar mensajería confiable, seguridad, transacciones y mucho más a los servicios web basados en SOAP. Todas estas especificaciones se definieron originalmente por Microsoft, IBM y otros proveedores que trabajan juntos. A medida que se convierten en estables, la propiedad suele pasar a organismos de estándares como la Organización para el Avance de estándares de información estructurada (OASIS). Las especificaciones de servicios web admitidas en la primera versión de Indigo incluyen WS-Addressing, WS-Policy, WS-MetadataExchange, WS-ReliableMessaging, WS-Security, WS-Trust, WS-SecureConversation, WS-Coordination, WS-AtomicTransaction y el Mecanismo de optimización de transmisión de mensajes SOAP (MTOM).

Cuando una aplicación Indigo se comunica con una aplicación que se ejecuta en un sistema que no es de Windows, el protocolo usado es SOAP estándar (quizás con algunas extensiones WS-*), representado en la conexión en su codificación XML basada en texto habitual. Sin embargo, cuando una aplicación basada en Indigo se comunica con otra aplicación basada en Indigo, tiene sentido optimizar esta comunicación. Se proporcionan todas las mismas características, incluida la mensajería confiable, la seguridad y las transacciones, pero la codificación de conexión usada es una versión binaria optimizada de SOAP. Los mensajes siguen siendo conformes a la estructura de datos de un mensaje SOAP, denominado Conjunto de información, pero su codificación usa una representación binaria de ese conjunto de información en lugar del formato estándar angle-brackets-and-text de XML.

Compatibilidad explícita con el desarrollo de Service-Oriented

Pensar en una aplicación como proporcionar y consumir servicios es apenas una idea nueva. Lo que es nuevo es un enfoque claro en los servicios como distintos de los objetos. Hacia este fin, los creadores de Indigo tenían cuatro principios en mente durante el diseño de esta tecnología:

• Compartir esquema, no clase: a diferencia de las tecnologías de objetos distribuidos anteriores, los servicios interactúan con sus clientes solo a través de una interfaz XML bien definida. No se permiten comportamientos como pasar clases, métodos y todos completos a través de los límites del servicio.
• Los servicios son autónomos: un servicio y sus clientes acuerdan la interfaz entre ellos, pero son independientes de otro modo. Pueden escribirse en diferentes lenguajes, usar entornos en tiempo de ejecución diferentes, como CLR y la máquina virtual Java, ejecutarse en distintos sistemas operativos y diferir de otras maneras.
• Los límites son explícitos: un objetivo de las tecnologías de objetos distribuidos, como Distributed COM (DCOM) era hacer que los objetos remotos se vean lo más posible como los objetos locales. Aunque este enfoque simplificaba el desarrollo de algunas maneras proporcionando un modelo de programación común, también ocultaba las diferencias ineludibles entre los objetos locales y los objetos remotos. Los servicios evitan este problema al hacer que las interacciones entre los servicios y sus clientes sean más explícitas. Ocultar la distribución no es un objetivo.
• Usar la compatibilidad basada en directivas: cuando sea posible, determinar qué opciones usar entre sistemas deben basarse en mecanismos basados en WS-Policy.

La orientación del servicio es un área amplia, que abarca aplicaciones orientadas a servicios y los conceptos más generales de la arquitectura orientada a servicios (SOA). Indigo será la base para las aplicaciones orientadas a servicios basadas en Windows, por lo que será fundamental para los esfuerzos de SOA de muchas organizaciones.

Creación de un servicio Indigo

Como se muestra en la ilustración siguiente, cada servicio indigo se construye a partir de tres cosas:

• Una clase de servicio, implementada en C# o VB.NET u otro lenguaje basado en CLR, que implementa uno o varios métodos;
• Un entorno de host , un dominio y un proceso de aplicación, en los que se ejecuta el servicio;
• Uno o varios puntos de conexión que permiten a los clientes acceder al servicio.

Toda la comunicación con un servicio Indigo se produce a través de los puntos de conexión del servicio. Cada punto de conexión especifica un contrato que identifica qué métodos son accesibles a través de este punto de conexión, un enlace que determina cómo un cliente puede comunicarse con este punto de conexión y una dirección que indica dónde se puede encontrar este punto de conexión.

Comprender Indigo requiere comprender todos estos conceptos. En esta sección se describe cada una de ellas, empezando por las clases de servicio.

Creación de una clase de servicio

Una clase de servicio Indigo es una clase como cualquier otra, pero tiene algunas adiciones. Estas adiciones permiten al creador de la clase definir uno o varios contratos que implementa esta clase. Cada clase de servicio indigo implementa al menos un contrato de servicio, que define las operaciones que expone este servicio. Una clase de servicio también podría implementar explícitamente un contrato de datos, que define los datos que transmiten esas operaciones. En esta sección se examinan ambos, empezando por los contratos de servicio.

Definir contratos de servicio

Cada clase de servicio indigo implementa métodos para que sus clientes los usen. El creador de una clase de servicio determina cuáles de sus métodos se exponen como operaciones invocables por el cliente incluyéndolas en un contrato de servicio. Definir contratos de servicio, de hecho, trabajar explícitamente con servicios en general, es en gran medida una nueva idea para el mundo de .NET. Los creadores de Indigo necesitaban encontrar una manera de injertar esta idea sobre CLR y los lenguajes de programación basados en él. Afortunadamente, los creadores de CLR previeron la necesidad de extensiones como esta, por lo que proporcionaron compatibilidad con atributos. Como ve un desarrollador, los atributos son cadenas de caracteres, quizás con propiedades asociadas, que pueden aparecer antes de una definición de clase, una definición de método y en otros lugares. Siempre que aparezca un atributo, cambia algún aspecto del comportamiento de lo que está asociado.

.NET Framework ha usado atributos para varias cosas desde su versión inicial. Por ejemplo, para marcar un método como un servicio web al que se puede llamar SOAP en la tecnología ASMX del marco, ese método va precedido por el WebMethod atributo . Del mismo modo, Enterprise Services usa el Transaction atributo para indicar que un método requiere una transacción. Indigo aplica esta idea a los servicios, definiendo un rango de atributos para definir y controlar los servicios.

El atributo más fundamental de Indigo es ServiceContract. De hecho, una clase de servicio Indigo es simplemente una clase que se marca con el ServiceContract atributo o que implementa una interfaz marcada con este atributo. Este es un ejemplo sencillo de C# que usa el primer enfoque:

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 ServiceContract atributo y todos los demás atributos que usa Indigo se definen en .SystemServiceModel espacio de nombres y, por tanto, este ejemplo comienza con una using instrucción que hace referencia a este espacio de nombres. Cada método de una clase de servicio que un cliente puede invocar debe marcarse con otro atributo denominado OperationContract. Todos los métodos de una clase de servicio precedidos por el OperationContract atributo se exponen automáticamente mediante Indigo como operaciones invocables soap. En este ejemplo, Add y Subtract están marcados con este atributo, por lo que ambos se exponen a los clientes de este servicio. Los métodos de una clase de servicio que no están marcados con OperationContract, como Multiply en el ejemplo anterior, no se incluyen en el contrato de servicio, por lo que los clientes de este servicio Indigo no pueden llamar a ellos.

Dos abstracciones, servicios y objetos bastante independientes, se unen en Indigo. Es importante comprender que ambos dependen de contratos, ya sea explícita o implícitamente, para definir lo que exponen al mundo exterior. Un objeto, especificado por alguna clase, define eficazmente un contrato que determina cuál de sus métodos puede invocar otro objeto en la misma aplicación. El acceso a estos métodos se controla mediante palabras clave de lenguaje como public y private. En la clase Calculator mostrada anteriormente, por ejemplo, otros objetos de la misma aplicación pueden llamar a Subtract y Multiply, los dos métodos públicos de esta clase. El objeto ** contract esta clase expone solo contiene estos dos métodos.

Con los atributos de Indigo, Calculator también se define un contrato de servicio, como se acaba de describir. Este contrato también tiene dos métodos, pero no son los mismos que los de su contrato de objeto. Si un cliente de este servicio indigo puede invocar un método controlado por el OperationContract atributo , no las public palabras clave y private . Dado que este atributo solo aparece en Add y Subtract, solo los clientes pueden llamar a estos dos métodos. El contrato de objeto y el contrato de servicio son completamente distintos entre sí, por lo que un método como Add puede ser private mientras sigue llevando el OperationContract atributo.

En el ejemplo que se muestra se muestra la manera más sencilla de crear una clase de servicio Indigo: marcar una clase directamente con ServiceContract. Cuando esto se hace, el contrato de servicio de la clase se define implícitamente para que conste de todos los métodos de esa clase marcados con OperationContract. También es posible (y probablemente mejor en la mayoría de los casos) especificar contratos de servicio explícitamente mediante el tipo de interface un lenguaje. Con este enfoque, la Calculator clase podría tener este aspecto:

using System.ServiceModel;

[ServiceContract]
interface ICalculator
{
 [OperationContract]
 int Add(int a, int b);

 [OperationContract]
 int Subtract(int a, int b);
}

class Calculator : ICalculator
{
 public int Add(int a, int b) // private methods aren't 
 {                            // allowed in interfaces
   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 ServiceContract atributos y OperationContract se asignan a la ICalculator interfaz y los métodos que contiene en lugar de a la Calculator propia clase. Sin embargo, el resultado es el mismo, por lo que esta versión del servicio expone el mismo contrato de servicio que el anterior. El uso de interfaces explícitas como esta es ligeramente más complicada, pero también permite más flexibilidad. Por ejemplo, una clase puede implementar más de una interfaz, lo que significa que también puede implementar más de un contrato de servicio. Al exponer varios puntos de conexión, cada uno con un contrato de servicio diferente, una clase puede presentar diferentes grupos de servicios a distintos clientes.

Un punto final: marcar una clase de servicio con ServiceContract y OperationContract también permite generar automáticamente definiciones de contrato de servicio en el lenguaje de descripción de servicios web (WSDL). En consecuencia, se puede acceder a la definición externamente visible de cada contrato de servicio de Indigo como un documento WSDL estándar que especifica las operaciones de ese contrato. Y aunque no se describe aquí, también es posible crear una clase de servicio Indigo directamente a partir de un documento WSDL, un enfoque especialmente útil para implementar interfaces WSDL definidas externamente.

Definición de contratos de datos

Una clase de servicio Indigo especifica un contrato de servicio que define cuáles de sus métodos se exponen a los clientes de servicio. Cada una de esas operaciones normalmente transmitirá algunos datos, lo que significa que un contrato de servicio también implica algún tipo de contrato de datos que describe la información que se intercambiará. En algunos casos, este contrato de datos se define implícitamente como parte del contrato de servicios. Por ejemplo, en las Calculator clases mostradas anteriormente, cada método toma dos parámetros de entrada, ambos enteros, y devuelve un único entero. Estos parámetros definen todos los datos intercambiados por este servicio, por lo que comprenden el contrato de datos del servicio. Para los servicios como este, donde cada operación solo usa tipos simples, tiene sentido definir los aspectos de datos de su contrato implícitamente dentro del contrato de servicio. No hay necesidad de nada más.

Pero los servicios también pueden tener parámetros de tipos más complejos, como estructuras. En casos como este, se requiere un contrato de datos explícito. Los contratos de datos definen cómo se convierten los tipos en memoria en un formulario adecuado para la transmisión a través de la conexión, un proceso conocido como serialización. En efecto, los contratos de datos son un mecanismo para controlar cómo se serializan los datos.

En una clase de servicio Indigo, se define un contrato de datos mediante el DataContract atributo . Una clase, estructura u otro tipo marcado con DataContract puede tener uno o varios de sus miembros precedidos por el DataMember atributo , lo que indica que este miembro debe incluirse en un valor serializado de este tipo. A continuación se muestra un sencillo ejemplo:

[DataContract]
struct Customer {
 [DataMember] public string Name; 
 int public age;
 [DataMember] private int CreditRating;
}

Cuando se pasa una instancia de este Customer tipo como parámetro en un método marcado con OperationContract, solo se pasarán los campos marcados con el DataMember atributoName y CreditRating.

Si un campo está etiquetado como public o private no tiene ningún efecto sobre si ese campo se serializa. Al igual que con los métodos , las public palabras clave y private forman parte del contrato que define cómo se puede tener acceso a este tipo por otros objetos de la misma aplicación. DataMember, como OperationContract, define cómo los clientes del servicio implementan el tipo al que puede acceder el tipo. Una vez más, los dos son completamente distintos.

Un último punto que merece la pena destacar sobre los contratos indigo es que nada se convierte en parte de un contrato de servicio o de un contrato de datos de forma predeterminada. En su lugar, un desarrollador debe usar explícitamente los ServiceContract atributos y DataContract para indicar qué tipos tienen contratos definidos por Indigo y, a continuación, especificar explícitamente qué partes de esos tipos se exponen a los clientes de este servicio mediante los OperationContract atributos y DataMember . Uno de los principios de sus diseñadores era que los servicios deben tener límites explícitos, por lo que Indigo es una tecnología de participación. Todo lo que un servicio pone a disposición de sus clientes se especifica expresamente en el código.

Los contratos y los atributos que los definen son un aspecto importante de Indigo, y esta breve descripción abarca solo los aspectos destacados. El OperationContract atributo se puede usar para definir operaciones unidireccionales , por ejemplo, donde una llamada a un servicio no tiene respuesta. También es posible definir interacciones en las que ambos lados pueden actuar como cliente y servicio, cada una de las operaciones que invoca y expone las operaciones que invoca el otro mediante la creación de lo que se denomina contratos dúplex . El DataContract atributo también tiene varias opciones más, y incluso es posible trabajar directamente con mensajes SOAP de forma nativa mediante un atributo denominado MessageContract. Los contratos se usan para expresar gran parte de lo que proporciona Indigo, por lo que son uno de sus conceptos más fundamentales.

Selección de un host

Normalmente, una clase que implementa un servicio Indigo se compila en una biblioteca. Por definición, todas las bibliotecas necesitan un dominio de aplicación host y un proceso de Windows para ejecutarse. Indigo proporciona dos opciones para hospedar bibliotecas que implementan servicios. Uno consiste en usar un dominio de aplicación host y un proceso proporcionado por el Servicio de activación de Windows (WAS), mientras que el otro permite que un servicio se hospede en cualquier dominio de aplicación que se ejecute en un proceso arbitrario. En esta sección se describen ambos, empezando por WAS.

Hospedaje de un servicio mediante el servicio de activación de Windows

La manera más sencilla de hospedar un servicio Indigo es confiar en WAS. (Tenga en cuenta que WAS no se admite en la primera versión preliminar de Community Technology preview de Indigo. En su lugar, los servicios indigo se pueden hospedar en Internet Information Server en Windows Server 2003 y Windows XP, aunque solo se admite SOAP a través de HTTP en esta configuración). El uso de WAS es muy similar al uso del mecanismo de hospedaje proporcionado por IIS para ASMX. Entre otras cosas, ambos se basan en la noción de un directorio virtual, que es solo un alias más corto para una ruta de acceso de directorio real en el sistema de archivos de Windows.

Para ver cómo funciona el hospedaje WAS, supongamos que cualquiera de las Calculator clases mostradas anteriormente se compiló en una biblioteca denominada calc.dll y, a continuación, se colocó en la calculadora de directorios virtuales en un sistema que ejecuta Windows Server 2003. Para indicar que el servicio Indigo implementado en calc.dll debe hospedarse en WAS, un desarrollador crea un archivo en el directorio virtual de la calculadora con la extensión .svc (que significa, por supuesto, para "servicio"). En nuestro ejemplo sencillo, este archivo podría llamarse calc.svc y su contenido completo podría ser:

%@Service language=c# class="Calculator" %

Una vez hecho esto y se ha definido un punto de conexión como se muestra en la sección siguiente, una solicitud de un cliente a uno de los Calculator métodos del servicio creará automáticamente una instancia de esta clase para ejecutar la operación especificada. Esa instancia se ejecutará en un dominio de aplicación creado dentro del proceso estándar que proporciona WAS.

Hospedaje de un servicio en un proceso arbitrario

Confiar en WAS para proporcionar un proceso para hospedar un servicio Indigo es ciertamente la opción más sencilla. Sin embargo, las aplicaciones a menudo necesitan exponer servicios de su propio proceso en lugar de confiar en uno proporcionado por Windows. Afortunadamente, esto no es difícil de hacer. En el ejemplo siguiente se muestra cómo crear un proceso que hospede cualquiera de las Calculator clases 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();    
  }
}

Dado que la clase CalculatorHost incluye un Main método, se ejecutará como un proceso distinto. Para hospedar el servicio de ejemplo Calculator , este método debe crear una nueva instancia de la clase ServiceHost<T>, pasando la Calculator clase . (Tenga en cuenta que esta clase indigo estándar es genérica, indicada por < y > que incluye su parámetro. Los genéricos son una nueva característica de lenguaje en la versión 2.0 de C#, Visual Basic .NET y otros lenguajes basados en la versión 2.0 de .NET Framework). Una vez creada una instancia de esta clase, lo único necesario para que el servicio esté disponible es llamar al Open método en esa instancia. Indigo ahora dirigirá automáticamente las solicitudes de los clientes a los métodos adecuados de la Calculator clase .

Para permitir que un servicio Indigo procese solicitudes de sus clientes, el proceso que hospeda debe permanecer en ejecución. Este no es un problema con los servicios hospedados en WAS, ya que el proceso estándar WAS proporciona garantiza esto. Sin embargo, una aplicación de hospedaje debe resolver este problema por sí solo. En este ejemplo sencillo, el proceso se sigue ejecutando a través del mecanismo sencillo de esperar la entrada de un usuario de consola.

Definición de extremos

Junto con la definición de operaciones en una clase de servicio Indigo y la especificación de un proceso de host para ejecutar esas operaciones, un servicio Indigo también debe exponer uno o varios puntos de conexión. Cada punto de conexión especifica las tres cosas siguientes:

• Un nombre de contrato que indica qué contrato de servicio expone esta clase de servicio Indigo a través de este punto de conexión. Una clase marcada con ServiceContract que no implementa interfaces explícitas, como Calculator en el primer ejemplo mostrado anteriormente, solo puede exponer un contrato de servicio. En este caso, todos sus puntos de conexión expondrán el mismo contrato. Sin embargo, si una clase implementa explícitamente dos o más interfaces marcadas con ServiceContract, los distintos puntos de conexión pueden exponer contratos diferentes.
• Dirección que indica dónde se puede encontrar este punto de conexión. Las direcciones son direcciones URL que identifican una máquina y un punto de conexión determinado en esa máquina.
• Enlace que determina cómo se puede acceder a este punto de conexión. El enlace determina qué combinación de protocolo se puede usar para acceder a este punto de conexión junto con otras cosas, como si la comunicación es confiable y qué mecanismos de seguridad se pueden usar. Supongamos, por ejemplo, que el creador de un servicio desea permitir que los clientes accedan a ese servicio mediante SOAP a través de HTTP o SOAP a través de TCP. Cada uno de ellos es un enlace distinto, por lo que el servicio tendría que exponer dos puntos de conexión, uno con un enlace SOAP sobre HTTP y el otro con un enlace SOAP a través de TCP.

Los enlaces son una parte fundamental de cómo se logra la comunicación. Para facilitar su uso, Indigo incluye un conjunto de enlaces predefinidos, cada uno de los cuales especifica un grupo determinado de opciones. Este conjunto incluye:

• BasicProfileHttpBinding: se ajusta al perfil básico 1.0 de la organización de interoperabilidad de servicios web (WS-I), que especifica SOAP a través de HTTP. Este es el enlace predeterminado de un punto de conexión si no se especifica ninguno explícitamente.
• BasicProfileHttpsBinding: se ajusta al perfil de seguridad básico de WS-I 1.0, que especifica SOAP a través de HTTPS.
• WsHttpBinding: admite la transferencia de mensajes confiable con WS-ReliableMessaging, seguridad con WS-Security y transacciones con WS-AtomicTransaction. Este enlace permite la interoperabilidad con otras implementaciones de servicios web que también admiten estas especificaciones.
• WsDualHttpBinding: como WsHttpBinding, pero también admite la interacción mediante contratos dúplex. Con este enlace, tanto los servicios como los clientes pueden recibir y enviar mensajes.
• NetTcpBinding: envía SOAP con codificación binaria, incluida la compatibilidad con transferencia de mensajes confiable, seguridad y transacciones, directamente a través de TCP. Este enlace solo se puede usar para la comunicación de Indigo a Indigo.
• NetNamedPipeBinding: envía SOAP con codificación binaria a través de canalizaciones con nombre. Este enlace solo se puede usar para la comunicación de Indigo a Indigo entre procesos en la misma máquina Windows.
• NetMsmqBinding: envía SOAP codificado de forma binaria a través de MSMQ, como se describe más adelante. Este enlace solo se puede usar para la comunicación de Indigo a Indigo.

En la ilustración anterior se muestran valores de ejemplo para cada uno de los tres elementos de un punto de conexión para el primer Calculator servicio mostrado anteriormente. El nombre del contrato del servicio es Calculator, que es el nombre de la clase que implementa este servicio y el enlace es BasicProfileHttpBinding. Suponiendo que este servicio se hospeda mediante WAS, se instala en la calculadora de directorios virtuales como se ha descrito anteriormente y se ejecuta en una máquina denominada qwickbank.com, su dirección podría ser http://www.qwickbank.com/calculator/calc.svc.

A diferencia de los contratos, los puntos de conexión no se definen mediante atributos. Aunque es posible crear puntos de conexión mediante programación, el enfoque más común probablemente será usar un archivo de configuración asociado al servicio. Los servicios hospedados en WAS usan el archivo web.config, mientras que los hospedados de forma independiente con el archivo de configuración asociado a la aplicación en la que se ejecutan (normalmente denominados app.config, aunque el nombre de archivo real varía). Si se usa únicamente para la primera Calculator clase de servicio mostrada anteriormente, este archivo de configuración podría tener este aspecto:

<configuration>
  <system.serviceModel>
    <services>
      <service serviceType="Calculator">
           <endpoint 
          contractType="Calculator"
          bindingType="basicProfileHttpBinding />
      </service>
    </services>
  </system.serviceModel>
</configuration>

La información de configuración de todos los servicios que implementa una aplicación Indigo se encuentra dentro del system.serviceModel elemento . Este elemento contiene un services elemento que puede contener uno o varios service elementos. Este ejemplo sencillo solo tiene un único servicio, por lo que solo hay una repetición de service. El serviceType atributo del service elemento identifica la clase de servicio que implementa el servicio al que se aplica esta configuración, que en este caso es Calculator. Cada service elemento puede contener uno o varios endpoint elementos, cada uno de los cuales especifica un punto de conexión determinado a través del cual se puede acceder a este servicio Indigo. En este ejemplo, el servicio expone solo un único punto de conexión, por lo que solo aparece un endpoint elemento. El nombre del contrato del punto de conexión es Calculator, que es el nombre de la clase que lo implementa. Si este archivo de configuración fuera para la segunda Calculator clase de servicio mostrada anteriormente, que definió su contrato de servicio mediante una interfaz explícita, el valor del serviceType atributo seguirá siendo el mismo, pero el valor de contractType sería ICalculator, el nombre de esta interfaz explícita. El enlace especificado aquí es basicProfileHttpBinding, aunque este es el valor predeterminado, podría haberse omitido. Y suponiendo Calculator que es un servicio hospedado por WAS, se crea automáticamente una dirección, por lo que no es necesario especificar una en este archivo de configuración.

Creación de un cliente indigo

La creación de un servicio Indigo básico no es especialmente complicada. La creación de un cliente Indigo es incluso más sencilla. Todo lo necesario es crear un stand-in local para el servicio, denominado proxy, que está conectado a un punto de conexión determinado en el servicio de destino y, a continuación, invocar las operaciones del servicio a través de este proxy. En la ilustración siguiente se muestra cómo se ve esto.

La creación de un proxy requiere saber exactamente qué contrato expone el punto de conexión de destino y, a continuación, usar la definición de este contrato para generar el proxy. En Indigo, este proceso se realiza mediante una herramienta denominada svcutil. Si el servicio se implementa mediante Indigo, svcutil puede acceder al archivo DLL del servicio para obtener información sobre el contrato y generar un proxy. Si solo está disponible la definición de WSDL del servicio, svcutil puede leerlo para generar un proxy. Si solo el propio servicio está disponible, svcutil puede acceder a él directamente mediante WS-MetadataExchange o una solicitud HTTP GET simple para adquirir la definición de interfaz WSDL del servicio y, a continuación, generar el proxy.

Sin embargo, se genera, el cliente puede crear una nueva instancia del proxy y, a continuación, invocar los métodos del servicio mediante él. Este es un ejemplo sencillo de un cliente para la Calculator clase :

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();
  }
} 

Una cosa más sigue siendo especificada por el cliente: el punto de conexión exacto en el que desea invocar operaciones. Al igual que un servicio, el cliente debe especificar el contrato del punto de conexión, su enlace y su dirección, y esto normalmente se realiza en un archivo de configuración. De hecho, si hay suficiente información disponible, svcutil generará automáticamente un archivo de configuración de cliente adecuado para el servicio de destino.

Otros aspectos de Indigo

Los conceptos básicos de los servicios y clientes son fundamentales para cada aplicación indigo. Sin embargo, la mayoría de esas aplicaciones también usarán otros aspectos de esta tecnología. En esta sección se examinan algunas de las características adicionales que Indigo proporciona para las aplicaciones integradas en ella.

Controlar el comportamiento local

Muchos aspectos de Indigo, como contratos, enlaces, etc., están relacionados con la comunicación entre un servicio y sus clientes. Sin embargo, también hay partes del comportamiento de un servicio que son básicamente locales. ¿Cómo se controla la duración de una instancia de servicio, por ejemplo, y cómo se administra el acceso simultáneo a esa instancia? Para permitir que los desarrolladores controlen comportamientos como estos, Indigo define dos atributos principales, ambos con varias propiedades. Uno de estos atributos, ServiceBehavior, se puede aplicar a las clases que también están marcadas con el ServiceContract atributo . El otro, OperationBehavior, se puede aplicar a los métodos de una clase de servicio que también están marcados con el OperationContract atributo .

El ServiceBehavior atributo tiene varias propiedades que afectan al comportamiento del servicio en su conjunto. Por ejemplo, se puede usar una propiedad denominada ConcurrencyMode para controlar el acceso simultáneo al servicio. Si se establece en Single, Indigo entregará solo una solicitud de cliente a la vez a este servicio, es decir, el servicio será de un solo subproceso. Si esta propiedad se establece Multipleen , Indigo entregará más de una solicitud de cliente a la vez al servicio, cada una en ejecución en un subproceso diferente. De forma similar, ServiceBehaviorla propiedad de InstanceMode se puede usar para controlar cómo se crean y destruyen las instancias de un servicio. Si InstanceMode se establece en PerCall, se creará una nueva instancia del servicio para controlar cada solicitud de cliente y, a continuación, se destruirá cuando se complete la solicitud. Sin embargo, si se establece PrivateSessionen , se usará la misma instancia del servicio para controlar todas las solicitudes de un cliente determinado.

Supongamos, por ejemplo, que su creador decidió que la Calculator clase debe ser multiproceso y usar la misma instancia para cada llamada de un cliente determinado. La definición de la clase tendría el siguiente aspecto:

using System.ServiceModel;

[ServiceContract] 
[ServiceBehavior(
  ConcurrencyMode=Multiple, 
  InstanceMode=PrivateSession)]
class Calculator { ... } 

Del mismo modo, las propiedades del OperationBehavior atributo permiten controlar el comportamiento de suplantación del método que implementa esta operación, sus requisitos transaccionales (descritos más adelante) y otras cosas.

Opciones de mensajería

En los ejemplos sencillos que se muestran en este artículo se supone un enfoque sincrónico de llamada a procedimiento remoto (RPC) para la interacción del cliente o servicio. Indigo admite esta opción, pero no es la única opción. SOAP es un protocolo orientado a mensajes, lo que significa que puede admitir una variedad de modelos de programación. De hecho, Indigo admite varias posibilidades, entre las que se incluyen las siguientes:

• RPC tradicional, con llamadas de bloqueo que llevan listas de parámetros con tipo;
• RPC asincrónico, con llamadas sin bloqueo que llevan listas de parámetros con tipo;
• Mensajería tradicional, con llamadas sin bloqueo que llevan un único parámetro de mensaje;
• RPC basada en mensajes, con llamadas de bloqueo que llevan un único parámetro de mensaje.

Y aunque la gran mayoría de las aplicaciones distribuidas lo requieran, la especificación SOAP no dice nada sobre la confiabilidad. Una manera habitual de garantizar la confiabilidad es usar SOAP solo en escenarios de punto a punto, basándose en TCP para garantizar la entrega de solicitudes y respuestas. Esto es suficiente en algunos casos y es lo que se hace cuando se usa BasicProfileHttpBinding.

Sin embargo, hay muchos casos para los que esto no es suficiente. ¿Qué ocurre si se accede a un servicio a través de varios intermediarios SOAP, por ejemplo? Las garantías de confiabilidad proporcionadas por TCP no son suficientes en este caso para garantizar la confiabilidad de un extremo a otro. Para solucionar este problema, Indigo implementa la especificación WS-ReliableMessaging. Al elegir un enlace como WsHttpBinding, que usa WS-ReliableMessaging, un servicio y su cliente pueden garantizar una comunicación de un extremo a otro confiable incluso a través de varios intermediarios SOAP.

Seguridad

La exposición de servicios en una red, incluso una red interna, normalmente requiere algún tipo de seguridad. ¿Cómo puede el servicio estar seguro de la identidad de su cliente? ¿Cómo se pueden enviar mensajes hacia y desde un servicio a salvo de cambios malintencionados y ojos indiscretos? ¿Y cómo se puede limitar el acceso a un servicio solo a los autorizados para usarlo? Sin alguna solución a estos problemas, es demasiado peligroso exponer muchos tipos de servicios. Sin embargo, la creación de aplicaciones seguras puede resultar complicada. Lo ideal es que haya maneras sencillas de abordar escenarios de seguridad comunes, junto con un control más específico para las aplicaciones que lo necesitan.

Para ello, Indigo proporciona las principales funciones de seguridad de autenticación, integridad de mensajes, confidencialidad del mensaje y autorización. El enfoque de Indigo para los tres primeros se basa principalmente en enlaces y las opciones de un desarrollador incluyen lo siguiente:

• Elija un enlace estándar que admita la seguridad. Las aplicaciones que solo necesitan seguridad basada en transporte, por ejemplo, pueden usar un enlace como BasicProfileHttpsBinding. Este enfoque es suficiente para las solicitudes que van directamente de un cliente a un servicio sin atravesar ningún intermediario, como servidores proxy HTTP u otros nodos SOAP. Las aplicaciones que requieren seguridad de un extremo a otro para los mensajes que pasan por varios intermediarios SOAP pueden usar en su lugar un enlace que admita WS-Security, como WsHttpBinding.
• Elija un enlace estándar que admita la seguridad y, a continuación, personalícelo cambiando uno o varios de sus valores predeterminados. Por ejemplo, el mecanismo de autenticación utilizado por un enlace como WsHttpBinding se puede cambiar si lo desea.
• Cree un enlace personalizado que proporcione exactamente las características de seguridad que necesita un desarrollador. Esto no es para el desmayo del corazón, pero puede ser la solución adecuada para algunos escenarios avanzados.
• Elija un enlace estándar que no admita la seguridad, como BasicProfileHttpBinding. Aunque el uso de ninguna seguridad suele ser una cosa arriesgada, puede ser la mejor opción en algunas situaciones.

Un servicio Indigo también puede controlar qué clientes están autorizados para usar sus servicios. En su mayor parte, Indigo solo admite los mecanismos de autorización existentes en .NET Framework. Un servicio puede usar el atributo estándar PrincipalPermission , por ejemplo, para definir quién puede acceder a él.

Permitir a los desarrolladores crear aplicaciones seguras sin exponerlas a una complejidad abrumadora ha demostrado ser difícil en el pasado. Al proporcionar un enfoque sencillo para los casos más comunes y el control específico para situaciones más complejas, Indigo tiene como objetivo alcanzar este objetivo de forma utilizable y eficaz.

Transacciones

El control de transacciones es un aspecto importante de la creación de muchos tipos de lógica de negocios. Sin embargo, el uso de transacciones en un mundo orientado a servicios puede ser problemático. Las transacciones distribuidas suponen un alto nivel de confianza entre los participantes, por lo que a menudo no es adecuado que una transacción abarque un límite de servicio. Aun así, hay situaciones en las que la combinación de transacciones y servicios tiene buen sentido, por lo que Indigo incluye compatibilidad con este aspecto importante del diseño de aplicaciones.

Transacciones en .NET Framework 2.0

La compatibilidad con transacciones en Indigo se basa en las mejoras proporcionadas en la versión 2.0 de .NET Framework. Esta próxima versión incluye System.Transactions, un nuevo espacio de nombres centrado únicamente en controlar los comportamientos transaccionales. Los desarrolladores suelen usar los servicios de System.Transactions en conjunto con un contexto de ejecución, una construcción que es nueva en la versión 2.0 de .NET Framework. Un contexto de ejecución permite especificar información común, como una transacción, que se aplica a todo el código contenido dentro de un ámbito definido. Este es un ejemplo de cómo una aplicación puede usar este enfoque para agrupar un conjunto de operaciones en una sola transacción:

using System.Transactions;

using (TransactionScope ts 
   = new TransactionScope(TransactionScopeOption.Required)) {
   // Do work, e.g., update different DBMSs
   ts.Complete();
}

Todas las operaciones dentro del using bloque se convertirán en parte de una sola transacción, ya que comparten el contexto de ejecución transaccional que define. La última línea de este ejemplo, que llama al TransactionScopemétodo de Complete , dará como resultado una solicitud para confirmar la transacción cuando se salga del bloque. Este enfoque también proporciona control de errores integrado, anulando la transacción si se produce una excepción.

Especificar Required para el nuevo TransactionScope, como hace este ejemplo, significa que este código siempre se ejecutará como parte de una transacción: unir la transacción del autor de la llamada si existe, creando uno nuevo si no lo hace. Como en Enterprise Services, también se pueden especificar otras opciones, como RequiresNew, Supportedy NotSupported.

A diferencia de Enterprise Services y sus predecesores MTS y COM+, Systems.Transactions se centra completamente en controlar el comportamiento transaccional. No hay ninguna conexión necesaria entre una transacción y el estado interno de un objeto, por ejemplo. Aunque Enterprise Services requiere que se desactive un objeto cuando finaliza una transacción, Systems.Transactions no realiza dicha demanda. Dado que Indigo se basa en Systems.Transaction, las aplicaciones Indigo también son gratuitas para administrar transacciones y el estado de objetos de forma independiente.

Transacciones en Indigo

Las aplicaciones indigo pueden usar System.Transactions explícitamente o pueden controlar las transacciones mediante atributos que se basan en System.Transactions en segundo plano. Una opción es para un método dentro de una clase marcada con el ServiceContract atributo para encapsular su trabajo en una transacción mediante TransactionScope, como se acaba de describir. Por ejemplo, este método podría incluir una using instrucción que establece un ámbito de transacción y, a continuación, actualizar dos bases de datos independientes dentro de esa transacción.

Los métodos de un servicio también pueden controlar el comportamiento transaccional mediante un atributo . En lugar de usar explícitamente System.Transactions, un servicio puede usar el OperationBehavior atributo descrito anteriormente. Este es un ejemplo:

using System.ServiceModel;

[ServiceContract]
class XactOperations
{
 [OperationContract]
    public int Add(int value1, int value2)
    {
       return value1 + value2;
    }

 [OperationContract] 
 [OperationBehavior(RequireTransaction=true,
                    AutoCompleteTransaction=true)]
 int Update(int value1, int value2)
 {
       // Insert value1 and value2 into
    // two different databases
 }
}

El primer método de este ejemplo, Add, no usa una transacción y, por tanto, su operación sencilla se realizará igual que antes. Pero el segundo método, Update, va precedido por el OperationBehavior atributo con la RequireTransaction propiedad establecida en true. Por este motivo, todo el trabajo realizado dentro de este método se realizará dentro de una transacción, como si estuviera dentro del ámbito de transacción del using bloque mostrado anteriormente. Y dado que también se especifica la AutoCompleteTransaction propiedad , la transacción votará automáticamente para confirmar si no se produce ninguna excepción.

Si el cliente que invoca este método no se ejecuta dentro de una transacción, el Update método se ejecutará en su propia transacción, no hay ninguna otra opción. Pero supongamos que el cliente ya forma parte de una transacción existente cuando llama a Update. ¿El trabajo realizado por el Update método se unirá a la transacción del cliente o seguirá ejecutándose dentro de su propia transacción independiente? La respuesta depende de si este servicio puede aceptar un contexto de transacción pasado por el cliente, una opción controlada mediante la TransactionFlowAllowed propiedad del OperationContract atributo . Si TransactionFlowAllowed no está asociado a un método en el servicio, como en el ejemplo anterior, el trabajo realizado dentro de este método nunca puede unirse a una transacción existente. Sin embargo, si este atributo está presente, un método puede unirse a la transacción de su cliente.

También merece la pena destacar que las aplicaciones basadas en Indigo pueden participar en transacciones que incluyen aplicaciones que se ejecutan en plataformas que no son Indigo. Por ejemplo, una aplicación Indigo podría iniciar una transacción, actualizar un registro en una base de datos de SQL Server local y, a continuación, invocar un servicio web implementado en un servidor de aplicaciones J2EE que actualiza un registro en otra base de datos. Si este servicio es transaccional y la plataforma en la que se ejecuta admite la especificación WS-AtomicTransaction, ambas actualizaciones de base de datos pueden formar parte de la misma transacción. Al igual que la seguridad y la mensajería confiable, las transacciones indigo funcionan en el mundo heterogéneo que los servicios web hacen posible.

Cola

Con un enlace como WsHttpBinding, una aplicación Indigo puede comunicarse de forma confiable con otra aplicación basada en Indigo o con cualquier otra plataforma de servicios web que implemente WS-ReliableMessaging. Pero aunque la tecnología que define esta especificación garantiza una entrega de un extremo a otro confiable de un mensaje SOAP, no direcciona la cola de mensajes. Con la puesta en cola, una aplicación envía un mensaje a una cola en lugar de directamente a otra aplicación. Cuando la aplicación receptora esté lista, puede leer el mensaje de la cola y procesarlo. Permitir este tipo de interacción es útil, por ejemplo, cuando el remitente de un mensaje y su receptor podrían no estar ejecutándose al mismo tiempo.

En consecuencia, Indigo proporciona compatibilidad con la puesta en cola de mensajes. Esta compatibilidad se basa en MSMQ, lo que significa que, a diferencia de la mayoría de los demás aspectos de Indigo, como la mensajería confiable, la seguridad y las transacciones, la puesta en cola de Indigo no interopera directamente a través de los límites del proveedor (aunque hay disponible un puente de MSMQ-MQSeries).

Para usar indigo en cola, un desarrollador crea una clase de servicio Indigo estándar, marcada como de costumbre con ServiceContract. Sin embargo, las operaciones del contrato de servicio de esta clase tienen algunas limitaciones. En concreto, todos deben marcarse como unidireccionales, lo que significa que no se devuelve ninguna respuesta. Esto no es sorprendente, ya que invocar una operación en cola envía un mensaje a una cola en lugar de a su receptor final, por lo que esperar una respuesta inmediata no tendría mucho sentido. Al igual que cualquier otra clase de servicio, las aplicaciones indigo en cola exponen puntos de conexión. Estos puntos de conexión usan enlaces como NetMsmqBinding, que permite la comunicación con otras aplicaciones indigo en cola o MsmqIntegrationBinding, lo que permite que una aplicación Indigo en cola interopera con una aplicación MSMQ estándar que no use Indigo. Indigo QueueIng también admite otras características tradicionales de entornos en cola, como colas de mensajes fallidos y control de mensajes dudosos.

La puesta en cola es el enfoque adecuado para un conjunto significativo de aplicaciones distribuidas. La compatibilidad de Indigo con este estilo de comunicación permite a los desarrolladores crear aplicaciones en cola sin aprender una tecnología de puesta en cola completamente independiente.

Coexistencia y migración

Indigo representa un enfoque moderno para crear aplicaciones distribuidas en la era de servicios confiables, seguros y transaccionales. Sin embargo, un punto clave para comprender es que la instalación de Indigo no interrumpirá ninguna aplicación existente. El código actual que se ejecuta en ASMX, .NET Remoting y las demás tecnologías cuya funcionalidad está subsumada por Indigo seguirá ejecutándose, por lo que no es necesario pasar a Indigo. Pero para las organizaciones con inversiones en tecnologías actuales de Microsoft, queda una pregunta obvia: ¿qué ocurre con el código existente escrito con las tecnologías que preceden a Indigo?

Para cada una de las tecnologías actuales cuyo futuro se ve profundamente afectado por la llegada de Indigo, los desarrolladores deben comprender dos cosas: si las aplicaciones creadas en esta tecnología interoperarán con aplicaciones basadas en Indigo y cuánto trabajo será portar aplicaciones de esta tecnología al entorno indigo. Esta es una breve descripción de cómo cada tecnología aborda estos problemas:

• ASP.NET servicios web (ASMX): los servicios web creados con ASMX interoperarán con aplicaciones Indigo. Dado que ASP.NET servicios web y Indigo admiten SOAP estándar, esto no debería ser sorprendente. Mover el código de servicios web de ASP.NET existentes a Indigo requerirá algún trabajo mecánico, pero aún debe ser sencillo. La estructura básica de las dos tecnologías es bastante similar, por lo que, para la mayoría de los atributos y archivos de configuración, será necesario cambiar. Sin embargo, las características más avanzadas, como extensiones SOAP, no serán directamente portátiles a Indigo. En su lugar, tendrán que volver a escribirse mediante las opciones de extensibilidad que proporciona Indigo.
• .NET Remoting: las aplicaciones creadas en .NET Remoting no interoperarán con aplicaciones basadas en Indigo; sus protocolos de conexión no son compatibles. Mover el código existente de .NET Remoting a Indigo requerirá algún esfuerzo, pero será posible. Sin embargo, cualquier persona que haya creado extensiones personalizadas de .NET Remoting, como canales y receptores, encontrará que este código no se migrará al nuevo mundo. Las extensiones similares son posibles en Indigo, pero las interfaces para hacerlo no coinciden con las de .NET Remoting.
• Servicios empresariales: para permitir que una aplicación de Enterprise Services existente interoperar con clientes indigo (u otro software basado en servicios web), un desarrollador puede identificar exactamente qué interfaces de esa aplicación se deben exponer. Con una herramienta proporcionada por Indigo, los contratos de servicio se pueden crear automáticamente para esas interfaces y exponerse a través de Indigo. En el caso de los clientes existentes de aplicaciones de Enterprise Services que no se basan en .NET Framework (y para otros clientes puramente basados en COM), se proporciona un moniker indigo para permitir un acceso sencillo a los servicios web. El esfuerzo necesario para migrar las aplicaciones existentes de Enterprise Services para que se ejecuten directamente en Indigo será similar a lo que se requiere para portar aplicaciones ASMX. Gran parte del trabajo, aunque no todos, serán cambios mecánicos sencillos en atributos y espacios de nombres.
• Mejoras de servicios web (WSE): WSE es la solución táctica de Microsoft para implementar aplicaciones de servicios web que requieren algunas o todas las funciones proporcionadas por las especificaciones WS-*. Las aplicaciones compiladas con WSE 1.0 y WSE 2.0 no interoperan con aplicaciones basadas en Indigo. Las aplicaciones basadas en WSE 3.0, que se enviarán antes de que indigo se libere, interoperarán con las aplicaciones indigo, sin embargo. Para la portabilidad, el artículo es similar a las tecnologías ya descritas: se requerirá cierta cantidad de esfuerzo para mover el código existente de WSE a Indigo, aunque este esfuerzo se minimizará para las aplicaciones que usan la versión final de WSE.
• MSMQ: dado que las funciones de puesta en cola de Indigo se basan en MSMQ, las aplicaciones en cola basadas en Indigo pueden interoperar con aplicaciones en cola creadas directamente en MSMQ. La portabilidad de aplicaciones desde el espacio de nombres System.Messaging proporcionado con .NET Framework original requerirá algún trabajo, ya que esta interfaz anterior es diferente de lo que proporciona Indigo. Una vez que Indigo se distribuye, los desarrolladores deben usarlo en lugar de System.Messaging para crear la mayoría de las aplicaciones de puesta en cola basadas en MSMQ.

Antes de que Indigo esté disponible, la mejor opción de tecnología para aplicaciones .NET distribuidas que no necesitan cola es probablemente ASMX. Es fácil de usar y también proporciona la ruta de migración más fluida a Indigo. Enterprise Services también puede tener sentido para las aplicaciones que necesitan las cosas que proporciona, como las transacciones distribuidas, mientras que MSMQ sigue siendo la opción adecuada para las aplicaciones en cola. Sin embargo, se debe usar .NET Remoting principalmente para la comunicación entre dos dominios de aplicación en el mismo proceso. ASMX es una mejor opción para la comunicación directa de la aplicación a la aplicación en la mayoría de los demás casos.

La introducción al nuevo software siempre tiene un impacto en lo que ya existe. Al proporcionar una base común para crear aplicaciones orientadas a servicios, Indigo ofrece una plataforma más sencilla y coherente para los desarrolladores. Aunque este cambio provoca algún dolor, el objetivo de los creadores de Indigo es hacer que la transición sea lo más fluida y sencilla posible.

Conclusiones

Indigo representa una evolución importante en la forma en que los desarrolladores crean software. A medida que las aplicaciones orientadas a servicios se convierten en la norma, Indigo será una tecnología estándar para los desarrolladores de software de Windows. Otros productos de Microsoft también cambiarán para aprovechar las ventajas de lo que ofrece Indigo. BizTalk Server, por ejemplo, agregará compatibilidad con Indigo como opción de comunicación en algún momento después de la versión de BizTalk Server 2006. Dado que Indigo proporciona una base estándar para el software orientado a servicios, será la base de una gran fracción de la comunicación de Windows.

El impacto de esta tecnología no será pequeño. Cualquier persona que compile aplicaciones distribuidas en Windows, especialmente las aplicaciones que deben interoperar con las de otras plataformas, debe prestar mucha atención. Indigo cambiará significativamente su mundo.

 

Acerca del autor

David Chappell es director de Chappell & Associates (www.davidchappell.com) en San Francisco, California. Este artículo se extrae de su próximo libro sobre Indigo, publicado por Addison-Wesley.