150 likes | 278 Views
Integración J2EE y .NET mediante Web Services. Agenda. Introducción Ejemplo 1: Un caso sencillo Ejemplo 2: Utilización de tipos de datos a medida (clases propias). Introducción. Introducción. La integración de aplicaciones siempre ha sido una necesidad empresarial.
E N D
Agenda • Introducción • Ejemplo 1: • Un caso sencillo • Ejemplo 2: • Utilización de tipos de datos a medida (clases propias)
Introducción • La integración de aplicaciones siempre ha sido una necesidad empresarial. • La existencia de las redes de comunicaciones y en particular Internet garantizan el camino para realizar la integración de aplicaciones físicamente distribuidas. • La creación de un “estándar” de representación de la información como es XML (lenguajes o protocolos de tipo XML) ha automatizado la tediosa labor de parseo, de tratamiento a bajo nivel de la información. • La creación del estándar “Web Services”, basado en los protocolos SOAP, WSDL y UDDI ha fijado la estructura de los puntos finales de comunicación entre aplicaciones para poder invocar métodos de objetos remotamente. • Incluso aunque las tecnologías de la aplicaciones en cada extremo sean diferentes (J2EE, .NET, LAMP…)
Introducción • Según lo comentado, integrar aplicaciones a través de Internet mediante Web Services debe ser algo trivial. • Más aún pensando que existen herramientas para automatizar: • La generación del fichero WSDL que describe el Web Service • La generación del proxy (a partir del WSDL) en el lado del cliente para acceder al Web Service como si fuese local • Y es cierto pero… • Podría no serlo si: • Los ficheros WSDL no siguiesen un único estándar, es decir, si admitiesen variantes (WSDL sobre JAX-RPC…) • Algunos aspectos complejos de los lenguajes o tecnologías de los extremos a integrar no fuesen fácilmente reflejables en el WSDL • Las herramientas generadoras de proxies y ficheros WSDL incorporasen aspectos no estándar
Introducción • Y efectivamente, sucede, lo que en teoría es un estándar, en la práctica presenta situaciones en que no lo es: • Los ejemplos de interoperabilidad que solemos ver funcionan porque trabajan con entornos controlados y tipos de datos simples. • Pero, en la realidad, en función de las herramientas elegidas, las cosas cambian. • Por ejemplo, nuestro caso: • Parte servidor: • Tecnología: J2EE • Herramienta de desarrollo: Jdeveloper 10.1.2 • Parte cliente: • Tecnología: .NET • Herramienta de desarrollo: Visual Studio .NET 2005 • ¿Cómo resolver una situación de este tipo? • Veámoslo
Ejemplo 1: Un caso sencillo • Tipos de datos básicos
Ejemplo 1: Un caso sencillo • Cliente creado con: • Visual Studio .NET 2005 • Web service creado con • JDeveloper 10.1.2
Ejemplo 2: Tipos de datos a medida • Tipos de datos a medida
Ejemplo 2: Tipos de datos a medida • A) • Cliente creado con: • Visual Studio .NET 2005 • Web service creado con • JDeveloper 10.1.2 • B) • Cliente creado con: • Visual Studio .NET 2005 • Web service creado con • JDeveloper 10.1.3
Ejemplo 2: Tipos de datos a medida • Nota • El tipo de datos ConjuntoOferta contiene arrays de tamaño fijo
Ejemplo 2: Tipos de datos a medida • Cuestión • ¿Es posible utilizar tipos de datos complejos con arrays de tamaño no definido?
Ejemplo 2: Tipos de datos a medida • Cuestión • ¿Es posible utilizar tipos de datos complejos con arrays de tamaño no definido? • La respuesta es SÍ