Representación externa de datos y Serialización Marisol García Valls Arquitecturas Distribuidas 2º Ingeniero de Telecomunicación (Telemática) Departamento.

Presentación del tema: "Representación externa de datos y Serialización Marisol García Valls Arquitecturas Distribuidas 2º Ingeniero de Telecomunicación (Telemática) Departamento."— Transcripción de la presentación:

1 Representación externa de datos y Serialización Marisol García Valls Arquitecturas Distribuidas 2º Ingeniero de Telecomunicación (Telemática) Departamento de Ingeniería Telemática Universidad Carlos III de Madrid mvalls@it.uc3m.es

2 Arquitecturas Distribuidas ©2009 Marisol García Valls 2 Índice Introducción a la comunicación remota Formato de representación externa de datos Empaquetado de datos (marshaling) Serialización de objetos de Java El mecanismo de reflexión Temas relacionados: –Referencias a objetos remotos Bibliografía: G. Coulouris, et al. “Sistemas distribuidos. Conceptos y diseño”. 3ª ed. (o posterior). Addison-Wesley 2001. CAPÍTULO 4.

3 Arquitecturas Distribuidas ©2009 Marisol García Valls 3 Comunicación remota mobjCliente () {... x = objetoRemoto.m1(a,b,c);... } La información en los programas en ejecución se representa como estructuras de datos (objetos interconectados) En los mensajes, la información consiste en secuencias de bytes. 0100011101001

4 Arquitecturas Distribuidas ©2009 Marisol García Valls 4 Formato externo de representación de datos Las estructuras de datos (ED’s) deben ser aplanadas (convertidas a una secuencia de bytes) para su transmisión. El orden de almacenamiento de valores primitivos, como los enteros, puede diferir en computadores distintos : big-endian o little endian. La representación de los números de coma flotante también puede diferir. Los códigos para representación de caracteres puede ser ASCII (Unix) o Unicode. Para permitir el intercambio de valores de datos entre dos computadores, los valores podrán: –convertirse a un formato externo de representación acordado antes de la transmisión. –transmitirse en el formato del emisor, junto con la indicación del formato usado. La representación externa de datos es un estándar acordado para la codificación de estructuras de datos y valores primitivos.

5 Arquitecturas Distribuidas ©2009 Marisol García Valls 5 Empaquetado Empaquetado (marshalling) es el proceso de tomar un conjunto de datos y ensamblarlos en una forma adecuada para ser transmitida en un mensaje. Desempaquetado (unmarshalling) consiste en el desensamblaje en el punto de recepción para producir una colección equivalente de datos. Por tanto, el empaquetado consiste en la traducción de elementos de datos estructurados y valores primitivos a una representación externa de datos. El empaquetado permite: –trabajar con los parámetros y resultados de invocaciones remotas, –conversión de ED’s u objetos a formas adecuadas para transmisión de mensajes, y –conversión de ED’s u objetos a formas adecuadas para almacenamiento en disco.

6 Arquitecturas Distribuidas ©2009 Marisol García Valls 6 CORBA CDR y Serialización de JAVA Existen dos aproximaciones al empaquetado y representación externa de datos: –Representación común de datos de CORBA (CORBA CDR): transmisión de argumentos y resultados. –Serialización/secuenciación de objetos de Java (serialization): transmisión de argumentos y resultados y almacenamiento en disco. En ambos casos, el des/empaquetado es realizado por el middleware sin intervención de la aplicación. En ambos casos, los tipos de datos primitivos se empaquetan a forma binaria. Una forma alternativa de empaquetado consistiría en empaquetar a texto ASCII (HTTP). El empaquetado ASCII es simple de implementar pero produce unos datos de mayor tamaño.

