Análisis de las alternativas cliente/servidor en el sistema AS/400~' --- ~$:;, ~ ·· A• ~')LJc: ~ \ },~ ~ ' l', li V ~"l.:.
de;,, ··~s-··¡. DO '° 1 ~~ : . ._ 1 ·, ,._. T1"" ~
INSTITUTO TECNÓLOGICO Y DE ESTUDIOS SU_PERIORES DE MONTERREY \\ ¡,¡.f:\t~~O ,§) CAMPUS ESTADO DE MEXICO ~,?,,,. - ,.-.. • · .. '.~.~/
ANÁLISIS DE LAS ALTERNATIVAS CLIENTE/SERVIDOR EN EL SISTEMA AS/400
TESIS QUE PRESENTA
Atizapán de Zaragoza, Edo. de México, Marzo del 2000.
~SN¡ L1'i>t~\'./" ~---~ .. -··
'· -· . . , .-... ·· ,, .. • .. ,• ,, ,
.. / _:~ '
:.; < . . ·: •: ·,.;
INSTITUTO TECNÓLOGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY ~ ... CAMPUS ESTADO DE MÉXICO
ANÁLISIS DE LAS ALTERNATIVAS CLIENTE/SERVIDOR EN EL SISTEMA AS/400
TESIS QUE PARA OPTAR EL GRADO DE MAESTRO EN SISTEMAS DE INFORMACIÓN
PRESENTA
Jurado: M.A. Adriana Román Rodríguez Presidente M.S.I. Rafael Martínez Casanova Secretario M.C. Ralf Eder Lange Vocal
Atizapán de Zaragoza, Edo. de México, Marzo del 2000.
' , .. , · ... -. ·, ")
RESUMEN
A pesar de la gran base instalada de computadoras AS/400 (Advanced System/400), este sistema de IBM no es tan conocido como los son otros equipos. Actualmente existen aproximadamente 700,000 equipos instalados en el mundo. En México existen alrededor de 4000 equipos usados en diferentes tipos de empresas, tales como en los sectores de telecomunicaciones, industria bancaria, manufactura y en transporte.
Este sistema, que es catalogado como de rango medio o mini-computadora, es usado por muchas empresas para reemplazar mainframes o para ser usado como servidor en redes LAN.
El sistema AS/400 no es mejor que otros tipos de computadoras, simplemente diferente, tal como un autobús no es mejor que un coche deportivo. Sus características únicas que lo diferencían de otros sistemas hacen que este equipo sea ideal para ciertas funciones, pero no apto para otras. Por ejemplo, el AS/400 no está orientado para funciones de tipo diseño gráfico ó para aplicaciones científicas con proceso intensivo de cálculo numérico. En cambio, está orientado para aplicaciones multi-usuario de tipo comerciales con uso de base de datos relacional. Las aplicaciones típicas que se pueden encuentrar en un AS/400 son: nómina, contablidad, manejo de inventarios, servidor para transacciones comerciales en internet, correo electrónico y servidor de Lotus Notes.
Ante las tendencias de la industria de cómputo, el sistema AS/400 también ha incorporado diversas funciones tecnológicas que permiten usarlo efectivamente ya sea como un sistema centralizado o distribuido. Han existido grandes avances en las funciones de base de datos, seguridad, comunicaciones, apertura, rendimiento, lenguajes de desarrollo orientados a objetos como C++ y Java, y soporte a Internet.
Una de las funciones estratégicas de investigación y desarrollo sobre el AS/400 es el ambiente cliente/servidor. Actualmente existen modelos de hardware diseñados específicamente para incrementar el rendimiento en este ambiente. De la misma manera, se han incorporado funciones de conectividad específicas para tal fin. También se soportan diferentes interfaces de programación, tanto propietarias como estándares de industria. Algunas de estas interfaces son: ODBC (Open Database Connectivity), JDBC en Java, OLE DB, Sockets, APPC y DAL.
4
Tradicionalmente las aplicaciones se han desarrollado en AS/400 por medio de lenguajes nativos como RPG y COBOL/400. Para un desarrollador de aplicaciones de este tipo, el cambio hacia la tecnología cliente/servidor es complejo, principalmente debido a que se requiere de aprender un lenguaje visual bajo el ambiente Windows y conocer el uso de Interfaces de Programación de Aplicación (APls).
En este trabajo se profundiza en el estudio del ambiente cliente/servidor en el equipo AS/400, en particular en el uso de interfaces abiertas y portables.
Las principales alternativas estudiadas son ODBC, Java y las interfaces a nivel de transporte como APCC y Sockets.
De la alternativa seleccionada depende que las aplicaciones desarrolladas presenten ciertas ventajas, como interoperabilidad, portabilidad, facilidad de desarrollo y de mantenimiento. A lo largo del trabajo, estas características son evaluadas en cada alternativa.
En suma, en este documento se explica y se comparan las principales interfaces de programación disponibles en el sistema AS/400. Este documento puede servir de referencia para que los desarrolladores de AS/400 definan su estrategia de desarrollo de sus aplicaciones nuevas o la modernización de sus aplicaciones existentes.
5
CONTENIDO
1.1. Antecedentes 1.2. Justificación _1.3 . Objetivos 1.4. Metodología
CAPÍTULO 2: ESTADO DE ARTE
2.1. El ambiente de desarrollo de aplicaciones 2.2. El concepto cliente/servidor 2.3. Modelos cliente/servidor 2.4. Factores alrededor de cliente/servidor 2.5. Conclusiones
CAPÍTULO 3: LA BASE DE DATOS EN AS/400
3.1 . Antecedentes de 082/400 3.2. Características de 082/400 3.3. Conclusiones
CAPÍTULO 4: APLICACIONES CON JAVA
4.1. Antecedentes de Java 4.2. Control de Java 4.3. Soporte de Java en AS/400 4.4. Estrategias de diseño con Java en AS/400 4.5. Modelos de aplicaciones
Página
8
30
6
CAPÍTULO 5: EL ESTÁNDAR ODBC 54
5.1. Antecedentes del ODBC 54 5.2. Componentes de ODBC 55 5.3. Versiones de ODBC 58 5.4. Niveles de conformancia 58 5.5. Proceso del uso de APls 60 5.6. Recomendaciones de rendimiento en ODBC 63 5.7. Estrategias de diseño con ODBC 65
CAPÍTULO 6: PROTOCOLOS A NIVEL DE TRANSPORTE 68
6.1. Aplicaciones cliente/servidor con APPC 68 6.2. Aplicaciones cliente/servidor con Sockets 78
CAPÍTULO 7: COMPARACIÓN DE ALTERNATIVAS 82
7 .1. Soporte a los modelos cliente/servidor 82 7.2. Eficiencia de la aplicación 83 7.3. Portablilidad de la aplicación 84 7.4. Desarrollo de aplicaciones con Java 85 7.5. Desarrollo de aplicaciones con ODBC 87 7.6. Protocolos a nivel de transporte 89
CAPÍTULO 8: CONCLUSIONES Y RECOMENDACIONES 92
8.1. Soporte de nuevas tecnologías 94
BIBLIOGRAFÍA 97
1.1. ANTECEDENTES.
Cada vez más las compañías están organizando sus sistemas de información en forma distribuida, lo que conlleva a tener aplicaciones de tipo cliente/servidor.
El factor determinante que impulsa el cambio hacia cliente/servidor es el usuario final. Al usuario final le atrae el modelo de cómputo distribuido con el uso de interfaces gráficas, en contraste con el modelo, considerado obsoleto, de terminales basadas en caracteres.
Las aplicaciones con una interfaz tradicional basada en caracteres no ofrece el poder intuitivo de una interfaz gráfica. Como se explicará más adelante, la interfaz gráfica sólo es una parte del modelo cliente/servidor. Algunos de los beneficios de una interfaz gráfica son:
a) Por medio de una interfaz gráfica, se pueden incorporar representaciones familiares del mundo conceptual del usuario [1 ]. Este tipo de representación ayuda al usuario a asociar una imágen conceptual con una función determinada. De esta forma, la interfaz es manejada por la intuición. Los usuarios generalmente quieren enfocar su atención en la solución y no en cómo la computadora trabaja para lograr el resultado.
b) Una interfaz natural hace más productivo al usuario. En lugar de memorizar opciones de menús o comandos, las tareas se ejecutan con solo "apuntar y presionar''.
c) El usuario controla el flujo de la aplicación, y no la computadora. El usuario tienen la capacidad de iniciar y ejecutar tareas en cualquier secuencia.
d) El usuario puede recibir información acerca de la tarea que está ejecutando, en forma de mensajes u otro tipo de retroalimentación. En otras palabras, la computadora no debe ignorar nunca al usuario, proporcionándole información de forma frecuente, sobre todo en operaciones de larga duración. En este caso, las aplicaciones proporcionan indicadores de progreso para mantener la paciencia del usuario.
Por otra parte, el uso de más y más redes de computadoras personales está también impulsado el fenómeno de cliente/servidor.
8
En las empresas que han contado tradicionalmente con minicomputadoras o con equipos mainframes, existe la alternativa de usarlos como servidores para los grupos de computadoras personales. Esta alternativa es viable siempre y cuando las minicomputadoras o mainframes evolucionen tecnológicamente en respuesta a la tendencia cliente/servidor. Factores como qué tipo de protocolos de redes se soportan, apego a estándares de industria y de facto, eficiencia, etc., hacen que tales equipos sean una opción viable para ser usados como servidores [2].
Conforme el paradigma de la computación se transforma, también lo hace el sistema AS/400. El AS/400 ha sido un poderoso sistema de aplicaciones comerciales, con más de 28,000 aplicaciones disponibles. Muchas de estas aplicaciones existentes están rápidamente evolucionando hacia el modelo cliente/servidor aprovechando las innovaciones tecnológicas que en el AS/400 se han incorporado para soportar esta tendencia.
1.1.2. INTERFACES DE PROGRAMACIÓN
Para implementar determinado modelo en el sistema AS/400, existen disponibles varias alternativas, llamadas interfaces de programación de aplicaciones o APls. Una de las características más importante del AS/400 es la gran cantidad de interfaces de programación que soporta, tanto propietarias como estándares de industria. Las APls más importantes que el AS/400 soporta son:
a) APPC (Advanced Program to Program Communications)
b) Colas de Datos.
c) APIS de Mensajes.
e) SQL Remoto
i) JDBC (Java Data Base Connectivity)
9
De la alternativa seleccionada depende que las aplicaciones desarrolladas presenten ciertas ventajas, como interoperabilidad, portabilidad, facilidad de desarrollo y mantenimiento.
Si se toma la alternativa de usar interfaces a nivel de transporte (como APPC ó Sockets) se están accesando directamente las funciones APls de comunicaciones, en este caso se obtiene como resultado aplicaciones muy eficientes en tiempo de respuesta. Sin embargo, el grado de complejidad para el desarrollo de la aplicación es más alto debido a que se requieren conocimientos de los protocolos de comunicaciones y de programación tanto en ambiente de AS/400 como de PC.
Esta alternativa es ideal, por ejemplo, si alguien desea desarrollar una aplicación gráfica para controlar la seguridad del AS/400. En este caso se deben crear programas en el AS/400 que intercambien datos con el programa cliente. De hecho, muchas empresas desarroladoras de software para AS/400, incluyendo a IBM, utilizan las interfaces propietarias del AS/400 para desarrollar, entre otros productos, emuladores de terminales, administradores gráficos de la base de datos, administradores de usuarios, etc.
La empresas que cuentan con AS/400 están más orientadas al desarrollo de aplicaciones transaccionales con la Base de Datos que al desarrollo de los productos de administración. En esta situación, el uso de interfaces de acceso directo a la base de datos es la mejor opción.
Por otro lado, con algunas alternativas se corre el riesgo que la aplicación no sea eficiente en términos de un buen tiempo de respuesta para el usuario final. Esto se debe a que las APls se pueden implementar de distintas maneras. Muchos lenguajes como Visual Basic incluyen funciones de alto nivel (como el Data Control) que simplifican el desarrollo de la aplicación pero que no proporcionan eficiencia en el acceso a los datos.
1.2. JUSTIFICACIÓN
Hasta este momento se han mencionado las diferentes interfaces de programación para el desarrollo de aplicaciones cliente/servidor con AS/400, en donde el AS/400 juega el papel de servidor de base de datos. Para implementar adecuadamente una interfaz, el desarrollador de sistemas tradicionales de AS/400 encuentra que el uso de APls es difícil de comprender y manejar apropiadamente.
El problema se complica más si tomamos en cuenta que la documentación de las interfaces de programación del AS/400 tiene un enfoque técnico y no de guía para la toma de decisiones del área de sistemas.
10
Los manuales existentes son de referencia al programador, lo que significa que no explican de forma amplia y comparativa las diferentes alternativas. Por otro lado, existen diversos libros que tratan las interfaces de acceso a bases de datos locales o en servidores de tipo PC o UNIX, pero que no consideran el acceso al AS/400. Y, por lo tanto, no se mencionan las ventajas y consideraciones a tomar en cuenta cuando se utiliza al AS/400 como servidor de base de datos.
En suma, no existe una documentación o bibliografía en donde se concentre y se explique de forma didáctica las facilidades, modelos y alternativas del desarrollo cliente/servidor en el AS/400. La bibliografía existente no se apega a las características de AS/400, por ejemplo, una parte importante en el tráfico de información entre el cliente y el servidor son los tipos de datos. Los lenguajes en ambiente Windows usan tipos de datos muy diferentes a los del AS/400.
Ante esta situación, muchos departamentos de tecnología de información continúan desarrollando con herramientas tradicionales, afectando a la productividad de los usuarios finales ya que el ciclo de desarrollo se alarga y la cartera de proyectos se agranda.
En otros casos, las empresas mantienen sus equipos AS/400 para las aplicaciones tradicionales, las aplicaciones nuevas de tipo cliente/servidor se incorporan paulatinamente en redes de PC. En esta situación, la solución tiene que incluir la adquisición de DBMSs adicionales corriendo en servidores de PC. En este ambiente, la complejidad del manejo de la información se complica debido a que se cuentan con diferentes copias de los datos. La redundancia de los datos se da de la siguiente manera: las fuentes de datos provienen de las aplicaciones tradiciones que corren en el AS/400, como las tareas de inventarios, compras, proveedores. Los datos son replicados en otro manejador DBMS para ser accesados por aplicaciones gráficas, por ejemplo, para obtener reportes y gráficas para la toma de decisiones.
Es frecuente encontrar que la replicación de datos se hace en procesos nocturnos. En este ambiente existen costos adicionales porque se tiene que comprar o desarrallor software para la replicación de datos, además de los costos de las los DBMS. También se debe considerar los gastos por personal adicional.
La intención básica de este trabajo de TESIS consiste en: (a) una investigación bibliográfica sobre la arquitectura cliente/servidor en el AS/400, y (b) comparación de las alternativas actuales para desarollar aplicaciones cliente/servidor en AS/400.
11
Al analizar qué interfaces de programación existen para la base de datos 082/400 y qué modelos de cliente/servidor se pueden implementar, los beneficios principales de este trabajo de Tesis son:
a) Entender lo que es la tecnología cliente/servidor, sus beneficios y alcances en el sistema AS/400.
Si la función de sistemas aún no ha considerado el uso de esta tecnología por resistencia al cambio, reducción de costos, desconocimiento o por otras razones, con los temas a discutir se presentará un panorama actual del ambiente cliente/servidor en AS/400, discutiendo sus beneficios y tendencias.
b) Disminuir costos de desarrollo e implementación de las aplicaciones cliente/servidor.
Con el conocimiento de qué interfaces de programación existen, cuáles están incluidas en el sistema operativo del AS/400 y cuál es la mejor en términos de los requerimientos de los usuarios y de los recursos existentes, podemos evitar el adquirir software adicional de comunicaciones, manejadores de base de datos, etc.
c) Considerar al AS/400 como un servidor viable y evitar cambios de tecnología.
El cambio de tecnología trae consigo impactos de costos, nuevo entrenamiento y resistencia al cambio. En muchas empresas que ya cuentan con un AS/400, se buscan otras alternativas de servidores por desconocimiento de que el AS/400 podría resolver su requerimiento.
Por otro lado, si tomamos en cuenta que una implementación exitosa de una aplicación es aquella que puede integrarse con las aplicaciones existentes, el usar a la misma plataforma AS/400 para las nuevas aplicaciones cliente/servidor nos trae ventajas de reducción de los costos típicos asociados con los cambios de tecnología.
12
Los objetivos de este trabajo de Tesis son:
1) Explicar las facilidades tecnológicas existentes en el sistema AS/400 para soportar los modelos cliente/servidor.
2) Comparar las principales alternativas para el desarrollo de aplicaciones cliente/servidor en el AS/400, en términos de interoperabilidad, portabilidad, eficiencia y facilidad de desarrollo.
1.4. METODOLOGÍA SEGUIDA.
Para alcanzar los objetivos planteados, la metodología seguida se basó en primer lugar en la investigación documental de la tecnología cliente/servidor en el ámbito del sistema AS/400. Se realizó también una investigación similar sobre el estándares APPC, OLE/DB, ODBC, JDBC y Data Queues.
El trabajo se ha desarrollado en base a los siguientes lineamientos:
1.4.1. ESTADO DE ARTE
Se inicia con una introducción de lo que es la tecnología cliente/servidor, mostrando sus ventajas, modelos y tendencias. Estos temas se estudian en el capítulo: El Estado de Arte de la tecnología cliente/servidor en AS/400.
1.4.2. ANÁLISIS DE LAS DIFERENTES INTERFACES
En los siguientes capítulos, se estudian las diferentes alternativas interfaces de programación. Cada alternativa se analiza en base las siguientes características:
a) lnteroperabilidad.
La facilidad para compartir y procesar información desde o hacia otros sistemas.
b) Portabilidad.
La portabilidad se refiere a la capacidad de poder utilizar la misma aplicación con diferentes manejadores de datos, sin tener que modificar el código. El objetivo de
13
algunos estándares es lograr la máxima portabilidad, mientras que otros se orientan a obtener la máxima eficiencia.
c) Eficiencia o Tiempo de Respuesta.
Se analiza la eficiencia del manejo de transaciones de cada alternativa. Algunas inetrefaces permiten el uso de bloqueaje, preparación de sentencias SQL, uso de marcas de parámetros, manejo adecuado de tipos de datos, etc.
e) Manejo de diferentes tipos de datos.
El manejo adecuado de los tipos de datos entre el programa cliente y el servidor es uno de los aspectos más vulnerables a errores debido a los diferentes tipos de datos entre la PC y el AS/400. Se analizará de qué forma cada interfaz maneja la conversión de los tipos de datos.
f) Lenguaje de programación.
Se mostrará para cada alternativa, si es necesario programar tanto en el servidor como en el cliente.
Algunas interfaces permiten que todo el desarrollo se realice del lado del cliente, lo cual nos permite utilizar herramientas de desarrollo comunes en el ambiente de PC, como los lenguajes de cuarta generación (4GL) y/o lenguajes visuales.
14
CAPÍTULO 2. ESTADO DE ARTE.
En este capítulo se describe el estado actual del entorno para el desarrollo de aplicaciones cliente/servidor. El enfoque de esta revisión será en el desarrollo de aplicaciones en donde el AS/400 juega el papel de servidor de base de datos.
2.1. EL AMBIENTE DE DESARROLLO DE APLICACIONES
La tecnología de información (TI) se ha visto modificada recientemente por estos dos factores principales:
En primer lugar, el poder del procesamiento de las computadoras se ha incrementado paulatinamente mientras que sus costos han descendido significativamente. El poder de procesamiento que alguna vez ocupaba todo un centro de cómputo y costaba cientos de miles de dólares puede ahora se colocado en un escritorio con un precio accesible.
En segundo lugar, se han desarrollado sistemas operativos, aplicaciones y herramientas de desarrollo con interfaces consistentes y que facilitan su uso.
Estos factores traen como consecuencia que los usuarios demanden aplicaciones más sofisticadas. Además del uso de paquetes de hojas de cálculo, procesadores de palabra, navegadores de internet y aplicaciones gráficas para el acceso a base de datos, los usuario demandan que la información sea fácil de accesar y que sea precisa.
Desde el punto de vista de la función de TI, la mayor parte de las empresas no pueden abandonar totalmente sus sistemas tradicionales y reemplazarlos por aplicaciones de vanguardia. Los sistemas tradicionales permanecen como núcleo de las aplicaciones de misión crítica del negocio. En estas aplicaciones se maneja y genera la información que soporta el negocio. A menudo, estas aplicaciones aún corren en terminales de caracteres.
Por lo tanto, el intento de la computación cliente/servidor se debe dar por razones de negocio, en otras palabras, una empresa no puede seguir siendo competitiva sin inversión adicional y continua en el área de TI [1].
Existen varias razones para justificar la adopción de nuevas tecnologías mediante cliente/servidor:
15
a) Se facilita el uso de nueva tecnología. El proceso cliente/servidor permite una integración modular y/o el reemplazo paulatino de componentes de software. En lugar de cambiar toda una aplicación, se pueden ir mejorando sus componentes.
b) Las soluciones no siempre estarán disponibles en una plataforma única. Las aplicaciones de diseño gráfico requieren de una plataforma de cómputo diferente que las aplicaciones comerciales con uso intenso de datos.
c) Se puede extender el cliclo de vida de una aplicación al mejorar porciones de la aplicacion. Por ejemplo, se puede convertir la interfaz basada en caracteres a una interfaz gráfica, en lugar de reescribir toda la aplicación. Muchas empresas que no pueden abandonar totalmente sus aplicaciones ya escritas, están convirtiendo sólo las interfaces usando Java [3].
d) El desarrollo de aplicaciones se puede hacer más rápidamente usando herramientas modernas de desarrollo. De acuerdo con analistas de la industria, la tecnología cliente/servidor es uno de los factores claves requeridos para el desarrollo de aplicaciones competitivas en el futuro. Con una entrega mas rápida de soluciones a los requerimientos de información de las áreas claves de la empresa, se puede mejorar el servicio al cliente y mejorar la posición de la empresa dentro de su industria.
La cuestión es cuánto tiempo la función de TI puede retrazar las siguientes decisiones:
• Proporcionar una interfaz gráfica y la funcionalidad del manejo por eventos. • Facilitar las aplicaciones para internet. • Mover el código de las aplicaciones con libertad de un sistema o otro. • Incrementar la productividad del programador y el tiempo de entrega de
aplicaciones.
Estos aspectos requieren del uso de la tecnología cliente/servidor. El término cliente/servidor no se refiere un tipo específico de proceso sino ha varias posibilidades.
2.2. EL CONCEPTO CLIENTE/SERVIDOR
La computación cliente/servidor permite la división de tareas entre diferentes procesadores, en donde cada máquina debe ejecutar la tarea que mejor sabe hacer.
Realmente no hay una definición que esté aceptada de forma general sobre lo que es cliente/servidor. Las diferentes definiciones dependen del contexto en que se dan, ya sea que estemos hablando de internet ó del proceso distribuido. Pero en general, el concepto incluye a dos entidades separadas: el cliente y el servidor, trabajando juntas para realizar alguna tarea.
Cliente/servidor es una interrelación entre dos funciones separadas: un servidor proporcionando servicios y el cliente utilizando esos servicios. El cliente puede ser tan
16
simple como una hoja de cálculo o tan complejo como un programa de alto nivel ejecutándose en una PC.
Prácticamente, podemos considerar que el modelo cliente/servidor se traduce en una función con interfaz gráfica ejecutándose en una computadora personal y accesando los recursos de una o de varias máquinas servidoras, las cuales pueden ser: computadoras personales, minicomputadoras o mainframes. Entre estas entidades existe, desde luego, un enlace de comuniciones que puede ser una red LAN o WAN.
Los recursos que los servidores proporcionan pueden ser de distinta clase, como almacenamiento en disco, servicios de impresión, acceso a una base de datos o acceso a aplicaciones.
El concepto cliente/servidor también puede ser visto como una forma especial de proceso cooperativo. El proceso cooperativo involucra dos o más procesos realizando una tarea común. Dichos procesos pueden estar o no en la misma máquina. El concepto de proceso cooperativo ha existido prácticamente desde los inicios de la computación, de tal manera que, por ejemplo, ocurre una forma de proceso cooperativo cuando un programa llama una rutina. Cuando uno de los procesos se caracteriza por estar siempre solicitando los servicios de otro, nos econtramos con un esquema cliente/servidor.
Algunas de las características comunes que podemos encontrar de las distintas definiciones de cliente/servidor son :
a) Los servidores proporcionan recursos que se comparten entre varios clientes. Estos recursos pueden de hardware y/o software.
b) La ubicación de los recursos es transparente para los usuarios finales. Los recursos pueden incluso estar en el mismo cliente o en un sistema diferente de la red.
c) Los clientes siempre inician la operación al solicitar un servicio. Los servidores están esperando las requisiciones de parte de los clientes.
d) Los clientes y servidores intercambian información por medio de mensajes. La conexión es por medio de una red local o por comunicaciones remotas.
2.3. MODELOS CLIENTE/SERVIDOR
Existen varios modelos o categorías de cliente/servidor. El modelo que se ha usado tradicionalmente en las redes LANs es el Servidor de Impresión y Archivos. Este fué el primer modelo de cliente serividor.
2.3.1. DIVISIÓN DE UNA APLICACIÓN
Una manera actual de clasificar los modelos se basa en la forma en que se puede dividir una aplicación, es decir, qué parte de la aplicación está en el cliente y qué parte en el servidor [5]. Los modelos de la empresa de consultoría Gartner Group se basan en esta idea. En estos modelos, se considera que una aplicación está formada por tres partes lógicas: la presentación ó interfaz del usuario, la lógica de la aplicación, y la
17
base de datos. En la figura 2.1. se muestran los modelos cliente/servidor en base a esta divisón de la aplicación.
Figura 2.1. Modelos cliente/servidor
1) Presentación Distribuida
Datos Oistri b.Ji oos
Un ejemplo de Presentación Distribuida es un emulador de terminal corriendo en ambiente Windows. Muchos emuladores actuales convierten el formato basado en caracteres en formato GUI. Esta alternativa es una forma primitiva de cliente/servidor debido a que en realidad la aplicación no fué diseñada con interfaz gráfica, sino que un software adicional se encarga de manejar la intefarce en el lado del cliente.
En este caso, el usuario tiene la percepción de que la intertace ha sido movida a la computadora personal.
Los beneficios reales del cliente/servidor se pueden obtener por medio de los otros modelos.
2) Presentación Remota.
En este caso, la lógica y los datos de la aplicación residen en el servidor. La interfaz completa del usuario reside y corre en el lado del cliente.
3) Lógica Distribuida.
La lógica de la aplicación se puede dividir entre el servidor y el cliente. Este enfoque permite que cada tarea se ejecute en el sistema más apropiado. Si la aplicación
18
maneja imágenes o rutinas especiales de proceso numérico intenso, deben quedar en el sistema que mejor ejecute este tipo de proceso.
Frecuentemente a este modelo se le conoce como conversacional debido a la comunicación directa entre los procesos cliente y servidor. Los procesos cliente y servidor se pueden comunicar por diferentes métodos, incluyendo APPC, Sockets o el estándar RMI (Remate Method lnvocation) en el caso de Java.
Este modelo proporciona el mejor rendimiento debido a que se codifica el proceso servidor usando herramientas nativas. Sin embargo, el grado de complejidad en el desarrollo de la aplicacion aumenta debido a que se deben conocer los dos ambientes de desarrollo, tanto conocer lenguajes de programación del AS/400 como del ambiente Windows.
Dentro de la clasificación de Lógica Distribuida se encuentran los procesos de Procedimientos Almacenados y el arranque de "Triggers" de la base de datos.
4) Datos Remotos
En este modelo, el cliente maneja la lógica de la aplicación así como la presentación. Los datos residen completamente en el servidor . De esta forma el servidor actúa como el repositorio de la base de datos.
5) Datos Distribuidos ..
En este modelo, también el cliente maneja toda la lógica de la aplicación así como la presentación. Los datos residen tanto en el servidor como en el cliente.
Por medio del enfoque de Datos Distribuidos se permite que una aplicación cliente/servidor utilice diferentes bases de datos en diferentes plataformas.
El cliente utiliza interfaces SQL como ODBC, OLE/DB o JDBC para accesar los datos remotos.
2.3.1. FUNCIONES DEL SERVIDOR
Otro modelo de cliente/servidor [3] se basa en las funciones que el servidor proporciona. Los casos que se presentan son:
1) Servidor de Base de Datos. En este modelo, tanto la lógica de la aplicación como la interfaz del usuario reside en el cliente. La base de datos se encuentra en el servidor. El programa cliente manda peticiones de consulta, usualmente en un formato estándar tal como SQL, hacia el servidor. Solamente el resultado es regresado al cliente, es decir, en lugar de que el archivo de datos se esté copiando de máquina en máquina, el cliente solicita información y el servidor responde con subconjunto sumarizado de datos.
19
2) Servidor de transacciones. En este modelo, el cliente manda una solicitud (CALL) hacia el servidor para invocar un procedimiento remoto. El procedimiento almacenado en el servidor puede ser una secuencia de sentencias SQL que trabajan sobre la base de datos, o puede ser cualquier programa. Este modelo es diferente del Servidor de Base de Datos, porque la unidad entera de ejecución es ejecutada en el servidor. Cuando el proceso termina de ejecutarse, se envía el resultado al programa cliente. Muchos manejadores de base de datos, incluyendo al AS/400, proporcionan facilidades para soportar este modelo. El término común en el ambiente de base de datos para estas unidades de ejecución es Procedimientos Almacenados.
3) Servidor de Grupos. Una nueva forma de computación que ha surgido como influencia de la tecnología cliente-servidor es el trabajo de grupos (Groupware). La idea surge a partir de la necesidad de realizar ciertas actividades de manera conjunta por personas trabajando en un grupo. Por ejemplo, la creación de un documento grande con varios participantes, mantener una conferencia con personas en sitios remotos, etc.
Un Servidor de Grupos combina varios componentes ( correo, flujo de trabajos, calendarización, etc.) para proporcionar la sinergia del grupo. En la industria actual, Lotus Notes es probablemente el producto más importante para soportar este modelo.
En los párrafos anteriores se han discutido varios modelos como si cada caso fuera un servidor separado cada uno con sus clientes. Desde luego, en la práctica los modelos no necesitan estar separados, en un mismo sistema servidor pueden presentarse una combinación o todos los modelos al mismo tiempo.
2.4. FACTORES ALREDEDOR DE CLIENTE/SERVIDOR.
La tecnología cliente/servidor actual se puede comprender mejor si se analizan los siguientes factores:
a) Los lenguajes de programación b) El ambiente de desarrollo c) Interfaces de acceso a datos
En las siguientes secciones se analiza el estado actual de estos factores. La intención es proporcionar información necesaria para posicionar la tecnología cliente/servidor dentro de un contexto actual.
20
2.4.1. LENGUAJES DE PROGRAMACIÓN.
El lenguaje de desarrollo impacta a la productibidad, portabilidad y al rendimiento de la aplicación creada. A continuación se resume el desarrollo que han tenido los lenguajes de programación.
El primer lenguaje simbólico de programación fue el ensamblador. El lenguaje ensamblador opera a un nivel tan cercano al hardware, que requiere una mínima conversión hacia instrucciones de máquina. Con un mínimo de sobrecarga, el código en ensamblador se ejecuta tan rápido como el hardware lo permita. Sin embargo, este tipo de código es difícil de mantener. Además de que cuando hay cambios a nivel hardware, el código también debe cambiarse para aprovechar las nuevas facilidades.
Si el código de máquina se considera como el lenguaje de primera generación, al ensamblador le corresponde la posición de ser un lenguaje de segunda generación. En el siguiente nivel están los lenguajes de tercera generación (3GL), en esta categoría se encuentran: C, COBOL, Pascal, etc. Con estos lenguajes se obtiene mayor productividad que los lenguajes de tipo ensamblador. La sintaxis de estos lenguajes no se apegan a la arquitectura del hardware, lo cual significa que el código escrito con lenguajes 3GL tienen cierto grado de portabilidad. Sin embargo, debido a que tienden a orientarse hacia un sistema individual, esta portabilidad es limitada. Por ejemplo, mientra solo existe el lenguaje COBOL, muchas máquinas tienen su propio compilador de COBOL. Cada compilador de COBOL aprovecha las características especificas del sistema y, por tanto, tienen ciertas funciones propietarias.
Los lenguajes de cuarta generación (4GL) introdujeron la noción de la programación no procedural. Con lenguaje de 3GL se requiere que el programador proporcione las instrucciones completas y precisas para las rutinas. Con un lenguaje no procedural, el programador no tiene que dar los detalles de cómo se debe realizar una tarea. Simplemente se describe qué se quiere lograr y el lenguaje 4GL se encarga de generar el código adecuado. Con este estilo, el programador escribe menos líneas de código que en un lenguaje procedural.
Además de mejorar la productividad, el uso de lenguajes 4GL produce código más portable. La abstracción de las sentencias permite el uso de objetos de programación tales como reportes, texto de ayuda, pantallas, fechas, etc.
Para crear aplicaciones cliente/servidor, los lenguajes tradicionales 3GL o 4GL requieren de características adicionales, como pueden ser el manejo de interfaces gráficas y el manejo de eventos. Por tanto el uso de lenguajes Visuales se hace necesario en estos casos. Un producto de desarrollo visual se puede basar en un 3GL ó en un lenguaje 4GL.
En lugar de escribir complejas instrucciones para describir la apariencia y ubicación de los elementos gráficos, con un lenguaje de programación visual, el programador simplemente selecciona objetos pre-construidos y los copia en el lugar deseado
21
dentro de una ventana. En este trabajo de Tesis se usará un lenguaje de este tipo (Visual Basic) para crear las apliaciones "cliente".
La programación visual incrementa la productividad significativamente al mismo tiempo que permite crear interfaces de usuario atractivas, intuitivas y de fácil uso. Sin embargo, cuando estas aplicaciones se difunden para su uso a lo largo de toda la empresa, el rendimiento del servidor tipo PC se ve afectado y se pierde escalabilidad debido al volúmen grande de transacciones y a la contingencia de los datos. Esto se debe a que las aplicaciones se basan en mecanismos de acceso a los datos que son fáciles de usar pero que resultan poco eficientes en ambientes multiusuario. Por ejemplo, el lenguaje Visual Basic tiene la función Data Control que, practicamente sin escribir una línea de código, permite el acceso a datos, pero con poca eficiencia para un ambiente de alto volumen de transacciones. Existen mecanismos de acceso a los datos, como las APls de ODBC, que resultan más eficientes. Estos mecanismos se estudiarán ampliamente a lo largo de este trabajo.
El desarrollo más novedoso en los lenguajes es la programación en red [7]. En este tipo de programación se resuelve totalmente el aspecto de la portabilidad al remover la atadura hacia un sistema operativo. La aplicaciones de red son creadas usando Java. Con Java se asegura que la aplicación es capaz de ejecutarse en cualquier nodo de la red que incluya una Máquina Virtual de Java (JVM).
En resúmen, los lenguajes de desarrollo han evolucionado tomando en cuenta los siguientes factores:
• Los lenguajes de programación muestran una tendencia a ser independientes del hardware.
• La programación se enfoca cada vez más a la reutilización de partes de software.
• La portabilidad del código se ha convertido en una prioridad. El uso de estándares de desarrollo es vital para proporcionar transparencia al usuario final.
• Las bases de datos relacionales y el SQL son la parte central de las aplicaciones nuevas.
• Las herramientas modernas de desarrollo requieren gran cantidad de recursos de cómputo, sin embargo esto no afecta a su difusión debido al mejoramiento contínuo del precio-rendimiento del hardware. Los beneficios son más productividad y portabilidad.
22
2.4.2. AMBIENTE DE DESARROLLO.
Los ambientes de desarrollo actuales tienen las características de ser visuales y orientados a objetos. La tecnología 00 ha abarcado a muchas de las herramientas de desarrollo actuales. Los beneficios de la programación 00 (como la reutilización del código, la herencia, el polimorfismo, etc.) están disponibles para incrementar la productividad del programador.
Debido a que los sistemas (hardware y sistemas operativos) usados en un ambiente distribuido cliente/servidor provienen por lo general de diferentes proveedores, es necesario que la tecnología de objetos se base en estándares de industria.
Para crear un ambiente de desarrollo con características 00, los proveedores deben considerar los siguientes aspectos [1 O]:
• La forma que la aplicación se comunica con los objetos • La forma en que el objeto regresa el resultado al solicitante. • La forma en que el sistema operativo maneja los objetos. • Manejo de versiones de los objetos • Herramientas para crear objetos
Las respuestas a estos factores dictan la implementación del ambiente de desarrollo, generalmente a este ambiente se le llama el Modelo de Objetos.
No existe un concenso sobre qué lenguaje es el mejor para lo programación Orientada a Objetos, esto significa que cuaquier modelo basado en objetos debe ser independiente del lenguaje. Los estándares de industria para objetos están siendo regidos por el grupo OMG (Object Management Group). Una de sus especificaciones es la arquitectura abierta y multi-plataforma llamada CORSA (Cross-platform Common Object Request Broker Architecture ).
Con base en estas especificaciones, surge el modelo SOM (System Object Model) que es usado en los diferentes sistemas operativos de IBM [3].
El modelo de objetos diseñado por Microsoft se llama COM (Component Objet Model). En este modelo se definen la forma en que la tecnología 00 se implementa entre los sistemas operativos Windows [8].
Los modelos basados en objetos no son excluyentes, es decir, los diferentes sistemas operativos pueden soportar uno o varios modelos al mismo tiempo.
23
2.4.3.1. OLE DB
En 1996, Microsoft publicó su primera especificación de una nueva tecnología de acceso a datos: OLE DB (OLE far DataBase). Aunque en este año, el ODBC era ya el estándar de industria para el acceso de bases de datos relacionales (9].
La tecnología OLE (Object Link Embbeding ) había surgido previamente. Con OLE, es posible crear un "enlace dinámico" entre aplicaciones. Esto significa que, despues de copiar y pegar una hoja de cálculo en un texto de un procesador de palabras, el OLE permite que los cambios en los datos de la hoja de cálculo se vean reflejados en la procesador de palabras.
Otra característica de OLE es la activación dinámica, por ejemplo, se puede dar un doble click en los datos tabulares dentro del procesador de palabras e invocar en ese momento a la aplicación de hoja de cálculo.
Sin embargo OLE por sí mismo no permite al programador accesar datos de diferentes fuentes de datos. Gran parte de los datos que los usuarios requieren accesar no están almacenados sólo en bases de datos relacionales. Por ejemplo, los usuarios almacenan datos en hojas de cálculo, mensajes de e-mail, etc. Las fuentes de información son diversas.
Para accesar a datos en formatos diferentes a una base de datos relacional, los programadores requerían usar herramientas y APls específicos para una determinada fuente de datos. Estas APls son completamente independientes unas de otras. El conocer cómo extraer datos de una carpeta de mensajes e-mail no significa que se conozca cómo usar otras APls para trabajar con sistemas de archivos planos. Para cada tipo diferente de fuente de datos, existe un API correspondiente. Esto trae como consecuencia que exista más codigo para el acceso a datos.
La teconolgía OLE DB está diseñada para proporcionar un API común. De hecho, el OLE DB no obtiene los datos directamente desde una fuente de datos, más bien, usa una capa intermedia de software (conocida como "provider") cuya tarea es conocer las características nativas de la fuente de datos específica y presentar los datos a OLE DB en un formato tabular. Todos los tipos de datos pueden ser representados en forma tabular. El dato más simple puede representarse como una tabla de una columna y un renglón.
Los fabricantes de las fuentes de datos (hojas de cálculo, procesadores de palabras, bases de datos, etc) son los encargados de implementar y proporcionar esta capa intermedia de software.
24
OLE 08 puede usar OD8C como un proveedor para accesar bases de datos relacionales.
La ventaja de usar OLE 08 es que el programador solo debe trabajar con un API: OLE 08. Al direccionar a OLE 08 para que use un determinado proveedor, por medio de comandos estándares, es posible obtener datos en un formato fácil de usar para la aplicación.
OLE 08 está diseñado para ser usado con C++. Debido a que la mayoría de los programadores en ambiente Windows trabajan con Visual 8asic u otros lenguajes, Microsoft introdujo una interfaz para OLE 08. Esta interfaz es ADO (ActiveX Data Objetes).
El sistema AS/400 soporta el OLE 08, por lo que, desde lenguajes como Delphi, Visual 8asic, Power8uidler, entre otros, es posible accesar la base de datos 082/400, así como otros recursos del AS/400 como son los procedimientos almacenados, los comandos de control y las colas de datos.
2.4.3.2. ODBC
El OD8C proporciona una interfaz portable que permite que una aplicación pueda interactuar con diferentes bases de datos relacionales.
El origen de esta interfaz está en la problemática de que cada manejador de base de datos usa un método diferente de acceso a los datos [9]. Ante esta diversidad de bases de datos (Oracle, Sybase, Paradox, Access, lnformix, 082, SQL Server, etc) los desarrolladores de aplicaciones tienen que conocer los diferentes tipos de acceso para cada base de datos .. Si una aplicación se desarrolla usando una interfaz propietaria de una base de datos, la aplicación sólo trabaja con esa base de datos. En el momento de querer accesar una base de datos diferente, es necesario modificar el código de la aplicación.
Para solventar esta situación, Microsoft fué la empresa que inicialmente propuso un conjunto de funciones basadas en SQL y escritas en C para accesar cualquier base de datos. El estándar desarrollado se llamó Open Data8ase Connectivity (OD8C). Las funciones de OD8C y la sintaxis de SQL se estandarizaron por las especificaciones X/Open y SQL Access Group.
La mayoría de las bases de datos relacionales, incluyendo a 082/400 soportan el estándar OD8C.
25
2.4.3.3. JDBC
Java tiene su propio mecanismo de acceso a una base de datos relacional: JDBC o Java DataBase Connectivity.
El JDBC es similar a ODBC, pero está completamente escrito en Java (en lugar de C). Sus características son [7]:
• Los desarrolladores escriben sus aplicaciones sin considerar las funciones propias de la base de datos.
• El proveedor de la base de datos proporciona una capa de software que debe ser incluida entre la aplicación y la base de datos.
El uso de JDBC involucra trabajar con:
• Un paquete Java llamado java.sql que contiene clases y métodos para: la conexión a la base de datos, consultas, etc.
• Un JDBC DataBase Driver Manager, que es similar a Driver Manager de ODBC. el JDBC Driver Manager es incluido con el lenguaje Java. EL JDBC Database Driver es proporcionado por el proveedor de la base de datos. Esta pieza permite que una aplicación pueda accesar diferentes bases de datos sin necesidad de modificar el código. Sin embargo, aunque JDBC es neutral a una base de datos, es posible explotar algunas funciones propietarias de la base de datos.
• Un puente JDBC/ODBC que permite que una aplicación Java accese una base de datos por medio de un Driver de ODBC. Esto sólo se requiere si un proveedor de base de datos no cuenta con un JDBC Database Driver.
El elemento clave es que el desarrollador sólo tiene que escribir los accesos a los datos por medio del paquete java.sql. Las clases y los métodos contenidos en este paquete se encargan de direccionar las peticiones de SQL hacia la base de datos específica.
El paquete java.sql es equivalente a las funciones CLI (Call Level Interface). Las funciones CLI son un conjunto de APls para la ejecución de sentencias SQL.
26
2.4.3.4. APPC (Advanced Program to Program Communications).
APPC es un protocolo de comunicaciones que forma parte de la arquitectura SNA de IBM.
Con APPC, el desarrollador de una aplicación tiene el control de las características de seguridad, recuperación de errores y la sincronización de errores. Debido a este control por parte del desarrollador, el APPC es el protocolo indicado para desarrollar aplicaciones cliente/servidor robustas, de misión crítica y de propósito general. Sin embargo, la aplicación no es portable porque los programas "servidores" se codifican en un lenguaje nativo del AS/400.
Los programas "cliente" pueden ser escritos en cualquier lenguaje de Windows que soporte el uso de funciones externas o APls. Algunos lenguajes usados son Visual Basic, C++ y Power Builder.
2.4.3.5. COLAS DE DATOS.
Una Cola de Datos es una especie de tabla que reside en AS/400 y que sirve para almacenar temporalmente datos. Las Colas de Datos son usadas para pasar información de un programa a otro.
Un programa cliente en una computadora personal puede enviar un dato a una Cola de Datos en el AS/400, de esta forma, otro programa nativo del AS/400 puede recibir este dato como parámetro. Con el dato recibido, el programa servidor realiza accesos a la base de datos o cualquier otra función. La información resultante se envía al programa cliente por la misma o por otra Cola de Datos.
Dado que el enlace entre los programas es por medio de una Cola de Datos, no es necesario que los programas corran de manera sincronizada. Tan pronto como un programa coloque el dato en la Cola de Datos, puede continuar con otras actividades.
Esta alternativa es recomendada para el desarrollo de aplicaciones cliente/servidor eficientes. Sin embargo, como en el caso de APPC la aplicación no es portable hacia otras bases de datos.
27
2.4.3.6. SQL REMOTO
El SQL Remoto es un conjunto de APls para accesar a la base de datos del AS/400 por medio de SQL. EL SQL Remoto y ODBC tienen en común el uso de SQL. La diferencia es que el SQL Remoto fué desarrollado sólo para trabajar con la base de datos del AS/400. En cambio ODBC es un estándar portable con distintas bases de datos.
2.4.3. 7. SOCKETS.
Los Sockets proporcionan un mecanismo para la comunicación programa a programa. El intercambio de datos se realiza sobre una red IP (Internet Protocol).
Los orígenes de los Sockets están en el UNIX de Berkeley en 1982. La implementación en el sistema AS/400 se basa en la definición Berkeley 4.3BSD.
La programación por medio de sockets proporciona un rendimiento comparable a la programación con APPC. De hecho, los Sockets y APPC tienen en común que proporcionan al programador un control completo sobre la sesión de comunicaciones. En este tipo de programación, se requiere que cada programa conozca en cada momento el estado de la conversación. Esto trae como resultado que el programa cliente y el programa servidor estén sincronizados. La programación por medio de Sokcets puede resultar compleja pero es la mejor alternativa en el ambiente TCP/IP si se requiere un tiempo de respuesta excelente y si el flujo de datos es complejo [8].
2.5. CONCLUSIONES
Los principales aspectos que buscan resolver los desarrolladores de aplicaciones cliente/servidor en AS/400 son:
a) El rendimiento de la aplicación.
b) Facilidad del desarrollo de la aplicación. Que se traduce en rapidez de desarrollo, baja de costos de desarrollo y mantenimiento, mayor rapidez en entrega de las soluciones a los requerimientos de los usuarios.
28
c) Acceso a la base de datos relacional.
En este trabajo se profundizará en el estudio de las principales interfaces de programación para crear aplicaciones cliente/servidor en AS/400. Las interfaces a estudiar son: interfaces a nivel de transporte (como APPC y Sockets), interfaz de acceso a la base de datos (ODBC) y el uso de Java.
29
CAPÍTULO 3: LA BASE DE DATOS DEL AS/400
La integración es uno de los elementos más importantes de diferenciación del sistema AS/400. Los componentes de seguridad, comunicaciones, base de datos, utilerías de respaldo, etc., están diseñados de una forma integral en el sistema operativo OS/400.
La gran mayoría de las bases de datos corren encima del sistema operativo al mismo nivel que las aplicaciones. Debido a que la base de datos 082/400 está integrada con el sistema operativo, se mejora su nivel de eficiencia además de que se integra completamente con otros componentes. El beneficio es una mayor simplicidad en la administración del sistema.
De hecho, otros desarrolladores de bases de datos han reconocido los beneficios de integrar el D8MS con el sistema operativo [11 ]. Por ejemplo, el sistema operativo de Windows NT incluye el SQL Server como su base de datos integrada.
En la práctica, la integración de 082/400 significa que gran parte de los datos del sistema están almacenados en la base de datos relacional. Además de los datos de las aplicaciones, los esquemas de seguridad, las definiciones de las comunicaciones y hasta el código fuente de las aplicaciones, se encuentran almacenados en la base de datos.
3.1. ANTECEDENTES DE 082/400.
La primera base de datos comercial con características relacionales apareció en 1978 con el Sistema/38 de 18M, que es el equipo predecesor del AS/400. Esta base de datos se anticipó 3 años a otras bases de datos relacionales en la industria.
El origen de las bases de datos relacionales se debe a los trabajos de E.F. Codd en 18M, quien definió una base de datos experimental conocida como System/R. Codd definió 4 operaciones primitivas sobre una tabla de dos dimensines (renglones y columnas). La primera operación se denominó Order, que permitía el procesamiento de los renglones de la tabla en un orden determinado usando una llave.
La segunda operación Selection, permitía la selección de un subconjunto de renglones en base a un valor determinado de la llave. La tercera operación Projection permitía la selección de columnas específicas de la tabla. Finalmente, la cuarta opreación, join, permitía que varias tablas fueran vistas como una sola tabla.
30
De esta forma, una base de datos relacional debería soportar estas 4 operaciones sobre una tabla de dos dimensiones.
El Sistema/38 sólo soportaba las operaciones Order, Selection y Projection. Debido a que en sus inicios este sistema no soportaba la operación Join, se consideró a su base de datos con características relacionales, más no completamente relacional [3].
En 1981, la base de datos System/R fué anunciada como 082 y es reconocida en la industria como la primera base de datos comercial completamente relacional.
3.2. CARACTERÍSTICAS DE 082/400.
Para describir las características generales de 082/400, se tomará como base las funciones que una base de datos relacional debe proporcionar [11], tales como
• Definición y manipulación de los datos. • Seguridad e integridad de los datos: Diarios, Funciones de CommiURollback ,
bloqueos, integridad referencial y triggers) • Funciones adicionales: Soporte a Datos Distribuidos y Procedimientos
Almacenados.
El estudio de las carerísticas de 082/400 será de utilidad para el análisis que se hará en los siguientes capítulos de las diversas opciones de desarrollo de aplicaciones cliente/servidor en AS/400.
3.2.1. DEFINICIÓN Y MANIPULACIÓN DE DATOS.
Los datos se almacenan en objetos llamados archivos físicos o tablas. Las tablas, como en cualquier base de datos relacional, están formadas por una estructura de datos que define el tipo y longitud de las columnas.
La definición de una tabla en 082/400 se puede hacer de dos formas:
a) Por medio de un lenguaje de definición de datos propio del sistema conocido como DOS (Data Description Specifications).
b) Por medio de SOL. Esta es la forma más común en la actualidad para definir la estructura de una base de datos relacional. El 082/400 soporta los estándares internacionales ANSI de SOL, por lo que cualquier desarrollador de aplicaciones en otras plataformas puede definir y trabajar con 082/400.
Aunque hay dos interfaces para la definición, es importante mencionar que sólo se trata de una base de datos.
31
3.2.1.1. ÍNDICES Y VISTAS DE SQL.
Los datos están almacenados físicamente en las tablas. Sin embargo, es común que las aplicaciones y los usuarios requieran accesar datos en un formato diferente al modo como están almacenados en las tablas físicas.
Por medio de una Vista se puede obtener, a patir de una tabla, una selección de columnas y un ordenamiento de datos, sin tener que duplicar los datos en otra tabla. Una Vista no contiene realmente datos, sino apuntadores hacia los datos de una tabla física.
Por otro lado, un índice de SQL proporcionan una acceso por medio de llave a los renglones de una tabla.
Los Archivos Lógicos ó Vistas proporcionan la independencia entre los datos y las aplicaciones. La separación de la descripción de los datos de los programas permite que en los programas no se tenga que volver a definir los datos. De esta forma, la creación y mantenimiento de las aplicaciones se simplifica.
El sistema mantiene las descripciones de todos las tablas, vistas e índices por medio de catálogos. Otro término común para este repositorio es el diccionario de datos. El manejador de base de datos se encarga de actualizar el diccionario de datos cada vez que se crea o modifica un objeto de base de datos, de tal forma que los desarrolladores puede consultar la estructura de los datos y en qué aplicaciones se usa determinada tabla o vista.
3.2.2. SEGURIDAD E INTEGRIDAD DE DATOS.
La integridad de la datos es un aspecto crucial para cualquier empresa. En un ambiente donde varios usuarios accesan y modifican los datos de forma simultánea, es posible que los datos pierdan su integridad. La base de datos 082/400 proporciona diversas facilidades para garantizar la integridad de los datos.
3.2.2.1. DIARIOS.
Un Diario ó Journal es un registro de los cambios realizados a las tablas. Cuando una aplicación modifica un renglón, el sistema guarda una copia de los datos en el Diario, incluyendo más información relacionada, como usuario, aplicación, fecha y hora.
Los Diarios de la base de datos se usan para la recuperación de fallas del sistema o de problemas de datos ocasionados por las aplicaciones. Las tablas son recuperadas automáticamente cuando el sistema se arranca después de una falla de hardware o software.
32
3.2.2.2. FUNCIONES DE COMMIT Y ROLLBACK.
En la práctica, los usuarios ejecutan operaciones en donde una serie de sentencias SQL están relacionadas entre sí. Por ejemplo, para surtir un pedido de un cliente, pueden existir tres archivos: una tabla de inventario contiene las existencias de los productos, otra tabla contiene las ordenes y una tercera contiene el monto a facturar al cliente por la orden. En este caso, una surtido de ordenes consiste en:
- un decremento en las existencias en el archivo de inventario, - añadir un registro en la ordenes para control del embarque, y - añadir un registro para el control de la facturacion al cliente.
Para el usuario un pedido consiste de una sola operación, sin embargo, ocurren varios cambios en la base de datos. Para este ejemplo, las sentencias SQL ejecutadas son un UPDATE y dos INSERTs
Si ocurre un error durante la operación, es inaceptable para la empresa que las existencias hayan disminuido sin que se realice la programación del embarque de la orden ó que no se registre el monto a facturar al cliente. La serie de operaciones deben de realizarse complatemente.
Desde luego, por medio de la lógica lf Then se pueden controlar las operaciones, y de alguna manera relacionar las sentencias SQL. Se puede también modificar la secuencia de las sentencias para detectar el estado del crédito del cliente o para verificar las existencias antes de registrar la orden. Esto requiere de más codificación. En ciertos casos, cuando se detecta un error es necesario deshacer los cambios ya hechos a los archivos.
Desde luego, por programación se pueden también relacionar las sentencias SQL e, inclusive, modificar su secuencia para detectar primero si el cliente tiene crédito antes de colocar la orden.
En suma, por medio de estas técnicas de programación se pueden detectar algunos errores y condicionar o deshacer cambios ya efectuados a los archivos. Esto requiere de más codificación pero se pueden a evitar errores comunes. Sin embargo, no es posible controlar cada posible error, por lo que la transacción aún puede verse interrumpida por otra clase de eventos, como errores en las comunicaciones o fallas en el servidor.
En este escenario, para evitar que una transacción quede incompleta, se debe usar la facilidad del DBMS para el manejo de transacciones conocida como Control de Compromiso.
33
Una transacción es un conjunto de operaciones que deben ser terminadas como si se tratara de una operación única. De esta forma, o se realiza completamente o no se realiza ninguna operación. A este enfoque se le conoce como "todo o nada"
El Control de Compromiso es una función del DBMS que permite definir un conjunto de cambios como una Unidad Lógica de Trabajo o transacción.
En caso de que la transacción se vea interrumpida, la aplicación puede ser iniciada nuevamente con la garantía de que no hay actualizaciones parciales en la base de datos.
Para el manejo de transacciones, una aplicación debe usar las siguientes sentencias:
COMMIT: Con esta sentencia, la aplicación indica que la transacción ha terminado exitosamente y confirma al DBMS todos los cambios efectuados en esa unidad lógica de trabajo.
ROLLBACK: Con esta sentencia, la aplicación indica explícitamente al DBMS que se deben deshacer los cambios efectuados en la unidad lógica de trabajo. En este caso, la aplicación ha detectado algún error por lo que la transacción debe terminar.
Si un error no monitoreado por el programa ocasiona que la transacción se termine abruptamente, el DBMS efectúa un ROLLBACK implícito para deshacer los cambios ya efectuados en la transacción.
Para hacer uso de la facilidad del Control de Compromiso, es necesario implementar la función de Diario explicada anteriromente. Los archivos que son modificados en una transacción deben estar bajo la función del Diario. De esta forma, si la aplicación actualiza un registro en un archivo de inventarios, el registro permanece bloqueado hasta que la aplicación confirme con COMMIT que la transación ha terminado.
Si en lugar de COMMIT, la aplicación efectúa un ROLLBACK o bien, si la transacción es interrumpida por un error, el DBMS hace uso del Diario para encontrar cuál era el contenido del registro antes del cambio y regresa esta información al archivo. De esta manera, se dice que el cambio se "deshace".
3.2.2.3. MANEJO DE BLOQUEOS.
Una consideración adicional en el manejo de transacciones es lo relativo a los conflictos potenciales cuando varias transacciones intentan accesar los mismos datos al mismo tiempo. Si se asume que la transacción A está ejecutando una serie de operaciones (Select, Updates, etc.) y que estos cambios aún no se han comprometido (Commit), y simultáneamente, otra transacción B lee la información con la cual la transacción A está trabajando. ¿ Qué pasa con los datos si la transacción B termina con Commit pero la transacción A deshace (Rollback) los cambios?
34
Existen básicamente tres tipos de problemas potenciales que pueden ocurrir con las transacciones concurrentes. En la literura de base de datos, a estos casos se les conoce como: Lecturas "basura", Lecturas sin repetición y Lecturas de registros fantasma.
Una Lectura "basura" se presenta en la siguiente secuencia de eventos:
a) Una transacción A efectúa una actualización a un registro, pero el cambio aun no se confirma con Commit.
b) Una transacción B efectúa una lectura al registro que acaba de ser actualizado por la transacción A.
c) La transacción A deshace (RollBack) el cambio, por lo tanto, la transacción estará trabajando con información inválida.
La Lectura no repetible (leer un registro que luego es cambiado por otra transacción) se presenta cuando:
a) Una transacción A efectúa un acceso de lectura a un registro.
b) La transacción B actualiza o borra el registro y termina confirmando la operación (COMMIT).
c) La transacción A estará trabajando con datos inválidos o inexistentes .
Este problema se conoce como Lectura no repetible debido a que si la transacción A vuelve a leer el registro, no se repetirá el mismo resultado pues el registro fué cambiado o borrado por la transacción "B".
Este problema se evita si el DBMS no permite que el registro leido por "A" pueda ser cambiado o borrado por otra transacción "B".
La lectura de registros fantasmas se presenta cuando:
a) La transacción A efectúa una lectura de un conjunto de registros que satisfacen una condición, por ejemplo:
Select * from Proveedores where Fecha_Alta > "1999-12-02"
b) La transacción B inserta uno o varios registros que satisfacen la condición de selección de la transacción A.
c) El usuario A está trabajando con datos incompletos.
35
Este problema se evita si el DBMS pone un bloqueo a la tabla completa utilizada por la transacción A.
Para evitar estos conflictos de integridad, es necesario definir a la base de datos que maneje un nivel de aislamiento entre las transacciones.
El nivel de aislamiento determina el grado con el cual un grupo de sentencias SQL (transacción) se aisla de otras transacciones concurrentes.
Existen diferentes grados de niveles de aislamiento. Por ejemplo, cuando un usuario A ejecuta una transacción, el nivel de aislamiento determina:
• El grado de disponibilidad que otros usuarios concurrentes tienen sobre los registros leidos y cambiados por el usuario A.
• El grado de disponiblidad que el usuario A tiene sobre los registros leidos y cambiados por otros usuarios concurrentes.
• El tipo y duración de los bloqueos que la base de datos pone a los datos.
Los tipos de bloqueos pueden ser:
Bloqueo Compartido (Share): Si el DBMS pone un Bloqueo Compartido a un registro utilizado en una transacción A, significa que otra transacción B puede tener un acceso de solo-lectura al registro. Al Bloqueo Compartido también se le conoce como bloqueo tipo *READ en AS/400.
Bloqueo Exclusivo: Si el DBMS pone un Bloqueo Exclusivo a un registro utilizado en una transacción A, significa que otra transacción B no puede actualizar o borrar el registro. Tampoco se permite una lectura para actualización. El nivel de aislamiento de la transacción B determina si puede o no tener un acceso de solo-lectura al registro. Al bloqueo exlusivo también se le conoce como bloqueo tipo *UPDATE en AS/400.
3.2.2.4. INTEGRIDAD REFERENCIAL.
La Integridad Referencial es un conjunto de mecanismos por medio de los cuales el manejador de la base de datos asegura el cumplimiento de reglas de integridad entre las tablas.
Un ejemplo típico de una regla de integridad ocurre entre una tabla de clientes y una tabla de facturas. No resulta lógico el tener facturas que no tengan relación con un cliente, es decir, cada factura debe hacer referencia a un cliente. Como consecuencia de esta regla, si un usuario intenta borrar un cliente que tiene facturas, la transacción
36
no se debe poder efectuar. Una forma de hacer cumplir esta regla es por medio de rutinas en la aplicación. Sin embargo, gracias a la integridad referencial, esta clase de reglas se pueden definir directamente al manejador 082/400. Una vez que las reglas han sido definidas, el 082/400 automáticamente verifica su cumplimiento, sin importar el medio usado por el usuario para efectuar el cambio.
La Integridad Referencial es, por tanto, una facilidad a nivel DBMS que evita que las reglas de integridad tengan que ser verificadas a nivel de las aplicaciones.
3.2.2.5. TRIGGERS.
Un Trigger se define como una acción que ocurre automáticamente siempre que se hace un cambio a una tabla. De esta forma, los Triggers son programas asociados a una tabla.
En ciertos casos, al efectuar una actualización, inserción o borrado de datos, se requiere que ocurra alguna otra acción. Por ejemplo, una actualización a una tabla de inventarios puede ocasionar que la cantidad de artículos en existencia caiga por debajo de un valor preterminado. Un Trigger en esta tabla podría ser un programa que verifique el valor y que tramite el pedido al proveedor en caso de ser necesario.
Cuando se especifica un Trigger a una tabla se deben definir tres atributos. El primero es el evento que dispara al programa. Los eventos pueden ser: una actualización, una inserción ó un borrado de un renglón de la tabla. El segundo atributo define en qué momento se ejecuta el programa: antes o después del evento. Finalmente, el tercer atributo define el nombre del programa a ejecutarse. De esta forma, se deduce que se pueden especificar hasta 6 Triggers por cada tabla.
3.2.3. SOPORTE DE DATOS DISTRIBUIDOS.
Cada vez más las compañías están organizando sus sistemas de información en un modo distribuido. La base de datos 082/400 proporciona diferentes opciones para operar con bases de datos remotas.
La arquitectura DOM (Distribuited Data Management) es la método nativo para el acceso a datos remotos entre equipos AS/400.
Por otro lado, la arquitectura DRDA (Distribuited Relational Database Architecture) permite usar al lenguaje SQL como medio para accesar tablas remotas. Esto significa que una aplicación escrita con SQL puede accesar datos de otro AS/400 o de un Mainframe con 082. Otros manejadores de base de datos que soportan DRDA son lnformix, lngres y Oracle.
37
Existen también otras interfaces para accesar los datos de 082/400 desde aplicaciones cliente/servidor, como son ODBC, OLE/DB, JDBC, etc. A lo largo de este trabajo se profundizará en el estudio de estas interfaces.
3.2.4. PROCEDIMIENTOS ALMACENADOS.
Los procedimientos almacenados se utilizan para mejorar el rendimiento de las aplicaciones distribuidas. Al usar los procedimientos almacenados se reduce significativamente el tráfico de información entre el programa cliente y el servidor.
Un procedimiento almacenado es un programa que se ejecuta en el AS/400. La característica que hace especial a este programa en relación a otros, es la forma en que se llama. Este programa se invoca por medio de SQL usando la sentencia CALL.
El propósito fundamental de los procedimientos almacenados es permitir que una aplicación basada en SQL pueda llamar a un programa en un sistema remoto. Por lo tanto, los procedimientos almacenados no solo se usan en aplicaciones cliente/servidor con el AS/400, sino también en aplicaciones distribuidas entre varios sistemas AS/400, o bien, entre un AS/400 con otras bases de datos relacionales.
El programa en el AS/400 puede ser implementado de dos formas:
a) Usar cualquier lenguaje de programación soportado en AS/400.
Los lenguajes son C, C++, CL, RPG, COBOL, FORTRAN, PASCAL y REXX. Este tipo de procedimientos almacenados se conocen como procedimientos externos. Para las operaciones de entrada/salida con la base de datos se pueden usar las funciones nativas del lenguaje, o bien, incorporando sentencias SQL dentro del programa.
Esta opción proporciona la flexibilidad de usar un lenguaje familiar para los diseñadores tradicionales en el AS/400. Sin embargo, debido a que el procedimiento almacenado está implementado por un lenguaje que usa métodos nativos de acceso a los datos, su uso ocasiona que una aplicación pierda portabilidad. En una situación determinada, es necesario evaluar las ventajas del rendimiento contra la pérdida de portabilidad para decidir la implementación por medio de un lenguaje familiar en el AS/400.
b) Procedimientos almacenados con SQL puro.
La mayoría de las bases de datos relacionales soportan un lenguaje procedural SQL para codificar los procedimientos almacenados. El estándar SQL3 de ANSI indica las reglas para crear procedimientos almacenados portables usando el lenguaje SQL. Este tipo de procedimientos se conocen como Procedimientos SQL
38
3.2.4.1. USO DE PROCEDIMIENTOS ALMACENADOS.
Antes de usar un procedimiento almacenado desde una aplicación cliente, se deben realizar estos pasos:
1. Codificación del procedimiento almacenado.
El programa que va ser un procedimiento almacenado puede ser codificado con cualquier lenguaje de programación mencionado anteriormente, incluyendo el SPL (SQL Procedure Language) disponible a partir de a versión V4R2 del sistema operativo OS/400.
Por lo general, es de esperar que exista un intercambio de información, por lo que el programa debe codificarse tomando en cuenta los parámetros de entrada (recibidos desde el cliente) y los parámetros de salida (enviados al cliente). Sin embargo, pueden existir procedimientos almacenados que no usen parámetros, aunque su uso no es común.
2. Definición del Procedimiento Almacenado
Cuando el programa ya está codificado y compilado, el siguiente paso consiste en definir a la base de datos 082/400 que este programa será un procedimiento almacenado. De esta forma el programa queda habilitado para ser invocado por medio de la sentencia CALL de SQL.
El proceso de definición se conoce como "creación" del procedimiento almacenado y se efectúa por medio de la sentencia CREATE PROCEDURE.
3.3. CONCLUSIONES.
La base de datos 082/400 soporta la mayoría de los estándares de industria actuales. Esto permite la interoperabilidad con equipos de diversas arquitecturas. Por otro lado, esta apertura permite también que el desarrollador de aplicaciones con 082/400 cuente con diversas alternativas para plantear su estrategia de diseño de las aplicaciones distribuidas. En los siguientes capítulos se utilizan los conceptos estudiados aquí (Triggers, procedimientos almacenados, etc.) para describir con más detalle las opciones de cliente/servidor con 082/400.
39
4.1. ANTECEDENTES DE JAVA.
Aunque el Java puede ser visto solamente como un nuevo lenguaje de programación fácil de aprender y depurar, su principal ventaja es la portabilidad a través de diferentes plataformas de cómputo.
La portabilidad del Java se logra por medio de las clases ( o APls) que proporcionan un gran conjunto de funciones independientes de una plataforma. La existencia de este conjunto de APls de Java proporciona a la industria de informática con la capacidad de desarrollar aplicaciones cliente/servidor en internet que pueden correr en cualquier plataforma que soporte Java [1 O). Por lo tanto, el Java no es solamente un nuevo lenguaje sino una plataforma de software que puede ser implementada y ejecutada en diversas plataformas.
Java es un lenguaje orientado completamente a objetos. La sintaxis de Java es similar a C++, aunque su comportamiento es más parecido a Smalltalk.
El Java se creó inicialmente como un lenguaje para programar los microprocesadores incluidos en los dispositivos electrónicos. La idea no era crear un nuevo lenguaje sino efectuar mejoras a C++ (el lenguaje más usado para crear aplicaciones orientadas a objetos). El C++ tiene la característica de permitir tener interfaces con las funciones de bajo nivel de la computadora.
Los desarrolladores de Java querían crear un lenguaje que fuera más fácil de usar que el C++. Por lo tanto, decidieron que los programas Java no fueran capaces de manejar el direccionamiento de áreas específicas de memoria. En su lugar, es posible usar apuntadores de alto nivel para indicar al sistema este tipo de requerimientos. El sistema operativo determina la dirección real cuando el programa se ejecuta.
La intención de Java no es reemplazar a C++. Las aplicaciones que necesitan accesos de bajo nivel continuarán usando C++. De hecho, el C++ es más usado como un lenguaje "de sistema" para crear compiladores y otras herramientas. En general, este lenguaje no es usado por las áreas de sistemas para crear aplicaciones comerciales. La curva de aprendizaje necesaria para que un programador desarrolla su primera aplicación de cuentas por cobrar es demasido larga. Esto no significa que el lenguaje no pueda ser usado para crear aplicaciones comerciales, pero es más usado por
40
proveedores ó casas de software que por desarrolladores locales dentro de una empresa [7].
A parte de simplificar la programación, otro objetivo del Java es permitir que el mismo programa pueda ejecutarse en diferentes plataformas. Sobre todo debido a que existen diferentes tipos de procesadores. La solución para cumplir con este requerimiento es incluir una capa adicional de software en cada dispositivo que pudiera traducir el código en instrucciones de máquina. Esta capa es llamada JVM (Java Virtual Machine)
Además de estas características, Java fué el primer lenguaje de computación desarrollado con capacidades de red. Se asumió que los programas escritos en Java necesitarían correr en diferentes tipos de dispositivos remotos conectados por medio de una red. Por lo tanto, se decidió que los programas de Java serían traducidos en una forma intermedia, llamada bytecode, que podría ser enviado eficientemente a lo largo de la red.
De esta forma, los programas escritos en Java son compilados en un formato bytecode y luego enviados a dispositivos que los ejecutan. Dentro del dispositivo existe una máquina JVM que maneja la ejecución del programa.
Este diseño tiene una desventaja: la interpretación del formato bytecode en tiempo de ejecución ocasiona que el proceso sea menos eficiente que si tomara la alternativa de ejecutar un código que es compilado en instrucciones de máquinas específicas para cada procesador. Sin embargo, conforme el precio-rendimiento de las computadoras siga avanzando, la nueva tecnología tiende a compensar este factor.
El Java ha sido desarrollado al mismo tiempo que el internet se ha popularizado, por lo que se han convertido en tecnologías inseparables. Actualmente la mayoría de los navegadores de internet incluyen a la máquina JVM. Los programas de Java que están incorporados dentro de las páginas Web y que corren en un navegador se denominan applets. Como resultado, el Java se ha convertido en el lenguaje más usado para añadir lógica de programación a las páginas Web.
El lenguaje Java permite desarrollar aplicaciones de negocio robustas debido a las características de variedad de definiciones de tipos de datos y al no permitir el direccionamiento de memoria por medio de apuntadores, además de las funciones de
"limpieza" automática de áreas de memoria [7], como se explicará más adelante.
41
4.2. CONTROL DE JAVA.
La empresa Sun Microsystem inventó el Java y es quien mantiene el control sobre la evolución de este lenguaje por medio de una subsidiaria llamada JavaSoft.
Dentro de los estándares que JavaSoft mantiene están el paquete de desarrollo JDK (Java Development Kit), la máquina vitual JVM y las especificaciones para el diseño de JavaBeans y EJB (Enterprise JavaBeans).
La máquina JVM es la pieza central del ambiente Java ya que es la responsable de ejecutar las aplicaciones Java en un ambiente específico de hardware. La máquina JVM sí es dependiente de una plataforma.
El paquete JDK incluye especificaciones para los compiladores de Java, así como ayudas para el desarrollo de aplicaciones y un conjunto de utilerías requeridas en un ambiente de programación de Java en cualquier computadora que sea utilizada para desarrollo.
Los JavaBeans permiten la creación de componentes reusables. Se enfocan al diseño de componentes gráficos para un ambiente de desarrollo visual en computadoras clientes. Por ejemplo, un JavaBean puede ser un objeto tan sencillo que crea una lista en la pantalla. O bien, en el otro extremo, un JavaBean puede ser una aplicación sofisticada como un sistema de control de fechas o un procesador de palabras. Actualmente existen miles de JavaBeans creados por diferentes proveedores.
E\ EJB es una especificación escrita para la creación de componentes del lado de los servidores. Estos componentes se requieren para manejar funciones como el control de transacciones, accesos a la base de datos ó administración de memoria. Estos componentes proporcionan las funciones necesarias para crear la parte servidora de las aplicaciones.
Otra iniciativa de JavaSoft, que está orientada a mejorar el rendimiento de Java, se llama HotSpot [12]. Frecuentemente en un programa existen objetos que se invocan varias veces. En Java existen límites definidos en la máquina JVM para las llamadas a los objetos de uso frecuente. Cuando un programa excede el límite de llamadas, el JVM usa una técnica llamada inlining. En lugar de repetir todos los pasos para cargar el código, la máquina JVM toma una vía directa, lo cual ahorra tiempo y recursos.
42
4.3. SOPORTE DE JAVA EN AS/400
El ambiente de Java y el AS/400 tiene una afinidad en su arquitectura. Tanto Java como AS/400 utilizan una interfaz de máquina de alto nivel [5]. En el AS/400 esta interfaz se conoce como TIMI (Technology lndependent Machine Interface).
El software de control del AS/400 es creado en dos capas. La capa de bajo nivel, llamado SLIC (System Licensed Interna! Code) contiene toda la lógica que depende de las características específicas del hardware. La capa superior, llamada OS/400, mantiene una interfaz con las aplicaciones y los usuarios (figura 4.1. ).
Figura 4.1. Ambiente de Java en AS/400
Aplicaciones en Java (Bytecode)
Hardware
Java se basa exactamente en el mismo concepto, pero con diferentes términos. El término bytecode es usado para describir la interfaz de alto nivel que el lenguaje Java usa para comunicar las funciones que el hardware debe realizar. Existe otra capa de software de bajo nivel llamada JVM ( Java Virtual Machi ne) que convierte el bytecode
43
en instrucciones de máquina. Esta estructura permite que los programas corran en diferentes computadoras.
La afinidad entre Java y el AS/400 no se limita solamente a la similitud en su diseño, sino también en el uso de la tecnología de objetos. En el AS/400 todo es un objeto, y el sistema reconoce que solamente ciertas operaciones son válidas para cada tipo de objeto. De la misma manera, una de las fortalezas de Java es su soporte a la programación orientada a objetos.
El Java está soportado en el AS/400 a partir de la versión 4.2 del sistema operativo, a principios de 1998. Con esta versión, el OS/400 tiene la capacidad de manejar los threads. Por medio de los threads, que es un mecanismo común en plataformas Unix, se logra la multitarea de las aplicaciones. Un proceso puede ser subdividido en varias operaciones simultáneas. En servidores con múltiples procesadores, los threads incrementan el rendimiento al dividir las tareas entre todos los procesadores.
La decisión más importante de los desarrolladores del AS/400 consistió en determinar de qué forma se debería implementar la máquina JVM. En otras computadoras la JVM corre al mismo nivel que otras aplicaciones. La alternativa más fácil pudo haber sido implementar a la máquina JVM bajo el control del sistema operativo [7]. Sin embargo, con esta alternativa no se aprovecharían las ventajas de la afinidad entre Java y la arquitectura del AS/400. Por lo tanto, se decidió crear una JVM a un nivel de microcódigo (capa SLIC).
Al tener que integrar la máquina JVM dentro de la capa SLIC, fué necesario reescribir las especificaciones de JVM en C++ ya que el micródigo del AS/400 está escrito en este lenguaje. La ventaja de