El presente artículo sólo intenta aportar un enfoque práctico a un tema del cual se dispone de mucha información en la red: Licencias libres, y más concretamente la GPL (General Public License). Todo lo que quieras saber está en el site de la Free Software Fundation (FSF), incluyendo un montón de casuística que, por razones de espacio y para no aburrir al personal, no voy a incluir en el presente documento.
He de indicar, antes de nada, que no me considero un experto en estas cuestiones. No he estudiado derecho, tampoco soy programador y menos aún he colaborado en proyectos GPL (aunque en esto último debo decir que ha sido por falta de tiempo, no por ganas, dado que existen multitud de posibilidades de cara a participar: traduciendo documentación, probando betas, reportando bugs, ofreciendo servidores para colgar-distribuir aplicaciones, diseñando logos, iconos,…) Me muevo en el mundo de la gestión de recursos (redes, equipos informáticos y personas) e intento, siempre desde el respeto a otros SO y a la habilidad de aquellos que van a manejar los equipos, introducir algo del mundo GNU en el que llevo ya desde el año 96 (en todo este tiempo el tema del “free” software y las licencias y estándares ha sido algo que me ha preocupado y sobre el que he procurado mantenerme informado)

Con este marco como presentación, paso a abordar el tema. Creo que a la hora de hablar sobre licencias de software hay un concepto sobre el que siempre debemos “pivotar”: los derechos. Tanto derechos del usuario como del programador. Desde este punto de vista, debemos siempre tener presente dos realidades:

• La licencia GNU GPL se enfoca más hacia los derechos del usuario, frente a otras privativas como la licencia EULA, que busca “proteger” a la empresa desarrolladora del software. Esto al menos en la teoría: yo nunca he entendido cómo pueden perjudicar los derechos del usuario a la empresa. Si el primero está contento, se beneficiará retroactivamente la segunda… Pero aquí entran en juego concepciones sobre el alcance del término licencia y patente (tan distintos en los EEUU y Europa, por ejemplo, aunque últimante intente imponerse el sentido americano en el viejo contienente. Ciertamente es más goloso, monetariamente hablando, a corto plazo).
• Por otro lado, las licencias privativas (por cierto, todavía no he mencionado que EULA es la licencia de Microsoft) tienen por objetivo limitar al usuario a tomar acciones, elecciones u opciones sobre el software (el impedir el acceso al código fuente, por ejemplo, no nos permite adaptar las aplicaciones a nuestras necesidades y a nuestro equipo, eliminando opciones que no vayamos a utilizar o recompilándolo para optimizarlo según el procesador que tengamos, por ejemplo) mientras que la GNU GPL pretende salvaguardar los derechos de los desarrolladores originales, asegurando de esta forma la continuidad y la accesibilidad del código fuente para el software.

Hasta aquí no he descubierto nada nuevo. Estas dos ideas aparecen de forma reiterativa en todos los foros y news que consultemos sobre el tema. Una lectura rápida y superficial de ambas licencias reafirman lo dicho:

La licencia GPL

• Permite la copia, modificación y redistribución del software.
• Al no suponer costo alguno, tampoco nos ofrece garantías. Si la última versión mejorada del programa no corre en tu PC, no puedes exigir daños y perjuicios al creador del soft. De ahí la importancia de la Comunidad que gira en torno de cada proyecto, que ofrece soluciones, parches y ayuda a todo aquel que lo necesite.
• Algo que muchas veces se desconoce o confunde con el “freeware”: Posibilita que el software sea vendido y se puedan cobrar por los servicios sobre las aplicaciones creadas… Al fin y al cabo hay que vivir de algo, y no sólo de amor al “arte”.

Debemos incluir el código fuente además del proyecto compilado.

• Si modificamos el software y lo comercializamos, no debe tener costo por la licencia.
• Los cambios en la licencia deben mantener ciertos términos generales, recogidos en la documentación de la propia licencia.

Mientras, las licencias privativas

• Prohíben la copia y requieren de un registro obligatorio.
• Solo pueden ser transferidas un número limitado de veces a otros usuarios.
• La garantía que ofrecen es por los primeros 90 días (en general), además de no garantizar actualizaciones y parches a lo largo de lal vida “útil” de mi equipo.

