Resultados del exámen Aplazados de TEOCOM2 20091

Acá están los resultados del examen de aplazados de TEOCOM2. La clave de corrección es 1a,2ab,3acde,4abce,5bc,6acde,7abde,8abcd

N	Código	Nota
1	48552	8
2	9736	7
3	9388	7
4	47416	6.5
5	50468	6
6	7342	5.5
7	15594	4.5
8	45239	4
9	50545	3
10	49471	2.5
11	48526	2.5
12	9755	2
13	6608	1.5
14	50692	1.5
15	47417	1
16	41812	0
17	42855	0
18	49334	-0.5
19	50760	-1.5
20	9460	-2
21	43558	-2.5
22	53633	-5

Resultados del exámen Aplazados de CIRDIG0 20091

Acá están los resultados del examen de aplazados de CIRDIG. Saludos

N	Código	Nota
1	27709	14.7334
2	40964	14.0666
3	27151	13.4667
4	63077	13.4667
5	52497	13.2
6	46048	12.9334
7	50832	12.0666
8	51120	11.9334

El Cubo de Rubik

Instrucciones

Modo X (Cubo superior)

Para rotar el cubo sobre el eje X: Ubicar el mouse en la zona azul eléctrico y arrastrar en mouse en los sentidos que indica la fecha de dos puntas.

Para cambiar a los modos Y ó Z: Ubicar el mouse en la zona azul acero y arrastrar en mouse en sentido vertical u horizontal.

Modo Z (Cubo del centro)

Para rotar el cubo sobre el eje Z: Ubicar el mouse en la zona azul eléctrico y arrastrar en mouse en los sentidos que indica la fecha de dos puntas.

Para cambiar a los modos X ó Y: Ubicar el mouse en la zona azul acero y arrastrar en mouse en sentido vertical u horizontal.

Modo Y (Cubo inferior)

Para rotar el cubo sobre el eje Y: Ubicar el mouse en la zona azul eléctrico y arrastrar en mouse en los sentidos que indica la fecha de dos puntas.

Para cambiar a los modos X ó Z: Ubicar el mouse en la zona azul acero y arrastrar en mouse en sentido vertical u horizontal.

Han pasado más de cinco años, cuando hacía mis pininos en flash y nada mejor para practicar que el cubo mágico. Este flash lo publico con el fin de promover este juguete y convocar a la gente para que se prepare armando el cubo para el concurso que estaremos realizando el próximo ciclo. Por lo pronto les dejo este link.

Control por Internet con MSMQ

Control por Internet con MSMQ

1. Introducción

Es inevitable que la verdadera red de servicios integrados sea la red IP. A su vez, es sabido que cuando hablamos de IP, estamos hablando de Internet, que es la plataforma en la cual cada día se van integrando mayores servicios.

El desarrollo de aplicaciones distribuidas ha significado una cada vez mayor utilización de equipos y recursos así como la necesidad de controlar y supervisar procesos cada vez a una distancia mayor. Esto ha generado, en consecuencia, la necesidad de implementar el control de procesos a través de Internet.

Control por Internet

El control por Internet ha sido abordado en distintos escenarios:

Un primer escenario es el desarrollo de aplicaciones cliente/servidor capaces de intercambiar información; la principal dificultad de esta solución, es la necesidad de un software cliente en la PC del usuario.

Como segunda propuesta tenemos a las aplicaciones web; éstas, a diferencia de las primeras, permiten que el usuario interactúe con el proceso desde una página Web, brindándole una interfase http para el control por Internet eliminando la necesidad de un software cliente e incrementando la seguridad del sistema.

La tercera solución es la implementación misma de un servidor web propietario, que por un lado permite la interacción con el usuario y por el otro comunicarse con el proceso.

Una solución un poco más complicada es similar a la anterior, sólo que la implementación se hace en un firmware, el cual puede ser parte del proceso mismo.

En esta oportunidad nos ocuparemos de las aplicaciones web.

2. Aplicaciones web

En este escenario, tenemos a un usuario que interactúa a través de su explorador con unservidor web. El servidor, a su vez, se comunica con una aplicación, la cual se encarga de controlar o supervisar el proceso.

A partir de aquí, nuestro trabajo estará enfocado principalmente en lograr la comunicación entre el servidor web y el servidor de aplicaciones de una manera óptima.

Entre las soluciones que se han propuesto a este problema tenemos a:

WSH, que permite la ejecución de una aplicación en un equipo de manera remota. Con esta herramienta podemos ejecutar un programa desde una página web. Los problemas que presentó y su falta de soporte para las nuevas versiones de Windows han hecho que miremos a otras soluciones como:

MSMQ, que tiene un esquema más ordenado y óptimo para realizar esta tarea.

Figura 1 Operación básica de MSMQ

Siendo MSMQ una mejor solución, explicaremos entonces, cómo utilizar MSMQ para el intercambio de información entre el cliente y servidor.

MSMQ - Microsoft Message Queuing

