Continuamos definiendo los estilos de integración definidos en esta entrada: http://redindustria.blogspot.com/2010/04/estilos-de-integracion-de-sistemas-i.html
Este estilo de integración es parecido al anterior. La característica esencial de este estilo es que en este caso, la información que se comparte se transmite en un formato estándar. Actualmente el formato estándar más utilizado para la integración de datos es el formato XML (Extensible Markup Language).
Se trata de un metalenguaje extensible y jerarquizado de etiquetas desarrollado por el World Wide Web Consortium (W3C), que es independiente de plataformas software y hardware. Es extensible porque una vez diseñado y puesto en producción, puede ser ampliado con nuevas etiquetas e independiente porque es un lenguaje estándar inteligible por todas las aplicaciones.
3. Base de datos compartida.
El tercer estilo de integración de datos es el que se realiza a través de una base de datos compartida. En este caso, no existe transferencia de información como en los anteriores, sino que la integración de datos se produce, porque varios sistemas de información acceden a un mismo repositorio de datos. Para ello es necesario que cada sistema de información disponga de un adaptador que le permita leer o escribir de la base de datos compartida.
4. Integración de aplicaciones o funcionalidades a través de middleware.
Las tres primeras técnicas descritas se centran en la integración de datos. Cuando se trata de integrar aplicaciones o funcionalidades, aparece el concepto de middleware como instrumento facilitador de dicha integración.
El concepto de middleware ha sido ya tratado en esta entrada, http://redindustria.blogspot.com/2008/11/qu-es-un-middleware.html
Dentro de este tipo de integración se pueden encontrar diferentes alternativas:
-Remote Procedure Calls (RPC), tratado en esta entrada http://redindustria.blogspot.com/2008/11/rpc-remote-procedure-call.html.
-Middleware basado en objetos o componentes. El siguiente estilo de integración es una evolución del anterior. En vez de realizar una integración utilizando un middleware que gestiona llamadas y respuestas a procedimientos, se utiliza un middleware que gestiona invocaciones y objetos (también llamados componentes).
El desarrollo de un objeto (código software) añade una capa de abstracción que hace que sea más independiente del software y hardware en el que se ejecuta. El objeto encapsula el código escrito en otro lenguaje, en un paquete que contiene información adicional sobre las capacidades del código que contiene y sobre cómo llamar a sus métodos. Los objetos que resultan, pueden entonces ser invocados desde otro programa (u objeto) desde la red. En este sentido se puede considerar como un formato de documentación legible por la máquina, similar a un archivo de cabeceras, pero con más información.
El middleware utilizado en este caso es más complejo, ya que debe gestionar, transformar y publicar las invocaciones y resultados de los objetos. Por otro lado, este estilo de integración facilita la
comunicación entre distintas aplicaciones y sistemas.
Un ejemplo de middleware orientado a objetos es CORBA (Common Object Request Broker Architecture). CORBA es un estándar definido por el Object Management Group (OMG) que define las APIs, el protocolo de comunicaciones y los mecanismos necesarios para permitir la interoperabilidad entre diferentes aplicaciones escritas en diferentes lenguajes y ejecutadas en diferentes plataformas, a través de la invocación de métodos remotos bajo un paradigma orientado a objetos
-Middleware orientado a mensajes (MOM), tratado en esta entrada http://redindustria.blogspot.com/2009/01/mom-middleware-orientado-mensajes.html
--------------------------------------------------------------------
2. Transferencia de ficheros estándar.Este estilo de integración es parecido al anterior. La característica esencial de este estilo es que en este caso, la información que se comparte se transmite en un formato estándar. Actualmente el formato estándar más utilizado para la integración de datos es el formato XML (Extensible Markup Language).
Se trata de un metalenguaje extensible y jerarquizado de etiquetas desarrollado por el World Wide Web Consortium (W3C), que es independiente de plataformas software y hardware. Es extensible porque una vez diseñado y puesto en producción, puede ser ampliado con nuevas etiquetas e independiente porque es un lenguaje estándar inteligible por todas las aplicaciones.
3. Base de datos compartida.
El tercer estilo de integración de datos es el que se realiza a través de una base de datos compartida. En este caso, no existe transferencia de información como en los anteriores, sino que la integración de datos se produce, porque varios sistemas de información acceden a un mismo repositorio de datos. Para ello es necesario que cada sistema de información disponga de un adaptador que le permita leer o escribir de la base de datos compartida.
4. Integración de aplicaciones o funcionalidades a través de middleware.
Las tres primeras técnicas descritas se centran en la integración de datos. Cuando se trata de integrar aplicaciones o funcionalidades, aparece el concepto de middleware como instrumento facilitador de dicha integración.
El concepto de middleware ha sido ya tratado en esta entrada, http://redindustria.blogspot.com/2008/11/qu-es-un-middleware.html
Dentro de este tipo de integración se pueden encontrar diferentes alternativas:
-Remote Procedure Calls (RPC), tratado en esta entrada http://redindustria.blogspot.com/2008/11/rpc-remote-procedure-call.html.
-Middleware basado en objetos o componentes. El siguiente estilo de integración es una evolución del anterior. En vez de realizar una integración utilizando un middleware que gestiona llamadas y respuestas a procedimientos, se utiliza un middleware que gestiona invocaciones y objetos (también llamados componentes).
El desarrollo de un objeto (código software) añade una capa de abstracción que hace que sea más independiente del software y hardware en el que se ejecuta. El objeto encapsula el código escrito en otro lenguaje, en un paquete que contiene información adicional sobre las capacidades del código que contiene y sobre cómo llamar a sus métodos. Los objetos que resultan, pueden entonces ser invocados desde otro programa (u objeto) desde la red. En este sentido se puede considerar como un formato de documentación legible por la máquina, similar a un archivo de cabeceras, pero con más información.
El middleware utilizado en este caso es más complejo, ya que debe gestionar, transformar y publicar las invocaciones y resultados de los objetos. Por otro lado, este estilo de integración facilita la
comunicación entre distintas aplicaciones y sistemas.
Un ejemplo de middleware orientado a objetos es CORBA (Common Object Request Broker Architecture). CORBA es un estándar definido por el Object Management Group (OMG) que define las APIs, el protocolo de comunicaciones y los mecanismos necesarios para permitir la interoperabilidad entre diferentes aplicaciones escritas en diferentes lenguajes y ejecutadas en diferentes plataformas, a través de la invocación de métodos remotos bajo un paradigma orientado a objetos
-Middleware orientado a mensajes (MOM), tratado en esta entrada http://redindustria.blogspot.com/2009/01/mom-middleware-orientado-mensajes.html
No hay comentarios:
Publicar un comentario