Conceptos (RMI,CORBA,BPM,BPML)

RMI


La idea que sustenta RMI es un ideal recurrente en tecnologías de Orientación a Objetos: hacer que un objeto invoque a otro objeto remoto con independencia de la JVM o el servidor en el que se encuentra, como si fuera un objeto local. Transparencia respecto a la máquina.

Hay dos posibilidades:

• El objeto servidor no está escrito en Java. Necesitamos algún sistema para que los objetos puedan hablar entre sí sin importar el lenguaje de codificación. En este sentido la solución más común es CORBA (Common Object Request Broker Architecture) del OMG (Object Management Group).


• El objeto está en Java. Entonces usamos RMI, que es una tecnología más sencilla que CORBA. Antes de la versión 1.3 RMI sólo podía usar JRMP (Java Remote Method Protocol). Paro a partir de la versión 1.3 podemos usar además IIOP (Internet Inter-ORB) de OMG.

¿Cómo es posible que el objeto cliente pueda invocar al objeto remoto? Hay varias cosas que debemos tener, una de ellas es un interfaz para el objeto remoto. Un concepto fundamental es que el cliente sólo puede invocar al objeto remoto a través de su interfaz remota. La interfaz remota es el "escaparate" del objeto remoto, es el modo en que el objeto remoto "exporta" sus servicios. Aquello a lo que el cliente accede está en el interfaz del objeto remoto. Lo que no significa que el objeto remoto no tenga otros métodos, claro que puede tenerlos; pero sólo los métodos que estén en su interfaz son invocados por el cliente.

Arquitectura RMI

Las tres capas de RMI:

• Capa de transporte: basada en TCP/IP.


• Capa de sesión: conecta clientes con objetos remotos en una referencia de uno-a-uno.


• Capa de presentación. La expresión "presentación" debe entenderse en el sentido OSI, es la capa que traduce los datos de sesión a la capa de aplicación y viceversa.

La capa de aplicación  del cliente traduce su invocación a una llamada al objeto Stub, que se traduce a JRMP, después a TCP, hasta llegar al nivel de hardware del cliente, que la envía al hardware donde está el objeto remoto. Aquí se recorre el orden inverso, desde el hardware hasta la capa de aplicación. Esta arquitectura mantiene la flexibilidad. Podemos reemplazar una sin afectar a la eficacia del conjunto. Por ejemplo, podemos usar UDP (User Datagram Protocol) en lugar de TCP.

Tomado de :  http://www.proactiva-calidad.com/java/rmi/introduccion.html

BPM

Se llama Gestión o administración por procesos de negocio (Business Process Management o BPM en inglés) a la metodología corporativa cuyo objetivo es mejorar el desempeño (Eficiencia y Eficacia) de la Organización a través de la gestión de los procesos de negocio, que se deben diseñar, modelar, organizar, documentar y optimizar de forma continua. El Modelo de Administración por Procesos, se refiere al cambio operacional de la empresa al migrar de una operación funcional a una operación de administrar por procesos.

Ventajas del modelo

Un proceso se puede ver como un conjunto de recursos y actividades interrelacionados que transforman elementos de entrada en elementos de salida. Los recursos pueden incluir personal, finanzas, instalaciones, equipos, técnicas y métodos.

A través del modelado de los procesos de negocio, al interior de una organización, puede lograrse un mejor entendimiento de la operación de la empresa y muchas veces esto presenta la oportunidad de mejorar los procesos y con ello mejorar el desempeño. La estructuración de los procesos reduce errores, asegurando que los procesos se comporten siempre de la misma manera, reduciendo el margen de error y dando elementos que permitan visualizar el estado de los mismos durante cada etapa. La administración de los procesos permite asegurar que los mismos se ejecuten eficientemente, cumpliendo con estándares de calidad previamente establecidos, y ayudando a la obtención de información que luego puede ser usada para mejorarlos. Es a través de la información que se obtiene de la ejecución diaria de los procesos, que se puede identificar posibles ineficiencias o fallas en los mismos, y actuar sobre ellos para optimizarlos.

Tomado de http://es.wikipedia.org/wiki/Gesti%C3%B3n_de_procesos_de_negocio

CORBA

CORBA es una tecnología que oculta la programación a bajo nivel de aplicaciones distribuidas, de tal forma que el programador no se tiene que ocupar de tratar con sockets, flujos de datos, paquetes, sesiones etc. CORBA oculta todos estos detalles de bajo nivel. No obstante CORBA también brinda al programador una tecnología orientada objetos, las funciones y los datos se agrupan en objetos, estos objetos pueden estar en diferentes máquinas, pero el programador accederá a ellos a través de funciones normales dentro de su programa.

Veamos un ejemplo:

Esta función ejecutaría el método setMode sobre el objeto object, para el programador esta llamada es como una operación local, no hay más complejidad.

