Archivos Mensuales: julio 2005

Stress de proyectos

Hola,

Esta imagen me llegó por correo electrónico. Cómo trabajo en proyectos de software, disciplina estudiada en la ingeniería de software, me pareció muy interesante.

Entre paréntesis, la ingeniería de software no he tenido mucho éxito hasta ahora…

Anuncios

MADAGASCAR

Maravillosa película, me reí mucho.

 

Ahora, claramente los 4 personajes principales son un exceso dirigido a vender 4 veces más monitos. Muy gringo!!!

 

Ahora, los bichos de la isla que bailan todo el día, es una caricatura Gringa de una isla Africana. Esto me da un sabor a mirar en menos a los otros.

 

Por último, los personajes con más carácter son los pingüinos. La escena en que uno de ellos está usando un computador del barco, y el líder le dice “No quiero excusas quiero resultados” es simplemente notable.

Notable chiste que me mandaron, La triste realidad.

El hijo termina el colegio y no tiene ganas de estudiar nada.

Como el padre es un tipo malas pulgas, lo aprieta:
– ¿Ah? ¿No quieres estudiar? Bueno, yo vagos no mantengo, así que vas a trabajar. ¿Estamos……?
El padre, que tiene algunos amigos políticos dada su larga trayectoria, trata de conseguirle un empleo y habla con un amigo:
-Alo,……. Carlos, habla Tito…….. ¿Te acuerdas de mi hijo?. Bueno, terminó el colegio y no quiere estudiar por ahora. Si tu puedes, necesitaría un puesto como para que empiece a trabajar mientras decide si va a seguir una carrera … El asunto es que haga algo y no se las ande tirando todo el dia, ¿me entiendes?…
A los tres días llama Carlos:
– Tito, ya está. Asesor de la Comisión de Salud de la Cámara de Senadores.
Unos $4.000.000 por mes. Está bien, ¿no?
– ¡No, Carlos!. ¡Es una locura!. Recién empieza. Tiene que comenzar de abajo.
A los dos días, de nuevo Carlos:
– Tito, ya lo tengo. Le conseguí un cargo de Secretario Privado de un Diputado. El sueldo es más modesto, de $2.000.000.
– ¡No, Carlos. ¡Recién terminó el colegio!. No quiero que la vida se le haga tan fácil de entrada. Quiero que sienta la necesidad de estudiar, ¿me entiendes?.
Al otro día:
– Tito, ahora sí, Ayudante del Encargado del Archivo, con algo de computación ya está, claro que el sueldo se va muy abajo…serían $1.000.000, nada más. ¿Con qué va a pagar sus gastos personales…..?
– Pero Carlos, por favor!, conseguime algo más modesto. Recién empieza. Algo de $300 mil.
– Bueno … sí… se puede ver… pero no sería para él, Tito.
– ¿Por qué?
– Y… esos cargos son por concurso, necesita currículum, título universitario… ¿Me entiendes..?

Whisky

Notable película que habla de la soledad de la manera más extrema. La vida de Jacobo está marcada por la rutina y unas pocas palabras de saludo, que no son más que reflejo de la buena crianza pero que no comunican nada.

Para reforzar la idea de la rutina tiene una escena que me dio la impresión que es la misma, repetida un par de veces para reforzar así de la manera más fiel una vida sin agitaciones.

La velocidad del relato es a veces irritante, pero es la correcta para relatar la vida de Jacobo. Ahora, en el momento que pasa lo mas “agitado” en Piriapolis tocan la musica de Álvaro Enríquez.

Tan buena como 25 Watts, esta película uruguaya esta bien.

Cubos de Gestión, ideas de diseño. Primera Parte

Las soluciones de OLAP son
típicamente usadas para presentar la agregación de datos de manera eficiente,
mientras otras tareas son atendidas por el mismo servicio. Los cálculos y
almacenamiento de los datos agregados permiten 
para que los usuarios finales puedan cruzar grandes volúmenes de información con tiempos
de respuestas muy efectivos.

 

Existen dos puntos esenciales a ser  considerados
en el diseño de una solución de OLAP: DATA EXPLOSION y SPARSITY.

 

DATA EXPLOSION

Este término se entiende como la
tendencia de los cubos a crecer exponencialmente debido al uso de agregaciones
excesivas. Esto ocurre porque muchas veces son la idea de aumentar el desempeño
se hacen muchos precálculos de agregaciones para que al momento de consultarlas
los tiempos de respuesta sean mínimos. El problema es que esto consume mucha
capacidad de almacenamiento.

 

SPARSITY

Es una medida de la densidad de
datos dentro de un cubo o de una dimensión. 
Idealmente los cubos no deben contener celdas vacías, en la realidad los cubos
contendrán celadas bases vacías en sus dimensiones para posteriores recálculos
del cubo.

 

