Unidad 3

Diseño de la puesta en marcha

3.1 arquitectura lógica, tecnológica y organizacional

Una arquitectura logica se selecciona y diseña con base en objetivos y restricciones. Los objetivos son aquellos prefijados para el sistema de información, pero no solamente los de tipo funcional, también otros objetivos como la mantenibilidad, auditabilidad, flexibilidad e interacción con otros sistemas de información. Las restricciones son aquellas limitaciones derivadas de las tecnologías disponibles para implementar sistemas de información. Unas arquitecturas son más recomendables de implementar con ciertas tecnologías mientras que otras tecnologías no son aptas para determinadas arquitecturas. Por ejemplo, no es viable emplear una arquitectura de software de tres capas para implementar sistemas en tiempo real.

La arquitectura tecnológica de una institución recoge el conjunto de decisiones significativas sobre la organización del software, sus interfaces, su comportamiento y su interacción, así como la selección y composición de los elementos estructurales (infraestructura tecnológica). Por encima de todo, sin embargo, la arquitectura tecnológica tiene que ser una definición de estilo: la descripción de las motivaciones o fundamentos que determinan por qué un sistema está diseñado de la forma en que lo está. Una arquitectura se selecciona y se diseña en función de objetivos y restricciones, y es una visión a alto nivel. Por lo tanto, no explica cómo está implementado un sistema, sino que define conceptos como sus principios y factores, la organización, estilos, patrones, responsabilidades, colaboraciones, conexiones y motivaciones.

Así pues, la arquitectura tecnológica en la UOC responde a un modelo de referencia abstracto o de alto nivel y a unas políticas generales de la institución. Se orienta a establecer el modelo de relación entre los diversos elementos tecnológicos dentro de la UOC y también los mecanismos para su actualización constante. En la sección de infraestructura tecnológica se describe la arquitectura física y los principales elementos de la infraestructura tecnológica de la UOC. Así pues, en esta sección, se describe sólo la arquitectura lógica. Esta lógica aporta a la institución un marco de referencia en cuanto a patrones y abstracciones para la construcción de nuevo software y para la integración de herramientas o servicios ya existentes.

Los siguientes diagramas ilustran esta arquitectura lógica de la UOC. El diagrama 1 muestra los mecanismos de acceso a la UOC, basados en el servicio de autentificación, que es uno de los elementos más destacados de esta arquitectura.

El servicio de autentificación permite a los usuarios acceder al entorno de la UOC. Pero, aparte de los usuarios, también hace posible el acceso a aplicaciones informáticas. Así, por ejemplo, una aplicación debidamente certificada e instalada en el teléfono móvil de un estudiante o de un profesor también podría acceder a la UOC. Estos mecanismos, llamados single sign-on (SSO), permiten que el campus y otras herramientas de la UOC se puedan integrar y relacionar con otros sistemas externos a la universidad. Los sistemas externos, pues, pueden autentificar y acceder a la UOC mediante diversos mecanismos de autentificación, entre los cuales destacan CAS, Shibboleth, IMS Basic LTI y las interfaces OKI OSIDs.

Arquitectura organizacional

Los verdaderos líderes empresariales, aquellos que hacen de sus empresas proyectos exitosos y perdurables, son, ante todo, verdaderos “arquitectos organizacionales”.

¿Qué quiere decir que son “arquitectos organizacionales”? Que se preocupan del diseño “arquitectónico” de su organización, para conseguir obtener la máxima eficiencia de la misma. Hacer que la organización sea un activo, aparte de las personas que pueblen ese “edificio organizativo”. Una organización bien diseñada es como una casa acogedora y funcional, que ayuda a vivir bien, y que ahorra energía. Una organización bien diseñada es aquella que potencia las capacidades de las personas que la “habitan”. Que ayuda a las personas a conseguir los objetivos estratégicos con un margen adecuado de autonomía, que evita los solapamientos, que favorece la convergencia de esfuerzos y evita la divergencia de enfoques, y que, por encima de todo, es fiel a la filosofía de la empresa, y permite aplicarla sin trabas. Como todo edificio, el edificio organizacional ha de compaginar coste y eficiencia. Ha de ser barato de mantener (“sostenible”) y ha de ser suficientemente flexible para adaptarse al entorno cambiante.

Ha de compaginar también las ideas generales con las aplicaciones concretas, aquí y ahora, acoplándose a los recursos de los que se dispone en cada momento (principalmente personas) para sacar el máximo partido de los mismos sin traicionar el espíritu del modelo. Un buen directivo no se limita a ganar un objetivo puntual, a ganar una batalla aislada, sino que se asegura de que su equipo estará preparado para ganar las sucesivas batallas que se le irán presentando en el tiempo; es decir, para ganar la guerra frente a la competencia. Para ganar esa guerra, es más importante dotarse de un buen diseño organizacional que de las mejores personas. De hecho, las mejores personas surgen de buenos edificios organizacionales, y se rebelan y dejan la empresa si se les hace trabajar en entornos organizativos incómodos, incoherentes o ineficientes.

