Inicio
 > Informes e investigaciones > Blog de TEC > Evolución de la arquitectura: desde la arquitect...

Evolución de la arquitectura: desde la arquitectura basada en la Web hasta la arquitectura orientada al servicio

Escrito por: Predrag Jakovljevic
Publicado: septiembre 19 2006

Extensión de las aplicaciones a la Web

La tecnología cliente/servidor previa a Internet dependía de las buenas comunicaciones entre las máquinas involucradas, y las redes de área local (LANs) y las redes extensas (WANs) se convirtieron en un gasto y un dolor de cabeza para la mayoría de las compañías. Además, actualizar las versiones de software, en especial en las numerosas computadoras personales (PCs), se convirtió en un problema que prácticamente no tenía solución. Por lo tanto, como una solución, varios departamentos de tecnología de la información (IT) se han movido hacia una tecnología basada en Internet o Intranet. En este acercamiento, las utilidades de las comunicaciones proporcionan una amplia estructura en el área de comunicaciones, y las PCs simplemente comunican los localizadores uniformes de recursos (URLs) para tener acceso a los servidores de los que necesitan ayuda. El software con código en lenguaje Java (o cualquier otro código fácil de utilizar de la Web) que opera en las PC de los clientes se puede descargar cuando sea necesario, para asegurarse que siempre se utilice la última versión. Con un sistema empresarial de Internet , las actualizaciones del software del lado del cliente se vuelven innecesarias, mientras que las aplicaciones basadas en navegadores simplifican en gran medida el entrenamiento. Unir locaciones lejanas de una empresa también se vuelve más sencillo.

Segunda parte de la serie Evolución de la arquitectura: desde la arquitectura de los marcos principales hasta la arquitectura orientada a los servicios

De hecho, debido al fenómeno de Internet, términos como basado en la Web y habilitado en la Web han reemplazado el término cliente/servidor de los años 90, ahora con connotación de una antigua forma de hacer las cosas previa a la Web. Sin embargo, la mayoría de los sistemas cliente/servidor han sido modificados para incluir el acceso a la Web, y la aplicación basada en la Web o la arquitectura es naturalmente una verdadera arquitectura cliente/servidor. En concreto, del lado del servidor, la Web utiliza una arquitectura de niveles múltiples interenlazada con los servidores Web, servidores de aplicación, servidores de bases de datos, y servidores caché, mientras que en el lado del cliente, las máquinas usuarias por lo general ejecutan escritos anexados a innumerables páginas Web. También ejecutan Java applets, programas más grandes de Java, aplicaciones de clientes ricos, etc., lo que significa que tanto el cliente como el servidor cooperan.

La ventaja de una arquitectura basada en Internet es que cualquier computadora con un acceso seguro a Internet puede ingresar al producto, dado que tan sólo con teclear una dirección URL, uno puede tener acceso al sistema. Existen ahorros potenciales en términos de despliegue, mantenimiento, soporte y actualizaciones, ya que los cambios por el lado del servidor están disponibles de forma instantánea a todos los usuarios.

Sin embargo, mientras que este acercamiento puede ser de gran valor desde una perspectiva IT, en un inicio no mejoró necesariamente la experiencia del usuario de una aplicación. De hecho, varios usuarios incluso se quejaron de una menor utilización y desempeño de las primeras aplicaciones en un modo puro de Internet. Los usuarios reportaron un serio declive en el desempeño de la aplicación debido a las numerosas idas y vueltas del lenguaje de marcas de hipertexto (HTML), a la pesada navegación de hiperenlaces, y a las redes más lentas. Incluso después de actualizar la red, soportar los servidores (ya que se requiere un hardware más grande para el servidor y un software del servidor Web), y volver a diseñar la interfase para conducir la navegación (por medio de cortas combinaciones de teclas), varios usuarios todavía anhelaban la metáfora de la interfase "rica" de cliente/servidor.

Las primeras arquitecturas de Internet de cliente esbelto también hicieron poco para fortalecer los dispositivos manejados de forma inalámbrica, los teléfonos celulares, y otras tecnologías inteligentes. Por lo tanto varios vendedores desde entonces han, dentro de sus series, entregado interfases de usuario (UIs) más ricas, más dinámicas y con un gran desempeño, con una fuerte integración a los productos de escritorio de Microsoft para los usuarios que siempre están conectados y para UIs HTML / HTML dinámica (DHTML) para los usuarios externos o casuales del sistema. Las últimas tecnologías llamadas Web 2.0 como JavaScript asíncrono (AJAX) y el lenguaje extensible de marcas (XML) ciertamente unen la división con lo mejor de dos mundos (consulte, El software como servicio está ganando terreno).

