El primer proyecto en que se aplicó este
lenguaje recibió el nombre de proyecto Green y
consistía en un sistema de
control completo
de los aparatos electrónicos y el entorno de un hogar.
Para ello se construyó un ordenador experimental
denominado *7 (Star Seven). El sistema presentaba una interfaz
basada en la representación de la casa de forma animada y
el control se llevaba a cabo mediante una pantalla sensible al
tacto. En el sistema aparecía Duke, la actual mascota de
Java.
Posteriormente se aplicó a otro proyecto
denominado VOD (Video On Demand)
en el que se empleaba como interfaz para la
televisión interactiva. Ninguno de estos proyectos se
convirtió nunca en un sistema comercial, pero fueron
desarrollados enteramente en un Java primitivo y fueron como su
bautismo de fuego.
Una vez que en Sun se dieron cuenta de que a corto
plazo la televisión interactiva no iba a ser un gran
éxito,
urgieron a FirstPerson a desarrollar con rapidez nuevas estrategias que
produjeran beneficios. No lo consiguieron y FirstPerson
cerró en la primavera de 1994.
Pese a lo que parecía ya un olvido
definitivo, Bill Joy, cofundador de Sun y uno de los
desarrolladores principales del Unix de Berkeley,
juzgó que Internet podría llegar a ser el campo de
juego adecuado
para disputar a Microsoft su
primacía casi absoluta en el terreno del software, y vio
en Oak el instrumento idóneo para llevar a cabo estos
planes. Tras un cambio de
nombre y modificaciones de diseño,
el lenguaje Java fue presentado en sociedad en
agosto de 1995.
Lo mejor será hacer caso omiso de las
historias que pretenden dar carta de naturaleza a la
clarividencia industrial de sus protagonistas; porque la
cuestión es si independientemente de su origen y entorno
comercial, Java ofrece soluciones a
nuestras expectativas. Porque tampoco vamos a desechar la
penicilina aunque haya sido su origen fruto de la
casualidad.
CARACTERÍSTICAS DE JAVA
Las características principales que nos ofrece
Java respecto a cualquier otro lenguaje de programación, son:
Simple
Java ofrece toda la funcionalidad de un lenguaje
potente, pero sin las características menos usadas y
más confusas de éstos. C++ es un lenguaje que
adolece de falta de seguridad, pero C y C++ son lenguajes
más difundidos, por ello Java se diseñó para
ser parecido a C++ y así facilitar un rápido y
fácil aprendizaje.
Java elimina muchas de las características de
otros lenguajes como C++, para mantener reducidas las
especificaciones del lenguaje y añadir
características muy útiles como el garbage
collector (reciclador de memoria dinámica). No es necesario preocuparse de
liberar memoria, el reciclador se encarga de ello y como es un
thread de baja prioridad, cuando entra en acción, permite
liberar bloques de memoria muy grandes, lo que reduce la
fragmentación de la
memoria.
Java reduce en un 50% los errores más
comunes de programación con lenguajes como C y C++ al
eliminar muchas de las características de éstos,
entre las que destacan:
- aritmética de punteros
- no existen referencias
- registros (struct)
- definición de tipos (typedef)
- macros (#define)
- necesidad de liberar memoria (free)
Aunque, en realidad, lo que hace es eliminar las
palabras reservadas (struct, typedef), ya que las clases son algo
parecido. Además, el intérprete completo de
Java que hay en este momento es muy pequeño, solamente
ocupa 215 Kb de RAM.
Orientado a objetos
Java implementa la tecnología
básica de C++ con algunas mejoras y elimina algunas cosas
para mantener el objetivo de la
simplicidad del lenguaje. Java trabaja con sus datos como
objetos y con interfaces a esos objetos. Soporta las tres
características propias del paradigma de
la orientación a objetos: encapsulación, herencia y
polimorfismo. Las plantillas de objetos son llamadas, como en
C++, clases y sus copias, instancias. Estas instancias, como en
C++, necesitan ser construidas y destruidas en espacios de
memoria.
Java incorpora funcionalidades inexistentes en C++
como por ejemplo, la resolución dinámica de
métodos. Esta característica deriva
del lenguaje Objective C, propietario del sistema operativo
Next. En C++ se suele trabajar con librerías
dinámicas (DLLs) que obligan a recompilar la
aplicación cuando se retocan las funciones que se
encuentran en su interior.
Este inconveniente es resuelto por Java mediante una
interfaz específica llamada RTTI (RunTime Type
Identification) que define la interacción entre objetos
excluyendo variables de
instancias o implementación de métodos. Las clases
en Java tienen una representación en el runtime que
permite a los programadores interrogar por el tipo de clase y
enlazar dinámicamente la clase con el resultado de la
búsqueda.
Distribuido
Java se ha construido con extensas capacidades de
interconexión TCP/IP. Existen
librerías de rutinas para acceder e interactuar con
protocolos como
http y
ftp. Esto
permite a los programadores acceder a la información a
través de la red con tanta facilidad como a los ficheros
locales. La verdad es que Java en sí no es
distribuido, sino que proporciona las librerías y herramientas
para que los programas puedan ser distribuidos, es decir, que se
corran en varias máquinas, interactuando.
Robusto
Java realiza verificaciones en busca de problemas tanto
en tiempo de compilación como en tiempo de
ejecución. La comprobación de tipos en Java ayuda a
detectar errores, lo antes posible, en el ciclo de desarrollo.
Java obliga a la declaración explícita de
métodos, reduciendo así las posibilidades de
error.
Maneja la memoria para eliminar las preocupaciones por
parte del programador de la liberación o corrupción
de memoria. También implementa los arrays
auténticos, en vez de listas enlazadas de punteros, con
comprobación de límites,
para evitar la posibilidad de sobrescribir o corromper memoria
resultado de punteros que señalan a zonas equivocadas.
Estas características reducen drásticamente el
tiempo de desarrollo de aplicaciones en Java.
Además, para asegurar el funcionamiento de la
aplicación, realiza una verificación de los
byte-codes, que son el resultado de la compilación de un
programa Java.
Es un código de máquina virtual que es interpretado
por el intérprete Java. No es el código
máquina directamente entendible por el hardware, pero ya ha pasado
todas las fases del compilador: análisis de instrucciones, orden de
operadores, etc., y ya tiene generada la pila de ejecución
de órdenes.
Java proporciona, pues:
- Comprobación de punteros
- Comprobación de límites de
arrays - Excepciones
- Verificación de byte-codes
Arquitectura neutral
Para establecer Java como parte integral de la red, el
compilador Java compila su código a un fichero objeto de
formato independiente de la arquitectura de la máquina en
que se ejecutará. Cualquier máquina que tenga el
sistema de ejecución (run-time) puede ejecutar ese
código objeto, sin importar en modo alguno la
máquina en que ha sido generado. Actualmente existen
sistemas run-time para Solaris 2.x, SunOs 4.1.x, Windows 95,
Windows NT,
Linux, Irix,
Aix, Mac, Apple y probablemente haya grupos de
desarrollo trabajando en el porting a otras plataformas. Ver
figura 1.
Para ver el gráfico seleccione la
opción "Descargar" del menú superior
El código fuente Java se "compila" a un
código de bytes de alto nivel independiente de la
máquina. Este código (byte-codes) está
diseñado para ejecutarse en una máquina
hipotética que es implementada por un sistema run-time,
que sí es dependiente de la máquina. En una
representación en que tuviésemos que indicar todos
los elementos que forman parte de la arquitectura de Java sobre
una plataforma genérica, obtendríamos una figura
como la siguiente (figura 2):
Para ver el gráfico seleccione la
opción "Descargar" del menú superior
En ella podemos ver que lo verdaderamente dependiente
del sistema es la Máquina Virtual Java (JVM) y las
librerías fundamentales, que también nos
permitirían acceder directamente al hardware de la
máquina. Además, habrá APIs de Java que
también entren en contacto directo con el hardware y
serán dependientes de la máquina, como ejemplo de
este tipo de APIs podemos citar:
- Java 2D: gráficos 2D y manipulación de
imágenes - Java Media Framework : Elementos críticos en
el tiempo: audio, video… - Java Animation: Animación de objetos en
2D - Java Telephony: Integración con telefonía
- Java Share: Interacción entre aplicaciones
multiusuario - Java 3D: Gráficos 3D y su
manipulación
Seguro
La seguridad en Java tiene dos facetas. En el lenguaje,
características como los punteros o el casting
implícito que hacen los compiladores de C
y C++ se eliminan para prevenir el acceso ilegal a la memoria.
Cuando se usa Java para crear un navegador, se combinan las
características del lenguaje con protecciones de sentido
común aplicadas al propio navegador. El lenguaje C,
por ejemplo, tiene lagunas de seguridad importantes, como son los
errores de alineación. Los programadores de C utilizan
punteros en conjunción con operaciones
aritméticas. Esto le permite al programador que un puntero
referencie a un lugar conocido de la memoria y pueda sumar (o
restar) algún valor, para
referirse a otro lugar de la memoria. Si otros programadores
conocen nuestras estructuras de
datos pueden extraer información confidencial de nuestro
sistema. Con un lenguaje como C, se pueden tomar números
enteros aleatorios y convertirlos en punteros para luego acceder
a la memoria:
printf( "Escribe un valor entero: " );
scanf( "%u",&puntero );
printf( "Cadena de memoria: %sn",puntero
);
Otra laguna de seguridad u otro tipo de ataque, es
el Caballo de Troya. Se presenta un programa como una utilidad,
resultando tener una funcionalidad destructiva. Por ejemplo, en
UNIX se visualiza el contenido de un directorio con el comando
ls. Si un programador deja un comando destructivo bajo esta
referencia, se puede correr el riesgo de
ejecutar código malicioso, aunque el comando siga haciendo
la funcionalidad que se le supone, después de lanzar su
carga destructiva.
Por ejemplo, después de que el caballo de Troya
haya enviado por correo el /etc/shadow a su creador, ejecuta la
funcionalidad de ls presentando el contenido del directorio. Se
notará un retardo, pero nada inusual. El código
Java pasa muchos tests antes de ejecutarse en una máquina.
El código se pasa a través de un verificador de
byte-codes que comprueba el formato de los fragmentos de
código y aplica un probador de teoremas para detectar
fragmentos de código ilegal -código que falsea
punteros, viola derechos de acceso sobre
objetos o intenta cambiar el tipo o clase de un
objeto-.
Si los byte-codes pasan la verificación sin
generar ningún mensaje de error, entonces sabemos
que:
El código no produce desbordamiento de operandos
en la pila
El tipo de los parámetros de todos los
códigos de operación son conocidos y
correctos.
No ha ocurrido ninguna conversión ilegal de
datos, tal como convertir enteros en punteros.
El acceso a los campos de un objeto se sabe que es
legal: public, private, protected.
No hay ningún intento de violar las reglas de
acceso y seguridad establecidas
El Cargador de Clases también ayuda a Java
a mantener su seguridad, separando el espacio de nombres del
sistema de ficheros local, del de los recursos
procedentes de la red. Esto limita cualquier aplicación
del tipo Caballo de Troya, ya que las clases se buscan primero
entre las locales y luego entre las procedentes del
exterior.
Las clases importadas de la red se almacenan en un
espacio de nombres privado, asociado con el origen. Cuando una
clase del espacio de nombres privado accede a otra clase, primero
se busca en las clases predefinidas (del sistema local) y luego
en el espacio de nombres de la clase que hace la referencia. Esto
imposibilita que una clase suplante a una predefinida.
En resumen, las aplicaciones de Java resultan
extremadamente seguras, ya que no acceden a zonas delicadas de
memoria o de sistema, con lo cual evitan la interacción de
ciertos virus. Java no
posee una semántica específica para modificar la
pila de programa, la memoria libre o utilizar objetos y
métodos de un programa sin los privilegios del kernel del
sistema operativo. Además, para evitar modificaciones por
parte de los crackers de la red, implementa un método
ultraseguro de autentificación por clave pública.
El Cargador de Clases puede verificar una firma digital antes de
realizar una instancia de un objeto. Por tanto, ningún
objeto se crea y almacena en memoria, sin que se validen los
privilegios de acceso. Es decir, la seguridad se integra en el
momento de compilación, con el nivel de detalle y de
privilegio que sea necesario.
Dada, pues la concepción del lenguaje y si
todos los elementos se mantienen dentro del estándar
marcado por Sun, no hay peligro. Java imposibilita,
también, abrir ningún fichero de la máquina
local (siempre que se realizan operaciones con archivos,
éstas trabajan sobre el disco duro de
la máquina de donde partió el applet), no permite
ejecutar ninguna aplicación nativa de una plataforma e
impide que se utilicen otros ordenadores como puente, es decir,
nadie puede utilizar nuestra máquina para hacer peticiones
o realizar operaciones con otra. Además, los
intérpretes que incorporan los navegadores de
la Web son
aún más restrictivos. Bajo estas condiciones (y
dentro de la filosofía de que el único ordenador
seguro es el que está apagado, desenchufado, dentro de una
cámara acorazada en un bunker y rodeado por mil soldados
de los cuerpos especiales del ejército), se puede
considerar que Java es un lenguaje seguro y que los applets
están libres de virus. Respecto a la seguridad del
código fuente, no ya del lenguaje, JDK proporciona un
desemsamblador de byte-code, que permite que cualquier programa
pueda ser convertido a código fuente, lo que para el
programador significa una vulnerabilidad total a su
código.
Utilizando javap no se obtiene el código fuente
original, pero sí desmonta el programa mostrando el
algoritmo que
se utiliza, que es lo realmente interesante. La protección
de los programadores ante esto es utilizar llamadas a programas
nativos, externos (incluso en C o C++) de forma que no sea
descompilable todo el código; aunque así se pierda
portabilidad. Esta es otra de las cuestiones que Java tiene
pendientes.
Portable
Más allá de la portabilidad básica
por ser de arquitectura independiente, Java implementa otros
estándares de portabilidad para facilitar el desarrollo.
Los enteros son siempre enteros y además, enteros de 32
bits en complemento a 2. Además, Java construye sus
interfaces de usuario a través de un sistema abstracto de
ventanas de forma que las ventanas puedan ser implantadas en
entornos Unix, Pc o Mac.
Interpretado
El intérprete Java (sistema run-time) puede
ejecutar directamente el código objeto. Enlazar (linkar)
un programa, normalmente, consume menos recursos que compilarlo,
por lo que los desarrolladores con Java pasarán más
tiempo desarrollando y menos esperando por el ordenador. No
obstante, el compilador actual del JDK es bastante lento. Por
ahora, que todavía no hay compiladores específicos
de Java para las diversas plataformas,
Se dice que Java es de 10 a 30 veces más
lento que C, y que tampoco existen en Java proyectos de gran
envergadura como en otros lenguajes. La verdad es que ya hay
comparaciones ventajosas entre Java y el resto de los lenguajes
de programación, y una ingente cantidad de folletos
electrónicos que supuran fanatismo en favor y en contra de
los distintos lenguajes contendientes con Java.
Lo que se suele dejar de lado en todo esto, es que
primero habría que decidir hasta que punto Java, un
lenguaje en pleno desarrollo y todavía sin
definición definitiva, está maduro como lenguaje de
programación para ser comparado con otros; como por
ejemplo con Smalltalk, que lleva más de 20 años en
el mercado.
La verdad es que Java para conseguir ser un
lenguaje independiente del sistema operativo y del procesador que
incorpore la máquina utilizada, es tanto interpretado como
compilado. Y esto no es ningún contrasentido, me explico,
el código fuente escrito con cualquier editor se compila
generando el byte-code. Este código intermedio es de muy
bajo nivel, pero sin alcanzar las instrucciones máquina
propias de cada plataforma y no tiene nada que ver con el p-code
de Visual Basic. El
byte-code corresponde al 80% de las instrucciones de la
aplicación. Ese mismo código es el que se puede
ejecutar sobre cualquier plataforma. Para ello hace falta el
run-time, que sí es completamente dependiente de la
máquina y del sistema operativo, que interpreta
dinámicamente el byte-code y añade el 20% de
instrucciones que faltaban para su ejecución. Con este
sistema es fácil crear aplicaciones multiplataforma, pero
para ejecutarlas es necesario que exista el run-time
correspondiente al sistema operativo utilizado.
Multithreaded
Al ser multithreaded (multihilvanado, en mala
traducción), Java permite muchas actividades
simultáneas en un programa. Los threads (a veces llamados,
procesos
ligeros), son básicamente pequeños procesos o
piezas independientes de un gran proceso. Al
estar los threads contruidos en el lenguaje, son más
fáciles de usar y más robustos que sus
homólogos en C o C++.
El beneficio de ser miltithreaded consiste en un
mejor rendimiento interactivo y mejor comportamiento
en tiempo real. Aunque el comportamiento en tiempo real
está limitado a las capacidades del sistema operativo
subyacente (Unix, Windows,
etc.), aún supera a los entornos de flujo único de
programa (single-threaded) tanto en facilidad de desarrollo como
en rendimiento. Cualquiera que haya utilizado la
tecnología de navegación concurrente, sabe lo
frustrante que puede ser esperar por una gran imagen que se
está trayendo. En Java, las imágenes se pueden ir
trayendo en un thread independiente, permitiendo que el usuario
pueda acceder a la información en la página sin
tener que esperar por el navegador.
Dinamico
Java se beneficia todo lo posible de la
tecnología orientada a objetos. Java no intenta conectar
todos los módulos que comprenden una aplicación
hasta el tiempo de ejecución. Las librería nuevas o
actualizadas no paralizarán las aplicaciones actuales
(siempre que mantengan el API anterior). Ver figura 3.
Para ver el gráfico seleccione la
opción "Descargar" del menú superior
Java también simplifica el uso de protocolos
nuevos o actualizados. Si su sistema ejecuta una
aplicación Java sobre la red y encuentra una pieza de la
aplicación que no sabe manejar, tal como se ha explicado
en párrafos anteriores, Java es capaz de traer
automáticamente cualquiera de esas piezas que el sistema
necesita para funcionar. Java, para evitar que los módulos
de byte-codes o los objetos o nuevas clases, haya que estar
trayéndolos de la red cada vez que se necesiten,
implementa las opciones de persistencia, para que no se eliminen
cuando de limpie la caché de la máquina.
¿Cuál es la ventaja de todo
esto?¿Qué gano con Java?
- Primero: No volverá a escribir el
código si quieres ejecutar el programa en otra
máquina. Un solo código funciona para todos los
browsers compatibles con Java o donde se tenga una
Máquina Virtual de Java (Mac's, PC's, Sun's,
etc). - Segundo: Java es un lenguaje de programación
orientado a objetos, y tiene todos los beneficios que ofrece
esta metodología de programación
(más adelante se da una pequeña
introducción a la filosofía de
objetos). - Tercero: Un browser compatible con Java deberá
ejecutar cualquier programa hecho en Java, esto ahorra a los
usuarios tener que estar insertando "plug-ins" y demás
programas que a veces nos quitan tiempo y espacio en
disco. - Cuarto: Java es un lenguaje y por lo tanto puede
hacer todas las cosas que puede hacer un lenguaje de
programación: Cálculos matemáticos,
procesadores de
palabras, bases de datos,
aplicaciones gráficas, animaciones, sonido,
hojas de
cálculo, etc. - Quinto: Si lo que interesa son las páginas de
Web, ya no tienen que ser estáticas, se le pueden poner
toda clase de elementos multimedia y
permiten un alto nivel de interactividad, sin tener que gastar
en paquetes carísimos de multimedia.
Pero también se tienen algunas
limitantes:
- La velocidad.
Los programas hechos en Java no tienden a ser muy
rápidos, supuestamente se está trabajando en
mejorar esto. Como los programas de Java son interpretados
nunca alcanzan la velocidad de un verdadero
ejecutable. - Java es un lenguaje de programación. Esta es
otra gran limitante, por más que digan que es orientado
a objetos y que es muy fácil de aprender sigue siendo un
lenguaje y por lo tanto aprenderlo no es cosa fácil.
Especialmente para los no programadores. - Java es nuevo. En pocas palabras todavía no se
conocen bien todas sus capacidades.
Pero en general Java posee muchas ventajas y se
pueden hacer cosas muy interesantes con esto. Hay que prestar
especial atención a lo que está sucediendo en
el mundo de la computación, a pesar de que Java es
relativamente nuevo, posee mucha fuerza y es
tema de moda en
cualquier medio computacional. Muchas personas apuestan a futuro
y piensan en Java.
Programación Orientada a Objetos
(POO)
Junto con el paradigma de la orientación a
procedimientos, son las dos filosofías
generales de diseño más importantes. A diferencia
de la orientación a procedimientos (OP), la
orientación a objetos (OO) no concibe los procesos como
una secuencia de procedimientos con su entrada y salida sino que
se basa en un conjunto de objetos interactuando. Ver figura
4.
Para ver el gráfico seleccione la
opción "Descargar" del menú superior
Veamos a continuación los aspectos más
destacados de esta filosofía general de
diseño.
1. Clases y objetos
Es importante distinguir entre los conceptos de clase y
objeto:
Clase: Es un modelo
abstracto de un tipo de objeto. Define sus métodos y
atributos.
Objeto: Es una instancia de una clase, es
decir, la implementación con valores de un
modelo abstracto. Para ver el
gráfico seleccione la opción "Descargar"
Las clases no son entidades independientes sino que se
agrupan jerárquicamente heredando características y
atributos. Cada instancia o implementación real de una
clase constituirá un nuevo objeto por lo que se pueden
crear infinitos objetos distintos a partir de una sola
clase.
2. Encapsulación
Se define como el proceso de empaquetar juntos los
métodos y los datos en un objeto. El objeto se encarga de
ocultar sus datos al resto de objetos. La encapsulación
permite una seguridad mayor en el acceso a los datos ya que este
acceso depende directamente de cada objeto. Asimismo, permite
abstraer los detalles internos de funcionamiento del
objeto.
3. Intercambio de mensajes
Los objetos se comunican entre sí mediante
mensajes de invocación a métodos, figura
5:
Para ver el gráfico seleccione
la opción "Descargar" del menú
superior
4. Herencia
Es el concepto que
define la adopción
de todas las características de una clase por parte de
otra clase que es definida como descendiente o heredera de la
primera. Ver figura 6.
Para ver el gráfico seleccione la
opción "Descargar"
La principal consecuencia de la herencia es la
posibilidad de reutilizar clases ya que se pueden crear nuevas a
partir de las ya creadas.
La herencia puede ser de dos tipos, simple si
sólo es posible heredar características de una sola
clase, o múltiple si se pueden heredar
características de varias clases.
5. Polimorfismo
Genéricamente, el polimorfismo es la capacidad de
tomar varias formas.
Aplicado a los lenguajes de programación, debemos
considerar dos tipos de polimorfismo: polimorfismo funcional y
polimorfismo de datos.
Polimorfismo funcional o sobrecarga.
El polimorfismo funcional es la posibilidad de
referenciar, mediante el mismo identificador, diferentes
funciones. La mayoría de los lenguajes de
programación presentan sobrecarga de operadores. En
algunos, también las funciones de entrada/salida
están sobrecargadas, pero sólo unos pocos admiten
el polimorfismo en funciones definidas por el
programador.
En los Lenguajes Orientados a Objetos, las operaciones
se aplican siempre a un objeto. El método que se ejecuta
viene determinado por la clase a la que pertenece el objeto que
recibe el mensaje. Por este motivo no hay limitaciones a la
sobrecarga de funciones definidas en clases distintas. En
Smalltalk, dado que no se realiza comprobación de tipos,
ésta es la única posibilidad de sobrecarga, puesto
que no es posible distinguir dos métodos en base a las
clases de los argumentos. Así:
p distancia: q
hace referencia a métodos distintos dependiendo
de si p es un Punto o un Segmento, pero el método
que se ejecuta no depende de la clase a la que pertenece
q. En Java, sí se permite la sobrecarga dentro de
una clase. Ej. Los constructores de una clase. Sin embargo, dado
que Java hace en ocasiones conversiones de tipos
implícitas, ciertas sobrecargas no están
permitidas:
class Sobrecargada {
int valor;
void setValor ( int v ) { valor = v; }
void setValor (float v) { valor = v; } //
Error
int getValor ( ) { return valor; }
float getValor ( ) { return ( float ) valor; } //
Error
Polimorfismo de datos.
El polimorfismo de datos es la capacidad de un
identificador para hacer referencia a instancias de distintas
clases. El polimorfismo de datos es una característica de
los lenguajes orientados a objetos.
El polimorfismo de datos aumenta las posibilidades de
reutilización de código, favoreciendo la construcción de módulos como
extensión de otros ya existentes. En los lenguajes con
polimorfismo de datos es necesario distinguir entre:
tipo estático: tipo con el que se declara
una referencia o variable.
tipo dinámico: tipo de objeto asociado a
una referencia en un momento dado.
En muchos lenguajes, el polimorfismo de datos
ésta limitado por las relaciones de herencia: el tipo
dinámico ha de ser un descendiente del tipo
estático. Las razones son dos:
Cualquier instancia de una clase es instancia de las
clases antecesoras.
p : Punto;
r : Particula;
p :=r;
Cualquier instancia de una clase posee los atributos
declarados por las clases antecesoras y entiende los
métodos definidos por ellas.
x := p.abscisa;
p.distancia(r);
1.4 FUTURO DE JAVA
Existen muchas críticas a Java debido a su lenta
velocidad de ejecución, aproximadamente unas 20 veces
más lento que un programa en lenguaje C. Sun
está trabajando intensamente en crear versiones de Java
con una velocidad mayor.
El problema fundamental de Java es que utiliza bytecodes
para solventar los problemas de portabilidad, que posteriormente
en cada máquina se tendrán que transformar en
código máquina, lo que a lenta considerablemente el
proceso de ejecución.
La solución que se deriva de esto parece bastante
obvio: fabricar ordenadores capaces de comprender directamente
los bytecodes, sería una máquina que utilizara Java
como sistema operativo y que no requeriría en principio de
disco duro porque regiría sus recursos de la
red4.
La primera gran empresa que se ha
dado cuenta de todo esto y ha apostado en esto ha sido Oracle, que en
enero de 1996 presentó en Japón
su primer NC (Network Computer), basado en un procesador RISC con
8 Mbytes de RAM. Tras Oracle, han sido compañías
del tamaño de Sun, Apple e IBM las que han anunciado
desarrollos similares.
Por ahora, toda esta tecnología está
comenzando a desarrollarse, aunque en la actualidad los anchos de
banda y el costo de las conexiones no favorecen demasiado estos
ordenadores. No obstante todos estos problemas
desaparecerán a corto plazo, y la actitud de Sun
de mantener un sistema transparente y accesible a cualquier
programador parece que van a ser determinantes en la comercialización de este tipo de
sistemas.
La principal empresa en el mundo del software,
Microsoft, que en los comienzos de Java no estaba a favor de su
utilización, ha licenciado Java, lo ha incluido en
Internet
Explorer 3.0 y posteriores, y ha lanzado un entorno de
desarrollo para Java, que se denomina Visual J++.
El único problema aparente es la seguridad para
que Java se pueda utilizar para transacciones críticas.
Sun va a apostar por firmas digitales, que será clave en
el desarrollo no sólo de Java, sino de toda
Internet.
CAPITULO II COMUNICACIÓN EN
JAVA
2.1 MODELO DE COMUNICACIONES
CON JAVA
En Java, crear una conexión socket TCP/IP se
realiza directamente con el paquete java.net. A
continuación mostramos un diagrama de lo
que ocurre en el lado del cliente y del servidor (figura
7):
Para ver el gráfico seleccione la
opción "Descargar" del menú superior
El modelo de sockets más simple es:
El servidor establece un puerto y espera durante un
cierto tiempo (timeout segundos), a que el cliente establezca la
conexión. Cuando el cliente solicite una conexión,
el servidor abrirá la conexión socket con el
método accept().
El cliente establece una conexión con la
máquina host a través del puerto que se designe en
puerto# .
El cliente y el servidor se comunican con manejadores
InputStream y OutputStream.
Hay una cuestión al respecto de los sockets, que
viene impuesta por la implementación del sistema de
seguridad de Java. Actualmente, los applets sólo pueden
establecer conexiones con el nodo desde el cual se
transfirió su código.
Esto está implementado en el JDK y en el
intérprete de Java de Netscape. Esto reduce en gran manera
la flexibilidad de las fuentes de
datos disponibles para los applets. El problema si se permite que
un applet se conecte a cualquier máquina de la red, es que
entonces se podrían utilizar los applets para inundar la
red desde un ordenador con un cliente Netscape del que no se
sospecha y sin ninguna posibilidad de rastreo.
2.2 CLASES ÚTILES EN
COMUNICACIONES
Vamos a exponer otras clases que resultan útiles
cuando estamos desarrollando programas de comunicaciones, aparte
de las que ya se han visto. El problema es que la mayoría
de estas clases se prestan a discusión, porque se
encuentran bajo el directorio sun. Esto quiere decir que son
implementaciones Solaris y, por tanto, específicas del
Unix Solaris. Además su API no está garantizada,
pudiendo cambiar. Pero, a pesar de todo, resultan muy
interesantes y vamos a comentar un grupo de ellas
solamente que se encuentran en el paquete sun.net.
Socket
Es el objeto básico en toda comunicación a
través de Internet, bajo el protocolo TCP.
Esta clase proporciona métodos para la entrada/salida a
través de streams que hacen la lectura y
escritura a
través de sockets muy sencilla.
ServerSocket
Es un objeto utilizado en las aplicaciones servidor para
escuchar las peticiones que realicen los clientes
conectados a ese servidor. Este objeto no realiza el servicio, sino
que crea un objeto Socket en función
del cliente para realizar toda la comunicación a
través de él.
DatagramSocket
La clase de sockets datagrama puede ser utilizada para
implementar datagramas o fiables (sockets UDP), no ordenados.
Aunque la comunicación por estos sockets es muy
rápida porque no hay que perder tiempo estableciendo la
conexión entre cliente y servidor.
DatagramPacket
Clase que representa un paquete datagrama conteniendo
información de paquete, longitud de paquete, direcciones
Internet y números de puerto.
MulticastSocket
Clase utilizada para crear una versión multicast
de las clase socket datagrama. Múltiples
clientes/servidores pueden transmitir a un grupo multicast (un
grupo de direcciones IP compartiendo el mismo número de
puerto).
NetworkServer
Una clase creada para implementar métodos y
variables utilizadas en la creación de un servidor
TCP/IP.
NetworkClient
Una clase creada para implementar métodos y
variables utilizadas en la creación de un cliente
TCP/IP.
SocketImpl
Es un Interfase que nos permite crearnos nuestro propio
modelo de comunicación. Tendremos que implementar sus
métodos cuando la usemos. Si vamos a desarrollar una
aplicación con requerimientos especiales de
comunicaciones, como pueden se la implementación de un
cortafuegos (TCP es un protocolo no seguro), o acceder a equipos
especiales (como un lector de código de barras o un
GPS diferencial),
necesitaremos nuestra propia clase Socket.
2.3 ARQUITECTURA CLIENTE /
SERVIDOR
2.3.1 Antecedentes
Los ordenadores personales y los paquetes de software de
aplicaciones proliferan comercialmente. Estos ordenadores,
también conocidos como estaciones de trabajo programables,
están conectados a las Redes de Area Local (LAN), mediante
las cuales, los grupos de usuarios y profesionales comparten
aplicaciones y datos. Las nuevas
tecnologías de distribución de funciones y datos en una
red, permiten desarrollar aplicaciones distribuidas de una manera
transparente, de forma que múltiples procesadores de
diferentes tipos (ordenadores personales de gama baja, media y
alta, estaciones de trabajo, minicomputadoras o incluso
mainframes), puedan ejecutar partes distintas de una
aplicación. Si las funciones de la aplicación
están diseñadas adecuadamente, se pueden mover de
un procesador a otro sin modificaciones, y sin necesidad de
retocar los programas que las invocan. Si se elige una adecuada
infraestructura de sistemas
distribuidos y de herramientas de desarrollo, las
aplicaciones resultantes podrán trasladarse entre
plataformas de distintos proveedores.
Dos años atrás, aún cuando en aquel
momento se hablaba mucho y se hacía muy poco sobre el
tema, decíamos que el desarrollo de aplicaciones
Cliente/Servidor era inevitable por un conjunto de
razones:
En muchas situaciones es más eficiente que el
procesamiento centralizado, dado que éste experimenta una
"des-economía" de escala cuando
aumenta mucho la cantidad de usuarios.
Existían ya en ese momento servidores
razonablemente eficientes y confiables.
Se había establecido un estándar de hecho
para una interface Cliente/Servidor (el ODBC SQL, adoptado
por todos los fabricantes importantes de servidores).
Era imprescindible, para apoyar con información a
la creciente cantidad de ejecutivos de nivel medio que necesitan
tomar decisiones ante el computador,
ayudándose con las herramientas "front office", que
utilizan con toda naturalidad (planillas electrónicas,
procesadores de
texto, graficadores, correos electrónicos,
etc.).
Sin embargo, existía tecnología para esta
arquitectura desde hacía ya bastantes años, sin que
nada ocurriera. Los primeros trabajos conocidos para la
arquitectura Cliente/Servidor los hizo Sybase, que se
fundó en 1984 pensando en lanzar al mercado
únicamente productos para
esta arquitectura. A fines de la década pasada el producto fue
lanzado para el voluminoso segmento "low-end" del mercado, en
conjunción con Microsoft, teniendo como soporte de la
base de datos
un servidor OS/2, y como herramienta "front end" básica el
Dbase IV de Ashton Tate. El Dbase IV no se mostró como una
herramienta adecuada, y los desencuentros comerciales entre
Sybase, Microsoft e IBM (en aquel momento socia de Microsoft para
el OS/2) hicieron el resto.
La situación era muy diferente en 1994, cuando
los principales fabricantes tradicionales (Informix, Oracle,
Sybase) habían lanzado al mercado poderosos servidores y,
a ellos, se agregaba IBM que estaba lanzando su producto DB2
para, prácticamente, todos los sistemas
operativos importantes (además de sus clásicos
MVS y VM, ahora anunciaba AIX, OS/2,Windows NT, Hewlett Packard's
UNIX, Sun´s UNIX, Siemens' UNIX, etc.) y Microsoft que,
luego de finalizar su acuerdo con Sybase, partió para su
propio SQL Server
para Windows NT.
Existía un conjunto de lenguajes "front end"
como, por ejemplo, Delphi,
Foxpro,
Powerbuilder, SQL Windows, Visual Basic,
etc. Decíamos en aquel momento que Visual Basic,
más allá de sus méritos intrínsecos
como lenguaje, era el favorito para dominar el mercado, cosa que
está ocurriendo.
Por otra parte, en la comunidad
informática existían muchas dudas
sobre la calidad de los
optimizadores de los sistemas de gerencia de
base de datos, cuyas fallas del pasado habían sido
causantes de verdaderas historias de horror.
¿Qué ha ocurrido en estos dos
años?. Que los servidores se han mostrado sólidos y
eficientes, que sus optimizadores probaron, en general, ser
excelentes. Que una cantidad muy importante de empresas, en todo
el mundo, ha encarado aplicaciones Cliente / Servidor, y quienes
lo están haciendo con los planes necesarios y con las
herramientas adecuadas, están obteniendo éxitos muy
importantes, mientras los que lo hicieron desaprensivamente, han
cosechado fracasos.
¿Cuál es el mejor de los servidores?. Esta
es una cuestión muy complicada. Podemos tomar bechmarks
publicados por cada uno de los fabricantes, o hacer los nuestros
específicos, pero su importancia siempre es relativa. La
respuesta, además, depende del momento en que se la
formula. Para aplicaciones pequeñas y medias, todos han
probado ser muy buenos, las diferencias se darán cuando se
necesiten altísimos regímenes transaccionales, y
dependerán de cómo cada uno vaya incorporando
nuevas características como paralelismo, "read ahead",
etc. Cada nueva versión puede modificar las posiciones y
los principales fabricantes están trabajando al ritmo de
una gran versión nueva por año.
En general, la tecnología de los servidores de
base de datos ha evolucionado mucho en los últimos
años y todos los fabricantes trabajan con
tecnología sensiblemente equivalente. Parecen, mucho
más importantes para la elección, elementos que
están fuera de la tecnología: la confianza que nos
despierta el fabricante, su compromiso con el producto, su
tendencia a mantenerse siempre actualizado, su situación
económico/financiera, las garantías que nos brinde
el soporte local y, en menor medida, el precio.
Aunque inicialmente fueron los propios usuarios quienes
impulsaron esta nueva tecnología, la situación ha
cambiado drásticamente. Hoy en día, el modelo
Cliente/Servidor se considera clave para abordar las necesidades
de las empresas. El proceso distribuido se reconoce actualmente
como el nuevo paradigma de sistemas de
información, en contraste con los sistemas
independientes. Este cambio fundamental ha surgido como
consecuencia de importantes factores (negocio, tecnología,
proveedores), y se apoya en la existencia de una gran variedad de
aplicaciones estándar y herramientas de desarrollo,
fáciles de usar que soportan un entorno informático
distribuido.
2.3.2 Cliente/Servidor
El concepto de cliente/servidor proporciona una forma
eficiente de utilizar todos estos recursos de máquina, de
tal forma que la seguridad y fiabilidad que proporcionan los
entornos mainframe se traspasa a la red de área local. A
ésto hay que añadir la ventaja de la potencia y
simplicidad de los ordenadores personales.
La arquitectura cliente/servidor es un modelo para el
desarrollo de sistemas de información, en el que las
transacciones se dividen en procesos independientes que cooperan
entre sí para intercambiar información, servicios o
recursos. Se denomina cliente al proceso que inicia el diálogo o
solicita los recursos y servidor, al proceso que responde a las
solicitudes.
Es el modelo de interacción más
común entre aplicaciones en una red. No forma parte de los
conceptos de la Internet como los protocolos IP, TCP o UDP, sin
embargo todos los servicios estándares de alto nivel
propuestos en Internet funcionan según este
modelo.
Los principales componentes del esquema cliente/servidor
son entonces los Clientes, los Servidores y la infraestructura de
comunicaciones.
En este modelo, las aplicaciones se dividen de forma que
el servidor contiene la parte que debe ser compartida por varios
usuarios, y en el cliente permanece sólo lo particular de
cada usuario.
Los Clientes interactúan con el usuario,
usualmente en forma gráfica. Frecuentemente se comunican
con procesos auxiliares que se encargan de establecer
conexión con el servidor, enviar el pedido, recibir la
respuesta, manejar las fallas y realizar actividades de
sincronización y de seguridad.
Los clientes realizan generalmente funciones
como:
- Manejo de la interfase del usuario.
- Captura y validación de los datos de
entrada. - Generación de consultas e informes
sobre las bases de datos.
Los Servidores proporcionan un servicio al
cliente y devuelven los resultados. En algunos casos existen
procesos auxiliares que se encargan de recibir las solicitudes
del cliente, verificar la protección, activar un proceso
servidor para satisfacer el pedido, recibir su respuesta y
enviarla al cliente. Además, deben manejar los
ínterbloqueos, la recuperación ante fallas, y otros
aspectos afines. Por las razones anteriores, la plataforma
computacional asociada con los servidores es más poderosa
que la de los clientes. Por esta razón se utilizan PCs
poderosas, estaciones de trabajo, minicomputadores o sistemas
grandes. Además deben manejar servicios como administración de la red, mensajes, control
y administración de la entrada al sistema ("login"),
auditoría y recuperación y contabilidad.
Usualmente en los servidores existe algún tipo de servicio
de bases de datos. En ciertas circunstancias, este término
designará a una máquina. Este será el caso
si dicha máquina está dedicada a un servicio
particular, por ejemplo: servidores de impresión, servidor
de archivos, servidor de correo
electrónico, etc.
Por su parte los servidores realizan, entre otras, las
siguientes funciones:
- Gestión de periféricos compartidos.
- Control de accesos concurrentes a bases de datos
compartidas. - Enlaces de comunicaciones con otras redes de
área local o extensa. - Siempre que un cliente requiere un servicio lo
solicita al servidor correspondiente y éste, le responde
proporcionándolo. Normalmente, pero no necesariamente,
el cliente y el servidor están ubicados en distintos
procesadores. Los clientes se suelen situar en ordenadores
personales y/o estaciones de trabajo y los servidores en
procesadores departamentales o de grupo.
Para que los clientes y los servidores puedan
comunicarse se requiere una infraestructura de comunicaciones, la
cual proporciona los mecanismos básicos de
direccionamiento y transporte.
La mayoría de los sistemas Cliente/Servidor
actuales, se basan en redes locales y por lo tanto utilizan
protocolos no orientados a conexión, lo cual implica que
las aplicaciones deben hacer las verificaciones. La red debe
tener características adecuadas de desempeño, confiabilidad, transparencia y
administración.
Entre las principales características de la
arquitectura cliente / servidor, se pueden destacar las
siguientes:
- El servidor presenta a todos sus clientes una
interfase única y bien definida. - El cliente no necesita conocer la lógica del servidor, sólo su
interfase externa. - El cliente no depende de la ubicación física del
servidor, ni del tipo de equipo físico en el que se
encuentra, ni de su sistema operativo. - Los cambios en el servidor implican pocos o
ningún cambio en el cliente.
Como ejemplos de clientes pueden citarse interfaces de
usuario para enviar comandos a un
servidor, APIs para el desarrollo de aplicaciones distribuidas,
herramientas en el cliente para hacer acceso a servidores remotos
(por ejemplo, servidores de SQL) o aplicaciones que solicitan
acceso a servidores para algunos servicios. Como ejemplos de
servidores pueden citarse servidores de ventanas como X-Windows,
servidores de archivos como NFS, servidores para el manejo de
bases de datos (como los servidores de SQL), servidores de
diseño y manufactura
asistidos por computador, etc.
2.3.3 Componentes esenciales de la infraestructura
Cliente/Servidor
Una infraestructura Cliente/Servidor consta de tres
componentes esenciales, todos ellos de igual importancia y
estrechamente ligados:
Plataforma Operativa. La plataforma deberá
soportar todos los modelos de
distribución Cliente/Servidor, todos los servicios de
comunicación, y deberá utilizar, preferentemente,
componentes estándar de la industria para
los servicios de distribución. Los desarrollos propios
deben coexistir con las aplicaciones estándar y su
integración deberá ser imperceptible para el
usuario. Igualmente, podrán acomodarse programas escritos
utilizando diferentes tecnologías y
herramientas.
Entorno de Desarrollo de Aplicaciones. Debe elegirse
después de la plataforma operativa. Aunque es conveniente
evitar la proliferación de herramientas de desarrollo, se
garantizará que el enlace entre éstas y el
middleware no sea excesivamente rígido. Será
posible utilizar diferentes herramientas para desarrollar partes
de una aplicación. Un entorno de aplicación
incremental, debe posibilitar la coexistencia de procesos cliente
y servidor desarrollados con distintos lenguajes de
programación y/o herramientas, así como utilizar
distintas tecnologías (por ejemplo, lenguaje procedural,
lenguaje orientado a objetos, multimedia), y que han sido puestas
en explotación en distintos momentos del
tiempo.
Gestión de Sistemas. Estas funciones aumentan
considerablemente el costo de una solución, pero no se
pueden evitar. Siempre deben adaptarse a las necesidades de
la
organización, y al decidir la plataforma operativa y
el entorno de desarrollo, es decir, en las primeras fases de la
definición de la solución, merece la pena
considerar los aspectos siguientes:
- ¿Qué necesitamos gestionar?
- ¿Dónde estarán situados los
procesadores y estaciones de trabajo? - ¿Cuántos tipos distintos se
soportarán? - ¿Qué tipo de soporte es necesario y
quién lo proporciona?
Cómo definir una infraestructura Cliente/Servidor
si no se acomete el trabajo de
definir una infraestructura Cliente/Servidor. Se corre el riesgo
de que surjan en la empresa una
serie de soluciones Cliente/Servidor aisladas.
No es en absoluto recomendable el intento de una
infraestructura completa desde el principio, ya que las
tecnologías pueden no responder a tiempo a las necesidades
prioritarias del negocio. El enfoque más adecuado
está en un sistema y una plataforma de aplicación
conceptuales, y una arquitectura construida incrementalmente y
ampliada a medida que se desarrollan nuevas
aplicaciones.
La Plataforma Operativa, el Middleware y el Entorno de
Desarrollo de Aplicaciones están relacionados entre
sí. Las necesidades de apertura pueden condicionar la
elección de la plataforma o del middleware, de igual
manera que lo condiciona una determinada herramienta de
desarrollo. El software de
aplicación puede influir en la plataforma del sistema,
y el tiempo disponible para la primera aplicación puede
implicar algún tipo de compromiso. Por lo tanto, es
necesario fijar los objetivos y el
modo de conseguirlos en cada caso concreto: una
Metodología de Infraestructura para Sistemas Distribuidos
que permita definir una infraestructura para el sistema
Cliente/Servidor y evalúe la puesta en marcha del proyecto
sobre una base racional.
El enfoque estructurado de dicha Metodología
comprende los pasos siguientes:
- Captación de las necesidades. Definir,
analizar y evaluar, aunando los requerimientos del negocio con
las aportaciones tecnológicas. - Diseño conceptual en el que se sitúan
los principales bloques funcionales y de datos del sistema,
mostrando la relación y comunicación entre
ambos. - Detalle de los principales componentes funcionales,
selección de procesos, determinando los
principios
que deben aplicarse a la selección de software o
diseño de los módulos.
Al final de los tres pasos anteriores, se definen los
conceptos del sistema y la infraestructura tecnológica,
sin concretar, todavía, en productos o plataformas
específicos.
Por último, se llega a la selección de
plataformas y principales productos y componentes para la
implantación. El resultado es la descripción de una solución que
incluye infraestructura tecnológica, plataformas y
productos.
2.3.4 Ventajas y desventajas
1) Ventajas
a) Aumento de la productividad:
Los usuarios pueden utilizar herramientas que le son
familiares, como hojas de cálculo y
herramientas de acceso a bases de datos.
Mediante la integración de las aplicaciones
cliente / servidor con las aplicaciones personales de uso
habitual, los usuarios pueden construir soluciones
particularizadas que se ajusten a sus necesidades
cambiantes.
Una interface gráfica de usuario consistente,
reduce el tiempo de aprendizaje de las aplicaciones.
b) Menores costos de
operación:
La existencia de plataformas de hardware cada vez
más baratas. Esta constituye a su vez una de las
más palpables ventajas de este esquema, la posibilidad de
utilizar máquinas considerablemente más baratas que
las requeridas por una solución centralizada, basada en
sistemas grandes.
- Permiten un mejor aprovechamiento de los sistemas
existentes, protegiendo la inversión. Por ejemplo, la
compartición de servidores (habitualmente caros) y
dispositivos
periféricos (como impresoras)
entre máquinas clientes, permite un mejor rendimiento
del conjunto. - Se pueden utilizar componentes, tanto de hardware
como de software, de varios fabricantes, lo cual contribuye
considerablemente a la reducción de costos y favorece la
flexibilidad en la implantación y actualización
de soluciones. - Proporcionan un mejor acceso a los datos. La
interface de usuario ofrece una forma homogénea de ver
el sistema, independientemente de los cambios o actualizaciones
que se produzcan en él y de la ubicación de la
información. - El movimiento
de funciones desde un ordenador central hacia servidores o
clientes locales, origina el desplazamiento de los costos de
ese proceso hacia máquinas más pequeñas y
por tanto, más baratas.
c) Mejora en el rendimiento de la red:
Las arquitecturas cliente/servidor eliminan la necesidad
de mover grandes bloques de información por la red hacia
los ordenadores personales o estaciones de trabajo para su
proceso. Los servidores controlan los datos, procesan peticiones
y después transfieren sólo los datos requeridos a
la máquina cliente. Entonces, la máquina cliente
presenta los datos al usuario mediante interfaces amigables. Todo
esto reduce el tráfico de la red, lo que facilita que
pueda soportar un mayor número de usuarios.
Se puede integrar PCs con sistemas medianos y grandes,
sin que todas las máquinas tengan que utilizar el mismo
sistema operacional.
Si se utilizan interfaces gráficas para
interactuar con el usuario, el esquema Cliente/Servidor presenta
la ventaja, con respecto a uno centralizado, de que no es siempre
necesario transmitir información gráfica por la
red, pues ésta puede residir en el cliente, lo cual
permite aprovechar mejor el ancho de banda de la red.
Tanto el cliente como el servidor pueden escalar para
ajustarse a las necesidades de las aplicaciones. Las UCPs
utilizadas en los respectivos equipos, pueden dimensionarse a
partir de las aplicaciones y el tiempo de respuesta que se
requiera.
La existencia de varias UCPs proporciona una red
más fiable: una falla en uno de los equipos, no significa
necesariamente que el sistema deje de funcionar.
En una arquitectura como ésta, los clientes y los
servidores son independientes los unos de los otros, con lo que
pueden renovarse para aumentar sus funciones y capacidad de forma
independiente, sin afectar al resto del sistema.
La arquitectura modular de los sistemas cliente /
servidor, permite el uso de ordenadores especializados
(servidores de base de datos, servidores de ficheros, estaciones
de trabajo para CAD, etc.).
Permite centralizar el control de sistemas que estaban
descentralizados, como por ejemplo la gestión
de los ordenadores personales que antes estuvieron
aislados.
Es más rápido el mantenimiento
y el desarrollo de aplicaciones, pues se pueden emplear las
herramientas existentes (por ejemplo los servidores de SQL o las
herramientas de más bajo nivel como los sockets o el RPC
).
El esquema Cliente/Servidor contribuye además a
proporcionar a las diferentes direcciones de una
institución soluciones locales, pero permitiendo
además la integración de la información
relevante a nivel global.
2) Desventajas
Hay una alta complejidad tecnológica al tener que
integrar una gran variedad de productos.
Por una parte, el mantenimiento de los sistemas es
más difícil pues implica la interacción de
diferentes partes de hardware y de software, distribuidas por
distintos proveedores, lo cual dificulta el diagnóstico de fallas.
Requiere un fuerte rediseño de todos los
elementos involucrados en los sistemas de información
(modelos de datos, procesos, interfaces, comunicaciones, almacenamiento de
datos, etc.). Además, en la actualidad existen pocas
herramientas que ayuden a determinar la mejor forma de dividir
las aplicaciones entre la parte cliente y la parte
servidor.
Por un lado, es importante que los clientes y los
servidores utilicen el mismo mecanismo (por ejemplo sockets o
RPC), lo cual implica que se deben tener mecanismos generales que
existan en diferentes plataformas.
Además de lo anterior, se cuenta con muy escasas
herramientas para la
administración y ajuste del desempeño de los
sistemas.
Es más difícil asegurar un elevado grado
de seguridad en una red de clientes y servidores que en un
sistema con un único ordenador centralizado. Se deben
hacer verificaciones en el cliente y en el servidor.
También se puede recurrir a otras técnicas
como el encriptamiento.
Un aspecto directamente relacionado con el anterior, es
el de cómo distribuir los datos en la red. En el caso de
una empresa,
por ejemplo, éste puede ser hecho por departamentos,
geográficamente, o de otras maneras. Además, hay
que tener en cuenta que en algunos casos, por razones de
confiabilidad o eficiencia se pueden tener datos replicados, y
que puede haber actualizaciones simultáneas.
A veces, los problemas de congestión de la red
pueden degradar el rendimiento del sistema por debajo de lo que
se obtendría con una única máquina
(arquitectura centralizada). También la interface
gráfica de usuario puede a veces ralentizar el
funcionamiento de la aplicación.
El quinto nivel de esta arquitectura (bases de datos
distribuidas) es técnicamente muy complejo y en la
actualidad, hay muy pocas implantaciones que garanticen un
funcionamiento totalmente eficiente.
Existen multitud de costos ocultos (formación en
nuevas tecnologías, licencias, cambios organizativos,
etc.) que encarecen su implantación.
CAPITULO III INTERNET RELA CHAT (IRC)
QUE ES UN CHAT (IRC)
En Internet, la gran "mediateca" global, se puede hacer
casi de todo y uno de los servicios que ofrece Internet es el IRC
(Internet Relay Chat). A través del IRC, se puede charlar
con otros usuarios que en ese momento también estén
conectados a la red, no importa en qué parte del mundo.
Además se nos ofrece la posibilidad de entablar
conversación con cientos o miles de usuarios
simultáneamente.
En realidad, el IRC está basado en el TALK, un
programa para Unix que permite la conexión con un
ordenador remoto para mantener una charla interactiva con su
operador, de manera que todo lo que se escribe a través
del teclado lo
recibe la otra persona en su
monitor y
viceversa. El IRC es pues algo parecido, aunque mucho más
evolucionado.
HISTORIA DE LOS CHAT´S
Los inicios del IRC se remontan a 1988, cuando un
finlandés llamado Jarkko Oikarinen5
escribió el código original. Fue por tanto en
Finlandia donde se comenzó a usar esta tecnología,
aunque en ese momento todavía no estaba en Internet, sino
que J. Oikarinen la diseñó para usarla en su propia
BBS6 como un sistema multichat en tiempo
real.
Cuando comenzó a usar Internet como medio, el
sistema comenzó a popularizarse rápidamente y
pasó a convertirse en una herramienta de
comunicación casi indispensable para todos aquellos que
necesitaban comunicarse de una manera más directa que con
el correo electrónico.
Hay dos fechas clave que marcaron el impulso definitivo
del IRC. La primera es 1991, con el estallido de La Guerra del
Golfo; el uso de este sistema de comunicación que plasmaba
la realidad segundo a segundo comenzó a tomarse en serio.
Fue en este momento cuando comenzaron a florecer los programas de
IRC.
La otra fecha es Septiembre de 1993, cuando gran
número de usuarios (en tiempo real) informaban desde
Moscú de la inestabilidad social y política por la que
estaba pasando el país.
Actualmente, los canales de conversación del IRC
abarcan todos los temas imaginables, pudiendo encontrar canales
en los que se habla de los temas más simples, hasta
canales en donde los temas de conversación son
absolutamente serios y de gran acervo cultural.
Actualmente, las redes más grandes de servidores
de IRC son: Efnet7,
DALnet8,
UnderNet9, NewNet10
y GalaxyNet11
ELEMENTOS DE UN CHAT
Dentro de los elementos que encontramos dentro de un
Chat para que se pueda llevar a cabo la comunicación,
están los siguientes
Usuarios. Serán las personas que harán uso
del Chat.
Canales. Donde los usuarios podrán entrar y
salir, aunque en algunas se deban cumplir ciertos
requisitos.
Chat Room Salas de Charla. Donde todos los usuarios
"hablan" entre ellos
OPERS. Donde el/los usuario/s solicitan canales o
cualquier tipo de información.
ADM (Administradores). Estos son los que marcan las
pautas y normas a seguir
para el buen funcionamiento del Chat y la conducta de los
usuarios.
IrCOP. Serán las personas que se dedican al
mantenimiento del Chat
OPER. Son las personas que ante las necesidades de los
usuarios, les ayudan o suministran cualquier tipo de
información respecto, comunicaciones entre canales, entre
usuarios, reservas de canales privados, etc.
CARACTERÍSTICAS DE LOS
CHAT´S
La tecnología de la CMC hace posible que un grupo
de personas distantes físicamente, sin la posibilidad de
verse el uno al otro puedan comunicarse de manera
sincrónica, al igual que en los encuentros cara a cara,
usando la palabra escrita. En esta forma de comunicación
se combinan la permanencia de la palabra escrita y la fluidez del
intercambio propia de las conversaciones
presénciales.
Dentro de las características principales podemos
menciona:
Abierto las 24 horas del día todos los
días. Internet y la totalidad de sus aplicaciones
están disponibles las 24 horas del día todos los
días. Sólo un par de clicks separan a la persona
del acceso al mundo virtual si cuenta con el
software12 y el hardware13 necesarios. Una
vez ingresado (conectado) a la red, siempre habrá personas
esperando alguien con quien conversar. Puede plantearse la
posibilidad de que la persona frecuente un mismo chat room y que
en éste, a las 7 de la mañana, no haya usuarios.
Este pequeño problema se soluciona fácilmente: se
puede entrar a otros canales de otros países (por ejemplo,
al de España,
que remite a un lugar del mundo donde son las 11 de la
mañana y probablemente haya mas usuarios en
línea).
Control sobre la presentación de uno mismo y
sobre lo que los otros ven del sí mismo. En IRC, el
anonimato, facilita la creación de un personaje. Las
máscaras esconden a la persona y permiten jugar un
personaje cuyas características son fácilmente
configuradas por la propia persona.
Control sobre la relación. Los programas de IRC
ofrecen la posibilidad de elegir con quien hablar y con quien no.
Es decir, que si al sujeto no le interesa comunicarse con una
determinada persona, con sólo tipear un comando (/ignore)
seguido por, por ejemplo, el nickname de ésta, logra su
objetivo. }
TIPOS DE CHAT
Los hay de todo tipo, desde el que solo admite texto sobre un
fondo liso (la versión primera del MIRC, hasta el que
combina también voz e imagen junto con la posibilidad de
compartir archivos, dibujar en una misma pizarra, etc. Poco a
poco, los chat´s se están quedando anticuados y en
muy poco tiempo nos encontraremos con chats en 3D (ya existen
algunos) acompañados de videoconferencia.
Como ejemplo podemos citar los chat´s mas usados
en la comunidad latina a: Latinchat, Starmedia, Yahoo, Microsoft
Chat, Esmas, etc.
EJEMPLO DE UN CHAT HECHO EN JAVA
Aquí veremos un ejemplo relativamente completo,
en donde se tratan todos los aspectos que se realizan para una
comunicación Chat (Servidor Chat y Cliente Chat). Para
ello vamos a construir una aplicación cliente-servidor que
implemente un servicio de chat: una serie de usuarios (clientes)
se conectan al chat (servidor) de forma que cada
información transmitida por un usuario le llega a todos
los demás.
1. Servidor de chat
El servidor se implementa haciendo uso del
multi-threading, para no limitar el número máximo
de usuarios que se conecten al servicio. El servidor será
el siguiente:
Servidor de chat: clase |
import java.net.*; public class ChatServer { |
Servidor de chat: clase |
import java.net.*; |
2. Cliente de
chat
El programa cliente se ha implementado tanto en forma de
aplicación como en forma de applet. Como se puede
observar, en general, la mayor parte del código es
similar.
Cliente de chat: | ||||||
/** | ||||||
Cliente de chat: | ||||||
/** import java.net.*; // Applet parameters: public class ChatApplet extends Applet protected TextArea output; protected Thread listener; public void init () { public void start () { public void stop () { public void run () { public void execute () {
Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior. Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.
|
