Tema 19. Arquitecturas, lenguajes, herramientas y protocolos para utilización en Internet. Lenguaje de especificación HTML: versiones y características. El protocolo HTTP: versiones y características. Lenguaje XML. Desarrollo de aplicaciones web en el cliente. Desarrollo de aplicaciones web en el servidor. Componentes distribuidos. Publicación de contenidos. Herramientas para la edición, gestión y personalización de contenidos en Internet. Javascript y AJAX. Web semántica.

1. Arquitecturas, lenguajes, herramientas y protocolos para utilización en Internet

🎯 Idea clave

• Internet es una red global de redes construida sobre la familia de protocolos TCP/IP que permite la comunicación entre sistemas heterogéneos de alcance mundial.
• La pila tecnológica de Internet se organiza en cuatro dimensiones fundamentales que deben estudiarse de manera conjunta: arquitecturas, lenguajes, herramientas y protocolos.
• Las arquitecturas definen cómo se estructuran y relacionan los componentes de los sistemas distribuidos en la red.
• Los lenguajes permiten representar, describir e intercambiar información entre aplicaciones, servicios y usuarios finales.
• Las herramientas soportan el ciclo completo de desarrollo, despliegue, operación y mantenimiento de los servicios en red.
• Los protocolos establecen las reglas formales y acuerdos técnicos que hacen posible la comunicación segura y eficiente entre sistemas heterogéneos.

📚 Desarrollo

Definición de Internet. Internet constituye una infraestructura distribuida de alcance mundial que interconecta millones de dispositivos, sistemas y usuarios mediante la familia de protocolos TCP/IP. Esta arquitectura descentralizada posibilita la comunicación entre sistemas heterogéneos con independencia del hardware y del sistema operativo subyacente, conformando lo que se denomina la red de redes.

Las cuatro dimensiones fundamentales. La tecnología de Internet se estructura en cuatro planos integrados que conforman su pila tecnológica. Las arquitecturas definen cómo se organizan los componentes distribuidos, los lenguajes permiten la codificación de información, las herramientas facilitan el desarrollo y la gestión, y los protocolos establecen las reglas formales de comunicación entre sistemas.

Modelos arquitectónicos. Las arquitecturas describen patrones de organización como cliente-servidor, peer-to-peer, arquitecturas multinivel, microservicios, serverless y edge computing. Cada modelo determina la distribución de funciones entre los nodos de la red y establece cómo se relacionan entre sí los distintos componentes software, desde la centralización hasta el procesamiento en el borde de la red.

Lenguajes de la web. Los formalismos de codificación incluyen HTML, XML, JSON y YAML para estructurar y transportar datos, mientras que JavaScript, TypeScript y PHP constituyen lenguajes de programación específicos para el entorno web. Estos lenguajes expresan el contenido, la estructura y el comportamiento de las aplicaciones, siendo la base de la web dinámica moderna.

Herramientas del ecosistema. El desarrollo y mantenimiento requieren navegadores, servidores web y de aplicaciones, entornos de desarrollo integrados, validadores de accesibilidad, analizadores de protocolos, gestores de API, sistemas de control de versiones, escáneres de seguridad, plataformas de monitorización y gestores de certificados digitales. En entornos sanitarios, estas herramientas soportan procesos asistenciales y administrativos críticos.

Protocolos de comunicación. TCP/IP proporciona la base de transporte y direccionamiento, DNS resuelve nombres de dominio en direcciones IP, HTTP define la interacción básica de la Web, TLS protege la confidencialidad y la integridad frente a escucha y manipulación, SMTP transporta el correo electrónico, REST y SOAP articulan el intercambio de datos entre aplicaciones mediante servicios web, y OAuth 2.0, OpenID Connect o SAML cubren la autenticación y autorización federada.

Aplicación en el SAS. En el Servicio Andaluz de Salud, estos elementos sustentan portales web, la sede electrónica, ClicSalud+, áreas de acceso profesional, servicios integrados, herramientas de soporte, publicación de contenidos, exposición de APIs y administración de infraestructura conectada. La interoperabilidad con sistemas estatales como Cl@ve o FACe, así como con el Espacio Europeo de Datos Sanitarios, depende del dominio de esta pila tecnológica.

Competencia profesional. Para el Técnico Especialista en Informática, conocer estas cuatro dimensiones resulta imprescindible para diagnosticar problemas de conectividad, configurar servidores web, desplegar aplicaciones, gestionar certificados TLS, monitorizar tráfico de red y atender incidencias en sistemas que pueden afectar directamente a procesos clínicos y administrativos.

🧩 Elementos esenciales

• Arquitectura cliente-servidor: modelo donde el cliente solicita servicios y el servidor los proporciona, constituyendo la base de la navegación web tradicional.
• Arquitectura peer-to-peer: sistema de distribución sin nodos centralizados donde cada equipo actúa simultáneamente como cliente y servidor.
• Microservicios: enfoque arquitectónico que descompone aplicaciones en servicios pequeños e independientes desplegables de forma aislada.
• Serverless: modelo de computación en el que el proveedor de la nube gestiona dinámicamente la asignación de recursos máquina.
• Edge computing: paradigma de procesamiento de datos cercano a la fuente de generación, reduciendo la latencia respecto al centro de datos.
• HTML: lenguaje de marcado estándar para estructurar y presentar contenido en navegadores web.
• XML: metalenguaje extensible que permite describir y transportar datos estructurados entre sistemas heterogéneos.
• JSON: formato ligero de intercambio de datos, legible por humanos y fácilmente parseable por máquinas.
• TCP/IP: suite de protocolos fundamentales que proporcionan direccionamiento, enrutamiento y transporte de paquetes en Internet.
• HTTP/HTTPS: protocolo de transferencia de hipertexto; su versión segura implementa TLS para cifrar la comunicación entre cliente y servidor.
• DNS: sistema de nombres de dominio que traduce direcciones mnemotécnicas legibles por humanos en direcciones IP numéricas.
• REST: estilo arquitectónico para diseñar servicios web basado en operaciones HTTP estándar y recursos identificados por URIs.

🧠 Recuerda

• Internet es una red de redes distribuida y descentralizada, no una estructura centralizada o monolítica.
• Las cuatro dimensiones tecnológicas deben comprenderse de forma integrada para construir sistemas web robustos.
• TCP/IP constituye la base técnica indispensable de cualquier comunicación en Internet.
• HTTP es el protocolo de interacción básica, pero HTTPS es obligatorio para la prestación seria de servicios públicos en línea.
• El conocimiento profundo de estas tecnologías es competencia básica para el técnico del SAS.
• Los fallos en sistemas web pueden originarse en DNS, TLS, balanceo, backend, base de datos o autenticación, no únicamente en el servidor frontal.
• La interoperabilidad sanitaria con DIRAYA y el SNS se construye sobre estándares web, APIs y protocolos seguros.
• Cuando arquitecturas, lenguajes, herramientas y protocolos se coordinan correctamente, Internet se convierte en una plataforma robusta de servicios.

2. Lenguaje de especificación HTML: versiones y características

🎯 Idea clave

• HTML es el lenguaje de marcado estándar para estructurar contenido web mediante etiquetas que definen significado semántico, sin ser un lenguaje de programación.
• Fue creado por Tim Berners-Lee en el CERN en 1989, con su primera especificación pública en 1991 que contenía 18 etiquetas básicas.
• La evolución histórica abarca desde HTML 2.0 (IETF, 1995) hasta HTML 4.01 (W3C, 1999) y XHTML 1.0 (W3C, 2000), culminando en HTML5 como versión de referencia.
• HTML5 introduce elementos semánticos estructurales como header, nav, article, section, aside, main y footer que mejoran la accesibilidad y el posicionamiento en buscadores.
• La especificación actual se mantiene como Living Standard por WHATWG y como recomendación W3C desde 2019, garantizando estabilidad y compatibilidad hacia atrás.

📚 Desarrollo