Los métodos y datos CORBA se agrupan formando lo que se demoninan interfaces, los interfaces pueden ser interpretados como objetos que grupan datos y métodos para acceder a estos. Todos estos interfaces se definen usado un lenguaje IDL (Interface Definition Language), que es precisamente esto, un lenguaje para la definición de interfaces. Este lenguaje es estandar y lo soportan todas las implementaciones CORBA.

es algo más que una abstracción que oculta la complejidad de red, -> TODAS LAS LLAMAS PARA EL PROGRAMADOR SON IGUALES -> SE DEFINEN OBJETOS Y METODOS -> LOS OBJETOS SON REMOTOS -> NO PORQUE CORBA OCULTE COSAS DEBEMOS DEJAR DE PENSAR EN LA EFICIENCIA DE RED Hay una multitud de sistemas con un propósito muy similar a CORBA circulando por el mundo, los más usados son: el RPC (Remote Procedure Call) de Sun Microsystems y DCOM (Distributed que los desarrolladores de GNOME han adoptado es individuales CORBA -> muy importante especificación, OMG


BPML 

Business Process Modeling Language (BPML) es un lenguaje para el modelado de procesos de negocio.BPML fue una propuesta de lenguaje, pero ahora el BPMI ha abandonado el soporte para esto en favor de BPEL4WS (Business Process Execution Language para Web Services). A partir de 2008, BPML También se ha

informado que ha sido descartado en favor de BPDM (Business Process metamodelo Definición ). BPMI tomó esta decisión cuando fue adquirida por la OMG con el fin de tener acceso a su especificación popular, BPMN ( Business Proceso de Modelo y notación ). Esta notación ha sido útil a OMG a fin de enriquecer con la notación UML proceso.

BPML, un superconjunto de BPEL, se llevó a cabo por los proveedores de la fase inicial, como Intalio Inc., pero los operadores tradicionales como IBM y Microsoft no ha aplicado BPML en su actual flujo de trabajo y las implementaciones de integración del motor (BizTalk Server, Websphere, etc.) Por lo tanto, abogó por un lenguaje más simple, BPEL. Hoy en día, las implementaciones de código abierto de BPML siguen siendo superiores a la capacidad de estos productos comerciales. Esto llevó a algunos a decir que BPML contra BPEL fue un caso de VHS contra Betamax. La analogía no es del todo correcto. Para VHS y Betamax tanto te permiten ver video - incluso si una aplicación se impuso. Eso no es el caso de BPML y BPEL. BPML fue diseñado como un lenguaje formal completa, capaz de modelar cualquier proceso, y, a través de un BPMS ( Business Process Management del sistema), implementado como un proceso de software ejecutable sin la generación de cualquier código de software. Esto no es posible con BPEL, desde BPEL no es un lenguaje de proceso completo. Para ilustrar esto, tenga en cuenta que BPEL se utiliza a menudo en combinación con Java para llenar los "desaparecidos" semántica. Además, BPEL está a menudo relacionado con implementaciones propietarias de motores de flujo de trabajo o de corredores de integración.Considerando que, BPML fue diseñado e implementado, como un motor de procesamiento de pura concurrente y distribuida.

Diferencias y Similitudes Entre Varias Arquitecturas

1. ES LO MISMO CLIENTE SERVIDOR QUE SOA

Para nuestro concepto tanto SOA como la arquitectura c/s son arquitecturas de gran importancia ya que la primera es la lógica del negocio y la segunda es la arquitectura en la cual se distribuye la información, Al contrario de las arquitecturas orientadas a objetos, SOA está formada por servicios de aplicación con acoplamiento débil y altamente interoperable.

Una diferencia clara de SOA con la arquitectura c/s es que esta está orientada a procesos y enfocada al cambio. De esta forma las empresas TI se benefician mucho ya que con esta pueden reconfigurar rápidamente sus recursos de TI sin necesidad de realizar una integración profunda, lo cual les permite liberar recursos para abrir espacio a la innovación y a la alta calidad.

2. ES LA  ARQUITECTURA CLIENTE SERVIDOR LA BASE DE SOA

La arquitectura C/S si es la base de SOA ya que SOA es una evolución de esta, aunque hay que tener en cuenta que SOA puede ser claramente independiente de la arquitectura C/S ya que esta es la lógica del negocio.

Como evolución de la arquitectura C/S esta contempla en si unos puntos claros de la arquitectura c/s Tales como:

-las funciones de la interface del usuario

- la lógica de las aplicaciones

- la administración de los datos, están separados de forma que cada una puede ser implementada usando las plataformas y las tecnologías que mejor se adapten a la tarea.

SOA incorpora servicios que corren en distintas plataformas y estos  están alojados en distintos servidores.

3. COMO SE ACOPLA SOA Y C/S CON SAAS Y ASP

Siendo SOA una evolución de la arquitectura cliente servidor enfocándose a los servicios podemos decir que hay una alta relación con las arquitecturas saas y asp ya que siendo ASP un proveedor de servicios, Y SASS un modelo de distribución de software podemos contemplar que todos están con un mismo fin satisfacer las necesidades del cliente ofreciendo en si un servicio o un software de calidad.

Aunque existen diferencias notables entre estas arquitecturas como por ejemplo ASP siendo proveedor de software este ofrece sus servicios a múltiples clientes y este puede adaptar dicho software a su modo para garantizar su necesidad en cambio en SAAS estando esta en la nube presta sus servicios a muchos clientes con la clara diferencia de que estos solo pueden acceder a este sin modificarlo un ejemplo claro de este es gmail y siendo SOA una arquitectura orientada a servicios en donde su claro objetivo no es más que darle soporte a los requisitos del negocio y contemplando la clara perspectiva de que la arquitectura c/s no garantiza la buena lógica de negocios ya que esta presentaba La congestión del tráfico ya que esta siempre ha sido un problema en el paradigma de C/S. Cuando una gran cantidad de clientes envían peticiones simultáneas al mismo servidor, puede ser que cause muchos problemas para éste ya que a mayor número de clientes, más problemas para el servidor por este motivo fue creado SOA ya que este satisface dichos problemas. Entonces como conclusión podemos decir que estas arquitecturas buscan la mejora de las tecnologías en sí, ya que un cliente siempre lo que espera en un software o en un servicio es la seguridad, la fiabilidad y la disponibilidad estas están en la clara respuesta sobre estos planteamientos ofreciéndonos siempre un servicio o un software de alta calidad garantizándonos éxitos a nosotros como clientes.

4. ESTANDARES DE SOA

Service Component Architecture (SCA): En el post pasado dijimos que esta especificación provee un modelo para la creación de componentes de servicios dentro de una solución de negocios, es decir las actividades las cuales están en el corazón de las aplicaciones. SCA provee un modelo de programación para crear componentes de servicios escritos ya sea en Java, BPEL, C++ o lenguajes declarativos como XSLT.

Service Data Objects (SDO): Establece un significado consistente a los datos que operan entre diversas aplicaciones sin importar la fuente o el formato de las mismas.Ofrece un mecanismo para unificar datos de diversas bases de datos y servicios.

Business Process Execution Language (BPEL): Provee un estándar de procesos de negocio empresarial para la ejecución y orquestación. Usando BPEL se pueden diseñar procesos de negocio que integran servicios discretos dentro de un flujo de proceso de presentación final. Esta integración reduce tremendamente los costos de proceso y complejidad.

Transformaciones XSL (XSLT): Procesa documentos XML y transforma datos de un esquema de documento XML en otro. 

Java Connector Architecture (JCA): Provee una solución en tecnología Java para la conexión entre diversos servidores de aplicaciones.

Java Messaging Service (JMS): Provee un estándar de mensajeo para comunicar diversas aplicaciones basadas en Java 2 y Enterprise Edition (Java EE) a través de sistemas heterogéneos.

Archivos Web Services Description Language (WSDL): Proporcionan los puntos de entrada en una aplicación compuesta SOA (composite application). El archivo WSDL proporciona un lenguaje estándar reducido y es la base para entender las capacidades de un servicio. El Simple Object Access Protocol (SOAP) proporciona el protocolo de red para la entrega de mensajes.

http://oscaryani.blogspot.com/2010/07/estandares-adoptados-por-oracle-soa.html

5. SOA NO ES LO MISMO QUE WEBSERVICES ¿Por qué?

SOA y servicios web son dos cosas diferentes ya que estos  son la preferencia basada en estándares  al contrario de SOA ya que este se puede implementar con múltiples tecnologías tales como MOM, CORBA, COBOL ETC.

SOA  es un mecanismo de intercambio de información dentro de los muchos que se utilizan,  para conectar o transmitir información de las aplicaciones. Estos son estándares, lo que comúnmente utilizamos. Es importante concretar que Web Services no es SOA, sino un mecanismo de intercambio de información.

Aunque hay que tener en cuenta que cuando se desea conseguir la máxima reutilización de información  se pueden utilizar los estándares más ampliamente soportados teniendo en cuenta aspectos como la reutilización de funcionalidades por otros consumidores, Reutilización de funcionalidades de otros servicios, Aprovechamiento de otras herramientas y Conocimiento del personal.

En conclusión podemos decir que SOA es una abstracción del éxito de los servicios web para integración de sistemas de información ofreciendo así un gran alto potencial ,bajos costos , alta integración y de gran flexibilidad favoreciendo en si la automatización de las relaciones de negocio a negocio a través de Internet.