DIMENSION SPARSITY, de manera
análoga, es la medida de la cantidad de miembros vacíos dentro de una
dimensión. Esto quiere decir miembros de la dimensión que no tiene datos
asociados en ninguna FACT TABLE. Mientras más miembros vacíos
tenga
una dimensión, más probable es que produzca SPARSITY en los cubos en los cuales
esa dimensión se usa.

 

La causa principal de SPARSITY es
el uso de dimensiones con espacios o datos no relacionados. Esto parece poco
importante en términos de tamaño, pero usado en grandes volúmenes de datos  puede
producir un crecimiento exponencial del tamaño de los cubos.

 

Diseño de dimensiones

 

El diseño de las dimensiones es la llave de cubos de gestión
eficientes y de valor porque en rigor las FACT TABLE son medidas agregadas de
estas dimensiones. La clave del diseño de una dimensión efectiva es la
estructuración de los datos subyacentes.

 

Existen dos preguntas básicas que
deben ser consideradas en el diseño de las dimensiones de un cubo. La primera
es que modelo se usará, las opciones son “estrella
o “copo de nieve”.

 

 

El modelo estrella tiene dos
características principales:

 

  1. Una o más tablas de dimensiones, cada una con su llave primaria, con uno o más
    campos descriptivos que se usan para determinar el nivel de atributos de cada
    dimensión. Cada dimensión se encuentra en una sola tabla.

 

  1. Una FACT TABLE que contiene campos numéricos que están
    mapeados
    con las llaves primarias de las dimensiones.

 

 

El siguiente diagrama muestra un
ejemplo del modelo estrella.

 

 

 

El modelo de copo de nieve es
caracterizado por:

 

  1. Una o más tablas de dimensiones, cada una con su llave primaria, con uno o más
    campos descriptivos que se usan para determinar el nivel de atributos de cada
    dimensión. La diferencia es que las dimensiones pueden tener más de una tabla
    que le suministran más atributos a los miembros de la dimensión.

 

  1. Una FACT TABLE que contiene campos numéricos que están
    mapeados
    con las llaves primarias de las dimensiones.

 

El siguiente diagrama muestra un
ejemplo del modelo copo de nieve.

 

 

 

La razón más común para usar el
modelo de copo de nieve es reducir el espacio de almacenamiento requerido para
dimensiones de gran tamaño. Los atributos de menor
cardinalidad
son sacados de la tabla principal de la dimensión, para ser puestos en una
tabla secundaria que se relaciona con la principal a través de una llave de la
segunda. Esto reduce notablemente el requerimiento de almacenamiento pero
aumenta la complejidad del modelo.

 

Una segunda razón para utilizar el
modelo de copo de nieve es habilitar 
el análisis de los atributos de segundo nivel sin presentar los primeros. Esto es una
razón desde el punto de vista de uso de la información más que desde la
perspectiva del desempeño.

 

 

La segunda pregunta básica del
diseño de dimensiones es ¿Dimensiones
privadas o compartidas?
Aquí el punto es decidir si la dimensión que se
está diseñando será exclusiva de un cubo o será compartida por más de uno.

 

Además las dimensiones  privadas
no pueden ser usadas como fuentes de datos para crear
dimensiones virtuales
.

 

Las dimensiones privadas tienen una
ventaja en términos de administración porque siempre son procesadas cuando el
cubo es recalculado.  Además este
tipo de dimensiones provee un nivel de seguridad para datos sensibles porque
sólo es usada en el cubo para lo cual fue diseñada.

 

Las dimensiones privadas proveen
una ventaja en desempeño porque hacen un uso más eficiente de la memoria, los
miembros de estas dimensiones sólo son cargados una vez y puestos en CACHE.
Esto permite tiempos de respuesta más rápidos para consultas que involucran
este tipo de dimensiones.

 

Está decisión debe ser tomada con
cuidado ya que las dimensiones definidas inicialmente compartidas pueden ser
convertidas en privadas mientras que al revés no es posible hacer una
transformación.

(borrador) BizTalk Messaging, implementación del patrón MESSAGE BROKER.

 

El patrón MESSAGE BROKER

 

Es un componente que administra
las comunicaciones entre aplicaciones. La idea es que todas las aplicaciones se
comuniquen entre sí a través de él. Las aplicaciones envían un mensaje que
contiene dos tipos de datos, datos fuera de banda y de negocio. Los primeros
son información de contexto que es usada por el MESSAGE BROKER. Un ejemplo de
estos datos es la aplicación de destino del mensaje. Los datos de negocio se refieren
específicamente a los datos que la aplicación destino requiere para efectuar la
llamada requerida por la aplicación generadora del request.

 

El MESSAGE BROKER administra
información de contexto que le permite hacer un MATCH entre el contenido de los
datos fuera de banda. Un ejemplo de esto es que el mensaje dice una aplicación
de destino como “aplicación_1”, “ventas”, “666”, etc. De ese identificador de
aplicación de destino el BROKER debe determinar dónde está la aplicación y cómo
se comunica con ella. Es aquí donde utiliza la información de contexto
administrada por él. En ella encuentra correlato entre el contenido del mensaje
y una dirección física y canal de trasporte.

 