Hay que indicar que la licencia GPL apareció en los años 80 como resultado de los esfuerzos de la FSF de cara a salvaguardar los derechos del usuario informático en un entorno cada vez más dominado por las patentes. La primera versión respondía a una visión un tanto “ingenua” de la realidad y pronto tuvo que someterse a una revisión. Como resultado apareció la segunda versión de la GPL, que es la actualmente vigente y que data de Junio de 1991. En todo este tiempo han surgido múltiples avances y situaciones no recogidas que han llevado a un nuevo proceso de revisión de la licencia, que se espera cristalicen en la GPL v.3. Ahora mismo está en proceso de discusión pública (se inició el 16 de enero de 2006 con la presentación del primer borrador) y con mucha controversia por parte de pesos pesados el mundo GNU. Pretende:

• Resolver formas en que a pesar de todo alguien podía quitar libertades a los usuarios, incluyendo cláusulas que defiendan a la comunidad de software libre del uso indebido de patentes de software
• Prohibir el uso de software cubierto por la licencia en sistemas diseñados para quitar libertades (DRM).
• Resolver ambigüedades y aumentar su compatiblidad con otras licencias.

El hecho es que la versión que actualmente rige es la GPL v.2, que es bajo la cual están licenciados el kernel del sistema GNULinux y un montón de paquetes y utilidades fundamentales, especialmente aquellos creados por miembros de la FSF, aunque otras utilidades “imprescindibles”, como pueden ser XFree86, OpenSSH, Mozilla, OpenOffice, etc., se distribuyen bajo licencias libres no-GPL.

Dicho esto hay que aclarar dos puntos claves referidos a las distros linux cuya respuesta no siempre se encuentra en los debates que sobre este tema se tienen en la red:

CLAVE 1:

• La GPL, al igual que otras licencias, no consideran como “distribucion” a la mera agregación de aplicaciones. Esto es: si yo tomo el programa GPL wifignu v.0.1, remasterizo la distro knoppix STD 0.1 y distribuyo la distro HackWifi 0.1, debo decir que el trabajo se basa en knoppix STD 0.1, mantener integras todas las notas de copyright de knoppix STD 0.1 en HackWifi 0.1, señalar las diferencias entre una y otra y ofrecer el código fuente.

CLAVE 2:

• Todas las distribuciones importantes (RedHat, SuSE, Mandriva, etc. Debian es un caso aparte) tienen dos versiones: La oficial y la “sólo” GLP.
• La ”sólo” GLP es la versión “libre” de la casa distribuidora. Se colocan en el FTP publico respectivo para que puedan ser copiadas en los Cds, DVDs o pendrives.
• La llamémosla versión oficial añade una serie de extas a la distribucion para hacerla mas atractiva: manuales, mayor número de paquetes, presentación en cajas con logos… Incluyen igualmente drivers y aplicaciones privativas, para lo cual ha debido realizar previamente acuerdos con fabricantes de Software para incluir “licencias especiales o limitadas” de esos productos adaptados a su distribución. La mayoria estas “licencias limitadas”, permiten que el comprador del producto Oficial pueda utilizar el software para fines no comerciales. Una de las consecuencias que tiene la inclusión de estas licencias es que si uno copia el DVD “oficial” de la distro donde están incluidos estos programas, incurre en un acto que puede llegar a ser ilegal, en función de los límites impuestos por la licencia. Por lo tanto, si queremos disfrutar (=descargar, tostar) Linux, debemos mirar primero que sea la distribucion GLP del fabricante, no la oficial. Si queremos un Linux más completo, con soporte y actualizaciones, debemos comprar la version oficial… Personalmente creo que es conveniente realizar este desembolso de vez en cuando, dado que no es un gran gasto comparado con otros S.O. y estamos animando a los fabricantes a que cada dia mejoren el soporte de Linux para sus productos. La ley de la oferta-demanda.

Hasta ahora he hablado de la GPL como si fuese una cosa única y no es así. Existen múltiples variaciones de esta licencia, en función del comentido que desempeñen. Si nos referimos a la creación de proyectos-aplicaciones software (que es donde me quiero centrar dada la enorme confusión que existe al respecto), el proyecto GNU tiene dos licencias principales: La GNU GPL habitual y la GNU GPL para Bibliotecas [GNU Library GPL].
Un comentario sobre esta última: Usar la GNU Library GPL permite el uso de la biblioteca en programas privativos. Mientras que el uso de la GPL usual para una biblioteca la hace disponible únicamente para programas libres. Las consecuencias sobre escoger una u otra son claras.