Para mayor información, consulte Evolución de la arquitectura: desde la unidad de programa hasta SOA.

Retos de extender la planificación de los recursos de la empresa al Internet

Extender las aplicaciones de la oficina de gestión a Internet surge a partir del deseo de varias organizaciones usuarias de no reinventar la rueda en su intento de crear aplicaciones listas para el comercio electrónico. Al extender los sistemas existentes de planificación de los recursos de la empresa (ERP), las organizaciones no sólo necesitan mejorar su inversión en la solución ERP, sino también necesitan acelerar el desarrollo de sus capacidades de comercio electrónico.

Sin embargo, los sistemas empresariales tradicionales han probado ser difíciles de cambiar y extender. Detrás de complejas interfases del programa de aplicaciones (APIs) de propiedad, y con base en esquemas complejos y casi indescifrables de bases de datos relacionales, los sistemas ERP tradicionales no llegan al comercio electrónico. Por lo tanto, las tecnologías de transporte y comunicación como los servicios Web, corredores y filas de mensajes, el intercambio electrónico de datos (EDI), y XML acaparan toda la atención, pero el problema inherente de los antiguos códigos centrales y la duplicación de la lógica comercial con frecuencia se ocultan o no se discuten abiertamente (para mayor información consulte, Integrating All Information Assets).

La primera etapa en la conquista del ERP de la Web fue permitir el acceso al navegador a través del soporte para el protocolo de transferencia de hipertexto (HTTP), HTML, y Java. Esta etapa de añadir un nivel de acceso Web en los sistemas existentes de cliente/servidor lo han completado la mayoría de los vendedores empresariales. Sin embargo, esta es sólo una solución a corto plazo, ya que sólo se ha reescrito la pieza del cliente para que se pueda accesar por medio de la Web, y debido a la naturaleza de la interacción y al tipo de visita casual los usuarios basados en Internet son diferentes en comparación a las interacciones tradicionales del sistema del usuario.

La siguiente etapa, que comenzó hace poco, es extender las aplicaciones empresariales a la Web, donde los socios comerciales externos y empleados pueden accesarlas y operarlas. Estas aplicaciones basadas en la Web son híbridas en forma, unen los elementos de propiedad, ya sea centrados en el hospedaje o cliente/servidor, con el cliente esbelto y las interfases basadas en el navegador. El truco es unir la funcionalidad avanzada de los sistemas ERP a la Web, pero romperlos en componentes y sin la necesidad de una capa adicional de una arquitectura sobrecubierta. Algunos vendedores también han comenzado a añadir ganchos de movilidad a sus series para que las sesiones ERP puedan accesarse por medio de dispositivos inalámbricos.

Para que los sistemas ERP tradicionales estén en Internet, tienen que:

  1. estar completamente habilitados en un navegador (auque dependa del papel o tarea del usuario, el navegador, Microsoft Office, o Microsoft Windows “cliente rico” puede ser la mejor UI).
  2. tener un nuevo diseño para estar disponible a todos los usuarios corporativos, no sólo a algunos cuantos.
  3. tener un nuevo diseño para estar disponible a los socios comerciales (por ejemplo, cliente, revendedores y proveedores)
  4. tener un nuevo diseño para utilizar un lenguaje estándar de intercambio de datos (como XML), en lugar de protocolos de propiedad.

Para hacer esto de la forma correcta, los vendedores ERP tienen que volver a diseñar por completo sus aplicaciones para un verdadero ambiente de comercio electrónico, en una fuente abierta basada en estándares, Java 2 Enterprise Edition (J2EE), o un servidor de aplicación de Microsoft .NET, que realmente se comprometa. La aplicación resultante entonces tendrá que ser diseñada desde cero para que se pueda accesar por medio de Internet a través de un navegador Web, y tendrá que ser extensible a componentes adicionales, y manejada por un servidor de aplicación con seguridad integrada y características de integración.

