JDBC es una API de Java que permite ejecutar operaciones sobre bases de datos de forma independiente al sistema operativo o base de datos utilizando SQL. Proporciona interfaces y métodos para gestionar conexiones a bases de datos específicas. Los usuarios pueden acceder a las bases de datos estableciendo conexiones y especificando la ubicación y parámetros de conexión.

1. Java Database Connectivity
Más conocida por sus siglas JDBC, es una API que permite la ejecución de operaciones sobre
bases de datos desde el lenguaje de programación Java, independientemente del sistema
operativo donde se ejecute o de la base de datos a la cual se accede, utilizando el dialecto SQL
del modelo de base de datos que se utilice.
El API JDBC se presenta como una colección de interfaces Java y métodos de gestión de
manejadores de conexión hacia cada modelo específico de base de datos. Un manejador de
conexiones hacia un modelo de base de datos en particular es un conjunto de clases que
implementan las interfaces Java y que utilizan los métodos de registro para declarar los tipos de
localizadores a base de datos (URL) que pueden manejar. Para utilizar una base de datos
particular, el usuario ejecuta su programa junto con la biblioteca de conexión apropiada al
modelo de su base de datos, y accede a ella estableciendo una conexión, para ello provee el
localizador a la base de datos y los parámetros de conexión específicos. A partir de allí puede
realizar con cualquier tipo de tareas con la base de datos a las que tenga permiso: consulta,
actualización, creación, modificación y borrado de tablas, ejecución de procedimientos
almacenados en la base de datos, etc.
Open DataBase Connectivity (ODBC)
Es un estándar de acceso a Bases de datos desarrollado por SQL Access Group en 1992, el
objetivo de ODBC es hacer posible el acceder a cualquier dato desde cualquier aplicación, sin
importar qué Sistema Gestor de Bases de Datos (DBMS por sus siglas en inglés) almacene los
datos, ODBC logra esto al insertar una capa intermedia ( CLI) denominada nivel de Interfaz de
Cliente SQL, entre la aplicación y el DBMS, el propósito de esta capa es traducir las consultas
de datos de la aplicación en comandos que el DBMS entienda. Para que esto funcione tanto la
aplicación como el DBMS deben ser compatibles con ODBC, esto es que la aplicación debe ser
capaz de producir comandos ODBC y el DBMS debe ser capaz de responder a ellos. Desde la
versión 2.0 el estandar soporta SAG y SQL.
El software funciona de dos modos, con un software manejador en el cliente, o una filosofia
cliente-servidor. En el primero modo, el driver interpreta las conexiones y llamadas SQL y las
traduce desde el API ODBC hacia el DBMS. En el segundo modo para conectarse a la Base de
Datos se crea una DSN dentro del ODBC que define los parámetros, ruta y características de la
conexión según los datos que solicite el fabricante.
JDBC es un derivado inspirado en el mismo, el acrónimo de Java Database Connectivity, un
API que permite la ejecución de operaciones sobre bases de datos desde el lenguaje de
programación Java independientemente del sistema operativo donde se ejecute o de la base de
datos a la cual se accede utilizando el dialecto SQL del modelo de base de datos que se utilice.
RMI (Java Remote Method Invocation)
Es un mecanismo ofrecido por Java para invocar un método de manera remota. Forma parte del
entorno estándar de ejecución de Java y proporciona un mecanismo simple para la
comunicación de servidores en aplicaciones distribuidas basadas exclusivamente en Java. Si se
requiere comunicación entre otras tecnologías debe utilizarse CORBA o SOAP en lugar de
RMI.
RMI se caracteriza por la facilidad de su uso en la programación por estar específicamente
diseñado para Java; proporciona paso de objetos por referencia (no permitido por SOAP),
recolección de basura distribuida (Garbage Collector distribuido) y paso de tipos arbitrarios
(funcionalidad no provista por CORBA).
A través de RMI, un programa Java puede exportar un objeto, con lo que dicho objeto estará
accesible a través de la red y el programa permanece a la espera de peticiones en un puerto TCP.
A partir de ese momento, un cliente puede conectarse e invocar los métodos proporcionados por
el objeto.
La invocación se compone de los siguientes pasos:

