1. Introducción
Hoy en día, todas las empresas buscan formas de mejorar su eficiencia de producción y también están explorando activamente la reorganización de los activos de TI. Las organizaciones de TI han logrado algunos avances para superar estos problemas con la ayuda de tecnologías de arquitectura orientada a servicios (SOA); sin embargo, en la mayoría de los casos sólo se implementa una pequeña parte de toda la cartera de servicios de TI; Actualmente, la mayoría de los esfuerzos en esta área simplemente están logrando un estado "suficiente" de adopción de SOA: mejorar la capacidad de crear aplicaciones e integrarlas con el mercado más rápido, mejor y más barato. Y como hemos aprendido, lograr estos objetivos es más fácil de decir que de hacer.
2. Aplicaciones compuestas tradicionales basadas en middleware
El hecho actual es que SOA es un tipo de middleware y, en los casos tradicionales, el middleware a menudo depende de más middleware para traducir los datos a un estado amigable para el consumidor. Cuando finalmente te das cuenta de que crear una aplicación compuesta que incorpore tecnología SOA no sólo requiere el uso de un portal (middleware) sino que también puede requerir el uso de un motor BPEL (o incluso middleware) para orquestarla, esto por supuesto hace que estés muy decepcionado. Peor aún, podría trabajar dentro de una organización que publica registros UDDI y registra numerosos servicios web. Desafortunadamente, en la mayoría de los casos, hay muy pocas aplicaciones que realmente consuman estos servicios. ¿Cómo podría ser este el caso?
¿La incapacidad de crear aplicaciones que consuman estos servicios SOA debería llevarnos a concluir que algo anda mal? ¿Se debe a que es demasiado difícil para los desarrolladores de contenidos empresariales crear aplicaciones que consuman directamente servicios SOA? ¿Dependemos de otras organizaciones de TI para crear dichas aplicaciones para nosotros? ¿Nos está frenando la falta de una estructura de gobernanza SOA? Creo que la respuesta a todo lo anterior es "sí". Y hay una razón muy importante: es demasiado difícil para los desarrolladores de negocios consumir y utilizar dichos servicios SOA expuestos por la organización de TI. De hecho, el verdadero problema es la falta de una manera fácil de agregar una interfaz SOA. ésta es la ventaja de combinar la tecnología AJAX con SOA.
Normalmente, un servicio SOA se implementa como un servicio web débilmente acoplado que encapsula y expone la funcionalidad empresarial. Esto puede parecer muy sencillo, pero es muy complejo y difícil de implementar. Los desarrolladores a menudo debaten sobre la granularidad del desarrollo de los servicios SOA; sin embargo, la mayoría de los desarrolladores ahora están de acuerdo en que la granularidad del desarrollo "a nivel empresarial" es la más apropiada. Sin embargo, esto todavía requiere que una gran cantidad de expertos en dominios relevantes se unan y trabajen con contenido empresarial para finalizar el tamaño de estos servicios.
3. El renacimiento de SOA
Afortunadamente, recientemente la gente se ha interesado profundamente en SOA. Tal vez las empresas finalmente se estén dando cuenta de que SOA realmente puede ayudarlas enormemente. Quizás esto se deba a mejores herramientas de desarrollo y servicios web promovidos por Amazon, Yahoo y eBay. ¿Quizás sea AJAX? Sí, por eso estoy escribiendo este artículo. En serio, creo que AJAX se ha convertido en una fuerza impulsora importante para renovar la comprensión de la gente sobre SOA, especialmente en los campos de aplicación híbridos actuales de varias tecnologías nuevas. Sin embargo, ¿cómo deberían combinarse y conectarse estas dos tecnologías tan diferentes para liberar un mayor poder? Primero echemos un vistazo a la definición de Wikipedia de la tecnología AJAX actual. Se trata de páginas web, pero SOA no se menciona en absoluto. La descripción es:
"AJAX, que significa 'JavaScript asincrónico + XML', es una tecnología de desarrollo web para crear aplicaciones web interactivas. Su propósito es facilitar la página web front-end intercambiando una pequeña cantidad de datos con el servidor. en segundo plano. Se siente más receptivo; por lo tanto, cada vez que un usuario realiza un cambio, no es necesario recargar toda la página web. El objetivo final es mejorar aún más la interactividad, la capacidad de respuesta y la usabilidad de la página web.
SOA no se menciona en esta definición. No es sorprendente, ya que las primeras aplicaciones AJAX se centraban en mejorar la funcionalidad y usabilidad de las páginas. Esto se ha demostrado en numerosas aplicaciones como Google Maps, Flickr y Yahoo Mail. Sin embargo, no son estas aplicaciones orientadas al consumidor las que me entusiasman con el potencial de AJAX, son las aplicaciones empresariales que se ejecutan detrás del firewall de una empresa las que realmente aprovechan lo bueno de AJAX, porque nos muestra dos características clave: una es un cliente. -Un lado del modelo de programación y el otro es una implementación sencilla de llamadas asincrónicas al servidor. Estas dos capacidades clave (la capacidad de aplicar lógica en el cliente (navegador) y la capacidad de acceder a los datos del servidor sin interrumpir la página web) abren la puerta a la creación de aplicaciones empresariales Web 2.0 nuevas y más ricas, con tantas áreas de aplicación posibles del programa. .
Anteriormente mencioné que SOA carece de una interfaz. Aquí es donde entra en juego AJAX: añade un aspecto decente a SOA. Aquí, permítanme explicarles un poco más. También podríamos pensar en lo que sucedería si los servicios SOA aparecieran en línea. Estos servicios generalmente deben registrarse en un registro o almacén (si tenemos suerte) y luego pueden usarse para el consumo. Por ejemplo, echemos un vistazo a lo que está disponible en el sitio web de StrikeIron ( www.StrikeIron.com ). StrikeIron ha creado con éxito un "mercado de servicios web" para el público en general. A primera vista, el mecanismo de directorio de StrikeIron se parece mucho a una lista proporcionada en una aplicación para pequeñas empresas. Pero más adelante se dará cuenta de que no se trata sólo de aplicaciones: en realidad son servicios web. El concepto de una única empresa que proporcione servicios web WSDL/REST a una amplia gama de consumidores tiene muchas implicaciones. Pero por ahora, echemos un vistazo a lo que vende esta empresa. Según la información proporcionada por StrikeIron (que proporciona acceso a estos servicios), los servicios web más populares que ofrece incluyen:
· Verificación de direcciones en EE. UU.
· Servicio de SMS global
· Impuesto sobre ventas y uso
· Verificación de correo electrónico
· Búsqueda inversa de teléfonos
Nada Sin duda, todos Estos servicios web son bastante útiles y se pueden utilizar en muchas áreas diferentes. Pero al mismo tiempo son demasiado "comerciales". En otras palabras, puede que no me importe quién proporciona estos servicios, sino que sólo quiero obtener la información que deseo. Por otro lado, ¿simplemente utilizaría algún servicio web para transferir efectivo desde mi cuenta corriente a mi cuenta de ahorros? Primero necesito generar confianza en este servicio, por lo que debo establecer una cierta relación con el proveedor que lo brinda. Este "círculo de confianza" que existe entre yo (el consumidor) y el proveedor de servicios también representa la relación dentro de la empresa y sus socios.
4. Combinación de tecnología AJAX + SOA
Las empresas también pueden adoptar el mismo método anterior para proporcionar sus servicios web a una base de usuarios más amplia. A través de un mercado de servicios web, las empresas pueden registrar varios servicios web, y estos servicios web normalmente sólo están disponibles dentro de la empresa o para sus socios. Los proveedores del mercado obviamente quieren que esto suceda, pero lo más importante es que vemos una oportunidad de aplicar la tecnología AJAX+SOA para impulsar una nueva clase de aplicaciones empresariales Web 2.0.
Por primera vez, la gente empezó a sentir que el desarrollo de aplicaciones y SOA finalmente se estaban uniendo. Disponemos de una funcionalidad empresarial descrita en un formato reutilizable: un servicio SOA. Tenemos una conectividad ubicua: la Web. Tenemos navegadores que están demostrando ser los nuevos contenedores de aplicaciones. Disponemos de un modelo de programación en este tipo de contenedor/navegador de aplicaciones: JavaScript. ¡Y todos usan estándares abiertos! ¿Qué más pedimos? De hecho, hay otras cosas.
En particular, me gustaría ver una forma más rápida de desarrollar aplicaciones basadas en todas las tecnologías anteriores: una forma de crear aplicaciones sin tener que depender de middleware integrado con servicios SOA. Esto es exactamente lo que quiero que sea capaz de hacer una aplicación web: "conexión directa a SOA". Esta "conexión directa a SOA" debería poder superar las barreras de los portales tradicionales y los motores de procesos pesados para acceder directamente (al menos conceptualmente; aprenderemos más sobre esto más adelante) a los servicios SOA. Con esto, no me refiero sólo a servicios web, también podrían ser servicios de orquestación BPEL, servicios POJO de grano grueso, canales RSS o cualquier otra cosa que pueda exponerse como un "servicio". Por supuesto, las interfaces deben exponerse utilizando estándares abiertos.
Este nuevo modelo de desarrollo y tiempo de ejecución crea una nueva forma de crear aplicaciones compuestas basadas en aplicaciones. Tiene el atractivo de un tipo cliente/servidor sin el pesado equipaje de los tradicionales clientes/servidores. Se ejecuta en el lado del navegador y se puede implementar según requisitos específicos.
5. Aplicaciones compuestas basadas en el usuario
En los últimos años, todos hemos oído hablar del concepto de "aplicaciones compuestas". Sin embargo, la mayoría de los proveedores han estado hablando de "servicios compuestos", como una forma de reestructurar sus servicios de host en otros servicios o aplicaciones de portal más útiles. Permítanme hacer una analogía para explicar más.
AcmeGrid, nuestro proveedor ficticio de computación grid en este artículo, proporciona un servicio (computación grid) que permite que sus aplicaciones se ejecuten como un servicio. Los clientes de la empresa le dijeron que querían una forma de combinar muchos servicios en un servicio generalizado. Entonces, naturalmente, AcmeGrid lanzó un AcmeGrid Composite Application Builder (CAB) basado en Eclipse. Curiosamente, CAB se parece mucho a un diseñador BPEL, pero está más estrechamente integrado con los servicios publicados por AcmeGrid. Aunque es muy bonita, no es una aplicación real, en el mejor de los casos es sólo un servicio. En esencia, CAB se parece más a un creador de servicios. Pero, ¿quién necesita un creador de servicios cuando intentamos crear aplicaciones? Pronto, otro proveedor ficticio, llamémoslo AcmePortal, anunció su Portal Composite Application Builder (PCAB). También viene con un diseñador basado en Eclipse; aunque también se ve y se siente como un diseñador BPEL, este programa "sabe" cómo construir portales. En muchos casos, un portal funciona tan bien como una aplicación. Sin embargo, si insistes en convertir un portal en una aplicación, será en vano.
De hecho, realmente quiero implementar una aplicación compuesta basada en el usuario en lugar de una aplicación compuesta basada en middleware. Para hacer esto, necesitaba una plataforma de desarrollo y ejecución que no sólo pudiera usar AJAX y SOA, sino también administrar ambos. Algunos proveedores han llevado el concepto de aplicaciones AJAX un paso más allá: llaman a servicios web basados en WSDL directamente desde el navegador, lo que es esencialmente una llamada SOAP. Este enfoque incluso tiene un nombre: "Cliente/SOA". Esto puede estar bien para aplicaciones simples no empresariales o de consumo, pero no para programas empresariales reales. ¿Por qué? Porque cuando llama a un servicio web directamente desde el navegador, la función de supervisión equivale a ser entregada al navegador, lo que simplemente significa que no hay ningún problema de supervisión. La Figura 1 muestra el diagrama de bloques del consumo de servicios web no supervisados. Nunca he conocido una empresa que no controle sus servicios y no creo que las empresas permitan que esto suceda sólo porque somos técnicamente muy eficientes en ello. Si no me cree, recuerde que las empresas nunca abren sus firewalls a aplicaciones que no sean HTTP y SSL. Por mucho que persuadamos a los administradores del sistema, no abrirán otros puertos.
6. Necesitamos un nuevo tipo de plataforma
Como se puede ver en lo anterior, lo que estamos discutiendo no se trata solo de tecnologías AJAX y SOA. De hecho, lo que realmente necesitamos es una plataforma que pueda proporcionar las capacidades de supervisión necesarias para que AJAX y SOA coexistan en la empresa. Esta plataforma también brinda la capacidad de consumir servicios SOA desde la perspectiva del cliente y también puede monitorear el consumo de servicios. La Figura 2 muestra cómo se pueden administrar los servicios web a través de una puerta de enlace de servicios. Una puerta de enlace de servicio es en realidad una abstracción del lado del servidor que monitorea y regula el acceso al servicio en nombre del cliente, que en el caso que acabamos de comentar es una aplicación AJAX basada en navegador. Lo bueno de utilizar una puerta de enlace de servicios es que no está restringido a acceder únicamente a los servicios que se ejecutan dentro de la empresa. Esta puerta de enlace de servicios puede supervisar cualquier servicio registrado dentro de la empresa. En un servicio web basado en WSDL, la empresa registrará el WSDL y el WSDL proporciona enlace al servicio en tiempo de ejecución. Este podría ser un servicio que se ejecuta en el centro de datos de una empresa, pero también podría ser un servicio que se ejecuta en el centro de datos de una asociación. Si una empresa permite (mediante regulación) que las aplicaciones accedan a los servicios, no importa dónde se estén ejecutando esos servicios.
7. Conclusión
Después de leer este artículo, espero que haya comenzado a apreciar el poder de unir AJAX y SOA, especialmente cómo los dos pueden coexistir y habilitar nuevos tipos de aplicaciones basadas en Web con las capacidades regulatorias requeridas por la aplicación de servicio empresarial. . Creo firmemente que estamos en vísperas de una nueva era de oportunidades asombrosas. En la era de la Web 2.0, las redes sociales, el intercambio de imágenes y diversas tecnologías de anotación son excelentes, pero lo que realmente influye es la respuesta de la Web 2.0 a las empresas.