Exportar (0) Imprimir
Expandir todo
Expandir Minimizar

Presentación de Indigo: primeras impresiones (Artículos técnicos sobre -Longhorn-)

fecha de actualizacion o subtitulo

Publicado: fecha de publicacion

David Chappell

Chappell & Associates

Resumen: en este artículo se ofrece información general sobre la arquitectura de "Indigo", el modelo unificado de programación que Microsoft ofrece para crear aplicaciones orientadas a servicios. En él se trata la relación de Indigo con las tecnologías de aplicaciones distribuidas existentes en .NET Framework, se comenta los conceptos básicos de creación y consumo de los servicios de Indigo, y se ofrece una visión general de las capacidades de Indigo, entre las que se incluye la compatibilidad con transacciones, mensajería confiable y seguridad. (24 páginas impresas.)

Nota. Este artículo se basa en una versión preliminar de Indigo‚ la primera Community Technology Preview (CTP). No hay que olvidar que los detalles de las características y la implementación pueden cambiar a medida que Indigo avance a través del ciclo de producto.

En esta página

Qué es Indigo Qué es Indigo
Qué ofrece Indigo Qué ofrece Indigo
Creación de un servicio de Indigo Creación de un servicio de Indigo
Creación de un cliente de Indigo Creación de un cliente de Indigo
Otros aspectos de Indigo Otros aspectos de Indigo
Coexistencia y migración Coexistencia y migración
Conclusiones Conclusiones

Qué es Indigo

Seleccionar las mejores abstracciones para crear software es un proceso que no finaliza nunca. Actualmente, los objetos constituyen el enfoque dominante en la creación de la lógica empresarial de una aplicación, pero el modelado de la comunicación entre aplicaciones mediante objetos no ha obtenido los resultados deseados. Un enfoque más adecuado consiste en modelar específicamente 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 creación de software resulta más novedosa. Por este motivo, en general apenas hay tecnologías disponibles diseñadas específicamente para crear aplicaciones orientadas a servicios.

El marco de Microsoft para crear aplicaciones orientadas a servicios, cuyo nombre en clave es Indigo, cambia esta situación. Indigo permite a los desarrolladores que actualmente crean aplicaciones orientadas a objetos con .NET Framework crear también aplicaciones orientadas a servicios de una manera similar. Además, 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 tecnologías 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 anterior 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 tendrán acceso los clientes. Un cliente y un servicio interactúan a través 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 extensión que se basa en .NET Framework 2.0, cuyo lanzamiento está previsto para 2005 como parte de la versión Windows cuyo nombre clave es Longhorn, prevista para 2006. También estará disponible en Windows XP y Windows Server 2003. Esta descripción se basa en una versión preliminar de la primera Community Technology Preview de Indigo. No olvide que es probable que se realicen ciertos cambios (de hecho, es casi seguro) antes del lanzamiento de la versión final.

Qué ofrece Indigo

Un gran equipo de Microsoft ha dedicado años a la creación 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 tecnología. Hay tres aspectos que destacan, no obstante, como las características más importantes de Indigo: la unificación de varias tecnologías de Microsoft existentes, su compatibilidad con la interoperabilidad con otros proveedores y su orientación explícita a servicios. Esta sección trata estas características.

Unificación de las tecnologías de computación distribuida de Microsoft

Las primeras versiones de .NET Framework incluían varias tecnologías diferentes para crear aplicaciones distribuidas. La siguiente figura las muestra, junto con el motivo principal por el que un desarrollador utilizaría dicha tecnología. Para crear servicios Web básicos interoperables, por ejemplo, la mejor opción 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 más adecuado. Si la aplicación requería transacciones distribuidas y servicios más avanzados, era probable que su creador utilizara Enterprise Services, el sucesor de .NET Framework a COM+. Para aprovechar las especificaciones de servicios Web más recientes, como WS-Addressing y WS-Security, un desarrollador podría crear aplicaciones que utilizaran Web Services Enhancements (WSE), la implementación inicial de Microsoft de estas nuevas especificaciones. Por último, para crear aplicaciones con colas y basadas en mensajes, un desarrollador basado en Windows podría utilizar Microsoft Message Queuing (MSMQ).

ASMX

.NET Remoting

Enterprise Services

WSE

MSMQ

Indigo

Servicios Web interoperables

X

.

.

.

.

X

Comunicación .NET – .NET

.

X

.

.

.

X

Transacciones distribuidas, etc.

.

.

X

.

.

X

Compatibilidad con las especificaciones WS-*

.

.

.

X

.

X

Mensajería 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 solución mejor consistía en tener una única tecnología 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 tecnologías que subsume. Aunque Microsoft seguirá ofreciendo compatibilidad con las tecnologías anteriores, la mayoría de las nuevas aplicaciones que antes hubieran utilizado estas tecnologías ahora se crearán en Indigo.

Interoperabilidad con las aplicaciones que no son de Microsoft

Conseguir que la vida de los desarrolladores de Windows sea más sencilla gracias a la unificación de tecnologías diversas es una buena idea. Pero con el acuerdo universal sobre servicios Web entre los proveedores, también es posible resolver el eterno problema de la interoperabilidad entre aplicaciones. Al ser SOAP el mecanismo fundamental de comunicación 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 aplicación creada en Indigo puede interactuar con todas las aplicaciones siguientes:

  • 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 tecnologías, como servidores de aplicaciones basados en Java 2, Enterprise Edition (J2EE), que admitan servicios Web estándar. 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 también pueden interoperar con aplicaciones creadas en algunas de las tecnologías de .NET Framework anteriores a Indigo, por ejemplo ASMX, como se describe más adelante.

