t\lt!UU: t:, _, ;,.

'\)"t. ~SlUD!os J'.

~' --- ~$:;, ~ ·· 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

ELISEO ARMANDO HERNÁNDEZ MARTÍNEZ

MAESTRÍA EN SISTEMAS DE INFORMACIÓN MSI 87

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

ELISEO ARMANDO HERNÁNDEZ MARTÍNEZ

Asesor: M.C. Ralf Eder Lange

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

CAPÍTULO 1: ANTECEDENTES Y OBJETIVOS

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

8 10 13 13

15

15 16 17 20 28

30

30 31 39

40

40 42 43 45 46

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

7

CAPÍTULO 1. ANTECEDENTES Y OBJETIVOS.

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.

d) ODBC (Open Data Base Connectivity)

e) SQL Remoto

f) DAL

g) Sockets.

h) OLE DB y ActiveX Data Objects (ADO)

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

1.3. OBJETIVOS.

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

Datos Datos

L.óg ic:a L.óg ic:a

SERVlDOR

Red

CLIENTE

L.óg ic:a

Presentación Presentación Presentación

Presentación Presentación Lógica Distrib..Jida Remota Distrib..Jida

1) Presentación Distribuida

Datos

Lógica

Presentación

Datos Remotos

Datos

Datos

L.óg ic:a

Presentación

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. INTERFACES DE ACCESO A DATOS

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

Existen diferentes lenguajes de programación para producir aplicaciones cliente/servidor, de la misma manera existen diferentes interfaces de programación para accesar los recursos del servidor. Estas interfaces fueron analizadas de manera general en este capítulo.

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

CAPÍTULO 4: APLICACIONES CON JAVA

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)

Sistema Operativo OS/400

-TIMI

Máquina Virtua Java (JVM)

Código interno SLIC

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 este enfoque es el incremento en el rendimiento al ejecutar las aplicaciones.

Una de las diferencias más importantes entre las diferentes implementaciones de JVM es de qué forma manejan la función llamada Garbage Collection. Esta función se requiere debido a que en Java los programadores no pueden indicar el sistema en qué momento un objeto deja de usarse. Gradualmente la memoria se va llenando de objetos que ya no son accesados. La JVM tiene que determinar periódicamente qué objetos deben ser eliminados de memoria. La especificación proporcionada por Sun no dice de forma precisa cómo se debe realizar esta tarea.

Para resolver este problema, la mayoría de las JVM periódicamente detienen todos los procesos (threads) concurrentes para que el sistema realice la limpieza de memoria. Mientras esto ocurre, no se pueden crear nuevos objetos. En un ambiente de varios procesadores, la tarea de Garbage Collection detiene todos los procesos. Esto impacta al rendimiento general del sistema [5].

44

El enfoque usado en AS/400 es concurrente, permitiendo que los propios threads participen en identificar a los objetos que deben eliminarse. Debido a que todos los threads contribuyen en la función de limpieza, no es necesario detener el proceso de crear nuevos objetos, lo cual resulta en un mejor rendimiento.

4.4. ESTRATEGIAS DE DISEÑO CON JAVA EN AS/400.

Existen diversas alternativas para utilizar a Java en el diseño de las aplicaciones en AS/400. El Java puede jugar un papel en las siguientes partes de una aplicación:

El cliente: el código en el cliente puede iniciarse por medio de un comando, en este caso se trata de una aplicación en Java. O bien puede ser arrancado por medio de un navegador Web si se trata de un applet. El código en el cliente se encarga de manejar la interfaz con el usuario.

El servidor: En esta parte, el Java es utilizado como un lenguaje para aplicaciones de negocio, con funciones de acceso a la base de datos, proceso batch y generación de reportes. Es decir, el AS/400 juega el papel de servidor de base de datos y/o servidor de aplicaciones.

El código Java en el servidor no se encarga de llamar directamente a las funciones de interfaz gráfica. Lo anterior se debe a que en servidores como AS/400 solamente se pueden correr aplicaciones Java y no applets (los cuales sólo corren en navegadores Web). Las aplicaciones formadas con applets pueden residir en el AS/400 y al momento de ejecución son bajadas a los navegadores para su ejecución.

Las consideraciones ha tomar en cuenta para modernizar o escribir una aplicación Java en AS/400 son:

• Acceso a la base de datos desde Java, ya sea desde el código cliente o desde el código servidor.

• Llamadas a rutinas (métodos) entre el código cliente y el servidor.

• Comunicación entre el código Java en el servidor con aplicaciones existentes en el AS/400 escritas en otros lenguajes.

• Comunicación entre el código Java en el cliente con aplicaciones existentes en el AS/400 escritas en otros lenguajes.

• Manejo de aplicaciones Java por medio de internet

45

Como se puede observar, existen varios factores que determinan el tipo de aplicación cliente/servidor resultante. Para simplificar este análisis, a continuación se describen los 5 modelos típicos en que una aplicación de Java puede desarrollarse en AS/400.

4.5. MODELOS DE APLICACIONES.

Los diferentes escenarios [7] para escribir aplicaciones Java en AS/400 se pueden ver en la figura 4.2.

Figura 4.2. Modelos cliente/servidor soportados con Java en AS/400

Oa1Ds Oa1Ds Oa1Ds Oa1Ds Oa1Ds

OP JOBC OPC JOBC JOBC DOM JOBC DOM DOM DOM

Lógica Lógica

Remoto SERVIDOR

htemet, B4ranet . ntranet

RMI RMI CLIENTE Oa1Ds

Lógica Lógica Lógica

Presentació Presentación Presentación Presenta ció

Preserhci én Presert:a ción Lógc:a O:atos Datos OistribLi da Remd:a OistribLi da Remdos OistribLi oos

En cada alternativa, existen dos elementos físicos: el sistema cliente y el sistema servidor. La aplicación es segmentada en tres partes (capas) lógicas:

• Presentación: formada por la interfaz de usuario.

• Lógica: Consiste del código de la aplicación para cálculos, acceso a la base de datos, reporteo, etc.

• Datos: capa consistente del repositorio de datos (tablas y vistas)

46

Debido a la portabilidad, cualquier capa puede ser implementada dentro de servidor o en el cliente, dependiendo de qué plataforma de hardware sea la más apropiada.

4.5.1. ALTERNATIVA 1: PRESENTACIÓN DISTRIBUIDA.

En este modelo, todas las partes de la aplicación (datos, lógica y presentación) corren en el servidor. Este caso ocurre generalmente en equipos con interfaz gráfica propia, como en servidores NT.

El AS/400 soporta completamente este modelo con el fin de que una aplicación Java existente en otra plataforma se pueda migrar. Sin embargo, al no contar con una interfaz gráfica propia, todas las llamadas de la aplicación a los métodos de interfaz son interceptadas por el AS/400 y enviadas al cliente. La función que el AS/400 utiliza para manejar los accesos a la interfaz se llama Remate AWT (Remate Abstract Window Toolkit).

Para comprender el mecanismo usado para soportar este modelo en el AS/400 a continuación se describen los conceptos AWT y AWT Remoto [12].

4.5.2.1. AWT

El soporte AWT (Abstract Window Toolkit) es un paquete proporcionado por el lenguaje Java para crear interfaces gráficas. Esta biblioteca o paquete de componentes permite que los desarrolladores diseñen interfaces gráficas que puedan correr en cualquier plataforma. La primera versión de JDK incluía a un AWT que creaba las interfaces usando funciones propias del sistema operativo, esto traía un impacto negativo en la aplicación debido al número de clases requeridas en el proceso de construcción de las interfaces. Las limitaciones de la primera versión se han resuelto en la versión 1.2. de JDK por medio del paquete llamado JFC (Java Foundation Classes).

Estas nuevas funciones están escritas totalmente en Java en lugar de usar las APls de cada sistema operativo, además de incluir una amplia gama de funciones para crear interfaces gráficas.

En la actualidad, existen diversas herramientas de diseño que permiten crear la interfaces a partir de componentes gráficos. Dentro de estas herramientas están el Visual Composition Editor que es parte del producto VisualAge far Java, o bien las herramientas visuales del JBuilder de Borland. Estos paquetes de diseño generan a su vez el código Java que usa finalmente las funciones AWT.

47

4.5.2.2. SOPORTE REMOTO DE AWT.

Si una aplicación existente desarrollada en Java con interfaz gráfica (y que, por lo tanto, hace uso de las funciones AWT) se desea portar hacia el AS/400, es necesario hacer uso de la función conocida como AWT Remoto.

La función AWT Remoto es una implementacion de AWT que permite que las aplicaciones de Java puedan correr sin cambios en servidores que no tienen una interfaz gráfica propia.

El soporte AWT Remoto es un conjunto de funciones de Java que se basan en la función RMI del JDK. El concepto RMI se estudia en la sección 4.5.3. (lógica distribuida).

En la figura 4.3. se muestra la implementación del AWT Remoto.

Figura 4.3. Soporte de AWT Remoto

Interface Gráfica

Servidor

Aplicación Java

APls deAWT APls deAWT

Soporte AWT Remoto Soporte AWT Remoto

APls de RMI APls de RMI

48

La aplicación Java en el servidor usa las funciones estándares de AWT para generar la interfaz gráfica. Sin embargo, como el AS/400 no tiene el soporte gráfico, cada llamada a una función AWT es enviada al soporte AWT Remoto. El soporte AWT Remoto usa a RMI para comunicarse con su función equivalente en el sistema cliente.

En el sistema cliente, el soporte AWT Remoto pasa todas las peticiones AWT que son recibidas desde el servidor a la función estándar AWT.

El soporte estándar AWT en el sistema cliente muestra la interfaz gráfica en la pantalla local. Las interacciones del usuario con el dispositivo apuntador y el teclado tienen un flujo con dirección opuesta.

Como se puede ver en la figura 4.3., la trayectoria de los datos al implementar el AWT Remoto es compleja. De hecho, la intención de soportar el AWT Remoto es permitir la portabilidad de aplicaciones Java desde otros sistemas hacia el AS/400.

La función del AWT Remoto no se recomienda para soportar aplicaciones que hagan uso extensivo de las interfaces gráfica. Tales aplicaciones deben ser diseñadas usando los otros modelos de cliente/servidor mostrados en la figurara 4.2.: el lado cliente de la aplicación usa AWT estándar para trabajar con las interfaces del usuario e interactúa con el servidor por medio de las funciones RMI.

Por ejemplo, un modelo recomendado es de Lógica Distribuida. Este diseño es más directo ya que el soporte RMI es usado solamente para comunicar la parte servidora con la parte cliente. Las funciones AWT son usadas en el lado del cliente que es en donde se lleva a cabo la interacción con el usuario. En este caso, no hay operaciones de tipo AWT ejecutadas en el servidor.

4.5.2. ALTERNATIVA 2: PRESENTACIÓN REMOTA (APLICACIONES WEB).

En este caso, "la lógica y los datos de la aplicación residen en el servidor. La presentación ó interfaz del usuario están en el cliente.

Un ejemplo práctico consiste de una aplicación en Java que es accesada por usuarios remotos por medio de una página Web. Los applets son bajados desde el servidor y se encargan de manejar la interfaz del usuario y de invocar a métodos remotos en el servidor.

En este ambiente, al existir código Java corriendo en el cliente y en el servidor, se usa el soporte de RMI para invocar a los métodos remotos.

49

4.5.3. ALTERNATIVA 3: LÓGICA DISTRIBUIDA.

Bajo el modelo de lógica distribuida, se pueden presentar dos opciones, dependiendo si el código en el servidor se escribe con Java o con otro lenguaje.

4.5.3.1. CON CÓDIGO JAVA EN EL SERVIDOR.

En esta alternativa, existe código en Java tanto en el cliente como el servidor. La aplicación debe utilizar las funciones de RMI (Remote Method lnvocation) para que la parte cliente en Java pueda comunicarse e intercambiar objetos con el código Java en el servidor, como si estuvieran en una misma máquina.

El RMI permite que un objeto corriendo en una máquina virtual pueda enviar mensajes hacia otro objeto de Java corriendo en otra máquina virtual de Java en un sistema remoto. De esta forma, el soporte RMI es utilizado para crear aplicaciones distribuidas con Java.

El RMI permite que una aplicación local pueda llamar a métodos y accesar variables dentro de una aplicación remota, e intercambiar objetos através de una conexión de red.

El objetivo de RMI es integrar un modelo de objetos distribuidos sin complicar el lenguaje y sin cambiar el modelo de objetos actual. Logrando que la interacción con un objeto remoto sea tan fácil como con uno local. El uso más común de RMI es en ambientes tradicionales de cliente/servidor en donde el código Java en el servidor recibe los requerimientos de uno o varios clientes en Java.

