Generación Dinámica de Contenidos WAP

Sergio Ríos Aguilar (srios@moebius.es)
Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software
Facultad de Informática
Universidad Pontifica de Salamanca en Madrid

Resumen

Tras una presentación de las características más relevantes de la tecnología WAP (Protocolo para Aplicaciones Inalámbricas), y justificando la importancia crucial que en este ámbito cobra la personalización de contenidos ofrecidos, en el presente estudio se analizan los distintos modelos y tecnologías de procesamiento en servidor existentes (CGI, xSAPI, Servlets Java...etc) reflejando el "estado del arte" actual en lo referente a la generación dinámica de contenidos WAP. Además, se hace hincapié en otro importante aspecto de la personalización: la negociación del formato de presentación de los contenidos para su correcta visualización en terminales móviles concretos, presentando para ello una solución avanzada que se basa en la utilización de perfiles CC/CP y la transformación de documentos XML mediante XSL.

1. Introducción a WAP

La especificación WAP (Wireless Application Protocol, Protocolo de Aplicaciones Inalámbricas) define un conjunto de componentes estándar que posibilitan la comunicación entre terminales móviles (teléfonos, asistentes personales, portátiles...etc) y servidores de red.

Los elementos más importantes de esta especificación son [WAPF99a]:

• Un lenguaje de códigos basado en XML para la definición y presentación de contenidos y la interacción del usuario, denominado WML (Wireless Markup Language).
  
• Un lenguaje de scripts complementario, denominado WMLScript, para la realización de actividades de procesamiento en el lado del cliente (agente de usuario WAP).
  
• La especificación de un micronavegador en la que se define cómo se deben interpretar tanto WML como WMLScript en terminal móvil y que, en general, gestiona la interfaz de usuario final del servicio WAP.
  
• Un entorno para aplicaciones de telefonía (WTA, Wireless Telephony Applications framework) que permite a los operadores la integración de funciones de telefonía del propio dispositivo móvil con el micronavegador incorporado.
  
• Una pila de protocolos estándar que hace posible el transporte real de los contenidos, y que está basada en la arquitectura de protocolos existentes en el WWW. Estos protocolos han sido diseñados para operar sobre distintos tipos de servicios portadores de diferentes niveles de calidad de servicio (ancho de banda, latencias, tasas de error..etc)

En cualquier caso, los tipos de contenidos y protocolos de WAP han sido optimizados para su utilización específica en dispositivos móviles de capacidades limitadas:

1. Pantallas de reducido tamaño
2. Conexiones de red con escaso ancho de banda y elevada latencia
3. Recursos de memoria y procesamiento muy limitados
4. Mecanismos limitados de interacción con el usuario.

1.1 Agentes de usuario WAE

El nivel de aplicación de la arquitectura de protocolos de WAP, WAE (Wireless Application Protocol) se considera como la base de un entorno de desarrollo de propósito general para aplicaciones WAP, en el que se combinan tecnologías similares a las usadas en el WWW y tecnologías relacionadas con Telefonía Móvil .

A nivel software, WAE se divide en dos niveles lógicos [WAPF99b]:

• Agentes de usuario, tales como micronavegadores, agendas telefónicas, editores de mensajes...etc
  
• Servicios y Formatos comunes, accesibles a los agentes de usuario, como WML, WMLScript, formatos de imágenes, de calendarios y agendas telefónicas...etc

WAE separa los agentes de usuario de los servicios, y asume la existencia de un entorno con múltiples agentes de usuario, sin que ello suponga ninguna implicación para la implementación. En la mayoría de los casos se suelen combinar todos los servicios en un único agente de usuario (como se supondrá aquí en lo sucesivo), mientras que en otros se puede optar por una política de distribución de servicios entre diferentes agentes de usuario.

1.2 Contenidos

En cuanto a los contenidos que se intercambian en transacciones WAP, el lenguaje WML define una estructura básica llamada carta (card), que representa una interacción con el usuario, y que sintácticamente contiene una primera parte no visible, con contenidos ejecutables, a la que le sigue una segunda parte de elementos visibles.

En este modelo, se define un mazo (deck) como un conjunto de cartas. Precisamente por ser ese conjunto una representación de las sucesivas interacciones con el usuario, un mazo sería el equivalente a un programa o documento WAP, y por ello tiene asociado un único URL (Uniform Resource Locator).

