Cuestión: en la actualidad, existe mucha información de datos transmitida entre diferentes máquinas / servidores.
Esto conlleva a la necesidad obligada de definir un formato comprensible entre dichas máquinas.
Véase, todas las máquinas entienden binario... podemos compartir información binaria entre ellas, pero dicha información debe tener un sentido. Podemos, entonces, yendo a niveles superiores, definir objetos de Java y serializarlos, o bien, podemos definir un lenguaje de intercambio de datos, como XML, y transmitir la información en este lengüaje.
En este escenario (compartición de datos entre sistemas), en un escenario ya maduro, entran los ingenieros de desarrollo de Google con Protocol Buffers.... y no defraudan (en principio)
A continuación, vemos un minitutorial y los conceptos básicos de esta "tecnología"
La página raíz de la información pública del proyecto está en: https://developers.google.com/protocol-buffers/docs/overview
"Protocol buffers es un mecanismo flexible, automatizado y eficiente para serializar datos estructurados, piensa en XML, pero más simple, más pequeño y más rápido".
message Person {
required string name = 1;
required int32 id = 2;
optional string email = 3;
enum PhoneType {
MOBILE = 0;
HOME = 1;
WORK = 2;
}
message PhoneNumber {
required string number = 1;
optional PhoneType type = 2 [default = HOME];
}
repeated PhoneNumber phone = 4;
}
¿Por qué no usar XML?: porque este mecanismo es más ismple, de 3 a 10 veces más pequeño, de 20 a 100 veces más rápido, menos ambiguo, genera clases de acceso a datos muy fáciles de usar a nivel programático.
Veamos un ejemplo de representación de dato en XML y Protocol Buffer
<person> <name>John Doe</name> <email>jdoe@example.com</email> </person>person { name: "John Doe" email: "jdoe@example.com" }
Haciendo uso de protocol buffer en Java (fuente https://developers.google.com/protocol-buffers/docs/javatutorial)
required, campo requerido, optional -> campo opcional, repeated -> campo repetido. Vemos que cada campo tiene un identificador numérico (orden) asociado, que existen tipos básicos de datos (entero, string), que se pueden definir tipos enumerados, y que además se pueden definir campo representados por tipos complejos (compuesto por campos con diferentes tipos básicos y / o compuestos), de manera anidada. En el fichero a continuación, vemos como AdressBook (que le precede la palabra message para indicar que es un mensaje), está compuesto de personas (relación 0..n por la palabra repeated), que a su vez se compone de un nombre obligatoriamente (string required), un id obligatorio (int required), un email opcional, y un teléfono que responde a un tipo compuesto (phone), compuesto a su vez por un campo con el número (requerido) y el tipo de teléfono (campo enumerado con tres valores diferentes).package tutorial;
option java_package = "com.example.tutorial";
option java_outer_classname = "AddressBookProtos";
message Person {
required string name = 1;
required int32 id = 2;
optional string email = 3;
enum PhoneType {
MOBILE = 0;
HOME = 1;
WORK = 2;
}
message PhoneNumber {
required string number = 1;
optional PhoneType type = 2 [default = HOME];
}
repeated PhoneNumber phone = 4;
}
message AddressBook {
repeated Person person = 1;</strong></em>
}
protoc -I=$SRC_DIR --java_out=$SRC_DIR $SRC_DIR/addressbook.proto