Caracteristicas de CORBA

Hola el presente artículo tiene como finalidad mostrar las principales características de CORBA.

CORBA es un middleware de comunicaciones ya que aísla la aplicación de los detalles del kernel de comunicaciones y desde la perspectiva técnica su arquitectura presenta las siguientes características de diseño:

1. Transparencia

CORBA oculta,  al programador de aplicaciones, muchas de las dificultades inherentes de la computación de objetos distribuidos. Todas las invocaciones de métodos en objetos remotos son manejadas transparentemente por CORBA. Para el programador de aplicaciones todas las llamadas a objetos serán invocaciones locales, y no necesita saber dónde están localizados los objetos en la red.

Además, CORBA automáticamente suministra un número de útiles servicios para comunicaciones de red, tales como procesamiento de transacciones o nombrado (naming). La mayoría de estos servicios pueden ser comprados como paquetes de software añadidos (add-on) y pueden ser instalados dentro del ORB para añadir la funcionalidad requerida a CORBA.

El hecho de que CORBA sea ampliamente transparente en el nivel de Aplicación, simplifica la programación de aplicaciones en sistemas distribuidos y, por lo tanto, puede reducir los costos de desarrollo de aplicaciones. Igualmente, los programadores de aplicaciones no requieren ser especialistas en CORBA para usarlo.

2. Independencia de Plataforma

CORBA tiene su propio lenguaje para describir interfaces de objetos, llamado Lenguaje de Definición de Interfaces (IDL / Interface Definition Language) el cual puede ser compilado en una variedad de lenguajes de programación y plataformas. De esta manera, las interfaces CORBA son independientes del lenguaje de programación usado para implementar los objetos cliente y servidor. Por ejemplo, es posible tener interfaces CORBA para un navegador (browser) basado en Java® del lado cliente, una aplicación PC basadas en C++, y una aplicación LINUX® basada en C del lado servidor. Todos estos objetos software pueden ser conectados a través de este ambiente heterogéneo con CORBA debido a que todas las interfaces de objetos tienen una representación IDL. CORBA también provee sus propios protocolos de comunicación, los cuales se ejecutan en la cima de una variedad de protocolos de red convencionales (Por ejemplo: TCP/IP).

3. Portabilidad

CORBA es una solución apropiada para evitar los costos de desarrollo innecesarios ya que muchos objetos software pueden ser reusados en varias partes del sistema. Esto es debido a que CORBA provee los mecanismos para acceder todos los objetos a través de las fronteras de plataformas y lenguajes de programación, lo cual significa que el software no necesita ser llevado a diferentes lenguajes de programación o plataformas.

4. Integración

CORBA permite la integración de componentes de software de varias fuentes. Por ejemplo, un código Java® en un cliente web puede usar información de una base de datos servidor en un entorno LINUX®. La mayoría de las grandes empresas tienen un gran número de sistemas heredados con información crítica del negocio, los cuales no pueden ser llevados a modernos sistemas debido a incompatibilidades de formatos de datos y de protocolos de comunicación. En la práctica, la solución CORBA a este problema es su mayor atractivo, y muchas compañías desarrollan «envolturas» (wrappers) CORBA para proveer una interfaz IDL a sus sistemas heredados.

5. Interoperatividad

La idea central detrás de CORBA es «que objetos en ejecución, en cumplimiento con productos CORBA de diferentes vendedores es posible», debido a que CORBA especifica sus propios protocolos de comunicación y lenguajes de definición de interfaces estandarizados. Por lo tanto todos los productos que cumplan con el estándar CORBA deben ser capaces de interoperar.

6. Localización Transparente

CORBA hoy requiere ser capaz de soportar aplicaciones móviles, por ejemplo en entornos inalámbricos con dispositivos móviles donde a menudo los servidores cambian su ubicación. Estos objetos son comúnmente llamados nómadas y los «servicios de nombrado» CORBA así como su mecanismo de invocación transparente a la localización, ofrecen los medios para ubicarlos.