En la práctica, y a efectos de desarrollo, se puede comparar un mazo (deck, o documento WML) con un documento HTML que contiene numerosas secciones identificables sin ambigüedad (de hecho, en WML se usa para ello la sintaxis #etiqueta, lo que recuerda enormemente a las anclas nominales de HTML).

Veamos un ejemplo de la codificación WML de un mazo con dos cartas:

<wml>

<card id="carta1" title="Ejemplo1">
<do type="accept" label="Ir a carta 2">
<go href="#carta2">
</do>
</card>
<card id="carta 2" title="Ejemplo2">
<p>Esta es la segunda carta del mazo</p>
</card>
</wml>

2. Modelo general de operación de WAP/WAE

El modelo típico de operación WAP se basa en el paradigma cliente/servidor multinivel, y tiene como característica distintiva el hecho de que las transacciones suelen utilizar como elemento intermediario un servidor/gateway WAP.

En este escenario (ver Figura 1), cuando el usuario suministra una URL en el cliente (terminal móvil), un agente de usuario WAE usa el protocolo WSP para enviar solicitudes de contenidos y servicios a través de una red inalámbrica, en formato comprimido (y opcionalmente seguro), al gateway.

El gateway convierte dichas solicitudes a formato HTTP (o HTTPS si se utilizan transacciones seguras [RIOS98]) no comprimido y las envía a un servidor de contenidos Web. Este servidor responde, mediante HTTP o HTTPS, enviando un documento u objeto directamente en formato WML, WMLScript, WBMP o bien en formato HTML, en cuyo caso habría que aplicar un filtro de conversión a WML.

Cuando el gateway WAP recibe la respuesta, compila y comprime el objeto WMLScript o WML, respectivamente, en formato binario compacto y la devuelve al agente de usuario.

Dentro del modelo descrito, las funciones del gateway están bastante definidas:

• Pasarela de protocolos: se traducen solicitudes basadas en protocolos WAP (WSP, WTP, WTLS y WDP) a solicitudes de protocolos WWW (HTTP y TCP/IP), realizando el proceso análogo para el transporte de las respuestas al cliente originario de las solicitudes.
  
• Codificación y decodificación de contenidos: Se transforman los contenidos WAP a formatos compactos y codificados para reducir el tamaño de los datos en tránsito por la red celular, así como para minimizar la capacidad de procesamiento necesaria en el cliente para el tratamiento de los datos.

Ésta, aún siendo la configuración más habitual, no es la única. En efecto, existen servidores de contenidos y servicios WTA que no necesitan realizar conversión de protocolos, y son capaces de responder directamente a solicitudes WAP del cliente.

Los servidores WTA permiten ofrecer acceso WAP a determinadas características de la infraestructura de comunicaciones del operador de Red, y para poder implementar los servicios ofrecidos se usan interfaces propietarias de servidor o bien interfaces abiertas y bien documentadas como la API de Servlets Java. Por otra parte, y por completitud, mencionar que en el cliente (terminal móvil), para operaciones locales de control de llamadas (recepción, iniciación y finalización) y de acceso a listines telefónicos, se utiliza la interfaz WTAI (Wireless Telephony Application Interface).

Ejemplo de inicio de llamada de voz mediante WTAI:

<wml>
<card>
<do type="options" label "Llamar">
<go href="wtai://wp/mc;914503300">
</do>
Teléfono de la empresa
</card>
</wml>

3. Técnicas de procesamiento en servidor WWW para generación de contenidos WAP

Como se puede apreciar, el modelo general de operación cliente/servidor de WAP es muy similar al usado en el dominio WWW, y, de hecho, aquél ha sido específicamente diseñado para que sea posible aprovechar la infraestructura tecnológica existente en la Web para el aporte de contenidos.

Obsérvese además que en tanto se accede en última instancia a un servidor Web estándar, los contenidos WAP devueltos pueden ser estáticos (tienen existencia previa en un sistema de archivos local o remoto accesible por el servidor) o generados dinámicamente usando tecnologías de servidor suficientemente probadas en la Web, sin que el cliente WAP pueda establecer distinción alguna sobre el mecanismo de producción de contenidos usado realmente (tal como sucedía en los clientes Web).

En general, nunca se debería confiar en la efectividad de procesos de filtrado y conversión automática de contenidos Web a formato WAP (posibilidad anteriormente mencionada), debido a que estos filtros poco pueden hacer para adaptar al 100% contenidos que no tienen en cuenta –en origen- las características físicas especiales de los terminales móviles que realmente se van a usar como clientes. Significa esto que es siempre preferible aportar contenidos directamente en formato WAP (WML, WMLScript..etc).

Por otra parte, y como uno de los puntos más importantes que contribuirán al éxito de WAP, es preciso entender que se trata de una tecnología en la que el usuario final es un usuario registrado y conocido por el operador de red celular.

Esto es esencial en operaciones de comercio electrónico, máxime si se tiene en cuenta que al propio mecanismo de seguridad de las redes GSM se le añade el ofrecido por los servicios de seguridad de WTLS.

Quiere todo esto significar que en el caso de WAP, cobra más importancia que nunca la necesidad de personalizar los contenidos entregados al cliente, y, por tanto, al usuario final. Por ello, el modelo de desarrollo a utilizar, sin duda alguna, será la entrega de contenidos WAP generados dinámicamente en el servidor Web.

Así pues, es necesario conocer cuáles son las técnicas de procesamiento en servidor disponibles en el dominio Web para su utilización en este nuevo ámbito, y conocer cómo se adaptan al mismo. Además, dado que nos encontramos en un entorno donde las redes inalámbricas introducen tiempos de latencia elevados, el rendimiento del mecanismo de generación dinámica es crítico para no añadir más penalizaciones en el tiempo de descarga.

Por todo lo expuesto, a continuación se ofrece una visión general que refleja el "estado del arte" referido a la totalidad de técnicas de procesamiento en el servidor existentes actualmente, contemplando la problemática de su adaptación a la generación de contenidos WAP, y realizando una comparación final de posibilidades de desarrollo y rendimientos.

Actualmente existen cinco mecanismos que permiten a los Servidores Web ofrecer contenidos dinámicos y procesar consultas de datos casi en tiempo real [RIOS97]:

3.1 Server Side Includes (SSI)

Se trata de un mecanismo que permite integrar comandos especiales en documentos (originalmente HTML), de modo que los contenidos de la página resultante sean diferentes cada vez que un cliente acceda a la misma.

En este caso, el Servidor HTTP debe analizar los documentos antes de entregarlos, para poder así interpretar los posibles comandos SSI e incrustar dinámicamente bloques de datos en el flujo de datos correspondiente al documento finalmente enviado al cliente.

SSI es una técnica de primera generación, por lo que adolece de bastantes inconvenientes, entre los que destacan el bajo rendimiento y el carácter propietario del conjunto de comandos disponibles. Esta técnica se utilizaba en el dominio WWW en aquellos casos en los que se deseaba implementar un mínimo comportamiento dinámico en servidores HTTP para sistemas Unix.

Tomando como base este mismo modelo de operación, han surgido técnicas de segunda generación, como es el caso de ASP (Active Server Pages, de Microsoft) y PHP (Personal Home Pages), que ofrecen posibilidades muy superiores en lo que a generación dinámica de contenidos se refiere, y que, en su conjunto, se podrían considerar mecanismos SSI Mejorados.

ASP es hoy día la principal tecnología ofrecida por Microsoft para la generación dinámica de páginas Web, y es directamente reutilizable en el contexto WAP. Los servidores Web Internet Information Server y Personal Web Server ofrecen soporte nativo de páginas ASP. Básicamente, una Página ASP no es más que un archivo de texto con extensión .ASP que contiene una combinación de códigos de un lenguaje de descripción de contenidos (como HTML o WML) y sentencias en un lenguaje de script para servidores (En este caso concreto, se pueden usar JavaScript y VBScript).

Así las cosas, salvo en lo referente a la mayor flexibilidad que proporciona un lenguaje de scripts, este modelo en sí no parece diferir demasiado del modelo básico SSI. Sin embargo, la verdadera importancia de esta tecnología radica en el hecho de que ASP permite la integración de componentes COM (Component Object Model, Modelo de Objetos para Componentes) en el servidor. De esta manera, un script ASP avanzado puede limitarse a crear un flujo de control, desde el que se realiza la invocación de Componentes Activos de Servidor que implementan la lógica la negocio y la conectividad con diversas fuentes de datos (locales o remotas). El propio servidor IIS 4.0 proporciona varios componentes útiles en este sentido.

Veamos ahora algunas notas de interés para la generación de contenidos WML con ejemplos de implementación usando ASP:

A. En primer lugar, se debe identificar en la cabecera HTTP de respuesta el tipo MIME del objeto devuelto:

<!--#include file="conn.asp">
<%
Response.ContentType= "text/vnd.wap.wml" %>

B. En segundo lugar, la aplicación debe identificar el tipo de documento XML devuelto (recuerde que WML se basa en XML):

<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1>
<wml>
...

C. Típicamente, el código ASP puede utilizar el modelo ADO (ActiveX Data Objects) para el acceso a elementos de una base de datos, de modo que se pueda ofrecer una carta WML que contenga, por ejemplo, un elemento SELECT con una lista de opciones:

<card id="carta1" title="Seleccione producto">
<%
sqlQuery = "SELECT [Cod_Prod], [nombre] FROM Productos"
set rsProductos = conn.execute(sqlQuery)
%>
<select name='prod'>
<%
do while not rsProductos.eof
response.write("<option value='" & rsProductos("Cod_Prod") &"'>"& rsProductos("nombre")
rsProductos.MoveNext
loop
%>
</select>

D. Se debe evitar el uso del objeto Session, aunque sea necesario repetir consultas al SGBD, pues su funcionamiento depende del uso de cookies, que, pese a formar parte de la especificación, no siempre están soportadas en terminales móviles WAP de primera generación

E.   En ocasiones, aún a riesgo de comprometer el principio de independencia del dispositivo contemplado por WML, es preciso realizar ajustes finos en la presentación para terminales específicos:

<%
if InStr(Request.ServerVariables ("HTTP_USER_AGENT"),"MotorolaTimePort") then ...
%>

3.2 La interfaz CGI (Common Gateway Interface)

La interfaz CGI, profusamente usada en el dominio WWW, posibilita la ejecución de aplicaciones externas en el servidor, cuya misión consiste en procesar la información suministrada por el usuario y generar al vuelo un documento WML (u objeto Wap, en general) que se devuelve al gateway WAP como respuesta, para su reenvío al cliente.

Estas aplicaciones pueden encargarse de forma autónoma de la gestión de los datos (procesamiento directo) , o bien actuar como pasarela middleware hacia otras aplicaciones especializadas (procesamiento indirecto).

El principal problema de las aplicaciones CGI es su pobre eficiencia en situaciones de carga elevada en el servidor. En efecto, cada vez que un cliente Web (el gateway WAP) hace una referencia a un programa CGI, se crea un proceso totalmente nuevo en el servidor para su ejecución : el Sistema Operativo debe inicializar un espacio de direcciones, leer el ejecutable de disco, cargar librerías dinámicas, iniciar la ejecución del programa, inicializar sus variables, y, finalmente, leer y procesar los datos enviados por el cliente Web.

Si, además, el programa CGI está codificado en un lenguaje interpretado (por ejemplo, Perl), la situación se agrava aún más, ya que a todo lo anterior se ha de añadir una importante penalización de tiempo debida a la carga del intérprete y al proceso de análisis léxico y sintáctico del archivo fuente.

Para la codificación de aplicaciones Wap basadas en CGI, existen librerías de código Perl que simplifican enormemente el desarrollo al ofrecer funciones específicas para generar contenidos Wap. Por ejemplo en la librería wmlib.pl, la función &PrintHeader genera la siguiente salida WML:

Context-type: application/x-wap.wml\n\n
<?xml version="1.0"?>
<!DOCTYPE WML PUBLIC "-//WAPFORUM//DTD WML 1.0//EN" "http://www.wapforum.org/DTD/wml.xml">

Como se puede observar, en el ejemplo, lo primero que se hace es lo que toda aplicación de servidor tiene por obligación: identificar el tipo MIME devuelto. En realidad este tipo se entrega al gateway, por lo que cabe usar tipos MIME propietarios para activar funciones específicas del gateway. Por ejemplo, en el caso del servidor UP.Link, se utiliza el tipo multipart/x-up-fax para activar el envío de los contenidos a un fax designado por el usuario/abonado.

3.3 Interfaces de Programas de Aplicación (APIs) propietarias.

En este caso se trata de desarrollar aplicaciones de funciones similares a las de los programas CGI, pero accediendo directamente al código nativo de los servidores. De este modo se incrementa el rendimiento de las aplicaciones y se reduce considerablemente la carga de los servidores.

Las APIs de referencia son las desarrolladas por Microsoft (ISAPI) y por Netscape (NSAPI), y son conceptualmente similares. Las aplicaciones xSAPI se implementan como librerias dinámicas (DLLs), con lo que se evita la creación de un proceso específico en el servidor para atender cada una de las peticiones de los clientes Web.

El uso de APIs en el servidor reduce notablemente la sobrecarga asociada a la ejecución de CGIs, pero no sin un coste : el código de una aplicación WAP implementada con xSAPI está directamente enlazado con el del servidor, por lo que cualquier bug podría, potencialmente, afectar al comportamiento del propio servidor. Por otra parte, no hay que olvidar que el código creado es propietario para cada servidor, por lo que se pierde la portabilidad de las aplicaciones WAP.

3.4 Interfaz CGI Asíncrona (FastCGI)

Se trata de una técnica reciente, y aún en evolución en el dominio WWW, que trata de combinar las ventajas de la interfaz CGI (simplicidad, aislamiento de procesos, solución estándar independiente del lenguaje y de la plataforma) con las derivadas de la utilización de APIs en el servidor (eficiencia y extensiones otras operaciones en el servidor).

La interfaz FastCGI es conceptualmente similar a la intefaz CGI, con dos importantes diferencias :

a. Los procesos FastCGI son persistentes : no se destruyen tras finalizar el procesamiento de una petición, sino que entran en estado de espera de nuevas peticiones.

b. El protocolo FastCGI multiplexa la información de entorno, la entrada estándar, la salida estándar y la salida de errores usando una única conexión bidireccional. En el caso de ejecución local se usa un pipe full-duplex, y en el caso de ejecución remota, el servidor utiliza una conexión TCP.

3.5 Servlets

Los servlets son programas codificados en Java que se ejecutan, como alternativa directa a CGI, en servidores HTTP especialmente diseñados para ello. Se trata, pues, de componentes de servidor, independientes de la plataforma, codificados en Java, y que permiten modificar dinámicamente las funciones del servidor. Así, los servlets ofrecen un entorno de desarrollo general para la creación de servicios basados en el paradigma solicitud/respuesta.

La utilización de servlets constituye una de las últimas tendencias en la programación de aplicaciones Web para servidores, y tienen una aceptación que crece día a día, y en consecuencia, son candidatos idóneos para el desarrollo de soluciones WAP en servidores HTTP.

Existe una única máquina virtual Java ejecutándose en el servidor HTTP, y los servlets sólo se cargan una vez, bajo demanda. Un servlet no se vuelve a cargar mientras no sufra ninguna modificación, y aún siendo éste el caso, no es necesario reiniciar el servidor.

Además, dado el carácter estándar del propio lenguaje Java, los servlets son directamente portables entre plataformas (independencia del Sistema Operativo y del tipo de servidor, en tanto en cuanto ofrezca soporte de Servlets)

A nivel de rendimiento, una de las principales características de los servlets es el hecho de que no precisan de la creación de un nuevo proceso para cada petición. En la mayoría de los sistemas, los servlets se ejecutarán en paralelo, dentro del mismo proceso del servidor. En estos casos, los servlets tienen una gran ventaja de rendimiento frente a las aplicaciones CGI e incluso aplicaciones FastCGI. Además, puesto que los servlets residen en memoria, posibilitan la compartición de información estática o persistente entre invocaciones.

Ya en el apartado de características avanzadas, un servlet puede reenviar solicitudes a otros servidores, lo que permite equilibrar la carga (load balancing) o utilizar servidores específicos para la generación de determinados contenidos (service request dispatching).

Veamos ahora un ejemplo de este tipo, en el que se usa la tecnología de servlets para la generación de contenidos WAP usando varios servidores [LUOMA99]:

En este ejemplo (ver Figura adjunta), la lógica de la aplicación se reparte entre dos tipos de servidores: un servidor Web estándar y servidores de aplicaciones. El usuario establece, a través del gateway WAP, una conexión con el servidor HTTP. Aquí se activa un servlet que se encarga de localizar, mediante un mecanismo de distribución basado en RMI (Invocación de Métodos Remotos) o CORBA un servidor de aplicaciones para ejecutar el servicio solicitado (que se modela como una clase Java). Una vez localizada dicha clase que representa al servicio, se establece la conexión entre el servidor WEB y el servidor de aplicaciones.

4 Eficiencia en la entrega de respuestas

Sea cual fuere el mecanismo elegido para la generación dinámica de contenidos WAP, es preciso tener en cuenta que existe un método para lograr una mayor eficiencia en la entrega de dichos contenidos al cliente final: se trata de los resúmenes (digests)

Los resúmenes, lejos de ser un extracto de los contenidos generados como parece sugerir el nombre, son, en este contexto, un formato MIME multiparte (multipart/mixed) que permite el envío de una o más entidades (mazos y otros contenidos WAP) en un único mensaje al gateway WAP [PHONE99].

Si se sabe de antemano que el usuario solicitará múltiples entidades, se pueden enviar todas en una única respuesta, con lo que el servicio percibido será mucho más ágil, ya que cada ciclo solicitud/respuesta HTTP tiene una sobrecarga de tiempo mínima independiente de la cantidad de datos a transmitir.

En cualquier caso, teniendo en cuenta que los servicios de creación de contenidos normalmente generan respuestas de longitud variable, se debe limitar el tamaño de los resúmenes a 1200 bytes

El formato de los resúmenes es el clásico del formato MIME multiparte:

Cabecera del resumen con indicación de separador

Separador
Entidad Contenido nº1
Separador
Entidad Contenido nº2
Separador
...

5. Personalización del formato de los contenidos

Resulta claro que las distintas técnicas de procesamiento en servidor ya vistas posibilitan la personalización de contenidos que se envían al cliente final; Sin embargo, aún queda por solucionar un aspecto importante de la personalización: el formato de presentación de los contenidos.

Cierto es que serán las propias técnicas de procesamiento las que se encarguen también de asignar el formato apropiado a los contenidos generados, aunque para conseguirlo, será necesario utilizar algún mecanismo que permita obtener las características físicas y la configuración actual del cliente y así poder establecer cuál es el formato más apropiado.

A continuación se expone uno de los mecanismos más avanzados de negociación de formato que se han propuesto para su aplicación en el contexto de WAP (Ver Figura adjunta).

Por un lado, se contempla la adquisición de características del terminal, y, por otro, la aplicación del formato correspondiente.

La primera cuestión queda resuelta con el envío de un documento Perfil de Cliente (en formato CC/PP) desde el propio terminal al gateway WAP [OHTO99], [REYN99]. CC/PP (Composite Capabilities/Preferences Profile) es un formato de metainformación creado por el W3C. Se trata de un entorno estructurado en RDF, fácilmente extensible, que permite describir las características de un dispositivo y/o las preferencias del usuario [LASS99].

Veamos ahora cómo se puede solucionar la segunda cuestión (aplicación de formato apropiado): En el dominio Web existe un mecanismo que separa la presentación de los contenidos: las hojas de estilo CSS. Así, si se tienen distintos tipos de clientes Web, bastará con aplicar la hoja de estilo apropiada para cada uno de ellos a los contenidos, que permanecen inalterados.

Esta solución no es válida para terminales WAP, puesto que en la especificación actual no se admite el uso de hojas de estilo. Esto significa que sólo se tiene la opción de transformar los datos en el propio proceso de generación, en lugar de usar hojas de estilo para asignarles un nuevo formato.

Como se sabe, WML se basa en XML. Por otra parte, puesto que la DTD de XML describe exactamente las semántica y el contenido de los códigos (usando una estructura arborescente), resulta sencillo transformar un archivo XML de un formato a otro. Únicamente será necesario usar un sistema de transformación, como XSL (en el que se define un árbol de reglas de transformación), con lo que el problema estaría resuelto de una forma simple y conceptualmente elegante.

Conclusiones

La tecnología WAP supone uno importantísimo avance en lo que se refiere al acceso ubicuo a servicios por vía telemática, aprovechando la aceptación generalizada del uso cotidiano de dispositivos móviles, que, en el caso concreto de terminales telefónicos, ya se cifran en torno a los 300 millones a nivel mundial.

Uno de los aspectos más notables de WAP es la posibilidad de reutilizar tecnologías maduras y suficientemente probadas como las existentes en el dominio WWW para ofrecer dichos servicios y resolver el problema de la generación dinámica de contenidos, logrando de este modo un grado de personalización no contemplado hasta el momento.

Además, por ser Wap una tecnología independiente del portador físico de acceso a la red inalámbrica, queda garantizada su vigencia para un futuro próximo, en el que existirá una evolucion de las redes GSM actuales a redes GPRS y, posteriormente, UMTS.

Esta evolución no sólo supondrá un beneficio directo para las aplicaciones WAP por el importante aumento de ancho de banda que trae consigo, sino que además existirá integración con otros servicios como es el caso de GPS, lo que permitirá una personalización de contenidos sin precedentes: basada en la ubicación actual del terminal móvil, y, por ende, del usuario.

En cualquier caso, es preciso tener en cuenta que en el desarrollo de soluciones WAP se deberán extremar los controles de calidad, pues los usuarios las perciben como servicios de telecomunicaciones, y por ello, el grado de exigencia de disponibilidad y fiabilidad es mucho más alto que, por poner un ejemplo, en el ámbito de los servicios tradicionales de Internet, donde el usuario suele ser más tolerante.