La aplicación web empresarial

Este artículo pretende plantear los requisitos genéricos que debe cumplir una aplicación Web empresarial.

Más que una visión tecnológica se plantearán ideas desde el punto de vista de la utilidad que puede sacar la empresa de estas tecnologías y comentarios basados en la experiencia sobre la mejor utilización o puntos que debemos tener en cuenta a la hora de abordar un proyecto Web.

Plantearé las necesidades sin entrar en dar soluciones, para ello tenemos toda la documentación y manuales de GestorWeb que dan una respuesta técnica a los requerimientos aquí planteados.

Pensemos que cualquier proyecto que abordemos sobre Internet tipo e-business, e-commerce, e-procurement, etc. tiene como interface de comunicación con el usuario una aplicación Web.

Independientemente de la funcionalidad final de la aplicación, existen una serie de necesidades intrínsecas al medio que estamos utilizando y que pueden surgir en cualquier momento. Este es el mayor problema, que puede que no surja la necesidad hasta que la aplicación sea demasiado grande y el cambio demasiado costoso. Esto provocará una caída en la calidad del servicio que estamos ofreciendo frenando el crecimiento en el mejor de los casos.

La empresa puede beneficiarse de las ventajas de comunicación que ofrece Internet ofreciendo servicios útiles a sus clientes, proveedores, agentes comerciales y usuarios en general tanto externos como internos, pero cuando creamos este nuevo canal de comunicación tenemos que prestarle la atención que requiere porque de ello depende la imagen que los usuarios van a percibir de nuestra empresa.

Otro punto en el que debemos hacer hincapié es que los servicios Web nos ayudan a solucionar problemas y necesidades actuales de nuestras empresas. Podemos pensar en crear nuevas empresas o buscar nuevos clientes, pero la verdadera ventaja de los servicios web es que automatizan los procesos de servicio que ya tienen las empresas de forma que pueden crecer en producción sin elevar sus costes en recursos de comunicación, tramitación y post venta.

Si no tenemos claro desde el principio cual es nuestro objetivo no podemos discernir cual es el mejor camino.

Uno de los cambios fundamentales que se ha producido, en el desarrollo de software en los últimos años está más cercano a la filosofía que a la tecnología, y es el cambio de orientación hacia el servicio.

Una aplicación Web es una aplicación orientada al servicio.

Mientras en las aplicaciones tradicionales el objetivo es el procesamiento de datos, en las aplicaciones Web el objetivo es ofrecer un servicio a cada uno de los usuarios que se conectan.

Pensemos que mientras en una aplicación de gestión tradicional el único beneficiario es la empresa y por tanto el interface está concebido para satisfacer las necesidades de ese beneficiario, en una aplicación Web el beneficiario debe ser cada uno de los usuarios que se conectan a la misma. Y cada usuario tiene una concepción de lo que él espera de ese servicio, su beneficio.

En la mayoría de los casos es un error trasladar el análisis de la aplicación de gestión interna de la empresa a una aplicación Web. No pensemos que vamos a poder dictar las normas y nuestros usuarios las seguirán a rajatabla. La Web es un sistema basado en la oferta y la demanda. Si no ofreces el servicio que demandan tus usuarios simplemente no lo utilizan. Y la empresa dejará de percibir los beneficios que esperaba sacar de esta utilización.

Este precepto va a marcar el análisis, las tecnologías a utilizar, el diseño, la usabilidad, y todo lo que interviene en la provisión de ese servicio incluidos los sistemas sobre los que se ejecuta la aplicación, los técnicos que soportan los sistemas, los sistemas de gestión de los que se alimenta la aplicación Web, etc. Pero en esta ocasión vamos a centrarnos en los requisitos específicos de la aplicación.

Cuando pensamos por primera vez en el concepto aplicación Web lo identificamos automáticamente con páginas Web. Las páginas Web han sido concebidas para publicar información a toda la comunidad Internet de forma sencilla. Esta simplicidad se vuelve en contra cuando queremos desarrollar aplicaciones complejas en entornos empresariales.