El código Java corriendo en el servidor puede usar las siguientes funciones para trabajar con los recursos del servidor:

• Usar JDBC para el acceso a la base de datos y/o para llamar a procedimientos almacenados en el mismo servidor

• Usar la función DPC (Distribuited Program Call) del paquete AS/400 Toolbox, para llamar a cualquier programa.

• Usar la función Record Level Access DOM del paquete AS/400 Toolbox for Java, para accesar la base de datos.

50

4.5.3.2. SIN CÓDIGO JAVA EN EL SERVIDOR.

En esta alternativa, existe código tanto en el cliente como el servidor, pero a diferencia del caso anterior, el código en el servidor no está escrito en Java sino en otros lenguajes.

El código en el cliente, que se escribe completamente en Java, se encarga de invocar a programas en el AS/400. Los programas se pueden invocar de dos formas: por medio del JDBC (llamando a un procedimiento almacenado), o por medio de una función del Toolbox llamada DPC (Distribuited Program Call). A continuación se explican estas opciones.

a) Llamar a un Procedimiento Almacenado

Un procedimiento almacenado es un programa que reside y corre en el servidor y que se invoca por medio de la sentencia SOL CALL, usando el JDBC, desde la aplicación Java. Esto significa que el programa es realmente llamado por medio de la base de datos [11].

Los procedimientos almacenados se usan básicamente por las siguientes razones:

• Proporcionan un medio para incrementar significativamente el rendimiento de la aplicación. En lugar de que el código cliente genere varias sentencias de SQL, se llama a un programa en el servidor para que realice las operaciones de entrada/salida con la base de datos.

• Es un método estándar en SQL para llamar programas existentes en el servidor

Para codificar los procedimientos se puede usar un lenguaje nativo de AS/400, o bien el lenguaje estándar SPL (SQL Procedure Language). No es posible usar Java para crear un procedimiento almacenado, esto se debe que el código Java no se convierte en un objeto de tipo PGM en el AS/400 sino que se guarda como de tipo .class.

Antes de llamar al programa con JDBC, el programa debe registrarse en el catálogo de SQL dentro de 082/400. Esto se efectua por medio de la sentencia CREATE PROCEDURE.

b) Llamar a un programa por medio de Distribuited Program Call.

La función DPC es parte de las clases proporcionadas en el paquete AS/400 ToolBox, y se puede utilizar para llamar a un programa del AS/400 desde una aplicación en Java.

51

A diferencia de un procedimiento almacenado, el programa no tiene que estar registrado en los catálogos de 082/400. Sin embargo, la ventaja de usar procedimientos almacenados es que la aplicación usa un método estándar de llamar un programa en el servidor. La función DPC trae como resultado que la aplicación sea menos portable, pero existe con el fin de facilitar la conversión de aplicaciones existentes hacia el ambiente Java.

4.5.4. ALTERNATIVA 4: DATOS REMOTOS.

En este caso toda la lógica de la aplicación y la presentación residen en el cliente. El AS/400 juega el papel de un servidor de base de datos.

La aplicación Java en el cliente puede usar JD8C para accesar los datos en la base de datos. Las peticiones de los datos se realizan por medio del envío de sentencias SQL hacia las funciones del D8MS. La sentencia es ejecutada y el resultado se envía al programa cliente en forma de un Conjunto Resultado de SQL. El JD8C maneja todas las conversiones de datos.

Otra alternativa para accesar los datos desde la aplicación cliente es usar las función Record Level Access DOM, que está incluida en el paquete AS/400 Toolbox for Java. Esta función sólo es válida para accesar datos almacenados en el AS/400, su característica es que se asemeja a los mecanismos de lectura y escritura de datos usados por el desarrollador tradicional en AS/400 en lenguajes como Cobol o RPG.

Una tercera opción para accesar los datos es usar el puente JD8C-OD8C. Esta opción, aunque está disponible para el AS/400, no se recomienda debido a que el rendimiento se ve afectado al usar más capas de software. La herramienta existe para poder usar un Driver de OD8C para una base de datos que aún no soporta el JD8C.

De estas alternativas de acceso a los datos, el JD8C ofrece la ventaja de ser un estándar de industria y es fácil de manejar. Al ser un estándar de industria, cualquier desarrollador de aplicaciones Java puede usar el AS/400 como un servidor sin tener que conocer los aspectos específicos de este equipo. El JD8C es más fácil de utilizar que otras funciones en el Tool8ox de AS/400 debido a que el driver JD8C se encarga de las conversiones de datos. Los tipos de datos de 082/400 son correlacionados automáticamente a los tipos de datos en Java.

52

4.5.4.1. RECOMENDACIONES DE RENDIMIENTO.

El JDBC permite que las sentencias de SQL sean enviadas al AS/400 para su ejecución. Si una sentencia de SQL se ejecuta varias veces, se debe usar la función de preparación para ejecutar la sentencia. De esta forma la sentencia se compila, por lo que la subsecuente ejecución será más rápida.

Existen diversas propiedades que pueden ser especificadas en el JDBC. Algunas propiedades pueden afectar significativamente el rendimiento de la aplicación cliente/servidor con JDBC. Las propiedades controlan el bloqueaje de registros, espacio para memoria intermedia, soporte dinámico de sentencias SQL, entre otras.

4.5.5. ALTERNATIVA 5: DATOS DISTRIBUIDOS.

Este enfoque es parecido a la alternativa anterior (Datos remotos). La diferencia es que ahora parte de los datos están en el servidor, y el resto en el cliente. La ventaja de distribuir los datos es el de minimizar el flujo de datos. Este enfoque también permite tener localmente datos gráficos u de otro tipo.

El código Java en el cliente se encarga de accesar la base de datos local por medio de JDBC . Los datos remotos son accesados también por JDBC, pero existen también la alternativa de usar la función Record Level Access DDM.

53

CAPÍTULO 5. EL ESTÁNDAR ODBC

5.1. ANTECEDENTES DEL ODBC.

Ante la diversidad de manejadores de base de datos (DBMS) que existen actualmente en el mercado, los desarrolladores de aplicaciones tienen que conocer los diferentes tipos de acceso para cada base de datos.

Cada DBMS tiene mecanismos particulares de acceso a sus datos, por lo que las aplicaciones resultantes están de alguna manera enlazadas a una base de datos específica.

Si un desarrollador requiere crear una aplicación que accese al mismo tiempo información de diferentes DBMS, tiene que escribir código diferente que cumpla con los requerimientos específicos de cada base de datos. Por ejemplo, para obtener los datos del AS/400 se pueden crear rutinas que usen las funciones de Colas de Datos, pero esas rutinas no serán útiles para accesar a Oracle.

Ante la demanda de aplicaciones portables y fáciles de crear, los desarrolladores de aplicaciones han proclamado la existencia de una interfaz común de acceso a datos [9]. Con esta necesidad que cubrir, Microsoft desarrolló la arquitectura ODBC (Open Data Base Connectivity).

Por medio de ODBC una aplicación no tiene que considerar las características propias de una base de datos. De esta forma, ODBC es un estándar que define una serie de funciones para que una aplicación pueda accesar a cualquier DBMS.

ODBC se basa en el lenguaje SOL para la definición y acceso a los datos. El SOL ha sido ampliamente adoptado por varios proveedores de base de datos.

La mayoría de los DBMS actuales soportan el ODBC, tales como SOL Server, Oracle, 082/400, Sybase, lnformix, entre otros.

Algunos lenguajes y aplicaciones que soportan ODBC son: Visual Basic, PowerBuilder, FoxPro, SOL Windows, Access, C++, Delphi, Lotus Notes, etc.

Si todos los accesos a los datos se codifican siguiendo las especificaciones de ODBC, se obtiene una aplicación que puede accesar cualquier base de datos. El requisito es que la base de datos soporte el estándar ODBC [6].

54

5.2. COMPONENTES DE ODBC

El estándar ODBC describe un grupo de más de 60 funciones -APls- que un programa puede invocar para accesar datos almacenados en una base de datos relacional. El propósito principal de las funciones de ODBC es enviar comandos de SQL y luego obtener los resultados.

Para cada función existe una descripción de los parámetros requeridos y los valores posibles de retorno [6], esta descripción se encuentra en la publicación "Microsoft ODBC 2.0 Reference and SDK Guide", ISBN 1-55615-658-8.

Cada función de ODBC se implementa por medio de una API. En términos de programación, una API es una rutina externa que un programa puede invocar.

En la figura 5.1. se muestran los componentes de la arquitectura de ODBC

Figura 5.1. Componentes de ODBC

.Aplicación I

Fuente de D D D D..- APls de ODBC

Datos ----. j Driver Manager I kchivo o oecn .DLL kchivoODBC .INI ~----,-t---~

~--º_ri_ve_r~d_e _o_o_s c_~I ~~;;i oec .DLL (de Oient A:cess/400)

5.2.1.DRIVER MANAGER.

Cada una de las rutinas o APls de ODBC es código ejecutable que se encuentra en el archivo ODBC32.DLL (ó en ODBC.DLL para Windows de 16 bits) . Este archivo es proporcionado como parte del sistema operativo Windows. Cuando el programa usa alguna de las APls de ODBC, realmente está llamando a una función contenida en el archivo ODBC32.DLL. Este archivo es conocido como ODBC Driver Manager.

55

5.2.2. DRIVER DE ODBC

Debido a que cada base de datos tiene sus propias características, el Driver Manager no está diseñado para comunicarse directamente con cualquier DBMS, por lo que debe existir otro componente cuya tarea sea convertir todas las peticiones hechas por el programa en peticiones que la base de datos pueda entender. Este otro componente se conoce como Driver de ODBC. Generalmente el proveedor de la base de datos es el responsable de proporcionar este componente.

En el caso del AS/400, el producto Client Access/400 proporciona el Driver de ODBC por medio del archivo cwbodbc.dll.

Otros proveedores ofrecen Drivers de ODBC para trabajar con 082/400. Dentro de estos proveedores están Attachmate, HIT, ShowCase y WallData.

La tarea del Driver proporcionado por el proveedor es traducir una llamada de OD8C en una función propia de la base de datos. El Driver también debe manejar las respuestas de la base de datos y entregarlas en un formato estándar 008C a la aplicación. Si la base de datos regresa un error, el Driver es responsable de traducirlo en un código de retorno estándar.

El estándar de ODBC no especifica cómo el driver del proveedor de la DBMS debe realizar la operación de acceso a la base de datos, ya que esto depende de las características propietarias. Cada driver puede usar un enfoque distinto, por ejemplo, el driver puede ser diseñado para trabajar con APls propietarias del sistema remoto, como APls de APPC para el caso del AS/400. El diseño es transparente para la aplicación y para el Driver Manager.

En el AS/400, el 082/400 soporta de manera nativas las llamadas de ODBC. La interfaz de 082/400 para el soporte de 008C se basa en CU (Call Level Interface). La ventaja de soportar de forma nativa a 008C es que se obtiene mayor rendimiento. Las bases de datos que no soportan de manera nativa a OD8C tienen que hacer conversiones adicionales.

Debido a que el estándar 008C implementa una arquitectura de capas, es decir, separa a la aplicación cliente de la base de datos en el servidor, es posible reemplazar la base de datos por otra sin tener que modificar la aplicación. Basta con instalar el driver adecuado para la nueva base de datos, sin necesidad de alterar el código fuente de la aplicación.

56

5.2.3. FUENTE DE DATOS

Al arrancar una aplicación, el Driver Manager es el responsable de buscar y cargar en memoria el Driver de ODBC correspondiente a la base de datos remota. A continuación se describe el mecanismo usado para la carga del driver de ODBC.

El Driver Manager determina qué driver de ODBC se usará por medio de un componente adicional llamado Fuente de Datos.

La Fuente de Datos se crea una sola vez antes de usar la aplicación. En la Fuente de Datos se ecuentra nombre y el directorio donde se encuentra el driver de ODBC proporcionado por el proveedor para accesar la base de datos remota.

Una aplicación puede trabajar con varias base de datos, por lo que debe crearse una Fuente de Datos para cada una.

Las fuentes de Datos quedan almacenadas en un archivo llamado ODBC.INI. En la figura 5.2. se muestra de manera simplificada el contenido de este archivo:

Figura 5.2. Archivo ODBC.INI

[ODBC 32 bit Data Sources] ServidorNT=SQL Server (32 bi1) ServidorAS!400=Client Access ODBC Driver (32-bii) (32 bii)

f Servidor N1] Driver32=C:\WJNDOWS\SYS1EM\sqlsrv32.dll

