CORBA VS WEB SERVICES

INTRODUCCION

Para establecer una comparativa, es preciso tener en cuenta

CORBA se introdujo en 1991 y Servicios Web en el 2000
CORBA es una solucin ms madura y mucho ms completa
Microsoft nunca ha querido apoyar CORBA

ORDEN DE EXPOSICION
1- IIOP/SOAP
2- Implementacin de clientes y servidores
3- Estandarizacin de APIs
4- Soporte para servicios estndar
5- Otros aspectos
6- Conclusiones
 IIOP/SOAP 1

Interoperabilidad
Con SOAP, todava existen algunos problemas de interoperabilidad (inexistentes en IIOP)
Eficiencia
IIOP es un protocolo binario
SOAP representa la informacin en XML
Los mensajes ocupan ms y es preciso parsear XML
Por tanto, IIOP es ms eficiente que SOAP
 IIOP/SOAP 2

USO DE INTERNET
SOAP normalmente usa HTTP
Todos los firewalls reconocen HTTP
Adecuado para integraciones en Internet
En la prctica, es difcil usar IIOP sobre Internet
Existen firewalls que no reconocen IIOP (aunque hay terceros que venden proxies de IIOP)
Existen tneles de IIOP sobre HTTP, pero no son ptimos
Se precisa usar una tecnologa ampliamente aceptada
Microsoft no fabrica implementaciones de CORBA (aunque hay terceros que lo hacen)
El soporte para Servicios Web est presente en cualquier plataforma
 IMPLEMENTACION DE CLIENTES Y
SERVIDORES

Definicin de interfaces
IDL es ms legible que WSDL
Pero la idea es generar WSDL automticamente
Implementacin de clientes
Ambos pueden usar proxies (ms sencillo) o invocar operaciones dinmicamente (ms complejo)
implementacin de servidores
Los objetos CORBA pueden tener estado, mientras que los puertos de los servicios web no lo tienen
El POA de CORBA permite implementar servidores eficientes y escalables
No existe algo equivalente al POA para Servicios Web
Sin embargo, puede no ser necesario
Ej.: en Java, los Servicios Web se ejecutan en contenedores (web o EJB), eficientes y escalables
ESTANDARIZACION DE APIs

El API CORBA est estandarizada

Es posible cambiar de fabricante CORBA sin que ello afecte al cdigo fuente
Las APIs de Servicios Web no estn totalmente estandarizadas
No afecta a la interoperabilidad (los protocolos estn
estandarizados), pero s a la portabilidad
Las APIs Java se estandarizan
Ej.: Apache Axis es una implementacin de JAX-RPC
Soporte para servicios estndar 1

Localizacin
Los Servicios de Nombres y Trading de CORBA conceptualmente son equivalentes a UDDI
Notificaciones
En CORBA, un operacin puede recibir una referencia a un
interfaz remoto como parmetro
Es posible aplicar el patrn Observer para enviar notificaciones
entre aplicaciones publicadoras y subscriptoras
Adems, CORBA ofrece servicios especficos para poder enviar notificaciones de forma
escalable entre publicadores y subscriptores (Servicios de Eventos y Notificaciones)
Actualmente SOAP no permite que una operacin reciba o devuelva una referencia a un
puerto
Soporte para servicios estndar 2

Transacciones
Agrupar invocaciones a operaciones remotas dentro de una
misma transaccin
CORBA ofrece un potente Servicio de Transacciones
Actualmente no existe un Servicio de Transacciones para Servicios Web
Seguridad
Restringir los usuarios que pueden invocar una operacin
remota
CORBA ofrece un potente Servicio de Seguridad
Actualmente no existe un Servicio de Seguridad para Servicios Web
 CORBA Web Services

Especificacin Interface IDL WSDL

Nombre y directorio CORBA Services UDDI

CORBA Stubs/Skeletons SOAP Message

CDR binary encoding XML Unicode encoding

PROTOCOLOS
GIOP/IIOP HTTP

TCP/IP TCP/IP
 CORBA Stubs-Skeletons/SOAP

CORBA Stubs-Skeletons
La compilacin de IDL da como resultado stubs (lado del cliente) y skeletons (lado del
servidor).
ORB decodifica la solicitud, la pasa al skeletons. La solicitud de servicios skeletons le
devuelven al cliente una respuesta si corresponde al stubs.
SOAP
La especificacin SOAP incluye:
una sintaxis para definir mensajes
reglas de codificacin / serializacin para intercambio de datos
Convenciones para representar RPC.
 IDL/WSDL