Cualquier conjunto de páginas web que interactuen con el usuario ofreciéndole la información solicitada y recogiendo datos del mismo podría llegar a percibirse como una aplicación Web por parte ese usuario, pero desde el punto de vista de la empresa la cosa cambia.

Vamos a ver los requisitos que debe cumplir cualquier aplicación Web genérica, con independencia de la implementación concreta en la que estemos pensando para nuestra empresa.

Esto debe ser así porque lo que vamos a construir es una plataforma desde la que ofrecer servicios a terceros, y aunque tengamos claras las necesidades inmediatas y los servicios que queremos ofrecer a nuestros clientes, representantes, etc. en un primer momento, van a ser los usuarios los que nos deben indicar que y como quieren consumir ese servicio. Y nuestra aplicación debe ser capaz de adaptarse a las nuevas demandas.

La decisión de qué servicios ofrece a sus usuarios corresponde a la empresa y no debe ser limitada por la tecnología que está utilizando. Muchos intentos de ofrecer servicios por Internet han fracasado por estas carencias y en parte se ha echado la culpa a Internet, a que la mayoría de mis clientes no están conectados, a que los usuarios no saben utilizar la plataforma.

Internet es un medio de comunicación, no se puede echar la culpa al mensajero del contenido del mensaje. Si tenemos un buen contenido y se ajusta a la demanda de nuestros clientes la utilización del medio es cuestión de tiempo, pero en cualquier caso la norma del 80/20 suele ayudarnos. Si el 20% de nuestros clientes tienen el 80% de nuestra facturación y ese 20% coincide con el 20 que utilizan internet estamos mejorando el servicio para el 80% de los intereses de la empresa. Pero además, al automatizar los servicios podemos duplicar nuestros clientes prácticamente con el mismo coste de servicio.

Pensando en una aplicación Web empresarial no como un programa informático sino como una plataforma de integración de servicios, veamos los requisitos que debe cumplir:

• Control de acceso por usuarios.
• Acceso on-line a los datos.
• Capacidad de integración.
• Independencia del diseño.
• Flexibilidad para la ampliación.
• Completamente administrable por la empresa.
• Calidad de servicio asegurada.

Y todo esto debe estar desarrollado sobre estándares Internet para asegurarnos un acceso desde cualquier lugar y desde la mayoría de los dispositivos de acceso a Internet.

Al entrar en algunas webs encontramos una casilla o enlace donde nos pide el login y password para poder seguir navegando por una zona determinada. En otras nos muestran información general, y cuando nos registramos el sistema reconoce nuestro perfil y actúa en consecuencia mostrándonos información particular del tipo: si tenemos correo nuevo o hacernos un resumen de las noticias de nuestro interés.

Un perfil de usuario está compuesto por una serie de roles que la aplicación conoce y puede tener un comportamiento distinto según los roles de los que disponga el usuario conectado.

En una aplicación web empresarial esto es de vital importancia, porque no queremos mostrar la misma información a un comercial que a un cliente, incluso diferentes clientes pueden tener diferentes tarifas e incluso restricciones según que productos.

Todas las restricciones que necesitemos y muchas más que irán saliendo según nuestra aplicación Web vaya dando más y más servicios deben estar implementadas mediante una arquitectura que ofrezca estos mecanismos de base. A código abierto es posible hacer casi cualquier cosa, el problema es que todos estos parches que introducimos en páginas sueltas terminan debilitando la aplicación y haciéndola vulnerable y difícil de mantener.

Un histórico de los usuarios conectados también es importante para conocer el uso que se hace de nuestros sistema.

La gestión de usuarios y sus perfiles es una parte importante de nuestro sistema y deberíamos tener herramientas que nos ayuden en estas tareas.

Los componentes que manejan el control de acceso suelen utilizar bases de datos para almacenar información de usuarios y sus perfiles, pero sería aconsejable que la arquitectura fuera abierta de forma que permitiera la utilización de otro tipo de repositorios como archivos xml, texto plano, directorios LDAP, etc.

Y por último un control de acceso no solo es la autenticación del usuario, también debe incluir los componentes para el comportamiento selectivo de la aplicación según el perfil del usuario.

