Simple Object Access Protocol Yonathan Ledo 01-34033 Christian de Sousa 01-33770.

Simple Object Access Protocol

Yonathan Ledo 01-34033Christian de Sousa 01-33770

SOAP es un protocolo que define un estándar para el intercambio de mensajes, basados en XML, a través de una red de computadoras, empleando frecuentemente como medio el protocolo HTTP. Las primeras versiones fueron diseñadas entre otros por Microsoft e IBM, y actualmente se encuentra bajo el auspicio de la World Wide Web Consortium (W3C).

SOAP se originó alrededor del año 1998 y se convierte en el sucesor de RPC-XML. Por este motivo el patrón de comunicación más empleado por SOAP es el RPC.

SOAP hace uso de la capa de aplicación del modelo TPC/IP como protocolo de transporte, por ende, SOAP es capaz de funcionar sobre cualquier protocolo de Internet, aunque el más popular es HTTP(S), y también el SMTP (invocación de procesos de forma asíncrona ).

Definición

Definición

Definición

DefiniciónEstructura de un mensaje SOAP

El encabezado es opcional, proporciona un mecanismo de control para el envío de directrices o información contextual sobre el procesamiento del mensaje

El cuerpo del mensaje es obligatorio, y aquí es donde realmente se aloja la información que se transporta de un extremo a otro.

Definición

WebServices

Un WebService es un artefacto de software que ha sido diseñado para dar soporte a la interacción entre máquinas brindando interoperabilidad. Los servicios web como tal son API’s que se acceden a través de redes como Internet y cuyos métodos o procedimientos se ejecutan de forma remota en el sistema que hospeda el servicio.

WebServicesImplementaciones:

• RPC: invocación a métodos remotos. Se basa en Web Service Definition Language ( WSDL ), siendo la unidad básica una operación

• SOA: Arquitectura Orientada a Servicios, la unidad básica de comunicación es el envío de mensajes. Más reciente y publicitado.

• REST: (Representational State Transfer ) menos difundido

Implementaciones • Axis y el servidor Jakarta Tomcat (de Apache)

• ColdFusion MX de Macromedia

• Java Web Services Development Pack (JWSDP) de Sun

• Microsystems (basado en Jakarta Tomcat)

• Microsoft .NET

• Novell exteNd (basado en la plataforma J2EE)

• WebLogic

• WebSphere

• Zope es un servidor de aplicaciones desarrollado en Python

• Mono

Ventajas• No esta asociado a ningún lenguaje

• No esta asociado fuertemente a un protocolo de transporte

• Permite la interoperabilidad

• Aprovecha estándares existentes

• El uso de XML facilita la legibilidad

• Permite la comunicación con objetos JB, EJB y COM/COM+

• Evita las restricciones que imponen los firewalls sobre otros modelos como

CORBA, RMI , GIOP/IIOP o DCOM

• El uso de CORBA o RMI implica hacer marshalling / unmarshalling por lo

que en el caso particular de CORBA, tanto cliente como servidor, deben

emplear el mismo ORB y en el caso de RMI estar desarrollados en JAVA.

Desventajas• El estándar define el uso de mecanismos no de políticas

• Falta de interoperabilidad debido a que el estándar se encuentra lleno de

ambigüedades

• Algunas implementaciones limita la cantidad de datos a enviar

• Es posible la transmisión excesiva de datos consecuencia del uso de XML

• Mas lento e ineficiente que CORBA o RMI (formato binario)

• Como usa HTTP como base para la comunicación, la misma es en una sola vía y

no se realiza manejo de estado (stateless)

• Sobrecarga del puerto 80 ¿Que pasa si se propaga un virus a través de SOAP?

• No se puede agregar información para el procesamiento de los datos

Otras AlternativasXML-RPC

Acercamiento minimalista al problema del paso de mensajesProtocolo bastante básico para la comunicaciónBases de SOAP

RESTProtocolos de HTTP para hacer aplicacionesPeticiones de bajo nivelBastante básico

JSON-RPCComunicación bidireccionalEl orden de respuesta puede no ser el mismo que el orden de llegada

CORBA Vs SOAP

SOAP el programador debe crear los mensajes (bajo nivel) en CORBA son llamadas a objetos

SOAP no esta atado al paradigma de Objetos

