Capitulo 20 Visual Basic

  • Published on
    07-Jun-2015

  • View
    3.737

  • Download
    2

Embed Size (px)

DESCRIPTION

Manual Visual Basic 6, el presente es un capitulo de un manual o tutorial de Visual Basic 6.0

Transcript

Visual Basic - Gua del Estudiante Cap. 20APLICACIONES CLIENTE SERVIDOR COMUNICACIN PUERTO SERIE: EL CONTROL MSCOMM(Captulo inacabado. Algn estudiante quiere colaborar a su terminacin?) Hasta ahora hemos visto aplicaciones que pueden utilizarse por s solas. Pueden acceder a bases de datos que estn en el mismo ordenador que la aplicacin o en otro, unido mediante una red de rea local. La conexin a las bases de datos a las que accede se realiza, bien indicndole la direccin y carpeta (\\MiServidor\BasesdeDatos\MiBase.Mdb) o bien mapeando esa direccin (crear una unidad de disco que contienen esa direccin). De esta forma podemos acceder a una base de datos instalada en un equipo remoto y la aplicacin debe funcionar perfectamente, aunque al abrir o leer la base de datos origine un trfico elevado por la red de rea local. Con esta configuracin podemos tener problemas de lentitud, sobre todo si la red es lenta y si hay muchos usuarios trabajando con esa aplicacin en distintos ordenadores, accediendo todos ellos a travs de la red a un servidor que contienen la base de datos. Esta lentitud se incrementara en una gran escala si la red a utilizar fuese Internet mediante una conexin lenta. Pero lo que ms se notara sera la ocupacin de los recursos de la red durante las consultas a esa base de datos. Dependiendo de cmo se crease el recordset, podra darse el caso de transmitir por la red todos los datos de la base de datos para que nuestra aplicacin utilice nicamente los datos correspondientes a un registro. Pensando en una aplicacin bancaria, por ejemplo la peticin de saldo de una cuenta desde un cajero automtico, los nicos datos relevantes de esa operacin sern el nmero de cuenta corriente, un cdigo para indicar que lo que se desea es el saldo, y como datos de retorno, el nmero de esa cuenta, el saldo actual disponible y quizs un nmero de comprobacin (Checksum) para comprobar que no ha existido error en la comunicacin. De nada nos servira en el cajero conocer el estado de cantidades retenidas, operaciones pendientes, etc. Si en ese ejemplo del cajero cresemos un objeto Database, un recordset, leysemos todos los datos del recordset y luego disemos la orden de cerrarlo, estaramos enviando informacin innecesaria a travs de la red, con el coste de tiempo y ocupacin que ello representa. Casi llegamos a demostrar con esta introduccin que sera ms conveniente hacer una aplicacin que tuviese dos partes: una, residente en el puesto de operacin, (que llamaremos aplicacin cliente) que fuese capaz de enviar datos solicitando informacin a otra aplicacin, instalada en el servidor donde est la base de datos. Esta segunda aplicacin, que llamaremos aplicacin servidor, abrir la base, crear los recordsets necesarios, filtrar la informacin, realizar con ella operaciones matemticas, y una vez concluido todo el proceso, enviar a la aplicacin cliente los datos estrictamente necesarios. Obviamente se necesita que ambas aplicaciones sean capaces de entenderse entre s, es decir, que tengan un protocolo de comunicacin entre ellas previamente definido. Esto es lo que se denomina una aplicacin cliente servidor. La aplicacin cliente servidor ms popular es el navegador de Internet. Esta aplicacin est formada por una aplicacin cliente (Navegador IEXplore, NetScape, etc) y una aplicacin servidor (Internet Information Server IIS, Apache, etc). El protocolo para que se comuniquen entre ellas es el protocolo Http o el Ftp. Estos protocolos al ser pblicos, permiten a cualquier empresa hacer su propia aplicacin cliente o servidor. No es nuestro deseo llegar a tanto. El navegador de Internet es una aplicacin clienteservidor que sobrepasa cualquier proyecto que podamos imaginar para realizarlo por medio de programacin en VB. Cualquier navegador de Internet comercial lleva asociadas una serie de funciones, muchas de ellas transparentes para el usuario, que sera imposible crear una aplicacin de este calibre, sobre todo como ejemplo de un curso de VB. Pensemos en una

LSB

Visual Basic Gua del Estudiante

Cap. 20

Pg. 1