Definición fundamental. HTML (HyperText Markup Language) constituye el lenguaje de marcado estándar para la creación de páginas y aplicaciones web. Utiliza etiquetas para delimitar elementos y atributos que añaden propiedades, organizando texto, enlaces, imágenes, formularios y elementos multimedia para su interpretación por navegadores. No es un lenguaje de programación sino descriptivo de estructura y contenido.

Origen histórico. Fue desarrollado por Tim Berners-Lee en el CERN en 1989 como parte del proyecto World Wide Web, publicándose la primera especificación informal en 1991 con apenas 18 etiquetas. Desde entonces, ha evolucionado manteniendo su carácter de estándar abierto y su preservación de compatibilidad hacia atrás, factores determinantes de su universalidad.

Evolución de versiones. El lenguaje transitó desde HTML 2.0 estandarizado por IETF en 1995, pasando por HTML 4.01 del W3C en 1999 y XHTML 1.0 en 2000, hasta llegar a HTML5, recomendado por W3C en 2014. Esta última versión superó las limitaciones de sus predecesoras incorporando semántica avanzada, multimedia nativa y capacidades de aplicación web.

HTML5 Living Standard. Actualmente, HTML5 se mantiene como Living Standard por WHATWG (Web Hypertext Application Technology Working Group), con el W3C como copublicador desde el alineamiento de ambas especificaciones en 2019. Este modelo de especificación viva permite actualizaciones continuas sin versiones numeradas posteriores, manteniendo la estabilidad del lenguaje.

Aportaciones semánticas y estructurales. HTML5 introduce elementos semánticos que otorgan significado real al contenido más allá de la presentación visual, incluyendo header, footer, nav, article, section, aside y main. Estas etiquetas mejoran fundamentalmente la accesibilidad, el mantenimiento del código y el posicionamiento en buscadores.

Capacidades técnicas avanzadas. La versión actual incorpora formularios mejorados con nuevos tipos de input (date, email, range, number, tel) y validación nativa sin necesidad de JavaScript. Asimismo, soporta multimedia nativa mediante elementos video y audio, eliminando la dependencia de plugins externos como Flash, e incluye Canvas para gráficos 2D/3D programáticos mediante JavaScript y WebGL, además de SVG para gráficos vectoriales escalables.

APIs para aplicaciones web. HTML5 integra APIs JavaScript avanzadas que extienden la funcionalidad del navegador, incluyendo Geolocation API, Web Storage (localStorage y sessionStorage), Web Workers, WebSocket para comunicación bidireccional en tiempo real, Service Workers para Progressive Web Apps (PWA) y capacidades de Drag and Drop.

🧩 Elementos esenciales

• Tim Berners-Lee: Creador de HTML en el CERN en 1989, estableciendo las bases del World Wide Web.
• Primera especificación: Publicada en 1991 con 18 etiquetas iniciales de marcado básico.
• W3C: World Wide Web Consortium, organismo estandarizador que publicó HTML 4.01 en 1999 y HTML5 en 2014.
• WHATWG: Grupo que mantiene HTML5 como Living Standard desde el alineamiento con W3C en 2019.
• HTML 4.01: Versión estandarizada por W3C en 1999, predecesora directa de HTML5.
• XHTML 1.0: Versión basada en XML estandarizada por W3C en 2000, rigurosa sintácticamente.
• Etiquetas semánticas: header, footer, nav, article, section, aside y main, que aportan significado estructural al contenido.
• Validación nativa: Capacidad de los formularios HTML5 para validar datos sin intervención de JavaScript.
• Canvas: Elemento que permite dibujo programático 2D/3D mediante JavaScript y WebGL.
• Web Storage: API que habilita almacenamiento local (localStorage) y por sesión (sessionStorage) en el navegador.
• Service Workers: Scripts que permiten funcionalidades offline y Progressive Web Apps (PWA).

🧠 Recuerda

• HTML es lenguaje de marcado, no de programación, que estructura contenido mediante etiquetas.
• Tim Berners-Lee creó HTML en el CERN en 1989 y se publicó en 1991 con 18 etiquetas.
• La evolución pasó por HTML 2.0, HTML 4.01, XHTML 1.0 hasta HTML5.
• HTML5 es la versión actual, recomendada por W3C en 2014 y mantenida como Living Standard por WHATWG.
• Los elementos semánticos de HTML5 mejoran accesibilidad y SEO (header, nav, article, section, aside, footer, main).
• HTML5 incluye multimedia nativa (audio, video) sin plugins y gráficos mediante Canvas y SVG.
• Los formularios HTML5 ofrecen nuevos tipos de input y validación nativa en el navegador.
• Las APIs de HTML5 incluyen Geolocation, Web Storage, Web Workers, WebSocket y Service Workers.
• La compatibilidad hacia atrás y el carácter de estándar abierto garantizan la universalidad de HTML.

3. El protocolo HTTP: versiones y características

🎯 Idea clave

• HTTP es el protocolo de la capa de aplicación que fundamenta la comunicación en la World Wide Web mediante un modelo petición-respuesta.
• Opera como protocolo sin estado, donde cada interacción es independiente y no conserva memoria de solicitudes previas entre el cliente y el servidor.
• La evolución del protocolo ha transitado desde HTTP/1.0 hasta HTTP/3, incorporando mejoras en eficiencia, multiplexación y seguridad en cada versión.
• Las versiones actuales de referencia son HTTP/1.1, HTTP/2 y HTTP/3, definidas por los RFC 9112, 9113 y 9114 respectivamente.
• La semántica del protocolo se fundamenta en mensajes autodescriptivos que utilizan métodos estándar y códigos de estado organizados en cinco categorías numéricas.
• HTTPS constituye la utilización de HTTP sobre un canal seguro mediante TLS, siendo hoy la forma estándar de uso protegido del protocolo.

📚 Desarrollo

Definición fundamental. HTTP, siglas de HyperText Transfer Protocol, es el protocolo de la capa de aplicación diseñado para la transferencia de recursos en la Web. Establece la forma en que un cliente solicita representaciones de recursos y cómo el servidor devuelve respuestas estructuradas y comprensibles, operando sobre recursos identificables mediante URI o URL.

Características arquitectónicas. El protocolo se define como una familia de protocolos sin estado, lo que significa que no conserva por sí mismo información de peticiones anteriores salvo mecanismos adicionales como cookies o tokens. Presenta semántica extensible que admite evolución mediante nuevos campos de cabecera y métodos, utilizando mensajes autodescriptivos que contienen toda la información necesaria para su interpretación.

Evolución de versiones. La especificación ha evolucionado desde HTTP/1.0 definido en el RFC 1945 de 1996, pasando por HTTP/1.1 estandarizado inicialmente en el RFC 2616 de 1999 y actualizado posteriormente en los RFC 7230-7235 y 9110-9114. HTTP/2, definido en el RFC 7540 de 2015 y actualizado en el RFC 9113 de 2022, introduce multiplexación, compresión de cabeceras HPACK, formato binario y server push. HTTP/3, especificado en el RFC 9114 de 2022, opera sobre QUIC en lugar de TCP, utilizando UDP como capa de transporte.

Estructura del mensaje. Una petición HTTP se compone de tres partes esenciales: la línea de solicitud que incluye el método, la URI del recurso y la versión del protocolo; las cabeceras que proporcionan metadatos como Host, Content-Type o Authorization; y el cuerpo opcional que contiene los datos enviados al servidor, vacío en operaciones GET pero presente en POST o PUT.

Métodos y semántica. Los métodos principales definen la acción sobre los recursos. GET solicita una representación sin modificar el estado del servidor, siendo seguro e idempotente. POST envía datos para crear recursos, no siendo idempotente. PUT reemplaza completamente un recurso y DELETE lo elimina, ambos idempotentes. PATCH modifica parcialmente recursos, mientras HEAD y OPTIONS son métodos seguros e idempotentes para obtener metadatos o consultar opciones disponibles.

Códigos de estado. Las respuestas se clasifican en cinco categorías: 1xx informativas, 2xx de éxito como 200 OK, 201 Created o 204 No Content, 3xx de redirección como 301 Moved Permanently, 302 Found o 304 Not Modified, 4xx de error del cliente incluyendo 400 Bad Request, 401 Unauthorized, 403 Forbidden y 404 Not Found, y 5xx de error del servidor como 500 Internal Server Error, 502 Bad Gateway o 503 Service Unavailable.