Las propia GNU GPL recoge múltiple casuística que se nos pueden presentar al programar aplicaciones libres. ¿Podemos incluir código libre en aplicaciones privativas? El código generado por aplicaciones libres ¿es también libre? ¿Debo licenciar públicamente cualquier aplicación libre que modifique, incluyendo las fuentes? ¿Puedo licenciar plug ins libres para aplicaciones privativas..? En estos casos la respuesta es no, aunque en todos ellos se matiza. La ética personal y la utilización de las aplicaciones suelen ser los raseros de enjuiciamiento. Recomiendo encarecidamente leer con detenimiento las faqs que al respecto están el la web de la FSF.

Existen también otras licencias “hermanas” de la GPL:

• La licencia de documentación libre GNU (GFDL) -todos los artículos de la wikipedia están licenciados como GFDL-
• La Open Audio License, para trabajos musicales,
• La MGPL o la LGPL (Lesser General Public License y Library General Public License), que permiten el enlace dinámico de aplicaciones libres a aplicaciones no libres.

Por último, una serie de aclaraciones sobre los pasos concretos para licenciar como GPL una aplicación que he creado.

Primero y muy importante: Legalmente hablando, sólo la versión original (en inglés) de la GPL es la que especifica realmente las condiciones de distribución de los programas GNU… Vamos, que lo correcto sería incluir el texto original de la licencia GPL en mi aplicación. Aunque de cara a facilitar la labor a la gente que no sabe inglés, la FSF permite utilizar traducciones a otros idiomas si se indica que se siguen sus normas para traducciones no oficiales.

Segundo: El texto de la licencia habría que adjuntarlo en principio al comienzo de cada archivo fuente. Como esto resultaría pesado en exceso, se recomiendo que sólo se incluya un aviso que contenga por lo menos la línea del “copyright” y un indicador sobre el lugar en el que podemos localizar el texto completo. Generalmente se coloca en un archivo con el nombre COPYRIGHT y/o en el README, en el cual también se incluyen instrucciones sobre la compilación, el modo de reportar bugs y una dirección de contacto con la persona que coordina-lidera el proyecto.

El texto a incluir sería de la forma que sigue:

Por Mordor.

Después de unas no tan merecidas vacaciones de fin de año, retomaré la costumbre de andar posteando cosillas en el blog. Iniciemos el año con un pequeño calentamiento en Java, tratando un tema muy sencillo pero muy útil: RMI o Invocación de Métodos Remotos (por sus siglas en inglés Remote Method Invocation).

Una definición simple podría ver al RMI como una forma de utilizar funciones de un programa, desde otro programa residente en otro equipo. Es decir, permitir a un programa (A) utilizar las funciones de otro programa (B), solo que el programa B está en otro equipo. Es ejecutar algo por allí, pero que parezca que esté por acá.
Pero, ¿que ventajas trae esto? umm, a simple vista las ventajas son obvias: se puede distribuir un programa en varios equipos; así podemos dividir la carga de procesos en varios hosts, y haciendo el programa más rápido. Esto es útil si el equipo “cliente” no tiene una suficiente capacidad de procesamiento, por ejemplo.

Ahora, una definición wiki más técnica podría ser está (utilicemos las ventajas del GFDL):

RMI es un mecanismo ofrecido en Java para invocar un método remotamente. Al ser RMI parte estándar del entorno de ejecución Java usarlo provee un mecanismo simple en una aplicación distribuida que solamente necesita comunicar servidores codificados para Java. Si se requiere comunicarse con otras tecnologías debe usarse CORBA o SOAP en lugar de RMI.

Al estar específicamente diseñado para Java RMI provee pasaje por referencia de objetos (cosa que no hace SOAP), “recolección de basura” distribuida y pasaje de tipos arbitrarios (funcionalidad no provista por CORBA).

