| Inicio | Perfil | Servicios | Offshore | Recursos | Mapa del sitio | Contáctenos |
Artículo "La transición a J2EE es más larga de lo que la mayoría de organizaciones piensa"
En este interesante artículo, recomendado para las empresas que deseen realizar la transición al desarrollo en J2EE, Jacquie Barker nos explica por qué dicha transición es más larga y costosa de lo que parece en un principio, debido a la variedad de tecnologías y conceptos nuevos y complejos que implica el desarrollo en J2EE.
Artículo "La transición a J2EE es más larga de lo que la mayoría de organizaciones piensa" (continuación)
Además de comprender los fundamentos del paradigma de objetos, se debe aprender también la sintaxis específica de Java para traducir los conceptos de orientación a objetos. Esto no es en sí mismo demasiado difícil, pero con ello viene la tarea desalentadora de familiarizarse con los cientos de clases preexistentes construidas en el lenguaje Java en forma de varias APIs o bibliotecas de clases (llamadas “paquetes” en Java) con el fin de (re)utilizarlas inteligentemente en nuestras aplicaciones. A continuación, surge el reto de comprender y dominar el paradigma de aplicaciones para el Web, el cual es, de nuevo, significativamente diferente del desarrollo tradicional de aplicaciones. Primero, debemos aprender cómo trabajar en lo que es esencialmente un entorno “sin estado” debido a la dependencia de las aplicaciones en la Web del protocolo HTTP de “petición-respuesta”. En una aplicación tradicional (orientada o no a objetos), el programador tiene la posibilidad de guardar datos en la memoria mientras sirvan a un propósito útil de la aplicación (esto se llama “datos que están en ámbito”). Por el contrario, en una aplicación Web, se deben aprender nuevas formas de conseguir que los datos persistan durante sus idas y venidas entre el navegador y el servidor. En una aplicación convencional, típicamente se compila la aplicación en un único ejecutable o, en el caso de Java, se cargan varias clases y objetos en una única instancia de la Máquina Virtual de Java para ejecutar su lógica. Por contraste, los fragmentos de una aplicación Web están desunidos en forma de Java Server Pages (JSPs), formularios HTML, clases “bean” de apoyo, archivos de configuración XML y cosas así. Se debe dominar una variedad de diferentes lenguajes (Java, JavaScript, HTML, XML, bibliotecas de etiquetas “a la medida”, etc.), cada uno con una sintaxis significativamente diferente, para trabajar estos variados componentes. Incluso si todos los fragmentos se construyen sin fallos, la aplicación en su totalidad puede fallar si cualquiera de estos fragmentos se despliega incorrectamente en un servidor Web; estos problemas son difíciles de depurar. Puede introducirse una miríada de problemas con respecto a la configuración de dichos entornos de despliegue – es decir, los servidores Web. Muchas veces, un desarrollador de aplicaciones Web “golpea su cabeza contra la pared” durante días, semanas o incluso meses, intentando depurar un problema de la aplicación que, al final, resulta ser un asunto de configuración del servidor Web. Desgraciadamente, en muchas organizaciones, la responsabilidad de la administración del servidor Web recae sobre un grupo de individuos separados de los que desarrollan aplicaciones Web. Frecuentemente, se producen “batallas políticas” de acusaciones recíprocas entre las dos organizaciones sobre si una aplicación Web falla debido a un error de desarrollo o a un asunto de configuración del servidor Web. Para acabar, hay un conjunto de tecnologías de componentes J2EE particulares que deben dominarse –servlets, JSPs, JDBC, etc., cada una con sus propios obstáculos y retos conceptuales.
Ir a la página: 1 2 3 Siguiente >>
Versión para imprimir
| Inicio | Perfil | Servicios | Offshore | Recursos | Mapa del sitio | Contáctenos| |