30 junio, 2009

MAPI, introducción.


I.-) MAPI es una especificación de arquitectura que define un subsistema de mensajería.

II.-) La especificación incluye las definiciones de varios componentes externos, lo que hacen y las interfaces que exponen.

III.-) Estos componentes pueden ser implementados por cualquier vendedor, no sólo por Microsoft.

IV.-) Las interfaces entre componentes no son API's sino interfaces COM.

V.-) "Simple MAPI" (version 0) si es una librería. Contiene 12 funciones, pero "Extended MAPI" (version 1) es a lo nos referimos en esta introducción.

El subsistema MAPI está formado por el componente "MAPI run-time" y por el "spooler de mensajes". El "MAPI run-time" es una dll que contiene un conjunto de objetos basados en MAPI y API's usadas por los otros componentes. Estos objetos y API's incluyen interfaces o funciones para inicializar el subsistema MAPI, iniciar una sesión MAPI, gestionar la memoria o administrar perfiles. El spooler es un proceso independiente que gestiona el flujo de mensajes de entrada y salida del sistema.

Un Proveedor de servicios es una dll que devuelve interfaces a MAPI y al spooler. MAPI define tres proveedores principales de servicios, aunque hay algunos más:

- Proveedor de almacén de mensajes (Crear, submitir y almacenar mensajes).

- Proveedor de libreta de direcciones (Ver direcciones de correo de receptores).

- Proveedor de transporte (Manipular la transmisión física de los mensajes).

Un cliente, típicamente, es un proceso que requiere los servicios del subsistema MAPI para poder manipular los mensajes. Un cliente suele ser una aplicación de usuario final para crear, enviar y ver mensajes. Debe hacer "log on" a una sesión MAPI antes de poder solicitar servicios. El "logging on" da lugar a una instancia de cada proveedor de almacén o de libreta de direcciones (se ejecutan en el contexto del cliente). El "logging on" también inicia el spooler que carga e inicializa el proveedor de transporte (se ejecuta excusivamente en el contexto del spooler).

Un perfil es un nombre de lista de servicio de mensaje y datos de configuración creados por el usuario.

Un "servicio de mensaje" es un grupo de uno o más proveedores de servicio que extienden código común de configuración.

Una sesión es el periodo fijo de tiempo durante el que se realiza el trabajo, siendo trabajo en el contexto MAPI una serie de peticiones del cliente a MAPI y que son servidas por uno o más proveedores.

El componente "MAPI run-time" actúa como un broker entre clientes y proveedores de servicio y es integrado en el S.O. Windows como parte del subsistema de mensajería, gestiona directamente las interfaces entre el cliente y los proveedores de servicio. También implementa sus propias interfaces para crear y administrar perfiles, administrar una sesión, y acceder a múltiples proveedores de libreta de direcciones. Además proporciona un conjunto de API's para alocar y liberar memoria, manipular estructuras de datos MAPI, etc.

Un proveedor de almacén de mensajes es una dll que manipula una base de datos de mensajes. Está organizado como una jerarquía de carpetas y mensajes. Aunque la dll de almacén de mensajes se ejecuta en el contexto del cliente y es local en la máquina del usuario la base de datos accedida puede ser local o estar situada en el servidor.

Una "lista de distribuciones" es un tipo especial de contenedor que permite a un grupo de receptores ser direccionados como receptor sencillo, una copia del mensaje es enviada a cada miembro de la lista de distribución. Al igual que los proveedores de almacén de mensajes, los proveedores de libreta de direcciones pueden ser locales o estar situados en el servidor. Estos últimos contienen listas de direcciones globales, mientras que los proveedores locales de libreta de direcciones son habitualmente PAB's (formados frecuentemente por entradas creadas por el usuario).

El trabajo del "proveedor de transporte" es aceptar un mensaje de salida, traducirlo en una cascada de bytes que entienda el sistema subyacente y transmitirlo mediante el sistema de mensajería. Los mensajes entrantes llegan al proveedor de transporte desde el sistema de mensajería, son codificados en un mensaje MAPI y manipulados hacia el spooler para entregarse al proveedor de almacen de mensajes. El sistema de mensajería subyacente hacia el que se conecta el proveedor de transporte dictamina qué protocolo usa el proveedor para establecer y mantener la conexión. Algunos protocolos son propietarios como el de "Micorosft Mail Post Offices", y otros son estándares como el X400 o el SMTP.

El spooler MAPI es un proceso separado que forma parte del subsistema de mensajería. El proveedor de transporte se ejecuta únicamente en el contexto del spooler, el cliente no puede acceder directamente a los proveedores de transporte para solicitar servicios de entrega desde el sistema de mensajería externo. Dicha comunicación debe pasar a través del spooler que está separado del cliente, por tanto es a través del proveedor del almacén de mensajes como se carga una instancia en el contexto del cliente y del spooler. El es el que une ambos procesos.

23 junio, 2009

Modula-2 was created by Niklaus Wirth


Niklaus Wirth was born in February 1934 in Winterthur (Switzerland). He received the degree of Electronics Engineering from the Swiss Federal Institute of Technology (ETH) in Zurich in 1959, an M.Sc. from Laval University, Canada, in 1960. Then in 1963 he was awarded a Ph.D.in EECS from the University of California, Berkeley.

From 1963 to 1967 he served as assistant professor of Computer Science at Stanford University and again at the University of Zurich. Then in 1968 he became Professor of Informatics at ETH Zürich, taking a two year sabbatical at Xerox PARC in California.

Wirth was the chief designer of the programming languages Euler, Algol W, Pascal, Modula, Modula-2 and Oberon. He was also a major part of the design and implementation team for the Lilith and Oberon operating systems, and for the Lola digital hardware design and simulation system. He received the ACM Turing Award for the development of these languages and in 1994 he was inducted as a Fellow of the ACM.

His article Program Development by Stepwise Refinement, about the teaching of programming, is considered to be a classic text in software engineering. In 1975 he wrote the book
Algorithms + Data Structures = Programs, which gained wide recognition and is still useful today.

He is retired since April 1999.

Infolinks In Text Ads