Seguridad y transporte. HTTPS representa la utilización de HTTP sobre un canal seguro mediante TLS, utilizando el puerto 443 en lugar del puerto 80 estándar de HTTP. Las versiones modernas emplean TLS 1.2 o TLS 1.3, e incorporan mecanismos como HSTS para forzar conexiones seguras y compresión Brotli para optimizar el rendimiento.

🧩 Elementos esenciales

• Protocolo capa aplicación: HTTP opera exclusivamente en la capa de aplicación del modelo TCP/IP, funcionando sobre TCP en versiones 1.0, 1.1 y 2, y sobre QUIC/UDP en HTTP/3.
• Modelo sin estado: Cada petición-respuesta es independiente; el servidor no mantiene memoria de interacciones previas sin mecanismos complementarios de gestión de sesión.
• HTTP/1.0 y HTTP/1.1: La versión 1.0 definida en RFC 1945 evolucionó a 1.1 incorporando mejoras como conexiones persistentes mediante keep-alive y mecanismos de caché avanzados.
• HTTP/2: Versión definida en RFC 9113 que implementa multiplexación de streams sobre una única conexión TCP, compresión de cabeceras HPACK, formato binario y capacidad de server push.
• HTTP/3: Especificado en RFC 9114, elimina la dependencia de TCP utilizando QUIC sobre UDP, con TLS 1.3 obligatorio desde el inicio de la conexión.
• Métodos seguros: GET, HEAD y OPTIONS no modifican el estado del servidor y pueden ser ejecutados sin riesgo de alterar recursos.
• Métodos idempotentes: GET, HEAD, PUT, DELETE, OPTIONS y TRACE producen el mismo efecto si se ejecutan múltiples veces consecutivas sobre el mismo recurso.
• Estructura tripartita: Los mensajes HTTP se componen de línea de solicitud o estado, cabeceras de metadatos y cuerpo de mensaje opcional.
• Categorías de estado: Los códigos de respuesta se organizan en cinco familias numéricas según el primer dígito: informativos, éxito, redirección, error cliente y error servidor.
• Puertos estándar: El servicio HTTP utiliza convencionalmente el puerto 80, mientras que HTTPS opera sobre el puerto 443.

🧠 Recuerda

• HTTP es un protocolo de la capa de aplicación con modelo petición-respuesta y semántica extensible.
• Las versiones actuales de referencia son HTTP/1.1 (RFC 9112), HTTP/2 (RFC 9113) y HTTP/3 (RFC 9114).
• HTTP/1.0 se definió originalmente en el RFC 1945 de 1996.
• HTTP/2 introdujo la multiplexación y el formato binario, abandonando el texto plano de versiones anteriores.
• HTTP/3 utiliza QUIC sobre UDP en lugar de TCP, mejorando la latencia en condiciones de red deficientes.
• GET es idempotente y seguro, mientras que POST no es idempotente ni seguro en términos estrictos del protocolo.
• Los códigos 2xx indican éxito, 4xx errores del cliente y 5xx errores del servidor.
• HTTPS es HTTP sobre TLS, operando en puerto 443 y constituyendo el estándar actual para comunicaciones seguras.
• Las cabeceras Host son obligatorias en HTTP/1.1 y posteriores para permitir el hosting virtual.
• TLS 1.3 es obligatorio en HTTP/3 y recomendado en configuraciones modernas de HTTPS.

4. Lenguaje XML

🎯 Idea clave

• XML es un lenguaje de marcado extensible diseñado para almacenar y transportar datos estructurados de forma legible tanto por humanos como por máquinas.
• Fue desarrollado por el W3C y publicado en 1998 como subconjunto simplificado de SGML orientado específicamente al entorno Internet.
• Permite definir etiquetas propias adaptadas al dominio del problema, actuando como metalenguaje sin vocabulario predefinido.
• Su objetivo fundamental es expresar la estructura lógica y jerarquía interna de los datos, no describir su presentación visual.
• Mantiene presencia relevante en sistemas empresariales, integración entre administraciones y formatos sanitarios estándar como HL7 CDA.
• Asocia tecnologías complementarias como DTD, XML Schema, XSLT, XPath y XQuery para validación, transformación y consulta de información.

📚 Desarrollo

Definición y origen. XML (eXtensible Markup Language) constituye un lenguaje de marcado desarrollado por el W3C cuya primera versión se publicó en 1998. Nace como subconjunto de SGML diseñado específicamente para resultar utilizable en Internet y procesable de forma sencilla por aplicaciones informáticas, manteniendo la rigurosidad del marcado documental tradicional pero reduciendo significativamente la complejidad de su predecesor.

Naturaleza de metalenguaje. XML no establece un repertorio cerrado de etiquetas con significado universal, sino que proporciona un conjunto de reglas sintácticas para crear vocabularios propios adaptados a cada dominio específico. Cada aplicación puede definir sus propios elementos, atributos y relaciones jerárquicas siempre que respeten la sintaxis base del lenguaje y, en su caso, las reglas de validación adoptadas.

Separación de contenido y presentación. A diferencia de HTML, que posee etiquetas predefinidas con semántica fija orientada a la visualización, XML se centra exclusivamente en expresar la estructura lógica y la jerarquía interna de los datos. Su objetivo primordial no consiste en describir cómo debe verse un documento, sino representar la información estructurada de forma que resulte interpretable tanto por personas como por sistemas automatizados.

Funciones principales. XML cumple múltiples propósitos en sistemas modernos: actúa como formato estándar de intercambio entre aplicaciones heterogéneas, facilita la configuración de software, permite almacenar datos estructurados en bases documentales, y soporta formatos específicos de dominio como SVG, MathML, XHTML, RSS, Atom, SOAP y WSDL para la serialización de objetos complejos.

Tecnologías asociadas. El ecosistema XML comprende especificaciones complementarias esenciales para su procesamiento completo. Entre ellas destacan DTD y XML Schema para la definición de estructuras y validación de documentos, XSLT para transformaciones entre formatos diferentes, y XPath junto con XQuery para la navegación y consulta selectiva de datos dentro de la estructura jerárquica definida.

Contexto sanitario y evolución. Aunque JSON ha desplazado a XML en muchos escenarios web modernos por su menor verbosidad y mayor simplicidad sintáctica, el lenguaje mantiene presencia significativa en entornos empresariales, integración entre administraciones públicas y sistemas sanitarios, donde se emplea en formatos estándar como HL7 CDA para el intercambio de información clínica estructurada y documental.

🧩 Elementos esenciales

• Extensibilidad: capacidad del lenguaje para definir etiquetas propias según las necesidades específicas de cada dominio de aplicación.
• Metalenguaje: naturaleza de XML como sistema que no proporciona vocabulario fijo, sino reglas sintácticas para crear lenguajes de marcado personalizados.
• Texto plano: formato de almacenamiento legible por humanos y simultáneamente procesable por máquinas sin dependencia de plataformas específicas.
• W3C: organismo internacional responsable del desarrollo y estandarización de XML desde su primera versión en 1998.
• SGML: origen de XML como subconjunto simplificado de este estándar previo, adaptado para su uso en entornos web.
• HTML diferenciado: mientras HTML define presentación visual con etiquetas fijas, XML define estructura lógica con etiquetas personalizables.
• Validación: mecanismos formales mediante DTD o XML Schema para comprobar la corrección estructural y semántica de los documentos.
• Transformación: tecnología XSLT que permite convertir documentos XML a otros formatos como HTML, PDF o texto plano.
• Consulta: uso de XPath para navegar por la estructura jerárquica y XQuery para extraer información específica.
• Independencia de plataforma: capacidad para funcionar en múltiples sistemas operativos y entornos tecnológicos heterogéneos.
• Estándares sanitarios: aplicación específica en HL7 CDA para el intercambio estructurado de documentos clínicos y datos médicos.
• Serialización: posibilidad de representar objetos y estructuras de datos complejas en formato textual estructurado.