/ServidorASl40CJ Driver3 2 =C: \Program Files \JBM\Client Access \Shared\cwbodbc. dll

En la figura anterior, se puede ver que existen dos Fuentes de Datos: ServidorNT y ServidorAS/400.

El nombre de la Fuente de Datos a usar se especifica en el programa al momento del arranque. De esta forma el Driver Manager buscará en el archivo ODBC.INI el nombre del Driver ODBC a usar. En el ejemplo, el driver de ODBC correspondiente a la fuente de datos "ServidorAS/400" es cwbodbc.dll.

Para configurar las Fuentes de Datos, no es necesario editar directamente el archivo ODBC.INI. Existe una función llamada Administrador de ODBC proporcionada por los

57

sistemas operativos de Windows ( 16 bits o 32 bits) para trajar con las Fuentes de Datos.

5.3. VERSIONES DE ODBC

El estándar ODBC cambia de acuerdo a las mejoras que se añadan y a la aparición de nuevos sistemas operativos.

La versión 1 fué la primera publicación de la especificación de ODBC de Microsoft . La versión 2 incluyó significativas mejoras al ODBC con la inclusión de nuevos APls y el reemplazo de otros. La versión 2.5 está orientada a sistemas operativos de 32 bits. La versión 3 incluye especificaciones que se adhieren a los lineamentos de OSF (Open Software Foundation).

5.4. NIVELES DE CONFORMANCIA.

Como se ha descrito, la arquitectura de ODBC está basada en un diseño de capas. La primera capa es la aplicación que invoca las funciones de ODBC. La segunda capa es el Driver Manager que intercepta las peticiones en formato estándar y las envía a la siguiente capa: el driver específico de la base de datos remota.

Los proveedores que desarrollan los Drivers de ODBC son los responsables de asegurarse que la interacción con el Driver Manager sea adeacuada. El Driver de ODBC debe entender las solicitudes del Driver Manager y debe regresar información estándar para que el Driver Manager le entienda. Idealmente, todos los drivers de ODBC deberían cubrir al 100% esta interfaz. Sin embargo, el grado de soporte a los estándares del Driver Manager puede variar dependiendo del proveedor.

Existen diversos factores [9] que influyen en la calidad del Driver de ODBC, como son: costos, tiempo de producción, rapidez de acceso y nivel de apego al estándar.

Debido a esta variación, se ha diseñado una escala para clasificar a los Drivers de ODBC en base a su nivel de apego o "conformancia" al estándar. La clasificación se ha dividido en dos areas: el grado de soporte a las funciones APls y el grado de soporte a la gramática SQL. El proveedor respectivo debe especificar las características de su Driver de ODBC.

58

5.4.1. CONFORMANCIA DE APls.

Existen cerca de 60 APls definidas por ODBC. El número y tipo de APIS que soporte un determinado Driver de ODBC, determina su clasificación. Existen tres clases: Nivel O ("Core"), Nivel 1 y Nivel 2.

A continuación se muestran, como ejemplo, sólo algunas funciones soportadas en cada nivel.

Nivel O Conectarse a una Fuente de Datos Preparar y Ejecutar sentencias SQL Leer los datos resultante de una sentencia SQL

Nivel 1 Todas las funciones de Nivel O Recuperar información de columnas

Nivel 2 Todas las funciones de Nivel 2 Obtener una lista de las fuentes de Datos disponibles Trabajar con arreglos que contienen parámetros y resultados

5.4.2. CONFORMANCIA DE SQL.

La conformancia de SQL está determinada por el número y tipos sentencias SQL soportadas, ya sean sentencias de definición de datos DDL (Data Definition Language) o de manipulación de datos DML (Data Manipulation Language).

Existen tres niveles: base ó "core", mínimo y extendido. Algunos ejemplos de las sentencias soportadas en cada nivel son:

En el nivel base se soportan las sentencias CREATE, DROP, SELECT, INSERT y UPDATE.

En el nivel mínimo se soportan adicionalmente las sentencias: CREATE INDEX y AL TER TABLE.

En el nivel extendido se soportan adicionalmente los tipos de datos BIT, BINARY y TIMESTAMP, así como manipulación de cadenas de caracteres y uso de funciones matemáticas.

59

5.5. PROCESO DEL USO DE APls.

El ODBC se implementa por medio de llamadas a las APls desde la aplicación. Aunque existen más de 60 APls, generalmente se utilizan alrededor de 20 en aplicaciones comunes.

A continuación se describe brevemente la forma de usar las APls básicas de ODBC, sin entrar a detalles de programación.

Cuando un programa usa una API de ODBC, se está llamando a una rutina (función) de ODBC que está contenida en el archivo ODBC32.DLL, conocido como Driver Manager.

Figura 5.3. Procesamiento de las funciones de ODBC

Aplicación Inicialización

API API API

Ejecución

D Driver Manager

t Driver de ODBC

082/400

Como se puede ver en la figura anterior, por medio de las APls la aplicación se comunica directamente con el Driver Manager.

A su vez, el Driver Manager pasa los requerimientos al Driver de ODBC ( archivo proporcionado generalmente por el proveedor de la base de datos).

60

Esta arquitectura asegura que las funciones de ODBC son llamadas desde cualquier aplicación de la misma forma, sin importar si la conexión es hacia un AS/400 u otro equipo con diferente DBMS.

Esta arquitectura por capas también permite que varios Drivers de ODBC puedan estar activos al mismo tiempo.

El proceso de uso de APls se divide básicamente en tres etapas [8]:

a) Inicialización de ODBC. b) Ejecución de sentencias SQL. e) Terminación del ODBC.

5.5.1. PROCESO DE INICIALIZACIÓN.

El proceso de inicialización de ODBC se divide en las siguientes tareas principales.

5.5.1.1 ARRANQUE DEL AMBIENTE ODBC

El primer paso de toda aplicación ODBC consiste en arrancar la interfaz ODBC. Esto se realiza por medio de la función SQLAllocEnv.

Con esta función se indica que una aplicación usará ODBC. Este paso se conoce como arranque del ambiente ODBC para la aplicación. En otras palabras, se indica que existirá un enlace entre el programa y el Driver Manager.

5.5.1.2. IDENTIFICACIÓN DE LA CONEXIÓN.

Un programa puede conectarse con distintas bases de datos al mismo tiempo, lo cual significa que se usarán varios Drivers de ODBC. (El término "conexión al Driver de ODBC" tiene el mismo significado que "conexión a la base de datos"). Por medio de la función SQLLAl/ocConnect, se lleva el control de la conexión con un determinado Driver de ODBC.

5.5.1.3. IDENTIFICACIÓN DE SENTENCIA SQL.

El siguiente paso en el proceso de las APls de ODBC es definir un identificador de cada sentencia SQL que se usará en el programa. Esta variable es conocida como identificador de sentencia SQL ó simplemente como handler de sentencia. Para definir un identificador de sentencia SQL, se usa la función SQLAllocStmt. Cuando se llama a la función SQLAllocStmt, el Driver Manager asigna recursos para cada sentencia SQL.

61

5.5.2. EJECUCIÓN DE LA SENTENCIA SQL

Después de haber realizado el proceso de inicialización de ODBC, la aplicación ya está lista para ejecutar sentencias SQL.

La ejecución de una sentencia SQL se puede realizar de dos formas:

a) Ejecución directa b) Ejecución de sentencias preparadas.

La diferencia básica entre estas formas es el rendimiento.

Para ejecutar de manera directa una sentencia SQL, se debe usar la función SQLExecDírect.

5. 5.3. TERMINACIÓN DEL PROCESO.

Una vez que la aplicación cliente ha terminado sus operaciones de base datos con el sistema servidor, es necesario ejecutar los pasos de cierre de ODBC. Con estos pasos se liberan los recursos asignados para las variables "handler" de ODBC y se terminan las conexiones que se arrancaron.

Después del cierre de ODBC, la aplicación puede terminar, o bien, continuar con otros procesos dependiendo de la lógica de la aplicación, ó incluso arrancar otra vez el ambiente de ODBC.

Es necesario realizar los pasos de cierre de ODBC, ya que de esta manera existe la seguridad de que existan recursos disponibles si es que se arranca otra aplicación ODBC. Por otra parte, con el proceso de cierre se avisa al servidor que también libere los recursos utilizados en la conexión.

5.6. RECOMENDACIONES DE RENDIMIENTO EN ODBC

5.6.1. USO DIRECTO DE LAS APls.

En determinados lenguajes existen ciertas herramientas que simplifican la codificación de ODBC. Con estas herramientas no es necesario codificar directamente las llamadas a las APls de ODBC. Por ejemplo, en Visual Basic existe el Data Control. Durante la ejecución, este tipo de herramientas invocan finalmente las APls para la comunicación con el Driver de ODBC, sin embargo, al usar más capas de software, el rendimiento se ve afectado. En general, estas utilerías se recomiendan para el acceso a datos que residen en la misma computadora o para aplicaciones con pocos accesos remotos.

62

El uso de las APls de ODBC requiere de mayor programación que las otras alternativas. Aunque el propósito fundamental de ODBC es ejecutar sentencias SQL, existen tareas previas que la aplicación debe realizar. Dentro de estas tareas se encuentran la declaración de las APls. Otras tareas típicas son la inicialización del ambiente ODBC, el manejo de errores y la desconexión. Además, las APls deben ejecutarse en una secuencia específica.

Sin embargo, las ventajas de usar las APls directamente son el incremento sustancial en el rendimiento de la aplicación y la flexibilidad, lo cual permite crear aplicaciones robustas y de misión crítica.

5.6.2. USO DE SQL DINÁMICO.

En general, cada vez que una sentencia de SQL se ejecuta desde la aplicación cliente, la sentencia es "compilada" en el servidor (AS/400). En este proceso el DBMS crea temporalmente una definición de acceso a los datos.

La definición creada se conoce como Plan de Acceso. El Plan de Acceso permite que en la ejecución de la sentencia SOL el sistema utilice los índices y algoritmos adecuados para maximizar el proceso de los datos [11].

Si una sentencia será utilizada varias veces, no es eficiente que en el sistema servidor se cree el plan de acceso en cada ejecución. Para evitar esto, la sentencia de SQL debe ser "preparada".

El proceso de preparación de una sentencia SQL consiste en crear de forma permanente el Plan de Acceso. El Plan de Acceso queda almacenado en el AS/400 en un objeto de tipo paquete (*SQLPKG). Este proceso se conoce como SQL Dinámico Extendido. Un sistema servidor sin esta facilidad, es como un sistema que almacena programas solo en formato fuente y luego los compila cada vez que un usuario los ejecuta.

La función de ODBC para preparar una sentencia es SQLPrepare. Para una sentencia preparada se usa SQLExecute.

Al momento de llamar a la función SQLPrepare, la información del Plan de Acceso para la sentencia SQL se almacena en el paquete SQL. Por omisión, el nombre del paquete es determinado en base a las carecterísticas de la Fuente de Datos. Pueden existir varios paquetes en el sistema, por omisión se almacenan en la biblioteca QGPL.

Con el comando PRTSQLINF del AS/400 es posible visualizar el contenido de un paquete en el AS/400.

63

En estapas de desarrollo y prueba de una aplicación ODBC, el paquete de SQL en el AS/400 puede dañarse debido a los cambios frecuentes de las sentencias SQL. En esta situación, la aplicación recibe el mensaje de error "Soporte deshabilitado para el SQL Dinámico Extendido". Para resolver este problema, basta con borrar el paquete en el AS/400. Al correr nuevamente la aplicación de ODBC, el sistema volverá a crear el paquete.

La mayoría de las aplicaciones se benefician del soporte de paquetes de SQL. Sin embargo, es necesario considerar una ligera afectación al rendimiento la primera vez que se ejecuta la aplicación, esto se debe a que la creación de los paquetes lleva recursos del servidor

La decisión entre usar o no el soporte de paquetes está en el diseñador de la aplicación ODBC. Si la sentencia de SQL se ejecuta solamente una vez en el programa, se recomienda ejecutar la sentencia SQL de manera directa.

Por el contrario, si la sentencia de SQL se ejecuta varias veces en un programa, como ocurre en la mayoría de las aplicaciones cliente/servidor, se recomienda la preparación de las sentencias.

5.6.3. USO DE PROCEDIMIENTOS ALMACENADOS.

El término "procedimiento almacenado" se utiliza en la literatura de base de datos para referirse a un programa que corre en el servidor y que se invoca desde la aplicación cliente por medio de SQL.

