tutorial implementar habilitar deploy wcf com components

wcf - implementar - ¿COM está muerto?



wcf in iis (6)

Depende de qué tan profundo en el sistema quieras cavar. COM nunca ''morirá'', lo mismo que los lenguajes no administrados nunca lo harán.

Para resumir, si desarrolla aplicaciones de escritorio para Vista +, probablemente ya no necesitará molestarse en usar COM.

¿Cuáles son las ventajas profundas que se obtienen al usar COM para desarrollar componentes en WCF? ¿Hay algo que se pueda hacer con COM y no con WCF?

No creo que COM esté muerto. Si nos fijamos en Vista, utiliza gran parte de la arquitectura / tecnología COM. Todo en Vista es un COM Dll / Exe. Siento que en comparación con XP, Vista usa mucho de COM.

Si queremos extender cualquier cosa en Vista, debemos implementar interfaces usando COM.

No, aún no está muerto, pero está en su lecho de muerte, eso es seguro. Usted ve que todavía hay muchos sistemas heredados que usan / requieren COM, eso nos asegura que estará con nosotros por unos años más, pero no a largo plazo.

En cuanto a WCF, puede haber algunos casos extremos de cosas que COM puede hacer, y WCF no, pero lo más importante, y relacionado con cosas heredadas, es que hay enlaces COM para casi todos los idiomas que puedes poner en una pila de Windows, pero las vinculaciones de WCF aún no están listas para todos (idiomas)

Si no me equivoco, .NET pretende reemplazar tecnología como COM y WFC. ¿Hay alguna razón (que no sea el código heredado) para elegir COM o WFC sobre .NET?

Hay varios aspectos distintos:

  1. Componentes que se ejecutarán e interactuarán con varias computadoras (como servicios)
  2. Componentes que solo se ejecutan localmente e interactúan con componentes implementados por múltiples proveedores a través de un ABI.
  3. Componentes que son creados por un único proveedor sin necesidad de interactuar con componentes de terceros.
  4. Componentes de múltiples proveedores que están disponibles en el código fuente, que se pueden compilar en una sola aplicación.

(ABI = interfaz binaria de la aplicación. COM es un ejemplo de ABI).

Para el aspecto 1, COM está prácticamente muerto.

El aspecto 2 aún requiere COM, y seguirá siéndolo. Windows Imaging Component es un gran ejemplo de tal extensibilidad que permite a cualquier persona implementar nuevos códecs de imágenes. .Net es un fuerte contendiente en este aspecto.

Para el aspecto 3, COM todavía vale la pena considerarlo, pero esta es una decisión que debe tomarse para cada proveedor de software. El desarrollador de componentes para uso interno puede algún día venderse como un producto. .Net parece ser una buena opción aquí también.

Para el aspecto 4, uno simplemente puede adaptar y combinar los códigos fuente de muchos proyectos de código abierto. No hay necesidad de COM, o cualquier ABI.

COM como un ABI no administrado es, desafortunadamente, difícil de defender contra errores porque el código y los datos están en el mismo espacio de memoria, y la pila se usa tanto para datos como para la pila de llamadas de ejecución. Cualquier agujero explotable en un componente COM se puede usar para causar inestabilidad en cualquier otro componente COM cargado en el mismo espacio de direcciones.