🧠 Recuerda

• XML significa eXtensible Markup Language y no posee etiquetas predefinidas universalmente aplicables.
• Es un subconjunto de SGML creado por el W3C en 1998 específicamente para su uso en Internet.
• Su objetivo principal es transportar y almacenar datos, no mostrarlos visualmente como ocurre con HTML.
• Permite crear vocabularios propios adaptados a las necesidades específicas de cada dominio de conocimiento.
• Las tecnologías DTD y XML Schema definen las reglas de estructura y validación de los documentos.
• XSLT permite transformar documentos XML mientras que XPath facilita la navegación por su estructura jerárquica.
• Mantiene vigencia en sistemas empresariales y sanitarios a pesar de la creciente popularidad de JSON.
• HL7 CDA utiliza XML como formato estándar para el intercambio de documentos clínicos estructurados.
• La sintaxis estricta requiere que todos los elementos estén correctamente anidados y cerrados obligatoriamente.
• La legibilidad humana convive con la procesabilidad automática como ventaja fundamental frente a formatos binarios.

5. Desarrollo de aplicaciones web en el cliente

🎯 Idea clave

• El desarrollo de aplicaciones web en el cliente, conocido como frontend, comprende el conjunto de tecnologías y técnicas cuyo código se ejecuta en el navegador del usuario.
• Este paradigma se distingue del desarrollo en servidor porque el procesamiento ocurre en la máquina local, permitiendo interfaces interactivas sin necesidad de peticiones HTTP constantes.
• Las tres tecnologías base son HTML para la estructura, CSS para la presentación y JavaScript para el comportamiento dinámico.
• El desarrollo cliente gestiona la presentación de información, la captura de interacciones, la validación de entradas y la comunicación asíncrona con el servidor.
• Ha evolucionado desde páginas estáticas hasta aplicaciones complejas que rivalizan con el software de escritorio en funcionalidad y rendimiento.

📚 Desarrollo

Definición conceptual. El desarrollo de aplicaciones web en el cliente, también denominado frontend, abarca el conjunto de tecnologías, lenguajes, APIs y herramientas cuyo código se descarga desde el servidor y se ejecuta directamente en el navegador del usuario. Este entorno de ejecución, que incluye navegadores como Chrome, Firefox, Safari o Edge, permite procesar la lógica de presentación e interacción sin intervención del servidor para cada acción individual.

Distinción respecto al backend. A diferencia del desarrollo en servidor, donde la lógica de negocio y persistencia operan en infraestructuras remotas, el desarrollo cliente se ejecuta en la máquina del usuario dependiendo de los estándares de la plataforma web. Ambos lados cooperan mediante peticiones HTTP, llamadas asíncronas como AJAX o Fetch API, y WebSockets, manteniendo responsabilidades, restricciones y herramientas claramente diferenciadas.

Tres capas fundamentales. El W3C denomina "las tres capas de la web" al sustrato tecnológico base: HTML para la estructura y semántica del contenido, CSS para el diseño visual y presentación, y JavaScript para el comportamiento dinámico e interactividad. Estas tecnologías constituyen el fundamento sobre el que se construyen todas las aplicaciones web accesibles desde navegador.

Funcionalidades principales. El desarrollo frontend no se limita a la maquetación estática, sino que comprende la gestión del estado de la interfaz, el tratamiento de eventos, la validación inicial de entradas, el almacenamiento local y el consumo de servicios remotos. Su propósito es presentar información y capturar la interacción del usuario de forma coherente, accesible y eficiente.

Evolución y alcance actual. La disciplina ha transcendido el concepto de simples páginas estáticas para abarcar aplicaciones complejas como Single Page Applications y Progressive Web Apps. Estas soluciones rivalizan con las aplicaciones de escritorio tradicionales en funcionalidad y rendimiento, gestionando actualizaciones dinámicas de contenido, manipulación del DOM y adaptación a distintos dispositivos y capacidades.

Condicionantes operativos. El desarrollo en cliente debe considerar factores como la compatibilidad entre navegadores, la seguridad del contexto de ejecución y el rendimiento percibido por el usuario. La lógica inmediata se ejecuta en el entorno local, permitiendo validaciones preliminares y respuesta rápida, siempre condicionada por la necesidad de comunicación asíncrona con los servicios del servidor.

🧩 Elementos esenciales

• Frontend: denominación alternativa del desarrollo de aplicaciones web en el cliente.
• Agente de usuario: el navegador web que actúa como entorno de ejecución del código descargado.
• HTML: lenguaje de marcado que proporciona la estructura y semántica del contenido.
• CSS: tecnología de hojas de estilo encargada de la presentación y diseño visual.
• JavaScript: lenguaje de programación que gestiona el comportamiento dinámico e interactividad.
• AJAX: técnica de comunicación asíncrona con el servidor sin recargar la página.
• Fetch API: interfaz moderna para realizar peticiones HTTP asíncronas desde el cliente.
• WebSockets: protocolo de comunicación bidireccional en tiempo real entre cliente y servidor.
• SPA: aplicaciones de página única que rivalizan con software de escritorio en funcionalidad.
• Validación de entradas: comprobación inicial de datos realizada en el lado cliente antes del envío al servidor.
• DOM: estructura de objetos que el código cliente manipula para actualizar dinámicamente el contenido.
• Accesibilidad: requisito fundamental para ofrecer experiencias de uso coherentes y eficientes.

🧠 Recuerda

• El código del lado cliente se descarga desde el servidor y se ejecuta en el navegador del usuario.
• La distinción cliente-servidor no es absoluta; ambos cooperan mediante comunicación asíncrona continua.
• Las tres capas base son HTML, CSS y JavaScript según la nomenclatura del W3C.
• No se trata solo de "pintar páginas", sino de gestionar estado, eventos y comunicación.
• El desarrollo frontend evolucionó desde HTML estático hasta aplicaciones complejas tipo SPA y PWA.
• Las validaciones iniciales y el almacenamiento local son responsabilidades típicas del cliente.
• La compatibilidad entre navegadores condiciona las tecnologías utilizables en el desarrollo.
• La experiencia de usuario depende del rendimiento percibido en el entorno local.

6. Desarrollo de aplicaciones web en el servidor

🎯 Idea clave

• El desarrollo de aplicaciones web en el servidor, denominado backend, comprende el conjunto de tecnologías y componentes cuyo código se ejecuta en el servidor web, no en el navegador del usuario.
• El backend gestiona la lógica de negocio, la persistencia de datos, la autenticación, la autorización y la integración con sistemas externos.
• La separación entre frontend y backend se articula mediante APIs que definen la interfaz de comunicación entre ambas capas, pudiendo ser de tipo REST, SOAP o GraphQL.
• En el contexto del Servicio Andaluz de Salud, el desarrollo backend soporta los sistemas de información clínica, los portales de acceso profesional y ciudadano, y las APIs de interoperabilidad con el Sistema Nacional de Salud.
• El servidor asume las decisiones funcionales decisivas como la validación definitiva de datos, la consistencia de operaciones, la trazabilidad de acciones y el control de identidades.
• El backend ha evolucionado desde sencillos scripts CGI hasta arquitecturas modernas de microservicios cloud-native con orquestación Kubernetes y despliegue continuo.

📚 Desarrollo

Definición de backend. El desarrollo de aplicaciones web en el servidor, también denominado backend, abarca el diseño, programación, configuración y explotación del software que se ejecuta en el servidor web. Este código procesa las peticiones HTTP entrantes, ejecuta la lógica de negocio, accede a recursos persistentes y genera las respuestas que se envían al cliente.

Funciones principales. El servidor gestiona la persistencia de datos, la autenticación y autorización de usuarios, la validación definitiva de información, la consistencia de operaciones transaccionales y el registro de acciones. Constituye el núcleo invisible que soporta toda la funcionalidad real de la aplicación, garantizando que la información entregada o modificada sea la correcta.

