El mejor CMS

He encontrado por ahí un concurso de CMS, ¿de Carlos Martín Sánchez? ... No! Content Management System (Gestores de contenido).

Actualmente esta web está hecha con uno de estos gestores de contenido, Drupal, a mí personalmente me parece uno de los mejores que existe actualmente. En un principio no lo elegí por nada en especial, decidí no programar mi propia web y descargué un CMS que me encontré por ahí, resulta que fué Drupal y es la leche, pero lo elegí por azar.

A lo que vamos, el concurso, el resultado ha sido:
1. Joomla!- $5,000
2. Drupal - $3,000
3. Plone - $2,000

En la web del concurso podéis ver detalles y argumentos de la elección.

Pescando en el mar de mi ignorancia

Estaba en el curro, pescando en el mar de mi ignorancia a ver si solucionaba un problemilla y me he vuelto a dar cuenta otra vez... Cada día estoy menos lúcido (que soy más tonto), recuerdo que hace unos años me atascaba menos en problemas de este tipo (casi triviales), pero ahora... necesito un Brain Trainer de esos.

Tras años preguntándome que por qué cada día soy más tonto tengo 2 teorías:
- Me he pasado con las fiestas, muy probable.
- Ya ahora viene la más científica, que los seres humanos perdemos nuestra capacidad de aprendizaje según vamos creciendo.

Yo me quedo con la de: "Como el Luisma es tonto ... "

El Viña a Benicásim

Cuantos buenos recuerdos (y lagunas) me trae la palabra ViñaRock. Siempre he asociado esta palabra al pueblo de Villarrobledo y como no, con sus gentes, que nos recibían con los brazos abiertos (y mira que no olíamos muy bien).
Bueno el caso es que ya ha salido el nuevo cartel del Viña con los grupos y días en que tocan. Por cierto lo han trasladado a Benicásim.

Bibiliografía

[1]

OMG. Common Object Request Broker Architecture - for embedded [archivo PDF]: May 2006. [Consulta: Diciembre, 2006]. Tambiém disponible en: http://www.omg.org/docs/ptc/06-05-01.pdf

[2]

GIDDINGS, Victor. Not Your Father’s CORBA - An Architecture for Embedded and Real-Time Systems.[online]: Octubre, 2006. http://www.rtcmagazine.com/home/article.php?id=100752 [Consultado Diciembre 2006].

[3]

ZeroC – Ice-E Overview [online]: Diciembre 2006.

http://www.zeroc.com/icee/index.html

Empotrabilidad

Las restricciones en la capacidad de memoria en los sistemas empotrados imponen un límite en el tamaño del middleware CORBA. Existen técnicas de optimización para adecuar CORBA a los sistemas empotrados. Algunas de ellas son optimizar el desarrollo del motor de protocolo y el compilador. Un buen ejemplo es la implementación de CORBA TAO, adecuada para sistemas empotrados de tiempo-real. Su compilador de IDL produce stubs y skeletons que pueden utilizar serialización tanto en forma compilada como interpretada (skeletons dinámicos). Un estudio del rendimiento y el tamaño de código de los stubs y los skeletons obtenidos mediante el compilador TAO IDL para varios tipos de datos indica que para tipos sencillos o medianamente complejos, los stubs interpretados son más eficientes, mientras para tipos complejos como estructuras de tamaño variable, estructuras anidadas, etc. los stubs compilados ofrecen mejos rendimiento.

De forma más general, el estudio realizado muestra que los stubs y skeletons dinámicos ofrecen menor rendimiento que los stubs y skeletons compilados (en una proporción del 75-100 %), mientras que en lo referente al tamaño, los skeletons y stubs dinámicos tienen un tamaño menor que los skeletons y stubs compilados (en una relación del 50-80 %).

El compilador TAO IDL genera stubs y skeletons con gran eficiencia y reducido tamaño que son adecuadas para un amplio rango de servicios y sistemas empotrados distribuidos.

Para reducir el tamaño de los stubs y skeletons, el compilador recurre a la técnica de factorización de código común en clases. También utiliza un esquema de paso de argumentos más eficiente que permite que el tamaño de los skeletons sea más pequeño.

Características técnicas:

A continuación vamos a ver qué aspectos hay que tener en cuenta y cuales no, a la hora de utilizar un determinado middleware (como Corba/e) en dispositivos empotrados:

Mecanismos de Interoperabilidad de CORBA/e

La interoperabilidad se consigue con el GIOP (General Inter-ORB Protocol) y por IIOP (Internet Inter-ORB Protocol).

GIOP [1]

El GIOP puede ser asociado a cualquier protocolo de transporte orientado a conexión que conozca un mínimo conjunto asunciones. La especificación consiste en:

• Common Data Representation (CDR). CDR es una sintáxis de transferencia que corresponde a tipos de datos OMG IDL en una representación a bajo nivel para la transferencia entre puentes (agentes) ORBs e Inter-ORB.

• GIOP Message Formats: formato de los mensajes que se intercambian entre distintos ORBs que interoperan.

• • Few, simple messages. Con solo 7 tipos de mensaje, soporta todas las funcionalidades de CORBA entre ORBs.

  • Dynamic object location. Muchas arquitecturas del ORB permiten a una implementación de objeto ser activada desde diferentes lugares durante la vida de éste y también los permite migrar dinámicamente.

• • Full CORBA support. Los mensajes GIOP soportan directamente todas las funciones y comportamientos requeridos por CORBA, incluyendo las excepciones remotas, referencia de objetos remota y contexto de paso de operaciones (como CORBA::Object::get_interface).