Un elemento clave de esa arquitectura organizacional es que la organización, el edificio organizacional, no dependa de un solo apoyo, de un solo líder. Como todo edificio, hay que asentar la organización en varias columnas de apoyo, una complementaria de la otra, sin que el edificio dependa de una de ellas en particular.

Los buenos gestores, aquellos cuyas empresas perduran, son verdaderos arquitectos de organizaciones. Podríamos decir que ese es su rasgo más característico. Y hay quien dice que el éxito de una empresa es 80% organización y 20% dirección (estrategia y ejecución). En cuanto a si hay un diseño organizacional bueno per se, en mi opinión, no. La arquitectura de una organización se ha de adaptar a sus propias características, del mismo modo que no todas las casas son iguales, sino que se adaptan a las características del terreno y a la filosofía que quiere impregnarles su diseñador.

El diseño de una organización es función, pues, de la filosofía, los objetivos y los recursos de una empresa (humanos y financieros). Pero, en cualquier caso, hay unos principios básicos que se respetan siempre, al margen de las peculiaridades del diseño. Quizás el principio más importante es el respeto a la consistencia. Una organización debe apuntar en la misma dirección en todos sus puntos. Por ejemplo, no puede pretender ser centralizadora y descentralizadora a la vez.

Otros principios de arquitectura organizacional son: la clarificación de responsabilidades en cada puesto, la coherencia entre responsabilidad y autoridad, el respeto al ámbito de autoridad de los subordinados (no “cortocircuitar”), la designación clara de un jefe único y claro para cada persona, la limitación del número de subordinados directos a una cifra manejable, la fijación clara de objetivos anuales y plurianuales a cada persona por parte de su jefe, la coherencia entre los objetivos y los recursos, la evaluación formal del desempeño de cada persona al menos una vez al año, etc.

3.2 transporte de datos

Servicios proporcionados a las capas superiores La meta final de la capa de transporte es proporcionar un servicio eficiente, confiable y económico a sus usuarios, que normalmente son procesos de la capa de aplicación. Para lograr este objetivo, la capa de transporte utiliza los servicios proporcionados por la capa de red. El hardware o software de la capa de transporte que se encarga del transporte se llama entidad de transporte, la cual puede estar en el núcleo del sistema operativo, en un proceso independiente, en un paquete de biblioteca o en la tarjeta de red.

Hay dos tipos de servicio en la capa de transporte, orientado y no orientado a la conexión. En el servicio orientado a la conexión consta de tres partes: establecimiento, transferencia de datos, y liberación. En el servicio no orientado a la conexión se tratan los paquetes de forma individual.

Es la primera capa que lleva a cabo la comunicación extremo a extremo, y esta condición ya se mantendrá en las capas superiores. Primitivas del servicio de transporte

Para permitir que los usuarios accedan al servicio de transporte, la capa de transporte debe proporcionar algunas operaciones a los programas de aplicación, es decir, una interfaz del servicio de transporte. Cada servicio de transporte tiene su propia interfaz. Con el propósito de ver los aspectos básicos, en esta sección examinaremos primero un servicio de transporte sencillo y su interfaz.

El servicio de transporte es parecido al servicio en red, pero hay algunas diferencias importantes. La principal, es que, el propósito del servicio de red es modelar el servicio ofrecido por las redes reales, con todos sus problemas. Las redes reales pueden perder paquetes, por lo que generalmente el servicio no es confiable. En cambio, el servicio de transporte (orientado a la conexión) si es confiable. Claro que las redes reales no están libres de errores, pero ése es precisamente el propósito de la capa de transporte: ofrecer un servicio confiable en una red no confiable.

Otra diferencia entre la capa de transporte y la de red es a quien van dirigidos sus servicios. El servicio de red lo usan únicamente las entidades de transporte. Pocos usuarios escriben sus entidades de transporte y pocos usuarios o programas llegan a ver los aspectos internos del servicio de red. En cambio, muchos programas ven primitivas de transporte. En consecuencia el servicio de transporte debe ser adecuado y fácil de usar.

Las primitivas de un transporte sencillo serían:

• LISTEN: Se bloquea hasta que algún proceso intenta el contacto.
• CONNECT: Intenta activamente establecer una conexión.
• SEND: Envía información.
• RECEIVE: Se bloquea hasta que llegue una TPDU de DATOS.
• DISCONNECT: Este lado quiere liberar la conexión.

Y con estas primitivas podemos hacer un esquema sencillo de manejo de conexiones. Las transiciones escritas en cursiva son causadas por llegadas de paquetes. Las líneas continuas muestran la secuencia de estados del cliente y las líneas punteadas muestran la secuencia del servidor.

Sockets de Berkeley