7. Escalabilidad

CORBA fue ideado para soportar entornos con un gran número de objetos y usuarios potenciales. Por lo tanto la arquitectura CORBA no coloca restricciones al crecimiento tanto en el número de objetos como de usuarios en el sistema. De igual manera CORBA facilita la migración de plataformas pequeñas centralizadas a grandes entornos distribuidos.

En un sentido general CORBA «envuelve» 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 CORBA) desde la red.

NHibernate

Hola el presente artículo tiene como finalidad mostrar un explicación básica de ORM, Hibernate y por ultimo NHibernate.

ORM (Object-Relational Mapping)

Un ORM es una técnica-software para convertir datos orientados a objetos a una base de datos relacional, usando un motor de persistencia. Se crea una base de datos orientada a objetos virtual sobre una base de datos relacional.  Por lo tanto su principal ventaja es “olvidarse” de la tediosa labor e crear todas las sentencias SQL para obtener, actualizar, insertar o borrar datos (CRUD como veremos adelante) en la base, así como soporte para la persistencia.

Hibernate

Ees una herramienta ORM (Object-Relational Mapping) ó Mapeo Objeto Relacional para la plataforma JAVA. Herramienta que facilita el mapeo de atributos entre una base de datos relacional tradicional y el modelo de objetos de una aplicación mediante archivos declarativos XML o anotaciones en los beans (componente que se puede reutilizar y que puede ser manipulado visualmente por una herramienta de programación en lenguaje Java) de las entidades que permiten establecer estas relaciones.

NHibernate

Es la alternativa de software libre disponible para .NET en C#, distribuido bajo los térmimos LGPL. Es una de las primeras aproximaciones para el mundo .NET de proyectos ORM, a la cual se ha unido Microsoft con LinqToSQL y Entity Framework.

Vamos a tratar NHibernate. Al emplearle para el acceso a datos, el desarrollador garantiza que su aplicación es independiente en cuanto al motor de datos empleado en producción.  Soporta los SGBDR más empleados en el mercado como puede ser MYSQL, Postgre, Oracle, MSSQL, etc. Sólo es necesario cambiar una línea en el fichero de configuración para que podamos emplear una base de datos distinta.

NHiberbate facilita el mapeo de atributos entre una base de datos relacional tradicional y el modelo de objetos de una aplicación, mediante archivos declarativos (XML) que permiten establecer estas relaciones. Intenta solucionar el problema de la diferencia entre los 2 modelos usados hoy en día para organizar y manipular datos: El usado en la memoria del ordenador (orientación a objetos) y el usado en los sistemas gestores bases de datos (modelo relacional).

Para lograrlo permite al desarrollador especificar cómo es su modelo de datos, qué relaciones existen y qué forma tienen. Con esta información NHibernate le permite a la aplicación manipular los datos de la base operando sobre objetos, con todas las características de la POO.

Hibernate convertirá los datos entre los tipos utilizados por c# y los definidos por SQL. Hibernate genera las sentencias SQL y libera al desarrollador del manejo manual de los datos que resultan de la ejecución de dichas sentencias, manteniendo la portabilidad entre todas las bases de datos con un ligero incremento en el tiempo de ejecución.

NHibernate está diseñado para ser flexible en cuanto al esquema de tablas utilizado, para poder adaptarse a su uso sobre una base de datos ya existente. También tiene la funcionalidad de crear la base de datos a partir de la información disponible.

Posee también un lenguaje de consulta de datos llamado HQL (Hibernate Query Language), al mismo tiempo que una API para construir las consultas de forma programada (conocida como “criteria“).

 

Universal Description, Discovery and Integration

Hola el presente artículo tiene como finalidad mostrar un explicación básica de UDDI.

Universal Description, Discovery and Integration