El objetivo es que el usuario sienta que se le está tratando de forma personalizada, que no nos estamos ahorrando el contacto directo sino que ha entrado a formar parte de la organización y está haciendo uso de esos privilegios.

Una vez tenemos identificada que tipo de información queremos suministrar o recoger de los usuarios de nuestro servicio una duda que siempre surge cuando se ataca un proyecto de este tipo es: ¿donde deben estar los datos ?.

La respuesta a esta pregunta depende de otras dos: ¿donde están los datos?, y ¿que tiempo de vida tienen?.

Si la información que está pidiendo el usuario tiene un tiempo de vida muy corto solo podemos ofrecérsela desde donde se produce. De cualquier otra forma nuestro servicio no tendría la calidad esperada por nuestro cliente y estaríamos dando un mal servicio, que en muchos casos es peor que no darlo.

En general, como regla a aplicar a la hora de tomar estas decisiones debemos pensar que toda la información que vamos a dar a través de Internet debe tener el mismo nivel de fiabilidad que si nos llamaran personalmente.

Si no podemos cumplir este requisito es mejor no darla, porque en el momento que un usuario desconfíe de la información obtenida a través de Internet volverán a llamar por teléfono echando por tierra todo el esfuerzo que hayamos realizado por automatizar el servicio. Esto sin contar con la desconfianza personal puesto que no puede saber si el sistema ha funcionado mal o simplemente hemos anulado su reserva para dársela a otro cliente.

Por tanto la aplicación debe ser capaz de atacar a los sistemas de gestión de la empresa para acceder o dejar información en línea. Recordemos que aunque no estemos pensando en, por ejemplo, hacer reserva de mercancías en un primer momento nuestro sistema debe ser capaz de implementarlo en el momento que lo necesitemos.

Los datos deben residir en la empresa y solo son entregados a quien dispone de los permisos necesarios.

En la mayoría de los casos una aplicación Web no sustituye a los sistemas informáticos que ya tiene la empresa, por el contrario, es el envoltorio que los transforma en servicio.

Para ello debe tener una alta capacidad de integración con los sistemas existentes: bases de datos, ERPs (Enterprise Resource Planing) y otros sistemas automáticos.

Esto se consigue utilizando protocolos estándar para conectar con cualquier recurso que necesite la aplicación. Independiente del fabricante del servidor de bases de datos nuestra aplicación debe conectarse a la base de datos a través del protocolo JDBC. El servidor de correo debe ser accesible por pop3, imap, smtp. Si necesitamos un servicio de mensajería debemos acceder mediante JMS (Java Messege Service).

La utilización de protocolos estándar es lo que nos da la independencia de elegir qué producto del mercado se ajusta mejor a nuestras necesidades y de cambiar, por ejemplo, a otra base de datos más potente cuando el sistema lo requiera sin necesidad de modificar la aplicación.

El poder cambiar de producto y de proveedor de una parte de nuestro sistema sin tener que modificar la aplicación es lo que nos permite una escalabilidad real. Si solo tenemos la posibilidad de meter máquinas más potentes pero utilizando los mismos programas servidores yo lo llamo apilabilidad. Cualquier sistema puede ser apilable pero muchas veces esto no basta.

Tengamos cuidado con el uso y abuso de tecnologías dependientes de la plataforma Active-x,DCOM, etc. o protocolos propietarios que no hayan alcanzado el status de estándar de facto porque podemos quedarnos enganchados al fabricante.

Una aplicación Web debe extender los sistemas de los que ya dispone la empresa, haciendo una labor integradora entre los mismos.

Una plataforma de servicios no es un ERP pero es interesante que pueda integrarse con estos sistemas de gestión también mediante mecanismos estándar como JCA (Java Connector Architecture) creando una independencia del sistema de back-office que estemos utilizando.

Las aplicaciones Web ofrecen servicios y los servicios pueden cambiar o crecer por requerimientos del mercado.

Al mercado le va a dar igual que hayas estado analizando tu aplicación durante tres meses para contemplar todas las posibilidades, es capaz de inventarse nuevas. De hecho, la única forma de evaluar la flexibilidad de una aplicación es analizar su arquitectura.

