Parece que hay mucha enemistad contra DCOM, y tengo curiosidad por comprender por qué. Para una empresa que todavía está escribiendo en Win32 SKD usando C++, ¿hay alguna razón real para no usar DCOM en el desarrollo actual o futuro? ¿Alguna versión futura de Windows no lo va a soportar? ¿Es demasiado frágil y no funciona a menudo? ¿Es demasiado complicado de implementar en comparación con otras tecnologías? ¿Cual es el trato?¿Qué pasa con DCOM?
Bueno, DCOM es una versión distribuida de COM y COM es muy complejo por sí mismo y es muy fácil hacer algo incorrecto involuntariamente (ver this recent question y la respuesta para ejemplos). Con DCOM solo tienes más formas de hacerte daño.
Aparte de eso, funciona y es, por ejemplo, una buena forma de alojar componentes COM en proc en un proceso separado.
De hecho, encuentro que COM es bastante comprensible y bastante simplista si entiende los punteros y los contadores de referencia. – Charles
Créame, las funciones de miembros desconocidas son solo el comienzo. Luego vienen apartamentos, concurrencia y otras cosas que pueden causar un dolor horrible. – sharptooth
Entonces, ¿qué recomendaría para un servicio local de win32 solo SDK y aplicación de cliente que necesita comunicarse? Sí DCOM es complicado, pero ¿qué tecnología no cumple estos requisitos? – Charles
Implementé un sistema grande usando DCOM a fines de los 90's. Aunque funcionó bastante bien, hubo un par de problemas. Para empezar, utiliza números de puerto impredecibles para la comunicación. No es escalable, y es mucho mejor usar WCF que DCOM.
Desafortunadamente, estamos confinados al SDK de Win32, no se permite .NET.Lo sé, lo sé, pero no establezco las reglas. – Charles
Aún así, creo que podrías usar servicios web. Estoy bastante seguro de que hay paquetes SOAP para C++. –
Si intenta crear una aplicación de servidor cliente y desea que la comunicación traspase los límites de la red (por ejemplo, Internet), entonces DCOM puede ser problemático debido a los cortafuegos.
Trabajé en una aplicación de servidor muy exitosa que se distribuyó utilizando DCOM, dejamos que el sistema maneje la mayor parte de la complejidad al crear aplicaciones COM + Server y exportar Application Proxies. En este caso, funcionó muy bien siempre que todas nuestras versiones estuvieran sincronizadas.
Olvidé mencionar que nuestro cliente y el servidor serían locales en la misma máquina, ambos escritos por nosotros y desplegados juntos, por lo que no hay problemas de red o sincronización. – Charles
Creo que el impulso se ha desplazado a SOAP y otras tecnologías de servicios web, ya que es:
I Nunca utilicé DCOM, así que no puedo comentar sobre su calidad general o estado físico.
Supongo que debería haber mencionado que mi uso sería para DCOM local, tanto cliente como servidor en la misma máquina. Convirtiendo todo en ASCII y luego envolviéndolo con más etiquetas ASCII, entonces el análisis del resultado ASCII es extremadamente ineficiente. – Charles
Ah, te escucho. Y sí, SOAP tiene sus propios problemas. – CBFraser
No me gusta COM/DCOM porque "Catastrophic failure" es el mensaje de error más inútil en el historial de mensajes de error.
Ese sería el mensaje de "sentirse bien" para el usuario. De esta forma, saben que lo están haciendo bien. – Jrud
ERROR_ALREADY_EXISTS para resumir. – ActiveTrayPrntrTagDataStrDrvr
Si solo desea desarrollar en C++ y desplegar en red controlada, aún puede ser una buena opción.
Los problemas de seguridad en los límites del sistema operativo local (cualquier cosa en otra máquina) no se pueden enfatizar lo suficiente. La "administración" de la seguridad DCOM es completamente imposible. (Y buena suerte tratando de localizar errores o interpretar mensajes de error). –
todo;) (Es una broma) –