Middleware y RPCs

Servicios de Comunicacin de datos

Historia

Mainframes

Computo centralizado Hardware caro Ms funciones ejecutadas por la PC cliente Aplicaciones divididas entre cliente ligero/pesado y servidor Distribucin combinada con objetos Componentes tiene roles cliente y roles servidor

Paradigma C/S

Objetos distribuidos

Por qu procesamiento distribuido? vs C/S bsico

Compartir recursos Reducir costos de dispositivos y mantenimiento

Instalar una sola vez, upgradear en un solo servidor

Mayor tolerancia a fallas: replicacin Performance.

Middleware

Capa de software que conecta procesos / objetos distribuidos Herramientas para ayudar a la programacin Para hacer que el desarrollo cliente servidor sea ms fcil y ms rpido. Es software resultante es:

Menos propenso al error Ms confiable

Enfoque del middleware

Permite que el programador de C/S trabaje con construcciones con las que est familiarizado en los lenguajes de programacin subrutinas Proporciona herramientas de apoyo:

Traductores Libreras Comunicacin por la red Gestin de conexiones

Genera cdigo automticamente para:

Tipos de middleware

Transaccional. Para bases de datos distribuidas

Abstraccin de tuplas (tipo SQL) Procesamiento distribuido de transacciones , ej: CICS

Orientado al mensaje. Ej: Java message queue, MQSeries de IBM

Abstraccin de mensajes y mailbox o cola de mensajes, cuya respuesta es asncrona

RPC De Objetos y Componentes

RPC

Remote procedure call = llamada a procedimiento remoto Usa el paradigma de llamada a procedimiento (subrutina, subprograma) . Divide el programa usando los lmites de las llamadas a procedimientos

El programa principal y algunos procedimientos para interactuar con el usuario en el cliente. Otros procedimientos en el servidor.

Sigue siendo Cliente/Servidor

RPC
Client Server

Requ es
Blocked

Blocked

Remote Procedure Call es una mecanismo para estructurar sistemas distribuidos. Se basa en el modelo de las local procedure call:

Computing

Reply
Blocked

La aplicacin hace una llamada a un procedimiento sin importar sies que este es ejecutado en el nodo local o en un nodo remoto, y bloquea hasta que la llamada regresa (retorna).

Recordar que la red entre el caller y el callee (llamante y llamado, cliente y servidor) puede ser poco confiable (mensajes duplicados o perdidos) y que puede haber diferencias arquitecturales significativas entre 2 computadoras (diferente representacin de la data).

Problema del C/S con sockets

Est diseado en torno a I/O, y los sistemas diseados en forma centralizada manejan I/O pobremente. En vez de mensajes, por qu no enviar y recibir procedimientos? Si se pudiera hacer, programar SOs y aplicaciones distribuidas sera muy parecido a programarlas para 1 sla CPU.

Razn para usar RPCs

Si el programador usa el mismo paradigma en el desarrollo de programas normales que en el desarrollo de programas cliente servidor, el programador tendr una labor ms fcil y con menos errores. Si hay gran cantidad de data centralizada. Proceso debe correr en cierta computadora siempre (hardware, seguridad, etc.) Adems, este paradigma es ms fcil de extender a prog. orientada a objetos.

Llamadas a procedimientos: ejemplo en programa tradicional

En esta figura, las flechas son llamadas a procedimientos

Llamadas a procedimientos: divididos entre cliente y servidor

Las divisiones ocurren en la frontera entre llamadas a procedimientos El programa principal est en el cliente.

Mecanismo del RPC

Mayores componentes de un RPC :
Caller (client) Arguments Client stub Request Reply Return value Callee (server) Arguments Return value

1.

Server stub Request Reply

Un protocolo entre caller y callee que parcha las propiedades no deseadas de la red. Puede ser propio del RPC o ajeno (TCP) Un lenguaje de programacin y un compilador que soporten RPC: los argumentos de una llamada deben ser puestos en el mensaje de request y entonces traducidos en algn punto. La data de regreso sufre un proceso similar.

RPC protocol

RPC protocol

2.

Ejemplo local procedure call

Ejemplo: count= read(fd, buf, nbytes) Count, fd y nbytes son enteros, buf es un array. Se llama a read desde el main()
Var. locales de main SP Var. locales de main nbytes buf fd Direc.retorno Var. locales de read Los parametros pueden ser llamados por valor (fd) o por referencia (buf)

SP

Mecanismo del RPC

Los parmetros en la pila no son mandados al SO local, son mandados por un mensaje de la red a un SO en otra computadora.
Resguardo o stab del cliente Resguardo del servidor

Computadora cliente

Computadora servidor

llamada