La operación básica de MSMQ consiste en que una aplicación -valga decir, un servidor web -, deja un mensaje en un servidor intermedio al cual llamaremos servidor de colas de mensajes. Este servidor a su vez, notifica al servidor de aplicaciones la llegada de un nuevo mensaje para que éste lo procese adecuadamente.

MSMQ es un servicio de los sistemas operativos Windows Server, por lo que su instalación es similar a la forma en que se agrega cualquier otro servicio.

El servicio de MSMQ tiene varios componentes; entre ellos encontramos al servicio mismo, desencadenadores y disparadores, integración con Active Directory, soporte para http, entre otros.

Figura 2 Consola de MSMQ

La consola de MSMQ no tiene un acceso directo en el menú de herramientas administrativas, por lo que es necesario acceder primero a la consola de administración del servidor y desplegar la consola en el árbol de servicios y aplicaciones. La consola de MSMQ nos permite la administración de colas públicas y privadas, la generación de reglas y finalmente la configuración de desencadenadores.

La función de los desencadenadores es la ejecución de un evento en respuesta a la llegada de un mensaje. El evento puede ser: el envío de parámetros a una aplicación, la ejecución de una tarea, entre otros. La ejecución del desencadenador depende de que el mensaje cumpla los requerimientos preestablecidos. A estos requerimientos se les llama reglas. Una regla puede ser que la cola de destino tenga por nombre ‘proceso2’ o que el título del mensaje sea ‘variables’.

La consola de administración de MSMQ permite, además de realizar tareas como las mencionadas anteriormente, la visualización de mensajes recibidos, pero no permite el envío de mensajes. El envío de mensajes debe hacerse a través de una aplicación.

En nuestro caso es el servidor web el encargado de enviar el mensaje y el servidor de aplicaciones el encargado de recibirlo.

Figura 3 Diseño todo en uno.

Todos los servicios pueden ser ejecutados en un solo equipo. Así, el servidor web, el servidor de aplicaciones y el servidor de MSMQ pueden estar integrados en un solo equipo como muestra la figura anterior, en este escenario el servidor necesita de una dirección IP fija o de lo contrario de una dirección IP dinámica resuelta por un DNS, como segundo requisito es tener abiertos los puertos del servidor web y de MSMQ. Sin embargo, este escenario es el más difícil de encontrar en una implementación real, por lo que se ilustrará a continuación, los distintos escenarios en los que se implementa el control por Internet.

Figura 4 Independencia del servidor de aplicaciones

El escenario que se muestra en la Figura 4, logra independizar el servidor de aplicaciones, esto se acerca más a la realidad ya que de esta manera el servidor de aplicaciones está ubicado mayormente cerca al proceso y el servidor Web se ubica en una sala de servidores. Los requerimientos para el servidor Web son los mismos que para el caso anterior y los requerimientos para el servidor de aplicaciones son disponer de un nombre netBios y tener abierto el puerto 1801 UDP/TCP.

Figura 5 Independencia del servidor web

El escenario mostrado en la Figura 5 es un escenario más real en el que se separa el servidor Web del servidor de MSMQ, esta división es necesaria porque normalmente nos vamos a encontrar con que no tenemos acceso al servidor Web ya sea porque pertenece a otra empresa o por políticas de nuestra misma empresa. En este caso el servidor Web debe enviar los mensajes a nuestro servidor MSMQ, es acá donde surge un problema, puesto que para enviar un mensaje se utiliza la dirección netBios del equipo y en el caso de un equipo remoto la dirección netBios no es resuelta. Para solucionar este problema MSMQ dispone del componente de integración con HTTP, de esta manera es posible enviar mensajes a través de Internet con el protocolo HTTP y utilizar el puerto 80 sin comprometer la seguridad de nuestra red.

3. Conclusión

MSMQ es un servicio de Windows Server que permite la comunicación de aplicaciones de arquitectura distribuida. Brinda una solución interesante, limpia y elegante a la interoperabilidad entre el servidor Web y el servidor de aplicaciones y por consecuencia al desarrollo de sistemas de control por Internet. Hay que señalar que todavía hay cosas en las cuales se debe profundizar como son: la integración de MSMQ con Active Directory, la operación de MSMQ en el camino de regreso, la operación de MSMQ en base a transacciones así como su implementación robaste en escenarios críticos. Así pues esto es sólo un paso más en un largo camino por andar.

4. Referencias

Información sobre WSH
http://www.devguru.com/Technologies/wsh/quickref/wsh_intro.html
Envío de mensajes MSMQ com VB.Net.
http://dotnet247.com/247reference/msgs/14/73719.aspx
Envío de mensajes MSMQ a través de http con VB6.0
http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art14.asp
MSMQ y soporte nativo en Windows
http://www.codeproject.com/w2k/msmq.asp
Puertos de los servicios de Windows
http://www.aspdeveloper.net/tiki-index.php?page= FirewallMicrosoftKB832017
Sitio oficial de MSMQ
http://www.microsoft.com/windowsserver2003/technologies/msmq/default.mspx