Para permitir una comunicación más amplia que la básica, Indigo implementa un grupo de novedosas tecnologías de servicios Web a las que se denomina colectivamente como especificaciones WS-*. Estos documentos definen métodos de varios proveedores para agregar transacciones, seguridad, mensajería 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 normalización como OASIS (Organization for the Advancement of Structured Information Standards). Las especificaciones de servicios Web que admite 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 MTOM (SOAP Message Transmission Optimization Mechanism).

Cuando una aplicación de Indigo se comunica con una aplicación que se ejecuta en un sistema que no es Windows, se utiliza el protocolo estándar SOAP (tal vez con algunas extensiones WS-*), representadas en la conexión mediante la habitual codificación de XML basado en texto. Cuando una aplicación basada en Indigo se comunica con otra aplicación basada en Indigo, no obstante, es conveniente optimizar esta comunicación. Aunque se ofrecen todas las mismas características, incluidas las transacciones, seguridad y mensajería confiable, la codificación de la conexión es una versión binaria optimizada de SOAP. Los mensajes siguen la estructura de datos de un mensaje SOAP, conocido como Infoset, pero la codificación utiliza una representación binaria del Infoset en vez de los habituales corchetes angulares y el formato de texto del XML.

Compatibilidad explícita con el desarrollo orientado a servicios

La idea de considerar una aplicación 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 propósito, los creadores de Indigo han tenido muy en cuenta cuatro principios fundamentales a la hora de diseñar esta tecnología:

  • Compartir el esquema, no la clase: a diferencia de las anteriores tecnologías de objetos distribuidos, los servicios interactúan con los clientes sólo mediante una interfaz XML bien definida. No se permiten algunos comportamientos como la transferencia de clases completas, métodos y todo, a través de los límites de los servicios.

  • Los servicios son autónomos: 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 ejecución, como CLR y la máquina virtual Java, ejecutarse en diferentes sistemas operativos y diferir en otros aspectos.

  • Los límites son explícitos: un objetivo de las tecnologías de objetos distribuidos como COM distribuido (DCOM) era conseguir que los objetos remotos fueran lo más similares posible a los objetos locales. Aunque este enfoque simplificaba el desarrollo en cierto modo al proporcionar un modelo de programación común, también ocultaba las diferencias inevitables entre objetos locales y objetos remotos. Los servicios evitan este problema al hacer más explícitas las interacciones entre los servicios y sus clientes. No se intenta ocultar la distribución.

  • Utilizar compatibilidad basada en directivas: siempre que sea posible, la especificación de las opciones que se utilizarán entre sistemas debe fundamentarse en mecanismos basados en directivas WS-Policy.

La orientación a servicios es un campo amplio, que abarca las aplicaciones orientadas a servicios y los conceptos, más 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.

Creación de un servicio de Indigo

Como muestra la siguiente figura, todos los servicios de Indigo se crean mediante tres elementos:

  • Una clase de servicio, implementada en C#, en VB.NET o en otro lenguaje basado en CLR, que implementa uno o varios métodos;

  • Un entorno host, un proceso y un dominio de aplicación, en el que se ejecuta el servicio;

  • Uno o varios extremos que permiten a los clientes tener acceso al servicio.

Toda la comunicación con un servicio de Indigo se realiza a través de los extremos del servicio. Cada extremo especifica un contrato que identifica los métodos a los que se puede tener acceso mediante este extremo, un enlace que determina cómo puede comunicarse un cliente con este extremo y una dirección que indica dónde se puede encontrar este extremo.

Para entender Indigo es necesario comprender bien todos estos conceptos. Esta sección los describe uno por uno, comenzando por las clases de servicio.

Creación 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 también puede implementar explícitamente un contrato de datos, que define los datos que transmiten estas operaciones. Esta sección estudia ambos, comenzando por los contratos de servicio.

Definición de contratos de servicio

Todas las clases de servicio de Indigo implementan los métodos que pueden utilizar los clientes. El creador de la clase de servicio determina los métodos que se exponen como operaciones a las que el cliente puede llamar mediante su inclusión en un contrato de servicio. La definición de los contratos de servicio, de hecho, el trabajar explícitamente 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 programación 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 definición de clase, una definición de método 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 método es un servicio Web al que se puede llamar mediante SOAP en la tecnología ASMX de Framework, dicho método se precede con el atributo WebMethod. De manera similar, Enterprise Services utiliza el atributo Transaction para indicar que un método requiere una transacción. Indigo aplica esta idea a los servicios y establece una gama de atributos que permiten definir y controlar los servicios.

El atributo más 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 continuación, podemos ver un sencillo ejemplo en C# que utiliza el primer método:

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 demás atributos que Indigo utiliza se definen en el espacio de nombres System.ServiceModel, por lo que el ejemplo comienza con una instrucción using que hace referencia a este espacio de nombres. Todos los métodos de una clase de servicio a los que el cliente puede llamar deben marcarse con otro atributo denominado OperationContract. Indigo expone todos los métodos 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 están marcados con este atributo por lo que quedan expuestos a los clientes de este servicio. Todos los métodos de una clase de servicio que no estén marcados con OperationContract, como Multiply en el ejemplo anterior, no se incluirán en el contrato de servicio, por lo que los clientes de este servicio de Indigo no podrán llamarlos.