aplicacin ms sencilla, que nos permita conocer como funcionan las aplicaciones cliente servidor, y sirva adems para algo til. Esa aplicacin no puede ser otra que una gua telefnica, (versin novsima del Listatel) cuya base de datos est en un servidor conectado a Internet, al que se podr acceder desde un nmero ilimitado de puestos cliente. En la base de datos del servidor, en un conjunto de tablas, figurarn los nombres, nmeros de telfono, despacho, etc. de una serie de personas, y el organigrama de esas personas dentro de la organizacin. Estas tablas sern estticas, es decir, tendrn datos que solamente se actualizarn cuando exista un cambio en esas personas, pero no variarn durante la ejecucin del programa. En otra tabla, esta dinmica, tendremos el registro de los usuarios que estn conectados en ese momento al servicio. As podremos saber si un usuario est presente y de esta forma conocer un dato importante para otro servicio que va a tener este programa: su direccin IP actual. Sabiendo que est conectado y con su direccin IP podremos enviarle mensajes directamente. Creo que ya vemos que se trata de una agenda telefnica que lleva incorporado un servicio de mensajera. El servicio de mensajera enviar mensajes con texto plano o RTF y puede llevar ficheros anexados. A esta agenda, y a su protocolo de comunicacin le vamos a denominar SML. No se preocupe de no conocer las siglas. Al protocolo SMTP tampoco lo conocan en el momento de su creacin. Una aplicacin cliente puede comportarse como aplicacin servidor de otra aplicacin, incluso de s misma. Este es el caso de la aplicacin cliente del SML. Cuando vamos a pedir la informacin de un abonado telefnico al servidor, el cliente se comporta como tal. Sin embargo cuando otro usuario de SML nos enva un mensaje, es nuestra aplicacin la que realiza las funciones de servidor. Ver esto con mucha ms claridad cuando comencemos el ejemplo. Toda aplicacin cliente - servidor debe tener un sistema de comunicacin entre la aplicacin cliente y la aplicacin servidor. Parece que la comunicacin que ha de tener es a travs de una red IP (Red de Area Local, Red Privada Virtual, Internet) pero puede ser cualquier otro sistema de comunicacin entre ordenadores. Sin ir ms lejos, a travs del puerto de comunicacin serie COM-1 COM-2. A efectos de los programas de la aplicacin cliente o servidor solamente variar en la forma en la que reciban y transmitan los datos. En nuestro ejemplo vamos a utilizar la comunicacin a travs de una red IP, usando el control Winsock ya estudiado. Tanto la aplicacin cliente como la aplicacin servidor debern tener un Winsock. Como en nuestro caso, segn explicamos ms atrs, la aplicacin cliente se convierte en aplicacin servidor para recibir mensajes, sta deber tener dos Winsocks, uno para la funcin cliente, y otro para la funcin servidor. Cuando se disea una aplicacin cliente servidor hay que comenzar pensando en las funciones que va a realizar y sobre esas funciones comenzar a escribir el protocolo de comunicacin. No es fcil tener terminado el protocolo de comunicacin antes de escribir la primera lnea de cdigo del programa. Segn se van concretando cada una de las acciones que debe realizar vemos que es necesario introducir nuevos cdigos de operacin en nuestro protocolo. No se preocupe que eso no es improvisar. Pero s es muy importante tener las cosas claras desde el principio y saber que es lo que va a hacer nuestra aplicacin para de esta forma poder saber dar respuesta correcta a cada uno de los dos programas. Y para tener las cosas claras, el autor recomienda que el protocolo de comunicacin se establezca antes de comenzar a escribir el cdigo en tanto se pueda. Y que se escriba en un documento en el propio ordenador o mejor an, en una base de datos u hoja de clculo, que nos permita ordenar las rdenes y avisos de nuestra aplicacin para evitar de esta forma cualquier repeticin involuntaria. Es muy importante a la hora de pensar el protocolo de comunicacin que este no pueda inducir a error al programa. Si el programa tiene como funcin la transmisin de mensajes (Tal como es nuestro caso) los mensajes no pueden estar limitados ni en su longitud ni en su contenido por el formato del protocolo de comunicaciones. Se entiende mejor esto analizando el protocolo del SML (fruto nicamente de la imaginacin del autor y no sujeto a normas ni recomendaciones internacionales de ningn tipo)

LSB

Visual Basic Gua del Estudiante

Cap. 20

Pg. 2

Protocolo de comunicacin de la aplicacin SML. (Vea el ANEXO 1 Protocolo de comunicacin SML) La comunicacin entre ambas aplicaciones se establece mediante palabras en ASCI que indican una operacin. A estas palabras las denominamos Acrnimos. Las operaciones pueden ser rdenes o avisos. Son rdenes aquellas comunicaciones del cliente que desencadenan una operacin en el servidor. Son avisos aquellas respuestas del servidor para enviarle datos o comunicar algo al cliente. Cada orden o aviso, puede llevar uno o varios parmetros. Los parmetros contienen la informacin necesaria para que la operacin que se va a realizar por esa orden o aviso pueda llevarse a cabo. En esta aplicacin SML los acrnimos todos son de 3 caracteres, utilizando los signos < > como delimitadores del acrnimo. Si el acrnimo lleva parmetros, la separacin entre los tres caracteres y el parmetro o parmetros es la barra / Volvamos a lo comentado anteriormente respecto a la limitacin del contenido de un mensaje. Si el mensaje contiene un carcter / puede que el programa se confunda y piense que ese carcter forma parte de un acrnimo. Para evitar cualquier confusin, si uno de estos caracteres forma parte de un texto, se le antepondr el signo &. De esta forma la recepcin de la pareja de caracteres & &/ significa que no son parte de un acrnimo sino texto. Observe ahora que ese mismo problema lo vamos a tener con el carcter &. Si queremos enviar