Entrevista a Clemens Vasters

Clemens Vasters  es cofundador de Newtelligence, una compañía especializada en Servicios Web y tecnologías .NET. Clemens ha estado asesorando a grandes empresas por más de una década como arquitecto de software y también imparte seminarios y cursos especializados sobre .NET. Es uno de los speakers más considerados en la actualidad por su clarísima visión del futuro de las tecnologías y excelente capacidad como comunicador. Sus conferencias en el Tech-Ed de Barcelona 2003 fueron de las mejor calificadas, y ha participado en eventos Microsoft por todo el mundo (Developer's Days, Tech-Ed's europeos y norteamericanos, etc).

M. Posadas: Tu eres un colaborador habitual de los eventos de Microsoft, y parte de tu labor es también divulgativa. ¿Sueles hablar también en entornos universitarios en Alemania?

C. Vasters: Todavía no hemos comenzado las conferencias en Alemania, pero sí que lo hemos hecho en otros países, y vamos a seguirlo haciendo con más intensidad. Creo que esa es una de las áreas en las que claramente Microsoft tiene la intención de profundizar ya que por sus características, carácter abierto, estandarización, etc., .NET se presta perfectamente para ello. Yo ha he conocido a muchos profesores de Universidad que me han manifestado su interés por esa tecnología. De hecho C# como lenguaje ha sido estupendamente acogido por su elegancia, y otros conceptos como los metadatos, atributos, etc. Incluso en las escuelas profesionales y otros estamentos donde, hasta ahora, el lenguaje de desarrollo era Java, la gente se está dando cuenta de que existe otra alternativa, incluso más moderna y flexible para hacer las cosas.

M. Posadas: Antes de nada, y dado que se te considera uno de los mayores expertos en Servicios Web , me gustaría saber algo más acerca de un comentario que hiciste en tu bitácora (blog), acerca de las carencias de la actual especificación WSDL...

C. Vasters: Creo que WSDL es innecesariamente complejo para lo que tiene que realizar. Voy a comenzar con las cosas básicas que creo que se necesitan: necesitamos Schema, ya que lo que pretende es precisamente pasar metadatos de tipos a un formato XML a través de la red. O sea pasar un XML desde un punto de red a otro y obtener una respuesta. El elemento portType de WSDL que básicamente define dos pares de mensajes, es la base, pero existen otras cosas como Bindings y específicamente la sección Survey, que no creo que sean estrictamente necesarias. Esta última, te ofrece una dirección hacia un punto final (end point), así que si por ejemplo lo desplazas de ese punto final, ya es inválido. Muchas de esas cosas, están siendo mejor tratadas en las nuevas Extensiones de los Servicios Web, como WS-Policy. WSDL define más cosas de las necesarias, y por lo tanto no permite que sean todo lo flexibles que pudieran ser.

M. Posadas: ¿Hay alguien trabajando en alguna especificación que vaya a reemplazar a WSDL en este momento?

C. Vasters: No puedo comentar eso.

M. Posadas: Hace poco tuve ocasión de comentar con Felipe Cabrera, del equipo de desarrollo de Web Services Extensions sobre el plan de desarrollo de hasta 19 nuevas extensiones. ¿Piensas que quizá la primera versión de Servicios Web era demasiado simple?

C. Vasters: Daban lo básico realmente. Digamos que tenían la interoperabilidad básica que no teníamos antes, eran una cosa nueva, permitiendo a diferentes sistemas hablar entre sí de forma sencilla. EL hecho de que dos plataformas diferentes se intercambien datos es algo muy bueno,. por que es la base de la Integración de Sistemas, Redes y Aplicaciones. Si te fijas en los sistemas, casi todos tienen implementados mecanismos de "Colas de Mensajes", Seguridad, etc. y ahora vamos a ver todas esas cosas en un modo externo, y no propio de la implementación del sistema.

M. Posadas: Esto que comentas, tiene que ver de alguna forma con las nuevas arquitecturas SOA (Services Oriented Architectures), que Microsoft nos presentó a algunos partners en Londres hace un par de meses y que según ellos es el "Roadmap", el camino a seguir, dentro de las arquitecturas de software y -desde luego- el que ellos van a seguir...

C. Vasters: Lo primero que sí quiero comentar respecto a eso es que SOA no es nada realmente nuevo. Hay muy buenos patrones de construcción que han venido funcionando adecuadamente ya unos años. Pero en la forma en que se ve ahora, podríamos decir que son sistemas "metadata-driven", que utilizan arquitecturas Web en la comunicación. Permite formalizar todo lo que existe mediante contratos, y estructurar de forma explícita la forma en que vamos a manejar esos contratos. Pero, en sí, no es que sea nuevo. Es una aproximación más estricta, más fiable y a la vez más flexible de cara a la Integración de Sistemas. Sobre si eventualmente todo se va a convertir en Servicios Web...potencialmente podría ser.

