3 ALTERNATIVAS DE SOLUCIÓN
En esta sección se describen las herramientas que pueden trabajar en conjunto con las herramientas proporcionadas para conectarse al sistema R/3. Entonces, se tendrá un panorama más amplio de las opciones de solución para el diseño de una buena arquitectura de cómputo distribuido.
3.1 JNI
La interfaz JNI -Java Native Interface- [B. Stearns], es solo eso; una interfaz de comunicación. Es un API que permite que el código escrito en Java pueda interactuar con código escrito en otros lenguajes de programación, típicamente C y C++. Porque JNI es una interfaz, los distribuidores de JVM son libres de implementar la máquina virtual como a ellos les parezca mejor según sus conceptos [B. Stearns]
JNI define el estándar para los acuerdos de nombrado y llamado, de manera que el JVM pueda localizar e invocar métodos nativos. El JNI esta incorporado al JVM, de tal forma el JVM puede invocar llamados al sistema local para desempeñar el I/O y threads en el sistema operativo entre otras cosas.
Cada proyecto de software tiene sus propios requerimientos y restricciones, así que la decisión de usar código nativo con Java es altamente dependiente de la situación.
Aunque podrían haber varias razones para utilizar métodos nativos, dos razones comunes son: reutilización de código y el desempeño -aunque los JIT –Just In Time Compiler- son cada vez más y más rápidos-.
Reutilización de código. Podríamos estar de acuerdo -superficialmente- que Java es un mejor C++. Sin embargo, los beneficios de usar Java en este nivel no superan la arrolladora tarea de re-implementar el actual código probado y depurado de C++. Dada una gran cantidad de código probado de C++, podría ser más efectivo en costo incorporar su funcionalidad a programas escritos en Java, en vez de portar, re-implementar, probar y depurar la funcionalidad de las clases C++ a Java.
Desempeño. Dado que Java es interpretado, asumimos que el código nativo compilado es mucho mejor en desempeño. Puede resultar muy útil programar código nativo donde la velocidad es crítica.
Otra de las razones que podemos mencionar para que los programadores utilicen JNI es cuando las aplicaciones no pueden ser completamente escritas en Java, por ejemplo:
La librería estándar de clases de Java no soporta características dependientes de la plataforma necesitadas por la aplicación.
Programar a través de JNI permite utilizar métodos nativos para realizar muchas operaciones. Los métodos nativos representan las aplicaciones legadas o código explícitamente escrito para resolver aquellos problemas que son mejor manipulados fuera del ambiente Java.
Con JNI los métodos nativos pueden utilizar objetos java de la misma forma que el código Java utiliza a estos objetos. Los métodos nativos pueden crear objetos Java, incluyendo los arreglos y cadenas, inspeccionar y usar estos objetos para llevar a cabo su tarea. Un método nativo también puede inspeccionar y usar objetos creados por código de aplicaciones Java. Un método nativo logra actualizar objetos que haya creado u objetos que fueron pasados como parámetros, y estos objetos actualizados están disponibles para la aplicación Java. Así, desde el lado del lenguaje nativo y el lado de la aplicación Java, se pueden crear, actualizar y acceder objetos Java, por lo tanto compartir objetos de ambos lados.
Los métodos nativos también saben invocar métodos Java. Esto es útil cuando ya se tiene un librería de clases programada en Java. Así, los métodos nativos no necesitan re-inventar la rueda para desempeñar la funcionalidad ya plasmada en métodos Java existentes. Los métodos nativos utilizando JNI, pueden llamar a los métodos escritos en
Java, pasar sus parámetros requeridos, y obtener el resultado cuando el método Java haya terminado.
En la siguiente figura se muestra como un programa legado en C puede utilizar JNI para utilizar las librerías Java, invocar métodos Java.
La siguiente imagen ilustra como una aplicación Java puede invocar a rutinas nativas. Este diagrama muestra la posibilidad de utilizar JNI en un programa Java que pueda invocar funciones escritas en C, usar clases de C++, etc.
miProgramaC
JavaVM misJavaClases Librerías Java
misMetodosJava
C/C++ a Java Fig. 3.1
miProgramaJava
miClaseC++
miDepuradorC miProgramaC
miEnsamblador
Java a C/C++
Fig. 3.2
Como se ha explicado es fácil ver que JNI tiene la función de glueware entre Java y aplicaciones nativas.
3.1.1 ESCRIBIENDO APLICACIONES JAVA CON MÉTODOS NATIVOS
Para escribir programas Java que utilicen métodos nativos se deben de seguir una secuencia de pasos que a continuación se mencionan:
1. Escribir el programa Java que ejecute el método nativo. Esto significa crear la clase Java que declare el método nativo; esta clase contiene la firma para el método nativo.
2. Compilar la clase Java que declare el método nativo.
Aplicación
J N
Librerías I
Funciones Clases
VM
JNI Glueware Fig. 3.3
3. Generar el archivo header para el método nativo utilizando javah con la bandera de interfaz nativa –jni. Una vez generado el archivo header, ya se tiene la firma formal para el método nativo.
4. Escribir la implementación del método nativo en el lenguaje de programación C o C++.
5. Compilar los archivos header y la implementación en una librería compartida.
6. Ejecutar el programa escrito en Java.
Con JNI es claro que se pueden utilizar las librerías RFC para conectar sistemas desarrollados en Java al sistema R/3 de SAP. Y para ejemplificarlo se muestra en la siguiente figura:
J N I
Librerías RFC Java
Arquitectura JNI Fig. 3.4
Sistema R/3
Esta solución se puede crear bajo las plataformas UNIX, Windows y todas aquellas plataformas que sean soportadas por la librería RFC. Un punto sobresaliente que hay que mencionar es el siguiente: como se indica en el paso número 5 de la creación de aplicaciones Java utilizando JNI, los archivos header y la implementación del método nativo se crean en una librería compartida -archivo.dll en el caso de Windows y archivo.so en el caso de UNIX- esto quiere decir que la aplicación java creada será dependiente de plataforma de acuerdo a la librería compartida creada.
3.2 Java IDL
CORBA -Common Object Request Broker Architecture-, es un importante y ambicioso middleware tomado por la industria de la computación. CORBA es un producto del consorcio llamado OMG. OMG incluye a más de 800 industrias representativas de la computación, con la notable excepción de Microsoft, quien tiene su propio middleware denominado DCOM -Distributed Component Object Model-. [Orfali
& Harkey, 1998]
CORBA fue diseñado para permitir que componentes inteligentes se pueden buscar el uno al otro y puedan comunicarse en un bus de objetos. CORBA también especifica un conjunto de servicios para la creación, borrado, acceso por nombre, definición de relaciones, exteriorización de estados y ordenamiento de los objetos.
Con CORBA se pueden crear objetos ordinarios, y hacer que ellos sean transaccionales, seguros y persistentes al hacer múltiple herencia de los apropiados servicios. La especificación de un servicio siempre es separada de su implementación.
El éxito de OMG es que crea interfaces de especificación, no crea código. Las especificaciones son escritas en un lenguaje neutral denominado IDL que define la frontera o límites de los componentes y las interfaces contractuales con los clientes potenciales. Los componentes escritos en IDL deben ser portables a través de los lenguajes, herramientas, sistemas operativos y redes.
Los objetos CORBA son componentes con cierta inteligencia que pueden vivir en cualquier nodo de la red. Estos objetos son empaquetados como componentes binarios que clientes remotos pueden acceder a través de invocación de métodos. El lenguaje y el compilador usado para crear el servidor de objetos son totalmente transparentes para los clientes. Los clientes no necesitan saber dónde el objeto distribuido reside o que sistema operativo lo ejecuta, incluso no necesita saber como el servidor de objetos esta implementado, el cliente no nota la diferencia. Lo único que necesita saber el cliente es la interfaz que el servidor de objetos comunica. Esta interfaz sirve como el contrato que se va a llevar acabo entre el cliente y servidor. Los programadores tratan con objetos CORBA usando lenguajes nativos de construcción.
3.2.1 IDL
El lenguaje IDL de CORBA es puramente declarativo, esto quiere decir que no provee detalles de implementación. Se puede usar el lenguaje IDL para definir el API concisamente y cubrir importantes puntos como el manejo de errores. Las especificaciones de métodos de IDL pueden ser escritas e invocados desde cualquier lenguaje que brinde las promesas de CORBA -Java, C, C++, Ada, Smalltalk, COBOL-.
El lenguaje IDL provee al sistema operativo y a los lenguajes de programación interfaces independientes para todos los servicios y componentes que residan en el bus de objetos de CORBA. Esto permite que los clientes y servidores escritos en diferentes lenguajes de programación puedan comunicarse.
El lenguaje IDL nos permite especificar los atributos de los componentes como:
La clase padre de la que hereda.
Las excepciones que pueden ocurrir.
Los tipos de eventos que emite y
Los métodos que su interfaz soporta -incluyendo los parámetros de entrada y salida y los tipos de datos que soporta.
La gramática de IDL es un subconjunto de C++, con palabras claves adicionales para el soporte de conceptos distribuidos.
3.2.2 IIOP
IIOP -Internet Inter-ORB Protocol- es el protocolo de comunicación de la arquitectura CORBA y es la parte crítica del estándar. Hace posible que objetos distribuidos programados en diferentes lenguajes de programación se puedan comunicar y hace posible que diferentes implementaciones de ORB -explicado en la siguiente sección- puedan operar entre ellos mismos.
3.2.3 ORB
El ORB -Object Request Broker- es el bus de objetos de CORBA. El ORB permite que los objetos transparentemente hagan peticiones y recibir respuesta a objetos localizados local o remotamente. El cliente no está consciente de los mecanismos usados para comunicarse, activar y provisionar al servidor de objetos. El ORB provee una amplia variedad de servicios distribuidos. El ORB permite a los objetos descubrirse el uno al otro en tiempo de ejecución e invocar los servicios. Algunos de los beneficios que provee un ORB son:
Invocación de métodos en forma dinámica y estática.
Sistema de propia descripción.
Transparencia local/remota.
Seguridad.
Comunicación polimórfica.
Coexistencia con sistemas existentes.
El ORB es el middleware que establece la relación de cliente/servidor entre objetos. Usando el ORB el cliente puede transparentemente invocar un método en un servidor, éste puede estar en la misma máquina o en otra parte en la red. El ORB intercepta la llamada y es responsable por encontrar un objeto que pueda ejecutar la petición, pasarle sus parámetros, invocar su método y regresar los resultados. El cliente no necesita estar consciente de donde el objeto esta localizado y tampoco necesitar saber aspectos técnicos como el lenguaje de programación, el sistema operativo o cualquier otro aspecto que no sea parte de la interfaz del objeto.
La estructura de CORBA ORB del lado del cliente es:
Stubs del cliente. Provee interfaces estáticas a los servicios de objetos. Define cómo el cliente debe invocar los correspondientes servicios de los servidores. El cliente debe de tener un stub para cada interfaz que usa en el servidor. Estos stubs incluyen el código para llevar a cabo el marshalling, esto significa que codifica y decodifica la operación, sus parámetros en mensajes formateados de tal manera que se puedan enviar al servidor.
DII -Dynamic Invocation Interface-. Permite descubrir métodos que pueden ser invocados en tiempo de ejecución.
Interfaz ORB. Consiste en un API para servicios locales que puede utilizar la aplicación.
La estructura de CORBA ORB del lado del servidor es:
Stubs del servidor -skeletons-. Provee interfaces estáticas para cada servicio exportado por el servidor.
DSI -Dynamic Skeleton Interface-. Provee el mecanismo de binding en tiempo de ejecución para servidores que necesitan manipular llamadas entrantes a métodos para componentes que no contienen un stub IDL base compilado.
Object Adapter. Asiste al ORB activando objetos en el servidor y entrega peticiones a los objetos una vez activados. Lo más importante es que asocia la implementación del objeto con el ORB. Provee el ambiente de tiempo de ejecución para instanciar, pasar solicitudes y asignarles ID de referencia.
Interfaz ORB. API de servicios iguales al cliente.
Por lo tanto, podemos decir que el ORB es un agente que se encarga de recibir la petición de un cliente a un componente u objeto distribuido y entregarla, así mismo también se encarga de regresar el resultado de la solicitud y de terminar la petición del solicitante. Las peticiones de solicitud -cliente- y la respuesta -servidor- deben de hablar el protocolo de comunicación IIOP, puesto que este es el protocolo de comunicación del ORB.
3.2.4 SERVICIOS DE CORBA
Los servicios de CORBA son colecciones de paquetes con interfaces IDL especificadas. Se puede pensar en los servicios de CORBA como servicios que pueden aumentar y complementar la funcionalidad del ORB. Se pueden utilizar para crear componentes, nombrarlos e introducirlos en el ambiente. Algunos de los servicios definidos por OMG son:
Life Cycle Service: Define las operaciones para crear, copiar, mover y borrar componentes en el bus.
Persistence Service: Provee la interfaz de servicios para el almacenamiento de componentes en diferentes servidores.
Naming Service: Permite a los componentes residentes en el bus puedan localizar a otros componentes por medio de nombres.
Event Service: Permite a los componentes residentes en el bus a que dinámicamente registren o no su interés a eventos específicos.
Concurrency Control Service: Provee un administrador de bloqueos para hilos y transacciones.
Transaction Service: Provee el commit de dos fases y los componentes pueden usar transacciones planas o anidadas.
Relationship Service: Provee los medios para crear dinámicamente asociaciones entre componentes que no se conocen el uno al otro.
Externalization Service: Provee los medios para la obtención de datos de un componente.
Query Service: Provee las operaciones tipo “query” para objetos, es un súper conjunto de SQL.
Licensing Service: Provee las operaciones para medir el uso de componentes.
Properties Services: Provee las operaciones para asociar propiedades a cualquier componente.
Time Services: Provee las interfaces de sincronización y operaciones de definición y manejo de eventos.
Entre otros.
Todos estos servicios enriquecen al comportamiento de los esquemas distribuidos, además de proveer un robusto medio ambiente a las aplicaciones basadas en el middleware CORBA.
3.3 RMI - IIOP
Java Remote Method Invocation -Remote Method Invocation- ha logrado establecerse en el campo de la programación distribuida en Java por sí mismo. Una mayor ventaja que toma sobre la programación en Sockets, es que Java RMI explota las características de la programación orientada a objetos, tales como métodos, clases, objetos, entre otras. [S. Ergül, 2000]
Java RMI es parte JDK desde la versión 1.1. El principal propósito de RMI es el desarrollo de aplicaciones distribuidas, el cual requiere que la aplicación sea totalmente implementada en Java.
El inicio de RMI – IIOP -Remote Method Invocation -Internet Inter-ORB Protocol- comienza en 1997, cuando SUN Microsystems anuncia que la tecnología RMI soportará IIOP -Internet Inter-ORB Protocol- como protocolo de transporte, además de su protocolo nativo de comunicación. La versión final de Java RMI – IIOP estuvo lista en junio de 1999 y fue desarrollada entre SUN e IBM.
RMI – IIOP promete que la plataforma Java y el mundo CORBA estarán más cerca que nunca. Java ha probado por si mismo ser un lenguaje de programación ideal para el desarrollo de aplicaciones CORBA. Con el desarrollo de RMI – IIOP, objetos de Java RMI, pueden ser accedidos por clientes CORBA escritos en otros lenguajes de programación que soporten la arquitectura estándar de CORBA. Además, los clientes Java RMI pueden acceder objetos CORBA, independientemente del lenguaje en que hayan sido escritos estos objetos. Esto significa que los clientes Java RMI no necesitan estar conscientes sobre el lenguaje neutral IDL -Interface Definition Language- de CORBA para poder acceder a objetos CORBA.
Básicamente RMI – IIOP es la unión de dos tecnologías; Java RMI y Java IDL, La cual permite la implementación y acceso a objetos CORBA sin la necesidad del lenguaje IDL. En la especificación de CORBA 2.3, se señala el mapeo de Java a IDL,
asimismo, describe como las interfaces de los objetos remotos de Java RMI deben de traducirse a CORBA IDL.
Ahora se puede definir la interfaz de un objeto Java RMI y traducirlo a su interfaz equivalente a IDL utilizando el compilador de Java-a-IDL. Entonces, se tienen dos opciones de implementación de interfaces:
Implementar la interfaz de RMI en el lenguaje Java y
Usar el compilador de IDL e implementar las interfaces de los objetos CORBA en otros lenguajes de programación.
En el primer caso, sólo se necesitara la interfaz IDL para los clientes CORBA, ejemplo:
Cliente Java RMI
Cliente Java IDL
Cliente CORBA
C++
I N T E R F A Z R M
I C
O R B A I D L
Objeto RMI/IIOP
Java
Los clientes Java RMI pueden acceder objetos RMI/IIOP a través de interfaces ordinarias de Java RMI. Los clientes CORBA necesitan las interfaces equivalentes en IDL.
IIOP IIOP IIOP
Fig. 3.5
En el segundo caso, también se necesita la interfaz IDL para implementar el objeto RMI/IIOP como un objeto CORBA, ejemplo:
Algunas de las ventajas que ofrece RMI/IIOP sobre RMI/JRMP son las siguientes:
Interoperabilidad con objetos escritos en diferentes lenguajes de programación a través de CORBA.
Contextos de seguridad y transacciones.
IIOP tiene soporte para firewalls a través de IIOP proxies la cual permite un tráfico controlado y manejable.
Cliente Java RMI
Cliente Java IDL
Cliente CORBA
C++
Interfaz RMI C
O R B A I D L
Objeto RMI/IIOP
C++
Los clientes Java RMI pueden acceder a objetos RMI/IIOP implementados como objetos CORBA a través de interfaces ordinarias de Java RMI. Las implementaciones de los clientes CORBA y los objetos RMI/IIOP necesitan las interfaces equivalentes en IDL.
IIOP
IIOP
IIOP
Fig. 3.6
Con IIOP como protocolo de transporte, Java RMI encuentra el soporte que necesita para promover el desarrollo de aplicaciones distribuidas. Sin embargo, RMI/IIOP tiene debilidades en comparación de RMI/JRMP como son:
No se tiene soporte de GC distribuido debido a que no existe dentro de la especificación CORBA. No se pueden utilizar las características de RMI/JRMP cuando sé esta trabajando con RMI/IIOP.
No se puede utilizar el operador de casting de Java en los clientes después de obtener la referencia de un objeto. En su lugar se utiliza un método especial para obtener el tipo.
Todas las definiciones en las interfaces remotas deben de ser de tipo primitivo y ser evaluadas en tiempo de compilado.
La tecnología Java RMI – IIOP, es la unión de dos tecnologías: Java IDL y Java RMI. Dando de esta forma el soporte necesario que se le debe dar a un ambicioso middleware como es CORBA. Hay que mencionar que esta tecnología es accesible a través del uso de Java IDL. Podemos decir que son tecnologías similares, lo único que distingue a Java IDL sobre RMI – IIOP, es el uso del IDL.
Resumen
En este capítulo se analizaron tres tecnologías que pueden engrandecer el alcance de las soluciones de interoperabilidad del sistema R/3 de SAP. Una de ellas con características muy diferentes a las otras dos: JNI. Mientras que las otras son de características muy similares: RMI – IIOP y Java IDL. Con JNI se desarrollan aplicaciones dependientes de plataformas donde el desempeño es crítico o la reutilización de código es de suma importancia. En cambio con RMI – IIOP y Java IDL se crean aplicaciones distribuidas que hablan el middleware CORBA tomando todas las particularidades que propone esta arquitectura como son la independencia de plataforma, la independencia de sistema operativo y la independencia del lenguaje de programación.
Así teniendo un panorama más detallado sobre los tipos de trabajos o aplicaciones que se pueden desarrollar en el contexto del sistema R/3 de SAP, damos paso a nuestro modelo de comunicaciones en el siguiente capítulo.