Por medio de RMI, un programa Java puede exportar un objeto. A partir de esa operación este objeto está disponible en la red, esperando conexiones en un puerto TCP. Un cliente puede entonces conectarse e invocar métodos. La invocación consiste en el “marshaling” de los parámetros (utilizando la funcionalidad de “serialización” que provee Java), luego se sigue con la invocación del método (cosa que sucede en el servidor). Mientras esto sucede el llamador se queda esperando por una respuesta. Una vez que termina la ejecución el valor de retorno (si lo hay) es serializado y enviado al cliente. El código cliente recibe este valor como si la invocación hubiera sido local.

Este fragmento de texto fue extraido del artículo RMI de la Wikipedia; por lo tanto está bajo los terminos de la Licencia de Documentación Libre de GNU (véase su uso).

Ahora bien, vamos a ver un ejemplo explicado de RMI. Lo primero es implementar el servidor. Para ello se debe crear una “interfaz” que enumere las funciones provistas por el objeto a ser exportado por la red. Esta “interfaz” (en este ejemplo la interfaz se llama InterfazReceptorMensajes.java) es compartida entre cliente y servidor. Del lado servidor es necesario que una de las clases (que hace de servidor como tal) implemente dicha interfaz. Del lado cliente el llamador accede a la misma interfaz, pero debajo hay un “stub” que da comienzo a la llamada vía la red. Para crear este “stub” es necesario utilizar el “compilador” rmi llamado rmic.

El lado cliente y el lado servidor deberán tener ambos acceso a la definición de las clases utilizadas para el intercambio de parámetros y de valores de retorno. Para esto Java tiene la capacidad de dinámicamente obtener las clases que se necesiten desde un servidor.

El programa a explicar consta de dos GUI’s, una para el cliente y una para el servidor. El cliente tiene una caja de texto donde se escriben los mensajes a enviar; dichos mensajes se envian utilizando un método remoto. Mientras, el servidor posee un area de texto donde se muestran los mensajes que recibe de los posibles clientes. Esta es la salida del los programas Servidor/Cliente:

Expliquemos entonces, paso a paso, el código fuente de la aplicación. Comencemos con la interfaz InterfazReceptorMensajes.java. Fíjate que no se declara una clase como tal (public class), sino una interfaz; y que dicha interfaz hereda de la clase Remote del paquete java.rmi. Además se declara el método recibirMensaje, más no se define. Y es necesario indicar que dicho método puede lanzar una excepción RemoteException.

import java.rmi.*;
public interface InterfazReceptorMensajes extends Remote
{
//Este es el metodo que implementará el servidor
void recibirMensaje(String texto) throws RemoteException;
}

Antes de ver el mecanismo de funcionamiento del servidor, veamos como funciona la clase GUIServidor, que simplemente nos sirve como salida para los procesos que realice el servidor. Lo único a resaltar en esta clase es el método anadirEntradas que nos permite añadir texto en el area de texto.

import javax.swing.*;
public class GUIServidor extends JFrame {

private JTextArea areaTexto;

public GUIServidor() {
super("Servidor RMI");
areaTexto = new JTextArea();
areaTexto.setEditable(false);
getContentPane().add(new JScrollPane(areaTexto));

setSize(600, 400);
setVisible(true);
}

public void anadirEntradas(String texto) {
areaTexto.append(texto + "\n");
}
}

Ahora veamos la clase RmiServidor.java que, como su nombre lo indica, maneja la parte del servidor. Es necesario importar ciertos paquetes y clases. Por ejemplo la clase InetAddress del paquete java.net, que sirve para capturar la dirección IP de la máquina local. Todo el paquete java.rmi, java.rmi.registry y java.rmi.server.

import java.net.InetAddress;
import java.rmi.*;
import java.rmi.registry.*;
import java.rmi.server.*;import javax.swing.JFrame;

En la declaración de la clase es necesario heredar de la clase UnicastRemoteObject del paquete java.rmi.server, e implementar la interfaz InterfazReceptorMensajes.