Catálogo independiente, basado en XML, que lista los negocios de internet  de todo el mundo. Es una iniciativa industrial abierta, en donde los negocios se listan a sí mismos en internet, como si se tratase de las páginas amarillas en una guía telefónica. Es patrocinado por OASIS, y que permite a las empresas publicar listas de servicios y descubrirse entre sí, y definir cómo los servicios o aplicaciones de software interactúan sobre internet. UDDI fue escrito en agosto de 2000.

UDDI es una plataforma destinada a facilitar la operativa funcional de las aplicaciones compartidas en la red. UDDI permite describir y encontrar servicios web, facilitando su uso a diversas plataformas que deseen utilizarlos. UDDI es el estándar para descripción, búsqueda e integración de servicios web. Configura un directorio de información de estos servicios. UDDI utiliza WSDL para la descripción de los servicios y SOAP para las comunicaciones.

UDDI es un formato definido, entre otras, por empresas como Dell, Fujitsu, HP, Hitachi, IBM, Intel, Microsoft, Oracle, SAP y SUM. Más de 220 compañías son miembros de la comunidad UDDI.

El registro de un negocio en el UDDI consta de tres partes:

• Páginas blancas: dirección, contacto y otros identificadores conocidos.
• Páginas amarillas: categorización industrial basada en taxonomías.
• Páginas verdes: información técnica sobre los servicios que la empresa brinda.

UDDI es uno de estándares básicos de los servicios web. Está diseñado para ser interrogado por mensajes SOAP y proveer acceso documentos de WSDL (Web Services Description Language), en los que se describen los requisitos del protocolo y los formatos del mensaje solicitado para interactuar con los servicios Web del catálogo de registros.

Diferencias entre Web Services y WCF (Windows Communication Foundation)

Hola el presente artículo tiene como finalidad mostrar un resumen básico, sencillo y directo sobre las diferencias existentes entre Web Servicies y WCF.

1)    Web Services

Un web service es una capa de lógica de negocio accesible a través de protocolos web, uno de ellos SOAP, que usa XML como estándar de datos para enviar y recibir datos.

Adicionalmente se puede decir que un Servicio Web es una entidad programable, proporcionado un elemento particular de funcionalidades, como Lógica de aplicación. Puede ser usado internamente por  cualquier aplicación o externamente, a través de la internet por cualquier número de aplicaciones usando estándares como XML (Lenguaje de Marca Extensible) y HTTP (Protocolo de Transferencia de Hipertexto).

2)    Windows Communication Foundation

Es un conjunto de librerías que provee Microsoft en el Framework .NET para la construcción de aplicaciones orientadas a servicios.

Es también un modelo de programación unificado, el cual se define como un simple vía para escribir servicios y por tanto unifica elementos como Servicio Web (*.asmx), .NET Remoting, Message Queue (MSMQ), Enterprise Services (COM+) y Servicios web Mejorados. WCF no remplaza estas tecnologías sobre una base individual, más bien suministra un modelo simple de programación que puede usar para aprovechar todo estos elementos a la vez.

3)    Diferencias

Como diferencias básicas entre WCF y Web Services podemos destacar:

• WCF es la evolución de las tecnologías web service de Microsoft de años anteriores.
• WCF provee un amplio rango de funcionalidad por encima de web services, con mejores características en aspectos de calidad como flexibilidad, portabilidad y mantenibilidad.
• Los web services sólo pueden ser accedidos a través de HTTP, mientras que  WCF se puede hospedar en un servidor web, WAS, puede ser un servicio de Windows, y usa una variedad de protocolos más amplia.
• En la plataforma .NET, la serialización de los datos de los web services se hace a través de la lase XmlSerializer, mientras que para WCF se usa la clase DataContractSerializer. Cabe anotar que esta última es más optimizada para WCF, por lo que provee una mejora en rendimiento a comparación del XmlSerializer.
• Al DataContractSerializer se le puede indicar cuáles propiedades de las entidades de datos serán serializadas. Esto permite optimizar el tamaño de las peticiones de datos que se generan.
• Hay clases que no se pueden serializar a través de un web service en .NET que si tienen soporte en WCF (HashTable por ejemplo).