Este es otro grupo de primitivas de transporte, las primitivas usadas en UNIX para el TCP. En general son muy parecidas a las anteriores pero ofrecen más características y flexibilidad. Elementos de los protocolos de transporte El servicio de transporte se implementa mediante un protocolo de transporte entre dos entidades de transporte. En ciertos aspectos, los protocolos de transporte se parecen a los protocolos de red. Ambos se encargan del control de errores, la secuenciación y el control del flujo. Pero también existen diferencias importantes entre ambas, como los entornos en que operan, la capa transporte necesita el direccionamiento explícito de los destinos, mientras que la capa de red no, otra diferencia es la cantidad de datos, mucho mayor en la capa de transporte. Direccionamiento Cuando un proceso desea establecer una conexión con un computador de aplicación remoto, debe especificar a cuál se conectará (¿a quién le mensaje?). El método que normalmente se emplea es definir direcciones de transporte en las que los procesos pueden estar a la escucha de solicitudes de conexiones. En Internet, estos puntos terminales se denominan puertos, pero usaremos el término genérico de TSAP (Punto de Acceso al Servicio de Transporte). Los puntos terminales análogos de la capa de red se llaman NSAP (Punto de Acceso al Servicio de Red). Las direcciones IP son ejemplos de NSAPS.

Establecimiento de una conexión

El establecimiento de una conexión parece fácil, pero en realidad es sorprendentemente difícil. A primera vista, parecería que es suficiente con mandar una TPDU (Unidad de Datos del Protocolo de Transporte) con la petición de conexión y esperar a que el otro acepte la conexión. El problema viene cuando la red puede perder, almacenar, o duplicar paquetes. El principal problema es la existencia de duplicados retrasados. Esto puede solucionarse de varias maneras (ninguna es muy satisfactoria). Una es utilizar direcciones de transporte desechables. En este enfoque cada vez que necesitemos una dirección la creamos. Al liberarse la conexión descartamos la dirección y no se vuelve a utilizar. O también asignar una secuencia dentro de los datos transmitidos, pero estos plantean el problema de que si se pierde la conexión perdemos el orden del identificador y ya no funciona. La solución seria más fácil si los paquetes viejos se eliminaran de la subred cada cierto tiempo de vida. Para ello podemos utilizar las siguientes técnicas: Un diseño de subred Restringido. Colocar un contador de saltos en cada paquete. Marcar el tiempo de cada paquete. Pero en la práctica no vale solo con hacer esto sino que tenemos que garantizar que todas las confirmaciones de los paquetes también se eliminan.

Liberación de una conexión

La liberación de una conexión es más fácil que su establecimiento. No obstante, hay más escollos de los que uno podría imaginar. Hay dos estilos de terminación de una conexión: liberación asimétrica y liberación simétrica. La liberación asimétrica es la manera en que funciona el mecanismo telefónico: cuando una parte cuelga, se interrumpe la conexión. La liberación simétrica trata la conexión como dos conexiones unidireccionales distintas, y requiere que cada una se libere por separado. La liberación asimétrica es abrupta y puede resultar en la perdida de datos. Por lo que es obvio que se requiere un protocolo de liberación más refinado para evitar la perdida de datos. Una posibilidad es usar la liberación simétrica, en la que cada dirección se libera independientemente de la otra. Aquí, un host puede continuar recibiendo datos aun tras haber enviado una TPDU de desconexión.

La liberación simétrica es ideal cuando un proceso tiene una cantidad fija de datos por enviar y sabe con certidumbre cuándo los ha enviado. En otras situaciones, la determinación de si se ha efectuado o no todo el trabajo y se debe terminarse o no la conexión no es tan obvia. Podríamos pensar en un protocolo en el que el host 1 diga:”Ya termine, ¿Terminaste también?”. Si el host 2 responde “Ya termine también. Adiós”, la conexión puede liberarse con seguridad.

Pero no es tan fiable por el problema de que siempre tendremos que esperar la confirmación de los mensajes recibidos y si esta confirmación no llega no libera la conexión y después puede que necesite la confirmación de que llego la confirmación y entraríamos en un bucle del que no podemos salir.

Podemos hacer que al host 1 si no le llega la confirmación después de N intentos (es que quiere la desconexión), se libere. Esto produce una conexión semiabierta en la que el host 1 está desconectado pero el host 2 no como no le llega la confirmación no se desconecta nunca. Para solucionar esto creamos una regla por la cual si al host 2 no le llega ninguna TPDU durante cierta cantidad de segundos, se libera automáticamente.

Control de Flujo y almacenamiento en buffer

Respecto de la manera en que se manejan las conexiones mientras están en uso, uno de los aspectos clave es el control de flujo. Se necesita un esquema para evitar que un emisor rápido desborde a un receptor lento. La diferencia principal es que un enrutador por lo regular tiene relativamente pocas líneas, y un host puede tener numerosas conexiones. Esta diferencia hace poco práctico emplear la implementación que se hace en la capa de enlace.

En esta capa lo que se hace es que si el servicio de red no es confiable, el emisor debe almacenar en un buffer todas las TPDUs enviadas, igual que en la capa enlace de datos. Sin embargo, con un servicio de red confiable son posibles otros arreglos. En particular, si el emisor sabe que el receptor siempre tiene espacio de buffer, no necesita tener copias de las TPDUs que envía. Sin embargo, si el receptor no garantiza que se aceptará cada TPDU que llegue, el emisor tendrá que usar buffers de todas maneras. En el último caso, el emisor no puede confiar en la confirmación de recepción de la capa red porque esto sólo significa que ha llegado la TPDU, no que ha sido aceptada.

