Merge branch 'main' of https://git.tatvil.es/tatiana/taiage-spring
This commit is contained in:
Tatiana Villa Ema
commit
b3f8ff195c
|
|
@ -15,7 +15,8 @@ set -euo pipefail
|
||||||
|
|
||||||
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
|
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
|
||||||
PROJECT_DIR="$(dirname "$SCRIPT_DIR")"
|
PROJECT_DIR="$(dirname "$SCRIPT_DIR")"
|
||||||
PYTHON="${PYTHON:-python3}"
|
PYTHON="/home/tatiana/desarrollo/html/taiage-spring/.venv/bin/python3"
|
||||||
|
#PYTHON="${PYTHON:-python3}"
|
||||||
LOG_PREFIX="[$(date '+%Y-%m-%d %H:%M:%S')]"
|
LOG_PREFIX="[$(date '+%Y-%m-%d %H:%M:%S')]"
|
||||||
|
|
||||||
echo "$LOG_PREFIX ── sync_audios.sh iniciado ──────────────────────────"
|
echo "$LOG_PREFIX ── sync_audios.sh iniciado ──────────────────────────"
|
||||||
|
|
|
||||||
|
|
@ -15,6 +15,12 @@ spring.jpa.open-in-view=false
|
||||||
# ── Thymeleaf ───────────────────────────────────────────────────
|
# ── Thymeleaf ───────────────────────────────────────────────────
|
||||||
spring.thymeleaf.cache=false
|
spring.thymeleaf.cache=false
|
||||||
|
|
||||||
|
# ── Recursos estáticos ──────────────────────────────────────────
|
||||||
|
# Los audios se generan en el filesystem (no van en el JAR), se sirven desde ahí.
|
||||||
|
# La ruta "file:src/main/resources/static/" permite que el cron actualice mp3 sin
|
||||||
|
# necesidad de recompilar. "classpath:/static/" mantiene el resto de estáticos (css, js…)
|
||||||
|
spring.web.resources.static-locations=file:src/main/resources/static/,classpath:/static/
|
||||||
|
|
||||||
# ── Stripe ──────────────────────────────────────────────────────
|
# ── Stripe ──────────────────────────────────────────────────────
|
||||||
stripe.secret-key=${STRIPE_SECRET_KEY}
|
stripe.secret-key=${STRIPE_SECRET_KEY}
|
||||||
stripe.webhook-secret=${STRIPE_WEBHOOK_SECRET}
|
stripe.webhook-secret=${STRIPE_WEBHOOK_SECRET}
|
||||||
|
|
|
||||||
|
|
@ -75,6 +75,119 @@ h1 { font-size: 18pt; text-align: center; margin-bottom: 0.2em; color: var(--acc
|
||||||
.leyenda-item { display: flex; align-items: center; gap: 5px; }
|
.leyenda-item { display: flex; align-items: center; gap: 5px; }
|
||||||
.leyenda-color { width: 14px; height: 14px; border: 1px solid var(--border); flex-shrink: 0; }
|
.leyenda-color { width: 14px; height: 14px; border: 1px solid var(--border); flex-shrink: 0; }
|
||||||
|
|
||||||
|
/* ── Hoy ────────────────────────────────────────────────── */
|
||||||
|
.dia.hoy {
|
||||||
|
border-color: var(--accent-2) !important;
|
||||||
|
box-shadow: 0 0 0 2px rgba(78,201,176,.25);
|
||||||
|
}
|
||||||
|
.dia.hoy > .num { color: var(--accent-2) !important; }
|
||||||
|
.hoy-label {
|
||||||
|
display: inline-block;
|
||||||
|
font-size: 7pt; font-weight: bold; letter-spacing: .06em;
|
||||||
|
color: var(--accent-2);
|
||||||
|
background: rgba(78,201,176,.12);
|
||||||
|
border: 1px solid var(--accent-2);
|
||||||
|
border-radius: 3px;
|
||||||
|
padding: 0 4px;
|
||||||
|
margin-left: 4px; margin-bottom: 4px;
|
||||||
|
vertical-align: middle;
|
||||||
|
}
|
||||||
|
|
||||||
|
/* ── Filas de tema ──────────────────────────────────────── */
|
||||||
|
.tema-row {
|
||||||
|
display: flex;
|
||||||
|
align-items: flex-start;
|
||||||
|
gap: 2px;
|
||||||
|
margin-bottom: 2px;
|
||||||
|
}
|
||||||
|
.tema-row .tema-btn { flex: 1; margin-bottom: 0; }
|
||||||
|
|
||||||
|
/* ── Botón check ────────────────────────────────────────── */
|
||||||
|
.check-btn {
|
||||||
|
flex-shrink: 0;
|
||||||
|
width: 15px; height: 15px;
|
||||||
|
border: 1px solid var(--border);
|
||||||
|
background: var(--bg);
|
||||||
|
color: var(--text-muted);
|
||||||
|
cursor: pointer;
|
||||||
|
font-size: 8pt; line-height: 1;
|
||||||
|
border-radius: 3px;
|
||||||
|
display: flex; align-items: center; justify-content: center;
|
||||||
|
padding: 0; margin-top: 1px;
|
||||||
|
transition: background .1s, color .1s, border-color .1s;
|
||||||
|
}
|
||||||
|
.check-btn:hover { border-color: var(--accent-2); color: var(--accent-2); }
|
||||||
|
.check-btn.checked { background: var(--accent-2); color: #111; border-color: var(--accent-2); }
|
||||||
|
|
||||||
|
/* ── Botón mover ────────────────────────────────────────── */
|
||||||
|
.move-btn {
|
||||||
|
flex-shrink: 0;
|
||||||
|
width: 14px; height: 14px;
|
||||||
|
border: none; background: transparent;
|
||||||
|
color: var(--text-muted); cursor: pointer;
|
||||||
|
font-size: 9pt; line-height: 1;
|
||||||
|
padding: 0; margin-top: 1px;
|
||||||
|
opacity: 0; transition: opacity .15s;
|
||||||
|
}
|
||||||
|
.tema-row:hover .move-btn { opacity: 1; }
|
||||||
|
.move-btn:hover { color: var(--warning); }
|
||||||
|
|
||||||
|
/* ── Completado ─────────────────────────────────────────── */
|
||||||
|
.tema-btn.completado {
|
||||||
|
text-decoration: line-through;
|
||||||
|
color: var(--text-muted) !important;
|
||||||
|
opacity: .45;
|
||||||
|
}
|
||||||
|
|
||||||
|
/* ── Atrasado ───────────────────────────────────────────── */
|
||||||
|
.tema-row.atrasado .tema-btn { color: var(--error) !important; }
|
||||||
|
.tema-row.atrasado .tema-btn::before { content: '⚠ '; }
|
||||||
|
.overdue-badge {
|
||||||
|
display: inline-block;
|
||||||
|
font-size: 7pt; font-weight: bold;
|
||||||
|
background: var(--error); color: #fff;
|
||||||
|
padding: 1px 6px; border-radius: 8px;
|
||||||
|
margin-bottom: 4px; margin-top: 1px;
|
||||||
|
-webkit-print-color-adjust: exact; print-color-adjust: exact;
|
||||||
|
}
|
||||||
|
|
||||||
|
/* ── Picker de día ──────────────────────────────────────── */
|
||||||
|
.move-picker {
|
||||||
|
position: absolute; right: 0; top: 100%;
|
||||||
|
z-index: 200;
|
||||||
|
background: var(--bg-alt);
|
||||||
|
border: 1px solid var(--border);
|
||||||
|
border-radius: 4px;
|
||||||
|
padding: 5px;
|
||||||
|
display: flex; flex-direction: column; gap: 2px;
|
||||||
|
min-width: 130px;
|
||||||
|
box-shadow: 0 4px 14px rgba(0,0,0,.55);
|
||||||
|
}
|
||||||
|
.mp-label {
|
||||||
|
font-size: 8pt; color: var(--text-muted);
|
||||||
|
padding: 0 3px 3px; border-bottom: 1px solid var(--border);
|
||||||
|
margin-bottom: 2px;
|
||||||
|
}
|
||||||
|
.move-picker button {
|
||||||
|
background: var(--bg); border: 1px solid var(--border);
|
||||||
|
color: var(--text); font-size: 8pt; padding: 3px 8px;
|
||||||
|
text-align: left; cursor: pointer; border-radius: 3px;
|
||||||
|
font-family: inherit;
|
||||||
|
}
|
||||||
|
.move-picker button:hover { background: var(--bg-hover); color: var(--accent-2); }
|
||||||
|
.move-picker .mp-today { border-color: var(--accent-2); color: var(--accent-2); }
|
||||||
|
.move-picker .mp-reset { color: var(--text-muted); font-size: 7.5pt; margin-top: 2px; }
|
||||||
|
.move-picker .mp-reset:hover { color: var(--error); }
|
||||||
|
|
||||||
|
/* ── Botón reset planning ───────────────────────────────── */
|
||||||
|
.btn-reset-planning {
|
||||||
|
background: none; border: none; cursor: pointer;
|
||||||
|
color: var(--text-muted); font-size: 10pt;
|
||||||
|
padding: 0 4px; vertical-align: middle; line-height: 1;
|
||||||
|
margin-left: 6px; transition: color .15s;
|
||||||
|
}
|
||||||
|
.btn-reset-planning:hover { color: var(--warning); }
|
||||||
|
|
||||||
@media print {
|
@media print {
|
||||||
body { background: #fff; color: #111; padding: 0.8cm 1cm; }
|
body { background: #fff; color: #111; padding: 0.8cm 1cm; }
|
||||||
.dia { background: #fff !important; border-color: #ccc !important; }
|
.dia { background: #fff !important; border-color: #ccc !important; }
|
||||||
|
|
@ -84,4 +197,7 @@ h1 { font-size: 18pt; text-align: center; margin-bottom: 0.2em; color: var(--acc
|
||||||
.tema-btn { color: #111; }
|
.tema-btn { color: #111; }
|
||||||
.semana { page-break-after: always; break-after: page; }
|
.semana { page-break-after: always; break-after: page; }
|
||||||
.semana:last-of-type { page-break-after: auto; }
|
.semana:last-of-type { page-break-after: auto; }
|
||||||
|
.check-btn, .move-btn, .move-picker, .overdue-badge,
|
||||||
|
.hoy-label, .btn-reset-planning { display: none !important; }
|
||||||
|
.tema-btn.completado { text-decoration: none; opacity: 1; color: inherit !important; }
|
||||||
}
|
}
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,192 @@
|
||||||
|
'use strict';
|
||||||
|
(function () {
|
||||||
|
|
||||||
|
/* ── Configuración ─────────────────────────────────────── */
|
||||||
|
const YEAR = 2026;
|
||||||
|
const MONTH = 4; // Mayo (0-based)
|
||||||
|
const USERNAME = document.querySelector('.user-email')?.textContent.trim() || 'guest';
|
||||||
|
const KEY = `planning_${YEAR}_${USERNAME}`;
|
||||||
|
|
||||||
|
/* ── Persistencia ──────────────────────────────────────── */
|
||||||
|
function load() {
|
||||||
|
try {
|
||||||
|
const s = JSON.parse(localStorage.getItem(KEY));
|
||||||
|
return { completed: s?.completed || [], moved: s?.moved || {} };
|
||||||
|
} catch { return { completed: [], moved: {} }; }
|
||||||
|
}
|
||||||
|
function save(s) { localStorage.setItem(KEY, JSON.stringify(s)); }
|
||||||
|
|
||||||
|
/* ── Fecha actual ──────────────────────────────────────── */
|
||||||
|
const now = new Date();
|
||||||
|
const todayDay = (now.getFullYear() === YEAR && now.getMonth() === MONTH)
|
||||||
|
? now.getDate() : null;
|
||||||
|
|
||||||
|
/* ── Mapa de días ──────────────────────────────────────── */
|
||||||
|
// dayMap: { 8: diaDom, 9: diaDom, … }
|
||||||
|
const dayMap = {};
|
||||||
|
document.querySelectorAll('.dia').forEach(dia => {
|
||||||
|
const numEl = dia.querySelector(':scope > .num');
|
||||||
|
if (!numEl) return;
|
||||||
|
const n = parseInt(numEl.textContent.trim(), 10);
|
||||||
|
if (!isNaN(n)) dayMap[n] = dia;
|
||||||
|
});
|
||||||
|
|
||||||
|
/* ── Marcar hoy ────────────────────────────────────────── */
|
||||||
|
if (todayDay && dayMap[todayDay]) {
|
||||||
|
const d = dayMap[todayDay];
|
||||||
|
d.classList.add('hoy');
|
||||||
|
const numEl = d.querySelector(':scope > .num');
|
||||||
|
if (numEl) numEl.insertAdjacentHTML('afterend', '<span class="hoy-label">HOY</span>');
|
||||||
|
}
|
||||||
|
|
||||||
|
/* ── Envolver .tema-btn en .tema-row ───────────────────── */
|
||||||
|
document.querySelectorAll('.tema-btn').forEach(btn => {
|
||||||
|
const row = document.createElement('div');
|
||||||
|
row.className = 'tema-row';
|
||||||
|
btn.before(row);
|
||||||
|
row.appendChild(btn);
|
||||||
|
});
|
||||||
|
|
||||||
|
/* ── Aplicar temas movidos al cargar ───────────────────── */
|
||||||
|
const state = load();
|
||||||
|
Object.entries(state.moved).forEach(([href, dayNum]) => {
|
||||||
|
const btn = [...document.querySelectorAll('.tema-btn')]
|
||||||
|
.find(b => b.getAttribute('href') === href);
|
||||||
|
const row = btn?.closest('.tema-row');
|
||||||
|
const contenido = dayMap[Number(dayNum)]?.querySelector('.contenido');
|
||||||
|
if (row && contenido && !contenido.contains(row)) {
|
||||||
|
contenido.appendChild(row);
|
||||||
|
}
|
||||||
|
});
|
||||||
|
|
||||||
|
/* ── Añadir controles a cada fila ──────────────────────── */
|
||||||
|
const completedSet = new Set(state.completed);
|
||||||
|
|
||||||
|
document.querySelectorAll('.tema-row').forEach(row => {
|
||||||
|
const btn = row.querySelector('.tema-btn');
|
||||||
|
if (!btn) return;
|
||||||
|
const id = btn.getAttribute('href');
|
||||||
|
const done = completedSet.has(id);
|
||||||
|
|
||||||
|
// ── Botón ✓ / ○ ──
|
||||||
|
const chk = document.createElement('button');
|
||||||
|
chk.className = 'check-btn' + (done ? ' checked' : '');
|
||||||
|
chk.title = done ? 'Marcar como pendiente' : 'Marcar como hecho';
|
||||||
|
chk.textContent = done ? '✓' : '○';
|
||||||
|
row.insertBefore(chk, btn);
|
||||||
|
if (done) btn.classList.add('completado');
|
||||||
|
|
||||||
|
chk.addEventListener('click', e => {
|
||||||
|
e.preventDefault();
|
||||||
|
const s = load();
|
||||||
|
const set = new Set(s.completed);
|
||||||
|
const nowDone = !set.has(id);
|
||||||
|
nowDone ? set.add(id) : set.delete(id);
|
||||||
|
s.completed = [...set];
|
||||||
|
save(s);
|
||||||
|
chk.classList.toggle('checked', nowDone);
|
||||||
|
chk.textContent = nowDone ? '✓' : '○';
|
||||||
|
btn.classList.toggle('completado', nowDone);
|
||||||
|
updateOverdue();
|
||||||
|
});
|
||||||
|
|
||||||
|
// ── Botón mover ──
|
||||||
|
const mv = document.createElement('button');
|
||||||
|
mv.className = 'move-btn';
|
||||||
|
mv.title = 'Mover a otro día';
|
||||||
|
mv.textContent = '⇌';
|
||||||
|
row.appendChild(mv);
|
||||||
|
mv.addEventListener('click', e => { e.preventDefault(); showPicker(row, id); });
|
||||||
|
});
|
||||||
|
|
||||||
|
/* ── Picker de día ─────────────────────────────────────── */
|
||||||
|
function showPicker(row, id) {
|
||||||
|
document.querySelectorAll('.move-picker').forEach(p => p.remove());
|
||||||
|
const picker = document.createElement('div');
|
||||||
|
picker.className = 'move-picker';
|
||||||
|
picker.insertAdjacentHTML('afterbegin', '<div class="mp-label">Mover a:</div>');
|
||||||
|
|
||||||
|
const days = Object.keys(dayMap).map(Number)
|
||||||
|
.filter(d => !dayMap[d].classList.contains('vacio')
|
||||||
|
&& !dayMap[d].classList.contains('examen'))
|
||||||
|
.sort((a, b) => a - b);
|
||||||
|
|
||||||
|
days.forEach(d => {
|
||||||
|
const b = document.createElement('button');
|
||||||
|
b.textContent = `Día ${d}` + (d === todayDay ? ' · hoy' : '');
|
||||||
|
if (d === todayDay) b.classList.add('mp-today');
|
||||||
|
b.addEventListener('click', e => {
|
||||||
|
e.stopPropagation();
|
||||||
|
const s = load();
|
||||||
|
s.moved[id] = d;
|
||||||
|
save(s);
|
||||||
|
const c = dayMap[d]?.querySelector('.contenido');
|
||||||
|
if (c && !c.contains(row)) c.appendChild(row);
|
||||||
|
picker.remove();
|
||||||
|
updateOverdue();
|
||||||
|
});
|
||||||
|
picker.appendChild(b);
|
||||||
|
});
|
||||||
|
|
||||||
|
const rst = document.createElement('button');
|
||||||
|
rst.className = 'mp-reset';
|
||||||
|
rst.textContent = '↺ Restaurar original';
|
||||||
|
rst.addEventListener('click', e => {
|
||||||
|
e.stopPropagation();
|
||||||
|
const s = load();
|
||||||
|
delete s.moved[id];
|
||||||
|
save(s);
|
||||||
|
location.reload();
|
||||||
|
});
|
||||||
|
picker.appendChild(rst);
|
||||||
|
|
||||||
|
row.style.position = 'relative';
|
||||||
|
row.appendChild(picker);
|
||||||
|
|
||||||
|
setTimeout(() => {
|
||||||
|
document.addEventListener('click', function h(e) {
|
||||||
|
if (!picker.contains(e.target)) {
|
||||||
|
picker.remove();
|
||||||
|
document.removeEventListener('click', h);
|
||||||
|
}
|
||||||
|
});
|
||||||
|
}, 0);
|
||||||
|
}
|
||||||
|
|
||||||
|
/* ── Indicadores de atrasados ──────────────────────────── */
|
||||||
|
function updateOverdue() {
|
||||||
|
const s = load();
|
||||||
|
const done = new Set(s.completed);
|
||||||
|
Object.entries(dayMap).forEach(([dayStr, dia]) => {
|
||||||
|
const d = Number(dayStr);
|
||||||
|
dia.querySelectorAll('.tema-row').forEach(row => {
|
||||||
|
const id = row.querySelector('.tema-btn')?.getAttribute('href');
|
||||||
|
const overdue = !!id && todayDay != null && d < todayDay && !done.has(id);
|
||||||
|
row.classList.toggle('atrasado', overdue);
|
||||||
|
});
|
||||||
|
const n = dia.querySelectorAll('.tema-row.atrasado').length;
|
||||||
|
let badge = dia.querySelector('.overdue-badge');
|
||||||
|
if (n > 0) {
|
||||||
|
if (!badge) {
|
||||||
|
badge = document.createElement('span');
|
||||||
|
badge.className = 'overdue-badge';
|
||||||
|
dia.querySelector(':scope > .num')?.insertAdjacentElement('afterend', badge);
|
||||||
|
}
|
||||||
|
badge.textContent = `${n} atrasado${n > 1 ? 's' : ''}`;
|
||||||
|
} else if (badge) {
|
||||||
|
badge.remove();
|
||||||
|
}
|
||||||
|
});
|
||||||
|
}
|
||||||
|
|
||||||
|
updateOverdue();
|
||||||
|
|
||||||
|
/* ── Reiniciar progreso ────────────────────────────────── */
|
||||||
|
document.getElementById('btn-reset-planning')?.addEventListener('click', () => {
|
||||||
|
if (confirm('¿Reiniciar todo el progreso guardado?')) {
|
||||||
|
localStorage.removeItem(KEY);
|
||||||
|
location.reload();
|
||||||
|
}
|
||||||
|
});
|
||||||
|
|
||||||
|
})();
|
||||||
|
|
@ -9,18 +9,21 @@
|
||||||
→ Lenguaje estándar para interactuar con bases de datos relacionales.
|
→ Lenguaje estándar para interactuar con bases de datos relacionales.
|
||||||
|
|
||||||
**Sublenguajes de SQL**
|
**Sublenguajes de SQL**
|
||||||
- DDL – Definición (CREATE, ALTER, DROP)
|
| Nombre | Tipo | COMANDOS | DESCRIPCIÓN |
|
||||||
- DML – Manipulación (SELECT, INSERT, UPDATE, DELETE)
|
| :--- | :--- | :--- | :--- |
|
||||||
- DCL – Control (GRANT, REVOKE)
|
| **DDL** | Definición | CREATE<br>ALTER<br>DROP | Permite crear y modificar la estructura de la base de datos |
|
||||||
- TCL – Transacciones (COMMIT, ROLLBACK, SAVEPOINT)
|
| **DML** | Manipulación | SELECT<br>INSERT<br>UPDATE<br>DELETE | Permite gestionar los datos contenidos en las tablas |
|
||||||
|
| **DCL** | Control | GRANT<br>REVOKE | Controla el acceso y permisos de los usuarios |
|
||||||
|
| **TCL** | Transacciones | COMMIT<br>ROLLBACK<br>SAVEPOINT | Gestiona los cambios realizados por las sentencias DML |
|
||||||
|
|
||||||
**Objetos avanzados**
|
| Objeto | Definición Breve | Se ejecuta cuando... |
|
||||||
- Vistas (VIEW)
|
| :--- | :--- | :--- |
|
||||||
- Índices (INDEX)
|
| **VIEW** | Tabla virtual | Se consulta (`SELECT`) |
|
||||||
- Procedimientos almacenados
|
| **INDEX** | Optimizador de búsqueda | Se busca o filtra información |
|
||||||
- Funciones de usuario
|
| **PROCEDURE** | Bloque de código reutilizable | Se llama explícitamente (`CALL`) |
|
||||||
- Disparadores (TRIGGER)
|
| **FUNCTION** | Cálculo que devuelve un valor | Se usa en una expresión o `SELECT` |
|
||||||
- Eventos
|
| **TRIGGER** | Reacción automática | Se modifica una tabla<br>(`INSERT`, `UPDATE`, `DELETE`) |
|
||||||
|
| **EVENT** | Tarea programada | Llega una fecha o<br>intervalo de tiempo |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,28 +1,497 @@
|
||||||
|
# Bloque 3 · Tema 4
|
||||||
# Diseño y programación orientada a objetos. Elementos y componentes software: objetos, clases, herencia, métodos, sobrecarga. Ventajas e inconvenientes. Patrones de diseño y lenguaje de modelado unificado (UML).
|
# Diseño y programación orientada a objetos. Elementos y componentes software: objetos, clases, herencia, métodos, sobrecarga. Ventajas e inconvenientes. Patrones de diseño y lenguaje de modelado unificado (UML).
|
||||||
|
|
||||||
## POO
|
---
|
||||||
-Herencia
|
|
||||||
-Polimorfismo
|
|
||||||
-Acoplamiento
|
|
||||||
|
|
||||||
## Patrones
|
# Esquema resumen
|
||||||
- MVC
|
|
||||||
- GRASP
|
**POO — Pilares fundamentales**
|
||||||
- Controller
|
- Abstracción
|
||||||
- Low Coupling (bajo acoplamiento)
|
- Encapsulación
|
||||||
- High Cohesion (Alta cohesión)
|
- Herencia
|
||||||
- Polymorphism (Polimorfismo)
|
- Polimorfismo
|
||||||
|
|
||||||
## UML (Lenguaje de modelado unificado)
|
**Elementos principales**
|
||||||
- Diagrama de clase
|
|
||||||
- Diagrama de objetos (instancia de una clase)
|
| Elemento | Descripción |
|
||||||
- Diagrama de componentes (servicio web, ejecutable, libreria, etc)
|
|---|---|
|
||||||
- Diagrama de paquetes
|
| Clase | Plantilla / molde |
|
||||||
- Diagrama de despliegue
|
| Objeto | Instancia de una clase |
|
||||||
- Nodos
|
| Atributo | Variable de una clase |
|
||||||
- Artefactos (librerias, bases de datos)
|
| Método | Función de una clase |
|
||||||
- Conexiones
|
| Constructor | Inicializa el objeto al crearlo |
|
||||||
- Diagrama de casos de uso
|
| Interfaz | Contrato sin implementación |
|
||||||
- Diagrama de actividades
|
| Clase abstracta | No instanciable; puede tener métodos sin implementar |
|
||||||
- Diagrama de comunicación
|
|
||||||
- Diagrama de Gantt
|
**Relaciones entre clases**
|
||||||
|
|
||||||
|
| Relación | Tipo | Ejemplo |
|
||||||
|
|---|---|---|
|
||||||
|
| Herencia | Es-un | `Perro` es un `Animal` |
|
||||||
|
| Composición | Tiene-un (fuerte) | `Motor` forma parte de `Coche` |
|
||||||
|
| Agregación | Tiene-un (débil) | `Alumno` pertenece a `Clase` |
|
||||||
|
| Dependencia | Usa-un | `Pedido` usa `Producto` |
|
||||||
|
|
||||||
|
**Patrones de diseño (GoF)**
|
||||||
|
|
||||||
|
- Creacionales: Singleton, Factory Method, Abstract Factory, Builder, Prototype
|
||||||
|
- Estructurales: Adapter, Facade, Decorator, Composite, Proxy
|
||||||
|
- De comportamiento: Observer, Strategy, Template Method, Iterator, Command
|
||||||
|
|
||||||
|
**GRASP** — Patrones de asignación de responsabilidades:
|
||||||
|
Controller, Creator, Information Expert, Low Coupling, High Cohesion, Polymorphism, Indirection, Pure Fabrication, Protected Variations
|
||||||
|
|
||||||
|
**UML — Diagramas estructurales**
|
||||||
|
Clases, Objetos, Componentes, Paquetes, Despliegue, Compuesto
|
||||||
|
|
||||||
|
**UML — Diagramas de comportamiento**
|
||||||
|
Casos de uso, Actividades, Estados, Secuencia, Comunicación
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 1. Programación orientada a objetos
|
||||||
|
|
||||||
|
## 1.1 Concepto y origen
|
||||||
|
|
||||||
|
La **programación orientada a objetos (POO)** es un paradigma de programación que organiza el software en torno a **objetos**, que combinan datos (atributos) y comportamiento (métodos).
|
||||||
|
|
||||||
|
Surgió en los años 60 con **Simula 67** y se popularizó con **Smalltalk** en los 70. Hoy es el paradigma dominante, presente en Java, Python, C++, C#, Ruby, etc.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1.2 Pilares de la POO
|
||||||
|
|
||||||
|
### Abstracción
|
||||||
|
|
||||||
|
Consiste en representar solo las características esenciales de un objeto, ocultando los detalles internos no relevantes.
|
||||||
|
|
||||||
|
Ejemplo: al modelar un `Coche` para una app de parking, nos interesa la matrícula, la marca y el color; no el número de cilindros.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Encapsulación
|
||||||
|
|
||||||
|
Agrupa los datos y los métodos que los manejan dentro de una misma clase, y restringe el acceso directo desde el exterior.
|
||||||
|
|
||||||
|
Se implementa mediante **modificadores de acceso**:
|
||||||
|
|
||||||
|
| Modificador | Acceso |
|
||||||
|
|---|---|
|
||||||
|
| `public` | Desde cualquier clase |
|
||||||
|
| `protected` | Desde la misma clase y sus subclases |
|
||||||
|
| `private` | Solo desde la propia clase |
|
||||||
|
| (sin modificador) | Solo desde el mismo paquete (Java) |
|
||||||
|
|
||||||
|
Los atributos suelen ser `private` y se exponen con métodos `getX()` / `setX()` (getters y setters).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Herencia
|
||||||
|
|
||||||
|
Permite que una clase (**subclase** o clase hija) adquiera los atributos y métodos de otra clase (**superclase** o clase padre).
|
||||||
|
|
||||||
|
- Favorece la **reutilización de código**.
|
||||||
|
- Modela la relación **"es-un"**: un `Perro` es un `Animal`.
|
||||||
|
- En Java la herencia es **simple** (solo un padre directo). En C++ es **múltiple**.
|
||||||
|
|
||||||
|
**Sobreescritura (override)**: la subclase redefine un método heredado para adaptar su comportamiento.
|
||||||
|
|
||||||
|
```java
|
||||||
|
class Animal {
|
||||||
|
public String sonido() { return "..."; }
|
||||||
|
}
|
||||||
|
class Perro extends Animal {
|
||||||
|
@Override
|
||||||
|
public String sonido() { return "Guau"; }
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Polimorfismo
|
||||||
|
|
||||||
|
Capacidad de un mismo método o referencia de comportarse de distinta forma según el tipo real del objeto.
|
||||||
|
|
||||||
|
Tipos:
|
||||||
|
|
||||||
|
| Tipo | Mecanismo | Cuándo se resuelve |
|
||||||
|
|---|---|---|
|
||||||
|
| **Polimorfismo de subtipos** | Herencia + sobreescritura | En tiempo de ejecución (dinámico) |
|
||||||
|
| **Sobrecarga (overloading)** | Mismo nombre, distintos parámetros | En tiempo de compilación (estático) |
|
||||||
|
|
||||||
|
**Sobrecarga**: varios métodos con el mismo nombre pero diferente firma (número o tipo de parámetros).
|
||||||
|
|
||||||
|
```java
|
||||||
|
class Calculadora {
|
||||||
|
int sumar(int a, int b) { return a + b; }
|
||||||
|
double sumar(double a, double b){ return a + b; }
|
||||||
|
int sumar(int a, int b, int c) { return a + b + c; }
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1.3 Elementos de una clase
|
||||||
|
|
||||||
|
| Elemento | Descripción |
|
||||||
|
|---|---|
|
||||||
|
| **Atributo (campo)** | Variable que almacena el estado del objeto |
|
||||||
|
| **Método** | Función que define el comportamiento |
|
||||||
|
| **Constructor** | Método especial que se ejecuta al crear el objeto (`new`) |
|
||||||
|
| **Destructor** | Libera recursos al destruirse el objeto (en Java: `finalize`; en C++: `~Clase()`) |
|
||||||
|
| **Método estático** | Pertenece a la clase, no a instancias concretas |
|
||||||
|
| **Atributo estático** | Valor compartido por todas las instancias |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1.4 Clases abstractas e interfaces
|
||||||
|
|
||||||
|
**Clase abstracta**:
|
||||||
|
- No puede instanciarse directamente.
|
||||||
|
- Puede tener métodos con y sin implementación (abstractos).
|
||||||
|
- Una subclase debe implementar todos los métodos abstractos.
|
||||||
|
- En Java: `abstract class Animal { abstract void sonido(); }`
|
||||||
|
|
||||||
|
**Interfaz**:
|
||||||
|
- Define un **contrato**: lista de métodos que una clase debe implementar.
|
||||||
|
- No tiene atributos de instancia (solo constantes).
|
||||||
|
- Una clase puede implementar **varias interfaces** (solución a la falta de herencia múltiple).
|
||||||
|
- En Java: `interface Volador { void volar(); }`
|
||||||
|
|
||||||
|
| | Clase abstracta | Interfaz |
|
||||||
|
|---|---|---|
|
||||||
|
| Instanciable | No | No |
|
||||||
|
| Herencia | Simple | Múltiple |
|
||||||
|
| Implementación de métodos | Puede tenerla | Solo desde Java 8 (`default`) |
|
||||||
|
| Atributos de instancia | Sí | No |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1.5 Relaciones entre clases
|
||||||
|
|
||||||
|
| Relación | Descripción | Símbolo UML |
|
||||||
|
|---|---|---|
|
||||||
|
| **Herencia** (generalización) | La subclase extiende la superclase | Flecha con triángulo hueco |
|
||||||
|
| **Realización** | Una clase implementa una interfaz | Flecha punteada con triángulo hueco |
|
||||||
|
| **Composición** | El objeto hijo no puede existir sin el padre | Rombo relleno |
|
||||||
|
| **Agregación** | El objeto hijo puede existir sin el padre | Rombo hueco |
|
||||||
|
| **Asociación** | Relación genérica entre clases | Línea |
|
||||||
|
| **Dependencia** | Una clase usa temporalmente otra | Flecha punteada |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1.6 Acoplamiento y cohesión
|
||||||
|
|
||||||
|
**Acoplamiento**: grado de dependencia entre clases.
|
||||||
|
- **Bajo acoplamiento** → deseable: cambios en una clase afectan poco a otras.
|
||||||
|
|
||||||
|
**Cohesión**: grado en que los elementos de una clase están relacionados entre sí.
|
||||||
|
- **Alta cohesión** → deseable: cada clase tiene una responsabilidad clara y bien definida.
|
||||||
|
|
||||||
|
> Regla de oro: **alta cohesión + bajo acoplamiento**.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1.7 Ventajas e inconvenientes de la POO
|
||||||
|
|
||||||
|
**Ventajas:**
|
||||||
|
- Reutilización de código (herencia, composición).
|
||||||
|
- Modularidad y mantenimiento más sencillo.
|
||||||
|
- Modelado más natural del mundo real.
|
||||||
|
- Facilita el trabajo en equipo.
|
||||||
|
- Encapsulación protege la integridad de los datos.
|
||||||
|
|
||||||
|
**Inconvenientes:**
|
||||||
|
- Mayor complejidad inicial frente a la programación estructurada.
|
||||||
|
- Peor rendimiento en sistemas de bajo nivel (overhead de objetos).
|
||||||
|
- Diseño incorrecto puede llevar a jerarquías de herencia rígidas.
|
||||||
|
- Curva de aprendizaje más pronunciada.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Miniresumen
|
||||||
|
|
||||||
|
La POO se basa en **abstracción, encapsulación, herencia y polimorfismo**. Sus elementos clave son **clases, objetos, atributos y métodos**. Favorece la reutilización y el mantenimiento, a cambio de mayor complejidad inicial.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2. Patrones de diseño
|
||||||
|
|
||||||
|
## 2.1 Qué es un patrón de diseño
|
||||||
|
|
||||||
|
Un **patrón de diseño** es una solución reutilizable a un problema recurrente en el diseño de software. No es código concreto, sino una **plantilla conceptual** que describe cómo resolver una situación.
|
||||||
|
|
||||||
|
El catálogo más conocido es el del libro **"Design Patterns: Elements of Reusable Object-Oriented Software"** (1994), de los llamados **Gang of Four (GoF)**: Gamma, Helm, Johnson y Vlissides.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2.2 Clasificación GoF
|
||||||
|
|
||||||
|
Los 23 patrones GoF se dividen en tres categorías:
|
||||||
|
|
||||||
|
### Patrones creacionales
|
||||||
|
Gestionan el proceso de **creación de objetos**.
|
||||||
|
|
||||||
|
| Patrón | Descripción |
|
||||||
|
|---|---|
|
||||||
|
| **Singleton** | Garantiza que solo exista **una instancia** de una clase |
|
||||||
|
| **Factory Method** | Define una interfaz para crear objetos; las subclases deciden qué clase instanciar |
|
||||||
|
| **Abstract Factory** | Crea familias de objetos relacionados sin especificar sus clases concretas |
|
||||||
|
| **Builder** | Construye objetos complejos paso a paso |
|
||||||
|
| **Prototype** | Crea nuevos objetos **clonando** uno existente |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Patrones estructurales
|
||||||
|
Definen cómo se **componen** clases y objetos.
|
||||||
|
|
||||||
|
| Patrón | Descripción |
|
||||||
|
|---|---|
|
||||||
|
| **Adapter** | Convierte la interfaz de una clase en otra que el cliente espera |
|
||||||
|
| **Facade** | Proporciona una interfaz simplificada a un subsistema complejo |
|
||||||
|
| **Decorator** | Añade responsabilidades a un objeto dinámicamente |
|
||||||
|
| **Composite** | Trata objetos individuales y composiciones de objetos de forma uniforme |
|
||||||
|
| **Proxy** | Proporciona un sustituto o representante de otro objeto |
|
||||||
|
| **Bridge** | Desacopla una abstracción de su implementación |
|
||||||
|
| **Flyweight** | Comparte objetos para soportar grandes cantidades de objetos de grano fino |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Patrones de comportamiento
|
||||||
|
Gestionan la **comunicación** entre objetos.
|
||||||
|
|
||||||
|
| Patrón | Descripción |
|
||||||
|
|---|---|
|
||||||
|
| **Observer** | Un objeto notifica automáticamente a sus dependientes cuando cambia de estado |
|
||||||
|
| **Strategy** | Define una familia de algoritmos intercambiables en tiempo de ejecución |
|
||||||
|
| **Template Method** | Define el esqueleto de un algoritmo; las subclases rellenan los pasos |
|
||||||
|
| **Iterator** | Accede secuencialmente a los elementos de una colección sin exponer su estructura |
|
||||||
|
| **Command** | Encapsula una acción como objeto, permitiendo deshacer/rehacer |
|
||||||
|
| **Chain of Responsibility** | Pasa una petición a través de una cadena de objetos hasta que uno la procesa |
|
||||||
|
| **State** | El comportamiento de un objeto cambia según su estado interno |
|
||||||
|
| **Mediator** | Centraliza la comunicación entre objetos para reducir dependencias |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2.3 Patrón MVC
|
||||||
|
|
||||||
|
**Model-View-Controller** es un patrón arquitectónico que separa la aplicación en tres capas:
|
||||||
|
|
||||||
|
| Capa | Responsabilidad | Ejemplo |
|
||||||
|
|---|---|---|
|
||||||
|
| **Model** | Datos y lógica de negocio | Entidades, acceso a BD |
|
||||||
|
| **View** | Presentación al usuario | HTML, plantillas Thymeleaf |
|
||||||
|
| **Controller** | Recibe peticiones y coordina Model y View | Controladores REST/web |
|
||||||
|
|
||||||
|
Ventajas: separación de responsabilidades, facilita el testing, permite cambiar la vista sin tocar el modelo.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2.4 Patrones GRASP
|
||||||
|
|
||||||
|
**General Responsibility Assignment Software Patterns** — definen cómo asignar responsabilidades a clases y objetos.
|
||||||
|
|
||||||
|
| Patrón | Principio |
|
||||||
|
|---|---|
|
||||||
|
| **Information Expert** | Asigna la responsabilidad a la clase que tiene la información necesaria |
|
||||||
|
| **Creator** | Asigna la creación de objetos a la clase que los agrega, contiene o usa |
|
||||||
|
| **Controller** | Asigna el manejo de eventos del sistema a una clase controladora |
|
||||||
|
| **Low Coupling** | Minimiza las dependencias entre clases |
|
||||||
|
| **High Cohesion** | Cada clase tiene una responsabilidad bien definida |
|
||||||
|
| **Polymorphism** | Usa polimorfismo para manejar comportamientos alternativos |
|
||||||
|
| **Pure Fabrication** | Crea clases artificiales para mantener alta cohesión y bajo acoplamiento |
|
||||||
|
| **Indirection** | Introduce un intermediario para reducir el acoplamiento directo |
|
||||||
|
| **Protected Variations** | Protege los elementos de las variaciones en otros, usando interfaces estables |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2.5 Principios SOLID
|
||||||
|
|
||||||
|
Aunque no son patrones, suelen examinarse junto a ellos:
|
||||||
|
|
||||||
|
| Letra | Principio | Descripción |
|
||||||
|
|---|---|---|
|
||||||
|
| **S** | Single Responsibility | Una clase, una única responsabilidad |
|
||||||
|
| **O** | Open/Closed | Abierto a extensión, cerrado a modificación |
|
||||||
|
| **L** | Liskov Substitution | Las subclases deben poder sustituir a sus superclases |
|
||||||
|
| **I** | Interface Segregation | Mejor varias interfaces específicas que una general |
|
||||||
|
| **D** | Dependency Inversion | Depender de abstracciones, no de implementaciones concretas |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Miniresumen
|
||||||
|
|
||||||
|
Los patrones GoF se dividen en **creacionales** (cómo crear), **estructurales** (cómo componer) y **de comportamiento** (cómo comunicar). Los más importantes en el examen son: **Singleton, Factory, Adapter, Facade, Observer y Strategy**. MVC es el patrón arquitectónico más usado en aplicaciones web.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 3. UML — Lenguaje de Modelado Unificado
|
||||||
|
|
||||||
|
## 3.1 Qué es UML
|
||||||
|
|
||||||
|
**UML (Unified Modeling Language)** es un lenguaje estándar de modelado visual para describir, especificar, diseñar y documentar sistemas software.
|
||||||
|
|
||||||
|
- Desarrollado en los 90 por Booch, Rumbaugh y Jacobson en Rational Software.
|
||||||
|
- Estandarizado por el **OMG (Object Management Group)** en 1997.
|
||||||
|
- Versión actual: **UML 2.x**.
|
||||||
|
- No es un lenguaje de programación: es un **lenguaje de modelado**.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3.2 Clasificación de diagramas UML
|
||||||
|
|
||||||
|
UML 2 define **14 tipos de diagramas**, divididos en dos grandes grupos:
|
||||||
|
|
||||||
|
### Diagramas estructurales (qué ES el sistema)
|
||||||
|
|
||||||
|
| Diagrama | Descripción |
|
||||||
|
|---|---|
|
||||||
|
| **Clases** | Muestra clases, atributos, métodos y relaciones |
|
||||||
|
| **Objetos** | Instancias concretas de clases en un momento dado |
|
||||||
|
| **Componentes** | Módulos software (ejecutables, librerías, servicios web) y sus interfaces |
|
||||||
|
| **Paquetes** | Agrupación lógica de elementos del modelo |
|
||||||
|
| **Despliegue** | Infraestructura física: nodos, artefactos y conexiones |
|
||||||
|
| **Estructura compuesta** | Colaboración interna de una clase o componente |
|
||||||
|
| **Perfil** | Extensión del metamodelo UML para dominios específicos |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Diagramas de comportamiento (qué HACE el sistema)
|
||||||
|
|
||||||
|
| Diagrama | Descripción |
|
||||||
|
|---|---|
|
||||||
|
| **Casos de uso** | Funcionalidades del sistema desde el punto de vista del usuario (actores) |
|
||||||
|
| **Actividades** | Flujo de trabajo o proceso; similar a un diagrama de flujo |
|
||||||
|
| **Máquina de estados** | Estados de un objeto y transiciones entre ellos |
|
||||||
|
| **Secuencia** | Interacción entre objetos ordenada en el tiempo (eje vertical) |
|
||||||
|
| **Comunicación** | Interacción entre objetos con énfasis en los enlaces (sin eje temporal) |
|
||||||
|
| **Tiempos** | Comportamiento en función del tiempo; usado en sistemas en tiempo real |
|
||||||
|
| **Resumen de interacción** | Combinación de diagramas de actividades y de interacción |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3.3 Diagrama de clases (el más importante)
|
||||||
|
|
||||||
|
### Representación de una clase
|
||||||
|
|
||||||
|
```
|
||||||
|
┌─────────────────────┐
|
||||||
|
│ Empleado │ ← Nombre de la clase
|
||||||
|
├─────────────────────┤
|
||||||
|
│ - id: int │ ← Atributos (visibilidad nombre: tipo)
|
||||||
|
│ - nombre: String │
|
||||||
|
│ # salario: double │
|
||||||
|
├─────────────────────┤
|
||||||
|
│ + getNombre(): String│ ← Métodos (visibilidad nombre(): tipo_retorno)
|
||||||
|
│ + calcularNomina() │
|
||||||
|
└─────────────────────┘
|
||||||
|
```
|
||||||
|
|
||||||
|
Visibilidad: `+` público, `-` privado, `#` protegido, `~` paquete.
|
||||||
|
|
||||||
|
### Relaciones en el diagrama de clases
|
||||||
|
|
||||||
|
| Relación | Representación |
|
||||||
|
|---|---|
|
||||||
|
| Herencia (generalización) | Línea continua + triángulo hueco en el padre |
|
||||||
|
| Realización (interfaz) | Línea punteada + triángulo hueco |
|
||||||
|
| Asociación | Línea continua (con multiplicidad) |
|
||||||
|
| Composición | Línea + rombo **relleno** en el todo |
|
||||||
|
| Agregación | Línea + rombo **hueco** en el todo |
|
||||||
|
| Dependencia | Línea punteada + flecha abierta |
|
||||||
|
|
||||||
|
### Multiplicidad
|
||||||
|
|
||||||
|
| Notación | Significado |
|
||||||
|
|---|---|
|
||||||
|
| `1` | Exactamente uno |
|
||||||
|
| `0..1` | Cero o uno (opcional) |
|
||||||
|
| `*` o `0..*` | Cero o muchos |
|
||||||
|
| `1..*` | Uno o muchos |
|
||||||
|
| `2..5` | Entre dos y cinco |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3.4 Diagrama de casos de uso
|
||||||
|
|
||||||
|
Muestra **qué puede hacer** el sistema desde el punto de vista del usuario.
|
||||||
|
|
||||||
|
Elementos:
|
||||||
|
- **Actor**: entidad externa que interactúa con el sistema (persona, otro sistema). Se representa como un muñeco.
|
||||||
|
- **Caso de uso**: funcionalidad ofrecida. Se representa como una elipse.
|
||||||
|
- **Sistema**: rectángulo que enmarca los casos de uso.
|
||||||
|
|
||||||
|
Relaciones entre casos de uso:
|
||||||
|
- `«include»`: un caso de uso incluye obligatoriamente otro.
|
||||||
|
- `«extend»`: un caso de uso puede extender opcionalmente otro.
|
||||||
|
- Generalización: un actor o caso de uso hereda de otro.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3.5 Diagrama de secuencia
|
||||||
|
|
||||||
|
Muestra la **interacción entre objetos** ordenada temporalmente (de arriba a abajo).
|
||||||
|
|
||||||
|
Elementos:
|
||||||
|
- **Línea de vida** (lifeline): línea vertical punteada que representa un objeto.
|
||||||
|
- **Activación**: rectángulo sobre la línea de vida que indica cuándo está activo.
|
||||||
|
- **Mensaje**: flecha horizontal entre líneas de vida.
|
||||||
|
- Síncrono: flecha rellena (espera respuesta).
|
||||||
|
- Asíncrono: flecha abierta (no espera).
|
||||||
|
- Respuesta: flecha punteada.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3.6 Diagrama de despliegue
|
||||||
|
|
||||||
|
Muestra la **arquitectura física** del sistema.
|
||||||
|
|
||||||
|
| Elemento | Descripción |
|
||||||
|
|---|---|
|
||||||
|
| **Nodo** | Recurso físico o virtual (servidor, dispositivo, VM) — cubo 3D |
|
||||||
|
| **Artefacto** | Elemento software desplegado (JAR, WAR, script, BD) |
|
||||||
|
| **Asociación** | Canal de comunicación entre nodos |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3.7 Diagrama de actividades
|
||||||
|
|
||||||
|
Similar a un diagrama de flujo; modela el **flujo de trabajo** de un proceso o algoritmo.
|
||||||
|
|
||||||
|
Elementos:
|
||||||
|
- Nodo inicial (círculo relleno).
|
||||||
|
- Actividad (rectángulo redondeado).
|
||||||
|
- Decisión / bifurcación (rombo).
|
||||||
|
- Barra de sincronización (barra gruesa horizontal) para concurrencia (fork/join).
|
||||||
|
- Nodo final (círculo relleno dentro de otro círculo).
|
||||||
|
- **Carriles (swimlanes)**: dividen las actividades por responsable o sistema.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Miniresumen
|
||||||
|
|
||||||
|
UML define **14 tipos de diagramas** agrupados en estructurales (qué es) y de comportamiento (qué hace). Los más relevantes para el examen TAI son:
|
||||||
|
|
||||||
|
| Diagrama | Para qué se usa |
|
||||||
|
|---|---|
|
||||||
|
| **Clases** | Diseño lógico del sistema |
|
||||||
|
| **Casos de uso** | Requisitos desde el punto de vista del usuario |
|
||||||
|
| **Secuencia** | Interacción entre objetos en el tiempo |
|
||||||
|
| **Despliegue** | Arquitectura física e infraestructura |
|
||||||
|
| **Actividades** | Flujos de trabajo y procesos |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Miniresumen final del tema
|
||||||
|
|
||||||
|
| Punto | Idea clave |
|
||||||
|
|---|---|
|
||||||
|
| **POO** | Paradigma basado en objetos; pilares: abstracción, encapsulación, herencia, polimorfismo |
|
||||||
|
| **Elementos** | Clase (molde), objeto (instancia), atributo (dato), método (comportamiento) |
|
||||||
|
| **Herencia/Sobrecarga** | Herencia: reutilización jerárquica. Sobrecarga: mismo nombre, distintos parámetros |
|
||||||
|
| **Ventajas POO** | Reutilización, modularidad, modelado natural. Inconveniente: mayor complejidad |
|
||||||
|
| **Patrones GoF** | Creacionales (Singleton, Factory), estructurales (Adapter, Facade), comportamiento (Observer, Strategy) |
|
||||||
|
| **GRASP** | Patrones de asignación de responsabilidades: Low Coupling, High Cohesion, Controller… |
|
||||||
|
| **MVC** | Patrón arquitectónico: Model (datos), View (presentación), Controller (coordinación) |
|
||||||
|
| **SOLID** | 5 principios de diseño: S, O, L, I, D |
|
||||||
|
| **UML** | 14 diagramas; más importantes: Clases, Casos de uso, Secuencia, Despliegue, Actividades |
|
||||||
|
|
|
||||||
|
|
@ -1,358 +1,455 @@
|
||||||
# Arquitectura Java EE/Jakarta EE y plataforma .NET
|
# Bloque 3 · Tema 5
|
||||||
## Componentes, persistencia y seguridad. Características, lenguajes y desarrollo de interfaces
|
# Arquitectura Java EE/Jakarta EE y plataforma .NET. Componentes, persistencia y seguridad. Características, lenguajes y desarrollo de interfaces.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# 1. Esquema general del tema
|
# Esquema resumen
|
||||||
|
|
||||||
- Arquitectura Java EE / Jakarta EE
|
**Java EE / Jakarta EE — APIs principales**
|
||||||
- Servidor de aplicaciones
|
|
||||||
- APIs principales
|
|
||||||
- Persistencia (JDBC, ORM, JPA)
|
|
||||||
- Seguridad
|
|
||||||
|
|
||||||
- Plataforma .NET
|
| API | Función |
|
||||||
- Componentes
|
|---|---|
|
||||||
- Persistencia
|
| **Servlet** | Gestión de peticiones HTTP |
|
||||||
- Seguridad
|
| **JSP** | Páginas HTML con Java incrustado |
|
||||||
|
| **EJB** | Componentes de lógica de negocio |
|
||||||
|
| **JSF** | Framework de interfaces web por componentes |
|
||||||
|
| **JPA** | Persistencia estándar (ORM) |
|
||||||
|
| **JTA** | Transacciones distribuidas (ACID) |
|
||||||
|
| **CDI** | Inyección de dependencias |
|
||||||
|
|
||||||
- Comparativa Java EE vs .NET
|
**Persistencia en Java**
|
||||||
|
|
||||||
- Desarrollo de interfaces
|
| Tecnología | Tipo | Características |
|
||||||
- Tecnologías front-end
|
|---|---|---|
|
||||||
- Comunicación cliente-servidor
|
| **JDBC** | Acceso directo SQL | Control total; mucho código manual |
|
||||||
|
| **JPA** | API estándar ORM | Mapeo objeto-relacional con anotaciones |
|
||||||
|
| **Hibernate** | Implementación JPA | ORM más popular; JPQL |
|
||||||
|
|
||||||
---
|
**Plataforma .NET — Equivalencias con Java EE**
|
||||||
|
|
||||||
# 2. Arquitectura Java EE / Jakarta EE
|
| .NET | Java EE |
|
||||||
|
|---|---|
|
||||||
|
| CLR | JVM |
|
||||||
|
| C# | Java |
|
||||||
|
| ASP.NET Core | Servlet + Spring MVC |
|
||||||
|
| ADO.NET | JDBC |
|
||||||
|
| Entity Framework | JPA + Hibernate |
|
||||||
|
|
||||||
## 2.1. Definición
|
**Desarrollo de interfaces**
|
||||||
|
|
||||||
Plataforma de desarrollo para aplicaciones empresariales en Java.
|
- Front-end: HTML, CSS, JavaScript
|
||||||
|
- Frameworks: Angular, React, Vue
|
||||||
|
- Comunicación: REST (JSON) / SOAP (XML)
|
||||||
|
|
||||||
- Java EE (Oracle)
|
|
||||||
- Jakarta EE (Eclipse Foundation)
|
# 1. Arquitectura Java EE / Jakarta EE
|
||||||
|
|
||||||
|
## 1.1 Definición y origen
|
||||||
|
|
||||||
|
**Java EE (Java Enterprise Edition)** era la plataforma de Oracle para el desarrollo de aplicaciones empresariales en Java.
|
||||||
|
|
||||||
|
En **2017** Oracle donó la plataforma a la **Eclipse Foundation**, que la renombró como **Jakarta EE**. A partir de la versión 9, todos los paquetes cambiaron del prefijo `javax.*` al prefijo `jakarta.*`.
|
||||||
|
|
||||||
Permite crear aplicaciones:
|
Permite crear aplicaciones:
|
||||||
- Web
|
- Web
|
||||||
- Distribuidas
|
- Distribuidas
|
||||||
- Escalables
|
- Escalables
|
||||||
|
|
||||||
Se ejecuta sobre un servidor de aplicaciones.
|
Se ejecuta sobre un **servidor de aplicaciones** que implementa las APIs de la especificación.
|
||||||
|
|
||||||
Ejemplos:
|
|
||||||
- WildFly
|
|
||||||
- GlassFish
|
|
||||||
- WebLogic
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 2.2. Servidor de aplicaciones
|
## 1.2 Servidor de aplicaciones
|
||||||
|
|
||||||
Software que proporciona servicios a aplicaciones empresariales:
|
Software que proporciona los servicios de infraestructura necesarios a las aplicaciones empresariales.
|
||||||
|
|
||||||
Funciones:
|
**Funciones:**
|
||||||
- Ejecución de aplicaciones web
|
- Ejecución de aplicaciones web (Servlets, JSP…)
|
||||||
- Gestión de transacciones
|
- Gestión de transacciones
|
||||||
- Seguridad
|
- Seguridad
|
||||||
- Gestión de conexiones a base de datos
|
- Pool de conexiones a base de datos
|
||||||
- Gestión de sesiones
|
- Gestión de sesiones y clustering
|
||||||
|
|
||||||
Idea clave:
|
**Servidores de aplicaciones Jakarta EE:**
|
||||||
El servidor implementa las APIs de Jakarta EE.
|
|
||||||
|
| Servidor | Fabricante | Licencia |
|
||||||
|
|---|---|---|
|
||||||
|
| **WildFly** (antes JBoss) | Red Hat | Open source |
|
||||||
|
| **GlassFish** | Eclipse Foundation | Open source |
|
||||||
|
| **WebLogic** | Oracle | Comercial |
|
||||||
|
| **WebSphere** | IBM | Comercial |
|
||||||
|
| **TomEE** | Apache | Open source |
|
||||||
|
|
||||||
|
> **Nota:** Apache Tomcat **no es** un servidor Jakarta EE completo; solo implementa Servlets y JSP.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 2.3. APIs principales
|
## 1.3 APIs principales
|
||||||
|
|
||||||
### Servlet
|
### Servlet
|
||||||
|
|
||||||
Gestiona peticiones HTTP.
|
Componente Java que gestiona peticiones y respuestas HTTP.
|
||||||
|
|
||||||
- Métodos: GET, POST, PUT, DELETE
|
- Métodos soportados: `GET`, `POST`, `PUT`, `DELETE`, `HEAD`, `OPTIONS`
|
||||||
|
- Ciclo de vida: `init()` → `service()` → `destroy()`
|
||||||
- Base del desarrollo web en Java
|
- Base del desarrollo web en Java
|
||||||
|
|
||||||
Flujo:
|
```
|
||||||
Cliente → Servlet → Respuesta
|
Cliente → petición HTTP → Servlet → procesa → respuesta HTTP → Cliente
|
||||||
|
```
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
### JSP (JavaServer Pages)
|
### JSP (JavaServer Pages)
|
||||||
|
|
||||||
- Páginas HTML con código Java incrustado
|
Páginas HTML con código Java incrustado que se compilan a un Servlet en el servidor.
|
||||||
- Generación dinámica de contenido
|
|
||||||
|
|
||||||
Uso actual:
|
- Etiquetas especiales: `<% %>` (scriptlet), `<%= %>` (expresión), `<%! %>` (declaración)
|
||||||
Limitado, sustituido por frameworks modernos.
|
- Uso disminuido en favor de Thymeleaf, FreeMarker, etc.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
### EJB (Enterprise JavaBeans)
|
### EJB (Enterprise JavaBeans)
|
||||||
|
|
||||||
Componentes de lógica de negocio.
|
Componentes de lógica de negocio con servicios gestionados automáticamente por el contenedor.
|
||||||
|
|
||||||
Características:
|
| Tipo | Descripción |
|
||||||
- Gestión automática de transacciones
|
|---|---|
|
||||||
- Seguridad
|
| **Session Bean Stateless** | Sin estado entre llamadas; escalable |
|
||||||
- Concurrencia
|
| **Session Bean Stateful** | Mantiene estado para un cliente concreto |
|
||||||
|
| **Message-Driven Bean** | Procesa mensajes asíncronos (JMS) |
|
||||||
Uso actual:
|
|
||||||
Menor en aplicaciones modernas.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
### JSF (JavaServer Faces)
|
### JSF (JavaServer Faces)
|
||||||
|
|
||||||
Framework de interfaces web basado en componentes.
|
Framework estándar de Jakarta EE para interfaces web basadas en **componentes**. Sigue el patrón MVC.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
### JPA (Java Persistence API)
|
### JPA (Java Persistence API)
|
||||||
|
|
||||||
API estándar para persistencia.
|
API estándar para la **persistencia de objetos** en bases de datos relacionales.
|
||||||
|
|
||||||
Permite:
|
- Mapea clases Java a tablas mediante anotaciones.
|
||||||
- Mapear objetos a tablas
|
- Consultas en **JPQL** (orientado a objetos) o Criteria API.
|
||||||
- Consultas orientadas a objetos
|
- Implementaciones: **Hibernate** (la más usada), EclipseLink, OpenJPA.
|
||||||
|
|
||||||
|
**Anotaciones básicas:**
|
||||||
|
|
||||||
|
| Anotación | Uso |
|
||||||
|
|---|---|
|
||||||
|
| `@Entity` | Marca la clase como entidad persistente |
|
||||||
|
| `@Table(name="...")` | Nombre de la tabla |
|
||||||
|
| `@Id` | Clave primaria |
|
||||||
|
| `@GeneratedValue` | Generación automática del ID |
|
||||||
|
| `@Column` | Mapeo de columna |
|
||||||
|
| `@OneToMany`, `@ManyToOne`, `@ManyToMany` | Relaciones entre entidades |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
### JTA (Java Transaction API)
|
### JTA (Java Transaction API)
|
||||||
|
|
||||||
Gestión de transacciones distribuidas.
|
Gestión de **transacciones distribuidas**. Garantiza las propiedades **ACID**:
|
||||||
|
|
||||||
Propiedades ACID:
|
| Propiedad | Descripción |
|
||||||
- Atomicidad
|
|---|---|
|
||||||
- Consistencia
|
| **Atomicidad** | Toda la transacción se ejecuta o ninguna parte |
|
||||||
- Aislamiento
|
| **Consistencia** | La BD pasa de un estado válido a otro |
|
||||||
- Durabilidad
|
| **Aislamiento** | Las transacciones concurrentes no se interfieren |
|
||||||
|
| **Durabilidad** | Los cambios confirmados son permanentes |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 2.4. Persistencia
|
### CDI (Contexts and Dependency Injection)
|
||||||
|
|
||||||
### JDBC
|
Framework de inyección de dependencias de Jakarta EE.
|
||||||
|
|
||||||
Acceso directo a base de datos mediante SQL.
|
- Gestiona el ciclo de vida de los objetos (beans).
|
||||||
|
- Permite inyectar dependencias mediante `@Inject`.
|
||||||
Patrón asociado:
|
- Favorece bajo acoplamiento.
|
||||||
DAO (Data Access Object)
|
|
||||||
|
|
||||||
Ventajas:
|
|
||||||
- Control total
|
|
||||||
|
|
||||||
Desventajas:
|
|
||||||
- Mucho código manual
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
### ORM (Object Relational Mapping)
|
### Miniresumen
|
||||||
|
|
||||||
Mapeo objeto-relacional:
|
Jakarta EE se ejecuta sobre servidores de aplicaciones como WildFly o GlassFish. Sus APIs clave son: **Servlet** (HTTP), **JSP** (páginas dinámicas), **EJB** (lógica de negocio), **JPA** (persistencia), **JTA** (transacciones) y **CDI** (inyección de dependencias).
|
||||||
- Tablas → Clases
|
|
||||||
- Registros → Objetos
|
|
||||||
|
|
||||||
Tecnologías:
|
|
||||||
- JPA (estándar)
|
|
||||||
- Hibernate (implementación)
|
|
||||||
|
|
||||||
Lenguaje:
|
|
||||||
JPQL (Java Persistence Query Language)
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 2.5. Documentación
|
# 2. Persistencia en Java
|
||||||
|
|
||||||
- JavaDoc: documentación del código Java
|
## 2.1 JDBC y patrón DAO
|
||||||
- Swagger / OpenAPI: documentación de APIs REST
|
|
||||||
|
**JDBC (Java Database Connectivity)** es la API estándar de Java para el acceso directo a bases de datos relacionales mediante SQL.
|
||||||
|
|
||||||
|
Pasos de uso:
|
||||||
|
1. Cargar el driver del SGBD.
|
||||||
|
2. Establecer la conexión (`DriverManager.getConnection()`).
|
||||||
|
3. Crear un `Statement` o `PreparedStatement`.
|
||||||
|
4. Ejecutar la consulta SQL.
|
||||||
|
5. Procesar el `ResultSet`.
|
||||||
|
6. Cerrar la conexión.
|
||||||
|
|
||||||
|
| | JDBC |
|
||||||
|
|---|---|
|
||||||
|
| **Ventajas** | Control total sobre el SQL; rendimiento máximo |
|
||||||
|
| **Inconvenientes** | Código repetitivo (boilerplate); acoplamiento al SGBD |
|
||||||
|
|
||||||
|
**Patrón DAO (Data Access Object):** encapsula la lógica de acceso a datos en una capa separada, aislando la lógica de negocio del mecanismo de persistencia.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 2.6. Seguridad
|
## 2.2 ORM, JPA e Hibernate
|
||||||
|
|
||||||
Tipos de seguridad:
|
**ORM (Object-Relational Mapping):** técnica que mapea el modelo de objetos con el modelo relacional.
|
||||||
|
|
||||||
### Seguridad declarativa
|
| Concepto relacional | Concepto OO |
|
||||||
- Configuración mediante ficheros o anotaciones
|
|---|---|
|
||||||
- Basada en roles
|
| Tabla | Clase |
|
||||||
|
| Fila (registro) | Objeto (instancia) |
|
||||||
|
| Columna (campo) | Atributo |
|
||||||
|
| Clave primaria | Identificador (`@Id`) |
|
||||||
|
| Clave foránea | Referencia a otro objeto |
|
||||||
|
|
||||||
### Seguridad programática
|
**JPA** es la especificación estándar. **Hibernate** es su implementación más popular.
|
||||||
- Implementada mediante código
|
|
||||||
|
**JPQL (Java Persistence Query Language):**
|
||||||
|
- Similar a SQL pero orientado a objetos.
|
||||||
|
- Opera sobre entidades y atributos, no sobre tablas y columnas.
|
||||||
|
|
||||||
|
```java
|
||||||
|
// JPQL
|
||||||
|
SELECT e FROM Empleado e WHERE e.departamento.nombre = :dept
|
||||||
|
|
||||||
|
// SQL equivalente
|
||||||
|
SELECT * FROM empleados e JOIN departamentos d ON e.dept_id = d.id WHERE d.nombre = ?
|
||||||
|
```
|
||||||
|
|
||||||
|
**Spring Data JPA:** genera automáticamente las consultas a partir del nombre del método.
|
||||||
|
|
||||||
|
```java
|
||||||
|
List<Empleado> findByDepartamentoNombre(String nombre);
|
||||||
|
```
|
||||||
|
|
||||||
|
**Documentación:**
|
||||||
|
- **JavaDoc**: documentación del código Java.
|
||||||
|
- **Swagger / OpenAPI**: documentación de APIs REST.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
### Spring Security
|
### Miniresumen
|
||||||
|
|
||||||
Framework para seguridad en aplicaciones Java:
|
La persistencia en Java usa **JDBC** para acceso SQL directo o **JPA/Hibernate** (ORM) para mapeo objeto-relacional. Las consultas se escriben en **JPQL**. Spring Data JPA simplifica el acceso generando consultas automáticamente.
|
||||||
|
|
||||||
Funciones:
|
|
||||||
- Autenticación
|
|
||||||
- Autorización
|
|
||||||
- Control de accesos
|
|
||||||
- Protección CSRF
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# 3. Plataforma .NET
|
# 3. Seguridad en Java EE
|
||||||
|
|
||||||
## 3.1. Definición
|
## 3.1 Tipos de seguridad
|
||||||
|
|
||||||
Plataforma de Microsoft para desarrollo de aplicaciones.
|
| Tipo | Mecanismo | Cuándo usarlo |
|
||||||
|
|---|---|---|
|
||||||
Permite crear:
|
| **Declarativa** | Anotaciones (`@RolesAllowed`, `@PermitAll`, `@DenyAll`) o ficheros de config | Lógica simple basada en roles |
|
||||||
- Aplicaciones web
|
| **Programática** | Código Java (`SecurityContext`, `isUserInRole()`) | Lógica de seguridad compleja |
|
||||||
- Aplicaciones de escritorio
|
|
||||||
- Servicios
|
|
||||||
|
|
||||||
Actualmente:
|
|
||||||
.NET moderno es multiplataforma.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 3.2. Componentes
|
## 3.2 Spring Security
|
||||||
|
|
||||||
- CLR (Common Language Runtime)
|
Framework de seguridad estándar de facto en el ecosistema Java.
|
||||||
- Framework de clases base
|
|
||||||
- ASP.NET para aplicaciones web
|
**Funcionalidades:**
|
||||||
|
- **Autenticación**: verificar la identidad (usuario + contraseña, JWT, OAuth2…)
|
||||||
|
- **Autorización**: controlar el acceso según roles o permisos
|
||||||
|
- **Protección CSRF**: evita ataques de falsificación de solicitudes entre sitios
|
||||||
|
- **Gestión de sesiones**
|
||||||
|
- **Cifrado de contraseñas**: BCrypt, Argon2…
|
||||||
|
|
||||||
|
**Mecanismos de autenticación soportados:**
|
||||||
|
|
||||||
|
| Mecanismo | Descripción |
|
||||||
|
|---|---|
|
||||||
|
| Form Login | Formulario HTML clásico |
|
||||||
|
| HTTP Basic | Cabecera `Authorization: Basic ...` |
|
||||||
|
| **JWT** | Token firmado sin estado (stateless) |
|
||||||
|
| **OAuth2 / OIDC** | Delegación a proveedor externo (Google, GitHub…) |
|
||||||
|
| LDAP | Directorio corporativo |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 3.3. Lenguajes
|
### Miniresumen
|
||||||
|
|
||||||
- C# (principal)
|
La seguridad en Java EE puede ser **declarativa** (anotaciones) o **programática** (código). **Spring Security** gestiona autenticación, autorización, protección CSRF y soporta JWT y OAuth2.
|
||||||
- VB.NET
|
|
||||||
- F#
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 3.4. Persistencia
|
# 4. Plataforma .NET
|
||||||
|
|
||||||
### ADO.NET
|
## 4.1 Definición y componentes
|
||||||
|
|
||||||
Acceso directo a bases de datos.
|
**.NET** es la plataforma de desarrollo de Microsoft para crear aplicaciones web, de escritorio, servicios y aplicaciones móviles.
|
||||||
|
|
||||||
### Entity Framework
|
**Evolución:**
|
||||||
|
- **.NET Framework** (2002): solo Windows.
|
||||||
|
- **.NET Core** (2016): multiplataforma (Windows, Linux, macOS).
|
||||||
|
- **.NET 5+** (2020): unificación bajo el nombre ".NET".
|
||||||
|
|
||||||
ORM de .NET equivalente a JPA/Hibernate.
|
**Componentes principales:**
|
||||||
|
|
||||||
|
| Componente | Descripción | Equivalente Java EE |
|
||||||
|
|---|---|---|
|
||||||
|
| **CLR** (Common Language Runtime) | Máquina virtual; ejecuta código IL | JVM |
|
||||||
|
| **BCL** (Base Class Library) | Librerías base del framework | Java SE |
|
||||||
|
| **ASP.NET Core** | Framework web | Servlet + Spring MVC |
|
||||||
|
| **Entity Framework Core** | ORM | JPA + Hibernate |
|
||||||
|
|
||||||
|
**Proceso de compilación:**
|
||||||
|
```
|
||||||
|
Código C# → compilador → IL (Intermediate Language) → CLR (JIT) → código nativo
|
||||||
|
```
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 3.5. Seguridad
|
## 4.2 Lenguajes de .NET
|
||||||
|
|
||||||
Características:
|
Todos compilan a **IL** y se ejecutan en el CLR:
|
||||||
- Integrada en el framework
|
|
||||||
- Basada en roles
|
|
||||||
|
|
||||||
Métodos de autenticación:
|
| Lenguaje | Paradigma | Uso principal |
|
||||||
- Windows Authentication
|
|---|---|---|
|
||||||
- JWT
|
| **C#** | Orientado a objetos | Aplicaciones empresariales, web, escritorio |
|
||||||
- OAuth
|
| **VB.NET** | Orientado a objetos | Aplicaciones legacy Windows |
|
||||||
|
| **F#** | Funcional | Análisis de datos, computación científica |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# 4. Comparativa Java EE vs .NET
|
## 4.3 Persistencia en .NET
|
||||||
|
|
||||||
| Característica | Java EE / Jakarta EE | .NET |
|
**ADO.NET:**
|
||||||
|----------------|---------------------|------|
|
- Acceso directo a bases de datos mediante SQL.
|
||||||
| Propietario | Eclipse Foundation | Microsoft |
|
- Equivalente a JDBC.
|
||||||
| Lenguaje | Java | C# |
|
- Clases: `SqlConnection`, `SqlCommand`, `SqlDataReader`, `DataSet`.
|
||||||
| Servidor | WildFly, GlassFish | IIS, Kestrel |
|
|
||||||
| ORM | JPA / Hibernate | Entity Framework |
|
|
||||||
| Multiplataforma | Sí | Sí |
|
|
||||||
| Seguridad | Spring Security | Integrada |
|
|
||||||
|
|
||||||
Conclusión:
|
**Entity Framework (EF Core):**
|
||||||
Ambos son frameworks empresariales equivalentes.
|
- ORM de .NET; equivalente a JPA + Hibernate.
|
||||||
|
- Tres enfoques:
|
||||||
|
- **Code First**: se definen las clases; EF genera la BD.
|
||||||
|
- **Database First**: se parte de la BD existente; EF genera las clases.
|
||||||
|
- **Model First**: se diseña el modelo visual; EF genera BD y clases.
|
||||||
|
- Consultas con **LINQ (Language Integrated Query)**: tipadas directamente en C#.
|
||||||
|
|
||||||
|
```csharp
|
||||||
|
var empleados = context.Empleados
|
||||||
|
.Where(e => e.Departamento.Nombre == "TIC")
|
||||||
|
.OrderBy(e => e.Apellidos)
|
||||||
|
.ToList();
|
||||||
|
```
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# 5. Características comunes
|
## 4.4 Seguridad en .NET
|
||||||
|
|
||||||
- Arquitectura en capas:
|
- Integrada en ASP.NET Core mediante middleware.
|
||||||
- Presentación
|
- Basada en **claims** y **roles**.
|
||||||
- Negocio
|
|
||||||
- Persistencia
|
|
||||||
|
|
||||||
- Aplicaciones distribuidas
|
| Método | Descripción |
|
||||||
- Escalabilidad
|
|---|---|
|
||||||
- Seguridad integrada
|
| Windows Authentication | Integración con Active Directory / dominio |
|
||||||
- Uso de servicios web
|
| **JWT** | Token sin estado; estándar en APIs REST |
|
||||||
|
| **OAuth2 / OpenID Connect** | Delegación a proveedor externo |
|
||||||
|
| Cookie Authentication | Sesión basada en cookies |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Miniresumen
|
||||||
|
|
||||||
|
.NET es la plataforma de Microsoft, multiplataforma desde .NET Core. Componentes clave: **CLR** (máquina virtual), **ASP.NET Core** (web), **ADO.NET** (SQL directo) y **Entity Framework** (ORM). Lenguaje principal: **C#**.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 5. Comparativa Java EE vs .NET
|
||||||
|
|
||||||
|
| Característica | Java EE / Jakarta EE | .NET (Core / 5+) |
|
||||||
|
|---|---|---|
|
||||||
|
| **Gestor** | Eclipse Foundation | Microsoft |
|
||||||
|
| **Lenguaje principal** | Java | C# |
|
||||||
|
| **Máquina virtual** | JVM | CLR |
|
||||||
|
| **Servidor web** | WildFly, GlassFish, Tomcat | Kestrel, IIS |
|
||||||
|
| **Framework web** | Spring MVC, JSF | ASP.NET Core |
|
||||||
|
| **ORM** | JPA / Hibernate | Entity Framework Core |
|
||||||
|
| **Acceso SQL directo** | JDBC | ADO.NET |
|
||||||
|
| **Seguridad** | Spring Security | ASP.NET Core Identity |
|
||||||
|
| **Inyección de dependencias** | CDI, Spring DI | DI nativo en ASP.NET Core |
|
||||||
|
| **Multiplataforma** | Sí (JVM) | Sí (desde .NET Core) |
|
||||||
|
| **Licencia** | Open source (mayoría) | Open source (MIT) |
|
||||||
|
|
||||||
|
> **Conclusión:** ambas son plataformas empresariales equivalentes. La elección depende del ecosistema y el perfil del equipo.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# 6. Desarrollo de interfaces
|
# 6. Desarrollo de interfaces
|
||||||
|
|
||||||
## 6.1. Front-end
|
## 6.1 Tecnologías front-end
|
||||||
|
|
||||||
Tecnologías principales:
|
El **front-end** es la parte de la aplicación que se ejecuta en el navegador del usuario.
|
||||||
- HTML
|
|
||||||
- CSS
|
|
||||||
- JavaScript
|
|
||||||
|
|
||||||
Frameworks:
|
**Tecnologías base:**
|
||||||
- Angular
|
|
||||||
- React
|
| Tecnología | Función |
|
||||||
- Vue
|
|---|---|
|
||||||
|
| **HTML** | Estructura y contenido de la página |
|
||||||
|
| **CSS** | Presentación y diseño visual |
|
||||||
|
| **JavaScript** | Comportamiento e interactividad |
|
||||||
|
|
||||||
|
**Frameworks de front-end:**
|
||||||
|
|
||||||
|
| Framework | Fabricante | Paradigma |
|
||||||
|
|---|---|---|
|
||||||
|
| **Angular** | Google | Framework completo (TypeScript) |
|
||||||
|
| **React** | Meta | Librería de UI (JSX) |
|
||||||
|
| **Vue** | Comunidad | Framework progresivo |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 6.2. Back-end
|
## 6.2 Comunicación cliente-servidor
|
||||||
|
|
||||||
Java:
|
**Protocolo:** HTTP / HTTPS.
|
||||||
- Jakarta EE
|
|
||||||
- Spring
|
|
||||||
|
|
||||||
.NET:
|
**Arquitecturas de API:**
|
||||||
- ASP.NET
|
|
||||||
|
| Arquitectura | Formato | Características |
|
||||||
|
|---|---|---|
|
||||||
|
| **REST** | JSON | Sin estado; orientado a recursos; HTTP nativo |
|
||||||
|
| **SOAP** | XML | Protocolo formal con WSDL; entornos corporativos |
|
||||||
|
| **GraphQL** | JSON | El cliente especifica exactamente los datos que necesita |
|
||||||
|
| **WebSocket** | Binario / texto | Comunicación bidireccional en tiempo real |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 6.3. Comunicación cliente-servidor
|
## 6.3 Tipos de aplicaciones web
|
||||||
|
|
||||||
Protocolos:
|
| Tipo | Descripción | Tecnología |
|
||||||
- HTTP / HTTPS
|
|---|---|---|
|
||||||
|
| **MPA** (Multi-Page Application) | Cada acción genera una página nueva desde el servidor | Thymeleaf, JSP, Razor |
|
||||||
Formatos:
|
| **SPA** (Single-Page Application) | Una sola página; contenido actualizado dinámicamente | Angular, React, Vue |
|
||||||
- JSON
|
| **PWA** (Progressive Web App) | SPA con capacidades offline y notificaciones push | Service Workers |
|
||||||
- XML
|
| **SSR** (Server-Side Rendering) | El servidor renderiza la página inicial | Next.js, Nuxt.js |
|
||||||
|
|
||||||
Arquitecturas:
|
|
||||||
- REST
|
|
||||||
- SOAP
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 6.4. Tipos de aplicaciones
|
### Miniresumen
|
||||||
|
|
||||||
- Aplicaciones web tradicionales
|
El front-end usa **HTML, CSS y JavaScript**. Los frameworks más usados son **Angular, React y Vue**. La comunicación con el back-end se realiza mediante **APIs REST con JSON** sobre HTTPS. Las SPA son el modelo más habitual en aplicaciones modernas.
|
||||||
- SPA (Single Page Applications)
|
|
||||||
- Aplicaciones móviles con API backend
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# 7. Conceptos importantes de examen
|
# Miniresumen final del tema
|
||||||
|
|
||||||
- Servlet: gestión de peticiones HTTP
|
| Punto | Idea clave |
|
||||||
- JSP: páginas dinámicas (uso limitado hoy)
|
|---|---|
|
||||||
- JPA: estándar de persistencia
|
| **1. Java EE / Jakarta EE** | Plataforma empresarial Java; APIs: Servlet, JSP, EJB, JSF, JPA, JTA, CDI |
|
||||||
- Hibernate: implementación de ORM
|
| **2. Persistencia en Java** | JDBC (SQL directo) o JPA/Hibernate (ORM); consultas en JPQL |
|
||||||
- Entity Framework: ORM de .NET
|
| **3. Seguridad Java EE** | Declarativa (anotaciones) o programática; Spring Security: autenticación, autorización, JWT, OAuth2 |
|
||||||
- Spring Security: seguridad en Java
|
| **4. .NET** | Plataforma Microsoft; CLR, C#, ASP.NET Core, Entity Framework (EF Core) |
|
||||||
|
| **5. Comparativa** | Plataformas equivalentes; Java EE usa JVM y Spring; .NET usa CLR y ASP.NET Core |
|
||||||
---
|
| **6. Interfaces** | HTML + CSS + JS; frameworks Angular/React/Vue; comunicación REST/JSON |
|
||||||
|
|
||||||
# 8. Miniresumen final
|
|
||||||
|
|
||||||
Java EE/Jakarta EE y .NET son plataformas de desarrollo empresarial.
|
|
||||||
|
|
||||||
Java EE usa:
|
|
||||||
- Servlets, JSP, EJB, JPA
|
|
||||||
|
|
||||||
.NET usa:
|
|
||||||
- ASP.NET, C#, Entity Framework
|
|
||||||
|
|
||||||
Ambos:
|
|
||||||
- Arquitectura multicapa
|
|
||||||
- Seguridad integrada
|
|
||||||
- Persistencia mediante ORM o acceso directo
|
|
||||||
- Desarrollo de aplicaciones web y servicios
|
|
||||||
|
|
@ -1,6 +1,136 @@
|
||||||
## Bloque 3 Tema 5. Arquitectura Java EE/Jakarta EE y plataforma .NET. Componentes, persistencia y seguridad. Características, lenguajes y desarrollo de interfaces.
|
## Bloque 3 Tema 5. Arquitectura Java EE/Jakarta EE y plataforma .NET. Componentes, persistencia y seguridad. Características, lenguajes y desarrollo de interfaces.
|
||||||
|
|
||||||
Este tema estudia las dos grandes plataformas de desarrollo empresarial: Java EE con su sucesor Jakarta EE, y la plataforma .NET de Microsoft.
|
Este tema estudia las dos grandes plataformas de desarrollo empresarial: Jakarta EE, sucesor de Java EE, y la plataforma .NET de Microsoft. También estudia la persistencia, la seguridad y el desarrollo de interfaces en ambos entornos.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Arquitectura Java EE / Jakarta EE
|
||||||
|
|
||||||
|
### 1.1. Definición y origen
|
||||||
|
|
||||||
|
Java EE, o Java Enterprise Edition, era la plataforma de Oracle para el desarrollo de aplicaciones empresariales en Java. En 2017 Oracle donó la plataforma a la Eclipse Foundation, que la renombró como Jakarta EE. A partir de la versión 9, todos los paquetes cambiaron del prefijo javax al prefijo jakarta. Permite crear aplicaciones web, distribuidas y escalables, que se ejecutan sobre un servidor de aplicaciones que implementa las APIs de la especificación.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 1.2. Servidor de aplicaciones
|
||||||
|
|
||||||
|
Un servidor de aplicaciones es el software que proporciona los servicios de infraestructura necesarios a las aplicaciones empresariales. Sus funciones son la ejecución de aplicaciones web mediante Servlets y JSP, la gestión de transacciones, la seguridad, el pool de conexiones a base de datos y la gestión de sesiones. El servidor implementa las APIs de Jakarta EE. Los servidores más conocidos son WildFly, antes llamado JBoss, que es de Red Hat y es de código abierto; GlassFish de la Eclipse Foundation; WebLogic de Oracle; y WebSphere de IBM. Es importante saber que Apache Tomcat no es un servidor Jakarta EE completo, porque solo implementa Servlets y JSP, sin el perfil completo de la especificación.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 1.3. APIs principales
|
||||||
|
|
||||||
|
Los Servlets son componentes Java que gestionan peticiones y respuestas HTTP. Soportan los métodos GET, POST, PUT, DELETE, HEAD y OPTIONS. Su ciclo de vida tiene tres fases: init para la inicialización, service para el procesamiento de peticiones, y destroy para la liberación de recursos. Son la base del desarrollo web en Java.
|
||||||
|
|
||||||
|
Las JSP o JavaServer Pages son páginas HTML con código Java incrustado que se compilan a un Servlet en el servidor para generar contenido dinámico. Su uso ha disminuido en favor de motores de plantillas modernos como Thymeleaf.
|
||||||
|
|
||||||
|
Los EJB o Enterprise JavaBeans son componentes de lógica de negocio con servicios gestionados automáticamente por el contenedor del servidor: transacciones, seguridad y concurrencia. Existen tres tipos: Session Bean sin estado, que es escalable y no conserva información entre llamadas; Session Bean con estado, que mantiene el estado para un cliente concreto; y Message-Driven Bean, para el procesamiento de mensajes asíncronos mediante JMS.
|
||||||
|
|
||||||
|
JSF o JavaServer Faces es el framework estándar de Jakarta EE para interfaces web basadas en componentes. Sigue el patrón MVC.
|
||||||
|
|
||||||
|
JPA o Java Persistence API es la API estándar para la persistencia de objetos en bases de datos relacionales. Permite mapear clases Java a tablas mediante anotaciones como Entity, Table, Id, Column y las relaciones OneToMany, ManyToOne y ManyToMany. Las consultas se escriben en JPQL, el Java Persistence Query Language, que opera sobre entidades y atributos en lugar de tablas y columnas. La implementación más popular es Hibernate.
|
||||||
|
|
||||||
|
JTA o Java Transaction API gestiona las transacciones distribuidas garantizando las propiedades ACID: atomicidad, que significa que toda la transacción se ejecuta o ninguna parte; consistencia, que asegura que la base de datos pasa de un estado válido a otro; aislamiento, que evita interferencias entre transacciones concurrentes; y durabilidad, que garantiza que los cambios confirmados son permanentes.
|
||||||
|
|
||||||
|
CDI o Contexts and Dependency Injection es el framework de inyección de dependencias de Jakarta EE. Gestiona el ciclo de vida de los objetos y permite inyectar dependencias mediante la anotación Inject, favoreciendo el bajo acoplamiento y la modularidad.
|
||||||
|
|
||||||
|
En resumen: Jakarta EE se ejecuta sobre servidores de aplicaciones como WildFly o GlassFish. Sus APIs clave son Servlet para HTTP, JSP para páginas dinámicas, EJB para lógica de negocio, JPA para persistencia, JTA para transacciones y CDI para inyección de dependencias.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. Persistencia en Java
|
||||||
|
|
||||||
|
### 2.1. JDBC y patrón DAO
|
||||||
|
|
||||||
|
JDBC, o Java Database Connectivity, es la API estándar de Java para el acceso directo a bases de datos relacionales mediante SQL. Los pasos de uso son: cargar el driver del SGBD, establecer la conexión mediante DriverManager, crear un Statement o PreparedStatement, ejecutar la consulta SQL, procesar el ResultSet y cerrar la conexión. Sus ventajas son el control total sobre el SQL y el máximo rendimiento. Sus desventajas son el código repetitivo conocido como boilerplate y el acoplamiento al SGBD concreto. El patrón DAO, o Data Access Object, encapsula la lógica de acceso a datos en una capa separada, aislando la lógica de negocio del mecanismo de persistencia.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 2.2. ORM, JPA e Hibernate
|
||||||
|
|
||||||
|
El ORM u Object-Relational Mapping es una técnica que mapea el modelo de objetos con el modelo relacional de la base de datos. Una tabla se convierte en una clase, una fila en un objeto, una columna en un atributo, la clave primaria en el identificador marcado con la anotación Id, y la clave foránea en una referencia a otro objeto.
|
||||||
|
|
||||||
|
JPA es la especificación estándar y Hibernate su implementación más popular. JPQL es similar a SQL pero orientado a objetos: opera sobre entidades y atributos en lugar de tablas y columnas, lo que hace las consultas más portables entre distintos gestores de base de datos. Spring Data JPA añade una capa de abstracción sobre JPA que genera automáticamente las consultas a partir del nombre del método: por ejemplo, un método llamado findByDepartamentoNombre genera la consulta correspondiente sin necesidad de escribirla. Para la documentación del código Java se usa JavaDoc. Para la documentación de APIs REST se usa Swagger u OpenAPI.
|
||||||
|
|
||||||
|
En resumen: la persistencia en Java puede gestionarse con JDBC para acceso SQL directo, o con JPA e Hibernate como ORM. JPA mapea clases a tablas mediante anotaciones y las consultas se escriben en JPQL. Spring Data JPA simplifica el acceso generando consultas automáticamente.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. Seguridad en Java EE
|
||||||
|
|
||||||
|
### 3.1. Tipos de seguridad
|
||||||
|
|
||||||
|
La seguridad en Java EE puede configurarse de dos formas. La seguridad declarativa se configura mediante anotaciones como RolesAllowed, PermitAll o DenyAll, o mediante ficheros de configuración. No requiere código adicional en la lógica de negocio y el servidor de aplicaciones gestiona el control de acceso basándose en los roles del usuario. La seguridad programática se implementa directamente en el código Java para casos más complejos, utilizando el SecurityContext o métodos como isUserInRole del HttpServletRequest.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 3.2. Spring Security
|
||||||
|
|
||||||
|
Spring Security es el framework de seguridad estándar de facto en el ecosistema Java. Proporciona autenticación, que es la verificación de la identidad del usuario mediante contraseña, token JWT u OAuth2; autorización, que controla el acceso a recursos según los roles y permisos; protección contra CSRF o Cross-Site Request Forgery; gestión de sesiones; y cifrado de contraseñas mediante algoritmos seguros como BCrypt. Los mecanismos de autenticación soportados son: formulario HTML clásico; HTTP Basic mediante la cabecera Authorization; JWT o JSON Web Token, que es un token firmado sin estado especialmente útil en APIs REST; OAuth2 y OpenID Connect para delegación a proveedores externos como Google o GitHub; y LDAP para directorios corporativos.
|
||||||
|
|
||||||
|
En resumen: la seguridad en Java EE puede ser declarativa mediante anotaciones o programática mediante código. Spring Security gestiona autenticación, autorización, protección CSRF y soporta JWT y OAuth2.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4. Plataforma .NET
|
||||||
|
|
||||||
|
### 4.1. Definición y componentes
|
||||||
|
|
||||||
|
.NET es la plataforma de desarrollo de Microsoft para crear aplicaciones web, de escritorio, servicios y aplicaciones móviles. Evolucionó desde .NET Framework en 2002, que solo funcionaba en Windows, pasando por .NET Core en 2016 que lo hizo multiplataforma para Windows, Linux y macOS, hasta la unificación bajo el nombre .NET a partir de la versión 5 en 2020. Sus componentes principales son: el CLR o Common Language Runtime, que es la máquina virtual equivalente a la JVM de Java y compila el código IL justo a tiempo con el compilador JIT; la BCL o Base Class Library, que son las librerías base del framework; ASP.NET Core para el desarrollo web; y Entity Framework Core como ORM.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 4.2. Lenguajes de .NET
|
||||||
|
|
||||||
|
Todos los lenguajes de .NET compilan a IL o Intermediate Language y se ejecutan en el CLR. El lenguaje principal es C#, que es orientado a objetos y se usa para aplicaciones empresariales, web y de escritorio. VB.NET es el sucesor del clásico Visual Basic y se usa principalmente en aplicaciones legacy de Windows. F# es un lenguaje funcional orientado al análisis de datos y la computación científica.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 4.3. Persistencia en .NET
|
||||||
|
|
||||||
|
ADO.NET es el acceso directo a bases de datos mediante SQL, equivalente a JDBC en Java. Sus clases principales son SqlConnection para la conexión, SqlCommand para ejecutar comandos, SqlDataReader para leer resultados y DataSet para almacenar datos en memoria. Entity Framework Core es el ORM de .NET, equivalente a JPA e Hibernate. Ofrece tres enfoques: Code First, en el que se definen primero las clases y Entity Framework genera la base de datos a partir de ellas; Database First, en el que se parte de una base de datos existente y Entity Framework genera las clases automáticamente; y Model First, en el que se diseña el modelo visual y Entity Framework genera tanto la base de datos como las clases. Las consultas se escriben con LINQ, o Language Integrated Query, que permite escribir consultas tipadas directamente en C# con verificación de tipos en tiempo de compilación, de forma similar a JPQL pero integrada en el lenguaje.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 4.4. Seguridad en .NET
|
||||||
|
|
||||||
|
La seguridad en .NET está integrada en ASP.NET Core mediante middleware. Se basa en claims y roles. Los métodos de autenticación soportados son: Windows Authentication para la integración con Active Directory y dominios corporativos; JWT o JSON Web Token para APIs REST sin estado; OAuth2 y OpenID Connect para delegación a proveedores externos; y autenticación basada en cookies para aplicaciones web tradicionales.
|
||||||
|
|
||||||
|
En resumen: .NET es la plataforma de Microsoft, multiplataforma desde .NET Core. Sus componentes clave son el CLR como máquina virtual, ASP.NET Core para web, ADO.NET para acceso SQL directo y Entity Framework Core como ORM. El lenguaje principal es C#.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 5. Comparativa Java EE vs .NET
|
||||||
|
|
||||||
|
Tanto Java EE como .NET son plataformas empresariales maduras con componentes equivalentes. Java EE usa la JVM como máquina virtual mientras que .NET usa el CLR. El lenguaje principal de Java EE es Java y el de .NET es C#. Para el desarrollo web, Java EE usa Spring MVC o JSF y .NET usa ASP.NET Core. Para la persistencia, Java EE usa JPA e Hibernate y .NET usa Entity Framework Core. Para el acceso SQL directo, Java EE usa JDBC y .NET usa ADO.NET. Para la seguridad, Java EE suele usar Spring Security y .NET tiene seguridad integrada en ASP.NET Core. Ambas plataformas son multiplataforma en sus versiones modernas, ambas son principalmente de código abierto, y la elección entre una y otra depende del ecosistema de la organización y del perfil del equipo de desarrollo.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 6. Desarrollo de interfaces
|
||||||
|
|
||||||
|
### 6.1. Tecnologías front-end
|
||||||
|
|
||||||
|
El front-end es la parte de la aplicación que se ejecuta en el navegador del usuario. Se desarrolla con tres tecnologías base: HTML para la estructura y el contenido de la página, CSS para la presentación y el diseño visual, y JavaScript para el comportamiento y la interactividad. Los frameworks de front-end más usados son Angular de Google, que es un framework completo que usa TypeScript; React de Meta, que es una librería de interfaz de usuario que usa JSX; y Vue, que es un framework progresivo mantenido por la comunidad.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 6.2. Comunicación cliente-servidor
|
||||||
|
|
||||||
|
La comunicación entre el front-end y el back-end se realiza mediante HTTP o HTTPS. Las arquitecturas de API más habituales son REST, que usa JSON como formato de datos, no mantiene estado entre peticiones y se apoya en los verbos HTTP; SOAP, que usa XML con un contrato formal definido mediante WSDL y se usa en entornos corporativos con requisitos estrictos de interoperabilidad; GraphQL, en el que el cliente especifica exactamente los datos que necesita, reduciendo el tráfico innecesario; y WebSocket, que permite comunicación bidireccional en tiempo real entre cliente y servidor.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 6.3. Tipos de aplicaciones web
|
||||||
|
|
||||||
|
Las aplicaciones web pueden clasificarse en varios tipos. Las MPA o Multi-Page Applications generan una nueva página completa desde el servidor en cada acción del usuario, usando tecnologías como Thymeleaf, JSP o Razor. Las SPA o Single-Page Applications cargan una única página inicial y actualizan el contenido dinámicamente mediante llamadas a una API, usando frameworks como Angular, React o Vue. Las PWA o Progressive Web Apps son SPA con capacidades adicionales como funcionamiento offline y notificaciones push, implementadas mediante Service Workers. Las SSR o Server-Side Rendering, como Next.js o Nuxt.js, combinan ambos modelos renderizando la página inicial en el servidor para mejorar el rendimiento y el posicionamiento en buscadores.
|
||||||
|
|
||||||
|
En resumen: el front-end usa HTML, CSS y JavaScript. Los frameworks más usados son Angular, React y Vue. La comunicación con el back-end se realiza principalmente mediante APIs REST con JSON sobre HTTPS. Las SPA son el modelo más habitual en aplicaciones modernas.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Miniresumen final del tema
|
||||||
|
|
||||||
|
Este tema cubre las dos grandes plataformas empresariales de desarrollo. Jakarta EE es la evolución de Java EE, gestionada por la Eclipse Foundation, que se ejecuta sobre servidores de aplicaciones como WildFly o GlassFish. Sus APIs principales son Servlet para gestionar HTTP, JPA para la persistencia mediante ORM con consultas en JPQL, JTA para las transacciones con propiedades ACID, y Spring Security para la autenticación y autorización. La persistencia en Java usa JDBC para acceso SQL directo o JPA e Hibernate como ORM. .NET es la plataforma de Microsoft con CLR como máquina virtual, C# como lenguaje principal, ASP.NET Core para web, ADO.NET para acceso SQL directo y Entity Framework Core como ORM con consultas en LINQ. Ambas plataformas son equivalentes y multiplataforma en sus versiones modernas. El desarrollo de interfaces usa HTML, CSS y JavaScript en el front-end, frameworks como Angular, React y Vue, y comunicación REST con JSON entre cliente y servidor.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,259 +1,318 @@
|
||||||
/* Apuntes de clase */
|
# Bloque 3 · Tema 6
|
||||||
|
# Arquitectura cliente/servidor y multicapas. Servicios web y protocolos.
|
||||||
Comunicacion
|
|
||||||
- Sincrona
|
|
||||||
- Asincrona
|
|
||||||
|
|
||||||
WS
|
|
||||||
|
|
||||||
# Tema 6 – Arquitectura cliente/servidor y multicapas. Servicios web y protocolos
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 1. Esquema general
|
# Esquema resumen
|
||||||
|
|
||||||
1. Arquitectura cliente/servidor
|
**Modelos arquitectónicos**
|
||||||
2. Arquitectura multicapas (n-tier)
|
|
||||||
3. Componentes principales
|
| Modelo | Descripción | Característica clave |
|
||||||
4. Funcionamiento (operación)
|
|---|---|---|
|
||||||
5. Arquitecturas de servicios web
|
| **Cliente/servidor** | Cliente solicita, servidor responde | Separación de roles |
|
||||||
6. Protocolos asociados
|
| **2 capas** | Cliente + servidor | Cliente pesado o ligero |
|
||||||
|
| **3 capas** | Presentación + lógica + datos | Forma más habitual |
|
||||||
|
| **N capas** | Multicapas con capa de servicios o integración | Aplicaciones complejas |
|
||||||
|
|
||||||
|
**Servicios web**
|
||||||
|
|
||||||
|
| Tecnología | Tipo | Formato | Descripción |
|
||||||
|
|---|---|---|---|
|
||||||
|
| **SOAP** | Protocolo | XML | Formal, contrato WSDL, empresarial |
|
||||||
|
| **REST** | Estilo arquitectónico | JSON | Ligero, verbos HTTP, API modernas |
|
||||||
|
| **GraphQL** | Lenguaje de consulta | JSON | Cliente define qué campos necesita |
|
||||||
|
| **gRPC** | Protocolo RPC | Protobuf | Alta eficiencia, microservicios |
|
||||||
|
| **WebSocket** | Protocolo bidireccional | Cualquiera | Tiempo real, persistente |
|
||||||
|
|
||||||
|
**Protocolos principales**
|
||||||
|
|
||||||
|
| Protocolo | Capa | Función |
|
||||||
|
|---|---|---|
|
||||||
|
| **HTTP/HTTPS** | Aplicación | Petición/respuesta web; HTTPS cifra con TLS |
|
||||||
|
| **TCP** | Transporte | Entrega fiable y ordenada |
|
||||||
|
| **IP** | Red | Direccionamiento y enrutamiento |
|
||||||
|
| **TLS** | Sesión/Presentación | Cifrado del canal; sucesor de SSL |
|
||||||
|
| **DNS** | Aplicación | Resolución de nombres a IPs |
|
||||||
|
| **FTP** | Aplicación | Transferencia de ficheros |
|
||||||
|
| **SMTP** | Aplicación | Envío de correo electrónico |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 2. Desarrollo
|
# 1. Arquitectura cliente/servidor
|
||||||
|
|
||||||
### 2.1 Arquitectura cliente/servidor
|
## 1.1. Definición y elementos
|
||||||
|
|
||||||
**Definición**
|
La arquitectura cliente/servidor es el modelo fundamental de distribución de aplicaciones. Un **cliente** realiza peticiones de servicios o recursos, y un **servidor** los proporciona. Ambos se comunican a través de una **red**.
|
||||||
Modelo en el que un cliente solicita servicios y un servidor los proporciona.
|
|
||||||
|
|
||||||
**Elementos**
|
Sus características principales son:
|
||||||
- Cliente: realiza peticiones
|
- **Separación de funciones**: el cliente gestiona la presentación; el servidor gestiona los datos y la lógica.
|
||||||
- Servidor: responde y gestiona recursos
|
- **Centralización de recursos**: los recursos compartidos (BD, ficheros, servicios) están en el servidor.
|
||||||
- Red: medio de comunicación
|
- **Escalabilidad**: se pueden añadir más servidores o clientes sin reestructurar la arquitectura.
|
||||||
|
- **Heterogeneidad**: cliente y servidor pueden usar plataformas distintas si se comunican mediante protocolos estándar.
|
||||||
**Características**
|
|
||||||
- Separación de funciones
|
|
||||||
- Centralización de recursos
|
|
||||||
- Escalabilidad
|
|
||||||
- Comunicación por red
|
|
||||||
|
|
||||||
**Tipos**
|
|
||||||
- Modelo de 2 capas
|
|
||||||
- Cliente pesado (thick client)
|
|
||||||
- Cliente ligero (thin client)
|
|
||||||
|
|
||||||
**Ejemplo**
|
|
||||||
- Navegador web (cliente)
|
|
||||||
- Servidor web (servidor)
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
### 2.2 Arquitectura multicapas (n-tier)
|
## 1.2. Tipos de cliente
|
||||||
|
|
||||||
**Definición**
|
| Tipo | Descripción | Ejemplo |
|
||||||
Modelo que divide la aplicación en varias capas independientes.
|
|---|---|---|
|
||||||
|
| **Cliente pesado** (thick/fat client) | Mayor parte de la lógica en el cliente; el servidor solo aporta datos | Aplicación de escritorio con BD remota |
|
||||||
|
| **Cliente ligero** (thin client) | Casi toda la lógica en el servidor; el cliente solo gestiona la presentación | Navegador web con servidor de aplicaciones |
|
||||||
|
| **Cliente mixto** | Reparte la lógica entre cliente y servidor | SPA (Angular/React) con API REST |
|
||||||
|
|
||||||
**Capas principales**
|
Los clientes ligeros son los más habituales en entornos empresariales actuales porque facilitan el mantenimiento centralizado.
|
||||||
1. Capa de presentación
|
|
||||||
- Interfaz de usuario
|
|
||||||
2. Capa de lógica de negocio
|
|
||||||
- Procesamiento y reglas
|
|
||||||
3. Capa de datos
|
|
||||||
- Acceso a bases de datos
|
|
||||||
|
|
||||||
**Capas adicionales (opcional)**
|
|
||||||
- Capa de servicios
|
|
||||||
- Capa de integración
|
|
||||||
|
|
||||||
**Ventajas**
|
|
||||||
- Modularidad
|
|
||||||
- Mantenimiento sencillo
|
|
||||||
- Escalabilidad
|
|
||||||
- Reutilización
|
|
||||||
|
|
||||||
**Importante**
|
|
||||||
Cliente/servidor es un modelo general, mientras que multicapas define la estructura interna de la aplicación.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
### 2.3 Componentes principales
|
# 2. Arquitectura multicapas (n-tier)
|
||||||
|
|
||||||
**En cliente/servidor**
|
## 2.1. Capas principales
|
||||||
- Cliente
|
|
||||||
- Servidor
|
|
||||||
- Red
|
|
||||||
|
|
||||||
**En multicapas**
|
La arquitectura multicapas divide la aplicación en capas independientes, cada una con una responsabilidad bien definida. La separación de responsabilidades facilita el mantenimiento, la escalabilidad y la reutilización.
|
||||||
- Front-end (presentación)
|
|
||||||
- Back-end (lógica)
|
**Tres capas clásicas:**
|
||||||
- Base de datos
|
|
||||||
- Middleware
|
| Capa | Responsabilidad | Tecnologías típicas |
|
||||||
|
|---|---|---|
|
||||||
|
| **Presentación** | Interfaz de usuario | HTML/CSS/JS, Thymeleaf, React, Angular |
|
||||||
|
| **Lógica de negocio** | Procesamiento y reglas de la aplicación | Java EE, Spring, .NET |
|
||||||
|
| **Datos** | Persistencia y acceso a la BD | JDBC, JPA, SQL, ORM |
|
||||||
|
|
||||||
|
**Capas adicionales:**
|
||||||
|
- **Capa de servicios**: expone funcionalidad como servicios web (REST/SOAP).
|
||||||
|
- **Capa de integración**: adapta la comunicación con sistemas externos.
|
||||||
|
- **Middleware**: software intermediario que actúa entre capas (MOM, ESB).
|
||||||
|
|
||||||
|
**Ventajas:**
|
||||||
|
- Modularidad: cada capa puede desarrollarse y desplegarse de forma independiente.
|
||||||
|
- Mantenimiento: los cambios en una capa no afectan a las demás si se respeta el contrato.
|
||||||
|
- Escalabilidad: se puede escalar cada capa de forma independiente.
|
||||||
|
- Seguridad: las capas actúan como barreras entre el exterior y los datos.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
### 2.4 Funcionamiento (operación) – Comunicación síncrona y asíncrona
|
## 2.2. Relación con cliente/servidor
|
||||||
|
|
||||||
**Comunicación síncrona**
|
Cliente/servidor y multicapas no son excluyentes: un sistema puede ser cliente/servidor (dos extremos que se comunican) y a la vez estar organizado en múltiples capas internamente.
|
||||||
- El cliente envía una petición y **espera la respuesta** del servidor.
|
|
||||||
- La ejecución queda bloqueada hasta recibir respuesta.
|
|
||||||
- Es el modelo clásico en HTTP.
|
|
||||||
|
|
||||||
**Ejemplo**
|
| Concepto | Alcance |
|
||||||
- Un navegador solicita una página web y espera a que el servidor responda.
|
|---|---|
|
||||||
|
| **Cliente/servidor** | Modelo general de comunicación entre dos extremos |
|
||||||
|
| **Multicapas** | Organización interna de la aplicación |
|
||||||
|
|
||||||
**Ventajas**
|
Un navegador web actúa de cliente; el back-end (organizado en 3 capas) actúa de servidor.
|
||||||
- Simplicidad
|
|
||||||
- Fácil de implementar
|
|
||||||
|
|
||||||
**Inconvenientes**
|
|
||||||
- Menor rendimiento en sistemas distribuidos
|
|
||||||
- Bloqueo del cliente
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
**Comunicación asíncrona**
|
# 3. Comunicación síncrona y asíncrona
|
||||||
- El cliente envía una petición y **no espera inmediatamente la respuesta**.
|
|
||||||
- Puede seguir ejecutando otras tareas.
|
|
||||||
- La respuesta llega posteriormente (callback, cola, eventos).
|
|
||||||
|
|
||||||
**Ejemplo**
|
## 3.1. Comunicación síncrona
|
||||||
- Sistemas de mensajería (colas de mensajes)
|
|
||||||
- Notificaciones push
|
|
||||||
- Procesos en segundo plano
|
|
||||||
|
|
||||||
**Ventajas**
|
En la comunicación síncrona el cliente envía una petición y **queda bloqueado** hasta recibir la respuesta del servidor. Es el modelo clásico de HTTP.
|
||||||
- Mayor escalabilidad
|
|
||||||
- Mejor rendimiento
|
|
||||||
- No bloquea procesos
|
|
||||||
|
|
||||||
**Inconvenientes**
|
| Aspecto | Detalle |
|
||||||
- Mayor complejidad
|
|---|---|
|
||||||
- Gestión de estados más difícil
|
| **Comportamiento** | Bloqueante: el cliente espera |
|
||||||
|
| **Modelo** | Petición → bloqueo → respuesta |
|
||||||
|
| **Ejemplo** | Navegador solicita una página; espera la respuesta |
|
||||||
|
| **Ventaja** | Simplicidad, fácil de implementar y depurar |
|
||||||
|
| **Inconveniente** | Bloqueo; menor rendimiento en alta concurrencia |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
**Clave de examen**
|
## 3.2. Comunicación asíncrona y colas de mensajes
|
||||||
- HTTP tradicional → síncrono
|
|
||||||
- Sistemas distribuidos modernos → combinan síncrono y asíncrono
|
En la comunicación asíncrona el cliente envía una petición y **no bloquea**: puede seguir ejecutando otras tareas. La respuesta llega posteriormente mediante un callback, un evento o una cola de mensajes.
|
||||||
- La asincronía es clave en arquitecturas escalables (microservicios, colas, eventos)
|
|
||||||
|
| Aspecto | Detalle |
|
||||||
|
|---|---|
|
||||||
|
| **Comportamiento** | No bloqueante |
|
||||||
|
| **Mecanismos** | Callbacks, eventos, colas de mensajes, WebSocket |
|
||||||
|
| **Ventaja** | Mayor escalabilidad y rendimiento |
|
||||||
|
| **Inconveniente** | Mayor complejidad; gestión de estado más difícil |
|
||||||
|
|
||||||
|
**Sistemas de colas de mensajes (MOM — Message-Oriented Middleware):**
|
||||||
|
- **JMS** (Java Message Service): API estándar de Jakarta EE para mensajería asíncrona.
|
||||||
|
- **RabbitMQ**: broker de mensajes con soporte AMQP.
|
||||||
|
- **Apache Kafka**: plataforma de streaming de eventos de alto rendimiento.
|
||||||
|
|
||||||
|
Los patrones de mensajería más comunes son:
|
||||||
|
- **Punto a punto** (Queue): un productor envía a una cola; un consumidor la lee.
|
||||||
|
- **Publicación/suscripción** (Topic): un productor publica en un topic; múltiples consumidores suscritos lo reciben.
|
||||||
|
|
||||||
|
Clave de examen: HTTP es síncrono; microservicios y arquitecturas de eventos combinan síncrono y asíncrono; la asincronía es fundamental para la escalabilidad.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
### 2.5 Arquitecturas de servicios web – WS (Web Services)
|
# 4. Servicios web
|
||||||
|
|
||||||
**WS (Web Services)**
|
## 4.1. SOAP
|
||||||
Son **servicios web** que permiten la comunicación entre aplicaciones a través de una red, independientemente del lenguaje o sistema.
|
|
||||||
|
**SOAP** (Simple Object Access Protocol) es un **protocolo** de comunicación entre aplicaciones basado en XML. Es el modelo clásico de servicios web empresariales.
|
||||||
|
|
||||||
|
| Elemento | Descripción |
|
||||||
|
|---|---|
|
||||||
|
| **SOAP** | Protocolo de mensajería en XML |
|
||||||
|
| **WSDL** | Web Services Description Language; describe la interfaz del servicio (operaciones, parámetros, tipos) en XML |
|
||||||
|
| **UDDI** | Universal Description, Discovery and Integration; registro para descubrir servicios web |
|
||||||
|
| **WS-Security** | Extensión de seguridad: cifrado, firma y autenticación a nivel de mensaje |
|
||||||
|
|
||||||
|
**Estructura de un mensaje SOAP:**
|
||||||
|
- **Envelope**: elemento raíz obligatorio.
|
||||||
|
- **Header**: cabeceras opcionales (seguridad, transacciones).
|
||||||
|
- **Body**: contenido del mensaje (petición o respuesta).
|
||||||
|
- **Fault**: información de error.
|
||||||
|
|
||||||
|
**Características:**
|
||||||
|
- Protocolo formal y estricto.
|
||||||
|
- Independiente del transporte (puede ir sobre HTTP, SMTP, TCP).
|
||||||
|
- Soporte nativo para transacciones distribuidas y seguridad a nivel de mensaje.
|
||||||
|
- Adecuado para integraciones B2B y entornos que requieren contratos formales.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
**Características**
|
## 4.2. REST
|
||||||
- Interoperabilidad (distintos sistemas se comunican)
|
|
||||||
- Uso de estándares abiertos
|
**REST** (Representational State Transfer) es un **estilo arquitectónico**, no un protocolo. Lo definió Roy Fielding en su tesis doctoral de 2000. Una API que cumple los principios REST se denomina **RESTful**.
|
||||||
- Comunicación a través de red (normalmente HTTP)
|
|
||||||
- Orientados a servicios
|
**Principios REST (restricciones):**
|
||||||
|
|
||||||
|
| Principio | Descripción |
|
||||||
|
|---|---|
|
||||||
|
| **Sin estado** (stateless) | Cada petición contiene toda la información necesaria; el servidor no guarda estado de sesión |
|
||||||
|
| **Interfaz uniforme** | Recursos identificados por URI; representaciones estándar (JSON, XML) |
|
||||||
|
| **Sistema en capas** | El cliente no sabe si hay intermediarios (proxy, caché, balanceador) |
|
||||||
|
| **Caché** | Las respuestas pueden ser cacheables para mejorar el rendimiento |
|
||||||
|
| **Cliente/servidor** | Separación clara entre cliente y servidor |
|
||||||
|
| **Código bajo demanda** (opcional) | El servidor puede enviar código ejecutable al cliente (JS) |
|
||||||
|
|
||||||
|
**Verbos HTTP en REST:**
|
||||||
|
|
||||||
|
| Verbo | Operación CRUD | Ejemplo |
|
||||||
|
|---|---|---|
|
||||||
|
| **GET** | Read (lectura) | `GET /usuarios/1` → obtener usuario 1 |
|
||||||
|
| **POST** | Create (creación) | `POST /usuarios` → crear usuario |
|
||||||
|
| **PUT** | Update completo | `PUT /usuarios/1` → reemplazar usuario 1 |
|
||||||
|
| **PATCH** | Update parcial | `PATCH /usuarios/1` → modificar campo |
|
||||||
|
| **DELETE** | Delete | `DELETE /usuarios/1` → eliminar usuario 1 |
|
||||||
|
|
||||||
|
**Códigos de estado HTTP:**
|
||||||
|
|
||||||
|
| Rango | Categoría | Ejemplos |
|
||||||
|
|---|---|---|
|
||||||
|
| **2xx** | Éxito | 200 OK, 201 Created, 204 No Content |
|
||||||
|
| **3xx** | Redirección | 301 Moved Permanently, 304 Not Modified |
|
||||||
|
| **4xx** | Error del cliente | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found |
|
||||||
|
| **5xx** | Error del servidor | 500 Internal Server Error, 503 Service Unavailable |
|
||||||
|
|
||||||
|
**Diferencias SOAP vs REST:**
|
||||||
|
|
||||||
|
| Aspecto | SOAP | REST |
|
||||||
|
|---|---|---|
|
||||||
|
| Tipo | Protocolo | Estilo arquitectónico |
|
||||||
|
| Formato | XML obligatorio | JSON (principalmente), XML, otros |
|
||||||
|
| Contrato | WSDL | OpenAPI/Swagger (recomendado) |
|
||||||
|
| Transporte | HTTP, SMTP, TCP... | HTTP/HTTPS |
|
||||||
|
| Estado | Puede ser con estado | Sin estado (stateless) |
|
||||||
|
| Uso | Empresarial, B2B, legado | APIs modernas, microservicios, móvil |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
**Tipos de Web Services**
|
## 4.3. Otras arquitecturas de servicios
|
||||||
|
|
||||||
**1. SOAP (Web Services clásicos)**
|
**GraphQL:**
|
||||||
- Basados en XML
|
- Desarrollado por Meta (Facebook) en 2015.
|
||||||
- Protocolo formal y estricto
|
- El cliente especifica exactamente qué campos necesita: evita el overfetching (recibir más datos de los necesarios) y el underfetching (necesitar múltiples llamadas).
|
||||||
- Utilizan:
|
- Una única URL de endpoint; las consultas se envían como `query` en el cuerpo de la petición.
|
||||||
- SOAP → formato de mensajes
|
- Adecuado para aplicaciones con clientes variados (web, móvil) que necesitan datos distintos.
|
||||||
- WSDL → descripción del servicio
|
|
||||||
- Más pesados pero más estandarizados
|
**gRPC:**
|
||||||
|
- Desarrollado por Google; usa HTTP/2 y Protocol Buffers (Protobuf) como formato binario.
|
||||||
|
- Muy eficiente y de bajo latencia; adecuado para comunicación entre microservicios internos.
|
||||||
|
- Los contratos se definen en ficheros `.proto`.
|
||||||
|
- Admite streaming bidireccional.
|
||||||
|
|
||||||
|
**WebSocket:**
|
||||||
|
- Protocolo que establece una conexión persistente y bidireccional entre cliente y servidor sobre TCP.
|
||||||
|
- A diferencia de HTTP (sin estado, petición/respuesta), la conexión se mantiene abierta.
|
||||||
|
- Usos típicos: chat en tiempo real, notificaciones push, juegos online, dashboards en vivo.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
**2. REST (estilo arquitectónico)**
|
# 5. Protocolos asociados
|
||||||
- Más ligero
|
|
||||||
- Usa HTTP directamente (GET, POST, PUT, DELETE)
|
## 5.1. HTTP/HTTPS
|
||||||
- Datos en JSON (principalmente)
|
|
||||||
- Más utilizado actualmente
|
**HTTP** (HyperText Transfer Protocol) es el protocolo de la capa de aplicación que define cómo se comunican cliente y servidor en la web. Opera sobre TCP.
|
||||||
|
|
||||||
|
| Versión | Características clave |
|
||||||
|
|---|---|
|
||||||
|
| **HTTP/1.1** | Conexiones persistentes; pipeline; cabeceras en texto |
|
||||||
|
| **HTTP/2** | Multiplexación de streams; cabeceras comprimidas (HPACK); mayor rendimiento |
|
||||||
|
| **HTTP/3** | Basado en QUIC (UDP); menor latencia; conexiones más rápidas |
|
||||||
|
|
||||||
|
**Cabeceras HTTP relevantes:**
|
||||||
|
- `Content-Type`: tipo MIME del cuerpo (application/json, text/html).
|
||||||
|
- `Authorization`: credenciales (Bearer token, Basic auth).
|
||||||
|
- `Cache-Control`: directivas de caché.
|
||||||
|
- `Cookie` / `Set-Cookie`: gestión de sesiones.
|
||||||
|
|
||||||
|
**HTTPS** = HTTP + **TLS**. Garantiza confidencialidad (cifrado), integridad (no manipulación) y autenticación del servidor (certificado).
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
**Ejemplo sencillo**
|
## 5.2. TCP/IP y SSL/TLS
|
||||||
|
|
||||||
Una aplicación pide datos de un usuario:
|
**TCP/IP** es el conjunto de protocolos base de internet. Corresponde a las capas 3 y 4 del modelo OSI.
|
||||||
|
|
||||||
- Cliente → petición HTTP (REST)
|
| Protocolo | Capa | Función |
|
||||||
- Servidor → devuelve JSON con los datos
|
|---|---|---|
|
||||||
|
| **IP** | Red (3) | Direccionamiento y enrutamiento de paquetes |
|
||||||
|
| **TCP** | Transporte (4) | Transmisión fiable, orientada a conexión, ordenada |
|
||||||
|
| **UDP** | Transporte (4) | Transmisión no fiable, sin conexión, más rápida |
|
||||||
|
|
||||||
|
TCP garantiza la entrega mediante el mecanismo de three-way handshake (SYN, SYN-ACK, ACK) y la retransmisión de paquetes perdidos. HTTP, HTTPS, FTP y SMTP usan TCP. DNS y algunos servicios de streaming usan UDP.
|
||||||
|
|
||||||
|
**TLS** (Transport Layer Security) es el protocolo que proporciona seguridad en la comunicación:
|
||||||
|
- **Confidencialidad**: cifrado asimétrico para el intercambio de claves, simétrico para el flujo de datos.
|
||||||
|
- **Integridad**: MAC (Message Authentication Code) para detectar modificaciones.
|
||||||
|
- **Autenticación**: certificados X.509 firmados por una CA (Autoridad Certificadora).
|
||||||
|
|
||||||
|
TLS 1.2 y TLS 1.3 son las versiones actuales; SSL está obsoleto y no debe usarse.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
**Relación con el temario**
|
## 5.3. Otros protocolos de aplicación
|
||||||
- WS = forma de implementar **arquitectura cliente/servidor distribuida**
|
|
||||||
- Muy usado en arquitecturas multicapas
|
| Protocolo | Puerto | Función |
|
||||||
- Base de APIs modernas
|
|---|---|---|
|
||||||
|
| **FTP** | 21 (control), 20 (datos) | Transferencia de ficheros |
|
||||||
|
| **SFTP** | 22 | FTP seguro sobre SSH |
|
||||||
|
| **SMTP** | 25 / 587 | Envío de correo electrónico |
|
||||||
|
| **IMAP** | 143 / 993 | Acceso a buzón de correo (sincronizado) |
|
||||||
|
| **POP3** | 110 / 995 | Descarga de correo (local) |
|
||||||
|
| **DNS** | 53 | Resolución de nombres de dominio a IPs |
|
||||||
|
| **LDAP** | 389 / 636 | Directorio de usuarios (Active Directory) |
|
||||||
|
| **SSH** | 22 | Acceso remoto seguro a servidores |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
**Trampas típicas de examen**
|
# Miniresumen final del tema
|
||||||
- WS no es solo SOAP → REST también es Web Service
|
|
||||||
- SOAP = protocolo
|
|
||||||
- REST = estilo arquitectónico (no protocolo)
|
|
||||||
- JSON → típico de REST
|
|
||||||
- XML → típico de SOAP
|
|
||||||
|
|
||||||
---
|
| Concepto | Clave |
|
||||||
|
|---|---|
|
||||||
**Resumen rápido**
|
| **Cliente/servidor** | Cliente solicita, servidor responde; comunicación por red |
|
||||||
- WS = comunicación entre aplicaciones
|
| **Cliente pesado** | Lógica en el cliente |
|
||||||
- SOAP (XML, pesado, formal)
|
| **Cliente ligero** | Lógica en el servidor; ej. navegador |
|
||||||
- REST (JSON, ligero, actual)
|
| **Multicapas (3 capas)** | Presentación + lógica de negocio + datos |
|
||||||
|
| **Comunicación síncrona** | Bloqueante; modelo HTTP clásico |
|
||||||
---
|
| **Comunicación asíncrona** | No bloqueante; colas JMS, RabbitMQ, Kafka |
|
||||||
|
| **SOAP** | Protocolo; XML; WSDL; formal; empresarial |
|
||||||
### 2.6 Protocolos asociados
|
| **REST** | Estilo arquitectónico; JSON; verbos HTTP; stateless |
|
||||||
|
| **GraphQL** | Cliente define los campos que necesita; Meta |
|
||||||
**HTTP / HTTPS**
|
| **gRPC** | RPC binario (Protobuf); HTTP/2; microservicios |
|
||||||
- Protocolo principal de la web
|
| **WebSocket** | Bidireccional; tiempo real; conexión persistente |
|
||||||
- Modelo petición/respuesta
|
| **HTTP** | Protocolo web; petición/respuesta; sobre TCP |
|
||||||
- HTTPS añade seguridad mediante cifrado
|
| **HTTPS** | HTTP + TLS; cifrado, integridad, autenticación |
|
||||||
|
| **TLS** | Seguridad del canal; sucesor de SSL |
|
||||||
**TCP/IP**
|
| **TCP** | Transporte fiable y ordenado |
|
||||||
- Base de las comunicaciones en red
|
|
||||||
- TCP: transmisión fiable
|
|
||||||
- IP: direccionamiento
|
|
||||||
|
|
||||||
**SSL/TLS**
|
|
||||||
- Protocolos de seguridad
|
|
||||||
- Proporcionan cifrado
|
|
||||||
|
|
||||||
**Otros protocolos**
|
|
||||||
- FTP: transferencia de archivos
|
|
||||||
- SMTP: envío de correo
|
|
||||||
- DNS: resolución de nombres
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 3. Ejemplo práctico
|
|
||||||
|
|
||||||
Aplicación web:
|
|
||||||
|
|
||||||
- Cliente: navegador
|
|
||||||
- Presentación: HTML, CSS, JavaScript
|
|
||||||
- Lógica: servidor de aplicaciones
|
|
||||||
- Datos: base de datos
|
|
||||||
|
|
||||||
Flujo:
|
|
||||||
1. Usuario realiza una acción
|
|
||||||
2. Se envía una petición HTTP
|
|
||||||
3. El servidor procesa la lógica
|
|
||||||
4. Consulta la base de datos
|
|
||||||
5. Devuelve la respuesta
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 4. Miniresumen
|
|
||||||
|
|
||||||
- Cliente/servidor: el cliente solicita y el servidor responde
|
|
||||||
- Multicapas: separación en presentación, lógica y datos
|
|
||||||
- Ventajas: modularidad, mantenimiento y escalabilidad
|
|
||||||
- Servicios web: comunicación entre aplicaciones
|
|
||||||
- REST es el modelo más utilizado actualmente
|
|
||||||
- Protocolos clave: HTTP/HTTPS, TCP/IP, SSL/TLS
|
|
||||||
|
|
@ -6,6 +6,164 @@ Este tema estudia los modelos arquitectónicos de las aplicaciones distribuidas,
|
||||||
|
|
||||||
## 1. Arquitectura cliente/servidor
|
## 1. Arquitectura cliente/servidor
|
||||||
|
|
||||||
|
### 1.1. Definición y elementos
|
||||||
|
|
||||||
|
La arquitectura cliente/servidor es el modelo fundamental de las aplicaciones distribuidas. En este modelo un cliente solicita servicios o recursos y un servidor los proporciona, comunicándose a través de una red.
|
||||||
|
|
||||||
|
Los tres elementos de esta arquitectura son el cliente, que realiza las peticiones; el servidor, que responde y gestiona los recursos; y la red, que es el medio de comunicación entre ambos.
|
||||||
|
|
||||||
|
Sus características principales son la separación de funciones entre cliente y servidor, la centralización de los recursos en el servidor, la escalabilidad porque se pueden añadir más clientes o servidores sin reestructurar la arquitectura, y la heterogeneidad porque cliente y servidor pueden usar plataformas distintas si se comunican mediante protocolos estándar.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 1.2. Tipos de cliente
|
||||||
|
|
||||||
|
El modelo de dos capas es la forma básica de cliente/servidor. A partir de ahí se distinguen dos tipos de cliente.
|
||||||
|
|
||||||
|
El cliente pesado o thick client es aquel en el que la mayor parte de la lógica reside en el cliente. El servidor solo aporta los datos. Un ejemplo es una aplicación de escritorio que se conecta a una base de datos remota. Este modelo requiere instalar y mantener el software en cada equipo cliente.
|
||||||
|
|
||||||
|
El cliente ligero o thin client es aquel en el que casi toda la lógica está en el servidor y el cliente solo gestiona la presentación. El ejemplo más claro es el navegador web junto a un servidor de aplicaciones. Es el modelo más habitual en entornos empresariales actuales porque facilita el mantenimiento centralizado en el servidor. El cliente mixto reparte la lógica entre cliente y servidor, como ocurre en las SPA que combinan Angular o React con una API REST.
|
||||||
|
|
||||||
|
En resumen: en el modelo cliente/servidor el cliente solicita y el servidor responde. El cliente ligero, cuyo ejemplo es el navegador web, es el más habitual hoy en día.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. Arquitectura multicapas (n-tier)
|
||||||
|
|
||||||
|
### 2.1. Capas principales
|
||||||
|
|
||||||
|
La arquitectura multicapas divide la aplicación en capas independientes, cada una con una responsabilidad bien definida. La separación de responsabilidades facilita el mantenimiento, la escalabilidad y la reutilización.
|
||||||
|
|
||||||
|
Las tres capas clásicas son las siguientes. La capa de presentación gestiona la interfaz de usuario y se implementa con tecnologías como HTML, CSS, JavaScript o frameworks como React, Angular o Thymeleaf. La capa de lógica de negocio contiene el procesamiento y las reglas de la aplicación y se implementa con Java EE, Spring o .NET. La capa de datos gestiona la persistencia y el acceso a la base de datos mediante JDBC, JPA u ORM.
|
||||||
|
|
||||||
|
A estas tres capas se pueden añadir otras opcionales: la capa de servicios expone la funcionalidad como servicios web REST o SOAP; la capa de integración adapta la comunicación con sistemas externos; y el middleware actúa como intermediario entre capas, como un bus de mensajes o un ESB.
|
||||||
|
|
||||||
|
Las ventajas son la modularidad, porque cada capa puede desarrollarse de forma independiente; el mantenimiento, porque los cambios en una capa no afectan a las demás si se respeta el contrato entre ellas; la escalabilidad, porque se puede escalar cada capa por separado; y la seguridad, porque las capas actúan como barreras entre el exterior y los datos.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 2.2. Relación con cliente/servidor
|
||||||
|
|
||||||
|
Cliente/servidor y multicapas no son excluyentes. Un sistema puede ser cliente/servidor, con dos extremos que se comunican, y a la vez estar organizado internamente en múltiples capas.
|
||||||
|
|
||||||
|
La diferencia clave es el alcance: cliente/servidor es un modelo general que describe la interacción entre dos extremos; la arquitectura multicapas define la organización interna de la aplicación. Un navegador web actúa como cliente ligero; el back-end que le responde puede estar organizado en tres o más capas internas.
|
||||||
|
|
||||||
|
En resumen: la arquitectura multicapas organiza la aplicación en tres capas fundamentales: presentación, lógica de negocio y datos. Se complementa con cliente/servidor porque define la estructura interna del servidor.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. Comunicación síncrona y asíncrona
|
||||||
|
|
||||||
|
### 3.1. Comunicación síncrona
|
||||||
|
|
||||||
|
En la comunicación síncrona el cliente envía una petición y queda bloqueado hasta recibir la respuesta del servidor. Es el modelo clásico de HTTP: un navegador solicita una página web y espera hasta que el servidor la devuelve completa. La ejecución del cliente no continúa hasta haber recibido la respuesta.
|
||||||
|
|
||||||
|
Sus ventajas son la simplicidad y la facilidad para implementar y depurar. Su principal inconveniente es el bloqueo: si la respuesta tarda, el cliente no puede hacer nada más. Esto reduce el rendimiento en sistemas con alta concurrencia o respuestas lentas.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 3.2. Comunicación asíncrona y colas de mensajes
|
||||||
|
|
||||||
|
En la comunicación asíncrona el cliente envía una petición y no bloquea: puede seguir ejecutando otras tareas mientras la respuesta llega posteriormente mediante un callback, un evento o una cola de mensajes.
|
||||||
|
|
||||||
|
Su ventaja es la mayor escalabilidad y rendimiento porque el sistema no se detiene a esperar. Su inconveniente es la mayor complejidad para gestionar el estado y coordinar los resultados.
|
||||||
|
|
||||||
|
Los sistemas de colas de mensajes, también llamados MOM o Message-Oriented Middleware, son la tecnología principal para la comunicación asíncrona. JMS es la API estándar de Jakarta EE para mensajería asíncrona. RabbitMQ es un broker de mensajes que soporta el protocolo AMQP. Apache Kafka es una plataforma de streaming de eventos de alto rendimiento muy usada en microservicios.
|
||||||
|
|
||||||
|
Los patrones de mensajería más comunes son dos. En el patrón punto a punto o queue, un productor envía mensajes a una cola y un único consumidor los lee. En el patrón publicación y suscripción o topic, un productor publica en un topic y todos los consumidores suscritos reciben el mensaje.
|
||||||
|
|
||||||
|
La clave para el examen es que HTTP es síncrono; las arquitecturas de microservicios y sistemas distribuidos modernos combinan síncrono y asíncrono; y la asincronía es fundamental para la escalabilidad.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4. Servicios web
|
||||||
|
|
||||||
|
### 4.1. SOAP
|
||||||
|
|
||||||
|
SOAP, que son las siglas de Simple Object Access Protocol, es un protocolo de comunicación entre aplicaciones basado en XML. Es el modelo clásico de servicios web empresariales.
|
||||||
|
|
||||||
|
SOAP se compone de varios elementos. El propio protocolo SOAP define el formato de los mensajes en XML. WSDL, o Web Services Description Language, es el lenguaje que describe la interfaz del servicio: sus operaciones, parámetros y tipos de datos. Es el contrato formal del servicio. UDDI, o Universal Description Discovery and Integration, es un registro para publicar y descubrir servicios web. WS-Security es la extensión que añade seguridad a nivel de mensaje: cifrado, firma digital y autenticación.
|
||||||
|
|
||||||
|
La estructura de un mensaje SOAP tiene cuatro partes: el Envelope es el elemento raíz obligatorio que envuelve todo el mensaje; el Header contiene cabeceras opcionales para seguridad o transacciones; el Body contiene el contenido real de la petición o la respuesta; y el Fault proporciona información de error cuando algo falla.
|
||||||
|
|
||||||
|
Sus características son que es un protocolo formal y estricto, es independiente del transporte porque puede viajar sobre HTTP, SMTP o TCP, y soporta transacciones distribuidas y seguridad a nivel de mensaje. Es adecuado para integraciones entre empresas y entornos que requieren contratos formales y auditoría.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 4.2. REST
|
||||||
|
|
||||||
|
REST, que son las siglas de Representational State Transfer, es un estilo arquitectónico, no un protocolo. Lo definió Roy Fielding en su tesis doctoral del año 2000. Una API que cumple los principios REST se denomina RESTful.
|
||||||
|
|
||||||
|
Los principios REST son los siguientes. El principio sin estado o stateless establece que cada petición contiene toda la información necesaria y el servidor no guarda estado de sesión entre peticiones. La interfaz uniforme define que los recursos se identifican por URI y se intercambian mediante representaciones estándar como JSON o XML. El sistema en capas significa que el cliente no sabe si hay intermediarios entre él y el servidor. La caché indica que las respuestas pueden marcarse como cacheables para mejorar el rendimiento. La separación cliente/servidor establece una separación clara entre ambos extremos.
|
||||||
|
|
||||||
|
Los verbos HTTP en REST se corresponden con las operaciones CRUD: GET para leer un recurso, POST para crearlo, PUT para reemplazarlo completamente, PATCH para modificarlo parcialmente y DELETE para eliminarlo.
|
||||||
|
|
||||||
|
Los códigos de estado HTTP se agrupan en rangos. Los códigos 2xx indican éxito: 200 OK, 201 Created para una creación exitosa, 204 No Content cuando no hay cuerpo de respuesta. Los códigos 3xx indican redirección. Los códigos 4xx indican errores del cliente: 400 Bad Request, 401 Unauthorized cuando no hay credenciales, 403 Forbidden cuando las credenciales no tienen permiso, 404 Not Found. Los códigos 5xx indican errores del servidor: 500 Internal Server Error, 503 Service Unavailable.
|
||||||
|
|
||||||
|
Las diferencias clave entre SOAP y REST para el examen son las siguientes: SOAP es un protocolo y REST es un estilo arquitectónico; SOAP usa XML obligatoriamente y REST usa principalmente JSON; SOAP tiene un contrato formal en WSDL y REST se documenta opcionalmente con OpenAPI o Swagger; SOAP puede viajar sobre distintos transportes y REST usa HTTP; y SOAP se usa en entornos empresariales y legados mientras que REST es el estándar en APIs modernas y microservicios.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 4.3. Otras arquitecturas de servicios
|
||||||
|
|
||||||
|
GraphQL fue desarrollado por Meta en 2015 y es un lenguaje de consulta para APIs. Su característica diferencial es que el cliente especifica exactamente qué campos necesita en la respuesta, lo que evita el overfetching, que es recibir más datos de los necesarios, y el underfetching, que es necesitar múltiples llamadas para obtener todos los datos. Usa un único endpoint URL y las consultas se envían en el cuerpo de la petición.
|
||||||
|
|
||||||
|
gRPC fue desarrollado por Google y usa el protocolo HTTP/2 y el formato binario Protocol Buffers, también llamado Protobuf, como formato de serialización. Es muy eficiente y de baja latencia, lo que lo hace adecuado para la comunicación interna entre microservicios. Los contratos se definen en ficheros con extensión proto. Admite streaming bidireccional.
|
||||||
|
|
||||||
|
WebSocket es un protocolo que establece una conexión persistente y bidireccional entre cliente y servidor sobre TCP. A diferencia de HTTP, que es sin estado y sigue el modelo petición y respuesta, la conexión WebSocket se mantiene abierta y tanto cliente como servidor pueden enviar mensajes en cualquier momento. Sus usos típicos son el chat en tiempo real, las notificaciones push, los juegos online y los dashboards con datos en vivo.
|
||||||
|
|
||||||
|
En resumen: SOAP es el protocolo clásico con XML y WSDL. REST es el estilo arquitectónico moderno con JSON y verbos HTTP. GraphQL da control al cliente sobre los datos que recibe. gRPC es eficiente y binario para microservicios. WebSocket proporciona comunicación bidireccional en tiempo real.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 5. Protocolos asociados
|
||||||
|
|
||||||
|
### 5.1. HTTP/HTTPS
|
||||||
|
|
||||||
|
HTTP, o HyperText Transfer Protocol, es el protocolo de la capa de aplicación que define cómo se comunican cliente y servidor en la web. Opera sobre TCP. Ha evolucionado en tres versiones principales.
|
||||||
|
|
||||||
|
HTTP 1.1 introdujo las conexiones persistentes que evitan abrir una nueva conexión TCP por cada recurso, y el pipeline para enviar múltiples peticiones seguidas. Las cabeceras se transmiten en texto plano.
|
||||||
|
|
||||||
|
HTTP 2 introdujo la multiplexación de streams, que permite enviar múltiples peticiones y respuestas en paralelo por la misma conexión TCP sin bloqueos. Las cabeceras se comprimen con el algoritmo HPACK, lo que reduce el tráfico significativamente.
|
||||||
|
|
||||||
|
HTTP 3 se basa en el protocolo QUIC que funciona sobre UDP en lugar de TCP. Esto reduce la latencia y acelera el establecimiento de conexiones porque combina el handshake TCP y el handshake TLS en un único paso.
|
||||||
|
|
||||||
|
Las cabeceras HTTP más relevantes son Content-Type para el tipo MIME del cuerpo de la respuesta, Authorization para las credenciales del cliente, Cache-Control para las directivas de caché, y Cookie y Set-Cookie para la gestión de sesiones.
|
||||||
|
|
||||||
|
HTTPS es HTTP con cifrado TLS. Garantiza tres propiedades: la confidencialidad mediante el cifrado de los datos en tránsito, la integridad para detectar cualquier manipulación del mensaje, y la autenticación del servidor mediante su certificado digital.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 5.2. TCP/IP y SSL/TLS
|
||||||
|
|
||||||
|
TCP/IP es el conjunto de protocolos base de internet. IP se encarga del direccionamiento y el enrutamiento de paquetes en la capa de red. TCP garantiza la transmisión fiable, ordenada y orientada a conexión en la capa de transporte mediante el mecanismo three-way handshake: el cliente envía SYN, el servidor responde SYN-ACK y el cliente confirma con ACK. Si se pierde un paquete TCP lo retransmite. UDP es el protocolo alternativo de transporte, no fiable pero más rápido y sin conexión, usado por DNS y servicios de streaming.
|
||||||
|
|
||||||
|
TLS, o Transport Layer Security, es el protocolo que proporciona seguridad en el canal de comunicación. Garantiza la confidencialidad mediante cifrado asimétrico para el intercambio de claves y simétrico para el flujo de datos; la integridad mediante un código de autenticación de mensaje; y la autenticación mediante certificados digitales X.509 firmados por una Autoridad Certificadora. TLS 1.2 y TLS 1.3 son las versiones actuales. SSL está obsoleto y no debe usarse.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 5.3. Otros protocolos de aplicación
|
||||||
|
|
||||||
|
Los protocolos de aplicación más relevantes para el examen son los siguientes. FTP o File Transfer Protocol usa el puerto 21 para el control y el 20 para los datos, y sirve para la transferencia de ficheros. SFTP es FTP seguro sobre SSH en el puerto 22. SMTP usa el puerto 25 o 587 y es el protocolo para el envío de correo electrónico. IMAP usa el puerto 143 o 993 cifrado y permite acceder al buzón de correo de forma sincronizada, manteniendo los mensajes en el servidor. POP3 usa el puerto 110 y descarga los mensajes al cliente local. DNS usa el puerto 53 y resuelve los nombres de dominio en direcciones IP. LDAP usa el puerto 389 o 636 cifrado y da acceso a directorios de usuarios como Active Directory. SSH usa el puerto 22 y proporciona acceso remoto seguro a servidores.
|
||||||
|
|
||||||
|
En resumen: HTTP es el protocolo de la web, opera sobre TCP y HTTPS añade TLS para cifrado e integridad. TCP garantiza la entrega fiable y UDP es más rápido pero sin garantías. TLS reemplaza a SSL. Los puertos más importantes para el examen son 80 HTTP, 443 HTTPS, 21 FTP, 22 SSH, 25 SMTP, 53 DNS.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Miniresumen final del tema
|
||||||
|
|
||||||
|
Este tema cubre los fundamentos de las arquitecturas distribuidas. La arquitectura cliente/servidor separa el cliente que solicita del servidor que responde, comunicándose por red. El cliente ligero, cuyo ejemplo es el navegador web, es el modelo más habitual hoy en día. La arquitectura multicapas organiza la aplicación en tres capas: presentación, lógica de negocio y datos. Ambos modelos son complementarios.
|
||||||
|
|
||||||
|
La comunicación puede ser síncrona, en la que el cliente bloquea y espera como en HTTP clásico, o asíncrona, en la que el cliente no bloquea y la respuesta llega mediante colas como JMS, RabbitMQ o Kafka con los patrones queue y topic.
|
||||||
|
|
||||||
|
En cuanto a los servicios web, SOAP es un protocolo formal que usa XML y WSDL; REST es un estilo arquitectónico que usa JSON y verbos HTTP; GraphQL permite al cliente definir los campos que necesita; gRPC usa Protobuf y HTTP/2 para comunicación eficiente entre microservicios; y WebSocket proporciona comunicación bidireccional en tiempo real. La diferencia clave para el examen es que REST es un estilo arquitectónico, no un protocolo.
|
||||||
|
|
||||||
|
Los protocolos principales son HTTP sobre TCP en el puerto 80, HTTPS con TLS en el puerto 443, TCP para transporte fiable, TLS como sucesor de SSL para cifrado, y DNS en el puerto 53 para resolución de nombres.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Arquitectura cliente/servidor
|
||||||
|
|
||||||
La arquitectura cliente/servidor es el modelo fundamental de las aplicaciones distribuidas. En este modelo un cliente solicita servicios y un servidor los proporciona, comunicándose a través de una red.
|
La arquitectura cliente/servidor es el modelo fundamental de las aplicaciones distribuidas. En este modelo un cliente solicita servicios y un servidor los proporciona, comunicándose a través de una red.
|
||||||
|
|
||||||
Los elementos de esta arquitectura son tres: el cliente, que realiza las peticiones; el servidor, que responde y gestiona los recursos; y la red, que es el medio de comunicación entre ellos.
|
Los elementos de esta arquitectura son tres: el cliente, que realiza las peticiones; el servidor, que responde y gestiona los recursos; y la red, que es el medio de comunicación entre ellos.
|
||||||
|
|
|
||||||
|
|
@ -1,238 +1,399 @@
|
||||||
# Bloque 3. Tema 7.
|
# Bloque 3 · Tema 7
|
||||||
# Aplicaciones web
|
# Aplicaciones web. Desarrollo web front-end y en servidor. HTML, XML y derivaciones. Navegadores. Lenguajes de script. Validación de datos.
|
||||||
|
|
||||||
## 1. Concepto de aplicación web
|
|
||||||
|
|
||||||
Una aplicación web es un software accesible mediante un navegador, que se ejecuta en Internet o en una intranet.
|
|
||||||
|
|
||||||
### Características
|
|
||||||
- No requiere instalación en el equipo del usuario.
|
|
||||||
- Acceso mediante navegador web.
|
|
||||||
- Actualización centralizada en el servidor.
|
|
||||||
- Compatible con múltiples sistemas operativos.
|
|
||||||
- Arquitectura cliente/servidor.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 2. Desarrollo web front-end
|
# Esquema resumen
|
||||||
|
|
||||||
El desarrollo front-end es la parte de la aplicación que se ejecuta en el navegador del usuario.
|
**Tecnologías front-end**
|
||||||
|
|
||||||
### Tecnologías principales
|
| Tecnología | Función |
|
||||||
- HTML: estructura del contenido.
|
|---|---|
|
||||||
- CSS: presentación y diseño.
|
| **HTML** | Estructura del contenido; etiquetas semánticas |
|
||||||
- JavaScript: comportamiento e interactividad.
|
| **CSS** | Presentación y diseño; diseño responsivo |
|
||||||
|
| **JavaScript** | Comportamiento e interactividad |
|
||||||
|
| **TypeScript** | Superset tipado de JavaScript |
|
||||||
|
| **AJAX** | Peticiones asíncronas sin recargar la página |
|
||||||
|
| **WebSocket** | Comunicación bidireccional en tiempo real |
|
||||||
|
|
||||||
### Funciones del front-end
|
**Lenguajes de marcado**
|
||||||
- Mostrar información al usuario.
|
|
||||||
- Gestionar la interacción.
|
| Lenguaje | Propósito | Clave |
|
||||||
- Validación básica de formularios.
|
|---|---|---|
|
||||||
- Adaptación a distintos dispositivos.
|
| **HTML5** | Estructura de páginas web | Semántica; etiquetas header, nav, article, footer |
|
||||||
|
| **XML** | Intercambio y almacenamiento de datos | Extensible; jerárquico; sin presentación |
|
||||||
|
| **XHTML** | HTML basado en XML | Más estricto que HTML |
|
||||||
|
| **SVG** | Gráficos vectoriales escalables | Derivación de XML |
|
||||||
|
| **JSON** | Intercambio de datos ligero | No XML; basado en objetos JS |
|
||||||
|
|
||||||
|
**Back-end: lenguajes y frameworks**
|
||||||
|
|
||||||
|
| Lenguaje | Frameworks / Entorno |
|
||||||
|
|---|---|
|
||||||
|
| Java | Jakarta EE, Spring Boot |
|
||||||
|
| C# | ASP.NET Core |
|
||||||
|
| PHP | Laravel, Symfony |
|
||||||
|
| Python | Django, Flask, FastAPI |
|
||||||
|
| JavaScript | Node.js, Express |
|
||||||
|
|
||||||
|
**Navegadores y motores**
|
||||||
|
|
||||||
|
| Navegador | Motor renderizado | Motor JS |
|
||||||
|
|---|---|---|
|
||||||
|
| Chrome / Edge | Blink | V8 |
|
||||||
|
| Firefox | Gecko | SpiderMonkey |
|
||||||
|
| Safari | WebKit | JavaScriptCore |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 3. Desarrollo web en servidor (back-end)
|
# 1. Concepto de aplicación web
|
||||||
|
|
||||||
El back-end es la parte que se ejecuta en el servidor.
|
## 1.1. Definición y características
|
||||||
|
|
||||||
### Funciones principales
|
Una aplicación web es un software accesible mediante un navegador que se ejecuta en Internet o en una intranet corporativa. Sus características principales son:
|
||||||
- Procesamiento de peticiones.
|
|
||||||
- Gestión de bases de datos.
|
|
||||||
- Lógica de negocio.
|
|
||||||
- Generación de respuestas (HTML, JSON, XML).
|
|
||||||
|
|
||||||
### Lenguajes habituales
|
- **Sin instalación**: el usuario accede solo con un navegador.
|
||||||
- Java (Jakarta EE)
|
- **Actualización centralizada**: los cambios se despliegan en el servidor y llegan a todos los usuarios inmediatamente.
|
||||||
- C# (.NET)
|
- **Multiplataforma y multidispositivo**: funciona en cualquier SO y dispositivo que tenga navegador.
|
||||||
- PHP
|
- **Arquitectura cliente/servidor**: el navegador es el cliente y el servidor gestiona la lógica y los datos.
|
||||||
- Python
|
- **Escalabilidad**: se puede escalar el servidor sin modificar los clientes.
|
||||||
- JavaScript (Node.js)
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 4. Lenguajes de marcado
|
## 1.2. Tipos de aplicaciones web
|
||||||
|
|
||||||
### 4.1 HTML
|
| Tipo | Descripción | Ejemplo |
|
||||||
HTML (HyperText Markup Language) es el lenguaje estándar para crear páginas web.
|
|---|---|---|
|
||||||
|
| **MPA** (Multi-Page Application) | El servidor genera una página completa en cada petición | Aplicaciones con Thymeleaf, JSP, PHP |
|
||||||
### Características
|
| **SPA** (Single-Page Application) | Se carga una única página; el contenido se actualiza sin recarga completa | Angular, React, Vue |
|
||||||
- Define la estructura del contenido.
|
| **PWA** (Progressive Web App) | SPA con capacidades offline y notificaciones push | Google Maps, Twitter Lite |
|
||||||
- Utiliza etiquetas.
|
| **SSR** (Server-Side Rendering) | La página inicial se renderiza en el servidor para SEO y rendimiento | Next.js, Nuxt.js |
|
||||||
- Es interpretado por el navegador.
|
|
||||||
|
|
||||||
### Ejemplo
|
|
||||||
<h1>Título</h1>
|
|
||||||
<p>Párrafo de ejemplo</p>
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
### 4.2 XML
|
---
|
||||||
XML (eXtensible Markup Language) es un lenguaje de marcado para almacenar e intercambiar datos.
|
|
||||||
|
|
||||||
### Características
|
# 2. Desarrollo web front-end
|
||||||
- Estructura jerárquica.
|
|
||||||
- No define presentación.
|
|
||||||
- Es extensible.
|
|
||||||
|
|
||||||
### Ejemplo
|
## 2.1. HTML5
|
||||||
<persona>
|
|
||||||
<nombre>Tatiana</nombre>
|
**HTML** (HyperText Markup Language) es el lenguaje estándar para definir la **estructura** del contenido de una página web. HTML5 es la versión actual e introduce mejoras importantes:
|
||||||
<edad>54</edad>
|
|
||||||
</persona>
|
**Etiquetas semánticas** (HTML5):
|
||||||
|
|
||||||
|
| Etiqueta | Significado |
|
||||||
|
|---|---|
|
||||||
|
| `<header>` | Cabecera del documento o sección |
|
||||||
|
| `<nav>` | Menú de navegación |
|
||||||
|
| `<main>` | Contenido principal |
|
||||||
|
| `<article>` | Contenido independiente |
|
||||||
|
| `<section>` | Sección temática |
|
||||||
|
| `<aside>` | Contenido lateral o complementario |
|
||||||
|
| `<footer>` | Pie de página |
|
||||||
|
|
||||||
|
**Nuevas funcionalidades de HTML5:**
|
||||||
|
- Soporte nativo de `<audio>` y `<video>` sin plugins.
|
||||||
|
- Canvas para gráficos con JavaScript.
|
||||||
|
- Tipos de input avanzados: `email`, `date`, `range`, `number`, `url`.
|
||||||
|
- APIs: Geolocalización, Web Storage, Web Workers.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
### 4.3 Derivaciones de XML/HTML
|
## 2.2. CSS
|
||||||
- XHTML: versión estricta de HTML basada en XML.
|
|
||||||
- SVG: gráficos vectoriales.
|
**CSS** (Cascading Style Sheets) define la **presentación** y el diseño visual: colores, tipografías, márgenes y distribución de los elementos.
|
||||||
- MathML: representación de fórmulas matemáticas.
|
|
||||||
|
**Conceptos clave:**
|
||||||
|
- **Selectores**: permiten apuntar a elementos HTML (por etiqueta, clase `.clase`, id `#id`).
|
||||||
|
- **Box model**: todo elemento es una caja con contenido, padding, borde y margen.
|
||||||
|
- **Cascada y especificidad**: las reglas más específicas sobrescriben a las generales.
|
||||||
|
- **Diseño responsivo**: adapta el diseño a distintos tamaños de pantalla mediante **media queries** (`@media`).
|
||||||
|
- **Flexbox y Grid**: modelos de diseño para distribución de elementos.
|
||||||
|
|
||||||
|
**Preprocesadores:** SASS y LESS añaden variables, anidamiento y funciones a CSS.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 5. Navegadores web
|
## 2.3. JavaScript y TypeScript
|
||||||
|
|
||||||
Un navegador web es una aplicación que permite acceder e interpretar contenidos web.
|
**JavaScript** es el único lenguaje de programación nativo del navegador. Proporciona comportamiento e interactividad a las páginas.
|
||||||
|
|
||||||
### Funciones principales
|
| Característica | Detalle |
|
||||||
- Interpretar HTML, CSS y JavaScript.
|
|---|---|
|
||||||
- Ejecutar scripts del lado del cliente.
|
| Tipado | Dinámico y débil |
|
||||||
- Gestionar solicitudes HTTP/HTTPS.
|
| Ejecución | Interpretado/JIT en el motor del navegador |
|
||||||
|
| Paradigma | Multiparadigma: funcional, orientado a objetos y procedimental |
|
||||||
|
| Estándar | ECMAScript (ECMA-262); versiones ES6+ |
|
||||||
|
|
||||||
### Componentes
|
**Funcionalidades clave:**
|
||||||
- Motor de renderizado.
|
- **DOM**: permite manipular la estructura HTML desde JavaScript.
|
||||||
- Motor JavaScript.
|
- **AJAX** (Asynchronous JavaScript and XML): realiza peticiones asíncronas al servidor sin recargar la página. Usa `XMLHttpRequest` o la API `fetch`.
|
||||||
|
- **Eventos**: onClick, onSubmit, onChange, etc.
|
||||||
|
- **JSON** (JavaScript Object Notation): formato ligero de intercambio de datos, más usado que XML en APIs REST.
|
||||||
|
|
||||||
|
**TypeScript** es un superset de JavaScript desarrollado por Microsoft que añade **tipado estático** opcional y se compila a JavaScript. Mejora el mantenimiento en proyectos grandes. Lo usan Angular, NestJS y muchos frameworks modernos.
|
||||||
|
|
||||||
|
**Frameworks JavaScript:**
|
||||||
|
|
||||||
|
| Framework/Librería | Tipo | Autor |
|
||||||
|
|---|---|---|
|
||||||
|
| **Angular** | Framework completo | Google |
|
||||||
|
| **React** | Librería UI | Meta |
|
||||||
|
| **Vue** | Framework progresivo | Comunidad |
|
||||||
|
| **Next.js** | SSR sobre React | Vercel |
|
||||||
|
| **Node.js** | Runtime server-side | OpenJS Foundation |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 6. Lenguajes de programación web
|
# 3. Desarrollo web back-end
|
||||||
|
|
||||||
### 6.1 Lenguajes del lado del cliente
|
## 3.1. Lenguajes y frameworks
|
||||||
Se ejecutan en el navegador:
|
|
||||||
- JavaScript
|
|
||||||
- TypeScript
|
|
||||||
|
|
||||||
### 6.2 Lenguajes del lado del servidor
|
El back-end es la parte que se ejecuta en el servidor. Sus funciones son procesar las peticiones, aplicar la lógica de negocio, gestionar el acceso a la base de datos y generar las respuestas.
|
||||||
Se ejecutan en el servidor:
|
|
||||||
- Java
|
| Lenguaje | Frameworks principales | Características |
|
||||||
- C#
|
|---|---|---|
|
||||||
- PHP
|
| **Java** | Spring Boot, Jakarta EE | Robusto, empresarial, JVM |
|
||||||
- Python
|
| **C#** | ASP.NET Core | Microsoft; multiplataforma desde .NET Core |
|
||||||
- JavaScript (Node.js)
|
| **PHP** | Laravel, Symfony | Muy extendido en web; fácil despliegue |
|
||||||
|
| **Python** | Django, Flask, FastAPI | Legible; populares en IA y APIs |
|
||||||
|
| **JavaScript** | Node.js, Express | Mismo lenguaje que el front; asíncrono |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 7. Lenguajes de script
|
## 3.2. Generación de respuestas
|
||||||
|
|
||||||
Los lenguajes de script son lenguajes interpretados utilizados para automatizar tareas y dar dinamismo a las aplicaciones web.
|
El back-end puede responder de distintas formas según el tipo de aplicación:
|
||||||
|
|
||||||
### Características
|
| Tipo de respuesta | Formato | Uso |
|
||||||
- Interpretados.
|
|---|---|---|
|
||||||
- Dinámicos.
|
| **Página HTML completa** | HTML | MPA: Thymeleaf, JSP, PHP |
|
||||||
- Integración directa con la web.
|
| **Datos estructurados** | JSON | API REST para SPA/móvil |
|
||||||
|
| **Datos estructurados** | XML | SOAP, legacy, configuración |
|
||||||
### Ejemplos
|
| **Sin cuerpo** | — | 204 No Content (DELETE exitoso) |
|
||||||
- JavaScript
|
|
||||||
- PHP
|
|
||||||
- Python
|
|
||||||
- Bash
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 8. Validación de datos en aplicaciones web
|
---
|
||||||
|
|
||||||
### 8.1 ¿Qué son las validaciones?
|
# 4. Lenguajes de marcado: XML y derivaciones
|
||||||
|
|
||||||
Las validaciones de datos son comprobaciones que aseguran que los datos introducidos por el usuario son correctos.
|
## 4.1. XML
|
||||||
|
|
||||||
### Objetivos
|
**XML** (eXtensible Markup Language) es un metalenguaje de marcado diseñado para **almacenar e intercambiar datos** de forma estructurada. A diferencia de HTML, XML no define cómo mostrar los datos, sino cómo estructurarlos.
|
||||||
- Evitar errores.
|
|
||||||
- Mejorar calidad de datos.
|
**Características de XML:**
|
||||||
- Reducir errores antes del servidor.
|
- **Extensible**: el desarrollador define sus propias etiquetas.
|
||||||
- Mejorar experiencia de usuario.
|
- **Jerárquico**: estructura en forma de árbol con un único elemento raíz.
|
||||||
|
- **Sin presentación**: solo estructura y datos; la presentación se define con XSLT o CSS.
|
||||||
|
- **Autodescriptivo**: las etiquetas describen el contenido.
|
||||||
|
- **Portable**: texto plano legible por cualquier sistema.
|
||||||
|
|
||||||
|
**Reglas de un documento XML bien formado:**
|
||||||
|
- Un único elemento raíz.
|
||||||
|
- Todas las etiquetas abiertas deben cerrarse.
|
||||||
|
- El anidamiento debe ser correcto (no cruzado).
|
||||||
|
- Los atributos van entre comillas.
|
||||||
|
- Sensible a mayúsculas.
|
||||||
|
|
||||||
|
**Usos de XML:**
|
||||||
|
- Mensajes **SOAP** en servicios web.
|
||||||
|
- Ficheros de configuración (Maven `pom.xml`, Spring `beans.xml`).
|
||||||
|
- Intercambio de datos entre sistemas legacy.
|
||||||
|
- Formatos de documentos (DOCX, ODT, SVG son XML por dentro).
|
||||||
|
|
||||||
|
**Diferencias HTML vs XML:**
|
||||||
|
|
||||||
|
| Aspecto | HTML | XML |
|
||||||
|
|---|---|---|
|
||||||
|
| Propósito | Presentar datos en el navegador | Almacenar e intercambiar datos |
|
||||||
|
| Etiquetas | Predefinidas | Definidas por el desarrollador |
|
||||||
|
| Tolerancia a errores | Permisivo | Estricto: errores rompen el documento |
|
||||||
|
| Presentación | Sí (navegador) | No (requiere XSLT o CSS) |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
### 8.2 Tipos de validación
|
## 4.2. Derivaciones de XML y HTML
|
||||||
|
|
||||||
#### Validación en cliente (front-end)
|
| Lenguaje | Base | Propósito |
|
||||||
Se realiza en el navegador.
|
|---|---|---|
|
||||||
|
| **XHTML** | XML + HTML | Versión estricta de HTML4 basada en XML; etiquetas en minúsculas y bien cerradas |
|
||||||
Características:
|
| **SVG** | XML | Gráficos vectoriales escalables; se integra en HTML5 |
|
||||||
- Rápida.
|
| **MathML** | XML | Representación de fórmulas matemáticas |
|
||||||
- Mejora experiencia de usuario.
|
| **RSS** | XML | Sindicación de contenidos (feeds de noticias) |
|
||||||
- No es segura por sí sola.
|
| **SOAP** | XML | Protocolo de mensajería para servicios web |
|
||||||
|
| **WSDL** | XML | Descripción de servicios web SOAP |
|
||||||
Ejemplos:
|
|
||||||
- Campos obligatorios.
|
|
||||||
- Formato de email.
|
|
||||||
- Longitud de contraseña.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
#### Validación en servidor (back-end)
|
## 4.3. JSON vs XML
|
||||||
Se realiza en el servidor.
|
|
||||||
|
|
||||||
Características:
|
JSON (JavaScript Object Notation) es el formato de intercambio de datos preferido en las APIs REST modernas. No es XML ni derivado de él.
|
||||||
- Obligatoria.
|
|
||||||
- Más segura.
|
|
||||||
- Última barrera de control.
|
|
||||||
|
|
||||||
Ejemplos:
|
| Aspecto | JSON | XML |
|
||||||
- Validación de usuarios.
|
|---|---|---|
|
||||||
- Comprobación en base de datos.
|
| Verbosidad | Más compacto | Más verbose (etiquetas de apertura y cierre) |
|
||||||
- Reglas de negocio.
|
| Legibilidad | Alta | Media |
|
||||||
|
| Tipado | Básico (string, number, boolean, array, object) | Solo texto (tipos via XSD) |
|
||||||
|
| Soporte en JS | Nativo (`JSON.parse`, `JSON.stringify`) | Requiere parser |
|
||||||
|
| Uso principal | APIs REST | SOAP, configuración, documentos |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
### 8.3 Validación de emails
|
# 5. Navegadores web
|
||||||
|
|
||||||
Un email válido debe tener:
|
## 5.1. Funciones y motores
|
||||||
- Texto antes de @
|
|
||||||
- Símbolo @
|
|
||||||
- Dominio después del @
|
|
||||||
|
|
||||||
Ejemplos:
|
Un navegador web es la aplicación que permite acceder e interpretar contenidos web. Sus funciones principales son interpretar HTML, CSS y JavaScript; ejecutar scripts del lado del cliente; y gestionar las solicitudes HTTP y HTTPS.
|
||||||
- usuario@gmail.com (válido)
|
|
||||||
- usuariogmail.com (inválido)
|
Internamente un navegador tiene dos motores clave:
|
||||||
- usuario@ (inválido)
|
|
||||||
|
| Motor | Función |
|
||||||
|
|---|---|
|
||||||
|
| **Motor de renderizado** | Procesa HTML y CSS; construye el árbol DOM y CSSOM; dibuja la página en pantalla |
|
||||||
|
| **Motor JavaScript** | Compila y ejecuta el código JavaScript con compilación JIT |
|
||||||
|
|
||||||
|
**Proceso de renderizado de una página:**
|
||||||
|
1. El navegador descarga el HTML y construye el **DOM** (Document Object Model).
|
||||||
|
2. Descarga el CSS y construye el **CSSOM** (CSS Object Model).
|
||||||
|
3. Combina DOM + CSSOM en el **Render Tree**.
|
||||||
|
4. Calcula la posición y tamaño de cada elemento (**layout**).
|
||||||
|
5. Pinta los píxeles en pantalla (**paint**).
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
### 8.4 Implementación de validaciones
|
## 5.2. Principales navegadores y sus motores
|
||||||
|
|
||||||
#### HTML5
|
| Navegador | Motor renderizado | Motor JavaScript | Desarrollador |
|
||||||
<input type="email" required>
|
|---|---|---|---|
|
||||||
|
| **Chrome** | Blink | V8 | Google |
|
||||||
|
| **Edge** | Blink | V8 | Microsoft |
|
||||||
|
| **Firefox** | Gecko | SpiderMonkey | Mozilla |
|
||||||
|
| **Safari** | WebKit | JavaScriptCore | Apple |
|
||||||
|
| **Opera** | Blink | V8 | Opera |
|
||||||
|
|
||||||
- Comprueba formato básico.
|
El motor **V8** de Google es también el que usa **Node.js** para ejecutar JavaScript en el servidor.
|
||||||
- Campo obligatorio.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
#### JavaScript
|
# 6. Lenguajes de script
|
||||||
function validarEmail(email) {
|
|
||||||
return email.includes("@");
|
|
||||||
}
|
|
||||||
|
|
||||||
Expresión regular:
|
## 6.1. Definición y características
|
||||||
const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
|
|
||||||
|
Los lenguajes de script son lenguajes de programación interpretados (no compilados a código máquina directamente) diseñados para automatizar tareas, integrar sistemas y dar dinamismo a las aplicaciones.
|
||||||
|
|
||||||
|
**Características:**
|
||||||
|
- **Interpretados**: se ejecutan directamente sin compilación previa a código máquina.
|
||||||
|
- **Dinámicos**: tipado dinámico; las variables no necesitan declarar su tipo.
|
||||||
|
- **Integración web**: diseñados para integrarse en entornos web o de sistema.
|
||||||
|
- **Rápido desarrollo**: código más conciso y expresivo.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
#### Servidor
|
## 6.2. Lenguajes de script principales
|
||||||
El servidor siempre valida los datos por seguridad.
|
|
||||||
|
| Lenguaje | Entorno | Uso principal |
|
||||||
|
|---|---|---|
|
||||||
|
| **JavaScript** | Navegador y servidor (Node.js) | Interactividad web; APIs; front-end |
|
||||||
|
| **TypeScript** | Transpila a JavaScript | Proyectos JS grandes con tipado estático |
|
||||||
|
| **PHP** | Servidor | Páginas web dinámicas; CMS (WordPress) |
|
||||||
|
| **Python** | Servidor y escritorio | Web (Django/Flask); IA; automatización |
|
||||||
|
| **Bash** | Sistema operativo (Unix/Linux) | Scripts de administración del sistema |
|
||||||
|
| **PowerShell** | Sistema operativo (Windows) | Automatización Windows y Azure |
|
||||||
|
| **Ruby** | Servidor | Web con Ruby on Rails |
|
||||||
|
|
||||||
|
**Diferencia lenguaje compilado vs interpretado:**
|
||||||
|
|
||||||
|
| Tipo | Ejemplo | Proceso |
|
||||||
|
|---|---|---|
|
||||||
|
| **Compilado** | Java, C, C++ | Código fuente → compilador → código máquina o bytecode |
|
||||||
|
| **Interpretado** | JavaScript, Python, PHP | Código fuente → intérprete → ejecución directa |
|
||||||
|
| **JIT** | JavaScript (V8), Java (JVM) | Se compila en tiempo de ejecución para mayor rendimiento |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
### 8.5 Reglas típicas de validación
|
# 7. Validación de datos
|
||||||
- Campos obligatorios
|
|
||||||
- Formato de email
|
## 7.1. Validación en cliente (front-end)
|
||||||
- Longitud mínima y máxima
|
|
||||||
- Solo números
|
La validación en cliente se realiza en el navegador **antes** de enviar los datos al servidor.
|
||||||
- Contraseñas seguras
|
|
||||||
- Confirmación de contraseña
|
**Ventajas:**
|
||||||
|
- Respuesta inmediata al usuario sin esperar al servidor.
|
||||||
|
- Reduce el tráfico de red al evitar envíos incorrectos.
|
||||||
|
- Mejora la experiencia de usuario (UX).
|
||||||
|
|
||||||
|
**Limitación clave:** la validación en cliente puede ser omitida o manipulada (con herramientas de desarrollador, Postman, etc.). **No es suficiente por sí sola**.
|
||||||
|
|
||||||
|
**Técnicas de validación en cliente:**
|
||||||
|
|
||||||
|
| Técnica | Descripción |
|
||||||
|
|---|---|
|
||||||
|
| **Atributos HTML5** | `required`, `type="email"`, `minlength`, `maxlength`, `pattern` |
|
||||||
|
| **JavaScript** | Validación programática en el evento `onSubmit` |
|
||||||
|
| **Expresiones regulares** | Validación de formatos complejos (email, DNI, teléfono) |
|
||||||
|
| **Frameworks** | React Hook Form, Angular Reactive Forms, Vuelidate |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
## 7.2. Validación en servidor (back-end)
|
||||||
|
|
||||||
|
La validación en servidor se realiza en el servidor **tras recibir los datos**.
|
||||||
|
|
||||||
|
**Es siempre obligatoria** porque:
|
||||||
|
- El servidor no puede confiar en el cliente (la validación del cliente puede ser omitida).
|
||||||
|
- Es la última barrera de seguridad antes de persistir los datos.
|
||||||
|
- Protege contra ataques como inyección SQL y XSS.
|
||||||
|
|
||||||
|
**Tipos de validación en servidor:**
|
||||||
|
|
||||||
|
| Tipo | Descripción | Ejemplo |
|
||||||
|
|---|---|---|
|
||||||
|
| **Formato** | Comprueba que el dato tiene la forma correcta | Email válido, DNI con formato correcto |
|
||||||
|
| **Existencia** | Comprueba que el dato existe en la BD | El usuario ya existe al registrarse |
|
||||||
|
| **Negocio** | Aplica las reglas de la aplicación | El saldo es suficiente para la transferencia |
|
||||||
|
| **Seguridad** | Previene inyección SQL, XSS, CSRF | Sanitización de entradas |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 7.3. Regla de oro y técnicas de validación
|
||||||
|
|
||||||
|
**Regla de oro:** la validación en cliente mejora la usabilidad; la validación en servidor es siempre obligatoria por seguridad. **Nunca confiar únicamente en la validación del cliente.**
|
||||||
|
|
||||||
|
**Reglas típicas de validación:**
|
||||||
|
|
||||||
|
| Regla | Descripción |
|
||||||
|
|---|---|
|
||||||
|
| **Campo obligatorio** | El campo no puede estar vacío |
|
||||||
|
| **Formato email** | Debe contener `@` y un dominio válido |
|
||||||
|
| **Longitud mínima/máxima** | Contraseña entre 8 y 64 caracteres |
|
||||||
|
| **Solo caracteres válidos** | El nombre no puede contener números |
|
||||||
|
| **Confirmación de contraseña** | Los dos campos de contraseña deben coincidir |
|
||||||
|
| **Unicidad** | El nombre de usuario no puede estar ya registrado |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Miniresumen final del tema
|
||||||
|
|
||||||
|
| Concepto | Clave |
|
||||||
|
|---|---|
|
||||||
|
| **Aplicación web** | Software accesible por navegador; sin instalación; actualización centralizada |
|
||||||
|
| **SPA** | Single-Page Application; carga una página; Angular, React, Vue |
|
||||||
|
| **MPA** | Multi-Page Application; el servidor genera cada página; Thymeleaf, PHP |
|
||||||
|
| **HTML5** | Estructura del contenido; etiquetas semánticas: header, nav, article, footer |
|
||||||
|
| **CSS** | Presentación y diseño; media queries para diseño responsivo |
|
||||||
|
| **JavaScript** | Comportamiento; DOM; AJAX; estándar ECMAScript |
|
||||||
|
| **TypeScript** | Superset tipado de JavaScript; compila a JS |
|
||||||
|
| **XML** | Intercambio de datos; jerárquico; extensible; sin presentación |
|
||||||
|
| **JSON** | Formato ligero; nativo en JS; preferido en APIs REST |
|
||||||
|
| **XHTML** | HTML estricto basado en XML |
|
||||||
|
| **SVG** | Gráficos vectoriales; derivación de XML |
|
||||||
|
| **Motor renderizado** | Blink (Chrome/Edge), Gecko (Firefox), WebKit (Safari) |
|
||||||
|
| **Motor JS** | V8 (Chrome/Edge/Node), SpiderMonkey (Firefox) |
|
||||||
|
| **Lenguaje de script** | Interpretado; dinámico; JS, PHP, Python, Bash |
|
||||||
|
| **Validación cliente** | Mejora UX; no es suficiente por sí sola |
|
||||||
|
| **Validación servidor** | Siempre obligatoria; última barrera de seguridad |
|
||||||
|
|
||||||
### 8.6 Idea clave de examen
|
### 8.6 Idea clave de examen
|
||||||
|
|
||||||
La validación en cliente mejora la usabilidad, pero la validación en servidor es obligatoria por seguridad.
|
La validación en cliente mejora la usabilidad, pero la validación en servidor es obligatoria por seguridad.
|
||||||
|
|
|
||||||
|
|
@ -1,81 +1,189 @@
|
||||||
## Bloque 3 Tema 7. Aplicaciones web. Desarrollo web front-end y back-end. Lenguajes de marcado HTML y XML. Navegadores web. Lenguajes de script. Validación de datos.
|
## Bloque 3 Tema 7. Aplicaciones web. Desarrollo web front-end y en servidor. HTML, XML y derivaciones. Navegadores. Lenguajes de script. Validación de datos.
|
||||||
|
|
||||||
Este tema estudia las aplicaciones web, su arquitectura, las tecnologías de desarrollo y la validación de los datos de entrada.
|
Este tema estudia las aplicaciones web, su arquitectura, las tecnologías de desarrollo front-end y back-end, los lenguajes de marcado, los navegadores, los lenguajes de script y la validación de datos de entrada.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 1. Concepto de aplicación web
|
## 1. Concepto de aplicación web
|
||||||
|
|
||||||
Una aplicación web es un software accesible mediante un navegador que se ejecuta en Internet o en una intranet corporativa. Sus características principales son que no requiere instalación en el equipo del usuario, se accede a ella mediante un navegador web, las actualizaciones son centralizadas en el servidor, es compatible con múltiples sistemas operativos y sigue la arquitectura cliente/servidor.
|
### 1.1. Definición y características
|
||||||
|
|
||||||
|
Una aplicación web es un software accesible mediante un navegador que se ejecuta en Internet o en una intranet corporativa. Sus características principales son que no requiere instalación en el equipo del usuario, se accede a ella mediante un navegador web, las actualizaciones son centralizadas en el servidor y llegan a todos los usuarios de forma inmediata, es compatible con múltiples sistemas operativos y dispositivos, y sigue la arquitectura cliente/servidor.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 1.2. Tipos de aplicaciones web
|
||||||
|
|
||||||
|
Las aplicaciones web modernas se clasifican en varios tipos según cómo gestionan la navegación y el contenido.
|
||||||
|
|
||||||
|
Las MPA o Multi-Page Applications generan una página HTML completa en el servidor en cada acción del usuario. Tecnologías como Thymeleaf, JSP o PHP son ejemplos habituales.
|
||||||
|
|
||||||
|
Las SPA o Single-Page Applications cargan una única página inicial en el navegador y luego actualizan el contenido dinámicamente sin recargas completas, mediante llamadas a una API. Los frameworks Angular, React y Vue son los más usados.
|
||||||
|
|
||||||
|
Las PWA o Progressive Web Apps son SPA con capacidades adicionales como funcionamiento offline y notificaciones push, implementadas mediante Service Workers.
|
||||||
|
|
||||||
|
Las SSR o Server-Side Rendering combinan ambos modelos renderizando la página inicial en el servidor para mejorar el rendimiento y el posicionamiento en buscadores. Next.js sobre React y Nuxt.js sobre Vue son los ejemplos más conocidos.
|
||||||
|
|
||||||
|
En resumen: las aplicaciones web son software accesible por navegador, sin instalación y con actualización centralizada. Los tipos principales son MPA con páginas generadas en servidor, SPA con actualización dinámica, PWA con capacidades offline y SSR con renderizado inicial en servidor.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 2. Desarrollo web front-end
|
## 2. Desarrollo web front-end
|
||||||
|
|
||||||
El front-end es la parte de la aplicación que se ejecuta en el navegador del usuario. Sus tres tecnologías fundamentales son HTML, CSS y JavaScript.
|
### 2.1. HTML5
|
||||||
|
|
||||||
HTML o HyperText Markup Language define la estructura del contenido de la página mediante etiquetas.
|
HTML, que son las siglas de HyperText Markup Language, es el lenguaje estándar para definir la estructura del contenido de una página web. HTML5 es la versión actual e introduce etiquetas semánticas que dan significado al contenido: header para la cabecera, nav para la navegación, main para el contenido principal, article para contenido independiente, section para secciones temáticas, aside para contenido lateral y footer para el pie de página. Estas etiquetas mejoran la accesibilidad y el posicionamiento en buscadores.
|
||||||
|
|
||||||
CSS o Cascading Style Sheets define la presentación y el diseño visual: colores, tipografías, distribución de los elementos y adaptación a distintas pantallas.
|
HTML5 también añadió soporte nativo para audio y vídeo sin necesidad de plugins, el elemento canvas para gráficos con JavaScript, tipos de input avanzados como email, date, range y number, y APIs del navegador como Geolocalización y Web Storage.
|
||||||
|
|
||||||
JavaScript es el lenguaje que proporciona el comportamiento y la interactividad: responde a las acciones del usuario, valida formularios, y actualiza partes de la página sin recargarla completa mediante técnicas como AJAX.
|
---
|
||||||
|
|
||||||
Las funciones del front-end son mostrar información al usuario, gestionar la interacción, realizar validaciones básicas de formularios y adaptar el diseño a distintos dispositivos mediante el diseño responsivo.
|
### 2.2. CSS
|
||||||
|
|
||||||
|
CSS, que son las siglas de Cascading Style Sheets u Hojas de Estilo en Cascada, define la presentación y el diseño visual de la página: colores, tipografías, márgenes y distribución de los elementos. Se aplica en cascada: las reglas más específicas sobrescriben a las generales.
|
||||||
|
|
||||||
|
El modelo de caja o box model es la base del diseño CSS: todo elemento es una caja compuesta por el contenido, el padding interior, el borde y el margen exterior. Flexbox y Grid son los modelos modernos para distribuir elementos en la página. Las media queries, escritas con la directiva at-media, permiten adaptar el diseño a distintos tamaños de pantalla, lo que se conoce como diseño responsivo. Los preprocesadores SASS y LESS añaden variables, anidamiento y funciones a CSS, compilando finalmente a CSS estándar.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 2.3. JavaScript y TypeScript
|
||||||
|
|
||||||
|
JavaScript es el único lenguaje de programación nativo del navegador. Proporciona el comportamiento y la interactividad de las páginas. Es un lenguaje interpretado o compilado con JIT, con tipado dinámico y débil, y multiparadigma porque soporta programación funcional, orientada a objetos y procedimental. Su estándar es ECMAScript, gestionado por ECMA International, cuyas versiones más importantes empezaron con ES6 en 2015.
|
||||||
|
|
||||||
|
El DOM o Document Object Model es la representación en árbol del documento HTML que JavaScript puede manipular para cambiar el contenido, los estilos o la estructura de la página en tiempo de ejecución. AJAX o Asynchronous JavaScript and XML permite realizar peticiones asíncronas al servidor sin recargar la página completa, usando la API fetch o el objeto XMLHttpRequest. JSON, que son las siglas de JavaScript Object Notation, es el formato de intercambio de datos más usado en APIs REST modernas y es nativo en JavaScript mediante los métodos JSON.parse y JSON.stringify.
|
||||||
|
|
||||||
|
TypeScript es un superset de JavaScript desarrollado por Microsoft que añade tipado estático opcional. El código TypeScript se compila a JavaScript estándar. Mejora el mantenimiento en proyectos grandes y lo usan Angular, NestJS y muchos frameworks modernos.
|
||||||
|
|
||||||
|
Los frameworks JavaScript más importantes son Angular de Google, que es un framework completo que usa TypeScript; React de Meta, que es una librería de interfaz de usuario que usa JSX; y Vue, que es un framework progresivo mantenido por la comunidad. En el servidor, Node.js ejecuta JavaScript fuera del navegador usando el motor V8 de Google.
|
||||||
|
|
||||||
|
En resumen: el front-end se construye con HTML5 para la estructura, CSS para el diseño responsivo y JavaScript para el comportamiento. TypeScript añade tipado estático. AJAX permite comunicación asíncrona con el servidor. Los frameworks principales son Angular, React y Vue.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 3. Desarrollo web back-end
|
## 3. Desarrollo web back-end
|
||||||
|
|
||||||
El back-end es la parte que se ejecuta en el servidor. Sus funciones son procesar las peticiones del cliente, gestionar el acceso a la base de datos, aplicar la lógica de negocio y generar las respuestas en formato HTML, JSON o XML.
|
### 3.1. Lenguajes y frameworks
|
||||||
|
|
||||||
Los lenguajes habituales del back-end son Java con Jakarta EE o Spring, C# con ASP.NET, PHP, Python con Django o Flask, y JavaScript en el servidor mediante Node.js.
|
El back-end es la parte que se ejecuta en el servidor. Sus funciones son procesar las peticiones del cliente, aplicar la lógica de negocio, gestionar el acceso a la base de datos y generar las respuestas.
|
||||||
|
|
||||||
|
Los lenguajes y frameworks más usados son Java con Spring Boot o Jakarta EE, que es robusto y empresarial; C# con ASP.NET Core de Microsoft, que es multiplataforma desde .NET Core; PHP con Laravel o Symfony, muy extendido en entornos de alojamiento web; Python con Django, Flask o FastAPI, muy usado en inteligencia artificial y APIs; y JavaScript en el servidor mediante Node.js con Express, que permite usar el mismo lenguaje en front-end y back-end.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 4. Lenguaje HTML
|
### 3.2. Generación de respuestas
|
||||||
|
|
||||||
HTML es el lenguaje estándar para crear páginas web. Define la estructura del contenido mediante etiquetas que el navegador interpreta. HTML5 es la versión actual y añadió etiquetas semánticas como header, nav, article y footer, así como soporte nativo para audio, vídeo y formularios avanzados con tipos de entrada como email, date y range.
|
El back-end puede responder de distintas formas según el tipo de aplicación. En una MPA el servidor genera y devuelve una página HTML completa usando un motor de plantillas como Thymeleaf o JSP. En una SPA el servidor expone una API REST que devuelve datos en formato JSON que el front-end procesa y muestra sin recargar la página. En entornos empresariales legacy el servidor puede devolver XML para servicios SOAP. Cuando una operación tiene éxito pero no hay contenido que devolver, el servidor responde con el código 204 No Content.
|
||||||
|
|
||||||
|
En resumen: el back-end procesa la lógica y los datos. Los lenguajes principales son Java, C#, PHP, Python y Node.js. Las respuestas pueden ser HTML para MPA, JSON para APIs REST o XML para servicios SOAP.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 5. Lenguaje XML
|
## 4. Lenguajes de marcado: XML y derivaciones
|
||||||
|
|
||||||
XML o eXtensible Markup Language es un lenguaje de marcado diseñado para almacenar e intercambiar datos. A diferencia de HTML, XML no define cómo mostrar los datos sino cómo estructurarlos. Su estructura es jerárquica, en forma de árbol, y es extensible porque el desarrollador define sus propias etiquetas.
|
### 4.1. XML
|
||||||
|
|
||||||
XML se usa en servicios web SOAP, en ficheros de configuración y en el intercambio de datos entre sistemas. Un documento XML bien formado debe tener un único elemento raíz, las etiquetas deben estar correctamente cerradas y anidadas, y los atributos deben ir entre comillas.
|
XML, que son las siglas de eXtensible Markup Language, es un metalenguaje de marcado diseñado para almacenar e intercambiar datos de forma estructurada. A diferencia de HTML, XML no define cómo mostrar los datos sino cómo estructurarlos.
|
||||||
|
|
||||||
Las derivaciones de XML más importantes son XHTML, que es una versión estricta de HTML basada en XML; SVG, para gráficos vectoriales; y MathML, para representar fórmulas matemáticas.
|
Sus características principales son que es extensible porque el desarrollador define sus propias etiquetas según sus necesidades; es jerárquico porque los datos se organizan en un árbol con un único elemento raíz; no define presentación sino solo estructura y datos; es autodescriptivo porque las etiquetas describen el significado del contenido; y es portable porque es texto plano legible por cualquier sistema.
|
||||||
|
|
||||||
|
Para que un documento XML sea válido y bien formado debe cumplir varias reglas: debe tener un único elemento raíz que contenga a todos los demás; todas las etiquetas abiertas deben cerrarse; el anidamiento de etiquetas debe ser correcto sin cruzarse; los atributos deben ir entre comillas; y es sensible a mayúsculas.
|
||||||
|
|
||||||
|
Los usos más habituales de XML son los mensajes SOAP en servicios web, los ficheros de configuración como el pom.xml de Maven o el beans.xml de Spring, el intercambio de datos entre sistemas legacy, y formatos de documentos como DOCX, ODT y SVG que internamente son XML.
|
||||||
|
|
||||||
|
La diferencia clave entre HTML y XML para el examen es que HTML tiene etiquetas predefinidas y está diseñado para presentar datos en el navegador; XML tiene etiquetas definidas por el desarrollador y está diseñado para intercambiar datos entre sistemas. HTML es permisivo con los errores; XML es estricto y un error de formato rompe el documento.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 6. Navegadores web
|
### 4.2. Derivaciones de XML y HTML
|
||||||
|
|
||||||
Un navegador web es la aplicación que permite acceder e interpretar contenidos web. Sus funciones principales son interpretar HTML, CSS y JavaScript; ejecutar los scripts del lado del cliente; y gestionar las solicitudes HTTP y HTTPS.
|
Las derivaciones más importantes son las siguientes. XHTML es una versión estricta de HTML4 basada en XML: las etiquetas deben ir en minúsculas y bien cerradas. SVG o Scalable Vector Graphics es el formato de gráficos vectoriales escalables basado en XML que se puede integrar directamente en HTML5. MathML permite representar fórmulas matemáticas en documentos web. RSS basado en XML se usa para la sindicación de contenidos o feeds de noticias. WSDL es el lenguaje en XML que describe la interfaz de los servicios web SOAP.
|
||||||
|
|
||||||
Internamente un navegador tiene dos motores: el motor de renderizado, que procesa el HTML y CSS y dibuja la página en pantalla; y el motor JavaScript, que ejecuta el código JavaScript.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 7. Lenguajes de script
|
### 4.3. JSON frente a XML
|
||||||
|
|
||||||
Los lenguajes de script son lenguajes interpretados que permiten automatizar tareas y dar dinamismo a las aplicaciones. Sus características son que son interpretados, dinámicos y se integran directamente con la web. Los ejemplos más conocidos son JavaScript para el lado del cliente, PHP y Python para el lado del servidor, y Bash para la automatización del sistema operativo.
|
JSON, JavaScript Object Notation, es el formato de intercambio de datos preferido en las APIs REST modernas. No es XML ni derivado de él. Sus diferencias principales respecto a XML son que JSON es más compacto porque no usa etiquetas de apertura y cierre para cada campo; JSON es nativo en JavaScript mediante JSON.parse y JSON.stringify; XML es más verbose pero tiene soporte para esquemas formales mediante XSD. El uso principal de JSON es en APIs REST y el de XML en servicios SOAP, ficheros de configuración y documentos.
|
||||||
|
|
||||||
|
En resumen: XML es extensible, jerárquico y estricto; se usa en SOAP, configuración y documentos. JSON es compacto y nativo en JavaScript; es el estándar en APIs REST. XHTML es HTML basado en XML. SVG es XML para gráficos vectoriales.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 8. Validación de datos
|
## 5. Navegadores web
|
||||||
|
|
||||||
Las validaciones de datos son comprobaciones que aseguran que los datos introducidos por el usuario son correctos. Sus objetivos son evitar errores, mejorar la calidad de los datos, reducir el trabajo en el servidor y mejorar la experiencia del usuario.
|
### 5.1. Funciones y motores
|
||||||
|
|
||||||
La validación en cliente o front-end se realiza en el navegador antes de enviar los datos al servidor. Es rápida y mejora la experiencia del usuario, pero no es segura por sí sola porque puede ser omitida.
|
Un navegador web es la aplicación que permite acceder e interpretar contenidos web. Sus funciones principales son interpretar HTML, CSS y JavaScript; ejecutar los scripts del lado del cliente; y gestionar las solicitudes HTTP y HTTPS con sus cabeceras, cookies y caché.
|
||||||
|
|
||||||
La validación en servidor o back-end se realiza en el servidor tras recibir los datos. Es obligatoria y es la última barrera de seguridad, ya que el cliente no puede omitirla. Incluye la validación de negocio y la comprobación contra la base de datos.
|
Internamente un navegador tiene dos motores fundamentales. El motor de renderizado procesa el HTML y el CSS, construye el árbol DOM con la estructura del documento y el árbol CSSOM con los estilos, los combina en el Render Tree, calcula la posición y tamaño de cada elemento en la fase de layout y finalmente pinta los píxeles en pantalla. El motor JavaScript compila y ejecuta el código JavaScript usando compilación JIT, o Just-In-Time, para mejorar el rendimiento frente a la interpretación pura.
|
||||||
|
|
||||||
La regla de oro de la validación es que la validación en cliente mejora la usabilidad, pero la validación en servidor es siempre obligatoria por seguridad. Nunca se debe confiar únicamente en la validación del lado del cliente.
|
---
|
||||||
|
|
||||||
Las reglas típicas de validación incluyen campos obligatorios, formato de email, longitud mínima y máxima, solo caracteres numéricos, contraseñas seguras y confirmación de contraseña.
|
### 5.2. Principales navegadores y sus motores
|
||||||
|
|
||||||
|
Los navegadores más importantes y sus motores son los siguientes. Chrome y Edge usan el motor de renderizado Blink y el motor JavaScript V8, ambos desarrollados por Google. Firefox usa el motor Gecko y el motor JavaScript SpiderMonkey, desarrollados por Mozilla. Safari usa el motor WebKit y el motor JavaScript JavaScriptCore, desarrollados por Apple.
|
||||||
|
|
||||||
|
El motor V8 de Google es especialmente relevante porque es también el que usa Node.js para ejecutar JavaScript en el servidor, lo que permite usar el mismo lenguaje tanto en el navegador como en el back-end.
|
||||||
|
|
||||||
|
En resumen: los navegadores tienen un motor de renderizado que procesa HTML y CSS, y un motor JavaScript que ejecuta el código. Los motores clave son Blink con V8 en Chrome y Edge, Gecko con SpiderMonkey en Firefox, y WebKit con JavaScriptCore en Safari.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 6. Lenguajes de script
|
||||||
|
|
||||||
|
### 6.1. Definición y características
|
||||||
|
|
||||||
|
Los lenguajes de script son lenguajes de programación interpretados, no compilados a código máquina directamente, diseñados para automatizar tareas, integrar sistemas y dar dinamismo a las aplicaciones. Sus características son que son interpretados porque se ejecutan directamente sin compilación previa; tienen tipado dinámico porque las variables no necesitan declarar su tipo; y están diseñados para integrarse en entornos web o de sistema operativo con código conciso y expresivo.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 6.2. Lenguajes de script principales
|
||||||
|
|
||||||
|
Los lenguajes de script más relevantes para el temario son los siguientes. JavaScript se ejecuta en el navegador y también en el servidor con Node.js; es el lenguaje de interactividad web por excelencia. TypeScript transpila a JavaScript y añade tipado estático para proyectos grandes. PHP se ejecuta en el servidor y genera páginas web dinámicas; es la base de sistemas de gestión de contenidos como WordPress. Python se usa en el servidor con frameworks como Django o Flask y también en inteligencia artificial y automatización. Bash es el lenguaje de script de los sistemas Unix y Linux para la administración del sistema. PowerShell cumple la misma función en sistemas Windows y Azure.
|
||||||
|
|
||||||
|
La diferencia entre lenguaje compilado e interpretado es importante para el examen. En un lenguaje compilado como Java, C o C++, el código fuente pasa por un compilador que genera código máquina o bytecode antes de ejecutarse. En un lenguaje interpretado como JavaScript, Python o PHP, el código fuente se ejecuta directamente mediante un intérprete. Los compiladores JIT como el V8 de JavaScript o la JVM de Java combinan ambos enfoques: compilan partes del código en tiempo de ejecución para mejorar el rendimiento.
|
||||||
|
|
||||||
|
En resumen: los lenguajes de script son interpretados y dinámicos. Los principales son JavaScript para la web, PHP para el servidor, Python para web e IA, Bash para Unix/Linux y PowerShell para Windows.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 7. Validación de datos
|
||||||
|
|
||||||
|
### 7.1. Validación en cliente (front-end)
|
||||||
|
|
||||||
|
La validación en cliente se realiza en el navegador antes de enviar los datos al servidor. Sus ventajas son la respuesta inmediata al usuario sin esperar al servidor, la reducción del tráfico de red al evitar envíos incorrectos y la mejora de la experiencia de usuario.
|
||||||
|
|
||||||
|
Las técnicas de validación en cliente son los atributos HTML5 como required para campos obligatorios, type igual a email para comprobar el formato, minlength y maxlength para la longitud, y pattern para expresiones regulares; la validación programática en JavaScript en el evento onSubmit; las expresiones regulares para validar formatos complejos como el DNI o el número de teléfono; y los frameworks de formularios como React Hook Form, Angular Reactive Forms o Vuelidate.
|
||||||
|
|
||||||
|
La limitación fundamental de la validación en cliente es que puede ser omitida o manipulada por el usuario mediante las herramientas de desarrollador del navegador o herramientas como Postman. Por ello no es suficiente por sí sola.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 7.2. Validación en servidor (back-end)
|
||||||
|
|
||||||
|
La validación en servidor se realiza tras recibir los datos del cliente. Es siempre obligatoria porque el servidor no puede confiar en que el cliente haya validado los datos; es la última barrera de seguridad antes de persistir los datos en la base de datos; y protege contra ataques como la inyección SQL, el XSS o la falsificación de peticiones CSRF.
|
||||||
|
|
||||||
|
Los tipos de validación en servidor son la validación de formato, que comprueba que el dato tiene la forma correcta como un email válido o un DNI con formato correcto; la validación de existencia, que comprueba contra la base de datos si el dato ya existe, como al registrar un nombre de usuario; la validación de negocio, que aplica las reglas propias de la aplicación como comprobar que el saldo es suficiente para una transferencia; y la validación de seguridad, que sanitiza las entradas para prevenir inyección SQL y XSS.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 7.3. Regla de oro y técnicas de validación
|
||||||
|
|
||||||
|
La regla de oro de la validación es que la validación en cliente mejora la usabilidad pero la validación en servidor es siempre obligatoria por seguridad. Nunca se debe confiar únicamente en la validación del lado del cliente.
|
||||||
|
|
||||||
|
Las reglas típicas de validación en cualquier aplicación web son las siguientes. Los campos obligatorios no pueden estar vacíos. El formato del email debe contener una arroba y un dominio válido. La longitud de la contraseña debe estar entre un mínimo y un máximo, por ejemplo entre ocho y sesenta y cuatro caracteres. Ciertos campos solo admiten caracteres válidos, como un nombre que no puede contener números. Los dos campos de contraseña de un formulario de registro deben coincidir. Y el nombre de usuario no puede estar ya registrado en la base de datos.
|
||||||
|
|
||||||
|
En resumen: la validación en cliente mejora la UX pero puede ser omitida. La validación en servidor es siempre obligatoria porque es la última barrera de seguridad. Las técnicas de cliente son atributos HTML5, JavaScript y expresiones regulares. Las de servidor incluyen validación de formato, existencia y reglas de negocio.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Miniresumen final del tema
|
## Miniresumen final del tema
|
||||||
|
|
||||||
Una aplicación web se accede mediante navegador sin instalación. El front-end usa HTML para estructura, CSS para diseño y JavaScript para comportamiento. El back-end usa Java, C#, PHP, Python o Node.js. XML es para intercambio de datos con estructura jerárquica; HTML es para presentación. Los navegadores tienen motor de renderizado y motor JavaScript. La validación en cliente mejora la usabilidad; la validación en servidor es siempre obligatoria por seguridad.
|
Este tema cubre el desarrollo completo de aplicaciones web. Una aplicación web es accesible por navegador sin instalación, con actualización centralizada en el servidor. Sus tipos principales son MPA con páginas generadas por el servidor, SPA con actualización dinámica mediante JavaScript, PWA con capacidades offline y SSR con renderizado inicial en servidor.
|
||||||
|
|
||||||
|
El front-end se construye con HTML5 para la estructura semántica, CSS para el diseño responsivo con media queries y Flexbox, y JavaScript para el comportamiento con manipulación del DOM y peticiones AJAX. TypeScript añade tipado estático y es la base de Angular. Los frameworks principales son Angular, React y Vue.
|
||||||
|
|
||||||
|
El back-end procesa la lógica con Java, C#, PHP, Python o Node.js, y responde con HTML para MPA o JSON para APIs REST.
|
||||||
|
|
||||||
|
XML es extensible, jerárquico y estricto; se usa en SOAP y ficheros de configuración. JSON es más compacto y es el estándar en APIs REST. Las derivaciones de XML incluyen XHTML, SVG, MathML y WSDL. Los navegadores tienen un motor de renderizado como Blink, Gecko o WebKit, y un motor JavaScript como V8 o SpiderMonkey. Los lenguajes de script son interpretados y dinámicos.
|
||||||
|
|
||||||
|
La validación en cliente mejora la usabilidad pero puede omitirse. La validación en servidor es siempre obligatoria y es la última barrera de seguridad.
|
||||||
|
|
|
||||||
|
|
@ -15,9 +15,11 @@
|
||||||
<span class="admin-badge">ADMIN</span>
|
<span class="admin-badge">ADMIN</span>
|
||||||
<nav class="topbar-nav" style="margin-left: auto">
|
<nav class="topbar-nav" style="margin-left: auto">
|
||||||
<a th:href="@{/curso}">Curso</a>
|
<a th:href="@{/curso}">Curso</a>
|
||||||
<a th:href="@{/logout}"
|
<form th:action="@{/logout}" method="post" style="margin:0"
|
||||||
onclick="return confirm('¿Cerrar sesión?')"
|
onsubmit="return confirm('¿Cerrar sesión?')">
|
||||||
style="color:var(--error)">Salir</a>
|
<input type="hidden" th:name="${_csrf.parameterName}" th:value="${_csrf.token}"/>
|
||||||
|
<button type="submit" style="background:none;border:none;cursor:pointer;color:var(--error);font:inherit;padding:0">Salir</button>
|
||||||
|
</form>
|
||||||
</nav>
|
</nav>
|
||||||
</nav>
|
</nav>
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -33,7 +33,9 @@
|
||||||
</nav>
|
</nav>
|
||||||
|
|
||||||
<h1>Planning de repaso TAI</h1>
|
<h1>Planning de repaso TAI</h1>
|
||||||
<p class="subtitle">Mayo 2026 · Examen: <strong>sábado 23 de mayo</strong></p>
|
<p class="subtitle">Mayo 2026 · Examen: <strong>sábado 23 de mayo</strong>
|
||||||
|
<button id="btn-reset-planning" class="btn-reset-planning" title="Reiniciar progreso guardado">⚙</button>
|
||||||
|
</p>
|
||||||
|
|
||||||
<!-- SEMANA 1: 5–11 mayo -->
|
<!-- SEMANA 1: 5–11 mayo -->
|
||||||
<section class="semana">
|
<section class="semana">
|
||||||
|
|
@ -179,5 +181,6 @@
|
||||||
<div class="leyenda-item"><div class="leyenda-color" style="background:#1a2a35;-webkit-print-color-adjust:exact;print-color-adjust:exact;"></div> Fin de semana</div>
|
<div class="leyenda-item"><div class="leyenda-color" style="background:#1a2a35;-webkit-print-color-adjust:exact;print-color-adjust:exact;"></div> Fin de semana</div>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
|
<script th:src="@{/js/planning.js}" defer></script>
|
||||||
</body>
|
</body>
|
||||||
</html>
|
</html>
|
||||||
Loading…
Reference in New Issue