Empacar parmetros Desempacar resultado

cliente
regreso

Solo por valor

RED

Desempacar parmetros Empacar resultado

llamada

servidor
regreso

Ncleo

Ncleo

Stubs o resguardos de comunicacin

Se insertan para hacer posible el RPC Se generan automticamente Usan una interface propia (original al middleware) de llamadas Permite que tanto el procedimiento que llama y el que es llamado no necesiten modificarse o adaptarse al middleware.

Los stubs en cliente y servidor

Programacin convencional en (a) El mismo programa con stubs en (b)

Creando stubs

El programador escribe:

El cdigo fuente del programa Especifica las interfaces usando un IDL (Interface Definition Language) Cdigo fuente del cliente stub y servidor stub Llamadas a los sockets Traduccin de formaos de data

El middleware genera:

Representacin de la data

Las redes pueden conectar sistemas heterogneos. Ej.: Una PC Intel con Windows y un Sistema P (rs/6000) con procesador Power y UNIX. Dos computadoras pueden usar diferentes:

Representaciones de enteros Representaciones de nmeros punto flotante Cdigos de carcter (ASCII vs. EBCDIC)

Hay que traducir la data.

Posibles formas de traducir

Usar la representacin del receptor

El emisor debe traducir la data que enva. El receptor debe traducir la data que recibe.

Usar la representacin del emisor

Usar una representacin predeterminada (es lo ms usado)

Emisor traduce al formato predeterminado antes de enviar Receptor traduce del formato predeterminado despus de recibir

Diseo de protocolos para RPC

Un protocolo para RPC debe cumplir varias funciones, principalmente: Fragmentar y rearmar mensajes largos, Sincronizar mensajes de request y sus respuestas, y Despachar mensajes de request al proceso correcto.

Ejemplos de protocolos RPC

DCE (Distributed Computing Environment) Microsoft: DCOM, Active X, .Net CORBA SUN RPC (ONC RPC) Web services (ejemplo: SOAP, XML-RPC)

Ejemplos de programas que usan RPC

Consultas DNS (nslookup, gethostbyname) X Windows. El cliente (host remoto) accede al servidor de grficos en la terminal para ejecutar funciones e manipulacin de la pantalla. Es un RPC asncrono (no se bloquea).

Middleware orientado a objeto

Diseado para usarse con lenguajes orientados a objetos Mismo esquema general que el del RPC

IDL Herramientas para construir stubs Libreras para manejar la comunicacin en la red

Usan invocacin de mtodos en vez de llamadas a procedimientos

Ejemplos de middleware OO

Corba COM, DCOM Java RMI, Enterprise Java Beans Plataforma o framework .NET (Windows Communication Foundation)

Web Services: Definicin

Segn el W3C (World Wide Web Consortium): Un Web Service es un sistema de software identificado por un URI cuyas interfases pblicas y enlaces estan definidos y descritos usando XML. Su definicin puede ser descubierta por otros sistemas de software. Estos sistemas pueden interactuar con el Web Service de un modo prescrito por su definicin, usando mensaje basadosen XML viajando en protocolos de Internet .

Web Services: Definicin

Ms resumido: es una aplicacin de software, accesible en la Web a travs de su URL, que es accedida por clientes usando protocolos basados en XML (ej.: SOAP) y mandado a travs de protocolos de Internet como el HTTP. Los clientes la acceden a travs de interfase y enlaces definidos en entidades XML (ej.: archivos WSDL).

Definicin

Registro2

Registro1
Web Service 2 Web Service 1

Registro3

Web Service 3 Cliente A Cliente B

Por qu usar Web Services?

Interoperabilidad entre diferentes plataformas. Facilidad de modificar la arquitectura de software. Servicios fcilmente accesibles va Web. Integracin con sistemas existentes. Variedad de clientes (Java, Windows) Muchos proveedores de herramientas. Programacin rpida.

Escenarios tpicos

Una agencia de viajes quiere proporcionar a potenciales clientes un catlago de tours. Un Sistema existente permite que el cliente personalice su tour: hoteles, transporte, actividades especficas, horarios; y permite que se separe el viaje. Adems se quiere: interatuar con el cliente, seguir el proceso de creacin del paquete turstico (workflow), CRM, interactuar con proveedores.

Escenarios tpicos

SOAP

XML es el lenguaje comn. SOAP es el formato de mensajes comn. SOAP hace posible que objetos que no se conocen puedan comunicarse entre si. Se basa en XML y usa HTTP o SMTP para llevar mensajes. Independiente de lenguajes y plataformas. Es amistoso respecto a los firewalls.

SOAP