Con la potencia de procesamiento transferida de la unidad de programa y as mini computadoras al escritorio, se hizo un gran esfuerzo para hacer que los sistemas fueran ricos en características con una gran cantidad de funcionalidad construida en paquetes de software “listos para utilizar” Sin embargo, cuando la aplicación central se tuvo que actualizar a una nueva versión, todo el desarrollo alrededor del sistema se tuvo que volver a probar para asegurar que el nuevo sistema (con modificaciones y extensiones específicas para la industria) siguiera siendo funcional. En varias instancias los procesos comerciales se tuvieron que cambiar de forma revertida y las tabas de las bases de datos se tuvieron que actualizar directamente. Con frecuencia este tipo de desarrollo anulaba las garantías del software, y los riesgos asociados con este tipo de situación eran muy altos al compararlos con los beneficios potenciales. Asimismo, la integración entre sistemas ERP dispares (ya sea entre distintas divisiones en una empresa o entre socios comerciales) consistía en tecnologías rígidas y complicadas de integración, llamadas integración de las aplicaciones empresariales (EAI). A largo plazo, algo se tenía que hacer con esta situación y con los retrasos resultantes y los altos costos asociados con las modificaciones de actualización.

Para ello, la fase de nivel n y la arquitectura basada en Internet ha surgido en la era de un entrenamiento inmediato, series de aplicación más amplias (con capacidades específicas para la industria más allá del ERP central y en una base de un solo código) en una sola plataforma, mientras que la base del usuario se ha expandido en todas las formas de vida en una empresa extendida (incluyendo a los trabajadores operacionales dentro de los departamentos de ventas, distribución, servicio de campo y desarrollo del producto).

Los servidores de aplicación llevan a una arquitectura orientada al servicio

Los habilitadores cruciales para estos rasgos fueron los servidores de aplicación, que constan del software de sistema utilizado para hospedar el nivel de la lógica comercial de las aplicaciones (por ejemplo, en aplicaciones cliente/servidor de tres niveles, el servidor de aplicación maneja la lógica comercial y permite el acceso a esta desde el nivel de UI). Estos son programas que manejan todas las operaciones de aplicación entre los usuarios y las aplicaciones comerciales o bases de datos de una empresa usuaria. Los servidores de aplicación por lo general se utilizan para aplicaciones basadas en transacciones complejas, y para soportar algunas necesidades, cualquier servidor de aplicación tiene que tener una redundancia integrada, monitores de gran disponibilidad, servicios de aplicación de alto rendimiento y soporte para el acceso a bases de datos complejas.

Además, una vez que se explotó la Web a mediados de los años 90, los servidores de aplicación se basaron en la Web, y el término servidor (aplicación) Web con frecuencia se refiere a un software en un ambiente de Intranet o Internet que hospeda una gran variedad de sistemas de lenguaje utilizados para programar preguntas de base de datos o procesamientos comerciales generales. Estos textos y servicios, como JavaScript o DHTML, Java server pages (JSPs) o Microsoft Active Server Pages (ASPs), por lo general accesan una base de datos para recuperar datos actualizados que se les presenta a los usuarios por medio de sus navegadores o aplicaciones de cliente.

Por lo tanto existe una sobreposición entre el servidor de aplicación y un servidor Web, ya que ambos pueden realizar tareas similares. El servidor Web (también conocido como servidor http) puede invocar una variedad de textos y servicios para bases de datos y llevar a cabo procedimientos comerciales, mientras que los servidores de aplicación con frecuencia vienen con su propio servidor HTTP, que muestra páginas Web en el navegador. El servidor de aplicación puede estar en la misma computadora que el servidor Web o estar en una computadora separada, mientras que en sitio más grandes, múltiples computadoras se utilizan tanto para servidores de aplicación y servidores Web. Algunos ejemplos de servidores de aplicación Web basados en J2EE son BEA Weblogic Enterprise, Sun Java System Application Server (antes Sun ONE Application Server), Borland AppServer, y el WebSphere Application Server de IBM, mientras que los vendedores más grandes de ERP como SAP y Oracle también tienen su propia versión de servidores de aplicación (consulte, ¿La infraestructura y las aplicaciones por SOA son la próxima frontera?). Se debe mencionar la plataforma Microsoft.NET como una alternativa para las contrapartes basadas en J2EE, consulte Understand J2EE and .NET Environments Before You Choose.

De hecho, varios negocios se embarcaron en un camino a la arquitectura orientada al servicio (SOA) y servicios Web hace algunos años cuando hicieron sus primeras inversiones en tecnologías software basadas en componentes y en especial, en servidores de aplicación. SOA (que con frecuencia se iguala a los servicios Web, aunque estas dos nociones no deben ser utilizadas indistintamente) es un término para una interfase estandarizada entre el software que permite que un programa utilice los componentes funcionales (servicios) de otro programa. Anteriormente llamada arquitectura de objetos distribuidos, el término SOA se acuñó en el cambio de siglo cuando los servicios Web y los estándares de Internet estaban en evolución (como se mencionó anteriormente, la arquitectura de corredor de solicitudes de objetos comunes [CORBA] y el modelo de objetos comunes distribuidos[DCOM] son ejemplos de las SOAs anteriores).

