Este documento describe DCOM (Modelo de Objetos de Componentes Distribuidos), una tecnología propietaria de Microsoft que extiende el modelo COM para permitir que los componentes de software se comuniquen entre máquinas a través de una red. DCOM maneja los detalles de la comunicación entre procesos y máquinas de forma transparente para el desarrollador. Esto permite la reutilización de componentes COM existentes en aplicaciones distribuidas y la independencia de la localización, lenguaje de programación y protocolo de red.
3. DCOM/COM
• Modelo de Objetos de Componentes Distribuidos .Es una tecnología
propietaria de Microsoft para desarrollar componentes software distribuidos
sobre varios ordenadores y que se comunican entre sí. Extiende el modelo
COM de Microsoft y proporciona el sustrato de comunicación entre la
infraestructura del servidor de aplicaciones COM+ de Microsoft. Ha sido
abandonada en favor del framework .NET.
4. DCOM/COM
• La adición de la "D" a COM fue debido al uso extensivo de DCE/RPC(llamada a
procedimiento remoto ), o más específicamente la versión mejorada de Microsoft,
conocida como MSRPC.
• En términos de las extensiones que añade a COM, DCOM tenía que resolver los
problemas de
• Aplanamiento - Serializar y deserializar los argumentos y valores de retorno de las
llamadas a los métodos "sobre el cable".
• Recolección de basura distribuida, asegurándose que las referencias mantenidas por
clientes de las interfaces sean liberadas cuando, por ejemplo, el proceso cliente ha
caído o la conexión de red se pierde.
5. • En el contexto del Component Object Model (y
derivados) se refiere a la capacidad de poder crear componentes COM que
tengan la capacidad de ser usados sin necesidad de conocer los nombres y
parámetros de los métodos, de antemano. Esto sirve para que lenguajes
como Visual Basic o los de scripting (VBScript, JScript) puedan invocar
estos componentes mediante un valor numérico (algo así como "método
uno", "método dos", etc). Esto se logra mediante los archivos idl/odl y
la implementación de la interfaz IDispatch.
6. *Cuando un componente tiene un subproceso de ejecución, se puede ejecutar
el código fuente de un solo objeto a la vez.
*La característica de automatización del Modelo de objetos componentes
(Component Object Model, COM) controla esta situación mediante
la serialización de las peticiones. Es decir, las peticiones se sitúan en una cola y
se procesan una por una hasta terminar todas.
*En un entorno operativo de subprocesamiento múltiple, la serialización evita
que los objetos de un solo subproceso se superpongan a las peticiones de
clientes: es decir, que se ejecute el código de una propiedad o método mientras
se esté ejecutando una o varias peticiones de clientes.
7. • *. La superposición de las peticiones puede causar errores internos de datos si
los objetos no están diseñados para reentrada.
• Por lo tanto, la serialización es una característica muy importante de la
automatización. No obstante, la serialización de componentes de un solo
subproceso implica que, algunas veces, las peticiones se bloquean.
• Cuando las operaciones largas bloquean otras cortas, la productividad
disminuye y la frustración del usuario aumenta. Los componentes que se
comportan de esta manera se denominan poco escalables. Es decir, no
funcionan bien si se realizan muchas peticiones de diferente duración.
9. ATL (ACTIVE TÉMPLATE 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.
10. 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.
11. 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
12. 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.
13. 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 [ 1envoltorio HRESULT.
Tenga en cuenta que a partir de Visual Studio 2012, las clases de apoyo compilador COM no incluye una envoltura SAFEARRAY
15. • Para soportar comunicación entre objetos en ordenadores distintos, en una LAN, WAN, o incluso en
Internet. Con DCOM una aplicación puede ser distribuida en lugares que dan más sentido al cliente y a
la aplicación.
16. • 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.
17. ARQUITECTURA 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 puede 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.
18. • 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.
19. • 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 Figura 2 ilustra como las librería de
COM/DCOM proporcionan la forma de comunicar el cliente y el componente.
20. • 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.
21. • 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.
22. COMPONENTES Y SU REUTILIZACIÓN
• Muchas aplicaciones distribuidas no están desarrolladas.
• DCOM toma ventaja directa y transparente de los componentes COM y herramientas ya existentes.
• Reducir el tiempo de desarrollo integrando soluciones estandarizadas en las aplicaciones de usuario.
23. INDEPENDENCIA DE LA LOCALIZACIÓN
• Cuando se comienza a implementar una aplicación distribuida en una red local, aparecen distintos
conflictos en el diseño.
• Los componentes que interactuan más a menudo deberian estar localizados más cerca.
• Algunos componentes solo pueden ser ejecutados en máquinas específicas o lugares específicos.
24. • 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.
25. • La independencia de localización en DCOM simplifica enormemente las tarea 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.
26. INDEPENDENCIA DEL LENGUAJE DE PROGRAMACIÓN
• Como una extensión de COM, DCOM es completamente independiente del lenguaje. Virtualmentem
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 interactuan perfectamente con DCOM.
27. INDEPENDENCIA DEL PROTOCOLO
• 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 independiente del protocolo.