public class RmiServidor extends UnicastRemoteObject implements InterfazReceptorMensajes {

Ahora declaramos los objetos que vayamos a utilizar. Declaramos el objeto ventana de la clase GUIServidor, para la parte visual. Una variable entera para almacenar el valor del puerto de escucha. Un string que almacenará la dirección IP del equipo servidor. Y un objeto Registry, del paquete java.rmi.registry.

private static GUIServidor ventana;
private int estePuerto;

private String estaIP;
private Registry registro;

El constructor de la clase debe especificar el tipo de excepciones que puede lanzar, en este caso RemoteException. Después obtenemos la dirección IP del servidor utilizando el método estático getLocalHost() de la clase InetAddress; y la almacenamos en el objeto estaIP. Se define el puerto de escucha en 3232. Y se despliega información en la GUI del servidor, acerca de la dirección IP y el puerto de escucha:

public RmiServidor() throws RemoteException {
try {
// obtener la direccion de este host.
estaIP = (InetAddress.getLocalHost()).toString();
} catch (Exception e) {

throw new RemoteException("No se puede obtener la direccion IP.");
}
estePuerto = 3232; // asignar el puerto que se registra
ventana.anadirEntradas("Conexion establecida por...\nEsta direccion="
+ estaIP + ", y puerto=" + estePuerto);

Luego se inicializa el objeto registro, utilizando la instrucción LocateRegistry.createRegistry(estePuerto); que indica al registro el puerto por el cual va a recibir conexiones, de la siguiente forma:

try {
// crear el registro y ligar el nombre y objeto.
registro = LocateRegistry.createRegistry(estePuerto);
registro.rebind("rmiServidor", this);
} catch (RemoteException e) {
throw e;
} }

El método recibir mensajes aquí definido, es el mismo que se declaró en la interfaz InterfazReceptorMensajes.java. Este método recibirá un string y lo enviará al método anadirEntradas de la GUI, para desplegar dicho mensaje en pantalla.

public void recibirMensaje(String texto) throws RemoteException {
ventana.anadirEntradas(texto);
}

En el método main se crea una instancia de la clase RmiServidor, lo que lanza el programa servidor, y lo pone en escucha:

public static void main(String[] args) {
JFrame.setDefaultLookAndFeelDecorated(true);
ventana = new GUIServidor();
ventana.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
try {
new RmiServidor();
} catch (Exception e) {
e.printStackTrace();
System.exit(1);
} }

Para compilar adecuadamente la parte del servidor y crear el “stub”, es decir: la interfaz gráfica (GUIServidor.java), la interfaz receptora de mensajes (InterfazReceptorMensajes.java) y el servidor (RmiServidor.java), debes utilizar los siguientes comandos:

javac *.java
rmic RmiServidor

Nota: El uso del comando rmic es necesario para crear el stub, aunque esto solo es en algunas versiones de Java. He probado con la version 1.5 y no he tenido que utilizarlo para que el programa funcione correctamente. Pero es recomendable usarlo en cualquiera de los casos, para evitar posibles errores.
Es de notar también que al utilizar el comando rmic, este crea un archivo de clase aparte del convencional (que se gunera con el comando javac), este archivo (para este ejemplo) toma el nombre de: RmiServidor_Stub.class, y es el que Java utiliza para manipular el stub del servidor.

Ahora veamos la parte cliente. Como ya hemos dicho antes la interfaz InterfazReceptorMensajes.java se comparte entre cliente y servidor; por lo cual solo nos queda explicar la clase RmiCliente.java. En dicha clase es necesario importar los paquetes java.rmi y java.rmi.registry, además de los necesarios para la GUI:

import java.rmi.*;
import java.rmi.registry.*;
import javax.swing.*;
import java.awt.*;import java.awt.event.*;

La clase RmiCliente, aparte de los necesarios para la interfaz gráfica, declara: un objeto de la interfaz InterfazReceptorMensajes, un objeto de la clase Registry y dos objetos String en donde colocaremos la dirección IP del servidor a conectarnos y el puerto de escuha. En este caso, en la dirección IP del servidor coloco la loop IP (127.0.0.1), ya que las pruebas las realizo en el mismo equipo, es decir, servidor y cliente corriendo en la misma máquina:

public class RmiCliente extends JFrame implements ActionListener {
private JTextField cajaEnviar;
private JButton botonEnviar;
private JLabel estado;
private static InterfazReceptorMensajes rmiServidor;
private static Registry registro;
private static String direccionServidor = "127.0.0.1"; private static String puertoServidor = "3232";

El constructor inicializa y configura los objetos de la GUI:

public RmiCliente() {
super("Cliente RMI");
getContentPane().setLayout(new BorderLayout());
cajaEnviar = new JTextField();
cajaEnviar.addActionListener(this);
botonEnviar = new JButton("Enviar");
botonEnviar.addActionListener(this);
estado = new JLabel("Estado...");

getContentPane().add(cajaEnviar);
getContentPane().add(botonEnviar, BorderLayout.EAST);
getContentPane().add(estado, BorderLayout.SOUTH);

setSize(300, 100);
setVisible(true);
}

El método actionPerformed captura cualquier evento, ya sea de la caja de texto o del boton, y envía el mensaje como parámetro al método enviarMensaje.

public void actionPerformed(ActionEvent e) {
if (!cajaEnviar.getText().equals("")) {
enviarMensaje(cajaEnviar.getText());
cajaEnviar.setText("");
} }

El método conectarseAlServidor inicializa el objeto registro (de la clase Registry), utilizando para ello la instrucción LocateRegistry.getRegistry(), que recibe como argumentos la dirección IP del servidor y el puerto de escucha. Luego inicializa el objeto rmiServidor (de la clase InterfazReceptorMensajes) utilizando el método lookup de de la clase Registry. Fíjate que al utilizar el método lookup se le pasa como argumento el string “rmiServidor”, pero ¿porqué “rmiServidor”?; la respuesta es sencilla: cuando implementamos el servidor y lo ponemos a la escucha, utilizamos el comando registro.rebind(“rmiServidor”, this); esto es como colocarle nombre al registro de escucha, y por ello al crear el registro cliente es necesario indicar dicho nombre.

private static void conectarseAlServidor() {
try {
// obtener el registro
registro = LocateRegistry.getRegistry(direccionServidor,
(new Integer(puertoServidor)).intValue());
// creando el objeto remoto
rmiServidor = (InterfazReceptorMensajes) (registro
.lookup("rmiServidor"));
} catch (RemoteException e) {
e.printStackTrace();
} catch (NotBoundException e) {
e.printStackTrace();
}
}

El método enviarMensaje es el que realmente utiliza RMI. Dicho método utiliza la función recibirMensaje del objeto rmiServidor, es decir: utiliza el método remoto del servidor a través de la interfaz.

private void enviarMensaje(String mensaje) {
estado.setText("Enviando " + mensaje + " a " + direccionServidor + ":"
+ puertoServidor);
try {
// llamando el metodo remoto
rmiServidor.recibirMensaje(mensaje);
estado.setText("El mensaje se ha enviado!!!");
} catch (RemoteException re) {
re.printStackTrace();
}
}

El método main utiliza la función conectarseAlServidor para crear la conexión, y luego crea el objeto de la GUI:

static public void main(String args[]) {
JFrame.setDefaultLookAndFeelDecorated(true);
conectarseAlServidor();
RmiCliente ventana = new RmiCliente();
ventana.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
}

El proceso de compilación del cliente es normal, no tienes que utilizar otros comandos. Por cuestiones de comodidad he realizado las pruebas en un solo equipo, pero lo ideal es hacerlo en equipos distintos, y mas aún: que tengan SO diferentes. Por ejemplo correr el servidor en un equipo con Linux, y utilizar sus métodos remotos desde uno con Windows; ahí se centra el verdadero potencial del Java y RMI: la multiplataforma.

Bien eso es todo. Imagino que ya descargaste el código fuente de los ejemplos. Dudas, comentarios, sugerencias e insultos: castidiablo[at]gmail.com.

Descargar versión en PDF
Descargar código fuente de los ejemplos

Este es un tema que aparentemente no tiene nada que ver con la programación de computadores, pero es fundamental conocer ciertos conceptos para poder desarrollar aplicaciones sobre ciertas tecnologías. Y aún más sabiendo que la programación forma importante parte del Internet.

Un servidor Web es un software de aplicación que nos brinda un servicio; pero ¿qué tipo de servicio? bien, al decir “Web” nos referimos obviamente a internet o a una red, por ello un “Servidor Web” debe implementar el protocolo HTTP (protocolo de transferencia de hipertexto). Este protocolo está diseñado para transferir páginas web, es decir, documentos en HTML (HyperText Markup Language): textos complejos con enlaces, figuras, formularios, botones y objetos incrustados como animaciones o reproductores de sonidos.

Aclaremos algo
El termino servidor es algo ambiguo, ya que un servidor es el software que presta un servicio, pero también se llama servidor a la máquina donde está instalado dicho software. En este artículo vamos a hablar del software, mas no del hardware.

¿Cómo funciona?

El servidor está siempre a la espera de peticiones Web. Dichas peticiones son hechas por un cliente http (un navegador web), que después de realizar la petición espera la respuesta del servidor. Por ejemplo, cuando digitas en tu navegador la dirección http://www.google.com/ este envía una petición HTTP al servidor de Google, dicho servidor responde al cliente enviando el código HTML de dicha página. El cliente recibe el código fuente, lo interpreta y lo muestra en pantalla. El servidor se limita a recibir las peticiones y responderlas adecuadamente, mientras el cliente se encarga del proceso de interpretación.

En cuanto a programación se refiere, existen dos tipos de aplicaciones web: del lado del cliente y del lado del servidor. Las aplicaciones del lado del cliente se ejecutan en el navegador web, entre ellas cabe destacar JavaScript, Visual Basic Script y los applets de Java. En cuanto a las aplicaciones del lado del servidor existen lenguajes de programación, que se ejecutan en el equipo servidor, generalmente formando documentos HTML dinámicos (basandose en operaciones y/o acceso a bases de datos, por ejemplo). Entre los lenguajes más destacables del lado del servidor están: PHP, JSP, ASP, Perl, CGI, entre otros.

En la mayoría de los casos se opta por utilizar tecnologías del lado del servidor, por varios motivos, por ejemplo: al ejecutarse en el servidor las respuestas son, por lo general, estándares XHTML por lo que cualquier navegador puede interpretarlas, cosa que no pasa con las tecnologías cliente (que en algunos casos necesitan plugins). Otra ventaja es ĺa seguridad: al ejecutarse el código fuente en el servidor, el programación es transparente al cliente, permitiendo ocultar así los detalles de implementación.

¿Qué servidores existen?

Algunos servidores conocidos son:

• Apache
• Internet Information Server (IIS)
• Tomcat, un servidor basado en Apache para estándares de Java (JSP y Servlets)
• lighttpd
• thttpd

Version pdf: Descargar

JSP (Java Server Pages) es una tecnología web, del lado del servidor, que se usa generalmente para generar documentos XHTML y XML dinámicos. JSP es un producto de la compañía Sun Microsystems, y su funcionamiento se basa en script’s, con una sintaxis similar al la de Java.

JSP es una tecnología similar a PHP, ASP y demás. Y permite incrustar código JSP dentro del HTML, para crear información dinámicamente (basándose en operaciones o acceso a bases de datos, por ejemplo). El código JSP se incrusta en el HTML dentro de las marcas , a esto se le llama scriptled.

Una de las principales ventajas del JSP, es que permite al programador integrar los scripts con clases de Java (en estos casos llamados servlets), lo que permite tener por separado los módulos que se encargan de hacer los procesos de datos (por lo general los archivos .class), de los que se encargan de presentar visualmente dichos datos (los documentos JSP).

Para correr un programa en JSP es necesario tener instalado un servidor que soporte dicha tecnología. La mejor opción sin duda es utilizar el Apache Tomcat, aunque es posible configurar servidores como el IIS para que ejecuten servlets. Tomcat posee un contenedor Web que cumple con las especificaciones de JSP y de Servlet.

Vamos a ver como sería el “hola mundo” en JSP. Lo único que tenemos que hacer es crear un documento con la extensión *.jsp y con el siguiente contenido:

<html>

<head><title>Ejemplo JSP</title></head>

<body>

<%

out.println(“Hola mundo!!!<br/>”);

out.println(“<b>elhacker r00Lz</b>”);

%>

</body>

</html>

La salida de este programa sería la siguiente:

Fíjate que la salida del programa se genera con la funcion out.println(“texto”), y que es necesario usar etiquetas HTML para dar formato al documento correctamente. Por ejemplo, para que haya un salto de línea entre una frase y la otra es necesario imprimir la marca. Ahora miremos el código fuente generado, es decir, el que recibe el cliente:

Como ves, el documento generado no contiene nada de código JSP, ya que éste se ejecuto en el servidor y envió al cliente un archivo HTML simple. Este no es un tutorial de referencia para JSP, si es lo que necesitas hay bastantes en internet. Si deseas más información acerca de JSP puedes visitar su página oficial.
Si deseas comenzar a programar en JSP tienes primero que tener el servidor Apache Tomcat. Sino lo has hecho, puedes leer este artículo donde explico como instalarlo y configurarlo, tanto en Windows como en Linux.

Descargar versión en PDF

Java es un lenguaje de programación orientado a objetos muy utilizado en el escritorio, y aún más en el servidor. Información en el Blog:

• Entorno típico de programación en Java
• Compiladores e IDE’s
• Listado de ejercicios y ejemplos
• Enlaces, tutoriales y recursos en la web

Brainkfuck es como su nombre lo dice un jodecerebros. Se trata de un lenguaje de programación esotérico, creado por un psicópata maniático llamado Urban Müller en 1993. Este mounstruo de lenguaje fue echo con el fin de que fuera simple y que tuviera pocas instrucciones (fue basado en la Máquina de Turing).

Primero, y antes de nada, quisiera que veas un programa en Brainfuck que creé hace un tiempo, para que veas los fácil que es desarrollar aplicaciones en este lenguaje XD. El programa imprime la cadena “elhacker.net”:

++++++++++[>++++++++++<-]>+.+++++++.
—-.——-.++.>++[<++++>-]<.——.>+++[<
++ ++>-]<+.>++++[>+++++++++++<-]>++.[-]
<<– –.>++[<---->-]<-.>+++[<+++++>-]<.

¿entendible nó? umm, que lenguaje más bonito… Y te quejabas del C++ y Java ¿no? La verdad es más fácil de lo que parece… la lógica del programa se basa en un arreglo de bytes, mínimo de 30000 espacios, todos inicializados a cero; un puntero que “apunta” a la primera direccion del array; y dos corrientes de bytes entrada y salida. Las instrucciones Son tan solo 8 instrucciones, y cada una consta de un carácter. No se puede poner otros caracteres más que esos… Estos son algunos enlaces de interés acerca del Brainfuck:

• Intérprete de Brainfuck con un depurador integrado (EDI) para Windows
• Brian Raiter, Muppetlabs. Brainfuck: Un lenguaje de programación Turing completo de ocho instrucciones. Este sitio incluye un quine de Brainfuck.
• Panu Kalliokoski. El Archivo de Brainfuck tiene muchos programas de Brainfuck, quines, y implementaciones.
• Brainfucked compilador de Brainfuck para Windows/DOS.
• Frans Faase. BF es Turing completo
• Daniel Cristofani. Alguna información de Brainfuck
• Brainfuck.ca Intérpretes y convertidores de Brainfuck autorizado con la GPL
• Un intérprete y compilador de Brainfuck para Windows
• Brainfuck.net
• Also Written In Brainfuck (awib) es un compilador de Brainfuck escrito en Brainfuck para Linux de i386.
• Robert Östling. Computadora de Brainfuck.
• Clifford Wolf. El UCP de Brainfuck y otros proyectos relacionados con Brainfuck
• Un tutorial de Brainfuck en inglés y francés.
• Jeffry Johnston. Programas de BF, incluyendo un compilador de Basic y un ensamblador

Los enlaces fueron citados de la lista de enlaces externos de un artículo en la Wikipedia. Por lo tanto el contenido está disponible bajo los términos de la Licencia de documentación libre de GNU.

Tomcat es el ervidor Web más utilizado a la hora de trabajar con Java en entrornos web; Tomcat es una implementación completamente funcional de los estándares de JSP y Servlets. Tomcat también puede especificarse como el manejador de las peticiones de JSP y servlets recibidas por servidores Web populares, como el servidor Apache HTTP de la Fundación de software de Apache o el servidor Microsoft Internet Information Server (IIS). Tomcat está integrado en la implementación de referencia Java 2 Enterprise Edition (J2EE) de Sun Microsystems.

Puedes descargar la última versión del Tomcat de:

http://jakarta.apache.org/site/binindex.cgi
en donde hay una variedad de archivos comprimidos. Allí puedes encontrar los instaladores para diversos sistemas operativos. Para Windows existe un instalador típico (un *exe), y para Linux puedes descargar los tar y tar comprimidos.

Puedes ver también: Instalación del Apache Tomcat en Linux y Windows

Más información en:

• Wikipedia
• Java en Castellano
• Bulma
• Página oficial
• Página Jakarta