Los procedimientos almacenados, al correr en el servidor, proporcionan la ventaja de utilizar las técnicas más eficientes del servidor para accesar los datos. Debido a esto se utilizan para mejorar el rendimiento de las aplicaciones cliente/servidor.

Si sólo se usaran APls de ODBC sin Procedimientos Almacenados, toda la lógica de la aplicación queda del lado de la PC, el AS/400 se convierte en un servidor de base de datos. En este caso, la aplicación resulta más portable hacia otro tipo de DBMS, ya que no existe código en el servidor (procedimientos almacenados) que deba trasladarse hacia otra plataforna.

Con el uso de procedimientos almacenados, el diseñador de la aplicación tiene la alternativa de trasladar una parte, o inclusive toda la lógica, hacia el AS/400. En el lado de la PC quedaría la interfaz del usuario.

Si no existe mucha experiencia en desarrollo de aplicaciones con Visual Basic u otro lenguaje en Windows, el uso de procedimientos almacenados proporciona una ventaja adicional al rendimiento: simplifica la codificación en lado de la PC. Esto se debe a que, como se ha mencionado, toda o cierta parte de la lógica de la aplicación y de control del acceso a los datos se codifican en el lado del AS/400. Del lado de la PC

64

sólo se codifica la interfaz del usuario. En este ambiente, es posible cambiar el comportamiento de la aplicación sin necesidad de modificar sustancialmente el código en la PC.

5.7. ESTRATEGIAS DE DISEÑO CON ODBC.

Existen diversas opciones para diseñar aplicaciones cliente/servidor en AS/400 usando ODBC. Las consideraciones ha tomar en cuenta para escribir una aplicación con ODBC en AS/400 son:

• El lenguaje a usar en el cliente: el código en el cliente puede desarrollarse con cualquier lenguaje de programación en Windows que soporte las llamadas a funciones externas (archivos DLL). Algunos de los lenguajes más conocidos son Visual Basic, Visual C++ y PowerBuilder.

• El servidor: En esta parte se consolidan las funciones de base de datos, seguridad de acceso a los datos, comunicaciones con otros servidores y las fuciones de respaldo y recuperación. Opcionalmente puede desarrollarse código que es invocado desde el código como llamadas a procedimientos almacenados.

• Acceso a la base de datos. ya sea desde el código cliente o desde el código servidor. Con ODBC, tanto el cliente como el servidor pueden accesar los datos del servidor.

• Comunicación entre el código cliente con aplicaciones existentes en el AS/400: Esta comunicación se puede dar por medio de las llamadas a Procedimientos Almacenados.

Para describir con más detalle estas consideraciones, a continuación se muestran los modelos típicos en que una aplicación ODBC puede desarrollarse en AS/400.

65

5.7.1. MODELOS CLIENTE/SERVIDOR CON ODBC.

Los diferentes escenarios para escribir aplicaciones ODBC en AS/400 (8) se pueden ver en la figura 5.4.

Figura 5.4. Modelos cliente/servidor soportados con ODBC

Datos Datos

Lógica roe. Almacenados

Lógica

Presentación

Lógica Distribuida

SERVIDOR

Red

CLIENTE

Lógica

Presentación

Datos Remotos

5. 7 .1.1. Alternativa 1: Lógica Distribuida.

Datos

Datos

Lógica

Presentación

Datos Distribuidos

En esta alternativa existe código tanto en el cliente como el servidor. La aplicación cliente utiliza la sentencia CALL de SQL para invocar a los programas del servidor (procedimientos almacenados).

Este escenario resulta ideal en los siguientes casos:

a) Existe poca experiencia en lenguajes de ambiente Windows. La aplicación cliente consiste básicamente en manejar la interfaz del usuario y en enviar ó recibir los datos

66

con el servidor. La lógica principal de la aplicación se codifica en el servidor por medio de los lenguajes conocidos al desarrollador tradicional en el AS/400.

b) Se requiere mejorar el rendimiento de la aplicación. Al tener código en el servidor, el flujo de datos con el cliente disminuye. Por otro lado, los programas en el servidor pueden utilizar herramientas nativas para el acceso a los datos y a otros recursos, lo cual maximiza el rendimiento.

La desventaja de esta alternativa es que la aplicación pierde portabilidad, excepto si los procedimientos almacenados se codifican con SQL estándar.

5. 7 .1.2. Alternativa 2: Datos remotos.

En este escenario, tanto la lógica completa de la aplicación y la presentación residen en el cliente. El AS/400 juega el papel de un servidor de base de datos.

La ventaja de este enfoque es que no es necesario escribir código en el servidor. Este resulta idóneo para las áreas de sistemas que cuentan con más experiencia en desarrollo de aplicaciones bajo Windows que en AS/400.

El código en el cliente se desarrolla con algún lenguaje visual y el manejo de los tipos de datos es realizado por medio del Driver de ODBC.

Esta alternativa proporciona la mayor portabilidad ya que si desea direccionar la aplicación hacia otra base de datos, sólo es necesario cambiar el Driver de ODBC en el cliente.

5.7.1.3. Alternativa 3. Datos Distribuidos.

Este enfoque es parecido a la Alternativa 2 (Datos remotos). La diferencia es que ahora parte de los datos están en el servidor, y el resto en el cliente. Generalmente se utiliza esta alternativa para minimizar el tráfico de datos en la red, por lo que los datos más usados se copian en tablas locales. La consideración adicional es que la aplicación debe tener mecanismos adicionales para el control adecuado de la redundancia de información.

Otro uso de los datos distribuidos ocurre cuando la aplicación maneja datos gráficos, como uso de dibujos de las partes de un inventario, o bien, fotografías de los empleados en una aplicación de recursos humanos. En estos casos resulta más conveniente tener estos elementos en el sistema cliente.

67

CAPÍTULO 6: PROTOCOLOS A NIVEL DE TRANSPORTE.

6.1. APLICACIONES CLIENTE/SERVIDOR CON APPC.

El protocolo de comunicaciones APPC (Advanced Program-to-Program Communications) juega un papel único como alternativa de comunicación entre programas remotos. Las características de seguridad, recuperación de errores, sincronización y velocidad, hacen del APPC el protocolo indicado para desarrollar aplicaciones cliente/servidor robustas y de misión crítica [8].

La implementación del APPC se encuentra en una gran variedad de software. Algunas empresas que desarrollan software usando APPC son: Amdhal, Apple Computer lnc, AT&T, Hewlett-Packard, IBM, Microsoft, NCR, Novell, Oracle, Sun Microsystems, Texas lnstruments, Unisys, etc.

El APPC es el término descriptivo dado al protocolo de comunicaciones LU 6.2. Este protocolo permite que dos programas entren en un sincronismo para el intercambio de datos, de ahí el término "comunicación programa a programa". El flujo de datos se codifica sin que el programador tenga que conocer los detalles de la recuperación de datos ó de las retransmisiones, de ahí el término "Avanzada". El protocolo APPC implementado en el sistema operativo ó en el software de comunicaciones proporcionado por el proveedor, se encarga de estos aspectos transparentes para el programador.

6.1.1. TERMINOLOGÍA USADA EN APPC

El LU 6.2. ( ó APPC) se desarrolló como una evolución a otros protocolos de comunicaciones dentro de la arquitectura SNA (System Network Architecture ).

La arquitectura SNA es un conjunto de reglas que permiten las telecomunicaciones en una red de computadoras. Como referencia, se pueden mencionar otras arquitecturas de comunicaciones como son: OSI (Open System lnterconnect) y TCP/IP (Transmission Control Protocol / Internet Protocol).

El SNA define cómo se comunican las computadoras dentro de una red. Dentro de la arquitectura SNA, hay muchos "lenguajes" o protocolos por medio de los cuales las computadoras se pueden comunicar entre sí. Algunos lenguajes son más usados que otros, mientras que otros han dejando de usarse y han aparecido nuevos para cubrir las nuevas necesidades de comunicaciones.

68

Para entender su funcionamiento y lograr posicionar al APPC como alternativa de desarrollo de aplicaciones cliente/servidor, a continuación se estudian los términos más importantes usados en este protocolo [3].

6.1.1.1. UNIDAD LÓGICA

Una LU (Logical Unit) es el término usado en SNA para representar el software que controla el intercambio de datos entre programas remotos. Este control se lleva a cabo siguiendo un conjunto de reglas predefinidas conocidas como el protocolo de la LU. Por ejemplo, una LU conocida de SNA es la LU 2, por lo que el protocolo usado en esta LU se conoce como protocolo LU2.

El protocolo LU2 fué desarrollado originalmente para la comunicación entre Mainframes y terminales. Este protocolo es ideal para las funciones de dispositivos periféricos, sin inteligencia, conectados a una computadora central. Sin embargo, no contiene todas las funciones requeridas para comunicar dos sistemas inteligentes, tal como se requiere en las aplicaciones cliente/servidor. Debido a que el mainframe se encarga del control de las comunicaciones con la terminal, el protocolo LU 2 se conoce como "Orientado al Host".

Otra LU similar es la LU7 que permite el flujo de datos entre el AS/400 y las terminales conectadas por enlace twinaxial, esta LU también se conoce como "5250 Display Data Stream". De igual forma, el control del flujo de datos con las impresoras del AS/400 se lleva a cabo por medio de la LU 4 ó "5250 Printer Data Stream".

Un tipo de LU más sofisticada y reciente es la LU 6.2, que proporciona la capacidad de comunicación "igual a igual" entre dos computadoras. Usando LU 6.2. no hay dependencia de que una máquina controle el enlace de comunicaciones, cualquier computadora puede inciar ó terminar la comunicación. Frecuentemente, la LU 6.2 se conoce como el soporte "LU independiente", ó el término más familiar APPC.

Para comprender mejor la evolución de los protocolos SNA, basta con comparar la funcionalidad entre la LU 7 con la LU6.2. Una PC conectada al AS/400 por medio de un emulador 5250 (LU 7) sólo nos servirá como terminal. En cambio, si en la PC se instala un software de comunicaciones que use el APPC , tendremos la posibilidad de contar con varias funciones: uso del AS/400 como servidor de archivos, como servidor de base de datos, emulación de terminal y de impresora, etc.

Los primeros emuladores de terminal o de impresora bajo el sistema operativo DOS, usaron la LU7 y LU4 para conectarse a los sistemas S/36 y S/38. Actualmente, para conectarse al sistema AS/400, se usa ampliamente la LU 6.2. por las ventajas ya mencionadas.

69

6.1.1.2. PROGRAMAS DE TRANSACCIÓN.

Las funciones que podemos obtener por medio del APPC, se logran mediante el sincronismo entre un par de programas: un programa cliente residente en la computadora personal y otro programa servidor ejecutándose del lado del AS/400. Cada uno de estos programas recibe el nombre de Programa de Transacción ó simplemente TP por sus iniciales en idioma inglés. En la figura 6.1 . se muestra el concepto de los programas TPs:

Figura 6.1 . Programas TP

Programa TP Cliente

1 11 Funciones APPC

Ruteador (LU 6.2)

Programa TP Servidor

Funciones ! ! j APPC

APPC en Servidor

Un TP es el programa que usa los servicios del protocolo LU para comunicarse. Por ejemplo, si se realiza una transferencia de un archivo de base de datos del AS/400, los datos del nombre del archivo, tipo de secuencia, selección de renglones, etc., se especifican dentro del programa TP cliente. Este programa invoca los servicios del programa TP servidor, el cual envia los datos.

Hay dos tipos de TPs:

a) Programas de Servicio, los cuales son proporcionados por el proveedor del software de comunicaciones, como por ejemplo, las funciones de Transferencia de Archivos, la función DOM (Distribuited Data Management), SNADS (SNA Distribution Services) y otras que vienen con el OS/400. Generalmente estos programas están codificados en lenguaje C.

b) Programas de Aplicación, que son los programas que se pueden codificar para cubrir los requerimientos específicos de los usuarios finales. Como ejemplo, se pueden mencionar aplicaciones comerciales como la versión cliente/servidor de BPCS,

70

MAPICS, JO EDWARDS. O bien, aplicaciones creadas dentro del área de sistemas de una empresa.

Los programas servidores se escriben generalmente en lenguaje COBOL, RPG ó C. Los programas cliente se escriben el lenguajes como Visual Basic, FoxPro, C++, y otros.

Para que cada TP logre establecer la comunicación con su contraparte, sus requerimientos de comunicaciones deben direccionarse hacia un puerto común: el ruteador. El ruteador es un programa que implementa el soporte APPC en la computadora personal. La reglas del intercambio de información entre el TP y el ruteador deben apegarse al protocolo LU 6.2.

