Site Title

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í.

Es una extensión del modelo Component Object Model (COM) de Microsoft y proporciona el sustrato de comunicación entre la infraestructura del servidor de aplicaciones COM+ de Microsoft.

Características

1. DCOM es completamente independiente del lenguaje de programación. Debido a que cualquier lenguaje puede crear componentes COM, estos a su vez pueden interactuar perfectamente con DCOM.
2. Independencia de la localización. La aplicación que esté usando DCOM puede combinar componentes relacionados en máquinas “cercanas” entre si, en una sola máquina o incluso en el mismo proceso.
3. Independencia de protocolo. DCOM puede utilizar cualquier protocolo detransporte, como TCP/IP, UDP, IPX/SPX y NetBIOS, ya que proporciona un marco de seguridad a todos estos.

Ventajas

• Hay muchos libros, herramientas y desarrolladores.
• Existe una buena integración con Visual Basic y JAVA.
• Microsoft depende de su funcionamiento.

Desventajas

• Hay muy poco soporte en plataformas no-Windows.
• Dificultad para funcionar a través de “cortafuegos” y sobre máquinas inseguras o desconocidas.
• No existe una limpieza “pacífica” por lo que una referencia a un servicio se puede mantener en memoria, pese a que se haya terminado.

Comparación entre las Tecnologías DCOM y CORBA

Sus principales características son:

• El protocolo DCOM es usado para explotar las más severas vulnerabilidades, para tomar el control total del equipo afectado, incluyendo la instalación de programas; visualización, cambio o borrado de datos; o crear nuevas cuentas de usuario con todos los privilegios.
• Desde aplicaciones Java se puede invocar a los componentes DCOM.
• Los sistemas SCADA utilizan el componente DCOM para el acceso remoto a máquinas cliente.

Acá les dejo un video con los principales conceptos sobre DCOM

Fernando Mesta.

En este post revisaremos los conceptos básicos sobre los principios SOA.

Contratos de Servicio Estandarizados

Cada servicio debe establecer un contrato con el cliente donde se especifique: nombre del servicio, forma de acceso, funcionalidades, parámetros de entrada y salida. En caso de ser necesaria una modificación a la implementación del servicio, se debe respetar el contrato, por lo tanto se logra una independencia entre el cliente y la implementación del servicio.

Debe haber un bajo acoplamiento entre un servicio y los clientes que lo usan, esto se logra con los contratos, ya que estos esconden la lógica del servicio y garantizan una forma estándar de invocación, de modo que si se llega a cambiar la implementación del servicio, éste será el único punto de actualización, no será necesario modificar la forma en que los clientes hacen el llamado.

Reusabilidad de Servicios

La reutilización es el pilar de SOA, cada servicio debe ser pensado de modo que se pueda explotar al máximo su uso, es decir, que sea de algún modo genérico con el fin de que pueda ser usado en diferentes contextos y satisfacer distintos objetivos, este es el caso de los procesos de negocio donde cada uno de estos puede tener un propósito totalmente distinto del otro y aún así estar usando un mismo servicio.

Cada servicio SOA es mantenido, desarrollado, instalado y versionado de forma independiente. De esta forma el servicio es autónomo y podemos asegurar que podrá ser reutilizable desde el punto de vista de la plataforma de ejecución.

Los servicios no deben depender del estado de otros servicios, esta independencia garantiza la posibilidad de reutilización de estos en variados contextos. Para lograr esta independencia, un servicio no debe conservar información del cliente que lo usa, tan solo debe recibir en el mensaje de invocación los argumentos necesarios para llevar a cabo su tarea y dar una respuesta, sin dejar algún rastro de la información dentro del servicio.

Para garantizar la reutilización de los servicios y evitar realizar implementaciones de servicios ya existentes pero desconocidos, se debe proveer de algún método o herramienta que permita descubrirlos; UDDI (Universal Description Discovery and Integration) es un mecanismo y repositorio basado en XML que permite registrar web services, publicarlos y realizar consultas sobre sus contratos para poder interactuar con estos.

En la medida en que las soluciones orientadas a servicios crecen, así crece la complejidad de las mismas, Por esta razón Los servicios deben ser construidos para ser parte de servicios más complejos, a si mismo se necesita de conceptos como orquestación y coreografía para cumplir con el propósito del servicio compuesto.

Aquí les dejo un video sobre los conceptos y principios SOA.

Fernando Mesta.

La capacidad de poder responder rápidamente ante los constantes cambios en las reglas y optimización dentro de los procesos de negocio, forma parte de un factor fundamental dentro de la competitividad y crecimiento de las empresas.

Las arquitecturas SOA (Service Oriented Architecture), buscan separar las actividades de los procesos, en servicios independientes y con gobernabilidad, lo que permite una integración de distintas tecnologías en diferentes plataformas, fácilmente.

¿Que ganamos?

Al implementar una arquitectura SOA, ganamos gobernabilidad de las actividades de los procesos, es decir cada tarea del proceso (Si el análisis nos indica que esta es la solución) se expone como un servicio, lo cual indica que al cambiar la tecnología de alguno de ellos, no afecta a los demás ya que para el intercambio de información se hacen el uso de estándares, aun incluso si el proceso global cambia, las tareas se siguen comportando de la misma forma y solo se adaptan si el proceso lo requiere.

Imaginemos que en nuestro proceso tenemos una funcionalidad de alarmas la cual envió correos y mensajes de texto, esta funcionalidad esta a tres distintos sistemas de la empresa, ¿que pasaría si nuestro proveedor de correos cambia?, pues tendríamos que recompilar las tres aplicaciones añadiendo en cada una los cambios y las adecuaciones.

Si nuestros sistemas estuvieran en una arquitectura SOA, veríamos a la funcionalidad de alarmas, como un servicio, y todas nuestras aplicaciones se conectarían al mismo servicio, y un cambio en el proveedor de correos o de mensajes solo implicaría un cambio en el servicio.

Aquí les dejo un video con una epxlicación más detallada de la Arquitectura SOA

Fernando Mesta