Dos abstracciones bastante diferentes, servicios y objetos, se unen en Indigo. Es importante comprender que ambas se basan en contratos, de manera explícita o implícita, para definir lo que exponen al mundo exterior. Un objeto, especificado por alguna clase, define de forma efectiva un contrato que determina cuáles son los métodos a los que puede llamar otro objeto de la misma aplicación. El acceso a estos métodos queda controlado por palabras clave del 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, que son los dos métodos públicos de la clase. El contrato de objetos de esta clase expone únicamente estos dos métodos.

Mediante los atributos de Indigo, Calculator también define un contrato de servicio, como acabamos de ver. Este contrato también tiene dos métodos, 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 método, en vez de las palabras public y private. Como este atributo aparece únicamente en Add y Subtract, los clientes sólo pueden llamar a estos dos métodos. Los contratos de objetos y los contratos de servicios son completamente independientes y por tanto un método como Add puede ser private aunque lleve el atributo OperationContract.

El ejemplo que acabamos de ver muestra la manera más 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 implícitamente y consta de todos los métodos de la clase marcados con OperationContract. También es posible (y probablemente mejor en la mayoría de los casos) especificar los contratos de servicio de manera explícita mediante un tipo interface del lenguaje. Empleando este método, la clase Calculator podría 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 métodos que contiene en vez de a la clase Calculator propiamente dicha. El resultado es el mismo, no obstante, de manera que esta versión del servicio expone el mismo contrato de servicio que la anterior. El uso de interfaces explícitas como la anterior es ligeramente más complicado, pero también ofrece una mayor flexibilidad. Por ejemplo, una clase puede implementar más de una interfaz, lo que permite implementar por tanto más 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.

Un último detalle: al marcar una clase de servicio con ServiceContract y OperationContract también es posible generar automáticamente definiciones de contrato de servicio en Lenguaje de descripción de servicios Web (WSDL). Por lo tanto, se puede obtener acceso a la definición visible externamente de cada contrato de servicio de Indigo como un documento WSDL estándar que especifica las operaciones del contrato. Y aunque no se describe aquí, también es posible crear una clase de servicio de Indigo directamente a partir de un documento WSDL, un método que resulta especialmente útil para implementar interfaces WSDL definidas externamente.

Definición de contratos de datos

Una clase de servicio de Indigo especifica un contrato de servicio que define los métodos que se exponen a los clientes del servicio. Todas estas operaciones también suelen implicar ciertos datos, lo que significa que un contrato de servicio también implica cierto contrato de datos que describa la información que se intercambiará. En algunos casos, este contrato de datos se define implícitamente como parte del contrato de servicio. Por ejemplo, en las clases Calculator mostradas anteriormente, cada método utiliza dos parámetros, ambos enteros, y devuelve un único entero. Estos parámetros 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 operación utiliza únicamente tipos simples, tiene sentido definir los aspectos de los datos del contrato de manera implícita en el contrato de servicio. No es necesario nada más.

Pero los servicios también pueden tener parámetros de tipos más complejos, como estructuras. En este tipo de casos, es necesario un contrato de datos explícito. Los contratos de datos definen cómo se convierten los tipos en memoria a un formato apto para su transmisión a través del cable, proceso denominado serialización. De hecho, los contratos de datos son un mecanismo para controlar cómo se serializan los datos.

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 parámetro en un método marcado con OperationContract, sólo se pasarán los campos marcados con el atributo DataMember (Name y CreditRating).

El hecho de que un campo esté etiquetado como public o private no tiene ningún efecto sobre cómo se serializará el campo. Al igual que ocurre con los métodos, las palabras clave public y private son parte del contrato que define cómo otros objetos de la misma aplicación pueden tener acceso a este tipo. DataMember, al igual que OperationContract, define cómo 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 señalar 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 explícitamente los atributos ServiceContract y DataContract para indicar los tipos que tienen contratos definidos por Indigo y, a continuación, especificar explícitamente las partes de dichos tipos que se exponen a los clientes de este servicio utilizando los atributos OperationContract y DataMember. Uno de los principios básicos de los diseñadores era que los servicios tuvieran límites explícitos y, por tanto, Indigo es una tecnología que permite elegir. Todo lo que un servicio pone a disposición de sus clientes deberá especificarse expresamente en el código.

Los contratos y los atributos que los definen son uno de los aspectos más importantes de Indigo y esta breve descripción sólo trata los puntos más destacados. El atributo OperationContract se puede utilizar para definir operaciones unidireccionales, por ejemplo, si una llamada a un servicio no tiene respuesta. También es posible definir interacciones en las que ambas partes pueden actuar como cliente y servicio, cada una de ellas invocando operaciones y exponiendo las operaciones invocadas por la otra parte, mediante la creación de contratos llamados dúplex. El atributo DataContract ofrece varias opciones más, siendo posible incluso trabajar directamente con mensajes SOAP utilizando un atributo llamado MessageContract. Los contratos se utilizan para expresar muchos de las posibilidades que ofrece Indigo, por lo que constituyen uno de sus conceptos más importantes.