De la misma manera, en el AS/400, cada TP direcciona sus paquetes de información a un dispositivo de tipo APPC. El soporte APPC en el AS/400 viene incluido en el microcódigo del sistema operativo. En cambio, el soporte APPC no forma parte de los sistemas operativos DOS ó Windows, por lo que es necesario instalar un software de comunicaciones como Client Access/400.

6.1.1.3. SESIONES Y CONVERSACIONES.

Así como cada TP mantiene una conversación con su correspondiente TP remoto. Cada LU mantiene un enlace con su contraparte. En términos de SNA, este enlace se llama una sesión.

La sesión controla el intercambio de datos entre las LU's, incluyendo el tamaño de los paquetes de información, la detección y recuperación de errores, el ruteo de los datos y el sincronismo.

Existe otro concepto que está relacionado con una sesión: la conversación. Una conversación es el término dado al enlace de datos entre un par de programas de transacción (TP). Sólo se puede tener una conversación por cada sesión.

Los TPs tienen el control de la sesión mientras exista una conversación entre ellos. Cuando la conversación termina, la misma sesión puede ser usada por otro par de TPs, de esta forma se hace más eficiente el uso de los recursos de la red al evitar la sobrecarga que se requeriría si una sesión se tuviera que crear para cada conversación entre programas TPs

La duración de una conversación está determinada por los mismos TPs, por ejemplo, si se trata de una transferencia de datos, quizá el programa TP servidor decide terminar

la conversación debido a que ya no hay mas registros que enviar.

El APPC permite establecer sesiones paralelas entre un par de LUs, de esta forma se pueden tener varias conversaciones al mismo tiempo: una puede ser utilizada por una

71

emulación de terminal, mientras otra serviría para usar la función de Servidor de Archivos.

6.1.1.4. FUNCIONES (APIS) DE APPC.

En párrafos anteriores, se ha mencionado que existe una comunicación entre los programas y la LU. Por ejemplo, si un programa TP cliente desea arrancar un programa TP servidor en el AS/400, esta petición debe ser solicitada al ruteador. En este caso, la petición debe ir acompañada por un parámetro principal: el nombre del programa servidor. A las peticiones se les conoce como verbos ó funciones de APPC.

Otras funciones típicas son: enviar datos al TP, recibir datos desde un TP y terminar la conversación. Cada una de estas funciones es ejecutada por del programa ruteador, por lo que el TP debe proporcionar los parámetros adecuados.

Del lado del AS/400, los programas TPs servidores utilizan las funciones de APPC por medio de archivos ICF (lntersystem Communication Facility) ó por medio de funciones CPI-C (Common Programming lnterface-Communications).

Una función de APPC puede interpretarse como la llamada a un procedimiento ó a un subprograma. Cuando el programa ejecuta la función de APPC, queda en espera de que la LU le regrese un código de retorno. De esta forma el programa puede saber si la fución APPC se ejecutó satisfactoriamente.

El sincronismo en el intercambio de datos entre un programa cliente y programa remoto se logra mediante el uso de la función APPC adecuada.

El APPC es un protocolo de tipo "half-duplex". Esto significa que, en un momento dado, solamente un lado de la conversación puede enviar datos, mientras la otra parte permanece en modo de recepción. Cuando un programa termina de enviar, puede ejecutar un verbo de APPC para informar al programa remoto que ahora él puede enviar datos.

6.1.1.5. FLUJO DE DATOS EN LAS CAPAS DE COMUNICACIONES

Como se mencionado, los datos que un TP cliente desea enviar a un TP servidor, deben ser direccionados hacia la LU por medio de un verbo de APPC. A su vez, la LU recibe el dato y lo envía a otras rutinas de comunicaciones. De esta manera, se forma un flujo de datos entre rutinas de diferentes niveles. La arquitectura SNA define una serie de capas para llevar la función de comunicaciones. Cada una de las capas ejecuta servicios a favor de la capa siguiente. El funcionamiento de la arquitectura por capas se puede comprender mejor si se usa la analogía del envío de un paquete entre dos personas de una misma empresa que están en diferentes ciudades. El flujo de datos se forma de la siguiente manera:

72

a) La persona "A" prepara la información que debe de enviarse a la persona "B" y la entrega a su secretaria indicando a quién va dirigida, si es urgente, etc.

b) La secretaria guarda la información en un sobre el cual es rotulado siguiendo ciertos convencionalismos para identificar la oficina origen, oficina destino y la urgencia.

c) La secretaria entrega el sobre al departamento de correspondencia de la oficina local. En este lugar, se le adhieren algunas etiquetas al sobre, esto es con el fin de contar con información de control que es útil para el departamento de correspondencia de la otra oficina. Por ejemplo, se decide si el sobre debe ser llevado a otra oficina intermedia, de donde se controlan la rutas para las oficinas de ciertas zonas.

d) El personal de una empresa de mensajería externa llega todas las tardes a recoger los envíos. Coloca el sobre en una bolsa que es rotulado con información nueva que sólo es útil y entendible a la empresa de mensajería, como puede ser: número de guía, peso, número de cliente, etc.

e) La empresa de mensajería se encarga de llevar el paquete al departamento de correspondencia de la oficina remota.

e) Al recibir el paquete, el departamento de correspondencia remoto deshecha la envoltura plástica, analiza y registra el contenido de las etiquetas del sobre. Luego se entrega el sobre a la secretaria del destinatario (persona "B").

f) A su vez, la secretaria analiza la información escrita por la otra secretaria, extrae y entrega los documentos a la persona "B".

Las observaciones del proceso son:

• Existe una comunicación "vertical" pre-establecida entre las diferentes capas del proceso.

• Cada fase realiza sus actividades en beneficio de la siguiente.

• Físicamente, el paquete de datos se mueve de forma vertical, sin embargo existe una comunicación horizontal entre las diversas capas: La persona "A" envía su información y "B" la recibe. La secreteria de "A" envía un sobre y la secretaria "B" recibe un sobre, etc.

• Para que exista la comunicación horizontal, debe establecerse un conjunto de convencionalismos ó "protocolos". La información extra que cada capa añade sólo es util para ese nivel.

• Las funciones de una capa son realizadas de forma desconocida para la otra. Sin embargo, una capa podría saltarse los servicios de otra, por ejemplo, la persona "A" podría llevar su sobre directamente a la empresa de mensajería, o incluso llevar

73

personalmente la información a la persona "B". El beneficio sería mayor rapidez, pero el costo está en que deben conocer y realizar los convencioanalimos de las otras capas. En términos de comunicaciones, esto equivale a codificar un programa que realice todas las funciones de enlace de datos, controlando el estado de cada bit de los paquetes de información y llegando incluso a intercambiar datos con los adaptadores de comunicaciones .

En la arquitectura SNA, el mensaje que un programa TP envía, debe pasar por 7 capas de comunicaciones:

1. Servicios de Transacción 2. Servicos de Presentación 3. Control de Flujo de Datos 4. Control de Transmisión 5. Controlde Ruta 6. Control de Enlace de Datos 7. Control Físico

El software de comunicaciones que implementa una LU (por ejemplo, el ruteador de Client Access/400) se encarga realizar las cuatro primeras capas de la arquitectura SNA.

6.1.1.6. IMPLEMENTACIÓN DEL APPC EN AS/400.

En el sistema AS/400 existen dos alternativas para escribir programas de APPC. Por medio de archivos ICF (lntersystem Comunications Function) y por medio de CPI-C (Common Programming lnterface-Comunications). La forma más común es por medio de archivos ICF.

Se ha descrito que un programa en la PC, por ejemplo en Visual Basic, accesa a las funciones de APPC por medio de las APls de APPC. En el AS/400, un programa ejecuta las funciones de APPC por medio de operaciones WRITE y READ hacia un archivo de tipo ICF.

Un archivo de ICF no contiene realmente datos, sino diversos formatos de registros -estructuras de datos- con los cuales se pueden enviar y recibir datos con un programa remoto. (Los datos son almacenados físicamente en un buffer de comunicaciones creado por las rutinas de APPC del sistema operativo).

En el AS/400, este tipo de archivos -sin datos- reciben el nombre de archivos de dispositivos. Un archivo de dispositivo contiene la descripción de cómo los datos son presentados hacia o desde el programa.

74

6.1.2. DISEÑO DE APLICACIONES CON APPC.

Como se puede ver en las secciones anteriores, el desarrollo de aplicaciones cliente/servidor con APPC requiere de más conocimientos de comunicaciones. Además de que un programas TP debe encargarse del sincronismo de la conversación con el programa TP remoto. Este tipo de actividades no se tienen que realizar en los programas cuando se usan las alternativas de ODBC o Java. Sin embargo, con el uso de APPC, se obtiene el mejor rendimiento.

En la siguiente sección se muestran, de manera general, los funciones (APls) principales que un programa puede llamar cuando se usa APPC. La intención no es llegar al detalle de la programación, sino más bien mostrar el tipo de actividades que una aplicación APPC debe realizar y contar con una base de comparación con las alternativas ya estudiadas de ODBC y Java.

6.1.2.1. ARRANQUE DE UNA CONVERSACIÓN EN APPC

Cuando un programa requiere iniciar una conversación con un programa remoto, debe usar la función Allocate. El programa que ejecuta el Allocate debe proporcionar cierta información. La infomación más importante es:

a) el nombre de la LU remota. Generalmente el nombre de la LU es igual al nombre sistema

b) el nombre del programa remoto. Este es el programa servidor a arrancarse en el sistema remoto.

c) Tipo de conversación: mapeada o básica

Cuando el Allocate es ejecutado, las rutinas de APPC dentro de la LU local, tratan de encontrar una sesión de comunicaciones para asignarla al programa. Si ya existe una sesión establecida y está libre, se asigna a la nueva conversación. De lo contrario, el APPC intentará arrancar una nueva. Algunas veces, debido al límite máximo establecido de sesiones, no es posible arrancar una nueva.

El programa que ejecuta el Allocate, automáticamente queda en modo de envío. Mientras tanto, el programa remoto que se arrancó, queda en modo de recepción.

6.1.2.2. ENVÍO DE DATOS

Para enviar un dato al programa remoto, se usa la función Send_Data. Se debe de indicar el dato y su longitud.

Cuando la LU local recibe los datos, se copian a un buffer interno. Aunque el programa local reciba un código de retorno de éxito, esto no significa que los datos hayan sido

75

enviados. Solamente significa que el APPC ya tiene los datos. Esto se hace para optimizar el rendimiento. En lugar de enviar pequeños bloques de datos, el APPC acumula datos hasta que el buffer se llena. Existen situaciones en las cuales el contendio buffer es enviado inmediatemente, sin importar si esta lleno o no, por ejemplo, cuando se usa una función de APPC que cambie de estado de envío a estado de recpción, o cuando se termina la conversación.

6.1.2.3. RECEPCIÓN DE DATOS.

Un programa puede recibir los datos por cualquiera de estas funciones: Receive And Wait ó Receive lnmediate.

- - -

La función Receive_And_Wait verifica si ha llegado un dato al buffer de la LU local. Si no hay datos, el programa queda suspendido hasta que llegue uno.

La función Receive_lnmediate también verifica si ha llegado un dato al buffer de la LU local, pero el control de ejecución se regresa inmediatamente al programa aunque no existan datos. El programa puede continuar con otras actividades. El programador debe diseñar un rutina cíclica para verificar frecuentemente la llegada de información

Para ejecutar la función Receive_lnmediate, el programa debe estar en modo de recepción. Sin embargo, la función Receive_And_Wait se puede ejecutar sin importar si el programa está en modo de envío o de recepción.

6.1.2.4. TERMINACIÓN DE UNA CONVERSACIÓN.

La conversación puede ser terminada por cualquiera de los programas, siempre y cuando se encuentre en modo de envío. Para finalizar una conversación se usa la función Deallocate.

Si hay datos en el buffer listos para ser enviados, el APPC los enviará junto con el indicador de terminación de la conversación. Por medio Receive And Wait ó - -Receive_lnmediate, el programa remoto leerá los datos y el indicador de que la conversación ha terminado.

6.1.2.5. CONFIRMACIÓN DE TRANSACCIONES.

Para verificar que el programa remoto ha recibido y procesado los datos, el programa local puede, mientras esté en modo de envío, ejecutar la función Confirm. Esta función ocasiona el envío del contenido del buffer y solicita una respuesta de confirmación del programa remoto.

76

El uso del Confirm es opcional. Se recomienda en transacciones complejas, en donde un programa puede estar enviando varios datos y de vez en cuando preguntar si el programa remoto los ha recibido y ha terminado de procesarlos satisfactoriamente. Un ejemplo puede ser un programa de transferencia de archivo. La confirmación significa que los datos han sido enviados y grabados exitosamente en disco.