Gartner define SOA como “una topología de aplicación en la que la lógica comercial de la aplicación se organiza en módulos (servicios) con una identidad clara, un propósito específico e interfases de acceso programático. Los servicios se comportan como “cajas negras”: Su diseño interno es independiente de la naturaleza y propósito del solicitante. En SOA, los datos y la lógica comercial se encapsulan en componentes comerciales modulares con interfases documentadas. Esto clarifica el diseño y facilita un mayor desarrollo y futuras extensiones. Una aplicación SOA también se puede integrar con un legado externo, heterogéneo de aplicaciones compradas más fácilmente que con una aplicación monolítica que no sea SOA.

La Organización para el adelanto de los estándares estructurados de información (OASIS) grupo del modelo de referencia SOA define SOA como “un paradigma para organizar y utilizar capacidades distribuidas que pueden estar bajo el control de distintos dominios de propiedad. Proporciona una forma uniforme de ofrecer, descubrir, interactuar y utilizar las capacidades para producir los efectos deseados con las precondiciones que se pueden medir y las expectativas".

Es decir, que SOA identifica todas las funciones o servicios utilizando un lenguaje descriptivo con interfases que realizan procesos comerciales, donde cada interacción es independiente de otras interacciones y los protocolos interconectados de los dispositivos de comunicación. Debido a que las interfases son independientes de las plataformas, un cliente debe ser capaz de utilizar el servicio desde cualquier dispositivo utilizando cualquier sistema operativo (OS) en cualquier lenguaje de programación. SOA soporta actividades de integración y consolidación dentro de sistemas empresariales heterogéneos, pero no especifica o proporciona una metodología o marco de trabajo para la documentación de capacidades o servicios. El concepto debe, en teoría, ser capaz de ayudar a los negocios a responder más rápido y con un costo efectivo a las condiciones cambiantes del mercado al reconfigurar los procesos comerciales. Permite la agilidad, flexibilidad, visibilidad, colaboración con socios comerciales (y entre departamentos IT y funcionales) etc., al promover la reutilización a nivel del servicio en lugar de a nivel de los objetos, por lo tanto se desvía del modelo de programación orientada a objetos (OO), que une los datos y los procesamientos. Además, SOA (en teoría) debe simplificar la interconexión y el uso de activos IT existentes incluyendo el legado de activos, incluso dando un nuevo alquiler de vida (si no es que un completo rejuvenecimiento) a las unidades de programa.

Sin embargo, además de madurar (y algunas veces conflictuar) los estándares comúnmente aceptados, los retos que enfrenta la implementación SOA incluyen el manejar servicios de metadatos y proporcionar los niveles adecuados de seguridad. Dirigir y suministrar información en la interacción de servicios puede ser complicado, ya que la arquitectura depende de mensajes múltiples complejos que abren la puerta a un código de comunicación, además del potencial incumplimiento de las regulaciones gubernamentales. La flexibilidad de SOA posee amenazas de seguridad ya que estas aplicaciones abarcan servicios, especialmente aquellas barreras informáticas externas, y son más visibles para las partes externas que las aplicaciones tradicionales, por lo que el negocio debe establecer políticas para proteger y ver quién puede ver exactamente qué información.

También pueden surgir problemas cuando los usuarios intentan conectarse a servicios que no se desarrollaron de la misma forma, que es muy probable si esto no se controla dentro del ecosistema de un vendedor. Aunque una de los principales objetivos de SOA es eliminar los enlaces de punto a punto, y reemplazarlos con enlaces genéricos centrados en las funciones y los procesos comerciales, para lograr estos nuevos componentes como la orquesta o el flujo de trabajo, tendrán que añadirse traductores de comunicación y localizadores de servicio a la ya compleja arquitectura.

No es necesario mencionar que todos los vendedores están buscando formas de dirigir estos retos. Aunque podemos encontrar más definiciones y explicaciones para SOA en Understanding SOA, Web Services, BPM, BPEL, and More, el hecho es que el siguiente paso evolutivo de la arquitectura de software empresarial o aplicaciones compuestas utiliza servicios comunes y constantes (componentes de software) de repositorios y (re) creación de procesos comerciales omnipresentes y plataformas específicas de la industria conforme sea necesario.

 
comments powered by Disqus

Búsquedas recientes:
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Others