Bye, bye COM

La tecnología Component Object Model (COM) de Microsoft hace años que prácticamente no la uso, más que de forma escondida. En la situación actual de .NET y otras herramientas, no parece hacer falta más. Pero como por una década a todos nos enseñaron sobre componentes COM distribuidos, y stateless y stateful, y transacciones requeridas, y esas cosas (como Apartment Threading Model, algo que sólo existe en el universo donde un runtime de Visual Basic no es reentrante), creo interesante poner algunos puntos de la situación actual. No soy un experto en todo COM, pero recuerdo haber devorado su implementación, y la curiosa IUnknown, que fue una solución pragmática a la diversidad de lenguajes, a la resolución de binding en runtime, y la necesidad de comunicar programas:

- COM Surge de OLE, y éste de DDE, que a su vez nacen de Office y el embebido de documentos en otros documentos, para tener componentes que binariamente, sin dependencia de lenguaje y de otros temas, se puedan comunicar entre si, como cajas negras, mediante una interfaz bien definida, o descubrible en runtime.

- Aparecen componentes COM visibles, luego llamados ActiveX Controls, que cumplen una serie de interfaces para poder ser albergados en cualquier contenedor de ActiveX controls, como el Visual Basic clásico.

- Aparecio COM distribuido, con los conceptos de tener marcados los metodos o componentes, para manejar transacciones (Required, Required New….) Habrán visto aparecer también esos conceptos en J2EE y otros lados, en los noventa del siglo pasado.

- Pero la realidad, es que hoy por hoy, todo se puede hacer sin COM, incluso el manejo de transacciones. En .NET 1.x dependiamos de System.Enterprise (no recuerdo el namespace) que interactuaba con COM, pero con .NET 2, practicamente no se necesita COM (nada más en lo de más abajo, sin verlo directamente).

- Los componentes visuales ahora son .NET, y hay varias empresas que migraron sus ActiveX controls a .NET “puro”, desde hace años.

- El manejo de transacciones ahora esta en System.Transaction (muy interesante que haya transacciones en objetos, y que tus objetos puedan tener un “rollback”)

- El manejo de threads es hermoso en .NET …. a la Java… ;-)

- El manejo de comunicacion distribuida, con seguridad y demas, esta en manos de Windows Communication Foundation, o por lo menos, con Web Services o Remoting (este ultimo se le esta “soltando la mano” de parte de MS, todo esta puesto en WCF).

- La necesidad de registrar el componente en el Registry, y solamente una versión del componente, ha conseguido crear el infierno de las DLL (DLL Hell), que en .NET es prácticamente inexistente.

Asi que, de alguna manera, COM no es indispensable. Puedo hacer todo lo de COM con esto que fue apareciendo con el tiempo.

Aunque se recomienda tomar con pinzas lo que aparece en Wikipedia, leemos ahí sobre COM:

The COM platform has largely been superseded by the Microsoft .NET initiative, and Microsoft now focuses its marketing efforts on .NET. COM was often used to hook up complex, high performance code to front end code implemented in Visual Basic or ASP.

To some extent, COM is now deprecated in favor of .NET. Since .NET provides rapid development tools similar to Visual Basic for both Windows Forms and Web Forms with just-in-time compilation, back-end code can be implemented in any .NET Language including C#, Visual Basic and C++.

Le dan algo de esperanza:

Despite this, COM remains a viable technology with an important software base. As of this writing, Microsoft has no plans for discontinuing either COM or support for COM. It is also ideal for script control of applications such as Office or Internet Explorer since it provides an interface for calling COM object methods from a script rather than requiring knowing the API at compile time. The GUID system developed for COM has wide uses any time a unique ID is needed.

Información sobre COM en Microsoft:

http://www.microsoft.com/com/default.mspx

Seguiremos teniendo COM en varios programas de Microsoft, pero no parece haber necesidad de incorporarlos en nuestros propios desarrollos.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com/

This entry was posted in 1389, 3463. Bookmark the permalink.

2 Responses to Bye, bye COM

  1. b52.NET says:

    Que tiempos aquellos! En los que Billy Reynoso defendía el Visual Basic a muerte… nos decian que no necesitabamos herencia, que podiamos usar aggregation!! Las eternas peleas con los programadores de Visual Fox que lo defendian porque ellos si tenian true-oop con herencia y todo!

    Y tambien me acuerdo de las VBX, las predecesoras de los OCX (ActiveX Controls)…

    Igual, todos los plug-in para IE y Office siguen usando COM, no entiendo que esperan para migrar todo eso a .NET!

  2. Fernando D. says:

    Hola Angel:

    Me gustan muchos tus artículos, y suelo leer tus feeds en Bloglines aunque todavía no me puse a estudiar .NET
    Todavía sigo programando en Microsoft Visual FoxPro y de vez en cuando uso algo de VBA para algunos temas de Office, así que no estoy “a la vanguardia” de los temas que tratás.
    Sobre este post de hoy te quería decir que me dejaste frío, ya que no sabía que COM no se usaba más “desde hace años”…
    Lo que te quería preguntar, entonces, es que tecnología se usa en lugar de COM+ para aplicaciones hechas con lenguajes no-.NET (Visual FoxPro, C++, automatización, Office, Delphi, y lenguajes para Windows en general) que deban interactuar con automatización o método similar, ya que no conozco un mecanismo más moderno que ese.

    Gracias y saludos desde el submundo

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>