Simple Object Access Protocol. Al inicio se desarrollo un RPC que usaba XML (XML-RPC). Luego apareci SOAP. Se define una envoltura o sobre: el cuerpo del SOAP donde va el mensaje, y la cabecera opcional. Toda la envoltura o sobre es un documento XML. El receptor del mensaje usa el cuerpo. La cabecera es para CPUs intermedias (autentiticacin y transacciones).

SOAP

En la cabecera va informacin relativa al tipo de informacin que va en el cuerpo. Los mensajes SOAP son transmisiones en un solo sentido.

Sobre SOAP

Cabecera

Cuerpo

Pedido en SOAP
<SOAP-ENV:Envelope xmlns:SOAP-ENV= "SoapEnvelopeURI SOAP-ENV:encodingStyle= "SoapEncodingURI"> <SOAP-ENV:Header> </SOAP-ENV:Header> <SOAP-ENV:Body> <m:GetLastTradePrice xmlns:m="ServiceURI"> <tickerSymbol>SUNW</tickerSymbol> </m:GetLastTradePrice> </SOAP-ENV:Body> </SOAP-ENV:Envelope

Pedido en SOAP
<SOAP-ENV:Envelope xmlns:SOAP-ENV= http://schemas.xmlsoap.org/soap/envelope SOAPENV:encodingStyle= " http://schemas.xmlsoap.org/ soap/encoding"> <SOAP-ENV:Header> </SOAP-ENV:Header> <SOAP-ENV:Body> <m:GetLastTradePrice xmlns:m="ServiceURI"> <tickerSymbol>SUNW</tickerSymbol> </m:GetLastTradePrice> </SOAP-ENV:Body> </SOAP-ENV:Envelope

WSDL

Web Services Definition Language. Define el modo estndar de especificar los detalles de un Web Service. Es un esquema XML de propsito general que puede describir la interfase, los enlaces y otros detalles de un Web Service. Un Web Service es pensado como una coleccin de puntos extermos de comunicacin (puertos). La data intercambiada es especificada como parte de un mensaje. Cada tipo de accin permitida en un puerto es una operacin.

WSDL

Un documento WSDL completo debe consistir de seis clases de definiciones: Type: define los tipos de datos. Message: define los mensajes que el Web Service intercambia, incluye tipo de datos (un elemento Message por cada mensaje). Port type: dice que operaciones y mensajes son parte de un Web Service. Binding: enlace un tipo de puerto (ms mensajes y operaciones) a un protocolo especfico y formatos de mensajes.

WSDL

Port: el nombre del puerto y su ubicacin (URl, URI). Service: junto con Port, define el punto extremo (puerto). Service agrupa 1 o ms puertos relacionados entre si.

WSDL
<?xml version="1.0" encoding="UTF-8"?> <definitions name="HelloWebService" targetNamespace="urn:HelloWebService" xmlns:tns="urn:HelloWebService" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <types/> <message name="HelloIntf_sayHello"> <part name="String_1" type="xsd:string"/> </message>

WSDL
<message name="HelloIntf_sayHelloResponse"> <part name="result" type="xsd:string"/> </message> <portType name="HelloIntf"> <operation name="sayHello" parameterOrder="String_1"> <input message="tns:HelloIntf_sayHello"/> <output message="tns:HelloIntf_sayHelloResponse"/> </operation> </portType> <binding name="HelloIntfBinding" type="tns:HelloIntf"> <operation name="sayHello">

WSDL
<input> <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" use="encoded" namespace="urn:HelloWebService"/> </input> <output> <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" use="encoded" namespace="urn:HelloWebService"/> </output> <soap:operation soapAction=""/> </operation> <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="rpc"/> </binding>

WSDL
<service name="HelloWebService"> <port name="HelloIntfPort" binding="tns:HelloIntfBinding"> <soap:address location= http://example.COM:8000/webservice /HelloService"/> </port> </service> </definitions>

Estructura de Web Services en Java

Estructura de Web Services en Java

Una vez que un cliente sabe como acceder al W.S., hace un requesta al W.S. llamando a un mtodo Java, que pasa con sus parmetros al JAX-RPC runtime en el cliente. El JAX-RPC runtime mapea los tipos de datos Java a los tipos de datos XML y crear un mensaje SOAP que encapsula el mtodo y los parmetros. Pasa el mensaje al manejador SOAP (si lo hubiera) y de all se va al puerto del W.S.

Estructura de Web Services en Java

Si hay manejadores en el servidor, el SOAP pasa por ellos. El mensaje SOAP pasa al punto extremo del W.S. Se extrae el mtodo y los parmetros, y se convierten los tipos XML a Java. Se ejecuta el mtodo Cuando se manda la respuesta, el proceso es parecido.