Separación de responsabilidades. Mientras el frontend opera en el navegador gestionando la interfaz y validaciones inmediatas, el backend concentra el control decisivo. El cliente representa la interacción visual, pero el servidor implementa las reglas de negocio críticas, comprueba identidades y garantiza la confidencialidad y trazabilidad de las operaciones sanitarias.

Interfaz entre capas. La comunicación entre frontend y backend se articula mediante APIs que pueden ser de tipo REST, SOAP o GraphQL. Esta interfaz definida permite que ambas capas evolucionen independientemente manteniendo un contrato de comunicación establecido, facilitando la integración entre sistemas heterogéneos.

Evolución tecnológica. El desarrollo backend ha transitado desde simples scripts CGI en los noventa hasta arquitecturas modernas de microservicios cloud-native con orquestación Kubernetes, observabilidad distribuida y despliegue continuo. Esta creciente complejidad refleja la importancia crítica que las aplicaciones web han adquirido en los servicios públicos y la economía digital.

Aplicación en el SAS. En el Servicio Andaluz de Salud, el backend construye los sistemas de información clínica, los servicios de integración entre centros sanitarios, los portales para ciudadanos y profesionales, y las APIs de interoperabilidad con el Sistema Nacional de Salud y otros organismos. Esta capa es fundamental para garantizar la operativa segura y eficiente de los sistemas sanitarios andaluces.

🧩 Elementos esenciales

• Backend: Conjunto de tecnologías, lenguajes, frameworks y componentes que se ejecutan en el servidor web procesando peticiones HTTP y generando respuestas seguras.
• Lógica de negocio: Conjunto de reglas y operaciones que definen el comportamiento funcional de la aplicación y que se ejecutan exclusivamente en el servidor.
• Persistencia: Capacidad del backend para almacenar, recuperar y gestionar datos en repositorios permanentes como bases de datos y otros recursos.
• Autenticación: Proceso de verificación de identidad de los usuarios que se gestiona en el servidor de forma segura e invulnerable a manipulaciones del cliente.
• Autorización: Control de permisos y accesos que determina qué recursos y operaciones puede utilizar cada usuario autenticado en el sistema.
• API: Interfaz de programación que define cómo se comunican el frontend y el backend, incluyendo tipos como REST, SOAP y GraphQL.
• Microservicios: Arquitectura moderna cloud-native que descompone la aplicación en servicios pequeños e independientes, frecuentemente orquestados con Kubernetes.
• Integración: Capacidad del backend para conectarse con sistemas externos, otros centros hospitalarios y el Sistema Nacional de Salud mediante APIs específicas.
• Trazabilidad: Registro de operaciones y acciones realizadas en el sistema para auditoría, control de seguridad y cumplimiento normativo.
• Validación definitiva: Comprobación final de datos realizada en el servidor, complementaria a las validaciones inmediatas del navegador cliente.

🧠 Recuerda

• El backend es invisible al usuario final pero soporta toda la funcionalidad real y crítica de la aplicación.
• La validación en cliente es inmediata pero la validación definitiva ocurre siempre en el servidor.
• Las APIs son el punto de unión contractual entre el frontend y el backend.
• REST, SOAP y GraphQL son los tipos principales de APIs utilizadas en el contexto del SAS.
• La seguridad crítica (autenticación y autorización) reside exclusivamente en el backend, nunca en el cliente.
• El backend garantiza la consistencia transaccional y la integridad de las operaciones sobre los datos.
• En el SAS, el backend soporta sistemas clínicos, portales de acceso y APIs de interoperabilidad con el SNS.
• La evolución histórica ha pasado de scripts CGI simples a arquitecturas de microservicios cloud-native.
• El backend gestiona el acceso a bases de datos y la integración con sistemas externos.
• La separación frontend/backend permite que cada capa evolucione tecnológicamente de forma independiente mediante contratos de API.

7. Componentes distribuidos

🎯 Idea clave

• Los componentes distribuidos son unidades de software autónomas y reutilizables que se ejecutan en nodos distintos de una red de computadores.
• Permiten descomponer sistemas complejos en partes independientes, desplegables y escalables de forma autónoma.
• Resuelven las limitaciones de los sistemas monolíticos en escalabilidad, tolerancia a fallos y capacidad de reutilización.
• La comunicación entre componentes puede ser síncrona, donde el llamante espera respuesta, o asíncrona, donde no espera respuesta inmediata.
• Su evolución ha transitado desde tecnologías propietarias como CORBA y DCOM hasta arquitecturas modernas de microservicios y serverless.

📚 Desarrollo

Definición fundamental. Los componentes distribuidos constituyen unidades de software autónomas y reutilizables que operan en nodos diferentes dentro de una red de computadores. Estas unidades se comunican mediante protocolos y mecanismos de comunicación estandarizados para colaborar en la provisión de funcionalidad global del sistema. Su naturaleza distribuida permite que cada componente evolucione y escale independientemente del resto.

Separación de procesos. A diferencia de los sistemas monolíticos, donde todos los componentes se ejecutan en el mismo proceso y espacio de memoria, los componentes distribuidos funcionan como procesos independientes en máquinas potencialmente distintas. Esta separación elimina cuellos de botella arquitectónicos y permite distribuir la carga computacional entre múltiples servidores, optimizando el uso de recursos hardware.

Modalidades de comunicación. La interacción entre componentes puede establecerse mediante comunicación síncrona, donde el llamante permanece bloqueado hasta recibir la respuesta del componente destino, utilizando mecanismos como RPC, servicios web SOAP o REST. Alternativamente, la comunicación asíncrona permite al emisor continuar su ejecución sin esperar respuesta inmediata, empleando sistemas de mensajería como JMS, RabbitMQ o Kafka.

Evolución tecnológica. La historia de los componentes distribuidos abarca varias generaciones tecnológicas. Las primeras implementaciones utilizaban tecnologías propietarias como DCE, CORBA, DCOM y RMI durante los años noventa. Posteriormente, los servicios web SOAP con WSDL dominaron en los años 2000, seguidos por el auge de REST con HTTP y JSON desde 2010. Las arquitecturas actuales incorporan microservicios, serverless, gRPC, GraphQL y patrones event-driven.

Ventajas arquitectónicas. La computación distribuida posibilita escalar sistemas a niveles inalcanzables con servidores únicos, ofreciendo alta disponibilidad mediante redundancia de componentes. Permite especializar funcionalidades en componentes concretos y facilita que equipos diferentes evolucionen partes del sistema de forma independiente, acelerando los ciclos de desarrollo y despliegue.

🧩 Elementos esenciales

• Autonomía: Cada componente opera como unidad independiente desplegable en nodos separados sin dependencias runtime de otros componentes en el mismo proceso.
• Reutilización: Diseñados para ser reutilizados en diferentes contextos y aplicaciones dentro de la arquitectura distribuida.
• Comunicación síncrona: El llamante espera la respuesta antes de continuar, implementada mediante RPC, SOAP o REST.
• Comunicación asíncrona: El emisor envía mensajes sin bloqueo, utilizando colas como JMS, RabbitMQ o Kafka.
• Escalabilidad horizontal: Capacidad de distribuir carga entre múltiples instancias en diferentes máquinas.
• Tolerancia a fallos: Redundancia que permite que el sistema continúe funcionando si falla un nodo específico.
• Procesos independientes: Ejecución en espacios de memoria y procesos separados, a diferencia de los sistemas monolíticos.
• Protocolos estandarizados: Uso de mecanismos de comunicación normalizados para la interoperabilidad entre componentes heterogéneos.
• Tecnologías legacy: DCE, CORBA, DCOM y RMI como precursores en los años noventa.
• Tecnologías modernas: Microservicios, arquitecturas serverless, gRPC, GraphQL y sistemas event-driven actuales.

🧠 Recuerda