Los Buffers pueden ser de tres tipos, y usaremos cada uno de ellos cuando más nos convenga. El equilibrio óptimo entre el almacenamiento del buffer en el origen y en el destino depende del tipo de tráfico transportado por la conexión. Multiplexión

La multiplexión de varias conversaciones en conexiones, circuitos virtuales o enlaces físicos desempeña un papel importante en diferentes capas de la arquitectura de red. En la capa de transporte puede surgir la necesidad de multiplexión por varias razones. Por ejemplo, si en un host sólo se dispone de una dirección de red, todas las conexiones de transporte de esa maquina tendrán que utilizarla. Cuando llega una TPDU, se necesita algún mecanismo para saber a cuál proceso asignarla. Esta situación se conoce como multiplexión hacia arriba.

La multiplexión también puede ser útil en la capa transporte para la utilización de circuitos virtuales, que dan más ancho de banda cuando se reasigna a cada circuito una tasa máxima de datos. La solución es abrir múltiples conexiones de red y distribuir el tráfico entre ellas. Esto se denomina multiplexión hacia abajo.

Recuperación de caídas

Si los hosts y los enrutadores están sujetos a caídas, la recuperación es fundamental. Si la entidad de transporte está por entero dentro de los hosts, la recuperación de caídas de red y de enrutadores es sencilla. Si la capa de red proporciona servicio de datagramas, las entidades de transporte esperan pérdida de algunas TPDUs todo el tiempo, y saben cómo manejarla. Si la capa de red proporciona servicio orientado a la conexión, entonces la pérdida de un circuito virtual se maneja estableciendo otro nuevo y sondeando la entidad de transporte remota para saber cuales TPDUs ha recibido y cuales no.

Un problema más complicado es la manera de recuperarse de caídas del host. Al reactivarse, sus tablas están en el estado inicial y no sabe con precisión donde estaba.

En un intento por recuperar su estado previo, el servidor podría enviar una TPDU de difusión a todos los demás host, anunciando que se acaba de caer y solicitando a todos sus clientes que le informen el estado de todas la conexiones abiertas.

Protocolos de transporte de internet

Internet tiene dos protocolos principales en la capa de transporte, uno orientado a la conexión y otro no orientado a la conexión. El protocolo no orientado a la conexión es el UDP y el orientado es el TCP.

UDP Artículo principal: UDP

El conjunto de protocolos de Internet soporta un protocolo de transporte no orientado a la conexión UDP (protocolo de datagramas de usuario). Este protocolo proporciona una forma para que las aplicaciones envíen datagramas IP encapsulados sin tener una conexión.

TCP Artículo principal: TCP

TCP (protocolo de control de transmisión) se diseñó específicamente para proporcionar un flujo de bytes confiable de extremo a extremo a través de una interred no confiable. Una interred difiere de una sola red debido a que diversas partes podrían tener diferentes topologías, anchos de banda, retardos, tamaños de paquete… TCP tiene un diseño que se adapta de manera dinámica a las propiedades de la interred y que se sobrepone a muchos tipos de situaciones.

3.3 topologias del comercio electrónico: internet, intranet y extranet

INTRANET

Consiste en una Red Privada de computadores que usan tecnología INTERNET como por ejemplo el navegador que permite consultar las páginas WEB existentes, también utilizando el programa gestor de correo electrónico se pueden comunicar los distintos computadores conectados en la red utilizando para ello los mismos protocolos, y estándares abiertos que permiten que computadores de diferentes tipos y fabricantes puedan comunicarse entre ellos. La Intranet proporciona herramientas competitivas, suficientemente poderosas como para conseguir ahorrar tiempo en el trabajo diario y reducir la gran desventaja que supone el trabajo a distancia por parte de empleados calificados y con conocimientos sobre las operaciones frecuentes y habituales de la Empresa

¿ Para quién es una intranet ? Una Intranet es adecuada para cualquier organización cuyas tareas necesitan la coordinación de múltiples personas y equipos de trabajo. Una Intranet tiene dos fundamentos:

Mejorar la coordinación de las acciones de la organización. Ahorrar costes en las labores de coordinación. Una Intranet es muy adecuada para organizaciones que cuentan con lugares de trabajo dispersos geográficamente y para organizaciones que desarrollan tareas que requieren alta cualificación (gestión del conocimiento).

EXTRANET

Una extranet es una red de ordenadores interconectada que utiliza los estándares de Internet. El acceso a esa red está restringido a un determinado grupo de empresas y organizaciones independientes que necesitan trabajar de manera coordinada para ahorrar tiempo y dinero en sus relaciones de negocio.

¿ Para quién es una extranet ?

Una extranet es adecuada para aquellas empresas cuyas cadenas de valor (value chain) son interdependientes, tienen necesidad de comunicarse datos confidenciales entre ellas y el utilizar la tecnología de Internet supone un importante ahorro de tiempo y dinero.