SOAP no especifica un mapeo o interfaz independiente (dependencia de la librería)

Tanto SOAP como CORBA permiten RPC

SOAP es débilmente acoplado

SOAP no posee Chequeo de Tipos a Tiempo de compilación

SOAP no posee una estandarización CORBA posee mas de 10 años de experiencia…

CORBA Vs SOAP<esd:CType name="EchoData">

<esd:item name="aLong" type="xsd:int" builtin="true" array="false" inout="false"/><esd:item name="aBool" type="xsd:boolean" builtin="true" array="false" inout="false"/><esd:item name="aString" type="xsd:string" builtin="true" array="false" inout="false"/>

</esd:CType><esd:Method name="getData">

<esd:InParam name="GetDataRequest"><esd:item name="l" type="xsd:int" builtin="true" array="false" inout="false"/><esd:item name="b" type="xsd:boolean" builtin="true" array="false" inout="false"/><esd:item name="s" type="xsd:string" builtin="true" array="false" inout="false"/></esd:InParam><esd:OutParam name="GetDataResponse"><esd:item name="return" type="typens:EchoData" builtin="false" array="false” inout="false"/>

</esd:OutParam></esd:Method>

struct EchoData {long aLong;boolean aBool;string aString;

};EchoData getData( in long l, in boolean b, in string s );

URL url = new URL("http://localhost:8080/apache-soap/servlet/rpcrouter");Call call = new Call();call.setTargetObjectURI("urn:Hello");call.setMethodName("sayHelloTo");call.setEncodingStyleURI(Constants.NS_URI_SOAP_ENC);Vector params = new Vector();params.addElement(new Parameter("name", String.class, "Mark", null));call.setParams(params);Response resp = null;try {

resp = call.invoke(url, "");if ( !resp.generatedFault() ) {

Parameter ret = resp.getReturnValue();Object value = ret.getValue();System.out.println(value);

}else {

Fault fault = resp.getFault();System.err.println("Generated fault!");

}}catch (Exception e) {}

CORBA Vs SOAP

try {org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args,null);org.omg.CORBA.Object rootObj = orb.resolve_initial_references("NameService");NamingContextExt root = NamingContextExtHelper.narrow(rootObj);org.omg.CORBA.Object object = root.resolve(root.to_name("AcmeMyService"));MyService myService = MyServiceHelper.narrow(object);int ret = myService.sayHelloTo("Mark");

} catch (MyServiceException e) {System.err.println("Generated fault!");

} catch (Exception e) {e.printStackTrace();

}

CORBA Vs SOAP

Technology Connect time Send string (21,000

characters)

Receive string (22,000

characters)

Send 5,000 integers

Actual message size sending 1,000

characters

Actual message size sending 100

integers

Raw sockets 0.002242 0.001377 0.001359 6.740674 2,279 85,863CORBA 0.000734 0.004601 0.002188 1.523799 2,090 27,181XML-RPC 0.00704 0.082755 0.050199 100.337219 4,026 324,989SOAP 0.00061 0.294198 0.279341 1,324.30 4,705 380,288

PruebasLenguaje Python•CORBA omniORB•SOAP ZSI•XML-RPC XMLRPClib

¿Que usar? Y ¿Cuando?•CORBA <> SOAP

•Para llamadas internas (complejas) CORBA/IIOP y para llamadas externas (simples) SOAP

• Cuando no importa la seguridad SOAP

• Cuando no importa el contexto de la transacción SOAP

•Cuando importa eficiencia CORBA

• EN CORBA no se puede hacer debugging de los mensajes ya que solo GIOP lo puede entender

CORBA/IIOP IDL y Web Service /SOAP WSDL

¿Que usar? Y ¿Cuando?• SOAP es un protocolo de transporte y no puede ser usado para manejar todos los aspectos de una arquitectura de objetos distribuidos

• CORBA posee una alta curva de aprendizaje. Es difícil “entrarle” (+ costos)

•Desarrollo rapido = SOAP

• Ya el precio de la tecnología no es relevante

• Cosas nuevas llaman la atención

Sobre el Futuro

CORBA inicio ligero y sencillo luego poco a poco maduro y evoluciono formando el complejo sistema que es hoy

WebService/SOAP también inicio ligero y sencillo y poco a poco ha madurado y evolucionando….

¿Preguntas?

Gracias por su atención…