2. Encapsulado (marshalling) de los parámetros (utilizando la funcionalidad de serialización de
Java).
Invocación del método (del cliente sobre el servidor). El invocador se queda esperando una
respuesta.
Al terminar la ejecución, el servidor serializa el valor de retorno (si lo hay) y lo envía al cliente.
El código cliente recibe la respuesta y continúa como si la invocación hubiera sido local.
LAMP
El acrónimo 'LAMP' se refiere a un conjunto de subsistemas de software necesarios para
alcanzar una solución global, en este caso configurar sitios web o servidores dinámicos con un
esfuerzo reducido.
En las tecnologías LAMP esto se consigue mediante la unión de las siguientes tecnologías:
Linux, el sistema operativo; En algunos casos también se refiere a LDAP.
Apache, el servidor web;
MySQL, el gestor de bases de datos;
Perl, PHP, o Python, los lenguajes de programación.
La combinación de estas tecnologías es usada primariamente para definir la infraestructura de
un servidor web, utilizando un paradigma de programación para el desarrollo.
CLIENTE PESADO
Se denomina cliente pesado al programa "cliente" de una arquitectura cliente-servidor cuando la
mayor carga de cómputo está desplazada hacia la computadora que ejecuta dicho programa.
También se conoce como cliente grueso (anteriormente se conocia como cliente rico pero esta
acepción ya está en desuso).
Un cliente pesado es la antítesis de un cliente liviano (también denominado cliente ligero).
CLIENTE LIVIANO
Un cliente liviano o cliente ligero (thin client o slim client en inglés) es una computadora cliente
o un software de cliente en una arquitectura de red cliente-servidor que depende primariamente
del servidor central para las tareas de procesamiento, y principalmente se enfoca en transportar
la entrada y la salida entre el usuario y el servidor remoto. En contraste, un cliente pesado hace
tanto procesamiento como sea posible y pasa solamente los datos para las comunicaciones y el
almacenamiento al servidor.
Muchos dispositivos de cliente liviano corrían solamente navegadores web o programas de
escritorio remoto, lo que significaba que todo el procesamiento significativo ocurría en el
servidor. Sin embargo, dispositivos recientes mercadeados como clientes livianos pueden correr
sistemas operativos completos tales como GNU/Linux Debian, calificándolos como nodos sin
disco o clientes híbridos. Algunos clientes livianos también son llamados "terminales de
acceso".
Por consecuencia, el término "cliente liviano", en términos de hardware, ha venido abarcar
cualquier dispositivo mercadeado o usado como un cliente liviano en la definición original,
incluso si sus capacidades reales son mucho mayores. El término también es a veces usado en
un sentido incluso más amplio que incluye nodos sin disco.
GRID COMPUTIN
La computación grid es una tecnología innovadora que permite utilizar de forma coordinada
todo tipo de recursos (entre ellos cómputo, almacenamiento y aplicaciones específicas) que no
están sujetos a un control centralizado. En este sentido es una nueva forma de computación
distribuida, en la cual los recursos pueden ser heterogéneos (diferentes arquitecturas,
supercomputadores, clusters...) y se encuentran conectados mediante redes de área extensa (por
ejemplo Internet). Desarrollado en ámbitos científicos a principios de los años 1990, su entrada
al mercado comercial siguiendo la idea de la llamada Utility computing supone una revolución
que dará mucho que hablar.
El término grid se refiere a una infraestructura que permite la integración y el uso colectivo de
ordenadores de alto rendimiento, redes y bases de datos que son propiedad y están