6.1.2.6. MODELOS TRANSACCIONALES.

Aunque hay un número infinito de combinaciones de las funciones de APPC en los programas, es posible escribir aplicaciones completas usando solo las funciones: Allocate, Send_Data, Receive_And_Wait y Deallocate. Usando solo estas funciones, a continuación se describe -sin entrar a los detalles de la programación- una aplicación cliente/servidor de consulta a una base de datos. En este ejemplo se supone que el usuario proporciona un número de artículo para consultar el detalle (descripción del artículo) que se encuentra en el servidor.

Para simplificar el ejemplo, se asume que este programa solo realiza una consulta. En la figura 6.2. se muestra la conversación entre el programa cliente y el servidor.

Figura 6.2. Secuencia de una conversación APPC

Programa Cliente

Inicio

íl Anicate

@) !

Enlace de comun icaciones

Intercambio de datos

Programa Servidor

,nTº Receive_And_Watt 0

Send_Data (núm artículo) ----••-

' J ~ Receive_And_Watt

@MostL dalo

t @) Deallocate

' Fin

Leer Base de Datos

' Send_Data (Descripción)

' Receive_And_Watt

Fin

77

1) El programa cliente ejecuta el Allocate para iniciar una conversación con el programa servidor. Esto ocasiona que programa servidor sea arrancado en modo de recepción y el programa cliente queda en modo de envío.

2) El programa servidor debe ejecutar el Receive_And_Wait para quedar en espera de algún dato.

3) El programa cliente lee el número de artículo proporcionado por el usuario, y lo envía al programa servidor por medio de un Send_Data. A continuación ejecuta la función Receive_And_Wait para quedar en modo de espera. De esta forma el programa cliente queda suspendido hasta que se reciba el dato del programa servidor.

4) Por medio del Receive_And_Wait, el programa servidor recibe el número de artículo y el indicador que el programa cliente ha terminado de enviar, ya que se encuentra en estado de recepción. A partir de este momento, el programa servidor tiene el permiso de enviar datos.

Con el número de artículo, el programa servidor accesa a la base de datos y extrae la descripción del artículo. Este dato es enviado con un Send_Data y a continuación se ejecuta un Receive_And_Wait para que cambie a estado de recepción (el programa servidor queda ahora en modo de espera)

5) El programa cliente lee el dato enviado por el programa servidor y luego muestra el dato al usuario

6) El programa cliente ejecuta el Deallocate, el cual es recibido por el Receive_And_Wait del servidor, con lo cual se termina la conversación.

6.2. APLICACIONES CLIENTE/SERVIDOR CON SOCKETS.

En la actualidad, el TCP/IP es el protocolo de comunicaciones dominante en la industria de cómputo.

De la misma forma que al APPC, el TCP/IP está incluido a nivel microcódigo en el sistema operativo OS/400. Esto repercute en un mejor rendimiento del protocolo de comunicaciones, por lo que el TCP/IP es otra alternativa viable para desarrollar aplicaciones cliente/servidor en AS/400.

El protocolo TCP/IP soporta la aplicaciones cliente/servidor por medio de puertos de comunicaciones llamados sockets. Desde un punto de vista funcional, los programas que usan sockets son muy parecidos a un programa de APPC. Ambas alternativas prorcionan una comunicación de igual a igual.

78

Con los sockets de TCP/IP, un programa cliente usa un canal de comunicación (socket) para enviar y recibir datos con un programa servidor (figura 6.3.).

Figura 6.3. Flujo de datos usando Sockets

PC AS/400

Programa Programa

WINSOCK ITCP/IP 1 =:;.:ón I TCP/IP I

Microcódigo

En la figura 6.3. se puede ver que el programa cliente en el lado de la PC se comunica sobre el enlace TCP/IP por medio de WinSock, que es la implementación de los sockets en ambiente Windows. Para sistemas operativos Windows de 32 bits, el soporte de WinSock es proporcionado por el archivo WSOCK32.DLL.

Cuando el programa cliente envía datos usando el API de WinSock, el dato es pasado al soporte de TCP/IP y luego enviado por el enlace físico de la red. El adaptador de red del AS/400 recibe el paquete y lo pasa a la capa TCP/IP. Ahí se direcciona a un programa de tipo socket que está "escuchando" un puerto específico.

Los programas que usan los sockets de TCP/IP deben seguir una conjunto dado de reglas, muy parecidas a las reglas de APPC. Por lo tanto, el desarrollador de este tipo de aplicaciones debe dominar las herramientas de programación tanto en ambientes Windows como en AS/400. Las aplicaciones del lado de la PC se escriben típicamente en Visual Basic, Delphi ó Visual C++. Por el lado del AS/400, los programas que usan sockets se escriben en C debido a que las bibliotecas de funciones para los sockets en AS/400 se proporcionan para este lenguaje.

79

6.2.1. ESTRATEGIAS DE DISEÑO CON APPC O SOCKETS EN AS/400

Las consideraciones más importantes para diseñar aplicaciones cliente/servidor en AS/400 usando APPC ó Sockets son:

• El código en el cliente puede desarrollarse con cualquier lenguaje de programación en Windows que soporte las llamadas a funciones externas (archivos DLL). Algunos de los lenguajes más conocidos son Visual Basic, Visual C++ y PowerBuilder.

• Acceso a la base de datos: el código en el servidor se encarga de los accesos a los datos, ya sea por medio de interfaces nativas o por medio de SQL.

• Comunicación entre el código cliente con aplicaciones existentes en el AS/400: El código cliente no se puede comunicar con código existente en el servidor. Excepto si el código del servidor se modifica para soportar las funciones de comunicaciones de APPC o Sockets [8].

6.2.1.1. MODELO CLIENTE/SERVIDOR.

El modelo cliente/servidor que se utiliza para escribir aplicaciones con APPC ó Sockets en AS/400 se puede ver en la figura 6.4.

Figura 6.4. Modelo cliente/servidor

Datos

Lógica

Red

Lógica

Presentación

Lógica Distribuida

SERVIDOR

CLIENTE

80

Como se puede observar en la figura 6.4. sólo se soporta el modelo de Lógica Distribuida. Los otros modelos de cliente/servidor estudiados en el capítulo 2, no se soportan debido a que con APPC o con Sockets se requiere programar tanto en el cliente como en el servidor. La aplicación usa las funciones ó APls del protocolo APPC o de Sockets para intercambiar mensajes su contraparte.

81

CAPÍTULO 7. COMPARACIÓN DE ALTERNATIVAS.

En este capítulo se comparan las alternativas principales para crear aplicaciones cliente/servidor en AS/400.

7.1. SOPORTE A LOS MODELOS CLIENTE/SERVIDOR.

Los modelos cliente servidor estudiados el capitulo 2 no son soportados en todos los casos. Por ejemplo, en el caso de APPC o Sockets, el modelo de Datos Remotos no se puede implementar debido a que con estas interfaces de programación es necesario tener código tanto en el cliente como en el servidor. El modelo de Datos Remotos establece que en el servidor sólo es el repositorio de datos y que el cliente contiene toda la lógica de la aplicación así como la interfaz del usuario.

En el caso de ODBC, el modelo de Datos Remotos se puede implementar completamente gracias a que ODBC permite el acceso a los datos remotos del servidor. Por otro lado, con el uso de procedimientos almacenados, es posible implementar el modelo de Lógica Distribuida. Esto es posible debido a que ODBC se basa en el estándar SQL para el acceso a los datos.

Con Java es posible implemetar cualquier modelo de cliente/servidor. A continuación en la tabla 7.1. se resumen los diferentes modelos de cliente/servidor soportados en las interfaces de programación estudiadas:

Tabla 7.1. Modelos de cliente/servidor soportados por las interfaces de programación.

Modelos Cliente/Servidor Interfaces (Capítulo 2)

Presentación Presentación Logica Datos Datos Remota Distribuida Distribuida Remotos Distribuidos

ODBC X X X

APPC X X

Sockets X X

JAVA X X X X X

82

7 .2. EFICIENCIA DE LA APLICACIÓN.

A continuación en la figura 7.2. se compara el rendimiento relativo de una aplicación cliente/servidor versus el grado de complejidad o esfuerzo requerido para desarrollar dicha aplicación.

Figura 7.2. Eficiencia de las aplicaciones.

B'i ciencia de la aplicación

Menor

APP C ó Sod<E!s

O 09 C y Prooedirrientos Ama::ena:los

Lógca Ostribuidi! con Java

Presentación Remeta con ..lalllil

009Csin .A.Pis

Menor Complejidad de desarrollo

Mayor

Como se puede observar en figura anterior, es posible utilizar herramientas que simplifican el desarrollo de una aplicación pero la eficiencia ó tiempo de respuesta al usuario se afecta. En el caso de ODBC, muchos lenguajes en ambiente Windows proporcionan utilerías para accesar los datos sin necesidad de escribir una línea de código, sin embargo, como se ha estudiado en los capítulos anteriores, estas técnicas se recomiendan para aplicaciones que usan datos locales o bien, que tienen poco acceso a los datos.

Para obtener aplicaciones más eficientes, se deben usar las APls directamente y combinarlas con los procedimientos almacenados, ya sea con ODBC o con Java.

Las aplicaciones con el mejor tiempo de respuesta se logran por medio de las interfaces como APPC ó Sockets. En el capítulo 6 se mostró que con estas técnicas el grado de complejidad en el desarrollo es mayor.

83

7.3. PORTABILIDAD DE LA APLICACIÓN.

En la figura 7.3. se compara la portabilidad de una aplicación dependiendo de la interfaz de programación utilizada.

Figura 7.3. Comparación de la portabilidad

D atos Remotos con Java

ODBC con APls

ODBC sin APls

Lógica Distribuida con Java

Java y Proc. Almacenados

OD BC y Pro c. Almacenados

APPC ó Sockets

Menor

Portabilidad de la aplicación

May;,r

Las aplicaciones más portables se logran utilizando a Java o ODBC bajo el modelo de Datos Remotos. Esto se debe a que no existe código en el servidor. En caso de mover la aplicación a otro servidor, sólo es necesario contar con un esquema de datos similiar en el nuevo servidor. Las aplicaciones menos portables son aquellas que se han desarrollado con APPC. Esta interfaz de programación es propietaria y requiere que exista código tanto en el cliente como en el servidor, lo que minimiza la portabilidad de la aplicación.

El uso de procedimientos almacenados con Java o ODBC también afecta a la portabilidad, aunque su beneficio es incrementar la eficiencia de la aplicación. Si se usan procedimientos almacenados, se recomienda que se escriban con SQL puro (estándar ANSI SQL3) ya que de esta forma es más facil portar el código hacia otros servidores con bases de datos relacionales.

Para una comparación más exhaustiva en términos de portablilidad y eficiencia, en las siguientes secciones de describen las característias de las principales alternativas para crear aplicaciones cliente/servidor. Se estudian los beneficios y las consideraciones a tomar en cuenta en cada opción.

84

7.4. DESARROLLO DE APLICACIONES CON JAVA.

Como se mecionó en el capítulo 4, una de las características más importantes de Java es que se puede desarrollar una aplicación en cualquier tipo de computadora y luego ejecutarla en otras, siempre que la computadora tenga una máquina virtual JVM. Las aplicacionees de Java que en algún momento correrán en el AS/400 pueden ser creadas en una PC con NT, o en plataformas UNIX.

En la plataforma del AS/400, el uso de cliente/servidor para desarrollar aplicaciones ofrece las siguientes ventajas [7].

• Reducir el tiempo y el costo de desarrollo debido a que los componentes pueden ser reutilizados.

• Proporcionar un ambiente de programación orientada a objetos para aplicaciones comerciales en internet. Java se está convirtiendo en lenguaje más usado para agregar lógica a las páginas web. Los desarrolladores de software puede asumir que cada tipo de computadora ofrece en la actualidad una JVM .

• Se facilita la actualización de aplicaciones obsoletas. En este tipo de aplicaciones, el cambio hacia Java se inicia por el uso de interfaces gráficas. En el capítulo 4 se explican las herramientas y el modelo a seguir para la modernización de aplicaciones en AS/400.

• Se facilita la tarea de obtener recursos humandos entrenados en un ambiente de desarrollo estándar. El número de programadores en Java se está incrementando. Los programadores que ya conocen otro lenguaje, usualmente prefieren a Java sus características de portabalidad, simplifidad y como lenguaje de internet. La mayoría de las universidades ha yan incluido el Java en sus programas de estudio.

7.4.1. CONSIDERACIONES AL USAR JAVA.