La arquitectura debe separar la lógica de negocio del diseño gráfico. Si se quiere cambiar el diseño no se tenga que reescribir la aplicación. Arquitecturas MVC (Model View Controller).

La aplicación debe trabajar directamente con los objetos de datos, dejando a la tecnología de Data Bindig que se encargue de llenar los objetos desde las fuentes de datos unmarshalling y restaurar las fuentes de datos desde los objetos marsalling.

Debe estar provista de herramientas para el tratamiento de variables de aplicación que permita acceder a las variables con independencia del repositorio de las mismas. Además es interesante que se puedan utilizar macros para referenciar variables dentro de otras variables.

Debe proveer de herramientas de administración de la propia aplicación, de los servicios sobre los que se sustenta: como con las bases de datos. De lo contrario podemos vernos restringidos al intentar ampliar funcionalidades.

Internet ha cambiado el concepto del software, un programa funciona correctamente cuando llega al usuario, cuando se convierte en servicio, y esto no termina en la máquina en la que se está ejecutando. Todas las capas que cubren a una aplicación hasta convertirla en servicio son otros servicios que deben estar funcionando correctamente.

Montado sobre una plataforma que asegure:

• Alta disponibilidad.
• Actualización continua.
• Seguridad

HTTP es un protocolo pensado para publicar páginas estáticas, no se creó para desarrollar aplicaciones. En 1989, en el Centro Europeo de Investigación Nuclear (CERN), Tim Berners-Lee propuso compartir la información utilizando documentos de texto de hiperenlace. Junto con un colega que conocía SGML llamado Anders Berglund desarrollaron una versión de hipertexto llamada Lenguaje de marcado de hipertexto (HTML).

Tim denominó a su sistema de hipertexto la Web mundial (world Wide Web).

Su sencillez, sin duda, ha sido la base de su éxito, la posibilidad crear páginas con información formateada desde un simple editor de textos y sin la necesidad de tener conocimientos profundos en lenguajes de marcado, unido a la proliferación de herramientas para la creación de páginas Web han inundado Internet de páginas formateadas en HTML.

Para visualizar estas páginas se crearon los navegadores Web. Sencillos programas, en un principio, que traducían el lenguaje de marcado HTML a un formato visual. Las compañías que desarrollaron estos navegadores han ido incorporando extensiones al lenguaje para ir mitigando sus carencias y para satisfacer las demandas que le solicitaba el mercado.

Los navegadores Web acceden a las páginas html conectandose a servidores Web mediante el protocolo HTTP (Hipertext Transfer Protocol), o protocolo de transferencia de hipertexto. Este protocolo provee de la semántica necesaria para la recuperación de recursos, como páginas html, utilizando URLs (Unit Resource Locator) que son direcciones universales para la localización de recursos en el mundo Internet.

Por un lado tenemos una forma de pedir información que se encuentre en cualquier lugar de Internet, o más exactamente hacer llegar la petición de información al servidor Web que se supone que la tiene (http).

Por otro lado tenemos un lenguaje que reconocen todos los navegadores Internet, y que son capaces de transformarlo en un formato con diseño, por tanto sabemos que si la información solicitada al servidor nos es devuelta en HTML podrá ser visualizada en un cliente universal, independiente del fabricante y del dispositivo.

Parece lógico pensar que si podemos formatear cualquier tipo de información que tengamos en nuestros sistemas de gestión en documentos html la tendremos accesible desde cualquier lugar y desde cualquier dispositivo que soporte html.

La tarea no es sencilla y las tecnologías han ido cambiando para responder más eficazmente a este principio. Mientras unas tecnologías basaban su diseño en la sencillez de uso y rápido aprendizaje del lenguaje como el PHP (que toma su nombre de Personal Home Page), otras han invertido su esfuerzo en crear una arquitectura robusta y escalable para dar soporte a complejas aplicaciones corporativas como es el caso de la J2SE y J2EE.

WEBCAT ofrece un marco de trabajo para el desarrollo de aplicaciones Web empresariales.

Vuestros comentarios o sugerencia podéis enviármelos pulsando sobre el icono de envío de correo que hay al principio de esta página.

Gracias.