3. administrados por diferentes instituciones. Puesto que la colaboración entre instituciones
envuelve un intercambio de datos, o de tiempo de computación, el propósito del grid es facilitar
la integración de recursos computacionales. Universidades, laboratorios de investigación o
empresas se asocian para formar grid para lo cual utilizan algún tipo de software que
implemente este concepto.
AJP
El Apache JServ Protocol (AJP) es, en el contexto de la World Wide Web un protocolo binario
que permite enviar solicitudes desde un servidor web a un servidor de aplicaciones que se
encuentra detrás del servidor web. También permite monitoreo dado que el servidor web puede
enviar un ping al servidor de aplicación.
El protocolo AJP suele utilizarse en un despliegue de balance de carga en el que uno o más
servidores web front-end envían solicitudes a uno o varios servidores de aplicaciones. Las
sesiones se redirigen al servidor de aplicaciones correcto utilizando un mecanismo de
enrutación en el que cada servidor de aplicaciones recibe un nombre (denominado ruta).
AJP funciona en Servidor HTTP Apache 1.x utilizando el plugin mod jk y en el Apache 2.2
utilizando los módulos proxy ajp, proxy y proxy balancer. El servidor Apache está programado
en C y el servidor de aplicaciones normalmente en Java.
PATRON OBSERVADOR
El patrón Observador (en inglés: Observer) también conocido como "spider" define una
dependencia del tipo uno-a-muchos entre objetos, de manera que cuando uno de los objetos
cambia su estado, el observador se encarga de notificar este cambio a todos los otros
dependientes.
El objetivo de este patrón es desacoplar la clase de los objetos clientes del objeto, aumentando
la modularidad del lenguaje, así como evitar bucles de actualización (espera activa o polling).
Este patrón también se conoce como el patrón de publicación-inscripción o modelo-patrón.
Estos nombres sugieren las ideas básicas del patrón, que son bien sencillas: el objeto de datos,
llamémoslo "Sujeto" a partir de ahora, contiene atributos mediante los cuales cualquier objeto
observador o vista se puede suscribir a él pasándole una referencia a sí mismo. El Sujeto
mantiene así una lista de las referencias a sus observadores.
Los observadores a su vez están obligados a implementar unos métodos determinados mediante
los cuales el Sujeto es capaz de notificar a sus observadores "suscritos" los cambios que sufre
para que todos ellos tengan la oportunidad de refrescar el contenido representado. De manera
que cuando se produce un cambio en el Sujeto, ejecutado, por ejemplo, por alguno de los
observadores, el objeto de datos puede recorrer la lista de observadores avisando a cada uno.
PATRON SINGLETON
El patrón de diseño singleton (instancia única) está diseñado para restringir la creación de
objetos pertenecientes a una clase o el valor de un tipo a un único objeto.
Su intención consiste en garantizar que una clase sólo tenga una instancia y proporcionar un
punto de acceso global a ella.
El patrón singleton se implementa creando en nuestra clase un método que crea una instancia
del objeto sólo si todavía no existe alguna. Para asegurar que la clase no puede ser instanciada
nuevamente se regula el alcance del constructor (con atributos como protegido o privado).
La instrumentación del patrón puede ser delicada en programas con múltiples hilos de
ejecución. Si dos hilos de ejecución intentan crear la instancia al mismo tiempo y esta no existe
todavía, sólo uno de ellos debe lograr crear el objeto. La solución clásica para este problema es
utilizar exclusión mutua en el método de creación de la clase que implementa el patrón.
TCP

4. Transmission Control Protocol (en español Protocolo de Control de Transmisión) o TCP, es uno
de los protocolos fundamentales en Internet. Fue creado entre los años 1973 y 1974 por Vint
Cerf y Robert Kahn.
Muchos programas dentro de una red de datos compuesta por computadoras pueden usar TCP
para crear conexiones entre ellos a través de las cuales puede enviarse un flujo de datos. El
protocolo garantiza que los datos serán entregados en su destino sin errores y en el mismo orden
en que se transmitieron. También proporciona un mecanismo para distinguir distintas
aplicaciones dentro de una misma máquina, a través del concepto de puerto.
TCP da soporte a muchas de las aplicaciones más populares de Internet (navegadores,
intercambio de ficheros, clientes ftp, ...) y protocolos de aplicación HTTP, SMTP, SSH y FTP.
UDP
User Datagram Protocol (UDP) es un protocolo del nivel de transporte basado en el intercambio
de datagramas (Paquete de datos). Permite el envío de datagramas a través de la red sin que se
haya establecido previamente una conexión, ya que el propio datagrama incorpora suficiente
información de direccionamiento en su cabecera. Tampoco tiene confirmación ni control de
flujo, por lo que los paquetes pueden adelantarse unos a otros; y tampoco se sabe si ha llegado
correctamente, ya que no hay confirmación de entrega o recepción. Su uso principal es para
protocolos como DHCP, BOOTP, DNS y demás protocolos en los que el intercambio de
paquetes de la conexión/desconexión son mayores, o no son rentables con respecto a la
información transmitida, así como para la transmisión de audio y vídeo en tiempo real, donde no
es posible realizar retransmisiones por los estrictos requisitos de retardo que se tiene en estos
casos.