Selección de un host

Una clase que implementa un servicio de Indigo suele compilarse en una biblioteca. Por definición, todas las bibliotecas necesitan un dominio de aplicación host y un proceso de Windows en el que se ejecuten. Indigo ofrece dos opciones para alojar bibliotecas que implementen servicios. Una opción consiste en utilizar el dominio de aplicación host y el proceso que ofrece el servicio de activación de Windows (WAS, Windows Activation Service), mientras que la otra permite que un servicio se aloje en cualquier dominio de aplicación que se ejecute en cualquier proceso. Esta sección describe ambas, comenzando por WAS.

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

La manera más sencilla de alojar un servicio de Indigo es utilizar WAS. (Tenga en cuenta que WAS no se admitía en la primera Community Technology Preview de Indigo. En su lugar, los servicios de Indigo se podían alojar en Internet Information Server en Windows Server 2003 y Windows XP, aunque sólo se admitía SOAP a través de HTTP en esta configuración.) El uso de WAS es muy similar al mecanismo de alojamiento que IIS ofrece para ASMX. Entre otros puntos en común, ambos se basan en el concepto de directorio virtual, que no es más que un alias más corto de una ruta de directorio real del sistema de archivos de Windows.

Para ver cómo funciona el alojamiento en WAS, supongamos que alguna de las clases Calculator antes mostradas se compila en una biblioteca llamada calc.dll y, a continuación, 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 extensión .svc (que corresponde, por supuesto, a "servicio"). Para nuestro sencillo ejemplo, este archivo podría llamarse calc.svc y sólo contendría lo siguiente:

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