IDL
IDL es un lenguaje que permite definir una serie de interfaces y los mtodos (funciones) de
esos interfaces para la comunicacin entre dos o ms aplicaciones. Este es un medio por el
cual la implementacin del objeto les dice a los clientes qu operaciones estn disponibles y
cmo invocarlas.
WSDL
WSDL es un formato que se utiliza para describir servicios web. WSDL describe la interfaz
pblica a los servicios Web.
Est basado en XML y describe la forma de comunicacin, es decir, los requisitos del
protocolo y los formatos de los mensajes necesarios para interactuar con los servicios listados
en su catlogo.
Las operaciones y mensajes que soporta se describen en abstracto y se ligan despus al
protocolo concreto de red y al formato del mensaje.
 Corba Services/UDDI

CORBA Services
CORBA Services son interfaces independientes del dominio que utilizan muchos programas de
objetos distribuidos.
Por ejemplo el servicio de nombres que permite a los clientes encontrar objetos basados en
nombres y el Servicio de Negociacin, que permite a los clientes encontrar objetos en
funcin de sus propiedades.
UDDI
UDDI proporciona un mecanismo para que los proveedores de servicios anuncien sus servicios
en un formulario estndar y para que los consumidores de servicios consulten los servicios de
inters.
Una entrada UDDI consta de pginas en blanco, pginas amarillas y pginas verdes.
 IIOP/HTTP

GIOP/IIOP
Para que un cliente solicite un programa en algn lugar de una red, debe tener una
direccin para el programa (IOR).
El GIOP es el protocolo que permite al programa establecer una conexin con un IOR y luego
enviarle solicitudes y recibir respuestas.
IIOP es el protocolo ms representativo que utiliza la capa de transporte de Internet TCP.
Otras posibles capas de transporte SNA de IBM y el IPX de Novell.
HTTP
SOAP utiliza el protocolo HTTP para la comunicacin entre mensajes. Los dos mensajes que
utiliza son request para enviar informacin del cliente al servidor y response como respuesta
del servidor al cliente.
 CDR/XML

CDR
Una representacin comn de datos (CDR) proporciona una manera de codificar y
decodificar datos para poder intercambiarlos de forma estndar.
XML
Una solicitud SOAP es un documento XML.
El orden es importante.
SOAP admite todos los tipos y tipos simples derivados de tipos simples definidos en W3C XML
Schema.
CDR binary encoding

CORBA CORBA
Short Struct
Long Sequence
Ushort Union
Tipos
Ulong Array
Float Referencia a
Double Objetos
Tipos
Char
String
Boolean
Octet
Enum
Array
XML Unicode encoding

Web Web
Services Services
Short ID
Long IDREF
Integer ENTITY
Ulong Tipos ENTITIES
Float NOTATION
Double NMTOKEN
Tipos NMTOKENS
Boolean
String
Datetime
Date
Time
Year
PROCESO DE DESARROLLO - CORBA

1. Definir los objetos del servidor mediante IDL.

2. Cargar la informacin de IDL en el Interface Repository
3. Pre-compilar el IDL para generar stubs y esqueletos.
4. Escribir el cdigo del servidor, heredando de los esqueletos (y
siguiendo el ejemplo)
5. Compilar los ficheros servidores.
6. Registrar los objetos en tiempo de ejecucin en el
Implementation Repository
7. Instanciacin de los sirvientes (por el adaptador,
normalmente bajo demanda)
8. Escribir el cdigo del cliente, (incluye los stubs generados)
9. Compilar el cliente
10. Ejecutar servidor, luego cliente
PROCESO DE DESARROLLO - WEB SERVICES

1. Crear un archivo .asmx

2. Indicar que es un Servicio Web mediante la directiva <%@ WebService e

indicar en la misma el lenguaje de programacin utilizado y el nombre de la
clase

3. Declarar la clase utilizando el atributo WebService en el que se indica el

espacio de nombres al que pertenece la clase y da una descripcin de la clase

4. Crear los mtodos que se deseen exponer del servicio web utilizando el
atributo WebMethod (si no se utiliza este atributo en la declaracin del
mtodo, entonces este no podr ser visto fuera del servicio web)

5. Publicar el servicio web en un registro UDDI

 Conclusiones

Integracin de aplicaciones en Internet

En general, la tecnologa de Servicios Web es la opcin (an
con sus limitaciones)
En general, CORBA no es una opcin (an con su madurez y
funcionalidad)
Integracin de aplicaciones en intranets
Actualmente CORBA parece la mejor solucin, dado que este
tipo de integraciones suelen requerir transacciones, seguridad, eventos, etc.
Servicios Web podra ser una alternativa para integraciones
sencillas (ej.: intercambio de datos)