Instituto tecnológico superior de Cintalapa
Programación en ambiente cliente/servidor
Investigación COM/DCOM (Component Object Model/
Distributed COM)
Luis German Montesinos
Juan Ignacio Zamora Chacón
Ing. Informática
Grupo: E Semestre: 7°
Cintalapa de Figueroa, Chiapas, México a 02 de noviembre del 2021
Introducción
En las siguientes paginas encontraremos la investigación de los temas de la unidad
4 de la asignatura de programación en ambiente cliente/servidor. En esta unidad
veremos los temas de COM (Component Object Model) y DCOM (Distributed COM),
entre los temas a tocar en esta investigación están la creación de un servidor COM,
un cliente COM, que es DCOM, etc.
A continuación, se encuentra la investigación de los temas antes mencionados con
el fin de conocer mas sobres estos, los cuales nos permitirá hacer uso del COM.
4.1. Creación de Servidores COM.
Microsoft Distributed COM (Component Object Model) sirve para soportar
comunicación entre objetos en ordenadores distintos, en una LAN, WAN, o incluso
en Internet.
DCOM es una extensión de COM, y éste define como los componentes y sus
clientes interactúan entre sí. Esta interacción es definida de tal manera que el cliente
y el componente pueden conectar sin la necesidad de un sistema intermedio. El
cliente llama a los métodos del componente sin tener que preocuparse de niveles
más complejos.
DCOM es una evolución lógica de COM, se pueden utilizar los componentes
creados en aplicaciones basadas en COM, y trasladarlas a entornos distribuidos.
DCOM maneja detales muy bajos de protocolos de red, por lo que uno se puede
centrar en la realidad de los negocios: proporcionar soluciones a clientes.
Servidor
Es una aplicación que ofrece un servicio a usuarios de Internet, el servidor es un
programa que recibe una solicitud, realiza el servicio requerido y devuelve los
resultados en forma de una respuesta. Generalmente un servidor puede tratar
múltiples peticiones (múltiples clientes) al mismo tiempo.
Las funciones que lleva a cabo el proceso servidor se resumen en los siguientes
Puntos
• Aceptar los requerimientos de bases de datos que hacen los clientes.
• Procesar requerimientos de bases de datos.
• Formatear datos para trasmitirlos a los clientes.
• Procesar la lógica de la aplicación y realizar validaciones a nivel de bases de
datos.
El uso de los componentes COM es un claro ejemplo de la arquitectura
Cliente/Servidor. El objeto COM en sí es el servidor, y es usado por un programa
que hace de cliente. Existen varias formas de realizar la comunicación. Podemos
encontrar los componentes como partes de un ejecutable (como el caso de los
productos de Microsoft Office, o si implementamos nuestro propio componente y lo
incluimos con un programa que los use), dentro de una librería de enlace dinámico
(DLL) o incluso en otra máquina (DCOM).
Tipos de Servidores COM
Anteriormente hemos visto que existen varios tipos distintos de servidores COM.
Entre ellos están los objetos COM que se “alojan” en DLLs, los que se alojan en un
ejecutable y los que se alejan en otra máquina de una red. Vamos a ver el problema
de la comunicación entre cliente y servidor (para el paso de parámetros).
Servidores COM en dll
Esta es la forma más sencilla de funcionamiento del modelo COM. Cliente y Servidor
comparten un espacio de direcciones y un mapa de memoria. La carga del objeto
COM desde el DLL se hace de forma transparente al usuario. La comunicación se
puede realizar con el paso de parámetros normal fijado para una DLL (incluyendo
eso sí, como parámetros también, un puntero a la instancia del objeto).
Es el programa cliente el que realiza la creación de memoria para comenzar la
creación del objeto COM. Al entrar en ejecución el constructor del objeto, éste podría
realizar peticiones de memoria dinámica.
Servidores COM en exe
Son llamados servidores locales. Se ejecutan en el mismo ordenador que el cliente,
pero en procesos distintos. La comunicación la gestiona el sistema operativo. No
hace falta que esté el ejecutable del servidor funcionando, pues el sistema es capaz
de ejecutarlo. El “exe” contiene una parte que se encarga de la gestión de memoria
inicial que requieren los objetos COM.
Servidores COM remotos o DCOM
Cliente y servidor se encuentran en ordenadores distintos. La comunicación la
gestiona el sistema operativo. Internamente, Microsoft usa el protocolo RPC para
realizar la comunicación. Sin embargo, el programa servidor debe de estar
ejecutándose.
A la hora de la práctica, hay poca diferencia en la programación. Las funciones
miembros se llaman de la misma forma, los objetos se crean prácticamente igual
(en servidores remotos se usa la función CoCreateInstanceEx, la cual tiene un
parámetro que identifica al ordenador servidor). Pero, si los objetos se usan igual,
¿cómo se puede conseguir entonces el efecto de llamadas a función? Es decir,
¿cómo podría usarse?
4.2. Creación de un cliente COM.
El cliente es una aplicación informática o un ordenador que consume un servicio
remoto en otro ordenador conocido como servidor, normalmente a través de una
red de telecomunicaciones. También se puede definir un cliente es cualquier cosa
(que no sea un servidor) que se conecta a un servidor.
En los componentes COM no existe el concepto de herencia, para la reutilización
se utiliza:
COMPOSICION o AGREGACIÓN.
COMPOSICIÓN
•En la composición el objeto COM simplemente actúa a su vez como cliente del
objeto COM que contiene.
AGREGACIÓN
•Se expone directamente la interfaz del objeto COM agregado, de modo que el
cliente puede acceder de forma transparente a las interfaces de los dos objetos
COM.
COM+ es una ampliación al modelo de componentes COM para la construcción de
aplicaciones empresariales, se encarga de proporcionar una serie de servicios:
Seguridad de grano fino, controla el acceso a cada método.
Esca labilidad, mediante balanceo de carga y “object pooling”
Manejo de transacciones, a través de MTS(Microsoft Transactional server).
Implementación
Se va a construir un objeto COM capaz de almacenar la siguiente información
sobre un usuario:
Age -> short
Name -> LPSTR
Sex -> unsigned char
El objetivo es poner de manifiesto cuales son las tareas básicas de las que es
responsable todo objeto COM.
EJ: Tareas del COM
1. Crear los GUID’s necesarios para el objeto y sus interfaces
2. Definir las interfaces del objeto
3. Implementar las funciones de la interfaz definida
4. Registrar el servidor COM
EJ: Crear los GUID’s
•El API COM dispone del método CoCreateGuid que se encarga de esta tarea.
•Como parte de la distribución de VS se puede encontrar el programa
UUIUDGEN.exe para realizar esta tarea, aunque internamente sencillamente
llama al método del API anterior. Generamos los 3 GUID’s que vamos a necesitar:
C:>uuidgen -n3
acceeb00-86c7-11d0-94ab-0080c74c7e95 acceeb01-86c7-11d0-94ab-
0080c74c7e95 acceeb02-86c7-11d0-94ab-0080c74c7e95
EJ: Definir las Interfaces
•Definición de la interfaz IUserInfo import "unknwn.idl" ;
[ object, uuid(acceeb02-86c7-11d0-94ab-0080c74c7e95)
] interface IUserInfo : IUnknown
{
[propget] HRESULT Age([out, retval] short *nRetAge);
[propput]HRESULT Age([in] short nAge);
[propget]HRESULT Name([out, retval] LPSTR *lpszRetName);
[propput]HRESULT Name([in] LPSTR lpszName);
[propget]HRESULT Sex([out, retval] unsigned char *byRetSex);
[propput]HRESULT Sex([in] unsigned char bySex);
}
EJ: Definir las Interfaces
• Definición de la type library y del objeto UserInfo
[uuid(acceeb00-86c7-11d0-94ab-0080c74c7e95),version(1.0)]
library UserInfo
{
[uuid(acceeb01-86c7-11d0-94ab-0080c74c7e95),]
coclass UserInfo
{
[default] interface IUserInfo;
}
}
•Las interfaces en IDL creadas las compilamos a través de MIDL (incluido en VS) y
se obtienen los siguientes ficheros:
•Contenido de UserInfo_i.c
const IID IID_IUserInfo = {0xacceeb02,0x86c7,0x11d0,
{0x94,0xab,0x00,0x80,0xc7,0x4c,0x7e,0x95}};
const CLSID CLSID_UserInfo = {0xacceeb01,0x86c7,0x11d0,
{0x94,0xab,0x00,0x80,0xc7,0x4c,0x7e,0x95}};
const IID LIBID_UserInfo =
{0xacceeb00,0x86c7,0x11d0,
{0x94,0xab,0x00,0x80,0xc7,0x4c,0x7e,0x95}};
• Contenido de UserInfo_i.h
Este fichero contiene las cabeceras del interfaz tanto en C como en C++
La interfaz en C++ se declara como una clase abstracta con todos sus métodos
virtuales puros, de esta manera se fuerza a quien implemente la interfaz a
implementar todos sus métodos.
class IUserInfo {
public: virtual QueryInterface(REFIID iid, LPVOID *ppv) = 0; .............}
class CUserInfo : IUserInfo { private: ULONG m_cRef; private: short m_nAge;
private: LPSTR m_lpszName; private: BYTE m_bySex;
public: STDMETHODIMP QueryInterface(REFIID iid, LPVOID *ppv); public:
STDMETHODIMP_(ULONG)AddRef(void); public:
STDMETHODIMP_(ULONG)Release(void); public: STDMETHODIMP
get_Age(short *nRetAge); public: STDMETHODIMP put_Age(short nAge); public:
STDMETHODIMP get_Name(LPSTR *lpszRetName); public: STDMETHODIMP
put_Name(LPSTR lpszname); public: STDMETHODIMP get_Sex(BYTE
*byRetSex); public: STDMETHODIMP put_Sex(BYTE bySex);
CUserInfo();
~CUserInfo(); };
•Implementación del método QueryInterface
STDMETHODIMP CUserInfo::QueryInterface(REFIID iid, LPVOID *ppv)
{
*ppv = NULL; if (IID_IUnknown == iid) *ppv = (LPVOID)(IUnknown *)this; else if
(IID_IUserInfo == iid) *ppv = (LPVOID)(IUserInfo *)this; else
return E_NOINTERFACE; //Interface not supported
((IUnknown *)*ppv)->AddRef(); return NOERROR;
}
•Implementación del método AddRef
STDMETHODIMP_(ULONG) CUserInfo::AddRef(void)
{ return ++m_cRef;
}
•Implementación del método Release
STDMETHODIMP_(ULONG)CUserInfo::Release(void)
{ m_cRef-; if (0 == m_cRef)
{ delete this; g_cObjects-; if (::ServerCanUnloadNow())
::UnloadServer(); return 0;
} return m_cRef;
}
Una vez implementados los métodos de la interfaz Iunknow simplemente restaría
implementar el resto de métodos de la clase CUserInfo, los que corresponden a la
interfaz IUserInfo.
La implementación de estos métodos es trivial, consiste únicamente en establecer
y devolver los valores de las propiedades definidas para contener el sexo, nombre
y edad del usuario.
EJ: Registrar el servidor COM
•La información sobre el objeto COM debe estar en el registro de windows para
que los clientes puedan localizarlo, la especificación COM define que las dll’s que
contengan objetos COM deben implementar los siguientes métodos para esta
tarea:
DllRegisterServer – En esta función se escribirá la información necesaria en el
registro para que luego se pueda localizar el servidor COM.
DllUnregisterServer – Esta función es la encargada de borrar la información sobre
el COM escrita en el registro.
EJ: Registrar el servidor COM
•La información que se debe almacenar en el registro sobre el servidor COM es la
siguiente:
HKEY_CLASSES_ROOT CLSID
{acceeb01-86c7-11d0-94ab0080c74c7e95} = Description
InprocServer32
C:\UserInfo\UserInfo.dll
•Los programas como Regsrv32.exe que se utilizan para registrar objetos COM
simplemente cargan la dll y
invocan el método DllRegisterServer
EJ: Creación de un cliente
•El cliente debe realizar las siguientes tareas:
Iniciar la librería COM
Obtener la interfaz
Manipular el objeto a través de su interfaz
Liberar las interfaces
Finalizar la librería COM
EJ: Iniciar la librería COM
•Para iniciar la librería COM hay que llamar al método del API COM CoInitialize:
hr = CoInitialize(NULL); if ( SUCCEEDED(hr) )
{ ...}
•El método CoInitialize inicializa la librería en el thread de ejecución desde el que
se invoque. Es necesario llamar a CoInitialize desde cada thread de la aplicación
que quiera acceder a objetos COM.
EJ: Obtener la interfaz
•Para obtener la interfaz inicial llamamos al método CoCreateInstance, este creará
una nueva instancia de un objeto COM y nos devolverá un puntero a su interfaz.
IUnknown *pIUnknown = NULL; hr = CoCreateInstance(CLSID_UserInfo, NULL,
CLSCTX_INPROC_SERVER, IID_IUnknown,
(LPVOID *)&pIUnknown);
if (SUCCEEDED(hr))
{....}
EJ: Obtener la interfaz
• A través del puntero a IUnknow obtener el puntero a la interfaz IUserInfo
hr = pIUnknown->QueryInterface (IID-IUserInfo,
(LPVOID *)&pIUserInfo); if (SUCCEEDED(hr))
{\\manipulación del objeto}
EJ: liberar las interfaces
•Para liberar las interfaces hay que llamar al método Release, si el objeto COM no
tiene más interfaces referenciadas se borrara automaticamente:
pIUserInfo->Release(); pIUnknown->Release();
EJ: Finalizar la librería COM
•La librería COM se finaliza a través del método CoUninitialize, una vez llamado a
Este método no se podrá seguir llamando a funciones de la librería COM ni
manipulando objetos COM.
4.3. Automatización.
Es un mecanismo formal de comunicación entre procesos basado en COM.
Facilita:
Una infraestructura que permite que aplicaciones llamadas automation controllers
para que puedan acceder, manipular y compartir automation objects (por ejemplo,
propiedades o métodos de otras aplicaciones).
El controlador es el "cliente" y, la aplicación que exporta los objetos de
automatización, el servidor.
Los componentes COM se pueden agrupar básicamente en tres categorías.
$ In-Process
$ Locales
$ Remotos
Los componentes In-Process se cargan en el mismo espacio de procesos que la
aplicación cliente. Estos componentes se implementan como librerías dinámicas
(DLL) por lo cual se minimiza el tiempo requerido para la invocación de los métodos.
Por otra parte, como el componente comparte el espacio de direcciones de la
aplicación, una falla en el componente puede causar daños en la aplicación. Los
componentes In-Process no son programas ejecutables, por lo tanto solo pueden
usarse en el contexto de un programa que los invoca. Los controles ActiveX son
componentes In-Process.
Los componentes locales se ejecutan en un proceso separado en el mismo
computador mientras que los componentes remotos se ejecutan en otro
computador. La aplicación cliente no necesita saber dónde reside el componente.
Cuando el componente es remoto, DCOM crea un proxy que intercepta las
referencias a la interface del objeto y luego usa RPC para ejecutar la instancia “real”
del objeto.
4.4. ATL (Active Template Library).
El Active Témplate Library (ATL) es un conjunto de clases basadas en plantillas de
C ++ clases desarrolladas por Microsoft, destinado a simplificar la programación del
Modelo de objetos componentes (COM) de objetos.
Es un conjunto de clases de C++ basadas en plantillas que permiten crear objetos
pequeños, rápidos (COM) del modelo de objetos componentes.
El apoyo COM en Microsoft Visual C ++ permite a los desarrolladores crear una
variedad de objetos COM, OLE Automation servidores y ActiveX controles.
ATL incluye un asistente de objeto que establece la estructura primaria de los
objetos muy rápidamente con un mínimo de codificación manual.
En el lado del cliente COM ATL proporciona punteros inteligentes que tienen que
ver con el recuento de referencias COM.
Historia
ATL versión7 introdujo atributos en C ++ en un intento de ofrecer algo similar a los
atributos de la CLI, no han tenido mucho éxito, y se han restado importancia en la
versión de ATL 8 (Visual Studio 2005). La versión7 introduce nuevas clases de
conversión de cadenas.
El 28 de julio de 2009, Microsoft lanzó un parche para ATL para corregir un error
que podría permitir ActiveX controles creados con ATL a ser vulnerable a una falla
de seguridad de ejecución remota de código.
Desde Visual Studio 2013, código de ATL en Visual C ++ 2013 es estática, lo que
elimina la DLL.
Clases de apoyo
ATL incluye muchas RAII clases para simplificar la gestión de tipos COM.
Las clases más comúnmente utilizados son:
•CComPtr <T> de propósito general Smart-puntero,
•CComBSTR envoltorio BSTR,
•CComVariant envoltorio VARIANTE, y
•CComSafeArray <T> envoltorio SAFEARRAY.
Apoyo Compiler COM
Aunque no es formalmente parte de ATL, Microsoft Visual C ++ también incluye
adicional de C ++ clases RAII para simplificar la gestión de tipos COM.
Estos apoyo compilador COM clases pueden ser utilizados como reemplazo para o
en combinación con ATL, e incluye:
_com_ptr_t smart-puntero que decora el nombre de la interfaz COM con un sufijo
"PTR",
_bstr_t envoltorio BSTR,
_variant_t envoltorio VARIANTE, y
_com_error envoltorio HRESULT.
Tenga en cuenta que a partir de Visual Studio 2012, las clases de apoyo
compilador COM no incluye una envoltura SAFEARRAY.
4.5. DCOM (Distributed COM).
El Modelo de Objetos de Componentes Distribuidos (Distributed Component Object
Model, DCOM) es una tecnología propietaria de Microsoft para desarrollar
componentes de software distribuidos sobre varias computadoras y que se
comunican entre sí.
Con DCOM una aplicación puede ser distribuida en lugares que dan más sentido al
cliente y a la aplicación.
Como DCOM es una evolución lógica de COM, se pueden utilizar los componentes
creados en aplicaciones basadas en COM, y trasladarlas a entornos distribuidos.
DCOM maneja detalles muy bajos de protocolos de red, por lo que uno se puede
centrar en la realidad de los negocios.
Actualmente DCOM viene con los sistemas operativos Windows 2000, NT, 98 y
también está disponible una versión para Windows 95 en la página de Microsoft.
También hay una implementación de DCOM para Apple Macintosh y se está
trabajando en implementaciones para plataformas UNIX como Solaris.
1.1 La arquitectura DCOM
DCOM es una extensión de COM, y éste define como los componentes y sus
clientes interactúan entre sí. Esta interacción es definida de tal manera que el cliente
y el componente pueden conectar sin la necesidad de un sistema intermedio.
El cliente llama a los métodos del componente sin tener que preocuparse de niveles
más complejos.
En los actuales sistemas operativos, los procesos están separados unos de otros.
Un cliente que necesita comunicarse con un componente en otro proceso no
puede llamarlo directamente, y tendrá que utilizar alguna forma de comunicación
entre procesos que proporcione el sistema operativo. COM proporciona este tipo
de comunicación de una forma transparente: intercepta las llamadas del cliente y
las reenvía al componente que está en otro proceso. La siguiente figura ilustra
como las librerías de COM/DCOM proporcionan la forma de comunicar el cliente y
el componente:
Cuando el cliente y el componente residen en distintas máquinas, DCOM
simplemente reemplaza la comunicación entre procesos locales por un protocolo
de red. Ni el cliente ni el componente se enteran de que la unión que los conecta
es ahora un poco más grande.
La Figura 3 representa la arquitectura DCOM en su conjunto: Las librería de COM
proporcionan servicios orientados a objetos a los clientes y componentes, y
utilizan RPC y un proveedor de seguridad para generar paquetes de red estándar
que entienda el protocolo estándar de DCOM.
1.2 Los Componentes y su reutilización
DCOM toma ventaja de forma directa y transparente de los componentes COM y
herramientas ya existentes. Muchos desarrolladores están familiarizados con COM
y pueden aplicar fácilmente sus conocimientos a las aplicaciones distribuidas
basadas en DCOM.
Cualquier componente que sea desarrollado como una parte de una aplicación
distribuida es un candidato para ser reutilizado.
Diseñando para COM y DCOM se asegura que los componentes creados serán
útiles ahora y en el futuro.
1.3 Independencia de la localización
Cuando se comienza a implementar una aplicación distribuida en una red
aparecen distintos conflictos en el diseño:
Los componentes que interactúan más a menudo deberían estar localizados más
cerca.
Algunos componentes solo pueden ser ejecutados en máquinas específicas o
lugares específicos.
Los componentes más pequeños aumentan la flexibilidad, pero aumentan el tráfico
de red.
Los componentes grandes reducen el tráfico de red, pero también reducen la
flexibilidad.
Con DCOM, estos temas críticos de diseño pueden ser tratados se forma bastante
sencilla, ya que estos detalles no se especifican en el código fuente. DCOM olvida
completamente la localización de los componentes, ya esté en el mismo proceso
que el cliente o en una máquina en cualquier lugar del mundo. En cualquier caso,
la forma en la que el cliente se conecta a un componente y llama a los métodos de
éste es identica. No es solo que DCOM no necesite cambios en el código fuente,
sino que además no necesita que el programa sea recompilado. Una simple
reconfiguración cambia la forma en la que los componentes se conectan entre sí.
La independencia de localización en DCOM simplifica enormemente las tareas de
los componentes de aplicaciones distribuidas para alcanzar un nivel de
funcionamiento óptimo.
Con la independencia de localización de DCOM, la aplicación puede combinar
componentes relacionados en máquinas "cercanas" entre si, en una sola máquina
o incluso en el mismo proceso. Incluso si un gran número de pequeños
componentes implementan la funcionalidad de un gran módulo lógico, podrán
interactuar eficientemente entre ellos.
1.4 Independencia del lenguaje de programación
Una cuestión importante durante el diseño e implementación de una aplicación
distribuida es la elección del lenguaje o herramienta de programación. La elección
es generalmente un término medio entre el costo de desarrollo, la experiencia
disponible y la funcionalidad. Como una extensión de COM, DCOM es
completamente independiente del lenguaje. Virtualmente cualquier lenguaje puede
ser utilizado para crear componentes COM, y estos componentes puede ser
utilizado por muchos más lenguajes y herramientas. Java, Microsoft Visual C++,
Microsoft Visual Basic, Delphi, PowerBuilder, y Micro Focus COBOL interactúan
perfectamente con DCOM.
1.5 Independencia del protocolo
Muchas aplicaciones distribuidas tienen que ser integradas en la infraestructura de
una red existente. Necesitar un protocolo específico de red, obligará a mejorar
todos los cliente, lo que es inaceptable en muchas situaciones. Los
desarrolladores de aplicaciones tienen que tener cuidado de mantener la
aplicación lo más independiente posible de la infraestructura de la red.
DCOM proporciona esta transparencia: DCOM puede utilizar cualquier protocolo
de transporte, como TCP/IP, UDP, IPX/SPX y NetBIOS. DCOM proporciona un
marco de seguridad a todos estos protocolos.
Los desarrolladores pueden simplemente utilizar las características
proporcionadas por DCOM y asegurar que sus aplicaciones son completamente
independientes del protocolo.
La Figura 4 representa como un "componente de validación" puede ser situado en
la misma máquina, cuando el ancho de red entre la máquina "cliente" y la máquina
"middle-tier" es suficiente, y en la máquina "servidor", cuando el cliente accede a
la aplicación a través de una red lenta.
Con la independencia de localización de DCOM, la aplicación puede combinar
componentes relacionados en máquinas "cercanas" entre si, en una sola máquina
o incluso en el mismo proceso. Incluso si un gran número de pequeños
componentes implementan la funcionalidad de un gran módulo lógico, podrán
interactuar eficientemente entre ellos.
Conclusión
El COM (Component Object Model) se pueden utilizar los componentes creados en
aplicaciones basadas en COM y trasladarlas a entornos distribuidos como DCOM
(Distributed COM))ya que maneja muy bajos protocolos, en la creación de cliente
COM se debe de realizar ciertos pasos para crearlo como son iniciar con la librería
COM, obtener la interfaz, manipular el objeto a través de su interfaz, liberar las
interfaces y finalizar la librería COM.
Bibliografía
Charte., F. (s.f.). Programación avanzada en Windows. Anaya Multimedia (ISBN
84-415-0832-1 ).
Abu-Hijleh, W. K. (2000). Implementation of client/server applications using the
Component Object Model. California State University, Long Beach.
Emmerich, W., & Kaveh, N. (2001, September). Component technologies: Java
beans, COM, CORBA, RMI, EJB and the CORBA component model. In
Proceedings of the 8th European software engineering conference held jointly with
9th ACM SIGSOFT international symposium on Foundations of software
engineering (pp. 311-312).
