Aplicaciones en AS/400 con APPC Y Sockets
Para el desarrollo de aplicaciones en AS/400, existen disponibles diversas alternativas desde el tradicional RPG, hasta herramientas nuevas como Java y Domino. Como hemos visto en artículos anteriores, de la alternativa seleccionada depende que las aplicaciones desarrolladas presenten ciertas ventajas, como interoperabilidad, portabilidad, facilidad de desarrollo y mantenimiento.
Por ejemplo, si se toma la alternativa de usar interfaces como APPC o Sockets en combinación con RPG, COBOL o C, se están accesando directamente las funciones 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 requiere interactuar con algunas funciones de comunicaciones y de programar tanto en ambiente de AS/400 como de PC.
Esta alternativa es ideal en ciertos requerimientos especiales, por ejemplo, si alguien desea desarrollar su propia aplicación gráfica de control de lí neas de comunicaciones, para monitorear la seguridad del AS/400, o para aplicaciones gráficas con el mejor rendimiento. En estos casos 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 las interfaces propietarias del AS/400 para crear, entre otros productos, administradores gráficos de la base de datos, administradores de usuarios, herramientas para transferencia de datos, aplicaciones ERP, etcétera.
Tomando en cuenta que en algunas empresas existen este tipo de requerimientos, a continuación se explican las consideraciones a tomar en cuenta en el desarrollo con interfaces como Sockets o APPC.
1. APPC
El protocolo de comunicaciones APPC (Advanced Program-to-Program Communications) ha jugado un papel único como alternativa de comunicación entre programas distribuidos. 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.
Este protocolo permite que dos programas entren en sincronía 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 o de las retransmisiones, de ahí el té rmino "Avanzada". El protocolo APPC implementado en el sistema operativo o en el software de comunicaciones proporcionado por el proveedor, se encarga de estos aspectos transparentes para el programador.
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 o simplemente TP. En la figura 1. se muestra el concepto de los programas TPs:
Un TP es el programa que usa los servicios del protocolo APPC 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étera, se especifican dentro del programa TP cliente. Este programa invoca los servicios del programa TP servidor, el cual envía los datos. En suma, los TP's 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 algunos ERP, o bien aplicaciones creadas dentro del área de sistemas de una empresa.
Los programas servidores se escriben generalmente en lenguaje COBOL, RPG o 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 APPC.
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 o Windows, por lo que es necesario instalar un software de comunicaciones como Client Access/400.
1.3. FUNCIONES (APIS) DE APPC.
En párrafos anteriores, se ha mencionado que existe una comunicación entre los programas y el APPC. 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 o funciones de APPC.
Otras funciones típicas son: envíar datos al TP, recibir datos desde un TP y terminar la conversación. Cada una de estas funciones es ejecutada por el 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 (Intersystem Communication Facility) o por medio de funciones CPI-C (Common Programming Interface-Communications).
Una función de APPC puede interpretarse como la llamada a un procedimiento o a un subprograma. Cuando el programa ejecuta la función de APPC, queda en espera de 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 un 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 determinado, 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.
1.4. 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 el ruteador por medio de una función de APPC. A su vez, el ruteador 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. Las arquitecturas de comunicaciones (como SNA o TCP) definen 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:
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étera.
b) La secretaria guarda la información en un sobre 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 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étera.
e) La empresa de mensajería se encarga de llevar el paquete al departamento de correspondencia de la oficina remota.
f)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).
g) 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étera.
Para que exista la comunicación horizontal, debe establecerse un conjunto de convencionalismos o "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 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. Control de Ruta
6. Control de Enlace de Datos
7. Control Físico
El software de comunicaciones que implementa el APPC en Windows (por ejemplo, el ruteador de Client Access/400) se encarga realizar las cuatro primeras capas de la arquitectura SNA.
1.5. 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 (Intersystem Comunications Function) y por medio de CPI-C (Common Programming Interface- Comunications). La forma más común es por medio de archivos ICF.
Un programa en la PC, por ejemplo en Visual Basic, accesa a las funciones de APPC por medio de las APIs 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.
1.6. 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 programa 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, 4 funciones 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 de ODBC y Java (estudiadas en artículos anteriores).
1.6.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 del sistema remoto.
b) el nombre del programa remoto. Este es el programa servidor a arrancarse en el sistema remoto.
Cuando el Allocate es ejecutado, las rutinas de APPC dentro del sistema local, tratan de encontrar una sesión de comunicaciones para asignarla al programa. 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.
1.6.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.
1.6.3. RECEPCIÓN DE DATOS.
Un programa puede recibir los datos con la función Receive_And_Wait. Esta función lee el dato del buffer de comunicaciones local. Si no hay datos, el programa queda suspendido hasta que llegue uno.
1.6.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.
1.7 MODELOS TRANSACCIONALES.
Aunque hay un número infinito de combinaciones de las funciones de APPC en los programas, es posible escribir aplicaciones completas usando sólo las funciones: Allocate, Send_Data, Receive_And_Wait y Deallocate. Usando sólo 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 sólo realiza una consulta. En la figura 2 se muestra la conversación entre el programa cliente y el servidor.
1) El programa cliente ejecuta el Allocate para iniciar una conversación con el programa servidor. Esto ocasiona que el 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.
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 proporcionan una comunicación de igual a igual. 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
En la figura 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. 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 o 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.
3. CONSIDERACIONES 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 o Sockets son:
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.