INSTITUTO TECNOLOGICO DE PARRAL

MATERIA: INGENIERIA WEB 1

ACTIVIDAD: TEMA 6

FECHA: 28/NOVIEMBRE/2015

NOMBRE DEL ALUMNO: VICTOR ANTONIO OCHOA PEÑA

TECNOLOGÍAS PARA APLICACIONES WEB

La elección de tecnologías apropiadas es un importante factor de éxito en el desarrollo de aplicaciones web. Tenemos que conocer las características de las tecnologías para poder utilizarlas de manera significativa. Además de conocer las tecnologías pertinentes, la implementación de aplicaciones Web a menudo requiere el conocimiento de cómo las diferentes tecnologías interactúan en una arquitectura existente. En este capítulo se ofrece una visión general de las diversas tecnologías y su interrelación y su uso en una arquitectura seleccionado pocos.

6.1 INTRODUCCIÓN

Una vez que hemos definido los requisitos de una aplicación web, elegido una arquitectura, y ha desarrollado un diseño, etc., en fin, una vez que hemos aclarado el "qué", estamos listos para iniciar la fase de ejecución, es decir, el "cómo”. En este contexto, la reutilización juega un papel cada vez más importante en el proceso de desarrollo. Los requisitos resultantes para la implementación de aplicaciones Web comienzan con la elección de tecnologías apropiadas. Los requisitos para el principio clave se describe en el capítulo 5, es decir, la separación de contenido y presentación, es un requisito fundamental para utilizar adecuadamente las tecnologías. Además, debemos tener en cuenta los requisitos para la distribución y la integración de otros sistemas de acuerdo con una arquitectura seleccionada o existente.

Los detalles de las tecnologías de implementación de aplicaciones web frente a sistemas de software "convencionales" se derivan de la utilización de estándares Web. Esto se refiere en particular la aplicación dentro de los tres puntos de vista: Solicitud (cliente), respuesta (servidor), y las reglas para la comunicación entre estos dos (protocolo). Este capítulo está organizado a lo largo de las líneas de estos "puntos de vista", es decir, clientes y tecnologías de servidor.

Debido a la rápida evolución de las tecnologías basadas en la web que es imposible describir completamente todas las tecnologías.

Por esta razón, en este capítulo se limitará a la introducción de unas pocas tecnologías específicas como una opción fundamental. En primer lugar, vamos a introducir unos protocolos de uso común en la web, haciendo hincapié en el protocolo más importante para la World Wide Web - Protocolo de transferencia de hipertexto (HTTP). A continuación, presentaremos tecnologías de cliente seleccionados. La sección sobre estándares de documentos representa una "zona gris" entre el cliente y el servidor. La razón es que la mayoría de los navegadores web populares actuales pueden procesar tecnologías XML, por ejemplo, XSLT. En consecuencia, la asignación de esta tecnología ya sea al grupo de clientes o el grupo de servidores es esencialmente pre-determinado

por inherente del sistema requisitos previos, por ejemplo, si un navegador soporta XSLT, o si la transformación se lleva a cabo en el lado del servidor. Por último, vamos a introducir tecnologías de servidor seleccionado y arquitecturas.

6.2 FUNDAMENTOS

Generalmente, todos los paradigmas de programación, aspectos de distribución, tecnologías de autoría, etc., se pueden utilizar como una base para la implementación de una aplicación Web. Esto representa uno de los problemas que han llevado al desarrollo caótico de las aplicaciones Web. Tales desarrollos sobre todo el resultado de enfoques ad-hoc o un cambio rápido en la tecnología. Por esta razón, esta sección se centra en las raíces, es decir, de marcado y hypertext.After todo, marcado, en la encarnación específica de SGML, constituye la base para HTML y XML, mientras que el hipertexto describe el concepto básico de la World Wide Web.

6.2.1 MARCADO

El concepto de margen de beneficio se origina en la industria editorial y, en general indica que las instrucciones tipográficas para el formato del documento. Estas instrucciones se especifican dentro de un documento en forma de caracteres adicionales. Por ejemplo, podríamos escribir * * Hola a la salida de Hola o / Hola / Hola a la salida. Marcado semántico nos permite escribir comentarios en texto sin mostrarlos en el documento. ISO define las siguientes clases de marcas:

1. Marcado: Este es el texto insertado en un documento para agregar información en cuanto a cómo los personajes y contenidos deben estar representados en el documento.

2. Marcado descriptivo: Este es marcado que describe la estructura y otros atributos de un documento, independientemente de cómo se procesa este documento para la representación (por ejemplo, comentarios).

3. Instrucciones de proceso: Se trata de marcas que consiste en datos específicos del sistema; controla la forma en que un documento se procesa.

SGML significa Standard Generalized Markup Language; su desarrollo en esencia ha sido promovido por las editoriales estadounidenses. Al usar SGML los autores utilizan etiquetas (<tag>) partes Tomark específica de texto, que han sido previamente definidas usando SGML (en una llamada Document Type Definition, DTD). En consecuencia, SGML también sirve como punto de partida para una serie de marcas especializadas, particularmente HTML y XML (véase también la sección 6.5.4).

6.2.2 HIPERTEXTO E HIPERMEDIA

Basado en el uso de marcadores para marcar elementos individuales, hipertexto se entiende como la organización de la interconexión de unidades de información individuales. Las relaciones entre estas unidades pueden ser expresadas por enlaces. El concepto de hipertexto (véase el capítulo 1) es la base conceptual básico de la World Wide Web. Mientras hipertexto meramente designa la conexión de unidades de información en su versión de texto, hipermedia es vista comúnmente como una manera de extender el principio de hipertexto a objetos multimedia arbitrarios, por ejemplo, imágenes o vídeo.

6.3 Cliente Comunicación / servidor en la Web

El paradigma cliente / servidor que subyace a todas las aplicaciones web constituye la columna vertebral entre un usuario (cliente o usuario del agente) y la aplicación real (servidor). Este modelo de comunicación se basa principalmente en una arquitectura de 2 capas. Sin embargo, los pasos de procesamiento en un servidor (web) pueden requerir la integración de otros sistemas, por ejemplo, bases de datos, servidores de aplicaciones, etc. Las arquitecturas de N-capas (ver Capítulo 4) formado de esta manera todavía se basan principalmente en el modelo cliente / servidor . Por ejemplo, un navegador Web envía una solicitud, y esta solicitud desencadena una respuesta de un servidor Web, mientras que los protocolos, principalmente el protocolo de transferencia de hipertexto (HTTP), juegan un papel central. Estos protocolos controlan la forma en que el cliente debe hacer una solicitud, que responde un servidor puede devolver, y cómo debe hacerlo.

6.3.1 SMTP - SIMPLE MAIL TRANSFER PROTOCOL

SMTP (Simple Mail Transfer Protocolo Postel 1982), combinado con POP3 (Post Office Protocol) o IMAP (Internet Message Access Protocol Crispin 2003) nos permite enviar y recibir correos electrónicos. Además, SMTP se utiliza cada vez más como un protocolo de transporte para el intercambio de mensajes asíncrono basado en JABÓN (ver sección 6.6.2).

6.3.2 RTSP - REAL TIME STREAMING PROTOCOL

