Comienza la integración a nivel comercial
Java, XML y Web Services
En el centro mismo de toda aplicación Internet útil hay mensajes de textos sencillos, legibles y que pueden estar escritos por personas o por ordenadores, y el lenguaje XML intenta potenciar el poder de expresión de estos textos preservando al mismo tiempo la posibilidad de acceder a ellos.
El lenguaje Java, aunque nació para Internet, ha sido extrañamente lento en adoptar estos modelos o paradigmas. Por ejemplo, expresiones de tipo normal son la herramienta más básica para trabajar con texto formateado, a pesar de lo cual sólo ahora, con la versión 1.4 del kit JDK (Java Development Kit) se convierten esas expresiones corrientes en una característica estándar de la plataforma Java. De forma similar, algunos medios Java como la descripción gramatical o “parsing” con interfaces SAX (Simple API for XML) o DOM (Document Object Model), y la transformación con XLT (Extensible Stylesheet Transformation) –aunque disponibles desde hace tiempo en otras fuentes– están haciendo ahora su debut oficial en J2SE (Java 2 Standard Edition) 1.4.
Aunque el motor Java/XML de Sun puede haber comenzado con lentitud, está adquiriendo realmente velocidad. Un conjunto de interfaces API XML y Web Services desagrupados, que se encuentran en diversas etapas de desarrollo, tienen por objeto complementar el núcleo XML que está incorporado en la plataforma. Estos APIs “JAX Pack” definen un marco o framework Java dentro del cual los desarrolladores de software pueden realizar varias tareas, incluyendo las siguientes:
• Conversión entre documentos XML y objetos Java nativos.
• Utilizar Web Services de estilo RPC (Remote Procedure Call) estrechamente acoplados.
• Utilizar Web Services de estilo documento que se comunican en formas de acoplamiento menos estrecho.
• Localizar Web Services utilizando UDDI (Universal Description, Discovery and Integration) o ebXML.
Hay que admitir que toda esta terminología resulta bastante pesada. Para atravesar toda esta niebla de acrónimos, Sun ofrece un lema: “Codificación portátil, datos portátiles”. Aunque esto ayuda, no puede evitarse el hecho de que la simplicidad de la primera Internet es cosa del pasado. Ahora se espera que la Internet haga lo mismo que hicieron todos los sistemas de empresa propietarios y aún más. El resultado es una multitud de iniciativas que ninguna plataforma única puede esperar establecer en una sola interacción. La estrategia de Sun mientras el Web de nueva generación entra en existencia por sí mismo, es adaptar Java de la forma más flexible que puede a un ecosistema en rápida evolución.
Los motivos de los APIs
Entonces, ¿cuáles son exactamente las funciones y características del nuevo modelo Web Services de Sun? A grandes rasgos hay tres actividades básicas: crear puntos finales de servicio, ensamblar servicios formando procesos comerciales, y desplegar éstos en formas que los administradores puedan controlar y los usuarios puedan comprender. Otro factor importante es el relativo a la elección del contexto en el que se intercambian esos mensajes. De forma tácita o explícita, está definido por las redes, aplicaciones y procesos comerciales existentes. Y estos son diferentes dentro de las compañías, e incluso más entre unas y otras.
Crear contexto para Web Services es la misión declarada para ebXML, uno de los perfiles de mensajería soportados por JAXM (Java API for XML Messaging). (Otro perfil JAXM es WS-Routing, antes SOAP-RP). Sin embargo, los protocolos de colaboración comercial como ebXML no resolverán pronto, o quizás nunca, los tipos de problemas semánticos que son una plaga para los integradores de sistemas que se enfrentan de forma regular a la necesidad de hacer coincidir la definición de cliente, proveedor u orden de compra de una compañía con la de otra compañía.
Hay que tener en cuenta que aunque el eslogan de “datos portátiles” de Sun implica interoperabilidad de Java-a-no-Java, ese no es el único motivo para utilizar XML con Java. Por encima de las plataformas y de los lenguajes está la semántica de las aplicaciones. Incluso en un entorno todo-Java, XML crea un terreno común sobre el que es posible enfrentarse a esas cuestiones semánticas. Si no fuera así, JAXB (Java Architecture for XML Binding), que realiza la conversión entre clases Java y documentos CML, podría parecer útil únicamente para comunicar con el mundo no-Java. Después de todo, Java siempre ha soportado nativamente la serialización de objetos a y desde un formato binario. Pero Java no soporta nativamente la transformación de objetos, y es perfectamente complementado por XML a este respecto.
Estilos de Web Services
Los Web Services de primera generación resumen un tema que todos hemos visto ya: emitir una llamada de función remota y recibir un package de datos en respuesta. Como les gusta decir a los veteranos del sector: “basta con introducir el protocolo RPC favorito”. Tanto si se utiliza RMI (Remote Method Invocation) de Java, o XML-RPC o SOAP, se trata de la misma cosa. Sin embargo, cuando las llamadas y respuestas se escriben en XML, quedan abiertas a una fácil inspección y manipulación. Naturalmente, XML también apoya la neutralidad de lenguaje y de plataforma que es la característica de Web Services. El objetivo del “stack” de Web Services SOAP, WSDL (Web Services Description Language) y UDDI, es convertir en realidad el sueño de la interoperabilidad entre múltiples lenguajes y múltiples plataformas.
Ese sueño no se ha hecho realidad aún, a pesar del importante progreso alcanzado. Uno de los motivos es la transición de XML de la definición DTD (Document Type Definition) como una forma de definir tipos de datos, al XML Schema, mucho más rico y variado. WSDL utiliza XML Schema para articular los tipos de objetos intercambiados entre Web Services. Desde el pasado año, la versión 1.2 de JAXP (Java API for XML Processing) de Sun incluye el “parser” Xerces 2 del Apache XML Project, que soporta a XML Schema. Resulta algo confuso el hecho de que J2SE 1.4 incluya el antiguo parser Crimson, que no soporta a XML Schema. (De forma similar, JAXB soporta actualmente sólo a DTD, no a Schema.) Otra posible anomalía es que el interface API Java para WSDL está aún en la fase de solicitud del Java Community Process, y no está incluido aún en el JAX Pack. En el lado favorable, resulta alentador ver cómo Sun trabaja más estrechamente con la comunidad open-source, que ha generado tanta innovación Java/XML.
Mientras los Web Services de estilo RPC se establecen finalmente en una definición tipo Schema, está apareciendo un nuevo estilo basado en documento. En este último caso, el cuerpo del mensaje SOAP no sigue el modelo de la semántica de llamada/respuesta de los lenguajes de programación convencionales, sino que incluye documentos XML tradicionales, que pueden ser escritos también en XML y validados utilizando XML Schema. El máximo defensor de este enfoque ha sido Microsoft, cuyo toolkit .Net prefiere la variante orientada a documentos de SOAP. El JAX Pack de Sun incluye APIs dirigidos a ambos enfoques: JAX-RPC (Java API for XML-based RPC) para servicios Web de estilo RPC, y JAXM para servicios de estilo documento.
Los desarrolladores de software que se enfrentan a estas opciones tienen que analizar afanosamente diversos “metrics” o valores de medición q
El lenguaje Java, aunque nació para Internet, ha sido extrañamente lento en adoptar estos modelos o paradigmas. Por ejemplo, expresiones de tipo normal son la herramienta más básica para trabajar con texto formateado, a pesar de lo cual sólo ahora, con la versión 1.4 del kit JDK (Java Development Kit) se convierten esas expresiones corrientes en una característica estándar de la plataforma Java. De forma similar, algunos medios Java como la descripción gramatical o “parsing” con interfaces SAX (Simple API for XML) o DOM (Document Object Model), y la transformación con XLT (Extensible Stylesheet Transformation) –aunque disponibles desde hace tiempo en otras fuentes– están haciendo ahora su debut oficial en J2SE (Java 2 Standard Edition) 1.4.
Aunque el motor Java/XML de Sun puede haber comenzado con lentitud, está adquiriendo realmente velocidad. Un conjunto de interfaces API XML y Web Services desagrupados, que se encuentran en diversas etapas de desarrollo, tienen por objeto complementar el núcleo XML que está incorporado en la plataforma. Estos APIs “JAX Pack” definen un marco o framework Java dentro del cual los desarrolladores de software pueden realizar varias tareas, incluyendo las siguientes:
• Conversión entre documentos XML y objetos Java nativos.
• Utilizar Web Services de estilo RPC (Remote Procedure Call) estrechamente acoplados.
• Utilizar Web Services de estilo documento que se comunican en formas de acoplamiento menos estrecho.
• Localizar Web Services utilizando UDDI (Universal Description, Discovery and Integration) o ebXML.
Hay que admitir que toda esta terminología resulta bastante pesada. Para atravesar toda esta niebla de acrónimos, Sun ofrece un lema: “Codificación portátil, datos portátiles”. Aunque esto ayuda, no puede evitarse el hecho de que la simplicidad de la primera Internet es cosa del pasado. Ahora se espera que la Internet haga lo mismo que hicieron todos los sistemas de empresa propietarios y aún más. El resultado es una multitud de iniciativas que ninguna plataforma única puede esperar establecer en una sola interacción. La estrategia de Sun mientras el Web de nueva generación entra en existencia por sí mismo, es adaptar Java de la forma más flexible que puede a un ecosistema en rápida evolución.
Los motivos de los APIs
Entonces, ¿cuáles son exactamente las funciones y características del nuevo modelo Web Services de Sun? A grandes rasgos hay tres actividades básicas: crear puntos finales de servicio, ensamblar servicios formando procesos comerciales, y desplegar éstos en formas que los administradores puedan controlar y los usuarios puedan comprender. Otro factor importante es el relativo a la elección del contexto en el que se intercambian esos mensajes. De forma tácita o explícita, está definido por las redes, aplicaciones y procesos comerciales existentes. Y estos son diferentes dentro de las compañías, e incluso más entre unas y otras.
Crear contexto para Web Services es la misión declarada para ebXML, uno de los perfiles de mensajería soportados por JAXM (Java API for XML Messaging). (Otro perfil JAXM es WS-Routing, antes SOAP-RP). Sin embargo, los protocolos de colaboración comercial como ebXML no resolverán pronto, o quizás nunca, los tipos de problemas semánticos que son una plaga para los integradores de sistemas que se enfrentan de forma regular a la necesidad de hacer coincidir la definición de cliente, proveedor u orden de compra de una compañía con la de otra compañía.
Hay que tener en cuenta que aunque el eslogan de “datos portátiles” de Sun implica interoperabilidad de Java-a-no-Java, ese no es el único motivo para utilizar XML con Java. Por encima de las plataformas y de los lenguajes está la semántica de las aplicaciones. Incluso en un entorno todo-Java, XML crea un terreno común sobre el que es posible enfrentarse a esas cuestiones semánticas. Si no fuera así, JAXB (Java Architecture for XML Binding), que realiza la conversión entre clases Java y documentos CML, podría parecer útil únicamente para comunicar con el mundo no-Java. Después de todo, Java siempre ha soportado nativamente la serialización de objetos a y desde un formato binario. Pero Java no soporta nativamente la transformación de objetos, y es perfectamente complementado por XML a este respecto.
Estilos de Web Services
Los Web Services de primera generación resumen un tema que todos hemos visto ya: emitir una llamada de función remota y recibir un package de datos en respuesta. Como les gusta decir a los veteranos del sector: “basta con introducir el protocolo RPC favorito”. Tanto si se utiliza RMI (Remote Method Invocation) de Java, o XML-RPC o SOAP, se trata de la misma cosa. Sin embargo, cuando las llamadas y respuestas se escriben en XML, quedan abiertas a una fácil inspección y manipulación. Naturalmente, XML también apoya la neutralidad de lenguaje y de plataforma que es la característica de Web Services. El objetivo del “stack” de Web Services SOAP, WSDL (Web Services Description Language) y UDDI, es convertir en realidad el sueño de la interoperabilidad entre múltiples lenguajes y múltiples plataformas.
Ese sueño no se ha hecho realidad aún, a pesar del importante progreso alcanzado. Uno de los motivos es la transición de XML de la definición DTD (Document Type Definition) como una forma de definir tipos de datos, al XML Schema, mucho más rico y variado. WSDL utiliza XML Schema para articular los tipos de objetos intercambiados entre Web Services. Desde el pasado año, la versión 1.2 de JAXP (Java API for XML Processing) de Sun incluye el “parser” Xerces 2 del Apache XML Project, que soporta a XML Schema. Resulta algo confuso el hecho de que J2SE 1.4 incluya el antiguo parser Crimson, que no soporta a XML Schema. (De forma similar, JAXB soporta actualmente sólo a DTD, no a Schema.) Otra posible anomalía es que el interface API Java para WSDL está aún en la fase de solicitud del Java Community Process, y no está incluido aún en el JAX Pack. En el lado favorable, resulta alentador ver cómo Sun trabaja más estrechamente con la comunidad open-source, que ha generado tanta innovación Java/XML.
Mientras los Web Services de estilo RPC se establecen finalmente en una definición tipo Schema, está apareciendo un nuevo estilo basado en documento. En este último caso, el cuerpo del mensaje SOAP no sigue el modelo de la semántica de llamada/respuesta de los lenguajes de programación convencionales, sino que incluye documentos XML tradicionales, que pueden ser escritos también en XML y validados utilizando XML Schema. El máximo defensor de este enfoque ha sido Microsoft, cuyo toolkit .Net prefiere la variante orientada a documentos de SOAP. El JAX Pack de Sun incluye APIs dirigidos a ambos enfoques: JAX-RPC (Java API for XML-based RPC) para servicios Web de estilo RPC, y JAXM para servicios de estilo documento.
Los desarrolladores de software que se enfrentan a estas opciones tienen que analizar afanosamente diversos “metrics” o valores de medición q