A pesar de la ventajas enunciadas.el Java no es todavía un ambiente perfecto de desarrollo. Exsiten algunas consideraciones a tomar en cuenta antes de usarlo en el desarrollo de aplicaciones.

85

7.4.1.1. DIFUSIÓN DEL LENGUAJE.

El Java todavía no es usado ampliamente para crear aplicaciones de negocio en los servidores. Este cambio puede darse conforme los componentes EJB estén disponibles.

La mayoría de los proveedores actuales que desarrollan paquetes de software usan preferentemente C, C++ u otras herramientas basadas en el modelo COM (Component Objete Model) de Microsoft. Algunos han empezado a experimentar con Java, sin embargo, muchos de estos proveedores esperan cambiar a Java conforme se incremente el número de componentes JavaBeans disponibles y el ambiente de Java llegue a ser más maduro [1 O].

Como un leguaje orientados a objetos, lo ideal es que los desarrolladores puedan disponer de bibliotecas completas de componentes de software como base para el desarrollo. Las especificaciones para los componentes han empezado a aparacer, Uno de los esfuerzos más importanes se llama Enterprise JavaBeans (EJB), que es una colección de componentes de Java que simplificará en gran medida el proceso de crear aplicaciones transaccionales.

7.4.1.2. RENDIMIENTO.

Otro problema serio que actualmente tiene Java tiene que ver con la cantidad de recursos de cómputo requeridos para correr los programas. Existen dos razones por las cuales el Java consume gran cantidad de recursos. En primer lugar, mientras se ejecuta una aplicación, la máquina virtual JVM está diseñada para convertir el bytecode en código de máquina, tomando instrucción por instrucción, lo cual disminuye la velocidad de la ejecución. En segundo lugar, los lenguajes orientados a objetos son por lo general más lentos que los lenguajes procedurales debido a la sobrecarga propia de los objetos.

En suma, Java requiere de más poder de cómputo que otros lenguajes. La historia de la computación muestra que cada avance importante en la tecnología de software trae un impacto adverso en el rendimiento. Por ejemplo: la aparición del Fortran o Cobol, versus el ensamblador y el cliente/servidor versus terminales de caracteres.

Parte del problema del rendimiento puede ser mejorado con el uso de la precompilación del código en AS/400. En general, las aplicaciones de Java son convertidas por la máquina virtual a instrucciones de máquina al momento de ejecución. Sin embargo, si la aplicación es de uso común en el AS/400, existe la alternativa de convertir sólo una vez el bytecode en instrucciones nativas de máquina

86

y almacenar estas instrucciones. Cada ejecución posterior de la aplicación será en realidad una ejecución directa, lo cual mejora significativamente el rendimiento.

7.4.1.3. ESCALABILIDAD

La forma actual en que Java maneja los bloqueos y la sincronización ocasiona que no se aproveche completamente el procesamiento simétrico SMP (Symmetrical Multiprocesor) de los servidores. En algunos servidores, incluyendo al AS/400, el problema se minimiza con el manejo propio que el sistema tiene para procesos concurrentes. Cuando existe contención de recursos, exsiten mecanismos dentro del microcódigo que mejorar la utilización del procesamiento simétrico.

7 .4.1.4. MANEJO DE MEMORIA.

Cuando se compara con otros lenguajes maduros, en Java no se cuenta con un manejo adecuado para las tareas de limpieza de los objetos no usados . Debido a que los programas de Java tienden a requerir un espacio grande de memoria, este manejo puede ser un aspecto serio a considerarse. Algunas implementaciones de JVM, como en el AS/400, incluyen herramientas de "limpieza" concurrente de áreas de memoria no usadas, lo cual simplifica el manejo de recursos por parte de la aplicación.

7.5. DESARROLLO DE APLICACIONES CON ODBC.

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 a la base de datos es la mejor opción.

La opción del ODBC sobresale sobre otras interfaces si es que los requerimientos son accesar la base de datos con SOL y contar con una aplicación totalmente portable [8]. Por otro lado, se tiene también la ventaja de simplificar el desarrollo ya que no es necesario programar del lado del AS/400. Todo el desarrollo se puede realizar del lado del cliente, lo cual nos permite utilizar herramientas de desarrollo comunes en el ambiente de PC, como o lenguajes de cuarta generación (4GL) y/o lenguajes visuales.

Sin embargo, con la alternativa de ODBC 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 el ODBC se puede implementar de distintas maneras. Muchos lenguajes como VB incluyen funciones de alto nivel (como el Data Control de Visual Basic) que simplifican el desarrollo de la aplicación pero que no proporcionan eficiencia en el acceso a los datos.

87

Para obtener más flexibilidad en la programación de las transacciones y contar con el mejor tiempo de respuesta, con ODBC se tienen estas opciones:

a) Usar directamente las APls de ODBC.

b) Usar las APls de ODBC en combinación con las técnicas marcadas en el modelo de un Servidor de Transacciones, en donde se utilizan las facilidades de Procedimientos Almacenados del servidor. Esta opción ocasiona que se tenga que desarrollar código del lado del AS/400. Este código se puede elaborar usando algún lenguaje nativo como COBOL o RPG, o bien, usando el lenguaje portable de SOL puro.

7.5.1. CONSIDERACIONES AL USAR ODBC.

Para usar efectivamente a ODBC en el desarrollo de aplicaciones cliente/servidor con AS/400, es necesario usar APls desde el código cliente. Sin embargo, el aprendizaje de las APls puede ser una tarea complicada para el desarrollador de sistemas tradicionales de AS/400.

Por lo tanto, el uso de las APls de ODBC no se recomienda si el desarrollador de aplicaciones no tiene experiencia en programación con lenguaje C. Esto se debe a que la documentación de las APls se basa en la nomenclatutar y en tipos de datos en C.

Las APls son funciones externas incluidas en archivos DLL (Dynamic Link Library) y frecuentemente están codificadas en lenguaje C. Al usar una API, el programador tiene que entender los detalles de paso de parámetros, manejo de variables de tipo string, conversión de tipos de datos, manejo de los códigos de retorno, etc.

Una consideración adicional en el uso de ODBC es que muchos desarrolladores utilizan a a ODBC como un mecanismo de acceso a nivel registro, es decir, se utiliza una sentencia SQL para recuperar sólo un registro. Aunque esto es válido en ODBC, el nivel de expectativa del programador es que este acceso debe ser igual de rápido como en los accesos de las aplicaciones nativas corriendo en AS/400 ( escritas en COBOL por ejemplo).

Una alternativa es utilizar el recurso de los procedimientos almacenados. Como se mencionó en el capítulo 5 de ODBC, los procedimientos son ideales para incrementar el tiempo de respuesta de los accesos a la base de datos. Sin embargo, la consideración a tomar en cuenta es que la aplicación cliente queda más acoplada hacia el sistema servidor, es decir, se pierde portabilidad. Una de las premisas de ODBC es que la aplicación puede obtener el mismo resultado si se accesa a una base de datos diferente sólo con cambiar el Driver de ODBC. Al usar procedimientos almacenados en un servidor específico, resulta más difícil lograr la portabilidad completa.

88

7.6. PROTOCOLOS A NIVEL DE TRANSPORTE.

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.

No hay un método más rápido para comunicar una aplicación cliente con el AS/400 que por medio de APPC (basado en SNA) o de Sockets (basados en TCP/IP). Esto se debe a que la conexión entre el programa en la PC y el programa en el AS/400 es de manera directa. El intercambio de datos se realiza con un mínimo de capas de software. Por estas características, los protoclos a nivel de transporte son la base para la mayoría de las productos cliente/servidor en AS/400.

Sin embargo, el costo de obtener este rendimiento es la complejidad del desarrollo de los programas. Para desarrollar estas aplicaciones se deben entender los conceptos de comunicaciones . Otra consideración adicional es que es necesario programar tanto en ambiente de AS/400 como de PC

Esta alternativa es ideal para, por ejemplo, si alguien desea desarrollar una aplicación gráfica para controlar la seguridad del AS/400, o una aplicación para el monitoreo de las comunicaciones o del rendimiento del sistema. En este caso se deben crear programas en el AS/400 que intercambien datos con el programa cliente. De hecho, muchas empresas desarrolladoras de software para AS/400, incluyendo a IBM, utilizan APPC o Sockets para desarrollar, entre otros productos, emuladores de terminales, administradores gráficos de la base de datos, administradores de usuarios, etc.

7.6.1. CONSIDERACIONES DE APPC.

A continuación se resumen las características de APPC:

• El APPC se recomienda para el desarrollo de aplicaciones en donde se requiera el máximo rendimiento. Para estas aplicaciones, el esfuerzo de desarrollo se compensa por el rendimiento obtenido. Para aplicaciones desarrolladas dentro de la misma empresa, no se justifica el esfuerzo.

• En las aplicaciones de APPC, el desarrollador siempre tendrá que codificar los programas servidores. Estos programas son escritos en algún lenguaje del AS/400 (COBOL, RPG, C, etc.).

• Cada vez que una conexión de APPC se arranca, el AS/400 crea un trabajo diferente. Esto significa que por cada usuario remoto, el AS/400 arranca un proceso. Aunque es posible diseñar el programa servidor para que atienda a varios clientes, esto dificulta el diseño de la aplicación.

89

• Uso de conversaciones tipo duplex. Por omisión, las conversaciones de APPC son del tipo half-duplex. Esto significa que solo un programa puede enviar datos en un momento dado. Cuando el otro programa requiere enviar, la dirección de la conversación debe ser cambiada. Este proceso de cambio toma tiempo. Una técnica para eliminar el cambio de dirección es establecer desde el inicio una conversación de tipo duplex. Al tener dos conversaciones, una se utiliza para el envío y la otra para la recepción.

• Debido a que con APPC la el cliente y el servidor se comunican directamente entre sí, es posible tener mayor control de la recuperación de errores. El APPC ofrece un conjunto extenso de códigos de retorno y de indicadores del estatus que permiten un dignóstios preciso. Estos códigos de retorno también indican si un error está asociado con la conexión física, el flujo de comunicaciones o si el error provienen de una terminación anormal del programa remoto.

• El APPC también proporciona un mecanismo sencillo por medio del cual el programa cliente o servidor pueden interrumpir el flujo de datos y notificar a la contraparte que se encontró un error a nivel de aplicación. Los programas pueden luego tratar de corregir el error y resincronizar el intercambios de datos

• El diseño de los programas cliente y servidor debe considerar de antemano la sincronización del intercamio de datos. Por ejemplo, en una aplicación simple para insertar un renglón a una base de datos, el diseño debe considerar que el programa cliente iniciará la conversación, enviará el registro de datos y esperará el mesaje de verificación de que los datos fueron insertados exitosamente. El programa servidor se encargará de aceptar la conversación, recibir los datos, insertar el renglón en la base de datos y enviar el mensaje que la operación fué exitosa. En uno de los programas, sólo se permiten modificaciones que no afecten al flujo predefinido de la conversación. Por ejemplo, el programa servidor puede ser modificado para utilice la información enviada por el cliente para que actualice varias tablas de la base de datos. Este cambio no afecta el código del programa cliente.

• El APPC proporciona seguridad para las sesiones y conversaciones. La seguridad a nivel sesión garantiza que sólo los dispositivos remotos autorizados puedan inciar una conexión. La seguridad a nivel conversación se encarga de validar la identificación de usuario y contraseña proporcionados en el sistema remoto.

• El desarrollar de aplicaciones APPC puede hacer uso del procesamiento traslapado. El procesamiento traslapado ocurre cuando el programa cliente envía el requerimiento al servidor y a continuación contínua con otras tareas en lugar de tener que quedar en modo de espera por la respuesta del servidor. El servidor recibe la petición del cliente y puede construir la respuesta mientras el cliente realiza tareas útiles (como preparar la siguiente petición, abrir bases de datos locales, etc.). Cuando el cliente está listo para recibir la respuesta, es muy probable que el servidor ya haya enviado la respuesta y se encuentre en el buffer local de

90

APPC. Este mecanismo incrementa el rendimiento de la aplicacción y disminuyen los tiempos de espera por parte del usuario.

7.6.2. CONSIDERACIONES DEL USO DE SOCKETS.

A continuación se mencionan las características principales del desarrollo de aplicaciones cliente/servidor en AS/400 usando sockets.

• Usar los sockets de TCP/IP para aplicaciones comerciales. Los sockets son un excelente alternativa para el desarrollo de aplicaciones comerciales y para aplicaciones en donde se requiera el máximo rendimiento. En estos casos, el esfuerzo de desarrollo se compensa por el rendimiento obtenido. Para aplicaciones de menor escala desarrolladas dentro de la misma empresa, no se justifica el esfuerzo.