¿ Como funciona una extranet ?

Una extranet funciona como Internet, es decir, ambas utilizan los mismos estándares tecnológicos. La seguridad en el diseño de la extranet es fundamental para asegurar:

Que los datos confidenciales sigan siendo confidenciales pese a viajar por la red.

Que sólo las personas autorizadas tengan acceso a la información que se comunican las distintas empresas participantes en la Extranet.

TOPOLOGÍAS DE UNA RED.

Anillo

Es una de las tres principales topologías de red. Las estaciones están unidas una con otra formando un círculo por medio de un cable común. Las señales circulan en un solo sentido alrededor del círculo, regenerándose en cada nodo. Una variación del anillo que se utiliza principalmente en redes de fibra como FDDI es el doble anillo.

Estrella.

Es otra de las tres principales topologías. La red se une en un único punto, normalmente con control centralizado, como un concentrador de cableado.

Bus.

Es la tercera de las topologías principales. Las estaciones están conectadas por un único segmento de cable. A diferencia del anillo, el bus es pasivo, no se produce regeneración de las señales en cada nodo.

Árbol.

Esta estructura de red se utiliza en aplicaciones de televisión por cable, sobre la cual podrían basarse las futuras estructuras de redes que alcancen los hogares. También se ha utilizado en aplicaciones de redes locales analógicas de banda ancha.

Trama

Esta estructura de red es típica de las WAN, pero también se puede utilizar en algunas aplicaciones de redes locales (LAN). Los nodos están conectados cada uno con todos los demás.

Combinadas.

Cuando se estudia la red desde el punto de vista puramente físico aparecen las topologías combinadas.

Anillo en estrella.

Esta topología se utiliza con el fin de facilitar la administración de la red. Físicamente, la red es una estrella centralizada en un concentrador, mientras que a nivel lógico, la red es un anillo.

Bus en estrella.

El fin es igual a la topología anterior. En este caso la red es un bus que se cablea físicamente como una estrella por medio de concentradores.

Estrella jerárquica.

Esta estructura de cableado se utiliza en la mayor parte de las redes locales actuales, por medio de concentradores dispuestos en cascada para formar una red jerárquica.

SISTEMAS DE CABLEADO ESTRUCTURADO

Constituye el nivel de infraestructura básica de una red; de su buen diseño y correcta instalación dependerá en gran medida el rendimiento de la misma.

De entre las distintas alternativas, tanto cableadas como inalámbricas, se seleccionará aquella que mejor se adapte a sus necesidades reales, sin olvidar posibles ampliaciones y demandas futuras.

Tipología

Par Trenzado (UTP, STP, FTP, ...) Fibra Optica: Conectorización y reflectometrías. Coaxial: Thin/Thick Ethernet, Conectores BNC, Transceptores Vampiro, ... Serie: Para aplicaciones de comunicación RS232 y RS422. IBM Tipo 1 Token Ring Data Connector

3.4 lenguajes de marcación

La generalización de los lenguajes de marcas Artículos principales: Generalized Markup Language y SGML. La iniciativa que sentaría las bases de los actuales lenguajes, partiría de la empresa IBM, que buscaba nuevas soluciones para mantener grandes cantidades de documentos. El trabajo fue encomendado a Charles F. Goldfarb, que junto con Edward Mosher y Raymond Lorie, diseñó el Generalized Markup Language o GML (nótese que también son las iniciales de sus creadores). Este lenguaje heredó del proyecto GenCode la idea de que la presentación debe separarse del contenido. El marcado, por tanto, se centra en definir la estructura del texto y no su presentación visual.

El lenguaje GML fue un gran éxito y pronto se extendió a otros ámbitos, siendo adoptado por el gobierno de Estados Unidos, con lo que surgió la necesidad de estandarizarlo. En los primeros años 1980 se constituyó un comité dirigido por Goldfarb. Sharon Adler, Anders Berglund, y James D. Mason fueron también miembros de dicho comité. Se incorporaron ideas de diferentes fuentes, y participó gran cantidad de gente. Tras un largo proceso, en 1986 la Organización Internacional para la Estandarización publicaría el Standard Generalized Markup Languaje con rango de Estándar Internacional con el código ISO 8879.4

El SGML especifica la sintaxis para la inclusión de marcas en los textos, así como la sintaxis del documento que especifica qué etiquetas están permitidas y donde: el Document Type Definition o schema. Esto permitía que un autor emplease cualquier marca que quisiera, eligiendo nombres para las etiquetas que tuvieran sentido tanto por el tema del documento como por el idioma. Así, el SGML es, estrictamente hablando, un metalenguaje, del que se derivan varios lenguajes especializados. Desde finales de los 80 han aparecido nuevos lenguajes basados en SGML, como por ejemplo el TEI o el DocBook.