7 Arquitecturas Distribuidas ©2009 Marisol García Valls 7 Serialización de objetos en Java Actividad para aplanar un objeto o un conjunto de objetos relacionados a un formato secuencial adecuado para almacenamiento en disco o transmisión en un mensaje. Deserialización consiste en restablecer el estado de un objeto o conjunto de objetos a partir de su forma serializada. Se pueden pasar como argumentos y resultados tanto valores de tipos primitivos como objetos. Para que una clase sea serializable debe implementar la interfaz Serializable. public class Persona implements Serializable { private String nombre, lugar; private int anno; public Persona(String uNombre, String uLugar, int uAnno){ nombre = uNombre; lugar = uLugar; anno = uAnno; } // Métodos para acceder a las variables de instancia }

8 Arquitecturas Distribuidas ©2009 Marisol García Valls 8 Información de serialización El proceso de deserialización no tiene conocimiento previo de los tipos de los objetos de la forma serializada. Se necesita incluir información sobre la clase de cada objeto en la forma serializada. Ello permitirá al receptor cargar las clases necesarias al serializar objetos. Información en la serialización de un objeto: NombreVersiónNúmero, tipo y nombre de variables instanciaValores de variables instancia Info. de la clase El número de versión cambia cuando la clase sufre modificaciones sustanciales. Puede establecerlo el programador o ser calculado como el hash del nombre, variables de instancia, métodos e interfaces. El proceso de deserialización comprueba si tiene la versión adecuada de la clase.

9 Arquitecturas Distribuidas ©2009 Marisol García Valls 9 Serialización recursiva Los objetos de Java pueden contener referencias a otros objetos. Cuando se serializa un objeto todos los objetos a los que mantiene referencias son también serializados. Al reconstruir los objetos en el destino, todas sus referencias podrán ser resueltas. Las referencias son serializadas como apuntadores (handles). Un apuntador es una referencia a un objeto en la forma serializada. Deberá existir una correspondencia 1 a 1 entre referencias a objetos y apuntadores. Cada objeto deberá ser escrito sólo una vez. En sus posteriores ocurrencias se escribirá el apuntador. Si las variables de instancia pertenecen a clases nuevas, su información de clase deberá ser escrita también, seguida de los nombres y tipos de sus variables de instancia. Cada clase tiene un apuntador de forma que sólo se escribe una vez al stream de bytes. Por lo tanto, es un proceso recursivo.

10 Arquitecturas Distribuidas ©2009 Marisol García Valls 10 Más datos sobre la serialización de Java Los contenidos de las variables que son tipos primitivos (enteros, caracteres, booleanos, bytes y longs) se escriben en un formato binario portable. Para ello se usan métodos de la clase ObjectOutputStream ( writeObject ). Los strings y caracteres se escriben usando el Formato Universal de Transferencia (UTF), con el método writeUTF. En UTF los caracteres ASCII se representan con un byte y Unicode con múltiples bytes. Los strings van precedidos del número de bytes que ocupan en el stream. Como ejemplo, véase la forma serializada del siguiente objeto: Persona p = new Persona(“Paco”, “Valencia”, 1909); PersonaNº versión de 8 bytesh0 3 int annojava.lang.String nombrejava.lang.String lugar 19094 Paco8 Valenciah1

11 Arquitecturas Distribuidas ©2009 Marisol García Valls 11 Utilización del mecanismo de serialización Para serializar un objeto: –se crea una instancia de la clase ObjectOutputStream, –se invoca su método writeObject, con el objeto a serializar como argumento. Para deserializar un objeto de un stream de datos: –se abre un ObjectInputStream sobre el stream en cuestión, –se usa su método readObject para reconstruir el objeto original.

12 Arquitecturas Distribuidas ©2009 Marisol García Valls 12 Cambios en la serialización El mecanismo de serialización y deserialización es llevado a cabo por el middleware sin intervención de la aplicación. Puede necesitarse características especiales en la serialización que obliguen a modificarla. Para modificar la serialización se puede cambiar la implementación de los métodos de de/serialización. Pueden también declararse variables que no deban ser serializadas con el modificador transient. Ejemplos de objetos que no deban ser serializados son: sockets, ficheros locales, claves, etc.

13 Arquitecturas Distribuidas ©2009 Marisol García Valls 13 El mecanismo de reflexión (reflection) La reflexión consiste en la habilidad de preguntar sobre las propiedades de una clase (nombres y tipos de sus atributos y métodos). Esto hace posible crear clases a partir de sus nombres y crear un constructor para una clase dada con los argumentos dados. La reflexión permite hacer serialización y deserialización de una manera totalmente genérica. Por tanto, no hace falta generar funciones de empaquetado especiales para cada tipo de objeto (como sí es el caso en CORBA). La serialización de Java usa reflexión para: –averiguar el nombre de la clase del objeto a serializar y los nombres, tipos y valores de sus atributos. La deserialización en Java usa reflexión para: –crear una clase a partir del nombre de la clase de la forma serializada; –esto se usa para crear un nuevo constructor con los tipos de argumentos correspondientes a los especificados en la forma serializada; –el constructor se usa para crear un objeto con los atributos cuyos valores vienen en la forma serializada.

14 Arquitecturas Distribuidas ©2009 Marisol García Valls 14 Referencias a objetos remotos Un objeto remoto vive sólo en el proceso que lo ha creado y muere al morir éste. Las invocaciones a métodos remotos se transmiten a través de mensajes que contienen la información necesaria (nombre del método, parámetros, valor de retorno, etc.). Además, en una invocación remota se necesita especificar el objeto remoto sobre el que se quiere ejecutar ese método. Una referencia a objeto remoto (RR) es un identificador para un objeto que reside en algún lugar de la red; esta referencia es válida a lo largo y ancho del sistema distribuido. En la invocación remota se pasa una referencia al objeto remoto sobre el que se va a realizar la invocación de ese método. Las referencias remotas son pasadas como argumentos y devueltas como resultados. Cada objeto remoto tiene una única RR. Las RR pueden ser comparadas para averiguar si hacen referencia al mismo objeto remoto. Las RR no deben ser reutilizadas; puede haber invocantes que mantengan RR obsoletas.

15 Arquitecturas Distribuidas ©2009 Marisol García Valls 15 Representación externa de las referencias remotas Las RR deben ser generadas de forma que se asegure su carácter único. Una forma de asegurar RR únicas es construyéndolas por concatenación con los datos: Dirección Internet Nº de puertoHoraInterfaz de objeto remotoNº de objeto 32 bits El número de puerto es el del proceso/hilo que creó el objeto. El número de objeto se incrementa cada vez que se crea un nuevo objeto en ese proceso. El nº de puerto y nº de objeto constituyen un identificador único para el proceso en esa máquina. La interfaz es relevante para cualquier proceso que reciba una RR como argumento o resultado de una invocación remota. La interfaz permite saber los métodos ofrecidos por el objeto remoto.