1 / 21

S imple O bject A ccess P rotocol

S imple O bject A ccess P rotocol. Yonathan Ledo 01-34033 Christian de Sousa 01-33770. Definición.

munin
Télécharger la présentation

S imple O bject A ccess P rotocol

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Definición 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 ).

  3. Definición

  4. Definición

  5. Definición Estructura 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.

  6. Definición

  7. 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.

  8. WebServices • Implementaciones: • 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

  9. 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

  10. 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.

  11. 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

  12. Otras Alternativas XML-RPC Acercamiento minimalista al problema del paso de mensajes Protocolo bastante básico para la comunicación Bases de SOAP REST Protocolos de HTTP para hacer aplicaciones Peticiones de bajo nivel Bastante básico JSON-RPC Comunicación bidireccional El orden de respuesta puede no ser el mismo que el orden de llegada

  13. 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…

  14. 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 );

  15. CORBA Vs SOAP • 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) { • }

  16. 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(); • }

  17. Pruebas • Lenguaje Python • CORBA omniORB • SOAP ZSI • XML-RPC XMLRPClib

  18. ¿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

  19. ¿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

  20. 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….

  21. ¿Preguntas? Gracias por su atención…

More Related