El SGML tuvo una gran aceptación y hoy día se emplea en campos en los que se requiere documentación a gran escala. A pesar de ello, resultó farragoso y difícil de aprender, como consecuencia de la ambición de los objetivos previstos. Su gran potencia era a la vez una ventaja y una desventaja. Por ejemplo, ciertas etiquetas podían tener sólo principio, o sólo final, o incluso ser obviadas, pensando en que los textos serían redactados a mano y que así se ahorrarían pulsaciones de teclas. Sin embargo fue un punto clave en el desarrollo de los lenguajes de marcas actuales, ya que la gran mayoría derivan de este.

La popularización Del HTML

En 1991, parecía que los editores WYSIWYG (que almacenan los documentos en formatos binarios propietarios) abarcarían casi la totalidad del procesamiento de textos, relegando al SGML a usos profesionales o industriales muy específicos. Sin embargo, la situación cambió drásticamente cuando Sir Tim Berners-Lee, que había aprendido SGML de su compañero en el CERN Anders Berglund, utilizó la sintaxis SGML para crear el HTML.

Este lenguaje era similar a cualquier otro creado a partir del SGML, sin embargo resultó extraordinariamente sencillo, tanto que el DTD no se desarrolló hasta más tarde. DeRose5 argumenta que la flexibilidad y escalabilidad del marcado HTML fue uno de los principales factores, junto con el empleo de URLs y la distribución libre de navegadores, del éxito de la World Wide Web.

El HTML es hoy día el tipo de documento más empleado en el mundo. Su sencillez era tal que cualquier persona podía escribir documentos en este formato, sin apenas necesidad de conocimientos de informática. Esta fue una de las razones de su éxito, pero también condujo a un cierto caos. El crecimiento exponencial de la web en los años 90 produjo documentos en cantidades ingentes pero mal estructurados, problema agravado aún más por la falta de respeto por los estándares, por parte de diseñadores web y fabricantes de software.

La madurez del XML

Ejemplo de código XML. La respuesta a los problemas surgidos en torno al HTML vino de la mano del XML (eXtensible Markup Language). El XML es un meta-lenguaje que permite crear etiquetas adaptadas a las necesidades (de ahí lo de "extensible"). El estándar define cómo pueden ser esas etiquetas y qué se puede hacer con ellas. Es además especialmente estricto en cuanto a lo que está permitido y lo que no, todo documento debe cumplir dos condiciones: ser válido y estar bien formado.

El XML fue desarrollado por el World Wide Web Consortium,6 mediante un comité creado y dirigido por Jon Bosak. El objetivo principal era simplificar7 el SGML para adaptarlo a un campo muy preciso: documentos en internet.

El nuevo lenguaje se extendió con rapidez, ya que todo documento XML es a su vez SGML. Los programas y documentos creados para y con SGML podían convertirse casi automáticamente al nuevo lenguaje. El XML simplificó radicalmente la complejidad del SGML, facilitando el aprendizaje y la implementación del nuevo estándar. Se solucionaron además viejos problemas, como los surgidos de la internacionalización, y la imposibilidad de validar un documento sin schema. El acierto fundamental de este lenguaje en que logra un equilibrio entre simplicidad y flexibilidad.

El XML fue ideado en principio para entornos semi-estructurados, como textos y publicaciones. Uno de los ejemplos más claros es el XHTML, la redefinición del HTML en clave XML, con las ventajas que ello supone. Sin embargo pronto se observó que sus virtudes podían ser útiles en campos bien distintos. Los lenguajes basados en XML tienen aplicaciones incontables, como en la transacción de datos entre servidores, intercambio de información financiera, fórmulas y reacciones químicas, y un largo etcétera.

Tendencias

Las nuevas tendencias están abandonando los documentos con estructura en árbol. Los textos de la literatura antigua suelen tener estructura de prosa o de poesía: versículos, párrafos, etc. Los documentos de referencia suelen organizarse en libros, capítulos, versos y líneas. A menudo se entremezclan unos con otros, por lo que la estructura en árbol no se ajusta a sus necesidades. Los nuevos sistemas de modelado superan estos inconvenientes, como el MECS, diseñado para la obra de Wittgenstein, o las TEI Guidelines, LMNL, y CLIX.

La Iniciativa de codificación de textos o Text Encoding Initiative (TEI) ha publicado multitud de guías8 para la codificación de documentos de interés en humanidades y ciencias sociales, desarrollados durante años de trabajo colaborativo internacional. Estas directrices se han empleado en innumerables proyectos de catalogación de documentos históricos, trabajos académicos, etc.

La web semántica

Los lenguajes de marcado son la herramienta fundamental en el diseño de la web semántica, aquella que no solo permite acceder a la información, sino que además define su significado, de forma que sea más fácil su procesamiento automático y se pueda reutilizar para distintas aplicaciones.9 Esto se consigue añadiendo datos adicionales a los documentos, por medio de dos lenguajes expresamente creados: el RDF (Resource descriptión framework-Plataforma de descripción de recursos) y OWL (Web Ontology Language-Lenguaje de ontologías para la web), ambos basados en XML.

Texto plano