• GIOP Transport Assumptions. Son premisas generales que conciernen a cualquier capa del protocolo de red que deben ser tenidas en cuenta para transferir mensajes en formato GIOP. También se especifica como se deben administrar las conexiones y restricciones en el orden de los mensajes.

• Internet IOP Message Transport. El IIOP especifica como los agentes abren conexiones TCP/IP t las utilizan para transferir mensajes GIOP. En el siguiente punto se explica el IIOP más a fondo.

Transferencia de mensajes:

La especificación del GIOP está diseñada para operar sobre cualquier protocolo de transporte orientado a conexión que conoce un conjunto mínimo de reglas (para más información, está descrito en el apartado 13.4 de [1], "GIOP Message Transport" ). El GIOP utiliza conexiones de transporte subyacentes en los siguientes sentidos:

• Uso asimétrico de la conexión: Se definen dos roles distintos respecto a la conexión, cliente y servidor. Desde el lado del servidor no se deben enviar peticiones de objetos. Esta restricción fué incluida en las especificaciones del GIOP 1.0 y 1.1, pero ha sido relajada en la versión 1.2.

• Multiplexación de la petición: Cada petición identifica únicamente a su objeto destino. Múltiples peticiones independientes para objetos diferentes, deben ser enviadas en la misma conexión.

• Administración de conexión: Define mensajes para la petición de cancelación y desconexión ordenada. Esto permite a los ORBs la recuperación de recursos de conexión inactivos.

• Versiones para las peticiones y respuestas: la versión del mensaje que lleva una respuesta a una petición será igual que la versión del mensaje que lleva la petición.

(Para más información, ver especificación del GIOP, apartados 13 y 15 de [1]).

La solución de CORBA para sistemas empotrados: CORBA/e

CORBA es un middelware muy grande, extenso, potente y con muchas formas de proporcionar soluciones. Pero estas características, muchas veces positivas, dejan de serlo en los sistemas empotrados. Estos sistemas disponen de recursos muy limitados para integrarlos con CORBA directamente. Por ello el OMG ha publicado el estándar CORBA/e, la nueva arquitectura de alto rendimiento para los entornos en tiempo real y sistemas empotrados distribuidos.

CORBA/e proporciona una arquitectura de procesamiento distribuido que se ajusta tanto a las granjas de servidores más grandes, como a los más pequeños procesadores de señal digital interconectados (DSP).[2]

El OMG ha mezclado los aspectos estáticos del estándar CORBA con las características principales de Real-Time CORBA en dos nuevos perfiles agrupados bajo el nombre de CORBA/e:

• CORBA/e Compact Profile

  Se ajusta fácilmente microprocesadores comunes de 32-bit, ejecutando un sistema operativo de tiempo real (Real-Time Operating System, RTOS). Estos sistemas deben dar soporte a aplicaciones de communications, de procesamiento de señal o imagen en tiempo real.

• CORBA/e Micro Profile es más pequeño y se ajusta mejor a los procesadores de baja potencia y a los DSP de equipos móviles.

CORBA/e es un middelware saneado que hace menos costoso el desarrollo de software empotrado.

CORBA/e proporciona un acceso fácil acceso a diversos métodos de transporte como transportes sofisticados incluyendo memoria compartida, RapidIO y el FireWire, así como Ethernet. [2]

En los sistemas empotrados, como ya sabemos, los dispositivos deben interactuar con el mundo real. Estas interacciones deben ser fiables. CORBA/e proporciona previsibilidad distribuida para reconocer y propagar prioridades en su propio proceso y a través del sistema.[2]

El del mundo real también hay necesidades de energía, peso, tamaño y velocidad. CORBA/e se diseña específicamente a los sistemas interconectados proporcionando un consumo muy bajo y un alto rendimiento. CORBA/e se centra en dar soporte a las características más comunes de las versiones antiguas de CORBA.[2]

Los sistemas de CORBA/e son completamente interoperable y se apoyan en los estándares maduros de interoperabilidad del OMG: GIOP (protocolo general del Inter-ORBE) e IIOP (protocolo del Inter-ORBE del Internet). Además, algunas implementaciones de CORBA/e también ofrecen los transportes adicionales centrados en sistemas empotrados y permiten a los sistemas empotrados conectar sus propios protocolos de transporte. Esta flexibilidad permite a los dispositivos empotrados interoperar con sistemas de un rango muy amplio, desde grandes arrays de servidores hasta los senque se extienden de las instalaciones más grandes del arsenal del servidor a los sensores basados en pequeños chip. [2]

Sistemas empotrados e interoperabilidad: CORBA/e

Es un resumen de la solución que da CORBA para sistemas empotrados.

Alberto Vargas Rodrígez
Raul Miguel Sabariego
Javier Verdugo Lara
Carlos Martín Sánchez

Sistemas empotrados e interoperabilidad: CORBA/e

Se trata de un trabajo que hicimos para la asignatura de arquitectura de sistemas distribuidos. Es un resumen de la solución que da CORBA para sistemas empotrados.

Alberto Vargas Rodrígez
Raul Miguel Sabariego
Javier Verdugo Lara
Carlos Martín Sánchez

Nevada en Ciudad Real

Aquí en Ciudad Real cayó una buena, pero no había podido subir las fotos antes, que las tenía en el móvil.
Por cierto el de la capucha es mi gemelo el feo.