• Las aplicaciones con sockets requieren programas servidores en el AS/400. Con sockets, el desarrollador siempre tendrá que codificar los programas servidores. Estos programas son escritos usando el lenguaje C del AS/400.

• Los datos enviados entre el AS/400 y la PC deben ser convertidos. Debido a que el el AS/400 usa un código de carácter EBCDIC que es diferente al ASCII, el desarrollador necesita usar las funciones de sockets de conversión de datos antes de enviarlos al AS/400. De la misma forma, los datos regresados del AS/400 deben ser convertidos usando estas funciones. Para WinSock, la conversión de datos se realiza con las funciones htonx (host-to-network) y ntohx (network to host). La letra x debe ser sustituida de acuerdo al tipo de datos. Por ejemplo, la función htons se utiliza para variables de tipo Short.

91

CAPÍTULO a.CONCLUSIONES Y RECOMENDACIONES

En este trabajo se han mostrado las principales herramientas para desarrollar aplicaciones cliente/servidor con el AS/400. La aportación básica de este trabajo es proporcionar los elementos que pueden servir de referencia para que las áreas de sistemas que cuentan con equipos AS/400 puedan definir su estrategia de desarrollo de aplicaciones cliente/servidor.

Las herramientas estudiadas son Java, ODBC y las interfaces a nivel de transporte como Sockets en redes TCP/IP y APPC en redes de tipo SNA.

Desde luego, existen otras alternativas para producir aplicaciones Cliente/Servidor con AS/400. Algunas de estas alternativas son: Data Queues y OLE/DB.

Sin embargo, tomando en consideración que las áreas de sistemas que cuentan con AS/400 están más enfocadas al desarrollo de aplicaciones transaccionales con la Base de Datos, el uso de interfaces portables basadas en el estándar SQL representa la mejor alternativa de desarrollo. Las interfaces estudiadas de Java y ODBC se basan en el estándar SOL para el acceso a los datos remotos.

Como se ha mencionado, la opción del ODBC en AS/400 produce aplicaciones totalmente portables y eficientes. Por otro lado, se tiene también la ventaja de simplificar el desarrollo ya que no es necesario programar del lado del AS/400. Una ventaja adicional es que la codificación de la aplicación "cliente" se puede realizar por medio de un lenguaje visual fácil de usar. Sin embargo, en la actualidad el ODBC se percibe por la industria de cómputo como un mecanismo de acceso lento a los datos remotos, por lo que el número de desarrolladores con experiencia en ODBC es escaso.

La opción del Java presenta también la ventaja de crear aplicaciones totalmente portables. El Java se puede utilizar inicialmente en el AS/400 como un lenguaje para nuevas aplicaciones y para modernizar partes de la aplicaciones existentes, especialmente la interfaz del usuario. Sin embargo, hasta que el Java ofrezca el rendimiento en acceso a base de datos y mejore sus capacidades de reporteo, el COBOL y otros lenguajes permancerán como lenguajes más usados en el AS/400 para aplicaciones de negocios.

Esto significa que en algunas empresas no existe razón para reescribir sus aplicaciones hacia Java, sobre todos las funciones típicas transaccionales con la base de datos. En cambio, cuando se requiere portabilidad, productividad por medio de programación orientada a objetos, y beneficios de la reutilización, la estrategia debe ser el uso de Java ya que en estos casos es en donde se ubica mejor.

92

El uso de las interfaces de APPC o Sockets no se recomiendan para los departamentos de sistemas que cuentan con AS/400 y que desarrollan aplicaciones transaccionales con la base de datos. Estas interfaces ocasionan que el desarrollo de las aplicaciones se complique al tener que codificar tanto en el cliente como el servidor. En cambio, debido a que con estas herramientas se obtiene el mejor tiempo de respuesta, su uso es más común en proveedores de aplicaciones.

Para mostrar las ventajas señaladas de portabilidad y eficiencia, en este trabajo se han explicado las siguientes técnicas:

a) Uso directo de las APls de ODBC.

Las APls de ODBC son funciones externas a la aplicación que se encuentran incluidas en el archivo ODBC32.DLL. Al usar una API, se tienen que entender los detalles de paso de parámetros, manejo de diferentes formatos de datos e interpretar los diferentes códigos de retorno. Debido a esto, se requieren de más líneas de código para realizar una tarea simple. Por ejemplo, para ejecutar una sentencia SELECT de SQL, se tienen que usar al menos las funciones de SQLPrepare, SQLExecute, SQLFetch y SQLGetData. Sin embargo, el uso directo de las APls produce el mejor rendimiento de la aplicación.

No se recomienda el uso de las funciones predefinidas que algunos lenguajes tienen para simplificar el acceso a los datos con ODBC, ya que estas funciones no proporcionan las eficiencia que se requiere en las aplicaciones cliente/servidor multiusuario y de misión crítica.

b) Procedimientos Almacenados.

Los procedimientos almacenados se utilizan para maximizar el rendimiento de las aplicaciones distribuidas ya que reduce significativamente el tráfico de información entre el programa cliente y el servidor.

En una sola instrucción el programa cliente puede enviar varios parámetros al procedimiento almacenado.

Los procedimientos almacenados pueden ser invocados desde aplicaciones ODBC o desde Java por medio del Driver JDBC.

El programa servidor puede ser codificado en cualquier lenguaje nativo del servidor, sin embargo, para seguir contando con la característica de portabilidad de la aplicación, se recomienda que el procedimiento almacenado se codifique usando el lenguaje estándar de SQL conocido como SPL (Stored Procedure Language). Este lenguaje se basa en el estándar SQL3 de ANSI. La ventaja de este enfoque es que el código del servidor se puede mover entre diferentes plataformas que soporten el SPL. La mayoría de las bases de datos relacionales actuales lo soportan.

93

8.1. SOPORTE DE NUEVAS TECNOLOGÍAS.

Por otro lado, en cuanto al soporte de nuevas tecnologías para el desarrollo de aplicaciones distribuidas, es necesario mencionar que los negocios através de internet ó "e-business" es la tendencia que permite a las empresas enfrentar los retos del mundo de negocios actual. Las empresas deben responder más rápidamente a los cambios en el mercado, reducir los ciclos de desarrollo de sus productos, mejorar la colaboración dentro de su organización y llevar sus productos a nuevos mercados, aprovechando las tecnologías de internet para extender el alcance y el rango de sus servidores.

La definición e-business es más amplia que el concepto de comercio electrónico [3]. De hecho, dentro de e-business se encuentran las aplicaciones de comercio eléctrónico para el relacionamiento de los clientes de la empresa, así como las aplicaciones de administración de la cadena de suministro y las aplicaciones de tipo colaborativas dentro de la empresa.

Las soluciones en el mundo de internet son una nueva generación de aplicaciones que tienen ciertos requerimientos diferentes [5]. En primer lugar se deben basar en estándares abiertos, de esta forma las aplicaciones pueden tener la flexibilidad de soportar la coexistencia y el acceso a otras aplicaciones futuras.

Una segunda característica es que las aplicaciones necesitan ser construidas para ser escalables sin tener que reescribirlas. Cuando no se puede manejar la demanda de utilización de una aplicación, no es posible entregar el nivel de rendimiento esperado por los usuarios. Otras características importantes son la seguridad y la integración adecuada con las aplicaciones existentes.

El sistema AS/400 proporciona la tecnología para incorporar las nuevas iniciativas de los usuarios, tales como el soporte a los estándares actuales de internet y el soporte a aplicaciones de tipo colaborativas.

Para que el sistema AS/400 funcione como servidor de páginas Web, se puede utilizar el producto "HTTP Server'', el cual forma parte del sistema operativo. Este producto proporciona pricipalmente los siguientes servicios:

• Actúa como un repositorio de páginas Web creadas con HTML y proporciona el servicio de transferencia de documentos solicitados desde un navegador con HTTP.

• Soporta los protocolos de seguridad SSL y HTTPS para la encriptación de datos. • Proporciona una interfaz a las aplicaciones por medio de CGI (Common Gateway

Interface). • Soporte del SNMP Subagent lo cual permitie el manejo de datos estadísticos de los

servicios Web.

94

Con respecto al desarrollo de aplicaciones "e-business" en AS/400, una de las principales alternativas es utilizar el producto WebSphere. Este producto permite aprovechar las capacidades que ofrece Java de "escribir la aplicación una vez y ejecutarla en cualquier sistema". El producto WebSphere proporciona un ambiente de ejecución para los "servlets" de Java, así como acceso a la base de datos y a otros recursos a través de conectores y agentes de objetos estándares en la industria. Esto significa que las empresas pueden lograr que cualquier sistema con capacidades de correr un navegador habilitado para Java ( como por ejemplo una computadora de red o una estación de trabajo UNIX) ejecute aplicaciones corriendo en AS/400 a través de la red.

Otra alternativa importante para el desarrollo de aplicaciones en internet en AS/400 es el producto Domino de Lotus. Este producto originalmente se conocía sólo como Lotus Notes. En la actualidad, el término Domino se refiere a la parte que corre en el servidor y Notes es el componente cliente.

Las aplicaciones y los sitios Web desarrollados pueden ser accesados usando cualquier navegador como Netscape o Internet Explorer.

Por medio de Lotus Domino se pueden obtener diversos servicios, tales como:

• Correo electrónico.

• Desarrollo de páginas Web.

• Servicios de base de datos para documentos.

• Herramientas visuales para desarrollo de aplicaciones cliente/servidor.

• Desarrollo de aplicaciones colaborativas.

Para los desarrolladores de aplicaciones que han trabajado con bases de datos tradicionales y rutinas procedurales, el cómputo colaborativo es un concepto diferente. Por ejemplo, los requerimientos de datos en el cómputo colaborativo son muy diferentes de los servicos que una base de datos relacional proporciona. En las aplicaciones colaborativas, los usuarios compartes diferentes clases de datos. Además de los datos estructurados en renglones y columnas, se requieren datos no estructurados como son hojas de cálculo, documentos de texto, gráficas, o gran cantidad de textos.

El Lotus Domino está diseñado para manejar y organizar datos de diferentes tipos . Un ejemplo de una aplicación colaborativa es el proceso de contratación de empleados. Por medio de una aplicación colaborativa se puede controlar el proceso de las entrevistas, de tal forma que los diferentes entrevistadores compartar la misma información: la imágen digitalizada del curriculum, las respuestas de la entrevista anterior, etc. Otros ejemplos similares son el proceso de adquisiciones del departamento de compras y el proceso de autorizaciones de gastos de viaje.

95

Con respecto al soporte para desarrollo de aplicaciones en internet, tanto los servicios de Domino en el servidor, como de Notes en el cliente soportan una variedad de estándares de internet. Se incluyen herramientas para servicios Web, agente de tranferencia de mensajes SMTP/MIME, soporte a los estándares IMAP y POP3, servidor NNTP (Network News Transport Protocol, el servicio LDAP (Lightweight Directory Access Protocol) y SSL 3.0.

El soporte a esta variedad de estándares permiten que el sistema AS/400 pueda participar como servidor de aplicaciones para usuarios internos sobre redes de tipo intranet, y para usuarios externos sobre extranets. Las aplicaciones de este tipo combinan las funciones de publicación de páginas Web, correo eléctrónico y el "e-business".

96

BIBLIOGRAFÍA

(1] E. Wain Right; Jeff Ray; A. Hoffer. "Managing the lnformation Technology what managers need to know". 2nd. Edition. Prentice Hall.

[2] Peter Burris; Chris Christiansen. "Midyear Update: Cost-to-Use of Midrange and PC LAN System in the Networked Enterprised". lnternational Data Corporation.

(3] Jim Hoskins. "Exploring IBM Technology and Products". Maximum Press

[4] David Andrews; Roy Bauer; Janet Puistonen. "The AS/400: In a class by itself'. ADM Consulting, lnc.

(5] Frank G. Soltis. "lnside the AS/400". Duke Press.

[6] Microsoft." ODBC 2.0 Reference and SDK Guide", Microsoft Press.

[7] Phil Coulthard; George Farr. "Java For RPG Programmers". Advice Press

(8] Roy Janes "Visual Basic with Client Access APls". Duke Press.

[9] Robert Gryphon; Luc Charpentier. "Using ODBC". Quebooks.

[1 O] Jeniffer Hamilton. "Object Oriented Programming for AS/400 Programmers". Duke Press.

[11] Paul Cante. "DataBase Desing and Programming for 082/400". Duke Press

[12] Laura Lemay, Charles Perkings. "Aprendiendo JAVA". Prentice Hall.

97