• Componente distribuido es software autónomo que corre en máquinas distintas comunicándose por red.
• Comunicación síncrona bloquea al llamante hasta recibir respuesta (RPC, REST).
• Comunicación asíncrona permite continuar sin esperar (mensajería JMS, Kafka).
• Los sistemas monolíticos ejecutan todo en un mismo proceso; los distribuidos separan la lógica en procesos independientes.
• REST y SOAP son tecnologías de comunicación síncrona ampliamente utilizadas.
• CORBA y DCOM son ejemplos de tecnologías propietarias antiguas.
• Los microservicios representan la evolución actual de los componentes distribuidos.
• La escalabilidad y tolerancia a fallos son ventajas clave sobre los sistemas monolíticos.

8. Publicación de contenidos

🎯 Idea clave

• El Servicio Andaluz de Salud dispone de múltiples canales digitales para la publicación de contenidos dirigidos a ciudadanos y profesionales sanitarios.
• Los portales corporativos y de ciudadanía deben cumplir la normativa de accesibilidad web según el Real Decreto 1112/2018 y las guías WCAG 2.1 y 2.2.
• El formato de sindicación Atom (RFC 4287) permite la distribución automatizada de contenidos actualizados en los portales públicos.
• El Portal de Datos Abiertos de la Junta de Andalucía alberga el catálogo de datasets sanitarios disponibles para reutilización pública.
• La publicación de contenidos debe garantizar la interoperabilidad y seguridad conforme al Esquema Nacional de Interoperabilidad y el Esquema Nacional de Seguridad.

📚 Desarrollo

Portales institucionales. El Servicio Andaluz de Salud mantiene una arquitectura de publicación digital diversificada que incluye el portal corporativo como sede institucional en internet, el portal ClicSalud+ orientado específicamente a la ciudadanía para el acceso a servicios sanitarios, y la intranet SSPA como espacio restringido para la difusión de información interna exclusiva entre los profesionales del sistema sanitario público andaluz.

Marco legal de publicación. La actividad publicadora del sector público se fundamenta en la Ley 40/2015, de Régimen Jurídico del Sector Público, y la Ley 39/2015, de Procedimiento Administrativo Común, normativas que establecen el deber de publicidad activa, transparencia y difusión de la información relativa a la organización, actividad y resultados de las administraciones públicas en el ámbito sanitario andaluz.

Accesibilidad universal. El Real Decreto 1112/2018 establece los requisitos de accesibilidad aplicables a los sitios web y aplicaciones móviles del sector público, exigiendo el cumplimiento de los niveles A y AA de las Pautas de Accesibilidad para el Contenido Web WCAG 2.1 y su versión actualizada WCAG 2.2, garantizando el acceso universal sin barreras a la información sanitaria pública.

Sindicación y protocolos web. La distribución automatizada de contenidos actualizados se realiza mediante el formato Atom Syndication Format, definido en el RFC 4287 del IETF, mientras que la transferencia de información en la web se fundamenta en el protocolo HTTP según las especificaciones semánticas del RFC 9110, que establece los fundamentos de la comunicación web para la publicación de recursos.

Datos abiertos y transparencia. El Portal de Datos Abiertos de la Junta de Andalucía alberga el catálogo específico de conjuntos de datos del sector sanitario, permitiendo la publicación en formatos abiertos y reutilizables de información pública que facilita la transparencia administrativa y el análisis por parte de la ciudadanía y otros organismos.

Seguridad e interoperabilidad. La publicación electrónica de contenidos debe ajustarse a los requisitos del Esquema Nacional de Interoperabilidad, regulado por el Real Decreto 4/2010, y del Esquema Nacional de Seguridad, establecido en el Real Decreto 311/2022, normativas que garantizan la protección de la información y la compatibilidad técnica entre los distintos sistemas de información sanitaria.

Canales móviles complementarios. La estrategia de publicación de contenidos del SAS se extiende más allá de la web tradicional mediante aplicaciones móviles como Salud Responde y la App Salud Andalucía, que permiten a la ciudadanía acceder a información sanitaria y servicios digitales desde dispositivos móviles, ampliando así los canales de difusión institucional.

Sede electrónica administrativa. La Sede Electrónica General de la Junta de Andalucía funciona como el canal oficial para la publicación de información administrativa y normativa del Servicio Andaluz de Salud, así como para la realización de trámites electrónicos, constituyendo el punto de entrada legalmente válido y seguro para la interacción telemática entre la ciudadanía y la administración sanitaria andaluza.

🧩 Elementos esenciales

• Portal Corporativo SAS: Plataforma principal de presencia institucional y publicación de información sanitaria del Servicio Andaluz de Salud en internet.
• ClicSalud+: Portal específico de ciudadanía para el acceso a servicios e información del Sistema Sanitario Público de Andalucía.
• WCAG 2.1 y 2.2: Pautas de accesibilidad para contenido web del W3C aplicables obligatoriamente a los portales públicos según el Real Decreto 1112/2018.
• Atom Syndication Format: Protocolo estándar definido en el RFC 4287 para la distribución y sindicación de contenidos web actualizados.
• Portal Datos Abiertos: Plataforma de publicación de datasets reutilizables del sector público andaluz, incluyendo catálogos específicos del sector sanitario.
• Sede Electrónica: Canal oficial para la publicación de información administrativa y apertura de procedimientos electrónicos con la Junta de Andalucía.
• Intranet SSPA: Red interna restringida para la publicación de contenidos dirigidos exclusivamente a profesionales del Servicio Andaluz de Salud.
• RFC 9110: Especificación de semánticas HTTP que fundamenta la transferencia de contenidos en la web del sector público.
• ENS y ENI: Esquemas nacionales que regulan la seguridad y la interoperabilidad de los contenidos publicados electrónicamente por las administraciones públicas.
• Aplicaciones móviles: Salud Responde y App Salud Andalucía como extensiones móviles de los canales de publicación de contenidos sanitarios.

🧠 Recuerda

• Todo portal público debe cumplir niveles A y AA de accesibilidad según el Real Decreto 1112/2018.
• WCAG 2.2 actualiza y complementa las pautas de accesibilidad web aplicables a los sitios del sector público.
• Atom (RFC 4287) es el formato estándar para la sindicación y distribución de contenidos actualizados.
• Los datos abiertos sanitarios se publican en el portal específico de la Junta de Andalucía para reutilización.
• La intranet SSPA es el canal restringido exclusivo para contenidos internos del personal sanitario.
• La Sede Electrónica concentra la información administrativa oficial y los trámites telemáticos.
• ClicSalud+ es el portal de referencia para la ciudadanía en materia de información sanitaria.
• La publicación electrónica requiere cumplir simultáneamente el Esquema Nacional de Interoperabilidad y el Esquema Nacional de Seguridad.
• Las aplicaciones móviles amplían los canales de publicación más allá de los sitios web tradicionales.
• El protocolo HTTP según el RFC 9110 fundamenta la transferencia técnica de contenidos en la web pública.

9. Herramientas para la edición, gestión y personalización de contenidos en Internet

🎯 Idea clave

• Las herramientas de edición, gestión y personalización de contenidos abarcan todo el ciclo de vida del contenido digital, desde su concepción inicial hasta su retirada planificada.
• Estas soluciones tecnológicas se organizan en familias complementarias que incluyen editores, CMS, gestores de medios digitales, plataformas de personalización y herramientas analíticas.
• En el contexto del SAS, estas herramientas sostienen los portales corporativos, ClicSalud+, la intranet del profesional y los sitios temáticos institucionales.
• El cumplimiento del estándar de accesibilidad WCAG 2.1 AA constituye un requisito exigible en la selección de herramientas para el sector público andaluz.
• Drupal es la solución recomendada por la Junta de Andalucía para el desarrollo de portales públicos de complejidad elevada y gran volumen de contenidos.
• La capacidad de integración con sistemas corporativos, identidad visual y plataformas estatales condiciona la elección tecnológica en el entorno sanitario público.

📚 Desarrollo

Definición conceptual. Las herramientas para la edición, gestión y personalización de contenidos en Internet configuran un entorno tecnológico que permite crear, organizar, modificar, distribuir y adaptar información digital de forma estructurada y coherente. Su ámbito de actuación cubre todo el ciclo del contenido, desde la redacción inicial hasta la retirada planificada, integrando procesos de diseño visual, control de versiones, flujos editoriales y distribución multicanal.