Las cuatro responsabilidades
básicas del BROKER son:

  1. Recibir mensajes desde las aplicaciones
    registradas.
  2. Determinar la aplicación de destino y el canal de
    comunicaciones a usar con ella.
  3. Administrar cualquier diferencia con la interfaz de
    la aplicación de destino.
  4. Enviar el mensaje a la aplicación destino, si
    corresponde responder a la aplicación de origen.

 

El siguiente diagrama muestra un
esquema de este patrón de integración.

 

 

 

 

 

¿Cómo implementarlo en BizTalk 2004?

 

Para implementar un MESSAGE
BROKER con BizTalk 2004 sólo es necesario hacer uso de BizTalk MESSAGING. Esto
rompe una idea recurrente en los desarrolladores los cuales piensan que toda
solución hecha en BizTalk necesariamente involucra una “orquestación”.

 

BizTalk MESSAGING provee varias
formas de enrutar, procesar y enviar mensajes entre
procesos de negocio.  Las tareas
principales que provee el servicio de MESSAGING son:

  1. Recepción de documentos (mensajes).
  2. PARSES de los mensajes entrantes para determinar su
    tipo especifico.
  3. Extraer las llaves de identificación y valores
    usados en las reglas de ruteo.
  4. Envío de mensajes a sus respectivos destinatarios.
  5. Hacer traking de los
    mensajes.

 

BizTalk utiliza un modelo llamado
Publish and Subscribe” que
le permite mayor escalamiento, tanto en la base de datos como en el
procesamiento de los mensajes. El concepto de suscripción  es el criterio que describe que tipos de
mensajes recibirá cada destinatario.

 

La idea es implementar un canal
de recepción de mensajes, que en jerga BizTalk sería un “puerto de recepción”,
para que las aplicaciones envíen ahí sus mensajes. Luego, según un criterio de
suscripción, el mensaje será despachado al puerto de salida que corresponda.
Esto suena muy simple, y en rigor lo es usando BizTalk.

 

Los pasos necesarios para
implementar el BROKER son:

  1. Crear un esquema de mensaje
    1. Promover los valores que se usaran cómo identificadores
      en el criterio de suscripción.
  2. Crear un puerto de recepción y un lugar de
    recepción.
  3. Crear los puertos de salida.
    1. Configurar los filtros necesarios.
    2. Suscribir los puertos al mensaje.
  4. Iniciar los puertos de entrada y salida.

 

Después de esto ya se tiene listo
el BROKER para un tipo de mensajes. Aquí hay que tener claridad que lo
importante es poder definir un mensaje de negocio lo suficientemente genérico
que permita tener información fuera de banda que sea usada por BizTalk e
información del negocio que será usada por la aplicación destino.

 

 

Crear el esquema del mensaje

Usando Visual Studio creamos el siguiente esquema.

  <?xml version="1.0" encoding="utf-16"
?>

– <xs:schema
xmlns="http://Liarjo.Demos.BrokerWs.Mesajeria.Schema1&quot;
xmlns:b="http://schemas.microsoft.com/BizTalk/2003&quot;
targetNamespace="http://Liarjo.Demos.BrokerWs.Mesajeria.Schema1&quot;
xmlns:xs="http://www.w3.org/2001/XMLSchema"&gt;

– <xs:element
name="Root">

– <xs:complexType>

– <xs:sequence>

– <xs:element
name="HEADER">

– <xs:complexType>

– <xs:sequence>

  <xs:element name="Aplicacion" type="xs:string"
/>

  <xs:element name="Usuario" type="xs:string"
/>

  </xs:sequence>

  </xs:complexType>

  </xs:element>

– <xs:element
name="BODY">

– <xs:complexType>

– <xs:sequence>

  <xs:element name="Valor1"
type="xs:string" />

  <xs:element name="Valor2"
type="xs:string" />

  </xs:sequence>

  </xs:complexType>

  </xs:element>

  </xs:sequence>

  </xs:complexType>

  </xs:element>

  </xs:schema>

 

 

Este esquema sólo nos da la
estructura del mensaje. Ahora debemos “destacar” que partes del mensaje
usaremos cómo criterios de la suscripción. Esto se hace promoviendo por ejemplo
el campo APLICACIÓN del TAG HEADER.

 

Para esto se debe apretar el
botón derecho sobre el campo y seleccionar “QUICK PROMOTION”. Esto hace que ese
valor ahora pueda ser usado en los filtros de ruteo y
criterios de suscripción. La siguiente imagen muestra el resultado de la
promoción del campo aplicación.

 

 

 

Crear un puerto de recepción y un lugar de recepción

Crear los puertos de salida

Iniciar los puertos de entrada y salida