La cuestión, de todas formas, va más allá que la simple comunicación, por que va a ser posible que dos sistemas distintos comunicándose puedan seguirlo haciendo en el futuro, incluso si uno de ellos ha cambiado su hardware o su software, con tal de que los contratos pactados entre ambos sigan siendo vigentes, y de que el nuevo software respete esos contratos. La diferencia respecto a los protocolos binarios se minimizará con el tiempo a medida que se implementa la compresión hardware. Incluso ahora, las penalizaciones de rendimientos en estos casos no lo son tanto cuando se planean las cosas adecuadamente, y sabemos que la potencia del hardware seguirá creciendo.

M. Posadas: Una de las preguntas que muchos alumnos me hacen al hablar de Servicios Web, es ¿Quién garantía la presencia del Servicio? Ya que debido a su naturaleza no tenemos garantía de respuesta, como cuando controlamos un dominio local...

C. Vasters: Es lo mismo con los sitios Web. Puedes verlos como servicios de cualquier otro tipo. Si tu haces una aplicación que utiliza un servicio es tu responsabilidad cubrir las posibles deficiencias de ese servicio, con algún mecanismo alternativo. Al final tendrás que garantizar la presencia a través de algún sistema de pagos, de forma que puedas responsabilizar al proveedor por su ausencia. Imagina la situación de que tu hicieras un software que se apoyara en un servicio Web y tu lo distribuyeses, pongamos por caso a "El Corte Inglés", y de repente, dejase de funcionar el Servicio. No tendría solución, por que no hay nada que pueda hacer el comprador del software para arreglarlo.

M. Posadas: ¿Para cuando va a estar disponible el paquete de Web Services Extensions para la nueva versión del Framework? Por que sólo funcionaban con la antigua (la 1.0)

