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

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

~' - - - ~$:;,
~ ·· A•l',~')LJc: ~ \
},~
de;,,
~~
~'
··~s-
li V

: . ._ 1·¡·,. DO
,._. '°
~ " l.:.

T1"" ~
1

INSTITUTO TECNÓLOGICO Y DE ESTUDIOS SU_PERIORES DE MONTERREY \ \ ¡,¡.f:\t~~O ,§)

CAMPUS ESTADO DE MEXICO ~,?,,,. - ,.-.. • · ..'.~.~/
~SN¡
~---~ .. -··
L1'i>t~\'./"

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.

 '·..-· . . , .-...··
• .. , • ,, ,
,,

..
/ _:~ '
' , .., ·...
-. ·, ")

.
:.; < .
·,.;
·: •:

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

Página

CAPÍTULO 1: ANTECEDENTES Y OBJETIVOS 8

1.1. Antecedentes 8
1.2. Justificación 10
_1.3 . Objetivos 13
1.4. Metodología 13

CAPÍTULO 2: ESTADO DE ARTE 15

2.1. El ambiente de desarrollo de aplicaciones 15

2.2. El concepto cliente/servidor 16
2.3. Modelos cliente/servidor 17
2.4. Factores alrededor de cliente/servidor 20
2.5. Conclusiones 28

CAPÍTULO 3: LA BASE DE DATOS EN AS/400 30

3.1 . Antecedentes de 082/400 30

3.2 . Características de 082/400 31
3.3. Conclusiones 39

CAPÍTULO 4: APLICACIONES CON JAVA 40

4.1. Antecedentes de Java 40

4.2. Control de Java 42
4.3 . Soporte de Java en AS/400 43
4.4. Estrategias de diseño con Java en AS/400 45
4.5. Modelos de aplicaciones 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 Datos Datos

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

SERVlDOR

Red

CLIENTE Datos

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

Presentación Presentación Presentación Presentación Presentación

Presentación Presentación Lógica Datos Datos

Distrib..Jida Remota Distrib..Jida Remotos Oistri b.Ji oos

1) Presentación Distribuida
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
DD DD..- APls de ODBC

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

ve_r~d_e_
~--º_ri_ o_o_s c_ ~I ~~;;ioec .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
Ejecución
API API

Driver Manager
API
D
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 Datos

Lógica
roe. Almacenados

SERVIDOR
Red

CLIENTE Datos

Lógica Lógica Lógica

Presentación Presentación Presentación

Lógica Datos Datos

Distribuida Remotos Distribuidos

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

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 Programa
TP Cliente TP Servidor

111
Funciones
APPC
Funciones
APPC
!!j
Ruteador APPC en
(LU 6.2) 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

Enlace de
Programa Cliente comun icaciones Programa Servidor

Intercambio de datos
Inicio

íl Anicate ,nTº
@) ! Receive_And_Watt 0
Send_Data (núm artículo) - - - - • • -

'
Receive_And_Watt
J~
Leer Base de Datos

@MostL dalo
''
Send_Data (Descripción)

Receive_And_Watt

@) t
Deallocate

'
Fin 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
SERVIDOR
Lógica

Red

Lógica
CLIENTE
Presentación

Lógica
Distribuida

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.

APP C ó Sod<E!s

O09 C y Prooedirrientos Ama::ena:los

B'i ciencia de
la aplicación Lógca Ostribuidi! con Java

Presentación Remeta con ..lalllil

009Csin .A.Pis
Menor
Menor Mayor
Complejidad de desarrollo

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 May;,r
Portabilidad de la aplicación

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