Cuatro capas diferenciadas. El estudio de estas herramientas exige distinguir al menos cuatro fases: edición, gestión, publicación y personalización. La edición comprende la redacción, corrección, inserción de imágenes y documentos, definición de metadatos y preparación de elementos audiovisuales, utilizando editores WYSIWYG, basados en bloques, estructurados por formularios o apoyados en plantillas que garantizan reglas de formato y accesibilidad.

Familias tecnológicas. El ecosistema profesional se compone de editores de texto y código, plataformas CMS, gestores de medios digitales (DAM), herramientas de diseño visual, plataformas de personalización y experimentación, traductores asistidos, sistemas analíticos, herramientas SEO, gestores de redes sociales y motores de búsqueda interna. La integración efectiva entre estas familias conforma entornos profesionales completos para la publicación digital.

Sistemas de gestión de contenidos. Los CMS más relevantes en Administraciones Públicas españolas incluyen WordPress, orientado a sitios institucionales pequeños o medianos con editor Gutenberg basado en React; Drupal, recomendado por la Junta de Andalucía para portales complejos con modelado avanzado de tipos de contenido, taxonomías, vistas y multilenguaje nativo potente; y Joomla, de complejidad intermedia entre los anteriores, con soporte multilenguaje nativo y sistema robusto de gestión de usuarios y permisos.

Aplicación en el SAS. En el Servicio Andaluz de Salud, estas herramientas mantienen los portales corporativos, ClicSalud+, la intranet del profesional y los sitios temáticos. La elección de soluciones combina criterios funcionales con cumplimiento normativo, exigiendo soporte de accesibilidad WCAG 2.1 AA e integración fluida con la identidad corporativa, sistemas de archivo y plataformas estatales del entorno sanitario.

Competencias del técnico. Para el Técnico Especialista en Informática, comprender este ecosistema facilita atender consultas de usuarios editoriales, configurar y mantener plataformas, integrar componentes heterogéneos y resolver incidencias en flujos de publicación. La capacidad de aprender nuevas herramientas con rapidez y consultar documentación técnica constituye una competencia profesional esencial y cotidiana.

Herramientas específicas. El entorno incluye editores de texto enriquecido como CKEditor y TinyMCE, motores de búsqueda interna como Apache Solr y Elasticsearch, sistemas de analítica web como Matomo, y verificadores de accesibilidad como axe DevTools y WAVE, configurando un ecosistema integral para la gestión profesional de contenidos en el sector público.

🧩 Elementos esenciales

• Ciclo de vida del contenido: Comprende creación, organización, modificación, distribución y retirada planificada de información digital en entornos web.
• Cuatro capas distintivas: Edición, gestión, publicación y personalización como fases diferenciadas e interrelacionadas del proceso completo.
• Editores de contenido: Herramientas WYSIWYG, basadas en bloques, formularios o plantillas que garantizan consistencia, formato y accesibilidad en la redacción.
• CMS principales: WordPress (sitios pequeños/medianos), Drupal (portales complejos y recomendado por la Junta de Andalucía) y Joomla (complejidad intermedia).
• DAM: Gestores de medios digitales especializados en el almacenamiento, organización y recuperación de recursos audiovisuales.
• Accesibilidad WCAG 2.1 AA: Requisito normativo exigible y verificable para las herramientas utilizadas en el sector público andaluz.
• Integración corporativa: Capacidad de conexión con sistemas de archivo, identidad corporativa y plataformas estatales como condicionante decisivo.
• Motores de búsqueda: Apache Solr y Elasticsearch para implementar búsqueda interna avanzada en portales institucionales.
• Analítica web: Matomo como herramienta de análisis de comportamiento de usuarios y tráfico de sitios web.
• Verificación de accesibilidad: axe DevTools y WAVE como evaluadores técnicos de conformidad con estándares de accesibilidad web.
• Portales del SAS: ClicSalud+, intranet del profesional y sitios temáticos como ámbitos principales de aplicación de estas herramientas.
• Flujos editoriales: Procesos estructurados de revisión, aprobación y publicación que deben soportar las plataformas gestoras de contenidos.

🧠 Recuerda

• El concepto abarca todo el ciclo de vida del contenido digital, no únicamente su publicación inicial o almacenamiento.
• Drupal es la opción recomendada por la Junta de Andalucía para portales públicos que requieren modelado avanzado y multilenguaje robusto.
• La accesibilidad WCAG 2.1 AA es un requisito obligatorio, no opcional, en la selección de herramientas para el sector público.
• Las herramientas se agrupan en familias complementarias que deben integrarse correctamente para formar un ecosistema profesional completo.
• El técnico debe dominar la resolución de incidencias en flujos editoriales y mantener capacidad de aprendizaje rápido de nuevas soluciones.
• Los editores pueden ser WYSIWYG, por bloques o estructurados por formularios según el nivel de control y accesibilidad requerido.
• La integración con sistemas corporativos y plataformas estatales es un criterio técnico decisivo en la selección de soluciones para el SAS.

10. Javascript y AJAX

🎯 Idea clave

• JavaScript es el lenguaje de programación estándar que se ejecuta de forma nativa en todos los navegadores modernos sin necesidad de plugins.
• Se caracteriza por ser interpretado, débilmente tipado, multiparadigma y orientado a objetos mediante herencia basada en prototipos.
• Está estandarizado como ECMAScript (especificación ECMA-262), siendo ES2015 (ES6) la versión de referencia con actualizaciones anuales posteriores.
• AJAX (Asynchronous JavaScript And XML) es una técnica que permite la comunicación asíncrona entre navegador y servidor sin recargar la página completa.
• El término AJAX fue acuñado por Jesse James Garrett en febrero de 2005, aunque la tecnología subyacente (XMLHttpRequest) existía desde 1998.
• Esta combinación de tecnologías constituye el fundamento de la web dinámica moderna y de la experiencia de usuario interactiva en las aplicaciones del SAS.

📚 Desarrollo

Lenguaje del navegador. JavaScript es el único lenguaje de programación que se ejecuta de forma nativa en todos los navegadores modernos sin necesidad de plugins adicionales. Es interpretado, débilmente tipado y soporta múltiples paradigmas de programación, incluyendo la orientación a objetos mediante herencia basada en prototipos, así como la programación funcional y asíncrona.

Estandarización ECMA. El lenguaje está estandarizado bajo la denominación ECMAScript (especificación ECMA-262) por ECMA Internacional. La versión de referencia actual es ES2015, conocida como ES6, a la cual siguen actualizaciones anuales posteriores que incorporan nuevas funcionalidades y mejoras al estándar.

Técnica asíncrona. AJAX (Asynchronous JavaScript And XML) es una técnica de desarrollo web que posibilita la comunicación entre el navegador y el servidor en segundo plano. Fue acuñada por Jesse James Garrett en febrero de 2005, aunque su tecnología base, el objeto XMLHttpRequest, ya existía desde 1998 en Internet Explorer 5.

Conjunto tecnológico. AJAX no constituye una tecnología única, sino un conjunto de tecnologías que operan conjuntamente: JavaScript para la lógica, el objeto XMLHttpRequest o la moderna Fetch API para las peticiones asíncronas, HTML y CSS para la presentación visual, y formatos como XML o JSON para el intercambio de datos.

Actualización dinámica. Esta técnica permite actualizar partes específicas del contenido de una página web de forma dinámica, sin necesidad de recargar la totalidad del documento. El resultado son aplicaciones más interactivas, responsivas y eficientes en el uso del ancho de banda.

Base de la web dinámica. JavaScript y AJAX constituyen el corazón de la web dinámica moderna y representan la base fundamental de la experiencia de usuario interactiva en los portales y aplicaciones del Servicio Andaluz de Salud, permitiendo interfaces ricas y comunicación fluida con servidores.

🧩 Elementos esenciales

