viernes
jun032005
¿WebServices XML o RPC cýntricos?
viernes, junio 3, 2005 at 2:56PM
Más o menos esta es la pregunta que hace TheServerSide.com, la propuesta se basa en un artículo de Steve Loughran y Edmund Smith de los laboratorios de HP de Bristol.
El artículo parte de la premisa de que existen dos tipos de enfoques de los WebServices:
1) Cýntricos en torno a documentos/mensajes XML, comunicaciones fundamentalmente asíncronas.
2) Tipo RPC (Remote Procedure Call) emulando a RMI, CORBA, DCOM pero con SOAP.
Analiza con detalle que el mundo de los WebServices está "escorado" hacia un modelo RPC, en parte debido a que las empresas de software enfocan su apuesta por los WebServices a herramientas tal y como JAX-RPC, en donde se oculta al mýximo todo lo referente al XML: los mensajes SOAP son generados por "serializacrión" de llamadas a métodos Java y el esquema WSDL es generado a partir de la interfaz Java que se pretende exportar. Frente a enfoques más cýntricos a XML como el JAXM/SAAJ.
Parte de la "culpa" la tiene la complejidad del WSDL que invita a seguir soluciones cýntricas en Java y no en XML.
Los autores critican este enfoque, el de emular el modelo RMI en los WebServices, en concreto critican el JAX-RPC, con tres razones fundamentales:
1) Latencia de las comunicaciones: el paradigma RPC (RMI, CORBA, DCOM etc) funciona en ýmbitos de redes locales y sistemas distribuidos muy "cercanos", mensajes pequeños y altamente sýncronos, pues este es el modelo de las llamadas a métodos. En largas distancias las latencias de las comunicaciones invitan a usar mensajes grandes y comunicaciones asíncronas.
2) Interoperabilidad: el modelo RPC tiende a imponer el modelo de objetos y tipos de datos al formato de los mensajes, sobre todo en el caso de JAX-RPC en donde se genera el WSDL a partir de Java, con el fin de ocultar lo más posible el XML. Por otra parte los errores se encapsulan en excepciones Java transmitidas lo cual no es muy "interoperable". En definitiva JAX-RPC invita a hacer WebServices orientados a ser consumidos y producidos ýnicamente por Java.
3) La impedancia XML-objetos Java: Java es más pobre que el WSDL por lo que el intento de expresar un WSDL "cualquiera" en una simple clase Java con correspondencia "directa" está lleno de problemas, para empezar el elegir nombres que no coincidan con palabras clave de Java.
Los autores reconocen que el uso de anotaciones en el futuro JAX-RPC 2.0 y la integracrión con JAXB que permitirý un mapeo mucho más preciso del WSDL aliviarýn bastante los problemas pero no los eliminarýn. Por su parte ellos proponen una ttecnología Java cýntrica en torno a XML: Alpine.
ý XML cýntrico o RPC ?
El artículo parte de la premisa de que existen dos tipos de enfoques de los WebServices:
1) Cýntricos en torno a documentos/mensajes XML, comunicaciones fundamentalmente asíncronas.
2) Tipo RPC (Remote Procedure Call) emulando a RMI, CORBA, DCOM pero con SOAP.
Analiza con detalle que el mundo de los WebServices está "escorado" hacia un modelo RPC, en parte debido a que las empresas de software enfocan su apuesta por los WebServices a herramientas tal y como JAX-RPC, en donde se oculta al mýximo todo lo referente al XML: los mensajes SOAP son generados por "serializacrión" de llamadas a métodos Java y el esquema WSDL es generado a partir de la interfaz Java que se pretende exportar. Frente a enfoques más cýntricos a XML como el JAXM/SAAJ.
Parte de la "culpa" la tiene la complejidad del WSDL que invita a seguir soluciones cýntricas en Java y no en XML.
Los autores critican este enfoque, el de emular el modelo RMI en los WebServices, en concreto critican el JAX-RPC, con tres razones fundamentales:
1) Latencia de las comunicaciones: el paradigma RPC (RMI, CORBA, DCOM etc) funciona en ýmbitos de redes locales y sistemas distribuidos muy "cercanos", mensajes pequeños y altamente sýncronos, pues este es el modelo de las llamadas a métodos. En largas distancias las latencias de las comunicaciones invitan a usar mensajes grandes y comunicaciones asíncronas.
2) Interoperabilidad: el modelo RPC tiende a imponer el modelo de objetos y tipos de datos al formato de los mensajes, sobre todo en el caso de JAX-RPC en donde se genera el WSDL a partir de Java, con el fin de ocultar lo más posible el XML. Por otra parte los errores se encapsulan en excepciones Java transmitidas lo cual no es muy "interoperable". En definitiva JAX-RPC invita a hacer WebServices orientados a ser consumidos y producidos ýnicamente por Java.
3) La impedancia XML-objetos Java: Java es más pobre que el WSDL por lo que el intento de expresar un WSDL "cualquiera" en una simple clase Java con correspondencia "directa" está lleno de problemas, para empezar el elegir nombres que no coincidan con palabras clave de Java.
Los autores reconocen que el uso de anotaciones en el futuro JAX-RPC 2.0 y la integracrión con JAXB que permitirý un mapeo mucho más preciso del WSDL aliviarýn bastante los problemas pero no los eliminarýn. Por su parte ellos proponen una ttecnología Java cýntrica en torno a XML: Alpine.
ý XML cýntrico o RPC ?