Una de las principales ventajas de este tipo de codificación es que puede ser interpretada directamente, dado que son archivos de texto plano. Esto es una ventaja evidente respecto al los sistemas de archivos binarios, que requieren siempre de un programa intermediario para trabajar con ellos. Un documento escrito con lenguajes de marcado puede ser editado por un usuario con un sencillo editor de textos, sin perjuicio de que se puedan utilizar programas más sofisticados que faciliten el trabajo.

Al tratarse solamente de texto, los documentos son independientes de la plataforma, sistema operativo o programa con el que fueron creados. Esta fue una de las premisas de los creadores de GML en lo años 70, para no añadir restricciones innecesarias al intercambio de información. Es una de las razones fundamentales de la gran aceptación que han tenido en el pasado y del excelente futuro que se les augura.

Compacidad
Las instrucciones de marcado se entremezclan con el propio contenido en un único archivo o flujo de datos. Este es un ejemplo en diferentes lenguajes de marcas:
Ejemplos HTML Título

Título

Título

Título

Lista

• Punto 1
• Punto 2
• Punto 3

\begin{itemize}
\item Punto 1
\item Punto 2
\item Punto 3
\end{itemize}
* Punto 1
* Punto 2
* Punto 3
texto en negrita texto
texto en cursiva texto

El código entre corchetes con < u l >, o con códigos \section, son instrucciones de marcado, también llamados etiquetas. Estas etiquetas en concreto son descriptivas de la estructura del documento, pudiendo ser su presentación visual de varias maneras. La etiqueta i (de italics, cursiva), por el contrario, especifica que el texto se debe mostrar en cursiva, sin especificar el motivo de esta diferenciación: es una etiqueta presentacional. El texto entre estas instrucciones es el propio contenido del documento.

Facilidad de procesamiento

Las organizaciones de estándares han venido desarrollando lenguajes especializados para los tipos de documentos de comunidades o industrias concretas. Uno de los primeros fue el CALS, utilizado por las fuerzas armadas de EE.UU. para sus manuales técnicos. Otras industrias con necesidad de gran cantidad de documentación, como las de aeronáutica, telecomunicaciones, automoción o hardware, ha elaborado lenguajes adaptados a sus necesidades. Esto ha conducido a que sus manuales se editen únicamente en versión electrónica, y después se obtenga a partir de ésta las versiones impresas, en línea o en CD. Un ejemplo notable fue el caso de Sun Microsystems, empresa que optó por escribir la documentación de sus productos en SGML, ahorrando costes considerables. El responsable de aquella decisión fue Jon Bosak, que más tarde fundaría el comité del XML.

Flexibilidad

Aunque originalmente los lenguajes de marcas se idearon para documentos de texto, se han empezado a utilizar en áreas como gráficos vectoriales, servicios web, sindicación web o interfaces de usuario. Estas nuevas aplicaciones aprovechan la sencillez y potencia del lenguaje XML. Esto ha permitido que se pueda combinar varios lenguajes de marcas diferentes en un único archivo, como en el caso de XHTML+SMILy de XHTML+MathML+SVG.10

3.5 intercambio electrónico de datos

El intercambio electrónico de datos es la transmisión estructurada de datos entre organizaciones por medios electrónicos. Se usa para transferir documentos electrónicos o datos de negocios de un sistema computacional a otro. El intercambio electrónico de datos puede realizarse en distintos formatos: EDIFACT, XML, ANSI ASC X12, TXT, etc.

EDIFACT es un estándar de la Organización de las Naciones Unidas para el intercambio de documentos comerciales en el ámbito mundial. Existiendo subestándares para cada entorno de negocio (distribución, automoción, transporte, aduanero, etc) o para cada país. Así, por ejemplo, AECOC regula el estándar EDI del sector de distribución. Para el intercambio de este tipo de información se suelen utilizar las redes de valor añadido. Además del intercambio de la información, estas redes permiten su registro.

EDI son las siglas de Electronic Data Interchange, intercambio electrónico de datos. El sistema EDI permite el intercambio (envío y recepción) de documentos comerciales por vía telemática.

Albaranes, facturas, órdenes de compra y otros documentos comerciales electrónicos pueden tramitarse directamente desde el ordenador de la empresa emisora al de la empresa receptora, con gran ahorro de tiempo y evitando muchos errores, propios de la comunicación tradicional «en papel».

3.6 dinero electrónico

El dinero electrónico (también conocido como e-money, efectivo electrónico, moneda electrónica, dinero digital, efectivo digital o moneda digital) se refiere a dinero que se intercambia sólo de forma electrónica. Típicamente, esto requiere la utilización de una red de ordenadores, Internet y sistemas de valores digitalmente almacenados. Las transferencias electrónicas de fondos (EFT) y los depósitos directos son ejemplos de dinero electrónico. Asimismo, es un término colectivo para criptografía financiera y tecnologías que los permitan.