• ECMAScript: especificación estándar que define JavaScript, mantenida por ECMA Internacional bajo el código ECMA-262.
• Herencia prototipal: modelo de orientación a objetos de JavaScript donde los objetos heredan directamente de otros objetos, no de clases.
• Multiparadigma: JavaScript soporta programación orientada a objetos, funcional y asíncrona simultáneamente.
• XMLHttpRequest: objeto API disponible desde 1998 que permite realizar peticiones HTTP asíncronas desde el navegador.
• Fetch API: interfaz moderna alternativa a XMLHttpRequest para realizar solicitudes de red de manera más flexible y basada en promesas.
• JSON: formato de texto ligero para el intercambio de datos, alternativa más liviana que XML en aplicaciones AJAX modernas.
• Jesse James Garrett: profesional que acuñó el término AJAX en 2005, dando nombre a una técnica ya existente técnicamente.
• Actualizaciones anuales: mecanismo de evolución de ECMAScript posterior a ES2015 (ES6) que incorpora mejoras incrementales al lenguaje.

🧠 Recuerda

• JavaScript es el único lenguaje nativo de todos los navegadores modernos sin plugins.
• AJAX no es una tecnología única sino una combinación de tecnologías existentes.
• El objeto XMLHttpRequest precedió al término AJAX en siete años.
• ES6 (ES2015) es la versión de referencia actual del estándar ECMAScript.
• AJAX permite actualizar partes de la página sin recarga completa.
• La comunicación asíncrona mejora la experiencia de usuario y reduce el tráfico de red.
• JSON ha sustituido en gran medida a XML como formato de intercambio en aplicaciones modernas.
• El desarrollo frontend del SAS se apoya fundamentalmente en estas tecnologías para sus portales y aplicaciones clínicas.

11. Web semántica

🎯 Idea clave

• La web semántica, propuesta por Tim Berners-Lee en 2001, amplía la web tradicional añadiendo significado formal a los datos para que las máquinas puedan procesarlos automáticamente.
• Su arquitectura se organiza en capas superpuestas conocidas como Semantic Web Stack, desde identificadores URI hasta capas de confianza y criptografía.
• RDF constituye el modelo fundamental de datos basado en tripletas sujeto-predicado-objeto que representan conocimiento como grafos interconectados.
• OWL permite la descripción formal de ontologías con capacidad de razonamiento automático, mientras que SPARQL proporciona el lenguaje de consulta para recuperar información de grafos RDF.
• En el ámbito sanitario del SAS, estas tecnologías facilitan la interoperabilidad semántica mediante vocabularios controlados como SNOMED CT y la publicación de datos estructurados en formatos reutilizables.

📚 Desarrollo

Definición fundacional. La web semántica constituye una extensión de la web tradicional que añade significado formal a los datos mediante tecnologías del W3C, permitiendo que sistemas automáticos procesen la información con mayor precisión semántica. Tim Berners-Lee propuso esta visión en 2001 para transformar la web actual en un espacio donde los datos sean comprensibles no solo por humanos sino por máquinas.

Arquitectura por capas. El Semantic Web Stack organiza las tecnologías en niveles superpuestos que van desde la identificación mediante URI e IRI, variante internacionalizada con soporte Unicode, pasando por la capa sintáctica XML, hasta el modelo de datos RDF. Sobre estas bases se construyen los vocabularios y ontologías mediante RDFS, OWL y SKOS, seguidos por el lenguaje de consulta SPARQL y las capas superiores de validación SHACL, reglas SWRL y mecanismos de confianza y criptografía.

Modelo de datos RDF. El Resource Description Framework establece el marco común para expresar información sobre recursos mediante tripletas que relacionan sujeto, predicado y objeto, representando el conocimiento como grafos de datos interconectados. La versión RDF 1.1, recomendación W3C de 2014, se serializa preferentemente en formatos como Turtle, compacta y legible, o JSON-LD, recomendado por el W3C y utilizado por Google para datos estructurados en buscadores.

Lenguajes de ontologías. RDFS proporciona el vocabulario básico para crear esquemas RDF mediante constructos como Class, subClassOf, Property, domain y range. OWL constituye el lenguaje de ontologías que permite la descripción formal de conceptos y relaciones con capacidad de razonamiento automático, existiendo herramientas como HermiT, Pellet, FaCT++ y ELK. OWL 2, recomendación W3C de 2009, define perfiles específicos EL, QL y RL adaptados a diferentes necesidades computacionales.

Capacidad de consulta. SPARQL funciona como lenguaje de consulta para bases de datos RDF, análogo a SQL en bases relacionales, con operaciones SELECT, CONSTRUCT, ASK y DESCRIBE. La versión SPARQL 1.1, recomendación W3C de 2013, incorpora capacidades de federación de consultas mediante el servicio SERVICE que permite consultar múltiples fuentes distribuidas simultáneamente.

Aplicación en el SAS. El Servicio Andaluz de Salud implementa estas tecnologías para garantizar la interoperabilidad semántica mediante el uso de ontologías médicas estándar como SNOMED CT, con más de 350.000 conceptos representables en OWL, junto con LOINC y CIE-10. Las guías de práctica clínica pueden modelarse como ontologías OWL para integrarse en sistemas de soporte a la decisión clínica, mientras que el estándar HL7 FHIR resulta compatible con JSON-LD para la publicación de recursos clínicos.

Publicación de datos. La Consejería de Salud y el SAS publican datos estadísticos y de actividad asistencial en el portal de datos abiertos progresivamente en formatos reutilizables. El portal de salud emplea Schema.org junto con JSON-LD para describir información de centros, horarios, servicios y eventos de salud, mejorando la visibilidad en buscadores y la accesibilidad para agentes automáticos en línea con los principios de Linked Data definidos por Berners-Lee en 2006.

🧩 Elementos esenciales

• URI/IRI: Identificadores únicos y globales para recursos que constituyen la base del modelo RDF, donde IRI añade soporte para caracteres Unicode.
• RDF: Marco de datos que representa conocimiento mediante grafos de tripletas sujeto-predicado-objeto, siendo la piedra angular del modelo de datos semántico.
• Turtle: Sintaxis de serialización RDF compacta y legible que resulta la más utilizada para representar grafos de conocimiento.
• JSON-LD: Formato de serialización RDF basado en JSON, recomendado por el W3C y empleado por Google para la implementación de datos estructurados en resultados de búsqueda.
• RDFS: Vocabulario básico para la construcción de esquemas RDF que incluye constructos como Class, subClassOf, Property, domain y range.
• OWL: Lenguaje de ontologías web que permite la descripción formal de conceptos y relaciones con capacidad de razonamiento automático mediante motores inferenciales.
• SPARQL: Lenguaje estandarizado para la consulta y manipulación de grafos RDF, análogo a SQL pero adaptado a la naturaleza de triples.
• SNOMED CT: Terminología clínica formal que contiene más de 350.000 conceptos relacionados, completamente representable en OWL para sistemas de información sanitaria.
• Schema.org: Vocabulario colaborativo para el marcado de datos estructurados en páginas web, utilizado conjuntamente con JSON-LD para mejorar la visibilidad en buscadores.
• Linked Data: Conjunto de cuatro principios definidos por Berners-Lee en 2006 para la publicación de datos interconectados en la web mediante estándares abiertos.

🧠 Recuerda

• Tim Berners-Lee propuso la web semántica en 2001 y los principios de Linked Data en 2006.
• RDF modela la información mediante tripletas sujeto-predicado-objeto formando grafos de conocimiento.
• Turtle ofrece la sintaxis más legible mientras que JSON-LD facilita la integración con aplicaciones web modernas.
• OWL 2 define tres perfiles específicos: EL, QL y RL, cada uno optimizado para diferentes escenarios de razonamiento.
• SPARQL 1.1 incorpora federación de consultas mediante la cláusula SERVICE para acceder a múltiples fuentes distribuidas.
• La interoperabilidad semántica en sanidad depende de la adopción de vocabularios controlados como SNOMED CT, LOINC y CIE-10.
• HL7 FHIR es compatible con JSON-LD, facilitando la publicación de recursos clínicos con semántica formal.
• Los razonadores OWL como HermiT, Pellet, FaCT++ y ELK permiten inferir conocimiento automáticamente a partir de las ontologías definidas.