El Real Time Streaming Protocol (RTSP Schulzrinne et al., 1998) representa un estándar publicado por la Internet Engineering Task Force (IETF), y está diseñado para apoyar la entrega de datos multimedia en condiciones de tiempo real. En contraste con HTTP, RTSP permite la transmisión de recursos para el cliente en un contexto oportuna en lugar de la entrega de ellos en su totalidad (a la vez).

Esta forma de transmisión es comúnmente llamada streaming. Streaming nos permite cambiar manualmente la "ventana de tiempo" audiovisual mediante la solicitud de la corriente en un momento determinado, es decir, nos permite controlar la reproducción de medios continuos. Por ejemplo, podemos

implementar funciones de la gente está familiarizada con la de los dispositivos de alta fidelidad, por ejemplo, "pausa", "avance rápido", o "rebobinar la reproducción", o la posición de la reproducción para un futuro o punto del tiempo pasado.

6.3.3 HYPERTEXT TRANSFER PROTOCOL - HTTP

El Protocolo de transferencia de hipertexto (Berners-Lee 1996), o, HTTPfor corto, se ha convertido cada vez más importante durante los últimos años. La gran proliferación de estándares web y la capacidad de expansión de la Web han ayudado HTTP para convertirse en el protocolo de transporte más popular para Web contenido. HTTP es un protocolo sin estado basado en texto, el control de cómo, por ejemplo, se accede a documentos HTML o imágenes recursos. HTTP se basa en la pila TCP / IP, donde el servicio se ofrece normalmente a través del puerto 80. Los recursos son abordados por el uso del concepto de un Uniform Resource Identifier (URI). URI no están obligados a protocolos especiales, como HTTP; que representan más bien un mecanismo de direccionamiento uniforme, que también se utiliza en HTTP. Un URI asigna identificadores únicos a los recursos, independientemente de su tipo (documentos HTML, imágenes, etc.). Probablemente, el representante más destacado de la URI es la URL (Uniform Resource Locator). URLs pueden ser utilizados en conexión con el sistema de nombres de dominio (DNS) para identificar a los ejércitos en la que se encuentran dichos recursos. Un URI, por ejemplo, (http://www.unikarlsruhe.de/Uni/index.html), por lo general describe tres cosas: cómo se accede a un recurso, por ejemplo, (http: //) si se utiliza HTTP; el equipo de destino (host), donde se encuentra el recurso, por ejemplo, (www.uni-karlsruhe.de); y el nombre de ese recurso, por ejemplo, Uni / index.html. Entre otras cosas, los URI también definir un delimitador de consulta, "¿?", Que permite HTTP para transmitir parámetros. La sintaxis completa de URIs fue estandarizado por el IETF en el RFC 1630.

El mecanismo de entrega de HTTP difiere del método utilizado normalmente en los sistemas orientados a objetos distribuidos. Mientras que el valor de una llamada de función, por ejemplo mediante el uso de RPC, se entrega una sola vez la función ha sido completamente procesado, una solicitud HTTP conduce a un flujo de datos, que se evalúa inmediatamente, incluso si no todos los datos han sido totalmente entregado. Este método tiene la ventaja de que las páginas Web se pueden interpretar inmediatamente, lo que significa que se rindió y se muestran más rápido. Sin embargo, la entrega inmediata por un servidor Web y el procesamiento inmediato por un cliente Web también puede causar la ejecución de un programa dentro de una página HTML (también llamado de scripting del lado del cliente) para ser culpable si su posición dentro del flujo de datos se produce en un mal momento (Powell et al. 1998). HTTP fue estandarizado por el IETF en el RFC 1945 y actualmente está disponible en la versión 1.1.

6.3.4 SEGUIMIENTO DE SESIÓN

Aplicaciones web interactivas deben ser capaces de distinguir las peticiones de múltiples usuarios simultáneos e identificar solicitudes relacionadas procedentes del mismo usuario.

El término sesión se utiliza para definir una secuencia de este tipo de peticiones HTTP relacionadas entre un usuario específico y un servidor dentro de una ventana de tiempo específico. Desde HTTP es un protocolo sin estado, el servidor Web no puede asignar automáticamente las solicitudes entrantes a una sesión. Dos métodos principales se pueden distinguir, para permitir que un servidor Web para asignar automáticamente una solicitud entrante a una sesión:

• En cada una de sus peticiones a un servidor, el cliente se identifica con una identificación única.

Esto significa que todos los datos enviados al servidor se asignan a la respectiva sesión.

• Todos los datos intercambiados entre un cliente y un servidor se incluyen en cada solicitud de un cliente envía a un servidor, de modo que la lógica de servidor se puede desarrollar a pesar de que la comunicación es sin estado.

En la mayoría de los casos es conveniente dejar los datos de lógica de aplicación en el servidor de forma que la lógica de la aplicación no tiene que ser apátrida. Un mecanismo de seguimiento de la sesión tiene que ser utilizado para asignar una solicitud de una sesión. Seguimiento de sesión se lleva a cabo normalmente por la reescritura de URL o cookies.

REESCRITURA DE URL

Reescritura de URL es un mecanismo que transmite los datos a la sesión pertinente como parámetros en una URL. Los datos transmitidos pueden entonces ser usados para reconstruir la sesión en el servidor. Desafortunadamente, este mecanismo tiene varias desventajas:

• Si se requiere un gran volumen de datos dentro de una sesión, el URL puede convertirse fácilmente en desordenado y propenso a errores. Dado que las aplicaciones Web tienden a ser complejos, los requisitos para el volumen de datos a ser almacenados en una sesión también pueden aumentar.

• Limitar la longitud de una URL puede causar este mecanismo quede inutilizable en ciertos sistemas.

• El principal inconveniente, sin embargo, es que las direcciones URL codificadas en las páginas HTML tienen que ser adaptados de forma dinámica para cada sesión, por ejemplo, para codificar una sesión en un identificador de

sesión dentro de la URL. Esto significa que las páginas o enlaces dentro de la aplicación tienen que ser generado de forma dinámica para cada solicitud. Podemos utilizar cookies para resolver elegantemente este problema.

GALLETAS

Las cookies son pequeños archivos de texto que se utilizan para almacenar información del servidor (por ejemplo, un identificador de sesión) en el equipo cliente. Esta información se escribe en un archivo de texto en forma de pares nombre-valor. Las cookies son generados por los servidores web y se transmiten a los clientes en la cabecera de la respuesta HTTP. Navegador Web del cliente almacena una cookie en el equipo cliente y entonces utilice siempre esta cookie para transmitirla al servidor que genera la cookie con cada solicitud. Las cookies son típicamente clasificados como "sesión" o cookies "permanentes". Mientras cookies permanentes permanecen en el equipo cliente (almacenado en el disco duro), cookies de sesión única se mantienen hasta que el sitio se deja o el navegador cerrado. Esto significa que el servidor puede identificar peticiones de un cliente específico y asignarlos a una sesión. Las cookies también pueden incluir fechas de vencimiento; una vez al día como expire el navegador del cliente dejará de enviar la cookie al servidor.

El mayor beneficio de las cookies es que la información que identifica una sesión puede ser intercambiada de forma transparente entre un cliente y un servidor. Ellos se pueden utilizar para implementar fácilmente el seguimiento de sesión, y no requieren gran esfuerzo, ya que sólo un identificador de sesión generada por el servidor tiene que ser transmitido.

El principal inconveniente de las cookies es que algunos usuarios desactivar la funcionalidad de cookies en sus navegadores para prevenir su comportamiento de navegación de ser capturados.

ESCENARIOS DE USO

¿Cuál de los dos mecanismos mencionados anteriormente es el más adecuado para las aplicaciones web depende en gran medida de las circunstancias. Lo ideal es que queremos dejar la información de sesión en el servidor y se limita a utilizar un ID de sesión seguro. Este método también se puede combinar, por ejemplo, el uso de cookies para almacenar un identificador de sesión, y el uso de la reescritura de URL para los navegadores que no aceptan cookies. Codificación típico ejemplos de identificadores de sesión en las URL son: (http: //host/application/page.ext SessionId = XYZ) o (http: //host/application/XYZ/page.ext), donde XYZ representa una clave única para el sesión; esta clave debe ser difícil de adivinar.

Tecnologías de servidor actuales como PHP, JSP o ASP.NET generalmente apoyan API para utilizar los mecanismos descritos anteriormente. Estas API

ocultan el manejo de la complejidad de sesiones, facilitan la generación de identificadores de sesión, y ofrecen métodos específicos para almacenar información de la sesión.

6.4 TECNOLOGÍAS DEL LADO DEL CLIENTE

6.4.1 AYUDANTES Y PLUGINS

Programas de ayuda de las aplicaciones que pueden agregar funcionalidad a los navegadores web. Tan pronto como un navegador recibe un tipo de medio incluido en su ayudante o lista de plug-in, este tipo de papel es enviado al programa externo especificado en la lista para su posterior procesamiento. Ejemplos de aplicaciones de ayuda incluyen WinZip o Acrobat Reader. Un programa de ayuda tiene que ser instalado por el usuario en su ordenador cliente. El programa de ayuda se invoca luego por su asignación al tipo MIME correspondiente. Cualquier programa básicamente puede llegar a ser un ayudante. Un inconveniente importante de ayudantes es su complejo de comunicación con el navegador. Plug-ins pueden resolver este problema. Un plug-in es un programa de ayuda de instalación permanente en el navegador para la comunicación optimizada.

6.4.2 APPLETS DE JAVA

Applets Java son programas escritos en Java que se cargan dinámicamente en el navegador. Se ejecutan en un denominado "sandbox", lo que les impide acceder directamente a los recursos del sistema en el cliente, o les permite acceder a los recursos sólo después de comprobar las políticas de seguridad. Los applets son cargados por un servidor web y se ejecutan en un navegador dentro de un entorno de ejecución de Java llamado Virtual Machine (JVM) (Lindholm y Yellin 1999). Applets no se almacenan persistentemente en un sistema. A diferencia de los controles ActiveX, applets se compilan en independiente del sistema de código de bytes, lo que les permite funcionar en todas las plataformas con una JVM.

6.4.3 CONTROLES ACTIVEX

Con controles ActiveX, Microsoft ha permitido el uso de su tecnología de componente COM en los navegadores web (Denning 1997). Los controles ActiveX son componentes COM estándar diseñados para proporcionar un cierto conjunto de interfaces (interfaces COM). Un navegador Web puede cargar un componente de un servidor Web, crear instancias de ella a través del sistema de ejecución de COM, y luego utilizar la funcionalidad de dicho componente. En contraste con los applets de Java, controles ActiveX se compilan en código binario, que proporciona un excelente rendimiento. Controles ActiveX se almacenan en el directorio de caché especial del navegador. Esto significa que para invocaciones posteriores la funcionalidad es

fácilmente disponible. Además, un control ActiveX tiene las mismas posibilidades que un plug-in o ayudante; se puede acceder a todas las áreas del sistema y funciones del usuario que posee el contexto de seguridad que se ejecuta en. Este es un riesgo de seguridad. Por lo tanto, Microsoft ha desarrollado un método que permite vendedores de Control ActiveX para utilizar un método de cifrado para firmar estos componentes. Cuando un control ActiveX se carga en un navegador, el certificado del proveedor ActiveX se puede mostrar. Un usuario puede decidir si él o ella está de acuerdo para ejecutar el programa, es decir, si él o ella confía en la empresa de fabricación. Anotherbenefit de Controles ActiveX es que los componentes se pueden desarrollar en un lenguaje arbitrario, incluyendo Java, Visual Basic y C ++, siempre y cuando el compilador del lenguaje cumple con las especificaciones COM requeridos.

6.5-DOCUMENTO ESPECÍFICO DE TECNOLOGÍAS

6.5.1 HTML - HYPERTEXT MARKUP LANGUAGE

El Hypertext Markup Language (HTML) es una aplicación SGML, que describe los elementos que se pueden utilizar para marcar contenidos en un documento hipertexto y cómo estos elementos se interrelacionan (en un tipo de documento (DTD); véase también la sección 6.5.4). Marcado está encerrado en "<" y ">" símbolos. HTML define un gran número de etiquetas para indicar diferentes semánticas. Por ejemplo, la etiqueta <H1> se puede utilizar para marcar un encabezado de nivel 1. Etiquetas sirven para estructurar lógicamente un documento. Por ejemplo, el elemento marcado <strong> significa que la parte de documentos entre este par etiqueta debe ser interpretado como un énfasis lógico, que los navegadores normalmente muestra en negrita. Debido a las limitadas posibilidades de diseño gráfico, elementos adicionales se habían introducido muy pronto para permitir a los diseñadores de influir directamente en el diseño de un documento. Por ejemplo, el elemento de marcado <b> puede ser utilizado para instruir a los navegadores para representar una parte del documento en negrita. Sin embargo, la semántica de marcado se pierde. Debido a la gran cantidad de posibilidades de influir en el diseño, no es una sorpresa que la mayoría de los recursos HTML descuidar el uso de elementos de marcado lógicas / semánticas. Esto hace que sea mucho más difícil para las máquinas para interpretar la información (véase el Capítulo 14). La situación es aún más crítica porque la información de lo contrario podría convertirse fácilmente en otros formatos, por ejemplo, para que sean utilizables en dispositivos como los teléfonos móviles. La simplicidad en la creación y procesamiento de recursos HTML (ya que son simples archivos de texto) es una propiedad muy importante para omnipresente personaje de información de la Web, pero es impedido por el uso común más o menos dominado por el aspecto presentación. La introducción de nuevos elementos de marcado había facilitado sobre todo por el hecho de que los navegadores rechazan o ignoran

elementos de marcado que no conocen. Esta flexibilidad se utilizó en varias ocasiones por los fabricantes de navegadores para ampliar las opciones de diseño, que finalmente condujeron a muchos nuevos estándares, pero también a las representaciones "incompatible" (Powell et al. (1998), Sano 1996).

Estos problemas alentaron a la introducción de un gran número de extensiones. Por ejemplo, hojas de estilo en cascada (CSS) representan un mecanismo simple para agregar información de estilo, como fuentes, colores, etc., a los documentos Web. Junto con la introducción de XHTML, un dialecto XML, se hizo posible usar los beneficios de XML como un lenguaje "limpia" para describir los documentos HTML.

Una descripción detallada del lenguaje HTML se encuentra en la literatura que se hace referencia al final de este libro.

6.5.2 SVG - SCALABLE VECTOR GRAPHICS

El SVG (W3C 2001a) formato de imagen significa Scalable Vector Graphics y permite describir gráficos bidimensionales en XML. SVG reconoce tres tipos de objetos gráficos: gráficos vectoriales que consisten en líneas rectas y curvas, imágenes y texto. Los objetos gráficos se pueden agrupar e integrar en otros objetos.

SVG soporta la interacción basada en eventos, por ejemplo, las respuestas a los botones o los movimientos del ratón. Por ejemplo, una respuesta de este tipo podría ser la ampliación de una imagen. Además, es posible definir un cursor especial para la interactividad del usuario. SVG es compatible con todo tipo de animaciones, que ofrece un gran número de funciones, incluyendo uno para mover un objeto gráfico a lo largo de un camino predefinido.

Gracias a estas propiedades especiales, este formato es adecuado para todo tipo de gráficos vectoriales interactivos y animados. Ejemplos de aplicación incluyen la representación de CAD, mapas y rutas.

6.5.3 SMIL - SMIL

SMIL (2001a W3C) es la abreviatura de Smil; que fue desarrollado por el W3C para representar presentaciones multimedia sincronizadas. SMIL permite la coordinación de la presentación de los diferentes medios de comunicación, tales como audio, vídeo, texto e imágenes. Por ejemplo, SMIL nos permite definir exactamente cuando una sentencia se debe hablar, y que la imagen o el texto debe aparecer en paralelo. Cada medio puede abordarse directamente, y podemos especificar un lugar y la hora para la representación.

Las horas de inicio y fin de cada medio se pueden sincronizar con relativa facilidad a los de otros medios de comunicación. Funciones de control estándar permiten al usuario interactuar con SMIL. Es posible detener, pausar, adelantar

o rebobinar toda la presentación. Las funciones adicionales incluyen generadores aleatorios, cámara lenta, y lapso de tiempo. Durante la presentación, el usuario puede seleccionar enlaces incrustados para navegar a otras páginas web. En su versión actual 2.0, SMIL incluye, entre otras cosas, las funciones para la animación, presentación controlada de contenidos, la vinculación, la integración de los diferentes medios de comunicación, el calendario y la sincronización, las manipulaciones de tiempo y efectos de transición.

6.5.4 XML - EXTENSIBLE MARKUP LANGUAGE

Extensible Markup Language (XML) es un dialecto extremadamente simple de SGML [. . .]. El objetivo es permitir que el SGML genérico para ser servido, recibido y procesado en la web de la manera que ahora es posible con HTML. Por esta razón, XML ha sido diseñado para facilitar la implementación y la interoperabilidad con SGML y HTML (Borrador de Trabajo del W3C, noviembre de 1996).

Sobre la base de la recomendación del W3C, XML (extensible Markup Language (W3C 1998)) ha experimentado un progreso verdaderamente triunfal con respecto a su uso y la proliferación dentro y fuera de la Web. Con su capacidad para definir los formatos de datos flexibles en las formas más sencillas e intercambiar estos formatos en la Web, XML ofrece el requisito previo para homogeneizar entornos heterogéneos. Esto significa que, además de describir formatos de datos uniformes, también podemos considerar la semántica de estos datos, independientemente de la información (véase también el Capítulo 14). Sus Capacidades de extensión se derivan del hecho de que, en contraste con HTML, XML no dicte marcado pre-definido con la semántica implícita. Más bien nos permite flexibilidad definir el significado de la semántica y la estructura de un XMLdocument, de modo que pueda adaptarse a las circunstancias dadas.

Esta es la razón por XML, en lugar de ser una alternativa a HTML, se abre completamente nuevas maneras de describir datos para fines arbitrarios.

Documentos XML se caracterizan por dos propiedades distintas: buena formación y validez.

Mientras que la buena formación está anclada inherentemente en XML, la validez puede ser asegurada por el tipo de documento (DTD) y esquemas XML. Este último será discutido en otras secciones. Para asegurarse de que está bien formado un documento XML, hay reglas generales para la sintaxis de documentos XML, que - en contraste con HTML - deben respetarse escrupulosamente. De hecho, la especificación XML hace referencia a estas normas como "restricciones". Tabla 6-1 utiliza ejemplos para demostrar la XML reglas de formación.

Dado que estas reglas tienen que ser estrictamente observados, es posible determinar con claridad la estructura de los documentos XML. Esto condujo a la definición del modelo de objetos de documento (DOM), que puede ser utilizado para transformar la estructura de tipo árbol de documentos XML en un árbol orientado a objetos. La Figura 6-1 muestra una orden de compra como un simple ejemplo de documento XML. Vamos a utilizar este ejemplo como nuestra base para otros ejemplos en las siguientes secciones.

LOS ESPACIOS DE NOMBRES

Los espacios de nombres (1999a W3C) son algunas de las características básicas de manejo de XML. Los espacios de nombres pueden utilizarse para evitar colisiones de nombres con elementos igualmente con nombre en un documento XML. Esto permite que los documentos de las diferentes estructuras que se fusionen.

Hay dos maneras diferentes para marcar un elemento XML con espacios de nombres: uno puede cualquiera de los Estados del espacio de nombres de un elemento o utilizar un prefijo. El método prefijo es útil sobre todo cuando varios elementos pertenecen al mismo espacio de nombres, ya que hace que los documentos XML más corto y fácil de leer. Figura 6-2 utiliza nuestro ejemplo anterior para ilustrar las dos variantes. El URI (uri: orden) se dirige a un espacio de nombres que se corresponde con una orden de compra.

DOM XML

El Document Object Model (DOM) presenta una visión orientada a objetos en documentos XML, lo que permite el procesamiento fácil e intuitivo de XML. Un

DOM se crea un analizador XML, que analiza la estructura de un documento XML y crea instancias de un árbol de objetos (Figura 6-3).

Cada elemento XML en este árbol corresponde a un nodo. La ventaja de este método es para acceder a los nodos de una manera orientada a objetos, una vez que el DOM ha sido creado. El inconveniente es que este enfoque es bastante costoso, ya que se necesita un analizador XML para crear primero el árbol. Por ejemplo, muchas veces querremos acaba de leer partes de un documento XML en lugar de todo el documento. En estos casos, se recomienda utilizar los analizadores que son menos consumo de recursos, por ejemplo, SAX (Simple API para XML) analizadores. Analizadores SAX utilizan un modelo basado en eventos, que apoya la intervención específica en el proceso de análisis, ya que un método para cada evento que ocurre puede ser registrado en el programa de llamada. De manera similar a los analizadores compatibles con DOM, SAX analizadores están disponibles para las plataformas más comunes y lenguajes de programación.

LA RESTRICCIÓN DE VALIDEZ XML

Mientras que la restricción de la buena formación definida en la especificación XML asegura una sintaxis clara para documentos XML, validez nos permite introducir una estructura definida específicamente para un documento XML. Un documento XML es válido cuando está bien formado, y cuando su contenido y estructura son compatibles con las reglas predefinidas. Estas reglas se formulan ya sea en Document Type Definitions (DTD) o esquemas XML. En cuanto a la orientación a objetos, esto significa que bien que para medness nos permite mapear XML DOM, mientras validez nos permite introducir los tipos de datos específicos de la aplicación (logrando así variabilidad).

DTD (DOCUMENT TYPE DEFINITION).

Una DTD representa un conjunto de reglas que se pueden utilizar para describir la estructura de un documento XML.

XML toma prestado DTD de SGML. Figura 6-4 muestra un DTD que valida el ejemplo XML "orden de compra". El DOCTYPE!,! ELEMENT, y fragmentos ATTLIST! Describen el tipo de datos. La forma más elementos están vinculados recuerda fuertemente a la definición de las expresiones regulares. La regla <! ELEMENT fin (artículo +, FechaPedido, precio)> expresa que un elemento de pedido consiste en menos un elemento de material ("+"), seguido de un OrderDate y un precio.

Gracias a su estructura simple, DTD son relativamente fáciles para los seres humanos entiendan. Es por eso que son útiles sobre todo cuando tienen que ser creado o mantenido de forma manual. Sin embargo, precisamente por su estructura simple, DTD causan dos problemas distintos, que son finalmente resueltos por esquemas XML:

• El hecho de que las DTD se han tomado de SGML a menudo se considera un problema, ya que requiere un analizador DTD para leer la gramática. Sería mejor que anotar también la propia gramática de XML, de manera que los analizadores XML existentes podrían leerlo. Nuestro ejemplo muestra que una DTD no es XML bien formado.

• Aunque algunos tipos de datos se pueden utilizar para definir los elementos o atributos dentro de DTDs, su alcance es muy limitado. Esta restricción afecta la reutilización de las DTD.

ESQUEMAS XML

Esquemas XML (W3C 2.000) están diseñados para responder a los problemas introducidos por DTD. Sin embargo, sus ventajas principales, es decir, la integración de tipo de datos, la reutilización, y la formulación XML, llegaron a costa de una complejidad creciente. El resultado es que, en el desarrollo de esquemas, se ha convertido casi inevitable de utilizar herramientas. Debido a su complejidad, esta sección analiza los esquemas sólo brevemente para delinear sus propiedades y conceptos más importantes.

Un esquema XML puede ser usado para describir varios tipos de datos predefinidos, tales como cuerdas, byte, decimal o fecha. Además, dejan que se definen las facetas que soportan los tipos de datos definidos por el usuario similar a las plantillas. Supongamos, por ejemplo, que todos los atributos válidos ISBN del libro elemento XML en el ejemplo "orden de compra" deben seguir la notación para números ISBN. Podríamos utilizar una faceta para describir los números combinados y rayas con el patrón de N \ NNNN \ -nnnn \ -N y volver a utilizar este tipo de datos en proyectos de desarrollo futuros.

Hay dos conceptos distintos para derivar los tipos de datos de esquema de los tipos existentes: ampliación y restricción. En el sentido de la herencia orientada a objetos, restricción correspondería a una especialización de la gama de valores del supertipo, mientras que la extensión sería similar a una agregación de otros tipos. Figura 6-5 (lado izquierdo) muestra cómo se crea el tipo LTH ("menos de 100") mediante la restricción de la (pre-definido) tipo positiveInteger y el establecimiento de un límite superior para el valor alcance. En el lado de la derecha en esta figura, el tipo OrderType definido por el usuario se extiende a datedOrderType, lo que añade un elemento, orderDate, de la fecha de tipo (predefinido) a un OrderType.

6.5.5 XSL - EXTENSIBLE STYLESHEET LANGUAGE

XSL significa extensible Stylesheet Language (1999a W3C) y consta de tres partes: Transformaciones XSL, XPath, y XSL-FO. XSL incluye una norma para transformar y formato XML.

XSLT es un lenguaje para definir las pautas y normas para su transformación, lo que representa el núcleo de XSL. Mientras XSL-FO se utiliza para definir claramente un estilo de formato, representa sólo una de todos los posibles resultados de la transformación de XSLT. Por esta razón, XSL se puede comparar con el patrón de diseño Model-View-Controller como una categorización general. El modelo corresponde a documentos XML, y el controlador se corresponde con XSLT. Las vistas creadas pueden ser de naturaleza arbitraria, es decir, HTML, WML, CHTML o nuevo XML. Una vista pre-definido en el XSL Suite puede ser pensado como un XSL-FO (Formateo de Object).

XSLT - EXTENSIBLE STYLESHEET LANGUAGE TRANSFORMATIONS

El estándar Extensible Stylesheet Language Transformations describe cómo / contenidos en XML se pueden transformar los datos marcados en marcha. Documentos que definen un programa de XSLT son también llamadas hojas de estilo. El lenguaje XSLT define es un dialecto XML. Esto significa que XSLT hereda todas las propiedades XML, incluyendo la buena formación y validez. XSLT se describe en el espacio de nombres (http://www.w3.org/1999/XSL/Transform) definido por el W3C, que garantiza la validez de una hoja de estilo XSLT. El resultado de una transformación XSL no está ligado a estructuras o restricciones específicas o dictados. Esto significa que el resultado de una transformación XSL cubre todo el espectro que va desde markup estructurada como XML a cadenas de caracteres arbitraria interpretables. Un procesador XSLT funciona por el principio IPO (entrada, procesamiento, salida). Los datos XML son la entrada, mientras que la hoja de estilo XSLT maneja el trabajo de procesamiento para generar la salida.

Figura 6-6 muestra cómo funciona un procesador XSLT.

La funcionalidad de una transformación XSLT se basa en un principio de "coincidencia de patrones". Una hoja de estilo representa un conjunto de pares de patrones de resultados, similares a las reglas de asignación de un sistema semi-Thue (patrón → resultado). Un procesador busca en la entrada (documentos originales) de los patrones, que se definen en la hoja de estilo (patrón), y los reemplaza por el resultado que coincide con este patrón en los documentos de salida (resultado). Podemos pensar en un resultado como una plantilla que representa una mezcla de productos y otros elementos del lenguaje XSL.

Comparándolos con los lenguajes de programación convencionales como Java, C o C #, también podemos pensar en los patrones como los procedimientos y de las plantillas como sus cuerpos. La sustitución patrón resultante inicia un proceso recursivo en el DOM de la entrada XML. De manera similar a los procedimientos, los patrones también se pueden parametrizar, el apoyo a los contextos dentro de una entrada XML. El XML Path Language (XPath) se utiliza para encontrar patrones. Mientras XSLT representa una colección de patrones, XPath controla cómo están conectados al documento XML de entrada. Los elementos del lenguaje XSLT se pueden agrupar en cuatro categorías distintas:

• Elementos de definición (D): Estos elementos del lenguaje se utilizan para definir una hoja de estilo XSL (xsl: stylesheet), un patrón (xsl: template), las variables, parámetros, etc.

• Elementos de flujo de control (C): Estos elementos del lenguaje se utilizan para manipular el flujo de control dentro de una plantilla de XSLT. Por ejemplo, podemos formular iteraciones (xsl: foreach) o instrucciones condicionales (xsl: if) o iteraciones.

• Elementos del lenguaje orientados a la producción (O): Estos elementos sirven para generar la salida de un patrón de XSLT. Por ejemplo, podríamos generar elementos de marcado (xsl: elementos y xsl: atributo) o sólo texto libre.

• Elementos relacionados con la ubicación (L): Estos elementos se utilizan para el multilingüismo, por ejemplo, las definiciones locales y formatos (xsl: decimal-formato).

Figura 6-7 define una hoja de estilo XSLT, que puede transformar la "orden de compra" ejemplo XML de la Figura 6-1. Navegadores con procesadores integrados XSL, por ejemplo, las versiones actuales de Internet Explorer y Netscape Navigator, pueden representar el ejemplo "orden de compra" con la hoja de estilo especificado en HTML. Nótese que tenemos que añadir una instrucción de procesador para el ejemplo XML para especificar la ubicación de la hoja de estilo (vea la Figura 6-8).

XPATH

El lenguaje XML Path (XPath) introduce la funcionalidad para atravesar un documento XML. XPath ofrece una gran cantidad de expresiones que permiten la definición de rutas de búsqueda, los cuales pueden ser operados en un documento XML para devolver conjuntos de nodos XML. Expresiones XPath son evaluados por un procesador XPath, que funciona de manera similar al concepto de directorios en los sistemas de archivos. Por ejemplo, hijos de elementos XML pueden ser vistos como entradas en un directorio del sistema de archivos. Figura 6-9 muestra la conexión entre un documento XML y su interpretación como un directorio del sistema de archivos para entender mejor el concepto. En el lado de la mano izquierda, la figura muestra cómo se utiliza una expresión XPath global, mientras que el lado derecho muestra cómo se utiliza una expresión local. Los nodos en soportes rizados representan los resultados de estas expresiones.

Similar a los caminos en un sistema de archivos, podemos definir expresiones XPath, que describe el camino a través de un documento XML. Y como en un sistema de archivos, distinguimos entre direccionamiento relativo y absoluto. XPath ofrece una gran cantidad de diferentes patrones de resultados en XML. Por ejemplo, podríamos utilizar atributos, además de elementos XML. Por otra parte, XPath nos permite acceso "ejes", por ejemplo, descendientes y ascendientes. Esto significa que podemos formular expresiones arbitrariamente

complejas, que luego puede ser usado para atravesar documentos XML sobre la base de la DOM.

XSL-FO - EXTENSIBLE STYLESHEET LENGUAJE DE FORMATO OBJETOS

XSL-FO significa extensible Stylesheet Lenguaje de Formato objetos y representa una definición de los objetos específicos de los medios de comunicación para diversas representaciones finales. XSL-FO no está vinculado exclusivamente a los medios visuales, tales como pantallas, impresoras, o documentos. De hecho, la norma permite la inclusión de representaciones de audio, por ejemplo, salida de voz. Propiedades importantes de estos "objetos formateados" incluyen la paginación, propiedades de diseño (por ejemplo, tipo de letra), o la estructuración de los objetos con respecto a su orientación y márgenes (XSL-FO Area Model). XSL-FO se describe en el espacio de nombres (http://www.w3.org/1999/XSL/Format).

En consecuencia, esta norma constituye el puente entre los contenidos definidos en XMLand medios de comunicación independiente de su producción dependiente de la plataforma, por ejemplo, un Pdf Documento. Figura 6-10 utiliza dos procesamiento pasos para mostrar cómo funciona esto. En primer lugar, un procesador XSLT utiliza una hoja de estilo XSLT para procesar los contenidos definidos en XML. El resultado de esta etapa de procesamiento representa una instancia de un objeto formateado como se define en la especificación XSL-FO. Posteriormente, un formateador utiliza recursos de formato, como imágenes y fuentes, para crear la salida específica de los medios de comunicación. Los medios de producción utilizados en este ejemplo son un documento PDF, una impresora y una pantalla.

RESUMEN

XSL representa una herramienta poderosa para transformar XML. La parte lenguaje XSLT incluye una gran cantidad de transformaciones, que puede crear salidas dedicadas. Desde XSLT actualiza inherentemente cambios porque separa los datos / contenido de su representación (transformación), las circunstancias para el uso de XSLT son similares a las que conducen a la selección de una arquitectura (Capítulo 4).

En entornos altamente dinámicos, la pérdida de rendimiento que implica el uso de XSLT en el servidor será atendido por arriba-hasta la fecha representaciones (transformación) y el apoyo de diferentes hojas de estilo para diferentes plataformas (WML, cHTML, etc.). Para crear la presentación de marcas como el HTML, el costo de rendimiento adicional causada por la transformación puede ser compensada mediante la integración de procesadores XSLT en los navegadores Web, o mediante el almacenamiento en caché dedicada en el servidor. Por ejemplo, las versiones actuales de los navegadores Internet Explorer y Navigator de Netscape han procesadores XSLT construida en Las propiedades más importantes de XSL son, en resumen.

• Apoyo a las diferentes representaciones (transformaciones), como HTML, WML, etc., sin tener que cambiar los datos / contenidos. XSLT es útil en la preparación para la evolución de las aplicaciones Web, en particular gracias a su capacidad de transformar datos en formatos que surgirán en el futuro.

• Capacidades para la presentación de datos dedicado para diferentes grupos de usuarios, por ejemplo, la discapacidad visual o ciegos (por medio de la salida de voz).

6.6 TECNOLOGÍAS DEL LADO DEL SERVIDOR

6.6.1 URI MANEJADORES

Manejadores de URI son aplicaciones especiales que se utilizan para procesar las peticiones HTTP y para entregar un recurso solicitado. Más específicamente, un URI se utiliza para identificar la instancia que procesa una solicitud. Esta instancia - el manejador especializado URI - toma la solicitud y la envía para su ejecución. El resultado de esta ejecución se devuelve a continuación al servidor Web, que, a su vez, envía el recurso al agente de usuario solicitante.

SERVER SIDE INCLUDES (SSI)

Una inclusión del servidor (SSI) representa un mecanismo sencillo que permite la creación de páginas HTML, compuesto de varios fragmentos de texto, sobre la marcha. Este mecanismo se implementa por un pre-procesador para páginas HTML, que normalmente está integrada en servidores web modernos. Una página HTML que utiliza SSI se remite a la pre-procesador cuando un navegador Web solicita. Las salidas del pre-procesador se envía entonces por el servidor. El servidor generalmente identifica este tipo de páginas de una extensión de archivo especial (normalmente html).

Los comandos que se utilizan para controlar el pre-procesador están incrustados en los comentarios SGML y tienen la siguiente forma: <! - # Comando atributo = valor... atributo = valor ->

El valor del comando especifica el tipo de comando, que está parametrizada por una lista de atributos-valor. SSI es compatible con los siguientes comandos:

• incluyen: Este comando se sustituye por el contenido de un archivo, se especifica ya sea por una ruta de archivo o una URL (por medio de un archivo o atributo virtual).

• exec: Este es un programa con su ruta de archivo especificada por el atributo cmd. Se ejecuta y su salida reemplaza el comando. Extensiones de SSI (por ejemplo, XSSI) incluyen comandos adicionales para la salida de texto condicional o para definir y variables de salida.

Aunque SSI no se usa mucho más, la tecnología ha contribuido mucho al progreso de nuevos enfoques o controladores modernos URI. La mayoría de los controladores modernos URI reemplazan SSI con los conceptos más poderosos. Sin embargo, SSI puede ser utilizado de manera significativa para las páginas que se encuentran principalmente estática, o páginas que ofrecen ayudas para la navegación o las notas legales.

CGI / FASTCGI

El Common Gateway Interface (CGI) es una interfaz estandarizada entre los servidores Web y los programas de aplicación que transmita información en una petición HTTP a un programa de aplicación. El programa de aplicación está dirigido al señalar un URL en la etiqueta de formulario en la página HTML que llama.

El programa lee los parámetros de la solicitud, las procesa y genera una salida, normalmente documentos HTML. Cualquier lenguaje de programación disponibles en la plataforma de servidor se puede utilizar; lenguas típicas incluyen Perl, C, C ++ o Python. Un inconveniente importante de la tecnología CGI es su escalabilidad limitada, ya que un proceso independiente tiene que ser iniciado para cada petición entrante.

Esto puede causar una tensión considerable sobre los recursos, especialmente cuando muchas solicitudes simultáneas tienen que ser procesados. Esta situación condujo a la introducción de FastCGI, un estándar que permite a los programas de aplicación para servir varias peticiones en paralelo.

SECUENCIAS DE COMANDOS DEL LADO DEL SERVIDOR

Esta sección presenta las páginas Active Server (ASP), una solución ofrecida por Microsoft, como un ejemplo representativo de todo un grupo de enfoques que se pueden resumir bajo el lema "scripting del lado del servidor". Otros representantes de esta categoría son PHP, ColdFusion y Server-Side JavaScript introducido por Netscape como parte de su programa de LiveWire. Todo URI manejadores mencionados aquí definen un lenguaje de script. Los comandos de estos lenguajes de script están incrustados en los recursos HTML y ejecutados por un intérprete de secuencia de comandos en el servidor antes de la entrega de los recursos.

ASP es una tecnología ofrecida junto con el servidor Web de Microsoft, el Internet Information Server (IIS). Similar a SSI, se añaden instrucciones especiales para un pre-procesador para las páginas HTML, que se procesan por que el pre-procesador antes de ser entregados. Una vez más, las páginas del guión se almacenan en archivos con la extensión de archivo especial (.asp). En consecuencia, estamos hablando de un apoyo a la ejecución con la generación dinámica de recursos, pero su costo de procesamiento se reduce algo en que un recurso, una vez que se ha creado en el servidor, se mantiene en una memoria caché y puede ser recuperada a partir de ese caché si se solicita de nuevo más tarde.

Si bien las instrucciones de ISQ permiten insertar contenido de los archivos o programas de salida, pero no ofrecen ninguna forma de intervenir en el flujo de control del pre-procesador, métodos de scripting del lado del servidor permiten la ejecución de código de programa incrustado en HTML, llamados guiones que

están inscritos en un lenguaje de programación interpretado. En analogía con SSI, por lo tanto, hablamos de scripting del lado del servidor.

En contraste con otros entornos de secuencias de comandos, ASP se caracteriza por el hecho de que no se limita a un lenguaje de script único. Prácticamente Podríamos instalar muchos intérpretes diferentes y utilizarlas al lado del otro. Incluso es posible insertar bloques de código escritas en diferentes lenguajes de script en una página HTML simple.

SERVLETS

Servlets representan una mejora de la tecnología CGI en el entorno Java. Exactamente igual que los programas CGI, los servlets son invocados por los URLs especiales para procesar las solicitudes entrantes y luego generar páginas HTML de respuesta sobre la marcha. Los servlets se ejecutan en un entorno especial en tiempo de ejecución (el llamado contenedor de servlets), que está totalmente integrado en el servidor Web.

Una ventaja importante de servlets frente CGI es su capacidad multi-threading. Los servlets pueden procesar muchas solicitudes simultáneamente en diferentes hilos dentro del entorno de tiempo de ejecución. Además, ofrecen una extensa API para aplicaciones web del programa y un gran número de características integradas, en particular los mecanismos de seguridad de Java. Por otra parte, los servlets ofrecen una manera elegante de la sesión seguimiento por el uso de cookies y el objeto HttpSession para acceder a los datos de sesión.

JAVA SERVER PAGES

Java Server Pages (JSP) están diseñados para simplificar la programación de páginas HTML gráficamente sofisticados creados sobre la marcha.

Java Server Pages extienden páginas HTML convencionales con etiquetas especiales JSP, lo que permite la integración de código de programa de Java para crear contenidos dinámicos. A su invocación inicial, el entorno de ejecución se traduce JSP en servlets, y luego crear las páginas HTML de respuesta correspondiente.

ASP.NET

ASP.NET representa la próxima generación de páginas Active Server de Microsoft. La nueva tecnología de componentes, la Asamblea y el Common Language Runtime correspondiente (CLR) forman la columna vertebral de toda una gama de nuevas tecnologías.

Por ejemplo, ASP.NET permite generar páginas de controles de servidor a código separado de contenidos, lo que simplifica el diseño de páginas dinámicas. Además, el marco .NET ofrece soporte dedicado para la

implementación y uso de servicios Web. ASP.NET ofrece beneficios considerables para el desarrollo de aplicaciones Web distribuidas modernos y aplicaciones basadas en Servicios Web, ya que utiliza un lenguaje de programación construye para el apoyo implícito.

6.6.2 SERVICIOS WEB

Desde la aparición de los Web Services y la introducción de SOAP, un gran número de mejoras y protocolos han sido publicados. Estos productos están diseñados para cualquiera de las lagunas existentes cercanos o aplicar conceptos mejorados. Esta sección sólo se refiere a la tecnología de la base de Web Services. No discute el gran número de protocolos adicionales, por ejemplo, WS-Security (véase el Capítulo 11), WS-Transacción o WSCI (ver Capítulo 5).

SOAP - SIMPLE OBJECT ACCESS PROTOCOL

El Simple Object Access Protocol (2003a W3C) representa una forma simplemente para intercambiar mensajes sobre la base de XML. Enfoques comparables son, por ejemplo, el Protocolo de Internet Inter-ORB (IIOP) en CORBA (Ben-Natan 1995), Remote Method Invocation de Sun (RMI) en Java (Gosling et al., 1996), o .NET de Microsoft. Para permitir que los servicios Web para comunicarse sin problemas, necesitamos un Protocolo de mensajes de uniforme, que es independiente de la plataforma subyacente. Representa un protocolo tal mensaje basado en XML. Tenga en cuenta que el jabón no pretende resolver todos los problemas; no maneja las cosas como los mensajes que transportan, semántica que hacen referencia, o la recolección de basura distribuida. Como su nombre lo indica, está diseñado para definir un formato de comunicación simple.

Por ejemplo, llamadas a procedimiento remoto (RPC) se pueden implementar y mecanismos sencillos para intercambiar mensajes en sistemas distribuidos pueden formularse. JABÓN generalmente transmite información como datos XML. Información binaria, tales como archivos de imagen, puede añadir MIME (Multipurpose Internet Mail Extensions), de manera similar a BizTalk Server de Microsoft.

Desde SOAP sólo específica qué mensajes debe ser similar, se requieren protocolos adicionales de transporte para enviar y recibir estos mensajes. La norma no define un protocolo de transporte específico. De hecho, cualquier protocolo se puede utilizar, por ejemplo, HTTP, SMTP (Simple Mail Transfer Protocol), o TCP propietaria / protocolos IP-basada. Sin embargo, HTTP es el protocolo utilizado con más frecuencia.

Por ejemplo, SOAP 1.1 define cómo los mensajes especificados en jabón se pueden intercambiar a través de HTTP.

La especificación SOAP consta de tres partes (ver Figura 6-11):

• Sobre SOAP: El sobre especifica qué datos se incluyen en un mensaje (cuerpo SOAP), que los datos pueden ser opcionalmente incluidos (encabezado SOAP), y cómo se debe procesar.

• Reglas de codificación de SOAP: Estas reglas especifican, por ejemplo, cómo deben ser serializados de datos definidos por el usuario.

• Representación SOAP RPC: Si SOAP se utiliza para trabajar por el principio Remote Procedure Call, entonces la representación RPC es responsable de dónde y cómo los mensajes deben ser codificados.

SOAP se ha diseñado para utilizar estas tres partes independientemente uno de otro. El principal beneficio de esta modularidad es que cada parte puede ser reemplazado y adaptarse a las circunstancias especiales.

WSDL - WEB DESCRIPCIÓN DEL SERVICIO DE IDIOMAS

Los consumidores y proveedores de servicio tienen que llegar a un entendimiento común, es decir, necesitan una interfaz común para poder intercambiar mensajes. El Web Service Description Language (WSDL) (2003b W3C) es un lenguaje diseñado para definir dichas interfaces (Interface Definition Language, IDL) para servicios Web. WSDL describe cómo el usuario de un servicio Web debe establecer sus llamadas a funciones. En él se especifica el tipo de mensajes de un servicio Web puede aceptar, que la información (parámetros) tiene que ser incluido en el mensaje, y cómo debería estructurarse. Además, se le dice al usuario cómo se construirá la respuesta esperada a su petición, y como información devuelta debe ser interpretado. WSDL es otro dialecto XML utilizado por los servicios Web (proveedores de servicios) para describir cómo estos servicios utilizan mensajes para comunicarse con sus usuarios (consumidores de servicios). Los servicios Web pueden utilizar uno o varios puertos de comunicación, los cuales intercambian mensajes para manejar las llamadas de función y transmitir documentos.

Una descripción WSDL se compone de elementos básicos y elementos de extensión. Elementos centrales describen un servicio y los puertos, tipos de puertos, y los mensajes que utiliza. Elementos de extensión permiten agregar

construcciones XML arbitrarios, como los tipos de datos definidos por el usuario. En consecuencia, los documentos WSDL representan un contrato que se establecen los métodos y convenciones de llamada de un consumidor de servicios tiene que observar cuando se utiliza ese servicio Web.

La especificación no dicta cómo los elementos básicos deben interactuar, lo que significa que puede ser una cuestión compleja. Básicamente Podemos identificar dos niveles, que están conectados por enlaces de específicos dentro de WSDL. WSDL Versión 1.1 define enlaces para SOAP y HTTP-GET y HTTP POST. Un gran número de entornos de desarrollo disponibles puede crear código de programa ejecutable sobre la base de la descripción WSDL de un servicio Web.

UDDI - UNIVERSAL DESCRIPTION, DISCOVERY Y LA INTEGRACIÓN

UDDI (http://www.uddi.org) es un directorio de servicios web; que ayuda a los clientes (solicitantes de servicios) y servidores (proveedores de servicios) para encontrar uno al otro. UDDI utiliza SOAP para la comunicación. UDDI es a menudo comparado con las páginas amarillas, ya UDDI permite a las empresas ofrecen sus productos y servicios por nombre, producto, ubicación y otros criterios.

6.6.3 TECNOLOGÍAS MIDDLEWARE

SERVIDORES DE APLICACIONES

Los servidores de aplicaciones están estrechamente relacionados con el concepto de una arquitectura de 3 capas. Ellos denotan una plataforma de software utilizado para procesar las transacciones en línea (OLTP). Una arquitectura de 3 capas mueve la lógica de la aplicación desde el cliente al servidor de aplicaciones. El cliente se ejecuta normalmente como una llamada

De Cliente ligero sin ninguna lógica en absoluto. La tercera capa está representada por los sistemas de back-end, por ejemplo, mainframes o

servidores de la empresa. Figura 6-12 muestra cómo las tres capas interactúan.

En este escenario, el servidor de aplicaciones representa un entorno para el desarrollo y el funcionamiento de aplicaciones distribuidas basadas en componentes. Para ello, ofrece una serie de servicios, por ejemplo, transacciones, la puesta en común de recursos, el equilibrio de carga, nombrando, o los servicios de directorio. La mayoría de las especificaciones de apoyo actuales servidores de aplicaciones de Java 2 Enterprise Edition (J2EE), servlets Java, Java Server Pages, Enterprise Java Beans (Thomas 1998), CORBA, etc. servidores de aplicaciones más antiguas, los llamados monitores "procesamiento de transacciones", se pueden programar en C, C ++ o COBOL.

ENTERPRISE JAVA BEANS

Enterprise Java Beans (EJB) representan una arquitectura basada en componentes para desarrollar, independientes de la plataforma, las aplicaciones cliente / servidor distribuidos abiertos en Java. La arquitectura EJB era desarrollada por Sun Microsystems y publicado en una especificación independiente del proveedor. Un Bean Enterprise sea implementa la lógica de aplicación (bean de sesión), o representa datos (bean de entidad). Dependiendo de sus funcionalidades, aplicaciones distribuidas pueden constar de un gran número de EJBs. Beans Enterprise se ejecutan en un entorno de ejecución especial - el contenedor EJB. El contenedor EJB es un servidor de aplicaciones que ofrecen servicios de sistemas integrados, por ejemplo, soporte de transacciones, objeto de persistencia, o jndi (JNDI). Figura 6-13 muestra estos componentes básicos.

Muchas de las propiedades de un Bean Enterprise, por ejemplo, las características, las transacciones o de control de la base de datos, se definen en un archivo de configuración (descriptor de despliegue) cuando se instala en un contenedor EJB.

SISTEMAS DE MENSAJERÍA

Los sistemas de mensajería ofrecen basada en mensajes, la comunicación asíncrona entre sistemas en un entorno distribuido. Los sistemas de origen y destino dentro de este entorno se comunican mediante el intercambio de mensajes. Dependiendo de la carga y la disponibilidad de un sistema de destino, un sistema de origen puede tener que esperar a que un mensaje llegue. Sistemas de mensajería se agrupan en dos tipos de comunicación diferentes: la comunicación de solicitud / respuesta entre exactamente dos máquinas (pares) en el entorno del sistema, y de publicación / suscripción comunicación. En una publicación / suscripción de comunicación, los suscriptores se registran con un servicio de mensajes de temas específicos, y posteriormente recibir mensajes de todos los editores.

6.7 PERSPECTIVAS

Las tecnologías de aplicación que tendrán éxito en la ingeniería Web en el futuro es difícil de predecir. Como la tecnología de núcleo, XML, sin duda, ha iniciado un giro importante con respecto a la homogeneización de entornos heterogéneos. XML ha traído una avalancha de otros estándares basados en XML, que han sido y serán más o menos éxito. Por ejemplo, Web Services se supone que son de gran éxito. Tecnologías como XSL tienen grandes potencialidades en materia de futuros escenarios de uso, ya que debido a XML pueden construir sobre requisitos homogéneos. Sin embargo, la implementación de aplicaciones Web requiere un enfoque disciplinado. Requisitos específicos de las tecnologías de implementación tienen su origen en otras fases de desarrollo, por ejemplo, análisis de requerimientos, diseño, tecnología consciente, o la arquitectura y las exigencias de seguridad. Esto significa que la implementación de aplicaciones web tendrá que seguir una correcta "cómo" después de un pre-determinado "qué".