Si bien el dinero electrónico ha sido un interesante problema de criptografía -véase por ejemplo el trabajo de David Chaum y Markus Jakobsson-, hasta la fecha, el uso de dinero en efectivo digital se ha efectuado relativamente a baja escala. Uno de los pocos éxitos ha sido sistema de tarjeta Octopus en Hong Kong, que comenzó como un sistema de pago de tránsito masivo y se ha utilizado ampliamente como un sistema de dinero electrónico. Singapur también ha implementado un sistema de dinero electrónico para su sistema de transporte público (tren, autobús, etc), que es muy similar al de Hong Kong y la tarjeta Octopus basada en el mismo tipo de tarjeta (FeliCa). Otra aplicación exitosa se encuentra en los Países Bajos, conocida como Chipknip.

Sistemas alternativos

Técnicamente, el dinero electrónico o digital es una representación, o un sistema de débitos y créditos, destinado (pero no limitado a esto) al intercambio de valores en el marco de un sistema, o como un sistema independiente, pudiendo ser en línea o no. El término dinero electrónico también se utiliza para referirse al proveedor del mismo. Una divisa privada puede utilizar el oro para ofrecer una mayor seguridad, como la divisa de oro digital. Un sistema de divisas digital puede ser plenamente respaldado por el oro (como e-gold y c-gold), no respaldados en oro, o de ambos sistemas (como e-Bullion y Liberty Reserve). Además, algunas organizaciones privadas, como las Fuerzas Armadas de los Estados Unidos usan divisas privadas como el Eagle Cash.

Muchos de los sistemas electrónicos venden sus divisas directamente al usuario final, tales como Paypal y WebMoney, pero otros sistemas, tales como e-gold, venden sólo a través de terceros como las casas de cambio de moneda digital.

En el caso de la tarjeta Octopus en Hong Kong, se trabaja de manera similar a los depósitos bancarios. Después que tarjeta Octopus Limited recibe dinero en depósito de los usuarios, el dinero se deposita en bancos, lo cual es similar al método de las tarjetas de débito donde los bancos emisores redepositan el dinero a los bancos centrales.

Algunas divisas locales, como los sistemas de cambio local, trabajan con transacciones electrónicas. El Cyclos Software permite la creación electrónica de divisas locales. El sistema Ripple es un proyecto para desarrollar un sistema de distribución de dinero electrónico independiente de la moneda local.

Dinero electrónico anónimo fuera de línea

Con el dinero electrónico anónimo fuera de línea (off-line) el comerciante no tiene que interactuar con el banco antes de aceptar dinero por parte del usuario. En lugar de eso puede recoger múltiples monedas gastadas por los usuarios y depositarlas posteriormente en el banco. En principio esto se puede hacer fuera de línea, es decir, el comerciante podría ir al banco con su medios de almacenamiento para intercambiar el efectivo electrónico por dinero en efectivo. No obstante, el comerciante debe asegurarse que el dinero electrónico del usuario, o bien será aceptado por el banco, o el banco será capaz de identificar y castigar a los usuarios que traten de engañar por esta vía. De esta forma, un usuario no tiene posibilidad de utilizar la misma moneda dos veces (doble gasto). Los sistemas de efectivo electrónico off-line también tienen la necesidad de protegerse contra los posibles engaños de los comerciantes, es decir, los comerciantes que deseen depositar una moneda dos veces (y luego culpar al usuario).

En criptografía el efectivo electrónico anónimo fue presentado por David Chaum. Solía hacer uso de firma digital ciega para lograr hacer imposible relacionar entre el retiro y transacciones de gastos.1 En criptografía, efectivo electrónico por lo general se refiere a dinero electrónico anónimo. Dependiendo de las propiedades de las operaciones de pago, se distingue entre efectivo electrónico en línea y fuera de línea (off-line). El primer sistema de efectivo electrónico fuera de línea fue propuesto por Chaum y Naor.2 Al igual que el primer sistema en línea, se basa en firma digital ciega RSA.

Evolución futura
Los ejes principales de desarrollo del efectivo digital son:

La posibilidad de usarlo a través de una gama más amplia de hardware tal como tarjetas de crédito garantizadas, Que las cuentas bancarias vinculadas, en general, se utilicen en un medio de Internet, para el intercambio con micropagos seguros como en el sistema de las grandes corporaciones (PayPal).

Para el fomento de la evolución de la red en términos de la utilización de efectivo digital, una empresa llamada DigiCash está en el centro de atención con la creación de un sistema de efectivo electrónico que permite a los emisores vender moneda electrónica a algún valor. Cuando se adquieren vienen a nombre del comprador y se almacenan en su computadora o en su identidad en línea. En todo momento, el dinero electrónico se vincula a la empresa de efectivo electrónico, y todas las transacciones se realizan a través de esta, por lo que la compañía de efectivo electrónico asegura todo lo que se compra. Sólo la compañía tiene la información del comprador y dirige la compra a su ubicación.

Desarrollos teóricos en el ámbito de la descentralización del tradicional dinero centralizado están en marcha. Los sistemas de contabilidad que están apareciendo, tales como Altruistic Economics, son totalmente electrónicos, y puede ser más eficaces y más realistas por no asumir un modelo de transacción de Suma cero .