C. Vasters: Puedes usarlo con la última "release" o Service Pack, y además en las próximas dos semanas van a estar disponibles los WSE 2.0. Incluirá soporte de WS-Policy, y una especie de "marco de transporte" (transport framework). El papel de WSE a partir de esta versión es hacerlo incluso más independiente del transporte, incluso se habla de la existencia de un "proveedor de transporte" (transport provider"), de forma que puedas configurar el canal TCP, y muchas novedades más. Va a ser una de las grandes novedades del próximo evento PDC

.

Con Clemens Vasters, en el área de prensa, al final de la entrevista

M. Posadas: Vamos ahora con el otro tema que parece que ha sido de tu interés en los últimos meses: la Programación Orientada a Aspectos. Me gustaría comenzar por una definición clara de la AOP.

C. Vasters: AOP trata acerca de la separación entre propósitos primarios y secundarios en la creación del software. Cuando escribes una aplicación de negocio, existen muchos aspectos, como la monitorización, la seguridad, las validación primaria, etc., que, siendo temas importantes, no son la razón primaria por la que se escribe esa aplicación. Y por lo tanto podríamos considerarlas como secundarias. Si miras el cíodigo que estas escribiendo, descubres que una pbuena parte de este trabajo secundario, se convierte en un trabajo primario, por que tienes que gastar mucho tiempo programándolas y haciendo que funcionen adecuadamente.

De forma que AOP lo que intenta es sacar factor común de todas esas cosas comunes, de toda esa infraestructura, y situarla en unos sitios llamados "interception points". Por ejemplo, tienes mensajes, que navegan por "pipelines", básicamente, y esos puntos, controlan el mensaje, actúan sobre el. Por ejemplo imagínate una llamada a una función que tiene varios parámetros y quieres asegurarte de que esos parámetros están dentro de cierto rango. Tenemos un componente accesible a través de un "pipeline" y metadatos que definen la función, de forma que cuando se produce la llamada, si se detecta que los valores no son válidos de acuerdo con esos metadatos, ni siquiera se el pasan los valores. Se intercepta la llamada y se rechaza. Lo mismo puede decirse de la seguridad. Podemos controlar si a través del sistema de autenticación, la persona que hace la llamada es realmente la que dice ser. De forma que todos estos "aspectos secundarios" de la aplicación pueden gestionarse mediante AOP.

Existen múltiples formas de hacer que la AOP funcione. Una es utilizar compiladores especiales, como el de AspectJ, o AspectC#, que funcionan permitiendo que el programador escriba clases diferentes para el código primario y secundario. Esto sería aplicable a muy diferentes contextos de programación como son los de ASP.NET, extensiones SOAP, extensiones de Servicios Web, o la configuración de seguridad de servidores.

Pero, la más conocida definición de AOP es la de AspectJ, y pienso que la aproximación que ellos han hecho no es correcta. Me explico: en .NET puedes escribir atributos a los métodos o a las propias clases, los metadatos van a estar ahí, disponibles. En AspectJ, tienes una clase por un lado y una clase de definiciones por otro.

M. Posadas: ¿Una especie de meta-clase?

C. Vasters: Exacto, incluso no recuerdo si la llaman así. De forma que añades el comportamiento de forma separada, influencias el comportamiento de algo que desconoce que va a ser modificado, lo que tiene el peligro de que si cambian las pre-condiciones, o las condiciones normales en una de las dos, la otra no sabe, de dichos cambios, por eso digo que es una enfoque muy peligroso. Yo mismo he hecho alguna labor de investigación para ver como funcionaban todas estas cosas, y el problema que le encuentro es que algunas veces, bajo algunas circunstancias, el tema simplemente no funciona. Hay una serie de clases de uso para las que la AOP sí que funciona y otro conjunto de situaciones para las que no. Así que no creo que vaya a ser un paradigma de programación de extensión universal. Si que es una idea preciosa, pero todavía tiene problemas.

Hay otras situaciones que pueden ilustrar esto que comento. Imaginemos una aplicación de negocio que pretende hacer un seguimiento estadístico de cierta información comercial: en el mismo pipeline donde intervienen los aspectos, y tienes un mecanismo de login. Supongamos que existe una transacción con todo lo que eso supone (capacidad de hacer commit, rollback, etc.)  Bien, ¿donde tiene que situarse el mecanismo de login? ¿antes o después de la transacción? ¿quieres situarte dentro o fuera? No existe una buena práctica que lo establezca, sino que depende de la lógica de negocio. Y desde ese momento necesitas tener unos mecanismos exquisitamente bien definidos para que el asunto funcione. No se trata de requerimientos técnicos sino de mecanismos que se interfieren mutuamente. Una vez que tienes esa serie de interdependencias, tu situación es bastante inestable si no haces que esas interdependencias aparezcan como metadatos. Y eso es lo que le falta al enfoque AspectJ. No creo en el buen funcionamiento de las clases que se influencian independientemente.

Así que para resumir, finalmente, diría que: en primer lugar, la presencia de metadatos en todo esto es fundamental. En segundo lugar, no se debieran crear aspectos que monitoricen mensajes y los transformen, por que de esa manera cambias las precondiciones. Lo que mejor funciona en AOP son los cortafuegos. La seguridad funciona bastante bien, las validaciones también. Pero todo aquello que modifique el entorno es problemático.

M. Posadas: ¿Quizá la AOP necesita maduración?

C. Vasters: Pues la verdad es que no veo mucho más potencial para maduración, tampoco. AOP como paradigma de programación para mi está muerto. Las posibilidades que tiene se reducen a unos cuantos casos de uso, en los cuales, además los metadatos son una parte crítica si queremos que el sistema funcione adecuadamente, por que es importante tener el control total de la situación. Tendríamos que tener algo similar a COM pero para aspectos. El problema es que tendríamos que disponer del código fuente de todos los aspectos con los que trabajas.

M. Posadas: Si el futuro no va por los caminos de la AOP, ¿cual es tu visión del próximo software?

C. Vasters: No creo cualquiera sea capaz de extender los sistemas independientemente. No creo que haya un mercado para Extensiones SOAP, por ejemplo. Y en general para elementos de software contexto-dependientes. No creo que una compañía pueda vender componentes que se instalen y funcionen adecuadamente en contextos WSE (Web Services Extensions). Nosotros mismos no hacemos eso. Suministramos el fuente para poder personalizarlo. La personalización sí es el futuro de la informática en todos los aspectos. Tendremos la gran mayoría de los conceptos que ya conocemos de antes, pero de tal forma que siempre podremos personalizarlos para adaptarlos a un escenario concreto.

M. Posadas: Bien, y ya para concluir ¿cuáles son tus próximos proyectos o ideas?

C. Vasters: Pues he estado una temporada de conferencias y viajes por todo el mundo, y creo que los próximos meses voy a dedicarlos a desarrollar algunas ideas nuevas. Estoy interesado en un par de cosas acerca de la generación de código, trabajando con ciertas especificaciones y adaptándolas para el software nuestro. También en una herramienta de Blogging, dasBlog, que espero sacar pronto.

M. Posadas: Como despedida, siempre pregunto a mis interlocutores extranjeros su opinión sobre España...¿te gusta venir aquí?

C. Vasters: Muchísimo. He estado anteriormente en Madrid, en el Foro de Arquitectos de Software, y un par de veces en Barcelona. Son ciudades apasionantes, y especialmente me gusta mucho Barcelona, su ambiente, es una de las ciudades que más me gustan de todas las que conozco.

M. Posadas: Pues muchas gracias por tus opiniones y quizá nos veamos en Ámsterdam en año próximo...

C. Vasters: Espero que sí. Gracias a tí.