Una vez hecho esto y definido un extremo como se explica en la siguiente sección, una solicitud de un cliente a uno de los métodos del servicio Calculator creará automáticamente una instancia de esta clase para que ejecute la operación especificada. Dicha instancia se ejecutará en un dominio de aplicación creado dentro del proceso estándar 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 opción más sencilla, con frecuencia las aplicaciones necesitan exponer servicios desde su propio proceso en vez de utilizar el que ofrece Windows. Afortunadamente, no es difícil hacerlo. El siguiente ejemplo muestra cómo 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 método Main, se ejecutará como un proceso diferente. Para alojar el servicio de ejemplo Calculator, este método debe crear una nueva instancia de la clase ServiceHost<T>, pasando la clase Calculator. (Observe que esta clase estándar de Indigo es un componente genérico, como indican los < y > que rodean a su parámetro. Los componentes genéricos son una nueva característica del 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 que se crea una instancia de esta clase, para que el servicio esté disponible basta con llamar al método Open de dicha instancia. Indigo dirigirá automáticamente las solicitudes de los clientes a los métodos 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 ejecutándose, lo que no supone un problema con los servicios alojados por WAS, ya que el proceso estándar WAS garantiza esto. No obstante, una aplicación 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.

Definición de extremos

Junto con la definición de las operaciones de una clase de servicio de Indigo y la especificación 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:

  • 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 explícita, como Calculator en el primer ejemplo mostrado anteriormente, sólo puede exponer un contrato de servicio. En este caso, todos sus extremos expondrán el mismo contrato. Si una clase implementa explícitamente dos o más interfaces marcadas con ServiceContract, no obstante, extremos diferentes pueden exponer contratos diferentes.

  • Una dirección que indica dónde 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 cómo se puede tener acceso a ese extremo. El enlace determina la combinación de protocolos que se puede utilizar para tener acceso a ese extremo justo con otros datos, como si la comunicación 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 través de HTTP o SOAP a través de TCP. Al ser cada uno de estos un enlace diferente y, por tanto, el servicio debería exponer dos extremos, uno con un enlace de SOAP a través de HTTP y el otro con un enlace de SOAP a través de -TCP.

Los enlaces son una parte fundamental de cómo se lleva a cabo la comunicación. 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:

  • BasicProfileHttpBinding: cumple el perfil básico 1.0 de la organización Web services Interoperability (WS-I), que especifica SOAP a través de HTTP. Este es el enlace predeterminado del enlace si no se especifica otro explícitamente.

  • BasicProfileHttpsBinding: cumple el perfil 1.0 de seguridad básico de WS-I, que especifica el SOAP a través 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 también admiten estas especificaciones.

  • WsDualHttpBinding: igual que WsHttpBinding, pero también admite la interacción mediante contratos dúplex. Mediante este enlace, tanto servicios como clientes pueden recibir y enviar mensajes.

  • NetTcpBinding: envía SOAP con codificación binaria, incluida la compatibilidad con la transferencia confiable de mensajes, seguridad y transacciones, directamente a través de TCP. Este enlace sólo se puede utilizar 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 sólo se puede utilizar para la comunicación de Indigo a Indigo entre procesos que se encuentren en el mismo equipo de Windows.

  • NetMsmqBinding: envía SOAP con codificación binaria a través de MSMQ, como se describe anteriormente. Este enlace sólo se puede utilizar para la comunicación de Indigo a Indigo.

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 dirección podría 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 programación, el método más habitual probablemente consiste en utilizar un archivo de configuración 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 configuración asociado a la aplicación 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 configuración podría 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 información de configuración de todos los servicios que implementa una aplicación de Indigo. Este elemento contiene un elemento services que puede contener uno o varios elementos service. Este sencillo ejemplo sólo tiene un único servicio, por lo que service sólo aparece una vez. El atributo serviceType del elemento service identifica la clase de servicio que implementa el servicio al que se aplica esta configuración, 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 sólo expone un único extremo y, por tanto, sólo 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 configuración fuese para la segunda clase de servicio Calculator mostrada anteriormente, que definía el contrato de servicio mediante una interfaz explícita, el valor del atributo serviceType seguiría siendo el mismo, pero el valor de contractType pasaría a ser ICalculator, que es el nombre de esta interfaz explícita. El enlace especificado aquí es basicProfileHttpBinding, aunque al ser el predeterminado, se podría haber omitido. Si suponemos además que Calculator es un servicio alojado en WAS, se crearía una dirección automáticamente, por lo que no sería necesario especificar una en este archivo de configuración.

Creación de un cliente de Indigo

Si crear un servicio básico de Indigo no es muy complicado, crear un cliente de Indigo es todavía más 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 continuación, invocar las operaciones del servicio a través 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 continuación, utilizar esta definición 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 sólo está disponible la definición WSDL del servicio, svcutil puede leerla para generar un proxy. Si sólo el propio servicio está disponible, svcutil puede obtener acceso a él directamente mediante WS-MetadataExchange o un sencillo HTTP GET para adquirir la definición de interfaz de WSDL del servicio y, a continuación, generar el proxy.

Independientemente de cómo se genere, el cliente puede crear una nueva instancia del proxy y, a continuación, invocar los métodos del servicio mediante dicha instancia. A continuación, 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 más 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 dirección, lo que se suele hacer en el archivo de configuración. De hecho, si hay suficiente información disponible, svcutil generará automáticamente el archivo de configuración de cliente adecuado para el servicio de destino.

Otros aspectos de Indigo

Los conceptos básicos de los servicios y los clientes son esenciales para todas las aplicaciones de Indigo. Sin embargo, la mayoría de estas aplicaciones utilizarán también otros aspectos de esta tecnología. Esta sección trata algunas de las características adicionales que Indigo ofrece a las aplicaciones creadas con él.

Control del comportamiento local

Muchos aspectos de Indigo, como los contratos, los enlaces, etc. están relacionados con la comunicación entre un servicio y sus clientes. Sin embargo, hay otras partes del comportamiento de un servicio que son básicamente locales. Por ejemplo, cómo se controla la duración de la instancia de un servicio y cómo se administra el acceso simultáneo 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 también están marcadas con el atributo ServiceContract. El otro, OperationBehavior, se puede aplicar a los métodos de una clase de servicio que también 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 simultáneo 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á más de una solicitud de cliente a la vez al servicio, cada uno de ellos ejecutándose en un subproceso diferente. De manera similar, la propiedad InstanceMode de ServiceBehavior se puede utilizar 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 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 definición de la clase tendría 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 suplantación del método que implementa esta operación, sus requisitos transaccionales (descritos más adelante) y otros detalles.

Opciones de mensajería

Los sencillos ejemplos que se muestran en este artículo suponen que se utiliza un método de llamada a procedimiento remoto (RPC) sincrónico para la interacción entre cliente y servicio. Indigo admite esta opción, pero no es la única posibilidad. SOAP es un protocolo orientado a mensajes, lo que implica que puede admitir varios modelos de programación. De hecho, Indigo admite varias posibilidades, entre ellas:

  • RPC tradicional, que bloquea las llamadas que incluyen listas de parámetros con tipo;

  • RPC asincrónica, que no bloquea las llamadas que incluyen listas de parámetros con tipo;

  • Mensajería tradicional, que no bloquea las llamadas que incluyen un único parámetro de mensaje;

  • RPC basada en mensajes, que bloquea las llamadas que incluyen un único parámetro de mensaje.

Además, aunque es necesario para la mayoría de las aplicaciones distribuidas, la especificación SOAP no trata en ningún 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, también 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 garantías 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 especificación WS-ReliableMessaging. Si se elige un enlace como WsHttpBinding, que utiliza WS-ReliableMessaging, un servicio y su cliente pueden garantizar una comunicación confiable de un extremo a otro aunque sea a través de varios intermediarios SOAP.

Seguridad

La exposición de servicios en una red, aunque sea una red interna, normalmente requiere ciertas medidas de seguridad. ¿Cómo puede el servicio comprobar la identidad del cliente? ¿Cómo se pueden proteger los mensajes enviados al servicio o desde él de alteraciones malintencionadas y ojos indiscretos? ¿Y cómo se puede limitar el acceso a un servicio para que únicamente los usuarios autorizados puedan utilizarlo? Sin alguna solución a estos problemas, resulta demasiado peligroso exponer numerosos tipos de servicios. Sin embargo, la creación de aplicaciones seguras puede resultar complicada. Lo ideal sería que hubiese maneras directas de tratar escenarios habituales de seguridad, junto con un control más preciso para las aplicaciones que lo requieran.

Para lograrlo, Indigo ofrece funciones de seguridad básicas de autenticación, integridad de los mensajes, confidencialidad de los mensajes y autorización. El método de Indigo para tratar los primeros tres aspectos se basa principalmente en los enlaces y entre las opciones del desarrollador se encuentran las siguientes:

  • Seleccionar un enlace estándar que admita seguridad. Las aplicaciones que necesiten sólo seguridad basada en el transporte, por ejemplo, pueden utilizar un enlace como BasicProfileHttpsBinding. Este método es suficiente para solicitudes que vayan 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 mensajes que atraviesan varios intermediarios SOAP pueden utilizar en su lugar un enlace que admita seguridad WS-Security, como WsHttpBinding.

  • Seleccionar un enlace estándar que admita seguridad y, a continuación, personalizarlo cambiando uno o varios de los valores predeterminados. Por ejemplo, el mecanismo de autenticación que utiliza un enlace como WsHttpBinding se puede cambiar si se desea.

  • Crear un enlace personalizado que ofrezca exactamente las características que un desarrollador necesita. Aunque este proceso no es apto para cardiacos, puede ser la solución adecuada para ciertos escenarios avanzados.

  • Seleccionar un enlace estándar que no admita seguridad, como BasicProfileHttpBinding. Aunque no aplicar ninguna seguridad es una práctica bastante peligrosa en general, es posible que sea la mejor opción en ciertas situaciones.

Un servicio de Indigo también puede controlar los clientes autorizados a utilizar sus servicios. En general, Indigo admite únicamente los mecanismos de autorización que incluye .NET Framework. Un servicio puede utilizar el atributo estándar PrincipalPermission, por ejemplo, para definir quién 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 método directo para los casos más habituales y un control preciso para situaciones más complejas, Indigo intenta lograr este objetivo de una manera viable y eficaz.

Transacciones

El tratamiento de las transacciones es un aspecto importante para crear muchos tipos de lógica empresarial. No obstante, el uso de transacciones en un mundo orientado a los servicios puede ser problemático. Las transacciones distribuidas suponen un alto nivel de confianza entre los participantes, por lo que no suele ser adecuado que una transacción abarque el límite de un servicio. No obstante, sigue habiendo situaciones en las que la combinación de transacciones y servicios tiene sentido, por lo que Indigo admite este importante aspecto del diseño de aplicaciones.

Transacciones en .NET Framework 2.0

La compatibilidad con transacciones de Indigo se basa en las mejoras que ofrece la versión 2.0 de .NET Framework. Esa próxima versión incluye System.Transactions, un nuevo espacio de nombres que se centra únicamente en el control de los comportamientos de las transacciones. Los desarrolladores utilizarán sobre todo los servicios de System.Transactions junto con un contexto de ejecución, una nueva construcción de 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 de un ámbito determinado. A continuación, vemos un ejemplo de cómo una aplicación puede utilizar este método para agrupar un conjunto de operaciones en una única transacción:

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

Todas las operaciones del bloque using formarán parte de una única transacción, ya que comparte el mismo contexto de ejecución transaccional que define. La última línea de este ejemplo, que llama al método Complete de TransactionScope, generará una solicitud de confirmación de la transacción cuando se salga del bloque. Este método también ofrece un tratamiento incorporado de los errores, que cancela la transacción si se genera una excepción.

Especificar Required para el nuevo TransactionScope, como ocurre en este ejemplo, implica que este código siempre se ejecutará como parte de una transacción: se unirá a la transacción del autor de la llamada, si existe uno, o se creará uno nuevo si no lo hay. Al igual que ocurre en Enterprise Services, es posible incluir otras opciones, incluidas RequiresNew, Supported y NotSupported.

A diferencia de Enterprise Services y sus predecesores MTS y COM+, Systems.Transactions se centra completamente en el control del comportamiento transaccional. No es necesaria una conexión entre una transacción y el estado interno de un objeto, por ejemplo. Mientras que Enterprise Services requiere que se desactive un objeto al finalizar una transacción, Systems.Transactions no lo exige. Como Indigo se basa en Systems.Transaction, las aplicaciones de Indigo también son libres de administrar las transacciones y el estado de los objetos de manera independiente.

Transacciones en Indigo

Las aplicaciones de Indigo pueden utilizar System.Transactions explícitamente o pueden controlar las transacciones mediante atributos que se basan en System.Transactions en segundo plano. Una opción es que un método de la clase marcado con el atributo ServiceContract envuelva su trabajo en una transacción utilizando TransactionScope, de la manera descrita. Por ejemplo, el método podría incluir una instrucción using que establezca un ámbito para la transacción y, a continuación, actualice dos bases de datos independientes dentro de dicha transacción.

Los métodos de un servicio también pueden controlar el comportamiento transaccional mediante un atributo. En vez de utilizar explícitamente System.Transactions, un servicio puede utilizar el atributo OperationBehavior descrito anteriormente. Veamos 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 utiliza una transacción, por lo que el funcionamiento será idéntico al anterior. Sin embargo, el segundo método, Update, aparece precedido por el atributo OperationBehavior con la propiedad RequireTransaction establecida en true. Por este motivo, todo el trabajo realizado por este método ocurrirá dentro de una transacción, exactamente como si estuviera dentro del ámbito de transacción del bloque using mostrado anteriormente. Como también se especifica la propiedad AutoCompleteTransaction, la transacción votará automáticamente para confirmarse si no se genera ninguna excepción.

Si el cliente que llama a este método no se está ejecutando dentro de una transacción, el método Update ejecutará su propia transacción, sin que haya elección. Pero imaginemos que el cliente ya forma parte de una transacción existente cuando llama a Update. Podemos preguntarnos si el trabajo realizado por el método Update se unirá a la transacción del cliente o se ejecutará 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 propiedad TransactionFlowAllowed del atributo OperationContract. Si TransactionFlowAllowed no se adjunta a un método del servicio, como ocurría en el ejemplo anterior, el trabajo realizado dentro de este método no podrá unirse nunca a una transacción existente. Si este atributo está presente, no obstante, un método podrá unirse a la transacción de su cliente.

También merece la pena señalar que las aplicaciones creadas en Indigo pueden participar en transacciones que incluyen aplicaciones ejecutadas en plataformas que no sean Indigo. Por ejemplo, una aplicación de Indigo podría iniciar una transacción, actualizar un registro en la base de datos local de SQL Server y, a continuación, invocar a un servicio Web implementado en un servidor de aplicaciones J2EE que actualice un registro en otra base de datos. Si este servicio es transaccional y la plataforma en la que se ejecutan es compatible con la especificación WS-AtomicTransaction, ambas actualizaciones de la base de datos pueden formar parte de la misma transacción. Al igual que ocurre con la seguridad y la mensajería confiable, las transacciones de Indigo trabajan en el mundo heterogéneo que los servicios Web hacen posible.

Colas

Mediante enlaces como WsHttpBinding, una aplicación de Indigo se puede comunicar de manera confiable con otra aplicación creada en Indigo o cualquier otra plataforma de servicios Web que implemente WS-ReliableMessaging. Sin embargo, aunque la tecnología que esta especificación define garantiza la entrega confiable de un mensaje SOAP de un extremo a otro, no trata las colas de mensajes. Mediante colas, una aplicación puede enviar mensajes a una cola en vez de directamente a otra aplicación. Cuando la aplicación receptora está preparada, puede leer el mensaje de la cola y procesarlo. Resulta útil permitir este tipo de interacción, por ejemplo, cuando el remitente de un mensaje y su receptor no se estén ejecutando al mismo tiempo.

Por lo tanto, Indigo ofrece compatibilidad con colas de mensajes. Esta compatibilidad se crea sobre MSMQ, lo que significa que a diferencia de la mayoría de los aspectos de Indigo, como la mensajería confiable, la seguridad y las transacciones, las colas de Indigo no interoperan directamente a través de los límites de los proveedores (aunque hay disponible un puente MSMQ-MQSeries).

Para utilizar las colas de Indigo, un desarrollador crea una clase de servicio estándar de Indigo, marcada como siempre con ServiceContract. No obstante, las operaciones del contrato de servicio de esta clase tienen ciertas limitaciones. Concretamente, todas ellas deben marcarse como unidireccionales, lo que implica que no se devolverá ninguna respuesta. Este detalle no resulta sorprendente, ya que al invocar una operación en cola se envía un mensaje a la cola en vez de a su receptor final y, por tanto, no tiene demasiado sentido esperar una respuesta inmediata. Y al igual que cualquier otra clase de servicio, las aplicaciones de Indigo en cola exponen extremos. Estos extremos utilizan enlaces como NetMsmqBinding, que permite la comunicación con otras aplicaciones de Indigo en cola, o MsmqIntegrationBinding, que permite que una aplicación de Indigo en cola pueda interoperar con una aplicación MSMQ estándar que no utilice Indigo. Las colas de Indigo también admiten otras características habituales de entornos en cola, como las colas de mensajes con problemas de entrega y el tratamiento de mensajes envenenados.

Las colas son muy adecuadas para un importante grupo de aplicaciones distribuidas. La compatibilidad de Indigo con este estilo de comunicación permite a los desarrolladores crear aplicaciones en cola sin tener que aprender de manera independiente la tecnología de colas.

Coexistencia y migración

Indigo constituye un método moderno de crear aplicaciones distribuidas en la era de los servicios confiables, seguros y transaccionales. Un punto clave que hay que señalar, no obstante, es que la instalación de Indigo no impedirá el funcionamiento de las aplicaciones existentes. El código actual que se ejecuta en ASMX, .NET Remoting y las demás tecnologías cuya funcionalidad subsume Indigo continuarán funcionando, por lo que no será necesario cambiar a Indigo. Pero aquellas organizaciones que hayan invertido en las tecnologías actuales de Microsoft, queda una pregunta evidente: ¿qué ocurrirá con el código existente escrito utilizando las tecnologías que han precedido a Indigo?

Para todas las tecnologías actuales cuyo futuro se verá gravemente afectado por la llegada de Indigo, los desarrolladores necesitan saber dos cosas: si las aplicaciones creadas en esta tecnología interoperarán con aplicaciones creadas en Indigo y cuánto trabajo implicará convertir las aplicaciones de esta tecnología al entorno de Indigo. A continuación, veremos brevemente cómo cada tecnología trata estos problemas:

  • Servicios Web ASP.NET (ASMX): los servicios Web creados con ASMX interoperarán con las aplicaciones de Indigo. Como tanto los servicios Web ASP.NET como Indigo admiten SOAP estándar, no resulta sorprendente. El cambio del código de los servicios Web ASP.NET a Indigo requerirá cierto trabajo mecánico, pero debe ser bastante directo. La estructura básica de las dos tecnologías es muy similar, por lo que en general bastará con cambiar únicamente los atributos y los archivos de configuración. Otras características más avanzadas, no obstante, como las extensiones SOAP, no se podrán pasar directamente a Indigo. En su lugar, será necesario reescribirlas utilizando las opciones de extensibilidad que ofrece Indigo.

  • .NET Remoting: las aplicaciones creadas en .NET Remoting no interoperarán con las aplicaciones creadas en Indigo, ya que sus protocolos de conexión no son compatibles. El paso del código de .NET Remoting existente a Indigo requerirá cierto esfuerzo, pero será posible. Aquellos que hayan creado extensiones de .NET Remoting personalizadas, no obstante, como canales y receptores, descubrirán que este código no se puede convertir al nuevo mundo. Aunque hay extensiones similares en Indigo, las interfaces que emplean no coinciden con las de .NET Remoting.

  • Enterprise Services: para permitir que una aplicación existente de Enterprise Services pueda interoperar con los clientes de Indigo (u otro software basado en servicios Web), un desarrollador puede identificar exactamente las interfaces que se deben exponer en dicha aplicación. Utilizando una herramienta incluida con Indigo, es posible crear automáticamente contratos de servicio para dichas interfaces y exponerlos mediante Indigo. Para los clientes existentes de las aplicaciones de Enterprise Services que no se hayan creado en .NET Framework (y para otros clientes basados completamente en COM), se proporciona un moniker de Indigo para permitir el acceso directo a los servicios Web. El esfuerzo necesario para convertir las aplicaciones existentes de Enterprise Services y que se ejecuten directamente en Indigo será similar al necesario para pasar aplicaciones ASMX. Gran parte del trabajo, aunque no todo, serán cambios mecánicos directos a los atributos y espacios de nombres.

  • Web services Enhancements (WSE): WSE es la solución táctica de Microsoft para la implementación de aplicaciones de servicios Web que requieran todas o parte de las funciones que ofrecen las especificaciones WS-*. Las aplicaciones creadas con WSE 1.0 y WSE 2.0 no interoperarán con las aplicaciones creadas en Indigo. Las aplicaciones creadas en WSE 3.0, que se lanzará antes de la aparición de Indigo, podrán interoperar no obstante con las aplicaciones de Indigo. Respecto a la posibilidad de conversión, se trata de un caso similar a las tecnologías ya descritas: será necesario cierto esfuerzo para convertir el código existente de WSE a Indigo, aunque este esfuerzo se reducirá al mínimo para aplicaciones que utilicen la versión final de WSE.

  • MSMQ: como las funciones de colas de Indigo se basan en MSMQ, las aplicaciones de colas creadas en Indigo pueden interoperar con las aplicaciones de colas creadas directamente en MSMQ. La conversión de aplicaciones del espacio de nombres System.Messaging incluidas con el .NET Framework original requerirá cierto trabajo, ya que esta interfaz anterior es diferente de lo que proporciona Indigo. Una vez que se lance Indigo, los desarrolladores deberán utilizarla en vez de System.Messaging para crear la mayoría de las aplicaciones de colas basadas en MSMQ.

Antes de que Indigo esté disponible, la tecnología más adecuada para aplicaciones .NET distribuidas que no necesiten colas es probablemente ASMX. Además de su facilidad de uso, también ofrece la ruta de migración más fácil a Indigo. Enterprise Services también es una buena opción para las aplicaciones que aprovechen las posibilidades que ofrece, como transacciones distribuidas, mientras que MSMQ sigue siendo la elección acertada para aplicaciones con colas. .NET Remoting, no obstante, debe utilizarse principalmente para la comunicación entre dos dominios de aplicación del mismo proceso. ASMX es la mejor opción para la comunicación directa entre aplicaciones en la mayoría de los demás casos.

La presentación de un nuevo software siempre afecta a lo que ya existe. Al ofrecer unos cimientos comunes para la creación de aplicaciones orientadas a servicios, Indigo ofrece una plataforma más sencilla y coherente a los desarrolladores. Aunque este cambio provocará algunos quebraderos de cabeza, el objetivo de los creadores de Indigo es conseguir que esta transición sea lo más suave y sencilla posible.

Conclusiones

Indigo representa una importante evolución respecto al modo de crear software por parte de los desarrolladores. A medida que las aplicaciones orientadas a servicios sean más y más habituales, Indigo se convertirá en una tecnología de uso general para los desarrolladores de software de Windows. Otros productos de Microsoft también deberán cambiar para poder aprovechar las ventajas de Indigo. BizTalk Server, por ejemplo, incluirá compatibilidad con Indigo como opción de comunicación poco después del lanzamiento de BizTalk Server 2006. Indigo será la base de gran parte de la comunicación de Windows ya que proporciona los cimientos estándar para el software orientado a servicios.

El impacto que tendrá esta tecnología no será pequeño. Todos los que creen aplicaciones distribuidas en Windows, especialmente aplicaciones que deban interoperar con las de otras plataformas, deberán estar muy atentos. Indigo cambiará considerablemente su mundo.

Acerca del autor David Chappell es director de Chappell & Associates http://www.davidchappell.com/, (en inglés) en San Francisco, California. Este artículo se ha extraído de su próximo libro sobre Indigo, que publicará Addison-Wesley.

Mostrar:
© 2015 Microsoft