ES2362573T3 - Método y aparato para la creación de una interfaz de usuario para aplicación compuesta. - Google Patents

Método y aparato para la creación de una interfaz de usuario para aplicación compuesta. Download PDF

Info

Publication number
ES2362573T3
ES2362573T3 ES04707569T ES04707569T ES2362573T3 ES 2362573 T3 ES2362573 T3 ES 2362573T3 ES 04707569 T ES04707569 T ES 04707569T ES 04707569 T ES04707569 T ES 04707569T ES 2362573 T3 ES2362573 T3 ES 2362573T3
Authority
ES
Spain
Prior art keywords
user interface
entity
data
class
composite
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
ES04707569T
Other languages
English (en)
Inventor
Edwin Wilhelmus Petrus Van Der Sanden
Matthew Rhys Madoc Stephens
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Corizon Ltd
Original Assignee
Corizon Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Corizon Ltd filed Critical Corizon Ltd
Application granted granted Critical
Publication of ES2362573T3 publication Critical patent/ES2362573T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/451—Execution arrangements for user interfaces
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0481—Interaction techniques based on graphical user interfaces [GUI] based on specific properties of the displayed interaction object or a metaphor-based environment, e.g. interaction with desktop elements like windows or icons, or assisted by a cursor's changing behaviour or appearance

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Communication Control (AREA)
  • Paper (AREA)

Abstract

Un método de configuración de un servidor (13) para proporcionar al menos una interfaz del usuario compuesta (5, 6) a una pluralidad de aplicaciones fuente, en que cada aplicación fuente proporciona una interfaz del usuario respectiva, y la interfaz del usuario compuesta comprende una pluralidad de elementos de interfaz del usuario proporcionados por dicha pluralidad de aplicaciones fuente; el método incluye el procesamiento de un modelo (252) que representa a dicha interfaz del usuario compuesta que genera reglas para la comunicación entre dicha interfaz del usuario compuesta (5, 6) y dicha pluralidad de aplicaciones fuente; en el que dicho modelo (252) comprende un modelo de al menos parte de una interfaz del usuario (1, 2, 3) proporcionada por cada aplicación fuente y un modelo de relaciones entre al menos parte de la interfaz del usuario proporcionada por cada aplicación fuente y la interfaz del usuario compuesta (5, 6).

Description

El presente invento trata de métodos y sistemas para modelar y crear interfaces de usuario para aplicaciones compuestas y con métodos para controlar y afectar el uso de dichas interfaces de usuario para aplicaciones compuestas.
Los usuarios informáticos habitualmente necesitan utilizar una pluralidad de diferentes aplicaciones para realizar las tareas asignadas, y cada aplicación generalmente tiene una interfaz de usuario diferente. Tener que cambiar entre las diferentes interfaces de usuario de las diferentes aplicaciones para completar una tarea asignada degrada considerablemente la eficiencia del usuario. Es frecuente que las diferentes aplicaciones sean suministradas por diferentes proveedores y en consecuencia, sus interfaces de usuario tienen un aspecto y sensación diferentes entre ellas, degradando aún más la eficiencia del operador.
Por ejemplo, para procesar las consultas de los clientes, es posible que los operadores en un centro de atención telefónica deban tener acceso a la aplicación de administración de clientes para acceder a los detalles del cliente, a una aplicación de facturación para acceder a información sobre la cuenta del cliente, y a una aplicación de pagos para procesar un pago que el cliente puede hacer por teléfono, por ejemplo utilizando una tarjeta de crédito. Trabajar de esta manera es ineficiente, dado que el operador debe cambiar de una aplicación a la otra para realizar ciertas tareas. Por otra parte, un cliente generalmente esperará al teléfono mientras el operador utiliza estas diferentes aplicaciones, y por lo tanto es ventajoso acelerar el proceso de consultas para poder ofrecer atención al cliente de mayor calidad.
Se han hecho varias propuestas para mejorar la eficiencia cuando es necesario utilizar aplicaciones múltiples.
Las aplicaciones múltiples pueden ser combinadas en un único producto o un paquete de productos. A pesar de que dicha propuesta aumenta notablemente la eficiencia del usuario, su implementación es difícil y costosa. Es más, dicho producto combinado o paquete de productos generalmente tendrá una interfaz de usuario diferente a la de los previamente utilizados, lo que significa que los usuarios deber ser entrenados para el uso del producto combinado, aumentando aún más el coste.
Como alternativa, se ha propuesto que la aplicación múltiple se combine de alguna manera. Por ejemplo, que todas las peticiones puedan ser enviadas a una única de las aplicaciones, y que esta aplicación pueda ser adaptada para reenviar las peticiones a una aplicación fuente apropiada. Dicha solución generalmente requiere una sustancial personalización si tiene que funcionar en todas las circunstancias que pueden surgir normalmente, lo que hace difícil implementar dicha solución.
US2003/007917 da a conocer un integrador, una pluralidad de adaptadores que corresponden a una pluralidad de aplicaciones y un proxy empleado para disponer de las aplicaciones como una aplicación compuesta.
Un propósito de este invento es evitar o mitigar al menos algunos de los problemas señalados anteriormente.
Según un aspecto del presente invento, se ofrece un método y un aparato para generar información modelo que representa un modelo de una interfaz de usuario compuesta. La interfaz de usuario compuesta comprenden una pluralidad de elementos de interfaz de usuario suministrados por al menos una aplicación fuente. El método incluye un modelado de por lo menos parte de una interfaz de usuario proporcionada por la aplicación fuente (o por cada una de ellas) y relaciones de modelado entre por al menos parte de las interfaces de usuario suministradas por la aplicación fuente.
Un modelo de interfaz de usuario creado de esta manera puede utilizarse por sí solo para analizar la interfaz de usuario compuesta, o puede ser procesada para crear una interfaz compuesta, la cual puede ser usada para comunicación con al menos una aplicación fuente.
El modelo puede ser creado de muchas maneras diferentes, sin embargo, en algunas de las realizaciones de la invención, la aplicación fuente se modela definiendo una multitud de elementos de flujo de datos fuente, cada uno incluyendo una página de interfaz de usuario fuente específica provista por al menos una aplicación fuente, y se definen relaciones entre estos elementos de flujo de datos fuente. Una página de la interfaz fuente puede ser un documento HTML. Modelar una aplicación fuente de esta manera es ventajoso, dado que cada elemento de flujo de datos fuente necesita solamente modelar una única página de interfaz de usuario fuente, y puede además incluir una pluralidad de otras páginas de interfaz de usuarios anónimos que no están modelados explícitamente, sino que son manejados por una aplicación fuente adecuada. Un primer elemento de flujo de datos fuente puede ser usado para representar una aplicación fuente completa. Otros elementos de flujo de datos pueden entonces representar solamente partes de la aplicación fuente que son relevantes para modelar una aplicación compuesta.
Cabe señalar que las realizaciones del invento pueden permitir la manipulación de páginas anónimas de interfaz de usuarios. Por ejemplo, un elemento de flujo de datos fuente puede incluir una sola página de interfaz fuente identificada, y una pluralidad de páginas anónimas de interfaz de usuarios. Todas las páginas (tanto identificadas como anónimas) pueden entonces, por ejemplo, caber en una página HTML de plantilla común, o tener un botón de salida agregado en una ubicación predeterminada. Así, las aplicaciones compuestas pueden ser modeladas y creadas con la inclusión de páginas fuente anónimas, las cuales se manipulan de una manera predeterminada, sin conocimiento del contenido o el formato de las páginas fuente anónimas. Esto puede reducir el número de páginas de interfaz fuente que sea necesario modelar.
imagen1
Cuando se modelan elementos de flujo de datos fuente que incluyen una página de interfaz fuente, el modelo puede contener datos que indiquen una o más reglas de reconocimiento para una página de interfaz fuente. Dichas reglas pueden ser especificadas utilizando una expresión regular, utilizando datos de la ruta tales como XPath, o algún otro modo adecuado. Por ejemplo, si una página fuente es un documento HTML, los datos de ruta pueden especificar una serie de etiquetas de HTML que deberían usarse para identificar la página de la interfaz fuente.
La interfaz de usuario compuesta puede contener al menos una página compuesta creada de una combinación de elementos de interfaz fuente provistos por una o más aplicaciones fuente. El modelo puede especificar las manipulaciones para aplicar a estos elementos de interfaz fuente, y una secuencia ordenada de manipulaciones puede ser definida, la cual puede usarse para crear la página compuesta.
Se ofrece preferentemente una GUI (interfaz gráfica de usuario) para permitir especificar y editar los datos del modelo. Los datos del modelo se representan preferentemente orientados a objetos creando objetos que son instancias de clases apropiadas definidas en un lenguaje de programación orientada a objetos como puede ser Java o C++.
Los modelos creados tal como se describió anteriormente pueden ser procesados para crear datos de configuración. Por ejemplo, se puede crea una estructura de datos jerárquica que incluya una pluralidad de entidades, y dicha estructura de datos jerárquica puede ser utilizada para representar la aplicación compuesta. La estructura de datos jerárquica puede ser creada utilizando varios escritores, cada uno de ellos asociados por una entidad particular dentro de dicha estructura de datos jerárquica. Cada escritor se representa preferentemente por un objeto escritor que es una instancia de una clase de escritor correspondiente definida en un lenguaje de programación orientada a objetos como Java o C++. Los objetos escritores se registran con un mecanismo de consulta de escritor. Cuando un modelo o una parte de un modelo debe ser escrito en dicha estructura de datos jerárquica, un proceso denominado publicación, la parte correspondiente al modelo se suministra al mecanismo de consulta, el cual determina entonces invocar a uno o más escritores para escribir los datos apropiados en las entidades correspondientes dentro de la estructura de datos jerárquica. Una ubicación dentro de la estructura de datos jerárquica en la cual deberían escribirse los datos puede ser determinada recurriendo a un escritor configurado para crear o encontrar una entidad apropiada dentro la estructura de datos jerárquica. En algunos casos, un escritor puede decidir que para publicar la parte especificada de un modelo haya que publicar también otras partes del modelo, y hacer que ocurra la publicación adecuada.
Según otro aspecto, la invención ofrece un método y un aparato para suministrar una interfaz de usuario compuesta que incluya una diversidad de elementos de interfaz de usuario suministrado por al menos una aplicación fuente. El método comprende el control de la operación de la interfaz de usuario compuesta para obtener datos de administración.
De esta manera, la invención permite a los administradores controlar el uso para obtener diferentes datos de administración, los cuales pueden ser utilizados, por a, para modificar la interfaz de usuario compuesta. Por ejemplo, si se determina que los tiempos de respuesta son relativamente lentos considerando el alto nivel relativo de las demandas, la modificación puede eliminar de dicha interfaz compuesta de usuario algunos de los elementos que no son esenciales para ofrecer la información esencial en un plazo más aceptable.
Según a otro aspecto más, la invención ofrece un método y un sistema para generar una interfaz de usuario compuesta que comprende una pluralidad de elementos de interfaz de usuario ofrecidos al menos por una aplicación fuente. El método incluye seleccionar dicha interfaz compuesta entre una variedad de interfaces de usuario compuestas predefinidas a partir de un parámetro predefinido por lo menos.
Así, la invención permite crear y almacenar una pluralidad de interfaces de usuarios, cada una de las cuales puede ser utilizada para desempeñar la misma función. La interfaz de usuario puede ser seleccionada usando una amplia gama de parámetros predefinidos. Por ejemplo, puede determinarse que los usuarios necesitan información un poco diferente dependiendo de la fecha u hora actual, y en dichos casos, el método y el sistema pueden seleccionar automáticamente la interfaz más adecuada utilizando los datos de hora o fecha.
En otras realizaciones, una primera interfaz de usuario puede suministrar una cantidad de información relativamente grande, mientras que una segunda suministra una cantidad menor. La primera interfaz de usuario puede entonces ser usada cuando el uso del sistema es relativamente bajo, y la segunda cuando el uso del sistema es relativamente elevado.
En algunas realizaciones, los elementos de la interfaz de usuario dentro de cada interfaz de usuario compuesta
imagen2
pueden considerarse obligatorios o no obligatorios, y la interfaz de usuario compuesta se produce cuando todos los elementos de la interfaz de usuario han sido recibidos desde las correspondientes aplicaciones fuente. La pluralidad de interfaces de usuario compuestas pueden comprender los mimos elementos de la interfaz de usuario, pero con diferentes elementos de la interfaz de usuario obligatorios. Así, una interfaz de usuario compuesta que tenga una gran cantidad de datos obligatorios puede ser utilizada en condiciones de bajo uso, y una interfaz de usuario compuesta que tenga una menor cantidad de datos obligatorios puede ser utilizada en condiciones de uso elevado.
A continuación se describirán las realizaciones de la presente invención, a través de ejemplos, haciendo
referencia a los dibujos que las acompañan, en los que: La figura 1 es una visión general esquemática de un sistema para la creación de aplicaciones compuestas según la presente invención;
La figura 2 es una ilustración esquemática que muestra el sistema de la figura 1 con más detalle; La figura 3 es una ilustración esquemática de la gestión del proceso dentro del servidor de la figura 2; La figura 4 es una visión general esquemática de las clases de Java utilizadas para implementar algunas partes
de la arquitectura de la figura 3; Las figuras 4A a 4V son diagramas de clase UML que muestran las clases de la figura 4 con más detalle; La figura 5 es una ilustración esquemática de las clases de Java utilizadas para implementar los nodos ilustrados
en la figura 3; Las figuras 5A a 5J son diagramas de clase UML que muestran las clases de la figura 5 con más detalle; La figura 6 es un diagrama de transición de estados que muestra las transiciones entre las clases de la figura 5
utilizadas para representar información de estados en relación a los nodos;
La figura 7 es una visión esquemática de las clases de Java utilizadas para implementar los servicios ilustrados en la figura 3; Las figuras 7A a 7F son diagramas de clase UML que muestran las clases de la figura 7 con más detalle; La figura 8 es una visión esquemática de las clases de Java utilizadas para implementar los servicios ilustrados
en la figura 3; Las figuras 8A a 8K son diagramas de clase UML que muestran las clases de la figura 8 con más detalle; La figura 9 es una ilustración esquemática que muestra la creación de un proceso dentro de la arquitectura de la
figura 3;
La figura 10 es una ilustración esquemática que muestra la creación de un nodo dentro de uno de los procesos de la figura 3; La figura 11A es una visión esquemática de un proceso de paso de mensajes según la presente invención; La figura 11B es un diagrama de flujo que muestra el proceso de paso de mensajes de la figura 11A con más
detalle;
Las figuras 12A a 12D son ilustraciones esquemáticas que muestran el paso de mensajes de las figuras 11A y 11B con más detalle; La figura 13 es una ilustración esquemática que muestra el paso de mensajes distribuido como se ilustra en las
figuras 12A a 12D; La figura 14 es una ilustración esquemática de la arquitectura lógica del servidor web y el servidor de la figura 2; La figura 15 es una ilustración esquemática que muestra cómo las partes de la arquitectura de la figura 14
cooperan para proveer las interfaces de usuario compuestas; La figura 16 es una tabla que muestra los parámetros de invocación utilizados por el servidor web de la figura 2; La figura 17 es una tabla que muestra los parámetros de invocación utilizados por el servidor de la figura 2; La figura 18 es una tabla que muestra etiquetas de HTML (lenguaje de marcado de hipertexto) que pueden ser
utilizadas en realizaciones de la presente invención; La figura 19 es un extracto del archivo de configuración que ilustra cómo pueden ser inicializados diferentes
imagen3
parámetros;
La figura 20 es un diagrama de árbol que ilustra los datos de configuración para el servidor y el servidor web de la figura 2; La figura 21 es un diagrama de árbol que muestra los datos de configuración pertinentes para los servicios de CL
(capas de comunicación) de la figura 14;
Las figuras 22 y 23 son diagramas de árbol que muestran los datos de configuración pertinente para los servicios de DT (transformación de datos) de la figura 14; Las figuras 24, 25 y 26 son diagramas de árbol que muestran los datos de configuración pertinentes para el
servicio del UXM (administrador de experiencia del usuario) de la figura 14;
La figura 27 es un diagrama de árbol que muestra los datos de configuración pertinentes para el ALF (bloqueo de estructuras de aplicaciones) ilustrado en la figura 14; La figura 28 es un diagrama de árbol que muestra los datos de configuración para el servidor web ilustrado en la
figura 14; La figura 29 muestra datos de configuración para el IDM ilustrado en la figura 14; La figura 30 es una ilustración esquemática que muestra una relación entre un árbol UXM y un árbol UXMObject; La figura 31 es una ilustración esquemática que muestra como un documento HTML puede ser convertido en
una pluralidad de objetos UXM; La figura 32 es una ilustración esquemática de la operación del servicio DT para una aplicación fuente específica. La figura 33 es un fragmento de código HTML que puede ser utilizado para generar un mensaje
IncomingUserRequest;
La figura 34 es una ilustración esquemática de modelación de aplicaciones según una realización de la presente invención; La figura 35 es un diagrama de clase que muestra clases utilizados para modelar aplicaciones fuente en
realizaciones de la presente invención;
La figura 36 es un diagrama de clase que muestra clases utilizadas para modelar una aplicación compuesta en realizaciones de la presente invención; La figura 37A muestra flujo de proceso dentro de dos aplicaciones fuente; La figura 37B muestra una aplicación compuesta construida de la composición de las aplicaciones ilustradas en
la figura 37A;
La figura 38 es una captura de pantalla de un cuadro de diálogo que muestra un modelo de una aplicación compuesta; La figura 39 es una ilustración esquemática de flujos fuente dentro de una aplicación fuente; La figura 40 es una captura de pantalla del cuadro de diálogo de la figura 38 con más detalle; La figura 41 es una captura de pantalla del cuadro de diálogo utilizado para configurar un elemento de flujo
fuente; La figura 42 es una captura de pantalla que muestra el cuadro de diálogo para configurar una página fuente; La figura 43 es una captura de pantalla que muestra parte del cuadro de diálogo de la figura 38 con más detalle; La figura 44 es una captura de pantalla del cuadro de diálogo utilizado para configurar un objeto de conexión; La figura 45 es una captura de pantalla que muestra el cuadro de diálogo utilizado para configurar un objeto de
aplicación fuente; La figura 46 es una captura de pantalla del cuadro de diálogo utilizado para configurar datos de petición; Las figuras 47 y 48 son capturas de pantalla que muestran el cuadro de diálogo de la figura 38 con más detalle; La figura 49 es una captura de pantalla que muestra un cuadro de diálogo utilizado para configurar un nuevo
elemento de flujo dentro de una aplicación compuesta;
imagen4
La figura 50 es una captura de pantalla de un cuadro de diálogo utilizado para configurar una página compuesta;
La figura 51 es una captura de pantalla de un cuadro de diálogo utilizado para solicitar correlaciones de parámetros;
La figura 52 es una captura de pantalla del cuadro de diálogo utilizado para configurar un script de composición;
La figura 53 es una captura de pantalla que muestra parte del cuadro de diálogo de la figura 38 con más detalle;
Las figuras 54 y 55 son capturas de pantalla de un cuadro de diálogo utilizado junto con el cuadro de diálogo de la figura 52;
La figura 56 es un diagrama de clases que muestra las clases utilizadas para publicar un modelo;
La figura 57 es un diagrama secuencial que ilustra la ubicación e instanciación de clases de escritor adecuadas;
La figura 58 es un diagrama secuencial que ilustra la escritura localizando un grupo de datos dentro del IDM; y
La figura 59 es un diagrama secuencial que ilustra la escritura de datos del IDM a un grupo de datos localizados utilizando el proceso de la figura 58, utilizando el objeto de escritura creado utilizando el proceso de la figura 57.
La figura 1 ilustra un sistema para crear aplicaciones compuestas según una realización de la presente invención. Una primera aplicación fuente provee una primera interfaz de usuario 1, una segunda aplicación fuente provee una segunda interfaz de usuario 2, y una tercera aplicación fuente provee una tercera interfaz de usuario 3. Un sistema de composición 4 compone la primera, segunda y tercera interfaz de usuario para formar una primera interfaz de usuario compuesta 5 y una segunda interfaz de usuario compuesta 6. Puede verse que la primera interfaz de usuario compuesta 5 se crea de la composición de la primera, segunda y tercera interfaz de usuario 1, 2, 3, mientras que la segunda interfaz de usuario compuesta 6 se crea de la composición de la segunda y tercera interfaces de usuario 2, 3.
El sistema de composición 4 procesa peticiones de usuarios de las interfaces de usuario compuestas 5, 6 y genera peticiones a las aplicaciones fuente correspondientes. El sistema de composición 4 además recibe información de la primera, segunda y tercera aplicaciones en respuesta a dichas peticiones, y utiliza esta información para generar las interfaces de usuario compuestas 5, 6.
Por ejemplo, las interfaces de usuario 75 pueden incluir un número de páginas, cada una conteniendo elementos de una o más de la primera, segunda y tercera interfaces de usuario 1, 2, 3. Esa es una primera página de la interfaz de usuario puede ser hecha exclusivamente de la primera interfaz de usuario 1, y una segunda página puede ser hecha de la combinación de parte de una segunda interfaz de usuario 2, y parte de la tercera interfaz de usuario 3, y una tercera parte puede incluir parte de la segunda interfaz de usuario 2, reorganizadas por el compositor para ofrecer un aspecto y sensación que sea similar a los de la primera y segunda páginas.
La figura 2 ilustra el sistema de la figura 1 con más detalle. Un usuario visualiza la interfaz de usuario compuesta 5 por medio de un dispositivo de visualización 7 conectado a un PC 8. Del mismo modo, la interfaz de usuario compuesta 6 se muestra a un usuario por medio de un dispositivo de visualización 9 conectado a un PC 10. Los PC 8, 10 tienen medios para conexión a Internet 11. Los PC 8, 10 pueden ser conectados a Internet 11 a través una conexión de red de área local, o de manera alternativa, a través de un módem (que no se muestra).
Un servidor web 12 también está conectado a Internet 11, y almacena una pluralidad de páginas web en formato HTML (lenguaje de marcado de hipertexto) a las que pueden acceder los PC 8, 10. El servidor web está conectado al servidor 13. Esta conexión puede ser una conexión directa 14 (como se muestra en la figura 2), o de manera alternativa, una conexión a través de una red como Internet. El servidor 13 está a la vez conectado a tres servidores 15, 16, 17 los cuales ejecutan respectivamente las aplicaciones primera, segunda y tercera para suministrar a la primera, segunda y tercera interfaces de usuario 1, 2, 3. El servidor 13 también está conectado a la base de datos 18, la cual almacena los datos de configuración.
Cuando está en funcionamiento, el servidor web 12 suministra documentos HTML los cuales forman las interfaces de usuario compuestas 5, 6. Las interfaces de usuario 5, 6 son creadas por procesos ejecutados en el servidor 13, las cuales crean las interfaces de usuario compuestas a partir de la información suministrada por los servidores 15, 16, 17, de acuerdo a los datos de configuración almacenados en la base de datos 18 como se describe a continuación. Los datos introducidos por los usuarios de las interfaces compuestas 5, 6 son recibidos por el servidor web 12 y enviados al servidor 13 a través de la conexión 14. El servidor 13 procesa dichos datos de manera predefinida y envía los datos a los servidores 15, 16, 17 como corresponda.
Se apreciará que en algunas realizaciones de la presente invención, en lugar de conexión por Internet 11, las conexiones correspondientes pueden hacerse a través de la Internet de una organización.
A continuación se describirá el funcionamiento del servidor web 12 y del servidor 13 en la creación y modificación de las interfaces de usuario compuestas 5, 6.
imagen5
El servidor 13 utiliza un framework de procesamiento flexible. La figura 3 ilustra componentes utilizados dentro de este framework de procesamiento flexible.
Un componente HostMasterWatchdog 19 comprueba si un proceso HostMaster 20 ya está siendo ejecutado, y de lo contrario hace que comience un proceso HostMaster. El proceso HostMaster 20 es responsable de crear y eliminar procesos. El proceso HostMaster 20 garantiza que todos los procesos creados están listos y en funcionamiento y además pasa información relevante de configuración a dichos procesos. Cualquier host que funcione de acuerdo a la estructura de procesamiento que aquí se describe ejecuta una sola instancia del componente HostMasterWatchdog 19 y el proceso HostMaster 20.
En la ilustración de la figura 3, un servidor ejecuta un primer proceso 21 y un segundo proceso 22. El primer proceso incluye dos nodos 23, 24, y el segundo incluye dos nodos 25, 26. Los nodos son contenedores para servicios de usuario, y se describen con más detalle a continuación. Cada uno de los procesos 21, 22 incluye un respectivo agente de proceso 27, 28 el cual es responsable de iniciar nodos dentro de sus respectivos procesos y reiniciar nodos dentro de procesos en caso de un fallo. El funcionamiento de nodos dentro de los procesos 22, 23 es administrado por los respectivos componentes de administración de nodos 29, 30.
En realizaciones preferidas de la presente invención, todas las entidades en la estructura ilustradas en la figura 3, excepto el HostMasterWatchdog 19, se implementan como instancias de clases JavaTM, de modo que proveen una implementación orientada a objetos. Los detalles de dicha implementación se describen a continuación. En la siguiente descripción, los componentes de lenguaje de programación tales como clases, objetos, interfaces y métodos tienen el significado habitual dentro del lenguaje de programación Java.
El proceso HostMasterWatchdog 19 comprueba periódicamente el estado del proceso HostMaster 20. Si el proceso HostMasterWatchdog 19 encuentra un proceso HostMaster 20 en estado invalidado, o no encuentra un proceso HostMaster, intenta detener cualquier proceso HostMaster 19 existente y empieza un nuevo proceso HostMaster. Si esto no tiene éxito al principio, se vuelve a intentar repetidamente hasta que un usuario sale del HostMasterWatchdog 19 manualmente. El proceso HostMasterWatchdog 19 está generalmente escrito en un lenguaje de programación convencional de algo nivel como C, y por lo tanto deberá escribirse una implementación de HostMasterWatchdog para cada plataforma diferente en la cual el debe funcionar la estructura. No obstante, en realizaciones preferidas de la invención, los demás componentes se implementan todos como instancias de clases de Java, otorgando portabilidad entre plataformas.
La figura 4 ilustra las clases utilizadas para implementar otras entidades ilustradas en la figura 3. Las clases individuales se ilustran con más detalle en las figuras 4A a 4V.
Además de las entidades ilustradas en la figura 3, cada uno de los procesos 21, 22 mantiene un registro de componentes creando y manteniendo una instancia de una clase DefaultComponentRegistry 31 (figura 4A), la cual implementa una interfaz ComponentRegistry 32 (figura 4B). Este registro permite a los objetos ser añadidos al registro utilizando usando un método registerObject (objeto C) especificado en el interfaz 32 ComponentRegistry. Los objetos agregados al registro pueden ser controlados y administrados utilizando métodos provistos por la clase DefaultComponentRegistry 31, y por lo tanto dichos componentes pueden recibir avisos de cambio de estado en otros componentes en el registro.
Cada una de las entidades ilustradas en la figura 3 está representada por una clase correspondiente que se muestra en la figura 4. El proceso HostMaster está representado por una instancia de una clase HostMaster 33 (figura 4C). El proceso ProcessAgent está representado por una instancia de una clase ProcessAgent 34 (figura 4D), la cual a su vez hace referencia a una instancia de una clase NodeManager 35 (figura 4E) por medio de una variable privada mNodeManager dentro de la clase ProcessAgent 34. La clase NodeManager 35 contiene detalles de nodos individuales. Las clases utilizadas para representar dichos nodos se describirán con más detalle a continuación.
Las instancias correspondientes de HostMaster 33 y ProcessAgent 34 definidas más arriba se registran con una instancia de la clase DefaultComponentRegistry 31. Puede observarse que tanto la clase HostMaster 33 y la clase ProcessAgent 34 implementan una interfaz ComponentAware 36 (figura 4F) Esta especifica un único método getComponentClass() que todas las clases que implementan deben suministrar. Cada clase define este método para localizar la clase apropiada de componente. En el caso de la clase HostMaster 33, una clase HostMasterComponent 37 (figura 4G) es localizada por el método getComponentClass (). En el caso de la clase ProcessAgent 34, el método getComponentClass () localiza la clase ProcessAgentComponent 38 (figura 4H).
Las clases componentes ofrecen un modo conveniente de encapsular información administrativa de manera separada de la funcionalidad. Cuando un objeto implementando la interfaz ComponentAware 36 se registra con la instancia de la clase DefaultComponentRegistry 31, el método getComponentClass() se utiliza para localizar la clase de componente correspondiente, y esta clase de componente es entonces instanciada y registrada con la instancia de DefaultComponentRegistry. Esta clase de componente a su vez enlaza con el objeto respectivo que está siendo registrado.
Cabe señalar que todas las entidades para registrar con el DefaultComponentRegistry no implementarán necesariamente la interfaz ComponentAware 36. Si el objeto DefaultComponentRegistry determina que un objeto que estás siendo registrado no implementa esta interfaz, una instancia de una clase GenericComponent 39 (figura 4I) se utiliza para registrar el objeto con el objeto DefaultComponentRegistry. Esta clase simplemente permite localizar el objeto que se registra, pero no ofrece ninguna función administrativa.
imagen6
La figura 4 ilustra la jerarquía de clases utilizada para representar componentes. El más alto nivel de la jerarquía incluye una interfaz Componente 40 (figura 4J), el cual se implementa por una clase ComponentBase 41 (figura 4K). La clase ComponentBase 41 tiene dos subclases, una clase G2Component 42 (figura 4L) y una clase AdminComponent 43 (figura 4M). La clase AdminComponent 43 actúa como una superclase para tres clases que se utilizan para implementar funciones administrativas. Una clase CascadingAgentComponent 44 (figura 4N) se utiliza para comunicación entre una instancia de clase HostMaster 33 y una instancia de clase ProcessAgent 34. Una clase HTMLAdaptorComponent 45 (figura 40) es utilizada por el HostMasterComponent 37. Un RMIConnectorServerComponent 46 (figura 4P) es utilizado por el ProcessAgentComponent 38 para comunicación por medio de RMI (Remote Method Invocation) como lo prevé el lenguaje de programación Java. La clase G2Component 42 actúa como una superclase para los componentes descritos anteriormente. Específicamente, la clase ServiceComponent 39, la clase ProcessAgentComponent 38 y la clase HostMasterComponent 37 son todas subclases de la clase G2Component 42. Además, la clase G2Component 42 es una superclase para una clase ServiceComponent 47 (figura 4Q), y una clase NodeComponent 48 (figura 4R)
Se ha mencionado anteriormente que una instancia de la clase NodeManager 35 es referenciada por una variable privada en instancias de la clase ProcessAgent 34. Tanto la clase ProcessAgent 34 como la clase NodeManager 35, ambos implementan una interfaz NodeAdmin 49 (figura 4S)
Una cantidad de otras clases también se ilustran en la figura 4. Una clase G2Runtime 50 (figura 4T) se utiliza como una clase maestra durante la ejecución de todas las clases ilustradas en la figura 4. Una clase ComponentAdress 51 (figura 4U) se utiliza para responder a los componentes de la arquitectura de la figura 3. Una excepción de AdminException 52 se utiliza para las excepciones por subclases de la clase AdminComponent 43.
Se utiliza una clase MBeanConfig 53 (figura 4V) para representar la información de configuración de un MBeanTM. Los componentes implementados como subclases de la clase ComponentBase 41 todos heredan una variable privada del tipo Object, la cual representa un MBean utilizado para implementar dicho componente. La clase MbeanConfig 53 representa la configuración de dichos objetos MBean.
Como se describió anteriormente, el proceso HostMaster 20 (figura 3) es representado por un objeto HostMaster y registrado utilizando un objeto HostMasterComponent. El HostMasterComponent permite que el HostMaster sea notificado de la creación o eliminación de ProcessAgent. Esto se describe con más detalle más adelante.
Los procesos de ProcessAgent 27, 28 (figura 3) se representan mediante los respectivos procesos ProcessAgent, que permiten la administración de nodos dentro de dicho proceso a través de los objetos NodeManager apropiados.
Como muestra la figura 3, los procesos contienen nodos, los cuales son administrados por un objeto NodeManager. Los nodos a su vez comprenden uno o más servicios. Un nodo es responsable de los servicios que contiene, y no ofrece directamente ninguna funcionalidad para usuarios. Cada nodo está representado por un objeto adecuado, y la figura 5 muestra una visión general de clases apropiadas. Las clases individuales se muestran con más detalle en las figuras 5A a 5J.
La clase NodeManager 35 instancia y usa una instancia de una clase NodeFactory 54 (figura 5A) la cual crea instancias de una clase MasterNode 55 (figura 5B), y estas instancias se utilizan para representar los nodos 23, 24, 25, 26 (figura 3). Cabe señalar que la clase MasterNode 55 implementa una interfaz de nodo 56 (figura 5C) que especifica los métodos necesarios para implementar la funcionalidad básica. La clase NodeManager instancia instancias de una NodeNotFoundException 35a, cuando se le solicita actuar sobre un objeto MasterNode que desconoce.
Cada objeto MasterNode lleva asociado una o más hilos de enrutamiento que se utilizan para enrutar mensajes dentro del nodo. Estos hilos están representados por una variable privada mRouterThreadPool en la clase MasterNode 55, que es una instancia de una clase (que no se muestra) que implementa un grupo (pool) de interfaces 57 (figura 5D). La clase que implementa la interfaz Pool contiene objetos representados por instancias por una clase RouterThread 58 (figura 5E), que representa los hilos de enrutamiento.
Cada nodo lleva asociado un caché representado por una instancia de una clase ReplicatedCache 59 (figura 5F), que es una subclase de una clase TimeStampedCache 60 (figura 5G), que a su vez implementa una interfaz Cache 61 (figura 5H). El propósito del objeto ReplicatedCache es almacenar información de estado relacionada con cada servicio contenido en ese nodo, y esta información puede ser utilizada para reiniciar los servicios en caso de una caída del sistema. Además, el caché está replicado entre múltiples nodos, de modo que si uno de los nodos falla, el nodo y sus servicios asociados puede reiniciarse utilizando datos de caché desde el nodo que contiene la copia de los datos de caché. La clase ReplicatedCache 59 ofrece métodos para asegurar la sincronización de datos en la copia de caché.
imagen7
Cada nodo también incluye un registro direccionable representado por una instancia de la clase ComponentRegistry 62 (figura 5I). Esta clase permite que servicios dentro de un nodo se registren con el nodo, y también ofrece funciones de consulta que pueden ser utilizadas para localizar servicios presentes dentro del nodo.
Un nodo representado por un objeto MasterNode puede tener un de ocho posibles estados, cada uno de los cuales está representado por una clase correspondiente. La variable privada mState indica un objeto que indica información de este estado. Cada una de las ocho clases que puede ser almacenada en la variable mState implementa la interfaz de nodo 56, la cual especifica métodos relevantes para la transición entre estados.
La información de estados está, de hecho, representada por instancias de clases que son subclases de una clase AbstractNode 63 (figura 5J), la cual implementa ella misma la interfaz de nodo 56.
Una clase CreatedNode 64 representa un nodo que ha sido creado pero no ha sido todavía inicializado. Una clase InitializedNode 65 se utiliza para representar un nodo después de la inicialización. Una clase StoppedNode 66 representa un nodo inicializado que no está siendo ejecutado en este momento. Cuando se inicia un nodo, su estado se representa por una clase StartingNode 67. Una clase RunningNode 68 representa un nodo que ha sido iniciado y está siendo ejecutado. Un nodo que está por cerrarse se representa por una clase StoppingNode 69. Las clases FailedNode 70 y RecoveringNode 71 se usan para representar un fallo de nodo. Cada una de estas clases especifica un método de constructor que toma como único parámetro el MasterObject al que pertenece, y también ofrece cinco métodos especificados en la interfaz de nodo 56 - init(), start(), stop(), destroy(), recover(). Cada estado que representa una clase, ofrece por lo tanto un número de métodos para permitir un cambio de estado. Para cada estado, solamente un único método no lanzará una InvalidStateException cuando le llama.
Las transiciones entre estados representadas por los objetos señalados anteriormente se describen ahora en referencia a la figura 6. Al construir un objeto MasterNode por instanciación del MasterNode 55 por el NodeFactory 54, la variable mState señala una instancia de la clase CreatedNode 64.
El método de llamar al init() provisto en la clase CreatedNote crea una instancia de InitializedNode 65, al que hace referencia el MasterNode para representar el estado. Cuando termina la inicialización, una instancia de la clase StoppedNode 66 es creada por la instancia InitializedNod. El método de llamar al start() provisto por la clase StoppedNode 66 provoca que se cree una instancia de la clase StartingNode 67, a la cual se refiere el MasterNode para representar el estado. La clase StartingNode crea entonces una instancia de la clase RunningNode 68. El único método ofrecido por la clase RunningNote 68 que no lanza el InvalidStateException es el método stop(). Cuando éste se llama, se crea una instancia de la clase StoppingNode 69, y posteriormente otra instancia de la clase StoppedNode 66 se crea para representar el estado.
Si el proceso provoca que se lance una excepción no capturada, se crea una instancia de la clase FailedNote 70. El único método que se puede usar de manera válida es recover(), el cual crea una instancia de la clase RecoveringNode 71, antes de crear una instancia de la clase StoppedNode 66.
Haciendo referencia a la figura 5, puede verse que la clase MasterNode 55 implementa una interfaz NodeStateSource 72 que permite a las instancias de una clase NodeStateListener 73 registrarse como receptores con objetos MasterNode.
La descripción anterior ha tratado sobre la implementación de nodos. Se ha señalado que los nodos contienen servicios, y ahora se describen los correspondientes servicios. Los servicios son administrados por un nodo, y reciben y procesan los mensajes que les son enviados. La jerarquía de clases utilizada para implementar los servicios se describe ahora en relación a la figura 7. Más detalles de las clases mostradas en la figura 7 se muestran en las figuras 7A a 7F.
Cada servicio es implementado como un objeto que es una instancia de una clase BaseService 74 (figura 7A), o como una instancia de una de sus subclases. La clase BaseService 74 implementa una interfaz direccionable 75, que especifica un solo método getAddress. En el caso de la clase BaseService 74, puede verse que la dirección se almacena como una variable privada del tipo ComponentAddress (vea la figura 4).
La clase BaseService 74 implementa además una interfaz HandlerContext 76 (figura 7B), la cual especifica las características que permiten proveer dentro del servicio los controladores de servicios representados por instancias de la clase BaseServiceHandler 77 (figura 7C) para ofrecer funcionalidad. Los controladores reciben mensajes dirigidos a un servicio y actúan en base a esos mensajes. De esta manera, los controladores ofrecen la funcionalidad de un servicio. Cada servicio tendrá una clase controladora predeterminada que suministra controladores, y esta clase será una subclase de la clase BaseServiceHandler 77. Cada servicio puede tener una pluralidad de instancias de la clase controladora, permitiendo así que un servicio procese mensajes de una pluralidad de usuarios al mismo tiempo.
imagen8
Puede verse que la clase BaseServiceHandler 77 implementa una interfaz MessageHandler 78 que permite controlar mensajes de manera unificada, especificando un solo método handleMessage(). La clase BaseServiceHandler 77 también implementa una interfaz ResultListener 79 que especifica un único método deliverResult.
Las instancias de la clase BaseService 74 utilizan instancias de una clase MessageDispatcher 80 (figura 7D) para enviar mensajes dentro y entre los servicios. La clase BaseService 74 y la clase BaseServiceHandler 77 ambas implementa una interfaz MessageRouter 81, que permite enrutamiento de mensajes entre servicios utilizando un método route(). Esta interfaz es usada por la clase MessageDispatcher 80. El enrutamiento de estos mensajes usando estas clases se describe con más detalle a continuación.
Puede verse que la figura 7 ilustra además una clase ServiceFactory 82 (figura 7E) que se usa para crear servicios, y una clase Service State 83 (figura 7F) que se usa para indicar el estado de una instancia de la clase BaseService 74 o una de sus subclases. La figura 7 también ilustra una clase DebugHandler 84, que es un controlador de servicios utilizado con fines de depuración durante el desarrollo.
La figura 8 ilustra una jerarquía de clases utilizadas para implementar mensajes que pueden pasar entre servicios para se controlados por controladores de servicios adecuados. Estas clases se muestran con más detalles en las figuras 8A a 8K.
En referencia a la figura 8, puede verse que la jerarquía utilizada para representar mensajes está encabezada por una interfaz Message 85 (figura 8A), la cual es implementada por una clase abstracta AbstractMessage 86 (figura 8B). Una clase ComandSequenceMessage 87 (figura 8C) extiende la clase AbstractMessage 86. Una instancia de la clase CommandSequenceMessage 87 representa mensajes que deben ser transmitidos entre servicios. La clase CommandSequenceMessage tiene cuatro subclases que representan mensajes usados en realizaciones preferidas de la presente invención. Una clase UserRequest 88 (figura 8D) se utiliza para representar mensajes generados por un usuario. Una clase UserResponse 89 (figura 8E) se utiliza para representar respuestas a mensajes representados por instancias de la clase UserRequest 88. Una clase ApplicationRequest 90 (figura 8F) se utiliza para representar peticiones hechas usando llamadas API (interfaz de programador de aplicación) y una clase ApplicationResponse 91 se utiliza para representar respuestas a mensajes representados por la clase ApplicationRequest 90.
Cada tipo de mensajes descritos anteriormente hereda características fundamentales necesarias para implementar paso de mensajes desde la clase CommandSequenceMessage 87 (figura 8C). Una variable mSequence dentro de la clase CommandSequence Message 87 se refiere a una instancia de una clase CommandSequence 92 (figura 8H). La clase CommandSequence incluye una matriz de pares que comprenden un comando y un destino (que es un servicio al cual se destina el comando). Cada par de comandos destino se representa por una instancia de una clase CommandTargetPair clase 93 (figura 8I). Puede verse que CommandSequence actúa como una superclase para la clase UserRequestCommandSequence 94, una clase UserResponseCommandSequence 95, una clase ApplicationRequestCommandSequence 96 y una clase ApplicationResponseCommandSequence 97. Cada una de estas subclases de la clase CommandSequence 92 representa una secuencia de comandos apropiada para la subclase correspondiente de la clase CommandSequenceMessage 87.
El estado de cualquier mensaje representado por una subclase de la clase AbstractMessage 86 se representa por una variable mState que se refiere a una instancia de una clase MessageState 97 (figura 8J).
La clase CommandSequenceMessage 87 también tiene como subclase una clase SingleCommandMessage 98 (figura 8K) que representa un mensaje que tenga un solo comando y un solo destino. La clase SingleCommandMessage a su vez tiene una clase System Request 99a y una clase ServiceRequest 99b como subclases.
Habiendo descrito las diferentes clases utilizadas para implementar lo que muestra la figura 3, y habiendo también descrito las clases utilizadas para implementar paso de mensajes, el modo en que los componentes de la figura 3 funcionan juntos, y cómo se logra el paso de mensajes se describe ahora en referencia a las figuras 9 a 13. En la siguiente descripción, los objetos se indican por los números de referencia seguidos por un símbolo primo ('). Cuando proceda, se usan los números de referencia asociados con la clase de la cual un objeto es una instancia.
Con referencia primero a la figura 9, se ilustra la creación de ProcessAgents en la arquitectura de la figura 3. Como se describió anteriormente, un proceso HostMasterWatchDog 19 crea un objeto HostMaster 33'. El objeto HostMaster lleva asociado un objeto G2Runtime 50', el cual puede ser utilizado para localizar un objeto DefaultComponentRegistry 31' utilizando un método getComponentRegistry(). El objeto HostMaster 33' se registra entonces dentro del objeto DefaultComponentRegistry 31' lo cual a su vez crea un objeto HostMasterComponent 37'.
El HostMaster utiliza datos de configuración para determinar cuántos objetos ProcessAgents necesita crear. Para cada objeto ProcessAgent que debe crear, se crea un CascadingAgentComponent 44', y este componente a su vez se comunica con un respectivo objeto Process Agent 34', el cual se crea dentro de su propia Máquina Virtual de Java. El principal método () del objeto ProcessAgent 34' está configurado para realizar el trabajo del Agente de procesos. El objeto ProcessAgent 34' tiene un objeto asociado G2Runtime 50'', que se utiliza para localizar un objeto DefaultComponentRegistry 31''. Este, a su vez, crea un objeto ProcessAgentComponent 38'.
imagen9
Los objetos Component creados por instancias de la clase DefaultComponentRegistry como se describió anteriormente permiten administrar ambos objetos HostMaster y ProcessAgent. Como se describió anteriormente, tanto el objeto HostMaster 33' como el objeto ProcessAgent 34' llevan asociados objetos DefaultComponentRegistry 31' y 31'', y ambos objetos DefaultComponentRegistry almacenan detalles del objeto HostMasterComponent 37' y el objeto HostMasterComponent 38'.
El objeto CascadingAgentComponent 44' y el objeto ProcesAgent 34' se comunican utilizando RMI, y ambos tienen clientes RMI, los cuales se utilizan con este propósito. Como se describió anteriormente, un objeto HostMaster es responsable de la administración de sus objetos ProcessAgent asociados. Esto se logra por comunicación utilizando los registros componentes descritos anteriormente. Más aun, un objeto ProcessAgent puede generar “eventos de latido” a intervalos predeterminados, y el objeto HostMaster puede recibir dichos eventos. Si un evento así no se recibe en el momento esperado, o dentro de un tiempo predeterminado luego del momento anticipado, el objeto HostMaster supone entonces que el objeto ProcessAgent ha muerto, y en consecuencia, realiza la recuperación instanciando un nuevo objeto Process Agent. Los detalles de la muerte del objeto Process Agent anterior y la creación del nuevo objeto ProcessAgent se registran en el objeto registro DefaultComponent correspondiente.
La figura 10 ilustra el proceso de creación de nodo dentro de un proceso particular. El objeto ProcessAgent 34' localiza su objeto NodeManager 35' (al que hace referencia la variable privada nNodeManager). Luego utiliza un método createNode público dentro del objeto NodeManager 35' para crear un nodo. El método createNode toma como parámetro un tipo de nodo, que se representa por un objeto NodeType, el cual es un índice y una descripción textual del nodo a ser creado. El objeto NodeManager 35' crea un objeto NodeFactory 54' utilizando su constructor que no toma ningún parámetro. El método createNode ofrecido por el objeto NodeFactory 54' se usa entonces para crear el nodo deseado. El objeto NodeFactory 54' crea un objeto MasterNode 55' llamando a su método constructor que no toma ningún parámetro.
El objeto MasterNode 55' a su vez instancia un objeto CreatedNode 64' al que hace referencia el parámetro mState dentro del objeto MasterNode 55'. Un método init() ofrecido por el objeto CreatedNode 64' es llamado entonces por el MasterNode para inicializar el objeto MasterNode 55', y las transiciones entre estados ilustradas en la figura 6 pueden entonces tener lugar como sea necesario, y el estado del nodo se fija utilizando un método setState ofrecido por el objeto MasterNode 55'. El objeto CreatedNode 64, a su debido tiempo, usa un objeto ServiceFactory 82' para crear los servicios requerido por el objeto MasterNode 64'.
Puede verse en la figura 4E que la clase NodeManager incluye una variable vector privada mynodes que almacena detalles de todos los nodos administrados por un objeto NodeManager. La figura 10 ilustra de manera esquemática que cada vez que se crea un objeto MasterNod, se añade a esta variable vector.
Las figuras 11A y 11B muestran cómo se transmiten los mensajes de un primer servicio 74' a un segundo servicio 74'' según la presente invención. Observando la figura 11A, puede verse que el primer servicio 74' incluye una pluralidad de controladores de servicio 77', el cual ofrece la funcionalidad del primer servicio que se describió anteriormente. El primer servicio 74' incluye además una cola de entrada IN1 donde se colocan los mensajes entrantes y una cola de salida OUT1 en la que se colocan los mensajes de salida antes de su transmisión. El segundo servicio 74'' incluye una pluralidad de controladores de servicio 77'', una cola de entrada IN2 y una cola de salida OUT2. Tanto el primer servicio 74' como el segundo servicio 74'' tienen asociados direcciones únicas que se utilizan para dirigir mensajes hacia ellos.
La figura 11B ilustra cómo se realiza el envío de mensajes usando la estructura ilustrada en la figura 11A. La figura 11B ilustra el enrutamiento de un mensaje de uno de los controladores 77' del primer servicio 74' a uno de los controladores de servicio 77'' del segundo servicio 74''. En el paso S1, un controlador de servicio 77' del primer servicio 74' ejecuta el comando especificado en el mensaje. Cuando se completa la ejecución, el controlador del servicio 77' recaba información del mensaje para determinar una máscara de dirección para el próximo servicio al que debe ser enviado, y modifica el mensaje para mostrar esta máscara de dirección (paso S2). En el paso S3, el mensaje es enviado a la cola de salida OUT1 del primer servicio 74'. Un objeto MessageDispatcher asociado con la cola de salida OUT1 copia entonces el mensaje a su cola de espera (paso S4), y recaba información del mensaje para obtener una máscara de dirección indicando el destino deseado (paso S5). Una cola S6, un objeto ComponentRegistry es utilizado para localizar todos los servicios dentro del proceso en curso del sistema operativo que coinciden con la máscara de dirección del mensaje.
En el paso S7, se hace un control para determinar si se han localizado o no algunos servicios. Si se determina que un solo servicio ha sido localizado (por ejemplo, el segundo servicio 74'' de la figura 11B), el mensaje es enviado a la cola de entrada de ese servicio (paso S8), un controlador de servicio apropiado se localiza dentro de ese servicio (paso S9), y el mensaje es enviado al controlador de servicio localizado.
imagen10
Si el paso S7 determina que no se puede encontrar ningún servicio adecuado puede encontrarse dentro del proceso en curso, el mensaje es modificado para mostrar que puede ser dirigido a un servicio de mensajes que puede realizar comunicación interproceso (paso S11). Un servicio de paso de mensajes apropiado es entonces encontrado (paso S12), el mensaje dirigido a la cola de entrada del servicio de paso de mensajes (paso S13), y el servicio de paso de mensajes lleva cabo la comunicación interproceso (paso S14).
Si el paso S7 encuentra N servicios adecuados, cuando N es mayor de uno, una contra variable, m es inicializada a cero (paso S15), y entonces una secuencia de operaciones se lleva a cabo N veces por medio de un bucle establecido por los pasos S16 y S21. Cada bucle producirá un clon del mensaje (utilizando la funcionalidad estándar de Java) en el paso S17, y este es enviado a uno de los servicios localizados en el paso
18. Un controlador de servicio se localiza entonces dentro de cada servicio (paso S19) y se lleva a cabo el proceso correspondiente (paso S20).
Las figuras 12A a 12D ilustran el envío de mensajes con más detalle.
Haciendo referencia a la figura 12A, puede verse que un objeto CommandExecutor 77b' (al que hace referencia una variable apropiada en una clase de controlador apropiada), utiliza un método de ejecución ofrecido por un comando almacenado en una variable Command dentro de un mensaje 88a'. En el ejemplo que ilustra la figura 12A, el comando es un ReceiveUserRequestCommand, el cual es a su vez controlado por un objeto controlador de conexión 77c'. Es en este momento que tiene lugar el procesamiento específico del servicio y mensaje. Suponiendo que el comando está correctamente ejecutado, el objeto CommandExecutor 77b' usa un método commandSucceded provisto por el mensaje 88a'. Puede verse que este método es provisto por la clase AbstractMessage (figura 8B), y todos los mensajes son instancias de subclases de la clase Abstract Message. En el caso de un CommandSequenceMessage, el método commandSucceed hará que una variable CommandTargetPair m_ProcessingDelivery se marque para el próximo comando, y la próxima dirección de destino. Cuando esto se complete, un método SendServiceMessage provisto por un objeto ConnectionService 74a' se usa para dirigir el mensaje a la cola de salida del servicio (representada por una variable mOutQueue en la clase BaseService), usando un método put. De ese modo, la figura 12A ilustra los pasos necesarios para colocar un mensaje en la cola de salida de un servicio.
Observando las figuras 8B y 8C, puede verse que un objeto CommandSequence Message incluye una secuencia de comando (que es una instancia de un objeto CommandSequence, figura 8H) y tres objetos CommandTargetPair. Un primer ComandTargetPair se establece en caso de éxito, como se describió anteriormente, usando el método commandSucceed. Un segundo CommandTargetPair se establece en caso de fallo de un método commandFailed, y un tercer CommandTargetPair se usa cuando es necesaria la comunicación entre procesos, como se describe a continuación con referencia a la figura 12D. Información del estado dentro de un objeto mensaje se utiliza para determinar cuál de los objetos CommandTargetPair debe usarse en un momento determinado.
La figura 12B ilustra los pasos que se llevan a cabo luego que un mensaje ha sido colocado en la cola de salida de una cola. La cola de salida del servicio está incluida en su propio objeto MessageDispatcher 80', el cual implementa la interfaz de Hilo proporcionada por el lenguaje de programación Java. Un método get() proporcionado por una WaitQueue es llamado por un objeto MessageDispatcher 80'. El método get() transfiere el mensaje a una cola representada por un objeto mWaitQueue 80a' dentro del objeto distribuidor Message 80'. El objeto MessageDispatcher 80' localiza entonces el objeto MasterNode 55' apropiado, y enruta el mensaje a ese nodo.
Al recibir el mensaje, el objeto Master Node 55' localiza un objeto RouterThread 58' de su grupo de hilos de enrutamiento (representados por una instancia de una clase que implementa la interfaz Pool ilustrada en la figura 5D), usando un método getRouterThread. Una vez que se ha localizado un objeto RouteThread apropiado, se utiliza un método de enrutamiento proporcionado por un objeto RouterThread 58' para enrutar el mensaje al servicio correcto. Esto implica llamar al método getAddressMask proporcionado por el objeto Message para obtener una máscara de dirección, y luego utilizar un objeto ComponentRegistry 31' para localizar todos los servicios que coinciden con la máscara de direcciones llamando a un método findLocalAddressables proporcionado por el objeto ComponentRegistry 31'. Suponiendo que al menos se encuentra un servicio adecuado, un método getRouter () es llamado en el objeto Service 74b'. Un método route() proporcionado por el objeto Service 74b' es usado entonces para enrutar el mensaje a la cola de salida 74c' del objeto Service 74b'.
Si el método findLocalAddressables no encuentra ningún servicio adecuado, se lleva a cabo el procesamiento ilustrado en la figura 12D, como se describe a continuación con más detalle.
Si se encuentra más de un servicio dentro de un nodo que coincide con la máscara de dirección especificada, entonces el mensaje es clonado y enviado a las colas de entrada de todos los servicios de la manera descrita anteriormente. Además, cabe señalar que en cuanto el mensaje es distribuido al objeto RouterThread 58', la tarea del objeto MessageDispatcher está terminada, y por lo tanto la operación del objeto Message Dispatcher 80' se desacopla de la operación del objeto RouterThread 58'.
La figura 12C ilustra el procesamiento cuando un mensaje ha llegado a la cola de entrada de un servicio. Un objeto MessageDispatcher 80b' se asocia con la cola de entrada y recibe los mensajes que llegan. Cuando llega un mensaje, el objeto MessageDispatcher 80b' usa un método get() para copiar el mensaje a su objeto WaitQueue 80c'. Un método de enrutamiento se usa entonces para reenviar el mensaje a un objeto MessageToHandlerForwarder 80d'. El objeto MessageToHandlerForwarder 80d' usa un método getObject incluido en el objeto ServiceHandlerPool 80e' para proporcionar un objeto Handler 77d'. El MessageToHandlerForwarder 80d' llama entonces a un método handleMessage (especificado en la interfaz MessageHandler) para que el mensaje sea controlado. En el momento debido, el Controlador usa un método setNextCommand suministrado por un objeto CommandExecutor 77b' para que la secuencia de comandos sea actualizada adecuadamente.
imagen11
La figura 12D ilustra el procesamiento mostrado en la figura 12B, modificada cuando se da el caso que el objeto RouterThread 58' determina que no hay servicios registrados con el ComponentRegistry 31' que coincidan con la máscara de dirección especificada. En este caso, un método leaveProcess se utiliza para actualizar el estado interno del objeto mensaje 88a', y el RouterThread busca entonces localizar un servicio que sea responsable de comunicación interproceso utilizando un método getAddressMask y un método findLocalAddressables, que devuelvan un servicio 74d' apropiado. Una vez que es localizado el servicio apropiado, el mensaje es enviado a ese servicio de la manera que se describió anteriormente con referencia a la figura 12B. Al recibir el mensaje en la cola de entrada del servicio, el servicio maneja el mensaje (como se describe con referencia a la figura 12D), y se logra la comunicación interproceso.
De la anterior descripción se desprende que el enrutamiento se lleva a cabo como se especifica dentro de variables apropiadas de un mensaje determinado. No hay un control central del enrutamiento de mensaje, pero en su lugar, el control se distribuye entre los objetos que controlan los mensajes.
Por ejemplo, en referencia a la figura 13, se ilustra un sistema de cinco controladores de mensajes indicados A, B, C, D y D'. Los controladores de mensajes D y D' son ambos instancias de un controlador de mensajes común.
Un mensaje Msg1 es enviado desde el controlador A al controlador B, y posteriormente del controlador B al controlador C. El controlador C procesa Msg1 de manera predeterminada y genera dos mensajes, Msg2 y Msg3. Cada uno de estos mensajes es entonces enrutado independientemente. El mensaje Msg2 es enrutado al controlador D, mientras que el mensaje Msg3 es enrutado al controlador D'.
Cada controlador procesa el mensaje y lo enruta hacia adelante al próximo servicio allí especificado. Distribuir el control del enrutado del mensaje de esta manera proporciona un sistema escalable, y elimina la necesidad de un control centralizado de paso de mensajes. Esto es particularmente beneficioso cuando un controlador crea una pluralidad de mensajes desde un solo mensaje recibido (como es el caso del controlador C en la figura 13).
Haciendo referencia nuevamente a la figura 2, luego de haber descrito un marco de operación del servidor 13, se describe ahora el funcionamiento del servidor web 12 y del servidor 13 para proporcionar interfaces de usuario compuestas.
La figura 14 ilustra la arquitectura lógica del servidor web 12 y el servidor 13. Puede observarse que el servidor 13 opera utilizando un marco de proceso como se ilustra en la figura 3, e incluye un proceso Host Master Watchdog 100, un proceso Host Master101 y un proceso 102.
El proceso 102 incluye un agente de proceso 104 y un administrador de nodo 105 que realizan funciones como se describió anteriormente. El proceso 102 incluye tres nodos 106, 107 y 108. Un nodo CA (adaptador de cliente) 106 es responsable de la interacción entre el servidor 13 y las aplicaciones compuestas. Un nodo AA (adaptador de aplicaciones) 107 es responsable de las interacciones entre el servidor 13 y las aplicaciones fuente apropiadas por medio de una interfaz de aplicaciones fuente 109. Un nodo ALF (Authentication Lockdown Framework) 108 es responsable de las funcionalidades de autenticación y seguridad suministradas por el servidor 13. La información de seguridad es almacenada en una base de datos 110, que puede ser accedida por medio de una interfaz convencional JDBC (conectividad de base de datos Java) 111. La función de cada uno de estos nodos se describe a continuación con más detalle.
El servidor 13 está conectado a una terminal de administración 112 por medio de un enlace 113. La terminal de administración 112 permite a los administradores del servidor 13 llevar a cabo varias funciones de administración, como se describe a continuación.
Los datos de configuración para los nodos 106, 107 se obtienen de un IDM (administrador de datos de integración), que incluye una base de datos 115 a la que se accede por una interfaz apropiada (tal como una interfaz JDBC 116). La forma de datos de configuración y la forma en que se usan se describen a continuación con más detalle. Cabe destacar que la base de datos 110 y la base de datos 115 juntas constituyen los datos de configuración 18 de la figura 2.
El servidor web 12 se comunica con el servidor 13 a través de una conexión 14. El servidor web ejecuta un servlet Java™ 117, y este servlet 117 es responsable de la comunicación entre el servidor web 12 y el servidor
13. En muchas situaciones es necesario imponer restricciones de acceso a las aplicaciones compuestas o parte de las aplicaciones compuestas administradas por el servidor. Dichas restricciones pueden ser implementadas convenientemente asignando contraseñas a los usuarios y asociando privilegios de acceso apropiados con dichos nombres y contraseñas. El servlet 117 implementa todas las políticas de seguridad necesarias cooperando con el nodo CA 106. A la funcionalidad proporcionada por el servlet 117 se le denomina un servicio UA (agente de usuario).
imagen12
El nodo CA 106 incluye cuatro servicios. Un servicio de ML (capa de messaging) 118 suministra funcionalidad de JMS (servicio de Java Messaging) para comunicación entre objetos dentro de los diferentes procesos. El JMS es tal que el paso de mensajes entre procesos puede ser llevado a cabo de manera unificada, independientemente de si los procesos están localizados en el mismo o en diferentes hosts.
Un servicio de CL (capa de comunicaciones) 119 ofrece conexiones entre el nodo CA y otros procesos. Un servicio de DT (transformación de datos) 120 proporciona los medios para transformar datos de una aplicación compuesta que debe ser reenviada a una aplicación fuente, y cuando se reciben datos de una o más aplicaciones fuente que debe salir de una aplicación compuesta. Un servicio de UXM (administrador de experiencia de usuario) 121 es responsable de determinar las acciones necesarias cuando se reciben peticiones del webserver 12, y cuando se reciben datos de una aplicación fuente.
El nodo AA incluye tres servicios, un servicio ML 122, un servicio CL 123 y un servicio DT 124. Cada uno de estos servicios ofrece la misma funcionalidad que el servicio equivalente del nodo CA 106.
El nodo ALF 108 también incluye un servicio ML 125 y un servicio ALF 126. El servicio ALF 126 es responsable de los atributos de seguridad como se describe a continuación con más detalle.
El uso de un nodo CA 106 y el nodo AA 107 para producir y administrar aplicaciones compuestas se describe ahora haciendo referencia a la figura 15. Un usuario opera un navegador 126 para tener acceso a documentos HTML proporcionados por el servidor web 13 que forman una interfaz de usuario compuesta. Un usuario emite una petición a través de un navegador web 126. Esta petición es reenviada al servidor web 12 utilizando el HTTP (protocolo de transferencia de hipertexto) funcionando de manera convencional. El servlet 117 dentro del servidor web 12 opera un servicio UA 127. El servicio UA 127 autentifica la petición de acuerdo con políticas de seguridad predeterminadas (definidas como se describe a continuación). Si la autenticación tiene éxito, un mensaje IncomingUserRequest se crea usando parámetros recibido por el UA (por ejemplo, de la petición HTTP). Este mensaje IncomingUserRequest es enviado luego por el servicio UA 127 al servidor 13, con una dirección de destino del servicio CL 119 del nodo CA 106. Como se describió anteriormente, este mensaje se transmite utilizando el protocolo JMS. El servicio CL 119 recibe el mensaje IncomingUserRequest, y una vez que se recibe el mensaje, lo dirige al servicio DT 120 del nodo CA 106. El servicio DT 120 realiza cualquier transformación necesaria de los datos contenidos en el IncomingUserRequest, y dirige el mensaje hacia adelante al servicio UXM 121 del nodo CA 106. El servicio UXM 121 procesa el mensaje y genera uno o más mensajes OutgoingUserRequest, destinados a las aplicaciones fuente apropiadas 128. Estos mensajes son enviados primero al servicio DT 124 del nodo AA 107 utilizando, por ejemplo, el protocolo JMS.
El servicio DT 124 del nodo AA 107 realiza las transformaciones necesarias y reenvía el mensaje al servicio CL 123, que a la vez genera mensajes para pedir datos apropiados de las aplicaciones fuente 128 en un formato adecuado. Estos mensajes son entonces reenviados a las aplicaciones fuente utilizando, por ejemplo, el protocolo JMS.
Las aplicaciones fuente 128 procesan los mensajes recibidos y al mismo tiempo producen datos en respuesta a las peticiones recibidas. Estos datos son recibidos por el nodo AA 107 y se pasan al servicio CL 123. Los datos se reenvían entonces al servicio DT 124, que procesa los datos para extraer uno o más objetos página y para crear un mensaje IncomingUserResponse, el cual es reenviado al servicio UXM 121 del nodo CA 106.
El servicio UXM 121 procesa el mensaje IncomingUserResponse y determina si ha recibido o no todos los datos necesarios para crear una página compuesta (determinada por su configuración, la cual se describe a continuación). Cuando se reciben todos los datos requeridos, se crea un mensaje OutgoingUserResponse, el cual se reenvía al servicio DT 120, donde se realiza toda transformación necesaria. Una vez realizadas las transformaciones necesarias, el mensaje OutgoingUserResponse se envía al servicio CL 119 y desde allí al servicio ML. El servicio ML transmite la página compuesta al UA 127 utilizando el protocolo JMS. El UA muestra entonces la página al usuario a través del navegador web 126, suponiendo que toda validación necesaria es llevada a cabo con éxito por el UA 127.
En la descripción presentada anteriormente, se hace una distinción entre los mensajes IncomingUserRequest y OutgoingUserRequest. Una distinción similar se hace entre mensajes IncomingUserResponse y mensajes OutgoingUserResponse. Estas distinciones se hacen para facilitar la comprensibilidad; no obstante, debe tenerse en cuenta que en algunas representaciones de la invención tanto los mensajes IncomingUserRequest y OutgoingUserRequest se representan por un único tipo de mensaje UserRequest. De manera similar, tanto los mensajes IncomingUserResponse como los OutgoingUserResponse pueden ser representados por un tipo único de mensaje UserResponse.
imagen13
Se apreciará que el procesamiento que se describió anteriormente puede ser utilizado para controlar un amplio rango de aplicaciones compuestas diferentes; no obstante, se apreciará también que el procesamiento necesario variará considerablemente, y por lo tanto, un medio efectivo de configuración de servicios ilustrados en las figuras 14 y 15 necesarios. Esto se logra accediendo a la base de datos IDM 115. Los datos IDM se almacenan de manera jerárquica como se describirá a continuación con más detalle.
Al inicio, el servidor web 12 y el servidor 13 deben ser provistos con datos que permitan acceso a la base de datos IDM e indiquen dónde están localizados los datos pertinentes en la base de datos. Esto se logra suministrando a cada los parámetros de invocación correspondientes que indiquen dónde pueden localizarse los datos de configuración.
El servlet 117 del servidor web 12 (denominado “el receptor”) se proporciona con los parámetros de invocación que se ilustran en la figura 16.
Un parámetro g2jms.config especifica un fichero que contiene propiedades de configuración para el servlet 117. Un parámetro g2config.home especifica un directorio que contiene un fichero de propiedades IDM, que proporciona información de cómo se accede a la base de datos IDM 115. Un parámetro g2listener especifica un nodo en la estructura jerárquica de datos IDM donde se encuentra la información de configuración para el servicio UA 127. Un parámetro g2config.instance especifica datos de configuración para la aplicación compuesta que el servidor web 12 debe proporcionar al usuario. Un parámetro g2jms.config especifica la configuración para el servicio de UA 127. Un parámetro g2tracer.conf especifica la configuración del archivo de registros.
Los nodos y servicios del servidor 13 (en su conjunto denominados “el redactor”) son proporcionados con lo parámetros de invocación que se ilustran en la figura 17.
Los parámetros g2config.home, g2jms.config y g2config.instance cumplen funciones como se describe con referencia a la figura 16. El parámetro g2config.webhost especifica una dirección IP para el servidor de web en el que se implementa un servicio 127 UA se implementa por medio del servlet 117. El parámetro g2config.baseipport especifica un número de puerto utilizado por una consola de administración que se usa en conexión con el redactor como se describe a continuación. El parámetro g2basetracer.conf se utiliza para especificar un archivo de registro para cada proceso operando dentro del redactor. Dado que cada redactor incluye por lo menos tres procesos HostMaster y un proceso que contiene nodos AA y CA, al menos dos archivos de registro deben ser especificados, además de un archivo de registro para el servidor web.
Los parámetros descritos anteriormente con referencia a las figuras 16 y 17 juntas permiten al receptor y al redactor obtener datos de configuración del IDM. Otros parámetros de invocación adicionales se ilustran en la figura 18. Estas especifican etiquetas de página que se usan en peticiones HTTP pasadas al receptor por el redactor.
APPLICATION_CLASS especifica un nombre utilizado por la aplicación compuesta y se utiliza por el redactor para determinar cualquier transformación que el CA.DT puede necesitar para funcionar. UXM_TREEID y UXM_NODEID especifican donde en la configuración puede el UXM encontrar información de configuración pertinente para la página compuesta específica. UXM_MODIFIED permite al UXM realizar no procesar en algunas páginas. Si UXM_MODIFIED está fijado en verdadero, esta es una indicación de que se necesita procesamiento de acuerdo con los datos de configuración almacenados en el IDM (descrito a continuación). Si UXM_MODIFIED está fijado en falso, significa que no es necesario ningún procesamiento y el UXM simplemente reenvía el mensaje al nodo AA.
Se utilizan etiquetas adicionales para fines de seguridad. Una etiqueta g2authorization se usa para indicar que el receptor debería intentar autenticación. Las etiquetas usr y pwd se utilizan respectivamente para representar datos de nombre de usuario y contraseña cuando son necesarios para la autenticación.
Los parámetros de invocación descritos anteriormente permiten al redactor y al receptor localizar el IDM y localizar datos adecuados dentro del IDM. Estos parámetros son implementados convenientemente como variables de clases apropiadas De Java. Pueden ser configurados por medio de un fichero system.properties, del que se ilustra un ejemplo en la figura 19. Cada línea del fichero corresponde a una propiedad de Java que debe ser configurada. Puede observarse que todas las entradas del fichero comienzan con el prefijo “hm” o “pm”. Esto garantiza que cada entrada sea recogida por el proceso correcto. Las entradas con el prefijo “hm” son recogidas por el proceso HostMaster, y puede verse que estas corresponden con los parámetros de invocación del redactor que se describen anteriormente. Las entradas con el prefijo “pa” son propiedades adicionales que se fijan en cada configuración por el proceso HostMaster. Generalmente incluyen configuración para varios aspectos de la JVM (máquina virtual de Java), tal como la recolección de residuos.
En la figura 19 se puede observar que todas las entradas que comienzan con “pa” están en formato “pa.x”. Esto indica que la propiedad debe ser configurada en todos los procesos iniciados por el HostMaster. No obstante, en algunas representaciones de la invención, las entradas pueden comenzar con el prefijo “pa.N”, donde N es un número entero. En este caso, esa entrada se refiere solamente al proceso N.
imagen14
Cabe destacar que el fichero system.properties se usa de manera jerárquica como sigue. Cualquier entrada de tipo “pa.N” anulará una entrada “pa.x” para el proceso N. Cualquier entrada de tipo “pa.x” anulará la entrada “hm” heredada del proceso HostMaster. Además de configurar parámetros por medio del fichero system.properties, debe tenerse en cuenta que los parámetros de configuración pueden ser especificados al inicio, por ejemplo, por medio de una interfaz de línea de comando. En tal caso, si un valor de propiedad se especifica tanto en el fichero system.properties como en la línea de comando, el fichero system.properties determinará el valor.
Habido descrito los parámetros de invocación y las etiquetas asociadas, la estructura de datos IDM almacenada en la base de datos 115 se describe a continuación.
Cabe mencionar que, como resultará evidente más abajo, cada aplicación compuesta tiene un nombre de clase de aplicación único que se usa para identificarla. Cada aplicación fuente también tiene un nombre de clase de aplicación único que se usa con fines de identificación. De esta forma, si una aplicación compuesta comprende dos aplicaciones fuente, su configuración incluye tres nombres de clases de aplicaciones.
En la figura 20 se muestra una estructura parcial IDM para una configuración que contiene un solo proceso que contiene un nodo AA y un nodo CA (como se ilustra en la figura 14). El nivel más alto de la jerarquía incluye una sola entidad CONFIG 129 la cual es la raíz del árbol IDM. Esta entidad tiene seis entidades secundarias. Una entidad INSTANCE 130 se ocupa de la información de configuración para un redactor particular. Una entidad BASE_ALF_CONFIG 131 suministra información de configuración para un nodo ALF. Cada entidad HOST 132, PROCESS 133, NODE 134 y SERVICE 135 tiene entidades secundarias que contienen información para las entidades correspondientes de la figura 14.
Como se describió anteriormente, el parámetro g2instance hace referencia a un nodo nombrado en el IDM que contiene datos de configuración apropiados. Estos datos incluirán detalles del número de procesos que deben utilizarse, la distribución de nodos CA, nodos AA y nodos ALF a esos procesos, y dónde se pueden encontrar los datos apropiados para los servicios contenidos en dichos nodos.
En este caso, el parámetro de invocación g2instance se configura de manera que:
G2instance=LAB1_INS
Esto indica que el redactor debe localizar la entidad LAB1_INS 136, la cual es una entidad secundaria de SINGLE_PROC_AA_CA_INSTANCE 130a, que es a su vez una entidad secundaria de la entidad instancia 130a, para obtener los datos de configuración. Puede verse que la entidad LAB1_INS tiene datos adecuados suministrados por un grupo de datos g2config 137.
La entrada alf en el grupo de datos 137 indica que el servidor utiliza el ALF, y ofrece una manera de localizar la base de datos ALF 110 (figura 14). La host de entrada indica que el servidor 13 incluye un solo host al que hace referencia dicha entrada en el grupo de datos 137. Puede verse que todas las demás entradas poseen la forma “hose.process1.”; y cada una de estas entradas suministra detalles de un nodo respectivo o de un servicio que funciona dentro del único proceso 102 (process1), en el servidor 13 de la figura 14. Puede verse que cada nodo y servicio 13 ilustrado en la figura 14 tiene una entrada correspondiente en el grupo de datos 137, el cual suministra detalles de su configuración.
Ahora se describe la configuración del servicio CL 123 del nodo AA 107 (figura 14). La figura 21 muestra parte de la jerarquía de la figura 20 con más detalle, junto con detalles de entidades relevantes para la configuración del servicio CL 123 del nodo AA 107. Además de las entidades descritas anteriormente, la jerarquía incluye una entidad BASE_CL_SERVICE 138 que es una entidad secundaria de la entidad SERVICE 135. La entidad BASE_CL_SERVICE 138 tiene dos entidades secundarias, la entidad AA_CL_SERVICE 139, la cual representa el servicio CL 123 del nodo AA 107, y una entidad EXT_APPS 140 que contiene detalles de aplicaciones fuente relevantes. Debe tenerse en cuenta que el orden jerárquico del IDM permite a las entidades secundarias heredar y anular las propiedades de su entidad dominante. Por ejemplo, los datos predeterminados para todos los servicios pueden ser especificados en la entidad SERVICE 135. Algunos de estos datos pueden ser heredados y utilizados por el entidad BASE_CL_SERVICE 138, mientras que otras parte de los datos pueden ser remplazadas por valores más adecuados especificados en la entidad BASE_CL_SERVICE 138.
Puede verse que la entrada host.processxAA.CL en el grupo de datos 137 hace referencia al grupo de datos g2config 141 bajo una entidad myscrapps 142. El grupo de datos g2config 141 incluye una entrada para cada aplicación fuente con la que AA se comunica, y se hace referencia a cada aplicación por el nombre de su clase de aplicación. Cada entrada incluirá un parámetro session_timeout que indica el tiempo (por ejemplo, en minutos) que un usuario puede permanecer inactivo sin que se corte una conexión, y un parámetro booleano replicate_sessions que indica si los datos de una sesión deben o no ser copiados entre procesos. Configurando este parámetro como TRUE ofrece recuperación si la sesión de datos se pierde por cualquier motivo.
imagen15
Las aplicaciones fuente de las cuales se crea la aplicación compuesta están cada una representadas por una entidad secundaria de la entidad EXT_APPS 140. En la figura 21 se ilustran dos aplicaciones fuente. Una primera aplicación fuente (que tenga el nombre de clase “ScrAppl”) se indica por una entidad SrcAppl 143 y una segunda aplicación (que tenga el nombre de clase “SrcApp2”) se indica por una entidad ScrApp2 144.
Cada una de estas entidades tiene dos grupos de datos. La entidad SrcAppl tiene un grupo de datos g2config 143 al cual hace referencia el grupo de datos 141 y que especifica datos para la configuración del AA y un grupo de datos de conexión 146 que especifica los protocolos de comunicación con la aplicación SrcApp1. La entidad SrcApp2 144 tiene dos grupos de datos similares, 147, 148.
Se describen ahora los datos almacenados en relación con cada aplicación fuente. El grupo de datos g2conifg para cada aplicación fuente 145, 147 incluye un número de parámetros. Un parámetro de autorización toma un valor booleano e indica si la aplicación fuente requiere o no autenticación. Un parámetro credential_type es necesario cuando el parámetro de autorización está configurado como TRUE. El parámetro credential_type se configura como USRPWD o DYNAMIC. Cuando credential_type está configurado como USRPWD, se utiliza una combinación de nombre de usuario y contraseña estática. Cuando el tipo de credencial está configurado como DYNAMIC, un nombre de usuario estático y una contraseña creada de manera dinámica se utiliza para autenticación. Por ejemplo, una contraseña se puede crear de manera dinámica desde un nombre de usuario usando un algoritmo predeterminado. Un parámetro de protocolo indica un parámetro para ser usado para comunicación con la aplicación fuente. Los protocolos adecuados pueden incluir HTTP, SOAP, MQSERIES y JDBC. Otros parámetros dan información sobre cómo deben ser manejados los errores.
El grupo de datos de conexión asociado con cada aplicación fuente 146, 148 almacena información relacionada con cada conexión. En la figura 21 se puede ver que el grupo de datos g2config 141 no se refiere directamente a los grupos de datos de conexión, y que estos se localizan en virtud de que se encuentran bajo la misma entidad que el grupo de datos g2config 145, 146 correspondiente a cada aplicación.
Cada grupo de datos de conexión 146, 148 incluirá indicaciones sobre un protocolo para ser usado, un número de puerto de la aplicación fuente al que deben enviarse los datos, un identificador para el host donde está funcionando la aplicación fuente, un identificador proxy (si corresponde), junto con parámetros relacionados con actualización y cierre de la sesión.
Además de los parámetros descritos anteriormente, el grupo de conexión de datos incluirá varios otros parámetros apropiados para el protocolo que se está usando.
Si se está usando SOAP, estos parámetros incluirán un parte de fichero de una URL para usar para conexión, un estilo URI para codificación de mensajes, un URI para el objeto destino, y un URI indicando el propósito de la petición SOAP.
Si se está usando JDBC, estos parámetros incluirán una URL para conexión de la base de datos JDBC, un nombre de controlador JDBC, y parámetros que indiquen el tamaño inicial y máximo del pool de conexiones de JDBC.
Otros protocolos requerirán otros parámetros, y dichos parámetros serán obvios para expertos en la materia.
Además de los datos presentados anteriormente, pueden usarse otros datos de configuración diferentes para configurar el servicio CL del AA. Dichos datos de configuración puede ser almacenados en uno de los grupos de datos indicados anteriormente, o de manera alternativa, en un grupo de datos adicional. Generalmente dichos grupos de datos se encentran dentro de la misma entidad de aplicación 143, 144 que los grupos de datos que se describen anteriormente, y en consecuencia, la entidad instancia 136 puede localizar todos los datos de configuración necesarios.
El servicio CL 119 del nodo CA 106 (figura 14) se configura de la misma manera, aunque se puede observar que en este caso serán necesarios datos de una manera similar para la aplicación compuesta o para cada una (en lugar de las aplicaciones fuente). En algunas representaciones del IDM, el grupo de datos 141 incluye una entrada para cada aplicación compuesta, además de entradas para cada aplicación fuente, y estas entradas a su vez identifican las entidades apropiadas que se encuentran por debajo de la entidad EXT_APPS 140.
Los datos de configuración para el servicio DT 120 de nodo CA 106, y para el servicio DT 124 del nodo AA 107 se describen a continuación. La figura 22 es un diagrama árbol que muestra parte de la jerarquía de la figura 20, junto con detalles de entidades pertinentes para la configuración de servicios DT.
La entidad de servicio 135 tiene una entidad secundaria BASE_DT_SERVICE 149, que a su vez tiene una entidad secundaria DT_SERVICE 150 que representa todos los datos de configuración del servicio DT. Una entidad LAB1_DT 151 es una entidad secundaria de DT_SERVICE y representa la configuración del servicio DT para la aplicación representada por la entidad LAB1_INS 136.
Puede verse que las entradas host.process1.AA.DT y host.process1.CA.DT en el grupo de datos 137 ambas hacen referencia a un grupo de datos DT.service 152 que se encuentra debajo de la entidad Lab1_DT 151. El grupo de datos DT.service contiene una única entrada que le permite ubicar su entidad dominante.
imagen16
Un grupo de datos DT.Applications 153 se encuentra debajo de la misma entidad 151 que el grupo de datos del servicio DT 152. El grupo de datos DT.Applications 153 contiene una entrada para cada aplicación compuesta que debe ser manejada por el servicio DT del AA. En el ejemplo de la figura 22, puede verse que el grupo de datos 153 incluye una entrada para cada aplicación compuesta individual Lab1App, y un solo firstbyte de la aplicación fuente. La figura 22 muestra los datos necesarios para configurar el servicio DT del CA para manejar la aplicación compuesta Lab1App.
Puede verse que la entrada Lab1App en el grupo DT.Applications 153 referencia a un grupo de datos DT.AppLab1App 154 que contiene datos relevantes para manejar transformaciones desde y hacia la aplicación compuesta Lab1App. El grupo de datos DT.App.Lab1App 154 incluye una entrada que indica las transformaciones necesarias para responder a un OutgoingUserRequest, y una entrada que indica las transformaciones necesarias para convertir datos del UXM a una manera adecuada para su salida a la aplicación compuesta.
La entrada UXM referencia al grupo de datos DT.App.Lab1App.UXM 155, el cual a su vez contiene entradas que indican cómo deben transferirse los datos entre los objetos UXM utilizados en el UXM del CA, y datos que pueden ser procesados por la aplicación compuesta. En el ejemplo de la figura 22, el grupo de datos 155 incluye una entrada NewObjectTransformations que referencia a un grupo de datos 156 y un UIElementTemplates que referencia al grupo de datos 157. Estos datos permiten añadir nuevos datos a los recibidos de las aplicaciones fuente para crear una página compuesta. El grupo de datos UIElementTemplates 157 contiene detalles de dichos datos nuevos, y el grupo NewObjectTransformations indica cómo deben incluirse estos datos en una página compuesta.
Puede verse que las otras entradas en el grupo de datos DT.App.Lab1App hacen referencia a otros grupos de datos 158, 159, 160, que contienen datos que indican como deben llevarse a cabo estas transformaciones.
La figura 23 muestra partes de la estructura IDM que contiene datos pertinentes al servicio DT del nodo AA. Puede verse que la entrada firstbyte en el grupo de datos 153 referencia al grupo de datos DT.App.firstbyte 161, que incluye una entrada para cada tipo de dato que el servicio DT del AA puede tener que manejar, es decir IncomingUserRequest, OutgoingUserRequest, IncomingUserResponse, OutgoingUserResponse y objeto UXM. Debe tenerse en cuenta que en el ejemplo de la figura 15 solamente se procesan mensajes OutgoingUserRequest e IncomingUserResponse. No obstante, los mensajes IncomingUserRequest y OutgoingUserResponse se incluyen para el caso en que el redactor simplemente pasa mensajes entre una aplicación compuesta y una aplicación fuente sin llevar a cabo ningún procesamiento.
Puede verse que las entradas en el grupo de datos DT.App.firstbyte 161 relacionadas con los cuatro tipos de mensajes hacen referencia a los correspondientes grupos de datos 162, 163, 164, que contienen la información de transformación necesaria. La entrada UXM referencia a un grupo de datos DT.App.firstbyte.UXM 165, el cual incluye cuatro entradas. Una entrada ErrorPageResolverData hace referencia a un grupo de datos DT.App.firstbyte.UXM.ErrorPageResolverData 166, el cual contiene los medios para reconocer varias páginas de errores que pueden ser generadas por la aplicación fuente firstbyte. Una entrada PageResolverData hace referencia a un grupo de datos DT.App.firstbyte.UXM.PageResolverData 167 que contiene datos que indican cómo se reconocen las páginas de las aplicaciones fuente, para poder identificar las transformaciones necesarias. Una entrada PageExtractionConfig referencia a un grupo de datos DT.App.firstbyte.UXM.PageExtractionConfig 168, el cual contiene referencias a una pluralidad de archivos XML (lenguaje extensible de marcado), que indican como cada página reconocida por una entrada en el grupo de datos PageResolverData debe ser transformada por el servicio DT antes de ser pasada al servicio UXM del AA.
Los datos de configuración para configurar el servicio UXM 121 del nodo CA 106 se describen ahora con referencia a la figura 24, que muestra las partes relevantes de la estructura de datos IDM. El nivel más alto de la estructura árbol es una entidad BASE_UXM_SERVICE 169, la cual es una entidad secundaria de la entidad SERVICE 135 (figuras 20 a 23). La entidad BASE_UXM_SERVICE 169 tiene tres entidades secundarias, un CA_UXM_SERVICE 170 que representa datos relevantes para el servicio UXM 121 del nodo CA 106 (figura 14), una entidad UXMActionLibrary 171 que almacena datos de acciones UXM, y una entidad UXMPredicateLibrary 172 que almacena predicados.
La entidad CA_UXM_SERVICE 170 tiene una entidad secundaria llamada TreeRootNode para cada aplicación compuesta que el UXM puede manejar, y una entrada adicional 173 para tratar las condiciones de errores. Una entidad TreeRootNode 174 representa una aplicación compuesta CompApp1, mientras que una segunda entidad TreeRootNode 175 representa una segunda aplicación compuesta. Cada entidad TreeRootNode 173, 174, 175 tiene un grupo de datos de control que especifica un identificador único. En el caso del grupo de datos 176 asociado con la entidad 173, este identificador es simplemente “error”, mientras en el caso de los grupos de datos de control 177, 178 se fija un identificador apropiado. Los grupos de datos de control adicionales incluyen información que puede ser utilizada para limitar un uso particular de nodos. Abajo del TreeRootNode 174 que se relaciona con CompApp1 hay dos TreeNodes secundarios que representan cada uno diferentes páginas de la interfaz de usuario para CompApp1. Un primer TreeNode secundario 178 y su grupo de datos asociado representan una página de cliente de página CustPg, en tanto que un segundo TreeNode secundario 179 y su grupo de datos asociado representa una página de orden OrderPg. Puede verse que el TreeNode 178 a su vez tiene tres entidades secundarias 180, 181, 182, cada una de las cuales representa partes particulares de la página de cliente.
imagen17
Se indicó anteriormente que el identificador con el grupo de datos de control para cada aplicación compuesta debe ser único. Cabe señalar que dentro de una aplicación particular, todos los identificadores deben ser únicos dentro de dicha aplicación.
La figura 25 muestra una vista alternativa de la estructura de árbol de la figura 24. Puede verse que además de los grupos de datos de control descritos arriba, todas las entidades TreeRootNode 174, 178, 180, 181, 182 incluyen además un grupo de integración de datos 183 que especifica las acciones que deben tomarse, si corresponde, cuando se encuentra una aplicación compuesta del tipo representado por el TreeRootNode 174. Esta información está determinada por los datos almacenados en una librería ubicada bajo la entidad UXMActionLibrary 171.
Además, las entidades TreeRootNode 178, 180 incluyen un grupo de datos predicados que especifica las condiciones (o predicados) que deben ser ciertas para que se lleven a cabo las acciones especificadas en el grupo de datos de integración. Cada uno de los grupos de datos predicados referencia a una librería predicada ubicada bajo la entidad UXMPredicate Library 172.
La figura 26 muestra parte de la configuración UXM para una aplicación compuesta Lab2App representada por una entidad TreeRootNode 183. Puede verse que la entidad TreeRootNode 183 tiene un grupo de control de datos 184 y un grupo de integración de datos 185. Un TreeNode 186 especifica datos UXM para parte de la aplicación, y tiene un grupo de datos de control 187 y un grupo de datos de integración 188. El grupo de integración de datos especifica las acciones que deben tomarse en respuesta a eventos particulares, y estas acciones se especifican en términos de un grupo de datos apropiados. Por ejemplo, una entrada para una acción deleteUXMObj.1 hace referencia a un grupo de datos DeleteUXMObjectFormTargetContext.RemData 189 dentro de una librería de acción Lab_Lib 190 para la aplicación Lab2App. Del mismo modo, una entrada aggregateNews.2 en el grupo de datos de integración 188 hace referencia a un grupo de datos AggregateNamedContext.AggregateNews 191 en la librería Lab2_Lib 190. A su vez, este grupo de datos referencia a dos TreeNodes 192, 193 que son entidades secundarias de la entidad TreeNode 186. Las otras entradas en el grupo de integración de datos 188 referencia a las entidades correspondientes 194, 195, en la librería Lab2_Lib 190. El funcionamiento del UXM de acuerdo con los datos de configuración descritos anteriormente se presenta con más detalle a continuación.
Ahora se describe la configuración de los servicios ML del nodo CA 106 y el nodo AA 107 (figura 14). Como se indicó anteriormente, la comunicación entre procesos se logra utilizando JMS, y el protocolo JMS está encapsulado dentro de los servicios ML. Haciendo referencia nuevamente a la figura 20, puede verse que las entradas ML del grupo de datos g2config 137 hace referencia a un grupo de datos 196, ubicado bajo un ML_SERVICE 197, el cual está a su vez ubicado bajo una entidad BASE_ML_SERVICE 198. En su mayoría, la configuración del ML se basa en archivos de propiedades, no por datos dentro del IDM. Estos archivos deben ser localizados usando parámetros de invocación como se describen anteriormente con referencia a las figuras 16 y
17. El ML se configura utilizando archivos de propiedades en lugar de datos IDM porque mucho de la configuración se requiere al inicio, antes que se haya accedido al IDM. En realizaciones preferidas de la invención, una configuración común es compartida por el nodo CA 106 y el nodo AA 107. JMS utiliza la interfaz JNDI (Java naming and directory interface) para obtener la información necesaria. Los archivos de propiedades deben contener por lo tanto detalles que permiten conectar al JNDI. Además, el archivo de propiedades debe incluir parámetros que especifiquen todos los datos de configuración necesarios para la implementación de JMS utilizado para poner en práctica representaciones de la invención. En realizaciones preferidas de la presente invención se utilizan la implementación SunONEMQ3.0 o la implementación OpenJMS 0.7.2. Los datos de configuración necesarios serán muy conocidos por los expertos en la materia, y no se describen aquí con más detalle.
No obstante, cabe señalar que algunos parámetros de configuración utilizados en realizaciones preferidas de la presente invención ofrecen resultados favorables. Por ejemplo, debe señalarse que cada proceso dentro del sistema puede enviar mensajes de envío masivo utilizando un tema de envío. Cada proceso tendrá una sola cola de entrada y un agente administrará esas filas garantizando que cualquier mensaje se envía a las filas de entrada de todos los procesos relevantes. Además, cada proceso tiene una fila de persistencia a la cual se entregan los mensajes si la fila de entrada no puede aceptar mensajes por algún motivo. Esta fila suministra recuperación para el sistema.
Habiendo descrito la configuración de todos los servicios del nodo CA 106 y el nodo 107 (figura 14), se describe ahora la configuración del servicio ALF 126 del nodo ALF 108. Los datos de configuración ALF se almacenan en la estructura jerárquica IDM, como se ilustra en la figura 27. El grupo de datos g2config 137 para la entidad Lab1_INS 136 referencia al grupo de datos g2config 199 ubicado bajo la entidad BASE_ALF_CONFIG 131. El grupo de datos g2config 199 ofrece la información necesaria para permitir localizar la base de datos ALF 110 (figura 14). Puede verse que este grupo de datos incluye detalles de una url para la base de datos, un driver para ser usado con la base de datos (aquí el JDBC driver OracleTM) y un nombre de usuario para usar cuando se conecta a la base de datos 110. Se apreciará que otros datos pueden ser necesarios para acceder correctamente a la base de datos 110 y esto también será almacenado en el grupo de datos g2config 199.
imagen18
Cada usuario autorizado para utilizar una aplicación compuesta tendrá una entidad usuario 200, 201 que es una entidad secundaria de la entidad BASE_ALF_CONFIG 131. La entidad usuario 200 tiene un grupo de datos G2 202 que incluye un nombre de usuario utilizado para iniciar sesión en aplicaciones compuestas proporcionado por el compositor. De forma adicional, la entidad usuario 200 tiene un grupo de datos SrcApp 203 que incluye detalles necesarios para conectar a una aplicación fuente SrcApp. Un grupo de datos similar se ofrece para cada aplicación fuente a la que un usuario puede acceder. La entidad usuario 301 tiene un grupo de datos G2 204, y también incluirá una o más entradas para aplicaciones fuente apropiadas (que no se muestran).
La entidad BASE_ALF_CONFIG 131 también tiene un grupo de datos userconfig 205 que especifica detalles relacionados a conectarse a la aplicación compuesta, por ejemplo, formato de contraseña, y una frecuencia con la que deben cambiarse las contraseñas. Los valores especificados en el grupo de datos usersconfig 205 especifican una configuración predeterminada de inicio de sesión heredado por todas las entidades usuario. No obstante, esta configuración predeterminada puede ser invalidada por un grupo de datos usersconfig ubicado debajo de una entidad de usuario apropiada. Cabe señalar que información similar relacionada con cada aplicación fuente se almacena como parte de la configuración del servicio CL dentro del nodo AA.
La entidad BASE_ALF_CONFIG 131 tiene una entidad secundaria adicional CONSOLE_CONFIG 206. Esta entidad incluye una pluralidad de grupos de datos (que no se muestra) que especifican como los datos de configuración de entrada en el sistema a través de la terminal de administración 112 (figura 14) se convierten en comandos ALF. Los comandos se reciben normalmente de la terminal de administración 112 basada en navegador web como peticiones HTTP, las cuales se asignan a los comandos ALF correspondientes. La terminal de administración 112 se usa para añadir usuarios y realizar otras funciones necesarias de administración relacionadas con el ALF.
Haciendo nuevamente referencia a la figura 20, puede verse que la entrada host.process1.ALFNODE en el grupo de datos g2config 137 referencia al grupo de datos g2config 206 ubicado bajo BASE_ALF_ML_NODE 207. La entrada host.process1.ALFNODE.ALF en el grupo de datos g2config 137 hace referencia a un grupo de datos g2config 208 bajo una entidad 209 BASE_ALF_SERVICE. El grupo de datos g2config 208 permitirá acceso a la base de datos ALF identificada por el grupo de datos g2config 199 ubicado bajo la entidad BASE_ALF_CONFIG
131.
Luego de describir la configuración de todos los servicios contenidos dentro de los nodos del servidor 13, se describe ahora la configuración del receptor suministrado por el servidor web 12. Como se indicó anteriormente, un parámetro de invocación g2listener especifica una entidad dentro del IDM que es usada para configurar el receptor. La figura 28 muestra una estructura de datos IDM apropiada. En este caso, el parámetro g2listener se configura para que:
g2listener=weblistener;
Es decir, el receptor localizaría un grupo de datos weblistener 210 ubicado debajo de una entidad UAconfigs 211. El grupo de datos weblistener 210 indica donde deben dirigirse las peticiones entrantes (generalmente a un servicio CA), y el nombre de una clase Java que suministra funciones de autenticación (en este caso personalizadas). El grupo de datos weblistener.custom 212 ofrece una correlación para parámetros de petición para los que necesiten autenticación.
Será apreciado que deben suministrarse los medios para que los datos de configuración puedan ser introducidos en la base de datos IDM para crear las jerarquías que se describen anteriormente. La especificación de estos datos de configuración se describe ahora utilizando un formato de archivo predeterminado.
La figura 29 muestra un archivo que puede ser utilizado para configurar el servicio CL 119 del nodo CA 106. El texto que aparece entre corchetes “[ ]” indica los nombres de una entidad dentro de la jerarquía IDM. El texto que aparece entre corchetes triangulares “< >” indica el nombre de un grupo de datos que se posiciona debajo de la entidad apropiada dentro de la jerarquía IDM. El texto que aparece entre llaves “{ }” indica un tipo de parámetro. “{GRF}” indica que un parámetro es una referencia a otro grupo de datos. Un parámetro {GRF} va seguido por un nombre de entidad apropiado y el nombre del grupo de datos al que se refiere. “{STR}” indica un parámetro string. También se pueden utilizar los parámetros especificados como “{INT}” y “{BLN}”, aunque estos no se muestran en la figura 29. “{INT}” indica un parámetro de número entero y {BLN} indica un parámetro booleano.
En referencia a la figura 29, puede verse que el archivo especifica una entidad CONFIG, que tiene una entidad SERVICE como secundaria, que a su vez tiene una BASE_CL_SERVICE como secundaria. Una entidad CA_CL_SERVICE es secundaria de la entidad BASE_CL_SERVICE y tiene una entidad LAB1_SrcApps como secundaria. La entidad LAB1_SrcApps tiene un solo grupo de datos g2config que incluye una entrada de grupo de referencia que referencia al grupo g2config ubicado bajo una entidad FirstByte dentro de la estructura de datos jerárquica.
imagen19
El archivo de la figura 29 también especifica que la BASE_CL_SERVICE también tiene una entidad EXT_APPS como secundaria, la cual a su vez tiene una entidad FirstByte como secundaria. La entidad FirstByte tiene un solo grupo g2config que especifica dos parámetros de tipo string que suministran información de autorización y protocolo relevantes para la aplicación FirstByte.
Habiendo descrito la configuración de la arquitectura mostrada en la figura 14, el funcionamiento de los servicios ilustrados en la figura 14 se describen a continuación.
El servicio UXM 121 es responsable de recibir peticiones de usuarios y generar una o más peticiones a la aplicación fuente en respuesta a la petición del usuario. El servicio UXM 121 también es responsable de crear páginas compuestas.
Cabe señalar que el UXM usa un formato de datos interno de UXMObjects para representar interfaces de usuario compuestas y partes de dichas interfaces de usuario compuestas. Usando UXMObjects de este modo permite al servicio UXM funcionar de manera independiente del formato de salida, y en consecuencia agrega considerable flexibilidad al sistema.
Un UXMObject almacena datos no estructurados, así como atributos que describen esos datos. Un árbol de UXMObjects se usa para representar datos para una interfaz de usuario compuesta. Puede recordarse que la estructura de la aplicación compuesta se describe por los datos de configuración UXM dentro de la base de datos IDM (vea las figuras 24 y 25). El árbol de objetos UXM generalmente corresponderá a la estructura árbol del UXM dentro del IDM, aunque es importante señalar que los dos árboles son estructuras de datos separados que se almacenan de manera separada.
Un objeto UXM incluye datos no estructurados para una entidad particular dentro del árbol UXM de la base de datos IDM, que representa parte de una interfaz de usuario compuesta. Estos datos se almacenan generalmente utilizando una matriz de bytes. Cada UXMObject también tiene un parámetro mode y un parámetro tipo. El parámetro mode se usa para indicar dónde debe ubicarse un UXMObject dentro del documento compuesto en relación a otros UXMObjects. El parámetro mode puede por lo tanto tomar valores tales como before, after, replace, insert y toplevel. El parámetro tipo se usa para diferenciar UXMObjects creados por el servicio UXM de UXMObjects creados de los datos de la aplicación fuente. UXMObjects pueden, por lo tanto, tener tipos New y Existing. Cada objeto además incluye un conjunto de atributos que están asociados con los datos no estructurados, y que pueden describir los datos o pueden utilizarse para conversión de datos. Cada objeto UXM tiene un identificador (que puede corresponder convenientemente a un ID dentro del árbol UXM dentro del IDM, ver figura 24), y referencia a objetos dominantes o secundarios si corresponde. Estas referencias a objetos dominantes o secundarios permiten a los UXMObjects ser utilizados para crear un árbol de objetos UXM. Debe tenerse en cuenta que los UXMObjects también pueden contener UXMObjects anidados.
Durante el funcionamiento, el UXM mantiene un árbol UXM (separado de un árbol de objetos UXM) el cual está basado en los datos de configuración almacenados en el IDM. Este árbol incluye las acciones, predicados y parámetros que están presentes dentro de las entidades relevantes y grupos de datos del IDM. Además, cada entidad dentro del árbol UXM incluye un estado para cada usuario de ese nodo, que corresponde al contexto de un usuario.
El contexto para un usuario de una entidad particular dentro del árbol UXM mantendrá un estado apropiado para ese usuario para toas las peticiones que dicho usuario pueda hacer y toda respuesta que ese usuario pueda recibir. Esto se almacena en un grupo de parámetros (generalmente como NVP) y por referencia a un único objeto dentro del árbol UXMObject.
En resumen, puede verse que el UXM esencialmente usa tres estructuras de datos, la estructura de datos IDM, el árbol UXM y el árbol UXMObject.
La información que indica como debe funcionar el UXM en respuesta a varias peticiones y respuestas se configura dentro del árbol IDM, el cual en el momento de ejecutarlo se usa para crear el árbol UXM. Además de esta información, el árbol UXM también almacenó información relativa al estado de un usuario específico en un nodo específico en el contexto de un usuario en una entidad particular dentro del árbol UXM. Los datos sobre páginas específicas de la interfaz de usuario compuesta se almacenan dentro del objeto UXM, y los objetos UXM en conjunto forman un árbol de objetos UXMm, que es diferente tanto del árbol UXM como de la estructura de datos IDM. Puede deducirse que por cada entrada en el árbol de objetos UXM, debe existir una entidad en el árbol UXM que tenga el mismo identificador. Lo contrario no es necesariamente cierto.
La figura 30 muestra una ilustración esquemática de parte de un árbol UXM 220 y un árbol UXMObject 221. Puede verse que cada entidad en el árbol UXM 220 incluye información de contexto para el Usuario 1. Los datos de contexto asociados con cada entidad en el árbol UXM 220 incluyen la referencia (indicada por una línea cortada) a una instancia apropiada de un UXMObject en el árbol UXMObject 221. Puede verse que el árbol UXM 220 y el árbol de objetos UXM 221 tienen la misma estructura. Se apreciará que muchas de las realizaciones de la presente invención con respecto a los datos de contexto serán almacenados para una pluralidad de usuario, y cada uno de los muchos usuarios tendrá un respectivo árbol de objetos UXM.
imagen20
Cuando se describe la estructura de datos IDM, se explicó que las acciones fueron ejecutadas si los predicados fueron satisfechos. Los predicados que pueden aparecer en grupos de datos predicados dentro del IDM se describen ahora.
Algunos predicados se basan en las credenciales de inicio de sesión de un usuario. Los usuarios pueden ser asignados a una pluralidad de roles, y una entrada de predicado RoleAuthorisedGuardCondition especificando un rol particular puede ser incluido en un grupo de datos predicados. Este predicado será satisfecho solamente si el rol de un usuario coincide con el rol especificado. De manera similar, un RoleNotAuthorisedGuardCondition se satisface solamente si un rol de usuario no coincide con el especificado por el predicado.
Algunos predicados se basan en un NVP dentro de un contexto de usuario en una entidad determinada dentro del árbol UXM. Un predicado CompareNVPValueGuardCondition compara un NVP especificado en una entidad especificada dentro del árbol UXM con un NVP especificada en una entidad diferente dentro del árbol UXM. El predicado tiene un parámetro que indica si debe evaluar a TRUE para igualdad o desigualdad.
Un predicado RegexNVPMatchGuardCondition toma una expresión regular como parámetro y la evalúa como true si una NVP especificada en una entidad especificada dentro del árbol UXM coincide con la expresión regular.
Un predicado NVPEqualsGuardCondition comprueba el valor de un NVP especificado en un contexto de usuario en la entidad actúa contra un valor especificado como un parámetro, y evalúa a TRUE en caso de igualdad. Un predicado NVPNotEqualsGuardCondition realiza la función opuesta a un predicado NVPEqualsGuardCondition, es decir, evalúa a TRUE en caso de desigualdad.
Un predicado NVPExists comprueba si un NPV especificado existe dentro del contexto de usuario en la entidad corriente dentro del árbol UXM. Si en NVP existe verdaderamente, el predicado evalúa como TRUE. Un NVPNotFound realiza la función opuesta a un predicado NVPExists, es decir, evalúa como TRUE si un NVP especificado no existe en el nodo corriente.
También se pueden especificar muchos otros predicados. Un predicado RemoteServiceCredentialFoundGuardCondition determina si el contexto de un usuario en una entidad específica dentro del árbol UXM incluye credenciales de inicio de sesión para un sistema externo específico (por ejemplo, una aplicación fuente). Si la credencial de servicio existe, el predicado evalúa como TRUE. Un predicado RemoteServiceCredentialNotFoundGuardCondition realiza la función opuesta, es decir, evalúa como TRUE si el contexto de un usuario en un nodo específico no incluye una credencial de servicio para el sistema externo especificado.
Los ExternaID son utilizados por el UXM para identificar elementos de datos dentro de las aplicaciones externas, tales como las aplicaciones fuente. Algunas acciones suministradas por el UXM se ocupan de crear y utilizar varios ExternalID. El UXM mantiene correlaciones entre los ExternaID e los ID internos utilizados dentro del IDM.
Un predicado ExternalIDFoundGuardCondition evalúa como TRUE si el contexto de un usuario en un nodo especificado incluye un ExternalID especificado. Un predicado ExternalIDNotFoundGuardCondition evalúa como TRUE si no encuentra el ExternalID. Un NodeGuardCondition toma una pluralidad de varias ID de un parámetro y evalúa como TRUE si el ID de una entidad especificada coincide con una de las muchas ID especificadas.
Un predicado DataReady comprueba si hay datos (generalmente un objeto UXMObject) presentes en una entidad especificada dentro del árbol UXM. Este predicado se utiliza para garantizar que los datos necesarios para agregación (vea abajo) están presente en un determinada entidad dentro del árbol UXM.
Un predicado FalseGuardCondition y un predicado TrueGuardCondition también pueden ser especificados. Un FalseGuardCondition siempre evalúa como FALSE, garantizando de manera efectiva que no se ejecuten nunca las acciones asociadas. Un TrueGuardCondition siempre evalúa como TRUE asegurando que las acciones asociadas siempre se ejecuten.
Una primera tarea realizada por el servicio UXM 121 es generar peticiones a las aplicaciones fuente luego de recibir una petición de un usuario. Ahora se describe el funcionamiento del UXM para realizar esta tarea.
Cuando un mensaje UserRequest es recibido por el servicio UXM 121 (generalmente de un servicio DT 120), un parámetro UXM_MODIFIED dentro del mensaje es comprobado. Si está configurado como FALSE, el mensaje es dirigido a una aplicación fuente sin que el UXM lo procese. Si está configurado como TRUE, el procesamiento se lleva a cabo como sigue a continuación y se genera un evento UserRequest.
imagen21
El evento UserRequest hace que el UXM localice dentro del IDM la entidad especificada por el parámetro UXM_NODE_ID. Esta entidad se convierte entonces en un punto de agregación activo de usuario. En este caso, ese nodo es el TreeNode 178. Se comprueban entonces cualesquiera predicados especificados en un grupo de datos asociado con ese nodo. Suponiendo que todos los predicados se satisfacen, se llevan a cabo las acciones a las que hacen referencia las entradas del grupo de datos de integración (como las definen sus respectivos grupos de datos). El UXM baja por el árbol UXM evaluando predicados y ejecutando acciones asociadas con cada entidad, cada entidad que encuentra generalmente suministra una lista de acciones, una o más de las cuales puede hacer referencia a una aplicación fuente apropiada. Los detalles de las acciones que pueden aparecer en un grupo de datos de integración se presentan a continuación.
Las acciones en general están asociadas con un único tipo de evento. No obstante, es posible anular esta asociación utilizando un parámetro EVENTMASK en un grupo de datos de acción. Este parámetro es un valor binario N-bit y está configurado de manera que cada bit representa un evento diferente, y que la acción asociada con todos los eventos para los cuales el respectivo bit está configurado como “1”, por ejemplo, si cuatro acciones se utilizan para desencadenar acciones, el parámetro EVENTMASK debería ser un valor binario de cuatro bits.
Las acciones generalmente asociadas con un evento UserRequest se describen a continuación.
Un UserRequestAction está asociado de manera predeterminada con un evento UserRequest, pero se puede asociar con otros eventos utilizando el parámetro EVENTMASK de la manera que se describió anteriormente. Esta acción genera una nueva petición de aplicación fuente que está destinada a la APPLICATION_CLASS de la aplicación fuente. Una petición será hecha a cada aplicación fuente que se necesita para producir la página compuesta.
Las entradas en un grupo de datos UserRequestAction especifica información relevante para crear una petición o peticiones para enviar a una aplicación o aplicaciones fuente determinadas; sin embargo, debe tenerse en cuenta que los detalles relacionados con la conexión de dicha aplicación no están incluidos, ya que estos están especificados por el servicio CL 123 del nodo AA 107. Cada petición de una aplicación fuente incluirá solamente información especificada por el grupo de datos de acción relevante y no incluirá necesariamente parámetros presentes en el mensaje IncomingUserRequest.
Una petición de una aplicación fuente incluirá un parámetro APPLICATION_CLASS, el cual especifica un nombre de clase de aplicación para la aplicación fuente, y un parámetro APPLICATION_PATH, el cual especifica una ruta para localizar la aplicación. Además, una petición de aplicación fuente puede incluir un método de petición que indique como deben ser pedidos los datos. Este parámetro puede tomar un valor como HTTP_GET en caso de una petición HTTP. El mensaje incluye además un string que comprende cero o más parámetros que son seleccionados del contexto actual. Si este parámetro es el string vacío, entonces no se añade ningún valor a la petición original.
Una acción DeflectUXMRequest se asocia nuevamente por defecto con un evento, aunque esta asociación puede ser invalidada usando un parámetro EVENTMASK como se describió anteriormente. Una acción DeflectUXM genera una petición a la aplicación fuente del tipo que se describió anteriormente, pero aquí los parámetros para dicha petición se obtienen del mensaje IncomingUserRequest, no del contexto actual. Esta acción generalmente es desencadenada para volver a usar un mensaje de petición de usuario, y el UXM simplemente descompone el mensaje en partes relacionadas con las diferentes páginas de la aplicación fuente.
Una acción UXMRequestLink está asociada con un evento UserRequest y no puede ser invalidada usando el parámetro EVENTMASK de la manera que se describió anteriormente. Esta acción desencadena un evento UserRequest en una entidad dentro del árbol UXM identificado por el parámetro TARGETNODE. La entidad receptora responderá entonces al evento UserRequest como lo especifican sus entradas UXM. Esta acción añade efectivamente un punto de agregación al árbol UXM.
Una acción JumpToTreeNode se asocia nuevamente con un evento UserRequest, pero puede ser invalidada usando el parámetro EVENTMASK. Esta acción salta a una rama diferente de la estructura de árbol de UXM y provoca un evento UserRequest en una entidad apropiada. Esto se diferencia de la acción UXMRequestLink descrita anteriormente en que el punto de agregación corriente se elimina y se reemplaza con el punto de agregación del destino especificado.
Un número de acciones se ocupan de manipular valores (generalmente nombre, pares de valor (NVP)) dentro del contexto UXM actual. Una acción CopyNVPA se asocia con un evento UserRequest, pero puede ser invalidado utilizando el parámetro EVENTMASK como se describió anteriormente. Una acción de copia CopyNVPAction fija un NVP a un nodo de destino especificado a un valor obtenido de una entidad original específica. La acción incluye identificadores de las entidades de origen y las de destino, y detalles del NVP de origen y el NVP destino dentro de dichas entidades. Si un NVP de destino no se especifica, por defecto, se supone que el NVP destino es el mismo que el NVP de origen. De manera opcional, se puede especificar un prefijo o sufijo, el cual se agrega al principio o al final del NVP de origen cuando se copia en el NVP de destino.
Una acción ConcatenateNVPAction es asocia nuevamente con un evento UserRequest pero no puede ser invalidado por el parámetro EVENTMASK. Esta acción concatena una pluralidad de NVP en una entidad de origen y los copia a un NVP especificado en una entidad de destino. La acción toma como parámetros un identificador de la entidad de origen (que se convierte por defecto en la de la entidad corriente si no se especifica), un identificador de la entidad de destino, una lista de nombres separados por comas de los NVP que se deben concatenar, y el nombre de un NVP para ser creado en la entidad de destino. El valor asignado al NVP creado será la concatenación de los valores de los NVP en la lista de nombres separados por comas.
imagen22
Una acción AddSequenceListener se asocia con un evento UserRequest pero si fuera necesario puede ser invalidada usando el parámetro EVENTMASK. Esta acción configura el contexto de la entidad corriente como un receptor en secuencia de una entidad especificada por un parámetro TARGETNODEID.
Una acción StoreRemoteServiceCredential se asocia con un evento UserRequest pero puede ser invalidada utilizando el parámetro EVENTMASK si fuera necesario. Esta acción permite que la información sobre un servicio remoto (por ejemplo, una aplicación fuente) sea almacenada como parámetro en el contexto de la entidad corriente. La información se almacena como un NVP, y es generalmente información de seguridad relacionada con una aplicación fuente. La acción incluye un parámetro REMOTE_SERVICE, el cual es un identificador para un servicio remoto (por ejemplo, una aplicación fuente) y un parámetro CRED_TYPE que se usa para indicar el tipo de credencial que se está almacenando. El parámetro CRED_TYPE puede ser configurado para USRPWD o IDONLY. Si CRED_TYPE se configura como USRPWD, el NVP almacena tanto el nombre de usuario como la contraseña. Si se configura como IDONLY, solamente se almacena un nombre de usuario. El nombre del NVP tiene la forma “credential.<remote_service>.username|password”, donde <remote.service> es un identificador obtenido del parámetro REMOTE_SERVICE.
Una vez que las peticiones de aplicación fuente creadas han generado una o más peticiones de la aplicación fuente en respuesta a acciones UserRequestAction o a acciones DeflectUXMRRequest (además de llevar a cabo cualquier otra acción que pueda ser necesaria), son utilizadas para crear mensajes OutgoingUserRequest, los cuales son luego generalmente destinados a un servicio DT 124 de un nodo AA.
Una segunda función del UXM es componer respuestas recibidas de aplicaciones fuente para formar la aplicación compuesta. El servicio UXM del nodo CA generalmente recibe respuestas de la aplicación fuente del servicio DT 124 del nodo AA 107. Un resumen de las acciones realizadas por el servicio DT 124 del nodo AA 107 se presenta a continuación para facilitar la comprensión del funcionamiento del UXM.
El servicio DT 124 del nodo AA 107 reconoce páginas devueltas por las aplicaciones fuente usando reglas predefinidas. El proceso de reconocimiento se describe con más detalle a continuación, pero debe señalarse que primero el DT intenta reconocer páginas normales, y luego páginas de error. Suponiendo que la página es reconocida, se genera un árbol de objetos UXM representando esta página.
En referencia con la figura 31, se ilustra un simple ejemplo de conversión que puede ser llevado a cabo por el servicio DT 124 para generar un árbol de objetos UXM apropiado. Un documento HTML 222 incluye una tabla 223, que a su vez incluye un formulario 224 y una imagen 225. El servicio DT genera un árbol de objetos UXM 226 desde este documento HTML. El árbol de objetos UXM 226 incluye cuatro objetos UXM, uno para cada elemento del documento HTML 222. Puede verse que estos objetos UXM están ordenados de manera jerárquica de manera que el objeto ...Body 227 está en la raíz del árbol, un objeto ...Body.Table1 228 es secundario del objeto ...Body, y un objeto ...Body.Table1 229 y un objeto ...Body.Table1.Image1 230 son secundarios del objeto ...Body.Table1 228. De ese modo, la jerarquía del árbol de objetos UXM 226 refleja el del documento HTML 222. Debe tenerse en cuenta que cada entrada en el árbol de objetos 226 lleva el prefijo “...” para indicar que en realizaciones prácticas de la invención, los nombres de las entradas llevan como prefijo un nombre de aplicación fuente apropiado. El funcionamiento del servicio DT 124 se describe con más detalle a continuación.
Una vez creada la pluralidad de objetos UXM, estos son enviados al servicio UXM 121 del nodo CA 106.
Un mensaje es recibido por el UXM del servicio CA del nodo AA 107. Si el mensaje incluye uno o más objeto UXM, un evento UserResponse es generado por el UXM. Los objetos UXM pueden estar anidados dentro del mensaje recibido, y en tal caso, el UXM desanida los objetos UXM recibidos para crear objetos UXM individuales como corresponda. Los objetos UXM individuales creados son entonces copiados al contexto de usuario en la entidad correspondiente de la estructura de árbol UXM y forman el árbol de UXMObject. La entidad apropiada puede ser identificada usando el parámetro ID del UXMObject recibido, el cual, como se describió anteriormente, corresponderá al ID de una entidad dentro del árbol UXM.
El evento UserResponse hace que el UXM atraviese el árbol UXM comenzando por la entidad especificada por el parámetro ID del UXMObject recibido. Para cada entidad dentro del árbol que se procesa de esta manera, el UXM determina si se satisfacen todos los predicados (especificados en los grupos de datos predicados correspondientes) para cada entidad. Si los predicados se satisfacen para una determinada entidad, las acciones asociadas con dicha entidad (como se especifica en un grupo de datos de acción) son ejecutadas. Los detalles de las acciones están generalmente asociados con eventos UserResponse que se describen a continuación.
Una acción RegexTransformNVPValue se asocia por defecto con un evento UserResponse, aunque esta asociación puede ser invalidada utilizando el parámetro EVENTMASK como se describió anteriormente. Esta acción configura un NVP dentro del contexto de usuario, para una entidad destino dentro del árbol UXM. La acción especifica un parámetro SOURCENODEID, el cual por defecto va a la entidad corriente si no se especifica, y un parámetro obligatorio SOURCENAME que especifica un NVP dentro de la entidad original. La acción puede especificar de manera opcional el parámetro TARGETNODEID identificando una entidad destino y un parámetro TARGETNAME identificando un NVP dentro de la entidad destino. Se estas no son especificadas, el TARGETNODEID se configura para se igual al SOURENODEID o el TARGETNAME se configura como igual al SOURCENAME. La acción también incluye un parámetro REGEX el cual especifica una expresión regular que se aplica al NVP de origen para generar el NVP de destino.
imagen23
Las expresiones regulares serán bien conocidas para los expertos en la materia como manera de manipular strings con programas de computación. En el caso de la presente invención, las expresiones regulares del tipo utilizado en el lenguaje de programación Perl5 son usadas preferentemente, aunque será aparente para los expertos en la materia que expresiones regulares de diferentes formatos también pueden ser utilizadas en realizaciones de la presente invención,
Un CopyUXMObjectValueToTargetContext se asocia nuevamente con un evento UserResponse, pero puede nuevamente ser invalidado utilizando el parámetro EVENTMASK como se describió anteriormente. Estas acciones configuran un NVP en un contexto de usuario en la entidad destino dentro del árbol UXM. El valor al que se configura el NVP se toma de un objeto UXM en la entidad de origen. La acción toma parámetros SOURCENODEID y TARGETNODEID, los cuales especifican respectivamente las entidades de origen y destino dentro del árbol UXM. Si estos parámetros no están configurados, se utiliza la entidad actual por defecto. La acción tiene un parámetro TARGETNAME obligatorio que especifica un NVP dentro del nodo de origen que debe ser configurado.
Una acción SetUXMObjectProperties se asocia nuevamente con un evento UserResponse, pero puede ser invalidado como se describió anteriormente. La acción especifica una pluralidad de NVP que se configuran dentro de un objeto UXM en la entidad corriente del árbol UXM.
Una acción SetTargeUXMNode se asocia con un evento UserResponse, pero puede ser invalidada usando el parámetro EVENTMASK. Esta acción determina los atributos de un UXMObject en una entidad especificada por un parámetro ACTIONTARGET, el cual pasa por defecto a la entidad corriente si no se especifica ningún valor. El objeto UXM especificado por el parámetro ACTIONTARGET se actualiza para que señale un UXMTreeNode relacionado con una entidad diferente dentro del árbol de objeto UXM especificado por un parámetro TARGETNODE obligatorio.
Una acción CopyUXMObjectToTargetContext es nuevamente asociada con un evento UserResponse pero puede ser invalidada. Esta acción configura el UXMObject en una entidad especificada por un parámetro SOURCENODEID para señalar el UXMObjects especificado por una entidad dada en un parámetro TARGETNODEID. El parámetro SOURCENODEID es opcional y por defecto pasa a la entidad actual si no está especificado.
Una acción RelocatedUXMObject se asocia con un evento UserResponse y no puede ser invalidado utilizado el parámetro EVENTMASK. Esta acción configura el parámetro mode dentro de un objeto UXM asociado con una entidad especificada por el TARGETNODEID para “Reubicar”, y resulta en la reubicación del objeto (es decir, movido en lugar de copiado) a un nuevo dominante.
Una acción DeleteUXMObjectFromTargetContext se asocia nuevamente con un evento UserResponse pero puede ser invalidada. Esta acción elimina el objeto UXM asociado con la entidad especificada por un parámetro TARGETNODEID obligatorio.
Una acción ConditionalCopyOfUXMChildObjectToTargetContext se asocia con un evento UserResponse pero puede ser invalidado. Esta acción compara un valor de un NVP especificado por un SOURCENVPNAME dentro del contexto de la entidad corriente con el mismo NVP en una entidad a la que referencia un parámetro CHILDNODETOCOMPARE. Si la comparación es tal que una condición predeterminada se satisface, un objeto UXM identificado por un parámetro CHILDNODETOCOPY es copiado al contexto de una entidad identificada por un parámetro TARGETNODEID. Cabe destacar que los parámetros CHIDNODETOCOMPARE y CHILDNODETOCOPY se especifican en relación con la entidad corriente, y no como nombres de ruta absolutos.
Una acción CopyUXMObjectValue se asocia nuevamente con un evento UserResponse y no puede ser invalidado utilizando el parámetro EVENTMASK. Esta acción copia valores de un objeto UXM presente en una entidad identificada por un parámetro SOURCENODEID a un objeto UXM presente en una entidad identificada por un parámetro TARGETNODEID.
Un CopyUXMObjectValueFromTargetContext se asocia nuevamente con un evento UserResponse pero puede ser invalidado. Esta acción copiará un valor de un NVP identificada por un parámetro SOURCENODEID a un objeto UXM a una entidad identificada por un parámetro TARGETNODEID.
imagen24
Un RegexTransformUXMObjectValue es asociado por defecto con un evento UserResponse, pero esto puede ser invalidado utilizando el parámetro EVENTMASK. Esta acción recupera un objeto UXM de una entidad identificada por un parámetro SOURCENODEID, aplica una expresión regular especificada por un parámetro REGEX y escribe el valor resultante a una entidad identificada por un parámetro TARGETNODEID.
Una acción UXMObjectNotification se asocia con un evento UserResponse y no puede ser invalidado. No toma ningún parámetro. Copia un UXMObject de un contexto actual a un secundario de un punto de agregación activo que tenga el mismo nombre. Por ejemplo, si la acción se asocia con una entidad con la ruta S1.A1.A2 y el contexto activo es S1.C1, el identificador de la entidad actual (es decir, A2) se utiliza para localizar la entidad dentro del contexto activo que debería referirse al objeto UXM. En este caso, es el S1.C1.A2.
Esas acciones relacionadas con la manipulación de varias ExternalID y las que por defecto están asociadas con una acción UserResponse que se describe a continuación.
Una acción LoadExternalID puede tener su asociación invalidada usando le parámetro EVENTMASK descrito anteriormente. Esta acción recupera un ExternalID, el cual es especificado por un parámetro EXTERNALENTITYCLASS y un parámetro APPLICATION_CLASS del contexto actual y escribe este valor a un objeto UXM asociado con el contexto actual.
Una acción StoreExternalID puede nuevamente tener su asociación invalidada por el uso de un parámetro EVENTMASK. Esta acción guarda el valor del objeto UXM asociado con la actual entidad como un ExternalID que tiene una clase de aplicación identificada por un parámetro EXTERNALENTITY.
Una acción ClearExternalID puede ser invalidada y limpiar todas las ID externas del contexto de una entidad identificada por un parámetro SOURCENODEID.
Una vez que ha atravesado el árbol, y ejecutado todas las acciones ara las que los predicados son satisfechos, la ejecución regresa al punto de agregación activo de usuario (es decir, la entidad dentro del árbol UXM que recibió un evento para desencadenar las peticiones de la aplicación fuente, que a su vez generaron la respuesta desde AA). Cada nodo del árbol UXM bajo el nodo que recibió el evento UserRequest es examinado para determinar si ha recibido su objeto UXM. Cuando todas las entidades debajo de la entidad que recibió la petición han recibido sus objetos se crea un evento UXMA para provocar la agregación.
Cabe señalar que en realizaciones preferidas de la presente invención, cada nodo en el árbol UXM puede especificar que un objeto UXM es obligatorio u opcional dentro de su grupo de datos de control usando una variable booleana isMandatory, la cual pasa por defecto a FALSE cuando no se especifica. En dichas realizaciones, un evento UXMAggregate se crea tan pronto como todos los UXMObjects están presentes. No obstante, en realizaciones alternativas de la invención puede ser deseable esperar a todos los objetos UXM, luego aplicar un tiempo de espera predeterminado, a partir del que la agregación se lleva a cabo usando aquellos objetos que hayan sido recibidos.
Un evento UXMAggregate hace que el UXM atraviese todas las entidades que son secundarias de la entidad actual, y ejecuta todas las acciones especificadas en el grupo de datos de integración que son provocadas por un evento UXMAggregate. Algunas acciones que se asocian con eventos UXMAggregate se describen a continuación.
Una acción AddUXMObjectAction se asocia por defecto con un evento UXMAggregate, pero esto puede ser invalidado utilizando el parámetro EVENTMASK descrito anteriormente. Esta acción crea un nuevo UXMObject y lo agrega a una entidad identificada por el parámetro TARGETNODEID. Esta acción permite, por lo tanto, crear UXMObject en cualquier punto del árbol UXM. Un parámetro OBJECTID especifica un nombre para el nuevo UXMObject, y los parámetros OBJECTYPE y MODE especifican el tipo y modo de objeto creado como se describió anteriormente. Un parámetro RELATIVETO permite que el TARGETNODEID sea especificado en relación con una entidad especificada por el parámetro RELATIVETO, aunque si RELATIVETO no se especifica, va por defecto al nivel superior.
Como se describió anteriormente, la acción AddUXMObject crea un nuevo objeto UXM en una entidad de destino. Un parámetro INSIDETARGET permite la configuración de lo que debería suceder si un objeto UXM ya existe en la entidad de destino. Si el parámetro no se especifica, y el objeto UXM que ya está en la entidad destino es del tipo “container”, el objeto actual se suministra como secundario del objeto UXM de la entidad destino. Si el parámetro INSIDETARGET está configurado como TRUE, el nuevo UXMObject se configura como secundario del objeto UXM existente. Si el parámetro INSIDETARGET está configurado como FALSE, el objeto UXM existente se configura como secundario del nuevo objeto UXM en la entidad destino.
Una acción CreateUXMObject se asocia por defecto con un evento UXMAggregate, pero esto puede ser invalidado utilizando el parámetro EVENTMASK descrito anteriormente. Esta acción crea un nuevo UXMObject y lo agrega al contexto del usuario en la entidad de destino. Cabe señalar que todo lo que se puede lograr usando una acción CreateUXMObject puede ser creado por un AddUXMObject, el cual tiene los parámetros apropiados. Es decir, la acción del CreateUXMObject puede pensarse como un AddUXMObjectAction con algunos valores de parámetros codificados.
imagen25
Una acción AggregateChildObjects se asocia por defecto con un evento UXMAggregate. Esto no puede ser invalidado usando el parámetro EVENTMASK descrito anteriormente. Esta acción es fundamental para crear interfaces de usuario compuestas. Agrega todos los UXMObjects en contextos de entidades que son secundarias de una entidad de destino, y crea un nuevo UXMObject en el contexto de destino. Cualquier UXMObject que tiene un mode definido para eliminar es ignorado para los fines de esta acción, y todos los demás se insertan como UXMObjects anidados. Un parámetro correspondiente a la acción especifica la entidad de destino.
Una acción AggregateNamedContexts se asocia por defecto con un evento UXMAggregate, pero esto puede ser invalidado usando el parámetro EVENTMASK descrito anteriormente. Esta acción permite especificar cero o más entidades, y los UXMObjects asociados con cada una de dichas entidades son agregados para formar un nuevo UXMObject en una entidad especificada por un parámetro TARGETNODEID.
Una acción DeleteUXMObject se asocia por defecto con un evento UXMAggregate, pero esto puede ser invalidado usando el parámetro EVENTMASK descrito anteriormente. Esta acción configurará cualquier UXMObjects presentes en una entidad definida por un parámetro TARGETNODEID para tener un Mode of Delete, lo que significa que no será incluido en acciones de agregación (vea arriba). Cabe señalar que esta acción no elimina objetos, pero simplemente define su parámetro mode para que tenga un valor delete.
Una acción AddHTMLElementAction se asocia por defecto con un evento UXMAggregate, pero esto puede ser invalidado utilizando el parámetro descrito anteriormente. Esta acción se utiliza para insertar un elemento HTML en un UXMObject en el contexto de una entidad identificada por un parámetro TARGETNODEID. Para que funcione esta acción, el UXMObject debe tener un tipo de parámetro como lo especifica un parámetro ENUMERATED_HTML_ELEMENT_TYPE dentro de una acción AddHTMLElement. Los valores posibles para el parámetro ENUMERATED_HTML_ELEMENT_TYPE son html_radiobuttongroup, html_checkboxgroup y html_dropdownlist. Un AddHTMElementAction también toma parámetros que especifican un nombre, un valor y un texto para el elemento HTML. Para cada tipo de elemento HTML pueden especificarse más parámetros relevantes para ese elemento con el AddHTMLElementAction.
Si un UXMObject en un contexto destino tiene un tipo de html_radiobuttongroup, una acción AddHTMLRadioButton se asocia por defecto con un evento UXMAggregate, pero esto puede ser invalidado utilizando el parámetro EVENTMASK descrito anteriormente. Esta acción agrega un botón de radio al grupo botón de radio representado por el UXMObject.
Luego de ejecutar todas las acciones correspondientes a un evento UXMAggregate, la entidad dentro del árbol UXM que recibió la petición del usuario tiene un UXMObject que representa la página compuesta pedida, la cual puede ser pasada al servicio DT 120 del nodo CA 106.
Debe tenerse en cuenta que UXMObjects se pasan entre servicios creando una representación que se utiliza entonces como carga útil de un mensaje a ser transferido entre servicios. Esto se logra utilizando un método toXML suministrado por un UXMObject.
Cabe destacar que el UXM incluye mayor funcionalidad además de la descrita anteriormente. Las acciones provocadas por varios eventos han sido descritas anteriormente. Cabe destacar que algunas acciones pueden no ser asociadas por defecto con ningún evento particular, y en dichos casos el parámetro EVENTMASK debe ser utilizado para determinar asociación.
El servicio UXM 121 permite que scripts JavaScript sean asociados con entidades determinadas dentro del árbol, y estos scripts pueden ser ejecutados por inclusión en un grupo de datos de acción, del modo destrito anteriormente. El JavaScript es interpretado por el UXM en el momento de ejecución, y se ejecuta para llevar a cabo las funciones necesarias. Se apreciará que puede ser necesario que los scripts necesiten comunicarse con e UXM para obtener datos relevantes. Esto se logra suministrando un objeto UXMRUNTIME que permita efectivamente crear los scripts.
Los métodos expuestos por un objeto Java se pueden invocar directamente desde un script, suponiendo únicamente que el script tenga el identificador del objeto Java. Los métodos expuestos por UXMRUNTIME permiten la creación efectiva de scripts.
Un objeto UXMRUNTIME permite que se realicen varias operaciones en los objetos UXM especificados por una ruta dentro del árbol UXM. Esta ruta es un string que incluye el nombre de una entidad con un “.” añadido al principio, con el nombre de su entidad dominante añadido al principio, el cual lleva un “.” añadido al principio y el nombre de la entidad dominante. Por ejemplo, el string “MyTRN.page1.FormElement” indica una entidad “FormElement”, la cual tiene como dominante una entidad “page1” que es secundaria del una entidad TreeRootNode “MyTRN”. Debe destacarse que las rutas completamente especificadas deben ser ejecutadas desde una entidad particular dentro del árbol UXM, y como consecuencia una ruta relativa no tendrá un significado bien definido.
imagen26
Los métodos suministrados por el objeto UXMRUNTIME se describen a continuación.
Un método prepareUXMObject toma una ruta de la manera descrita anteriormente como parámetro y permite al script acceder al UXMObject especificado por la ruta. La línea de código en la que se está ejecutando el script se bloquea hasta que el UXMObject sea devuelto y entonces puede suponerse la disponibilidad del UXMObject. Este método provocará efectivamente un evento UserRequest en el nodo especificado por el parámetro de ruta, y es por lo tanto importante asegurarse de que los nodos que se van a utilizar de este modo por los scripts tienen las acciones provocadas por eventos UserRequest. Una entidad a la que se dirija este método generalmente es una página fuente, y este método crea efectivamente una petición para traer la página fuente, la cual es posteriormente suministrada al script. Si por cualquier motivo el UXMObject no puede ser provisto al script, un campo de error con el objeto UXMRUNTIME contendrá detalles de cualquier excepción lanzada. El campo de error del objeto UXMRUNTIME debe por lo tanto ser comprobado (vea abajo) antes de intentar usar el UXMObject pedido. Un método prepareUXMObjects funciona de manera análoga a prepareUXMObject, pero toma un conjunto de rutas como parámetro y devuelve todos los UXMObjects suministrados por un parámetro del método.
Un método getUXMObject recupera un UXMObject desde una entidad especificada por un parámetro de ruta. Un método setUXMObject configura un objeto UXM en una entidad especificada a un objeto UXMObject proporcionado por un parámetro del método.
El objeto UXMRUNTIME ofrece varios métodos para acceder y manipular los NVP en una determinada entidad dentro del árbol UXM. Un método setNVP permite configurar un NVP especificado en un valor determinado en una entidad dentro del árbol UXM. Un método getNVP permite que el valor de un NVP especificado se obtenga de una entidad especificada. Un método clearNVP permite a todos los NVP ser limpiados de una entidad específica. Un getRequestParameter devuelve el valor de un parámetro pedido en una entidad específica en el árbol UXM.
Se mencionó anteriormente que el objeto UXMRUNTIME incluye un campo en el cual los detalles de cualquier error son almacenados. Un método hasException devuelve el valor indicando si ocurrió una excepción durante el procesamiento, y un método getException devuelve detalles de cualquier excepción que ocurrió.
Los detalles del error también pueden ser almacenados dentro del contexto de un usuario en una entidad del árbol UXM. Se ofrecen varios métodos para acceder a dichos detalles de error. Un método getErrorDetail toma los detalles de dicho mensaje de error de una entidad especificada por un parámetro de ruta. Un método requestHadError devuelve un valor indicando si un error ha ocurrido o no. Un getErrorLodation devuelve el nombre del servicio (por ejemplo, UXM, DT, CL) donde ocurrió el error.
Un método getErrorMessage devuelve detalles del mensaje de error generado, y los métodos getMajorErrorCode y getMinorErrorID devuelven detalles de códigos de error. Todos estos métodos toman una ruta especificando una entidad dentro del árbol UXM como parámetro.
En términos generales, los scripts pueden utilizarse para reemplazar los mecanismos descritos anteriormente para hacer agregación. Cuando se usa un script, un grupo de datos de integración generalmente contendrá una sola entrada haciendo referencia a un grupo de datos de acción para el script dentro de una librería de acciones que contenga un nombre de script y detalles del script.
Si un script se utiliza para agregación, se apreciará que es importante asegurarse de que se suministra un mecanismo tal que el script sabe cuando todas las páginas fuente necesarias han sido recibidas por el UXM como UXMObjects. Esto es suministrado por una acción ScriptResponseNotification, que se suministra en una librería de acciones, y se incluye en el grupo de datos de integración de cada página fuente, y que es provocado luego del procesamiento de un evento UserRequest.
El espacio de memoria de ejecución del script incluirá detalles de todas las páginas fuente pedidas. Cuando un UXMObject correspondiente a una página fuente es recibido por el UXM, el objeto UXMRUNTIME es actualizado por el ScriptResponseNotification. El objeto UXMRUNTIME en respuesta al ScriptResponseNotification actualiza entonces el espacio de memoria de ejecución del script.
Debe señalarse que cuando se usan scripts, dos parámetros que pueden ser especificados en el grupo de datos de control asociado con una entidad tiene cierta importancia. Un parámetro EVENTORDER controla el orden en el que las entidades secundarias son procesadas. Un parámetro HANDLEERROR debe ser configurado como TRUE para permitir que el script procese cualquier error que pueda ocurrir durante la ejecución, en lugar del manejo global de errores generalmente ofrecido por el redactor.
Las funciones de scripting descritas anteriormente son suministradas por el BSF (Bean Scripting Framework), que ofrece el lenguaje de programación Java. Este framework permite que se utilicen varios lenguajes de scripting, a pesar de que como se describió anteriormente, JavaScript se utiliza en realizaciones preferidas de la presente invención. Cabe señalar que al ejecutarlo por primera vez, el script JavaScript será compilado para generar código Java Byte el cual puede ser interpretado por una Máquina Virtual de Java. Se apreciará, por lo tanto, que la ejecución de un script demorará en su primera ejecución.
imagen27
El funcionamiento del servicio DT se describe a continuación. El servicio DT incluye una pluralidad de generadores de transformación que pueden ser aplicadas a los datos para provocar la transformación de datos. Los generadores de transformación están sin estado y una única instancia de cada generador existe dentro de un servicio DT particular. Estos generadores de transformación se describirán ahora con más detalle.
Un APICallExternalizer traduce datos de representaciones internas a representaciones externas utilizando las ExternalID descritas anteriormente y dichos datos pueden ser entonces utilizados por el servicio CL para general llamadas API. Un generador de transformación DOMtoString convierte un objeto DOM representando un fichero HTML (generalmente recibido de una aplicación fuente) en un string.
Un generador de transformación IDExternalizer y un generador de transformación IDInternalizer convierten respectivamente los ID internos a ID externos y los ID externos a ID internos.
El servicio DT incluye algunos generadores de transformación para procesar y corregir HTML provisto. Una etiqueta HTML TagBalancer compensa HTML de entrada para producir HTML bien formado de salida. Un generador de transformación HTMLTidy usa el Jtidy para corregir HTML mal formado y garantiza que la salida cumple con el XHTML.
Un generador de transformación JavaSpecializedEngineExecutor ejecuta transformaciones especializadas que son codificadas en una clase Java. La clase Java especificada para este generador debe implementar una interfaz predefinida JavaEngine especificando un único método execute() que se utiliza para transformar datos, para que se pueda saber si la clase Java incluirá este método que se requiere para transformación.
Un generador de transformación Marshaller usa el marco Castor para convertir objetos Java en XML, como se describe en http://castor.exolab.org. Este generador puede ser usado para transformaciones genéricas.
Un generador de transformación PageResolver reconoce páginas de respuesta y aplica la correspondiente configuración de extracción. Primero trata de reconocer páginas normales, luego páginas de error y finalmente aplica un extracción predeterminada si no se encuentra ninguna coincidencia.
Un generador de transformación RegEx toma un string de entrada, le aplica una expresión regular y devuelve un string de salida.
Un generador de transformación RegexAggregator se utiliza para insertar nuevos elementos de interfaz de usuario en una interfaz de usuario. La configuración de este generador es un solo string de expresión regular. Algunas expresiones regulares tienen significados especiales, y serán sustituidas antes de que se aplique una expresión regular:
_VALUE_se reemplaza por el valor del parámetro OBJECT_ID en el grupo de datos de definición de generador.
_NAME_ se reemplaza con el valor del NOMBRE del parámetro en el grupo de datos de definición del generador.
Un generador de transformación RegexExtractor se usa para extraer elementos de interfaz de usuario en formato UXM usando expresiones regulares. También marca el string de entrada donde se extrajo el fragmento de string.
Un generador de transformación UIAggregator se utiliza para agregar los datos de la interfaz de usuario UXM en una manera adecuada para devolver al usuario. Generalmente solo se usa en el CA.DT. Un generador de transformación UIExtractor convierte la página de respuesta de entrada a objetos UXM que pueden ser reenviados al servicio UXM. Esto se utiliza en el AA.DT.
Un generador de transformación Unmarshaller usa el marco Castor para convertir objetos XML en Java. Un generador de transformación UxmDecomposer se usa en el proceso de agregación de datos de interfaz de usuario UXM. Descompone objetos UXM complejos en otros más simples para que la agregación pueda tener lugar en fases posteriores. Un UxmObjectToString extrae los datos de un UXMObject y lo devuelve como un string.
Un generador de transformación XMLParser toma un string de entrada y lo analiza en un árbol DOM. El árbol XML resultante es la salida del generador. Un generador de transformación XpathExtractor se utiliza para extraer elementos de la interfaz de usuario en formato UXM utilizando XPath. También marca el string de entrada donde se extrajo el fragmento. Se usa generalmente en el UXM. Un generador de transformación XSLTransformer toma un documento XML de entrada, le aplica unas hojas de estilo XSL, y devuelve un documento XML de salida.
Los generadores de transformación indicados anteriormente ofrecen una variedad de funciones básicas que se necesitan para un servicio DT. Los generadores de transformación se utilizan para transformar actores que actúan sobre los datos para transformarlo. Hay esencialmente dos tipos de actores de transformación: actores atómicos utilizan generadores de transformación directamente, mientras los actores de grupo utilizan otros actores de transformación.
imagen28
Un actor atómico mantiene datos de configuración indican cómo debe ser utilizado un generador de transformación para llevar a cabo las transformaciones necesarias. Por ejemplo, un actor atómico que utiliza un generador de transformación XSL puede ser configurado usando una hoja de estilo XSL. La salida será entonces un objeto DOM (vea arriba). Cuando es llamado, el actor pasará los datos de entrada y los datos de configuración al generador de transformación para efectuar la transformación.
Un actor atómico tiene un tipo de parámetro configurado como “base”, lo cual indica que es un actor atómico. Tiene una descripción textual de las transformaciones que realiza. Tiene un parámetro EngineID que identifica uno de los generadores de transformación presentado anteriormente, el cual es para ser utilizado por el actor. Un parámetro de configuración se representa por un string. Esto será generalmente una expresión regular o alternativamente un nombre de fichero de una hoja de estilo XSL. Algunos actores tendrán múltiples salidas, mientras que otros siempre tendrán un único valor de salida. Esto se representa por un parámetro MultipleOutputs, el cual se configura como TRUE si se permiten múltiples salidas, o FALSE si no se permiten MultipleOutputs. Si un actor para el cual MultipleOutputs está configurado como FALSE produce múltiples datos de salida en el momento de ejecución, los datos se fusionan utilizando una clase Java especificada por el parámetro DataMerger. Un parámetro Timeout suministra un límite de tiempo, preferentemente en milisegundos.
Un actor en grupo combina uno o más actores de transformación. Los actores de transformación que se agrupan pueden ser actores atómicos o actores grupos, y pueden ser ejecutados en paralelo o de manera consecutiva, o como alternativas.
Un actor en grupo tiene un tipo de parámetro inicializado como “grupo”, un parámetro de descripción que especifica una descripción textual y un parámetro TransformationID, el cual es una lista de actores contenidos dentro del actor grupo. Un parámetro GroupType puede tomar valores de “sequence”, “parallel” y “switch”. Si el parámetro GroupType está configurado como “sequence”, todos los actores de transformación se ejecutan de manera secuencial, en el orden en el cual están en la lista en un parámetro Transformation ID. Si el parámetro GroupType está configurado como switch, un único actor será elegido en el momento de ejecución para actuar sobre los datos de entrada pasados. Un parámetro LateInitialization toma un valor booleano indicando si se debe
o no utilizar la inicialización tardía. Es decir, este parámetro indica si el generador de transformación debe o no ser inicializado al inicio (si LateInitialization está configurado como FALSE), o cuando el generador de transformación es utilizado por primera vez (si LateInitialization está configurado como TRUE). Un actor de grupo también tiene MultipleOutputs, parámetros DataMerger y Timeout, como se describió anteriormente en referencia a los actores atómicos.
En realizaciones preferidas de la presente invención, algunos actores atómicos y algunos actores grupos son suministrados por defecto. Los detalles de estos actores de transformación se describen a continuación.
Los actores atómicos suministrados por defecto son los siguientes. Un actor NOP no realiza ninguna operación, lo cual puede ser necesario en el DT en casos cuando no se necesita transformación alguna. Otros tres actores atómicos más simplemente ponen generadores de transformación a disposición como actores. Un actor HTMLTagBalancer pone el HTMLTagBalancer generador de transformación disponible como actor, un actor UXMObjectDecomposer es utilizado por el servicio DT del CA y pone al generador de transformación UXMObjectDecomposer disponible como un actor, y un actor XMLParser pone al generador de transformación XMLParser disponible como un actor.
Un actor PageResolver es utilizado por el servicio DT del AA para reconocer páginas devueltas por aplicaciones fuente. Recoge detalles de las páginas para que sean reconocidas desde las partes correspondientes del IDM, como se describió anteriormente. Un actor UIExtractor es utilizado por el servicio DT del AA para convertir páginas en UXMObjects, y nuevamente, la correspondiente información de configuración es ofrecida por el IDM.
Un actor UIAggregator es usado por el servicio DT del CA para convertir objetos UXM en una manera adecuada para devolver a un usuario como parte de una aplicación compuesta. Un actor URLRewrite se utiliza para actualizar cualesquiera URL, formas o marcos en una página que debe ser devuelta a un usuario.
Una pluralidad de actores de grupo son también suministrados por defecto. Un actor sequence.IncomingUserResponse es una secuencia de actores de transformación que pueden ser aplicados a un mensaje entrante de respuesta al usuario, para convertir la respuesta de página en forma UXM. Aplica el actor PageResolver y el actor UIExtractor descritos anteriormente.
Un actor sequence.OutgoingUserResponse es una secuencia de actores de transformación para aplicar a una respuesta típica de usuario de salida para convertir el árbol de objetos UXM en la página resultante para devolver al usuario. Aplica un actor para convertir un árbol UXMObject utilizado en un árbol XML y luego agrega los varios componentes de acuerdo con la información en el árbol XML. El resultado se convierte en un string que representa la página que se devuelve al usuario.
imagen29
Un actor sequence.UIAggregation incluye una secuencia de actores de transformación para aplicar para agregar los componentes de una página en la página final. Aplica otros actores de transformación para descomponer y agregar y luego usa el actor atómico UIAggregator descrito anteriormente.
Una secuence.UIAggregation.DecomposeAndAggregate es una secuencia de actores de transformación que se aplica para preparar los elementos de la página para agregación. Primero descompone el UXMObject superior usando el actor UXMObjectDecomposer. Luego desciende por el árbol de manera recursiva repitiendo la misma acción.
Un switchgroup.UIAggregationRecursion es un grupo conmutador de actores de transformación. Recorre la jerarquía de UXMObject, eligiendo en cada fase si el UXMObject contiene otros UXMObjects o no.
Un actor sequence.UIEextraction incluye una secuencia de actores de transformación que se aplica para extraer los componentes de una página en un árbol UXMObject. Descompone y agrega, y luego utiliza el actor atómico UIAggregator.
Un actor switchgroup.UIExtractionRecursion es un grupo conmutador de actores de transformación. Recorre la jerarquía UXMObject, eligiendo en cada fase si el UXMObject contiene otros UXMObjects o no.
El funcionamiento del servicio DT dentro del nodo AA correspondiente a una aplicación fuente específica se ilustra en la figura 32. Los datos se reciben de una aplicación fuente indicada por una flecha 231. Estos datos pasan primero a un generador de transformación 232, el cual hace las modificaciones necesarias a las referencias URL incluidas en los datos fuente recibidos. Esto puede lograrse utilizando, por ejemplo, el generador de transformación RegEx descrito anteriormente. Un segundo generador de transformación 233 realiza las modificaciones genéricas a la URL que puedan ser necesarias, y puede ser nuevamente el generador de transformación RegEx descrito anteriormente. Un generador de transformación con compensador de etiquetas HTML 234 (del tipo descrito anteriormente) se utiliza entonces para asegurar que el HTML producido está bien formado.
La salida del compensador de etiquetas HTML es introducida en un actor de grupo 235, el cual está configurado para reconocer y procesar la página fuente recibida. El actor de grupo 235 incluye un generador de transformación adecuado PageResolver 236 el cual está configurado para reconocer páginas predefinidas, y un actor de grupo 237 el cual incluye uno o más de los generadores de transformación descrito anteriormente, los cuales actúan juntos para extraer elementos de la interfaz de usuario de las páginas reconocidas.
Habiendo descrito la configuración del redactor, y los servicios clave contenidos dentro de sus nodos, su funcionamiento suministrando aplicaciones compuestas, como se detalla anteriormente con referencia a la figura 15, se describe ahora con más detalle, haciendo referencia a las figuras 14 y 15.
El procesamiento comienza generalmente cuando un usuario que utiliza el navegador web 126 hace una petición HTTP que es dirigida posteriormente al servidor web 12. El servlet 117 funcionando en el servidor web 12 determina si la URL introducida se relaciona o no con una página suministrada por el redactor. Si se determina que la URL no incluye al redactor, el servidor web obtiene y muestra la página web pedida de manera convencional. Si la URL es suministrada por el redactor el servlet 117 intercepta y procesa la petición HTTP. Esto implica convertir la petición HTTP en un mensaje IncomingUserRequestJMS.
Será apreciado que algunas peticiones necesitarán autenticación. La autenticación se maneja utilizando cookies. Cuando un usuario intenta primero acceder a una página que requiere autenticación, la petición será interceptada por el servicio CL del nodo CA, y este servicio determinará si la petición incluye o no cualquier cookie necesaria. Si dicha cookie no está presente en la petición, el usuario será representado con una página en la cual se introducen datos de autenticación adecuados (por ejemplo, nombre de usuario y contraseña). Estos datos se envían al servidor web, y en adelante al servicio ALF 126 del nodo ALF 108, donde la entrada de datos de autenticación se comprueba contra datos almacenados en la base de datos ALF. Suponiendo que este proceso de autenticación es exitoso, se procesa la petición original del usuario. Una cookie se guarda en el ordenador del usuario, y en caso de peticiones posteriores, esta cookie se leída por el servidor web, reenviada al servicio CL del nodo CA, y luego reenviado al servicio ALF 126 para permitir la autenticación usando la base de datos ALF 110. La siguiente descripción supone que toda la autenticación necesaria ha sido realizada con éxito.
La creación del mensaje JMS se lleva a cabo como se especifica por los datos de configuración correspondientes dentro del IDM. Una vez creado un mensaje IncomingUserRequest apropiado y determinado dónde debe ser enviado utilizando un parámetro de destino dentro del grupo de datos weblistener 210 (figura 28) es entonces necesario localizar una instancia apropiada del servicio de destino que pueda aceptar el mensaje creado.
El receptor realiza una compensación de carga con JMS para que una pluralidad de instancias de un servicio de destino puedan ser utilizadas al mismo tiempo, pide que sea distribuido de manera efectiva entre la pluralidad de redactores. Las propiedades del fichero correspondiente al receptor (descrito anteriormente) incluye un parámetro resolverprotocol.roundrobin.target que especifica un algoritmo de compensación de carga, para ser utilizado como tal (por ejemplo, el algoritmo round robin). Este parámetro también especificará cuantas instancias del destino se pueden esperar (en este caso el servicio CL de un CA).
imagen30
Cuando una instancia del servicio de destino se inicia, se declara a sí misma usando un mensaje JMS apropiado, y el receptor sabrá entonces que pueden enviarse los mensajes a dicha instancia del servicio de destino. Cuando un receptor necesita enviar un mensaje a una instancia del servicio destino (por ejemplo, al servicio CL de un CA) un mensaje de difusión es enviado a todas las instancias del servicio registradas con el receptor. El receptor entonces esperará una respuesta de todos los destinos registrados, y cualquier respuesta de destinos no registrados será simplemente ignorada. Cuando todas las respuestas esperadas han sido recibidas, el receptor elije una instancia del servicio de destino de acuerdo con el algoritmo especificado, y el IncomingRequestMessage se envía a la instancia seleccionada.
Luego de seleccionar un destino para recibir mensajes de un usuario determinado, el receptor garantiza que los mensajes posteriores de ese usuario se dirigen al mismo redactor. Este no es necesariamente el caso y se decide por un parámetro add_affinity dentro del IDM. Del mismo modo, la configuración IDM para el redactor tiene un parámetro add_listener_affinity que garantiza que los mensajes de un usuario determinado son siempre dirigidos al mismo receptor.
El mensaje IncomingUserRequest JMS transmitido será recibido por el servicio CL 199 del nodo CA 106 por medio de su servicio ML 118, el cual es responsable del paso de mensajes. Al recibir el mensaje IncomingUserRequest, el CL puede realizar la autenticación utilizando un registro de parámetros especificados en el mensaje IncomingUserRequest, usando el servicio ALF del nodo ALF del modo que se describió anteriormente. Suponiendo que la autenticación es exitosa, el mensaje simplemente pasa al servicio DT 120 del nodo CA. El paso de mensajes entre servicios se determina por los datos almacenados dentro de los objetos message, como se describió anteriormente.
El servicio DT 120 recupera datos de configuración pertinente a las acciones requeridas en respuesta a la recepción de un mensaje IncomingUserRequest. Los datos son recuperados accediendo a la estructura de datos IDM (figura 22) y localizando el grupo de datos DT.Applications 153. El grupo de datos 154 pertinente a la aplicación compuesta especificada en el mensaje IncomingUserRequest es entonces ubicado y la acción de referencia 158 a la que hace referencia el mensaje IncomingUserRequest del grupo de datos 154 se identifica y realiza entonces.. Al recibir un mensaje IncomingUserRequest, generalmente no es necesaria la transformación, y por lo tanto el servicio DT 120 no realiza ninguna operación, como lo especifica el grupo de datos 158. El mensaje se pasa entonces al servicio UXM 121 del nodo CA 106.
El mensaje IncomingUserRequest generalmente es generado desde una petición HTTP como se describió anteriormente. Un fragmento HTML adecuado para una petición de ese tipo se muestra en la figura 33. Puede verse que la tercera línea especifica que el nombre de la clase de aplicación de la aplicación compuesta es “CompAppl”. La cuarta línea especifica que la petición requiere modificación por parte de la UXM, la quinta línea especifica un nodo en la estructura de árbol IDM relevante a la aplicación y la sexta línea especifica un nodo en el IDM relevante a la página que generó la petición. Todos estos datos están encapsulados dentro del mensaje IncomingUserRequest.
La UXM localizará un nodo “CompAppl” dentro del árbol UXM, descenderá por la estructura de árbol, ejecutando todas las acciones para las que se satisfacen los predicados. Estas acciones generalmente implicarán crear uno
o más mensajes OutgoingUserRequest dirigidos a la aplicación fuente correspondiente, los cuales son reenviados a las aplicaciones fuente por medio del nodo AA 122, y estos mensajes son por lo tanto reenviados al nodo AA.
En este ejemplo, el nodo AA está presente dentro del mismo proceso del CA, y por lo tanto puede ser localizado sin problemas. No obstante, si no existe dicho nodo dentro del proceso actual. El mensaje o los mensajes son reenviados al servicio ML 118 del nodo CA 106 y el servicio ML intenta entonces localizar un nodo AA apropiado dentro de un proceso diferente utilizando JMS, como se describe más arriba con referencia a la figura 12D. Cuando un nodo adecuado ha sido localizado, el mensaje o los mensajes son reenviados al servicio ML de dicho nodo, y en adelante al servicio CL de dicho nodo. Utilizar JMS de esta manera permite comunicación interproceso conveniente, independientemente de la distribución de los procesos entre máquinas físicas.
Un mensaje OutgoingUserRequest es recibido por el servicio DT 124 del nodo AA 107. El servicio DT debe transformar el OutgoingUserRequest de una manera comprensible por la aplicación fuente de destino. En muchos caso, no se necesitará ninguna acción del DT en esta fase como se muestra en la configuración del ejemplo de la figura 23, donde puede verse que la entrada OutgoingUserRequest del grupo de datos DT.App.firstbyte 161 hace referencia a una acción de no operación 162. El mensaje OutgoingUserRequest es por lo tanto reenviado al servicio CL 123 del nodo AA 107.
El servicio CL 123 usa datos de configuración almacenada en el IDM para localizar un grupo de datos que representa la correcta aplicación fuente (por ejemplo, los grupos de datos g2config 145, 147 de la figura 21). Este grupo de datos especificará cualquier información de autenticación la cual debe incluirse en una petición a dicha aplicación fuente. Para obtener dicha información de autenticación el servicio CL 123 solicita datos de autenticación del servicio ALF 126 del ALFNODE 108, y estos datos son luego recogidos desde la base de datos ALF como lo indican los datos en el IDM.
imagen31
Como se describió anteriormente, la configuración IDM para un servicio CL también especifica los parámetros que se utilizan para conectarse con la aplicación fuente correspondiente (especificada en un grupo de datos de conexión). El servicio CL utilizará estos parámetros para determinar el formato de las peticiones, que debe ser generado para la transmisión hacia adelante hacia la aplicación fuente. Por ejemplo, esto puede ser una petición HTTP dirigida a un puerto específico de un host específico. Esta petición se transmite entonces a la aplicación fuente.
La aplicación fuente procesará de manera convencional los mensajes de petición recibidos, y a la vez el servicio CL 123 del nodo AA 107 recibirá la salida de datos en respuesta a la petición.
El servicio CL 123 recibe los datos de la aplicación fuente y la reenvía al servicio DT 124 del nodo AA 107. En esta fase, el servicio DT 124 debe actuar sobre los datos recibidos para transformarlos en una manera adecuada para el envío al servicio UXM 121 del nodo CA 106. Este procesamiento será del tipo que se ilustró en la figura 32, más arriba.
Los UXMObjects creados son luego reenviados al servicio UXM 121 del nodo CA 106. El UXM registrará los objetos recibidos dentro del árbol UXM como se describe más arriba, y cuando todos los datos necesarios han sido recibidos, tendrá lugar la agregación para crear uno o más UXMObjects representando la página compuesta solicitada. Los UXMObjects son luego reenviados al servicio DT 120 del nodo CA 106, en uno o más mensajes que contienen versiones XML de los UXMObjects creados.
El servicio DT 120 del nodo CA 106 debe recibir entonces los mensajes, volver a crear los UMXObjects y usar datos de la configuración IDM para determinar cómo convertir los UMXObjects recibidos en una forma adecuada para salida al usuario. Entre las formas adecuadas podrían figurar HTML y texto simple.
Cabe destacar que usando un formulario interno hasta que se procese la página compuesta es procesada por el servicio DT 120 del nodo CA 106, el sistema descrito más arriba puede ser fácilmente adaptado para manejar diferentes tipos de salidas, simplemente añadiendo datos de configuración apropiados al IDM para el servicio DT
120. Esto permite un desacoplamiento efectivo del redactor del formato de salida que se requiere. Un desacoplamiento similar puede ser suministrado cuando se manejan datos de entrada.
Los datos de salida creados son luego reenviados por el servicio DT 120 al servicio CL 119. El servicio CL usa la estructura de datos IDM para determinar el protocolo que debería usarse para devolver la página compuesta al usuario, generalmente a través del servlet 117 en el servidor web 12.
Haciendo referencia nuevamente a la figura 14, el funcionamiento de la terminal de administración 112 el cual está conectada al servicio 13 por medio de la conexión 113 se describe a continuación. Es preferible que la terminal de administración 112 esté conectada al servidor por una conexión de red y puede utilizarse adecuadamente una conexión convencional de TCP (transmission control protocol) / IP (Internet protocol) del tipo usado en las redes de Internet. La terminal de administración puede funcionar ejecutando un navegador de Web y accediendo un documento HTML adminconsole que es suministrado en un número de puerto adecuado para el servidor (por ejemplo, el puerto 8080).
Cuando un usuario inicia una sesión en el servidor de administración, es posible crear usuarios y roles. Los usuarios son asignados a los roles, y los roles a los cuales un usuario es asignado determina las acciones que pueden ser realizadas por un usuario. Los roles especifican comandos que pueden ser ejecutados por sus usuarios y pueden también especificar nodos secundarios que hereden sus propiedades. Cuando los roles han sido creado, los usuarios pueden ser asignados a los roles creados. Los usuarios pueden ser suprimidos de roles como sea necesario, y eliminados si ya no son necesarios. Si un rol es eliminado, los datos para todos los usuarios asignados a ese rol son automáticamente actualizados. La terminal de administración puede ser utilizada para configurar las credenciales de servicio de un usuario, que son los datos de seguridad que un usuario necesita para acceder a varias aplicaciones fuente utilizadas dentro de las aplicaciones compuestas.
Se ha descrito más arriba que el UXM y otros servicios del redactor juntos procesan las peticiones de usuario desde una aplicación compuesta y generan peticiones apropiadas para aplicaciones fuente. También se ha explicado que el IDM contiene datos de configuración, y que estos datos pueden ser especificados utilizando un fichero como el que se ilustra en la figura 29. No obstante, especificar los datos de configuración de esta manera es relativamente difícil y requiere usuarios con experiencia que pueden crear y manipular los ficheros de datos de configuración. La representación de esta invención ofrece un mecanismo para generar ficheros de datos configuración desde modelos de manera automática. Los modelos se crean representando cada aplicación fuente y estos modelos se combinan para modelar el comportamiento de la aplicación compuesta.
La figura 34 representa un resumen de dicho modelado. Una primera aplicación fuente se representa con un primer modelo de aplicación fuente 250, y una segunda aplicación se representa por un segundo modelo de aplicación fuente 251. Estos modelos representan todo o parte de las respectivas interfaces suministradas por la primera y segunda aplicación. Estos modelos se combinan para crear un modelo de aplicación compuesta 252, y este modelo se usa para genera datos de configuración para incluir en el IDM.
imagen32
Los modelos pueden ser convenientemente implementados especificando las clases Java apropiadas y creando objetos que son instancias de dichas clases.
La figura 35 ilustra clases utilizadas para crear un modelo de aplicación fuente. Un componente clave de todos los modelos de aplicaciones fuentes es una clase SourceFlowItem 253. Cada modelo de aplicación fuente contiene por lo menos un objeto SourceFlowItem. Un primer objeto SourceFlowItem siempre representa el flujo completo de la aplicación de una aplicación fuente, sin detalles definidos. Este objeto representa un punto de entrada a la interfaz del usuario de esa aplicación fuente. Entonces más objetos SourceFlow definen más detalles. Las instancias de la clase SourceFlowItem hacen referencia a otras instancias de la clase SourceFlowItem por medio de una matriz Next que especifica uno o más objetos SourceFlowItem, los cuales pueden ser usados para modelar el flujo de la aplicación por medio de una gráfica de objetos SourceFlowItem.
Cada objeto SourceFlowItem también hará referencia a una instancia de una clase SourcePage 254 por medio de una variable ItemEntryPage, la cual representa una página fuente conocida dentro de las aplicaciones fuente, como se describirá con más detalle a continuación. La clase SourceFlowItem 253 también incluye una matriz ItemEntryConditions que referencia una o más instancias de la clase FlowControlConditions 255, y una variable SourceApplication que referencia una instancia de la clase SourceApp 256, que representa la aplicación fuente a la cual se refiere el SourceFlowItem.
A continuación se describirán más detalles de la clase FlowControlCondition 255. Cada objeto FlowControlCondition puede especificar una de tres categorías de condición. Una condición UserInRole se usa para modelar la aplicación del rol de usuario. Una condición SourceFlowItemExit se usa para garantizar que se tendrá acceso a algunos objetos SourceFlowItem solamente si se sigue una ruta bien definida a través de una aplicación. Dos condiciones finales se relacionan con valores de parámetro dentro de la petición de usuario. Una condición RequestParameterExists garantiza que un parámetro especificado existe, mientras que una condición RequestParameterValue garantiza que un parámetro especificado tiene un valor especificado.
Las instancias de la clase SourcePage 254 hacen referencia a una o más instancias de una subclase de una clase AbstractPageIdentification 257 para permitir la identificación de una página fuente. Una instancia de una clase QueryParameterIdentificationRule 258 se usa para especificar los datos de configuración para reconocer la página. Una instancia de la clase RegexParameterIdentificationRule 259 se usa para especificar una expresión regular que se usa para permitir el reconocimiento.
Las instancias de una clase PageElement 260 representan un elemento extractable dentro de una página fuente. Las instancias de la clase PageElement son referencias de objetos SourcePage apropiados. Por ejemplo, un objeto PageElement puede representar algo de texto o una imagen dentro de una interfaz de usuario suministrada por una aplicación fuente. Los objetos PageElement a su vez hacen referencia a cero o más instancias de una clase de atributo PageElementAttribute 261, el cual se utiliza para almacenar datos tales como color de fondo, nombres de cuadros de texto, y etiquetas asociadas con elementos de una página específica. Los objetos PageElements se pueden asignar a una pluralidad de tipos que están representados por una instancia de una clase PageElementTypeAttributeListMap 262, el cual a la vez contiene cero o más instancias de una clase PageElementType 263.
Las instancias de la clase SourceFlowItem 253 también hacen referencia a una instancia de la clase 264 PageRequest que se utiliza para modelar detalles de recuperación del objeto SourcePage referenciado. La clase PageRequest incluye un string que indica cuándo debería efectuarse la petición (por ejemplo, HTTP GET o HTTP POST) y un string más que suministra una ruta a la que debería dirigirse la petición. Un objeto PageRequest también referencia una instancia de una clase StaticRequestParameter 266 se usa para representar un NVP fijo, una clase UserRequestParameter 267 representa un parámetro especificado por el usuario, y una clase LinkedRequestParameter 268 representa un parámetro que referencia una instancia de la clase PageElementAttribute 261.
Una vez descrita la estructura de un modelo de aplicación fuente, un modelo de aplicación compuesta se describe ahora en relación a la figura 36. Una aplicación compuesta está representada por una o más instancias de una clase CompositeFlowItem 269. Esta clase suministra una variable para permitir que un objeto CompositeFlowItem haga referencia a cero o más instancias de esa clase y así poder crear un flujo de objetos CompositeFlowItems. Nuevamente, una primera instancia de la clase CompositeFlowItem 269 representará el flujo total de la página compuesta sin definir ningún detalle. Los objetos CompositeFlowItem se refieren a una instancia de la clase FlowControl Condition 255 como se describe en relación a la figura 35, aunque debe señalarse que no se puede especificar ningún SourceFlowItemExit, dado que una aplicación compuesta no aplica un flujo de página.
La clase CompositeFlowItem 269 es una superclase para una clase ExistingFlowItem 270 y una clase NewFlowItem 271. La clase ExistingFlowItem 270 se utiliza para incluir parte de una aplicación fuente dentro de una aplicación compuesta sin ser modificada. Esto puede ser una parte o el total de una aplicación fuente modelada. La clase ExistingFlowItem 270 referencia una instancia de la clase SourceFlowItem 253.
imagen33
La clase NewFlowItem 271 se usa para modelar páginas compuestas que forman aplicaciones compuestas. Tiene una sola variable, que se utiliza para hacer referencia una instancia de una clase CompositePage 272. La clase CompositePage 272 incluye una matriz de objetos PageElement que se utilizan para crear una página compuesta. Ese tipo de objetos PageElement pueden representar elementos de página desde una pluralidad de aplicaciones fuente.
La clase CompositePage 272 también incluye una matriz de instancias de una clase RequestParameterMapping 273, la cual se usa para identificar parámetros utilizados para recibir la CompositePage, y sus correlaciones para solicitar parámetros que son utilizados para recuperar páginas fuente para suministrar los objetos PageElement necesarios. La clase CompositePage 272 también referencia una clase PageElementManipulation 274, la cual se utiliza para manipular PageElements para crear páginas compuestas. La clase PageElementManipulation también referencia una instancia de la clase PageElementLocation 275, la cual suministra una ubicación para la página elemento luego de la manipulación. La locación puede ser especificada como UNCHANGED, en cuyo caso el dominante del elemento en la manipulación determinará la localización. De manera alternativa, la locación puede ser configurada como AFTER, BEFORE o REPLACE, todo relativo a un objeto PageElement especificado. La ubicación también puede ser especificada como TOPLEVEL, en cuyo caso el elemento está posicionado en el nivel más alto dentro de la página compuesta.
Los detalles de subclases de la clase PageElementManipulation 274 se describen ahora, subclases las cuales se utilizan para representar manipulaciones específicas. Una clase InsertPageElement 276 se utiliza para suprimir un elemento de página y no especifica variables adicionales. Se usa un elemento clase InsertPageElement 277 para insertar un elemento de página en la ubicación especificada y no especifica ninguna variable más.
Una clase MergePageElements 278 se usa para representar una manipulación que fusiona el objeto PageElement especificado dentro de la clase PageElementManipulation con un objeto PageElement especificado. Esta clase también usa una clase MergeDetailEnumeratedList 279 para especificar la ubicación del objeto PageElement especificado dentro de la clase MergePageElement 278 relativa a aquella especificada dentro de la clase PageElementManipulation 274. La clase MergeDetailEnumeratedList 279 puede tomar valores de AFTER, BEFORE y TOPLEVEL.
Una clase SetActionElementTarget 280 es también una subclase de la clase PageElementManipulation 274. Esta clase se usa para modificar un PageElement de modo que su destino apunte a una instancia de la CompositeFlowItemClass 269. Esto permite que los objetos PageElement existentes sean utilizados mientras se modifica el flujo como lo requiere la aplicación compuesta.
Una clase SetElementAttributeValue 281 es una clase abstracta que tiene una clase ValueFromPageElementAttribute 282 y una clase ValueFromRequestParameter 283 como subclases. La clase SetElementAttributeValue suministra una variable que se utiliza para referirse a un objeto destino PageElementAttribute. La clase ValueFromPageElementAttribute 282 se utiliza cuando el destino PageElementAttribute debe ser configurado utilizando un PageElementAttribute especificado dentro de una variable adecuada. La clase ValueFromRequestParameter 283 se utiliza cuando el destino PageElementAttribute debe ser configurado usando un parámetro solicitado.
Una vez descritas las clases de Java utilizadas por modelamiento de aplicación fuente y compuesta, la creación de dichos modelos se describe ahora en relación a un ejemplo de aplicación compuesta que está hecho de dos aplicaciones fuente.
En referencia a las figuras 37A y 37B, una empresa comercial usa dos paquetes de software que deben ser integrados, un sistema de registro de clientes (sistema CRM) 285 y un sistema de orden 286. Como se ilustra en la figura 37A, antes de la implementación de una solución de aplicación compuesta, un usuario utiliza el sistema CRM 285 y el sistema de orden 286 de manera independiente. Para utilizar el sistema CRM, un usuario introduce detalles del inicio de sesión en una página de inicio de sesión 287 y —suponiendo que la validación tiene éxito— se le presenta al usuario una página de criterios de búsqueda 288. Es posible introducir criterios de búsqueda para luego visualizar los resultados de la búsqueda en una página de resultados de la búsqueda 289. A partir de la página de resultados de la búsqueda, el usuario puede terminar sesión para volver a la página de inicio de sesión 287 o reiniciar los criterios de búsqueda y volver a la página de criterios de búsqueda 288.
Para usar el sistema de orden 286, el usuario nuevamente introduce los detalles en una página de inicio de sesión 290, y luego de validación adecuada, los criterios de búsqueda pueden ser introducidos en una página de criterios de búsqueda 291 y los resultados pueden mostrarse entonces en una página de resultados de búsqueda
292. El usuario puede entonces cerrar la sesión para regresar a la página de inicio de sesión 290 o reconfigurar los criterios de búsqueda para regresar a la página de criterios de búsqueda 291.
Analizando el uso de las aplicaciones 285, 286 puede determinarse que la productividad aumentará ofreciendo un único procedimiento de inicio de sesión que cubra tanto el sistema CRM 285 como el otro sistema 286. Además, un botón puede ser suministrado dentro de la página de resultados de búsqueda 289 del sistema CRM 285 para permitir ordenar la información que debe ser recuperada utilizando la entrada de los criterios de búsqueda en la pantalla de criterios de búsqueda 288. La figura 37B ilustra una aplicación compuesta 293 que suministra estos atributos. La aplicación compuesta 293 suministra una página de inicio de sesión 294 la cual permite iniciar la sesión en el sistema CRM 285 y el sistema de orden 286. Luego de iniciada la sesión, la página 288 del sistema CRM 285 se muestra, y los resultados son mostrados usando la página de búsqueda de resultados 289 que se describe más arriba. No obstante, usando la aplicación compuesta 293, es posible mostrar la página de resultados de orden 292 sin iniciar la sesión nuevamente, sino únicamente presionando un botón apropiado suministrado en la página de resultados CRM 289.
imagen34
La especificación y creación de la aplicación compuesta 293 se describen a continuación. La creación del modelo se realiza usando software de la aplicación que suministra una interfaz de usuario gráfica (GUI). La figura 38 ilustra una ventana de exploración 295 que forma parte de la GUI, y la cual permite a las partes componentes de una aplicación compuesta ser visualizadas y editadas. La aplicación compuesta se muestra como una estructura de árbol hecha de ficheros y objetos. En el nivel más alto, la aplicación compuesta está representada por un proyecto 296 titulado "FBS1". El proyecto incluye un fichero AA 297 que es utilizado para especificar detalles de las aplicaciones fuente (dado que el nodo AA se encarga de las aplicaciones fuente, como se describe más arriba), y una carpeta CA 298 la cual se usa para especificar detalles de la aplicación compuesta. Tanto la carpeta AA 297 como la carpeta CA 298 contienen un número de carpetas y objetos que se usan para moldear partes diferentes de la aplicación compuesta). Estas se describen en más detalle a continuación.
Cuando se crea una aplicación compuesta, un proyecto debe ser establecido primero seleccionando una opción de proyecto en un fichero suministrado por una barra de menú. Un paquete debe también ser establecido para proporcionar espacio de almacenamiento en uno o más directorios donde se guardan los datos relacionados con el proyecto. Las aplicaciones original y compuesta son entonces configuradas. La configuración de la aplicación fuente se describe ahora.
En referencia nuevamente a la figura 38, puede verse que la carpeta AA 297 contiene una carpeta de sistema 299 que almacena los datos relacionados con el sistema CRM 285 (figura 37A) y una carpeta de orden de sistema 300, la cual almacena datos relacionados con el sistema de orden 286 (figura 37B). El sistema CRM se define por un objeto de aplicación fuente 301, una carpeta de conexión 302, una carpeta de flujos originales 303, y una carpeta general 304. Para crear el icono de la aplicación 301, un usuario selecciona un nuevo botón suministrado por la GUI.
Los flujos originales representan flujos posibles a través de partes de un aplicación fuente o compuesta. Los flujos originales actúan efectivamente como los controladores de páginas originales. Cada flujo original comienza con una página original identificada, y puede entonces haber una o más páginas originales con las que el usuario interactúa, pero de la que la aplicación compuesta no tiene conocimiento. Por ejemplo, con referencia a la figura 39, puede verse que una aplicación se define en términos de cuatro flujos originales. Un primer flujo original 307 incluye una página original identificada 308, y tres páginas originales más 309. Un segundo flujo original 310 incluye una sola página original identificada 311, y un tercer flujo original 312 incluye una página identificada original 313 y dos páginas originales más 314. Un cuarto flujo original 315 incluye una página original identificada 316 y dos páginas originales más 317. Permitiendo flujos originales que contengan algunas páginas no identificadas, solamente algunas partes de cada aplicación fuente de interés deben ser explícitamente modeladas.
La figura 40 ilustra otra vista más de parte de la ventana de exploración 295 en la cual se ilustran los objetos dentro de la carpeta de orden de flujo 303. Puede verse que la carpeta 303 que contiene los flujos originales incluye detalles para iniciar la sesión de flujo original dentro de una carpeta de inicio de sesión 318, un flujo original de búsqueda dentro de una carpeta de búsqueda 319, y un flujo original de resultados dentro de una carpeta de resultados 320. Cada una de estas carpetas incluye una sola página original identificada, y ninguna página no identificada. Cada flujo original corresponde a una página respectiva del sistema CRM 285 como lo ilustra la figura 37A.
La figura 40 ilustra los contenidos de la carpeta de resultados 320. Puede verse que esa carpeta incluye un objeto de flujo de resultado 321 que representa el flujo original, un objeto página de resultado 322 el cual representa la página original identificada dentro del objeto de flujo de resultados 321, una carpeta de solicitud de página 323, y una carpeta de identificador de página 324.
Un objeto de flujo original es creado y sus detalles se especifican utilizando el cuadro de diálogo 325, parte del cual se ilustra en la figura 41. Un cuadro de texto 326 se utiliza para especificar una aplicación fuente con la que está asociado el flujo original. En ese caso, puede verse que la aplicación de entrada se corresponde con la carpeta de sistema CRM 299. Un cuadro de texto 327 se usa para especificar una página de entrada que representa la página original identificada dentro del flujo original. En este caso puede verse que los datos introducidos hacen referencia al objeto página de resultados 322. Un cuadro de texto 328 se utiliza para referirse a datos, lo que indica cómo se obtiene la página original especificada en el cuadro de texto 327. En este caso, los datos introducidos se refieren a un objeto dentro de la carpeta de la página de peticiones 323, la cual se describe en más detalle a continuación. Un cuadro de texto 329 se utiliza para especificar un destino de salida, y puede ser utilizado para permitir la creación de flujos con control. Por ejemplo, si una aplicación fuente incluye una primera página A y una segunda página B, y se dispone de tal manera que la página B se puede mostrar solamente después de la página A, la página B tendrá un destino de salida configurado hacia la página A. Esto permite a las aplicaciones compuestas utilizar combinaciones de páginas de una aplicación fuente específica.
imagen35
El cuadro de diálogo 325 puede además ser utilizado para especificar uno o más elementos de flujo siguiente (entrando datos que señalen un objeto de flujo original apropiado dentro de una carpeta de flujos originales 303), y también puede introducir detalles de condiciones de entrada que se deben aplicar antes de mostrar la página fuente especificada.
El objeto de página de resultados 322 se identifica utilizando un cuadro de diálogo 330 ilustrado en la figura 42. En una pestaña de página de elementos 331, se suministra un panel 332 que muestra que ResPg incluye una pluralidad de elementos de interfaz de usuario organizados de forma jerárquica. Para crear una definición de una página original de esta manera, un usuario crea primero un objeto que representa la página entera, y luego crea objetos secundarios que representan los diferentes elementos de la página. La pestaña 331 además suministra una pestaña de extracción 333 que especifica un tipo de extractor en un área 334 (como expresión regular o basada en ruta) la que puede ser seleccionada de un menú desplegable. Una área 335 muestra los detalles del extractor y un área 336 muestra dónde se está utilizando el extractor en la aplicación compuesta.
Una pestaña de atributos 337 muestra datos relacionados con los atributos dentro de una página original específica. Una pestaña avanzada 338 permite especificar un elemento de la página de manera que los objetos pasivos que son simplemente mostrados al usuario son diferenciados de los que realizan funciones (por ejemplo, botones). Además, la etiqueta avanzada 338 permite introducir los datos indicando si debe hacerse una copia de la página fuente o si debería utilizarse la página original misma dentro de la aplicación compuesta.
El cuadro de diálogo 330 además suministra una pestaña de identificación de página 339, la cual se usa para suministrar detalles de cómo se identifica la página. Esto puede ser en forma de una expresión regular adecuada que, por ejemplo, investiga el título de una página original para realizar al identificación. Una pestaña de detalles de errores 340 se utiliza para especificar detalles de relevancia para manejar las páginas de error y una pestaña about 341 se usa para presentar una versión marcada de la página original (es decir, almacenada como un fichero de imagen como un JPEG o GIF) mostrando los elementos que constituyen la página.
En referencia a la figura 43, se puede ver una carpeta de conexión 342 dentro de la carpeta de orden del sistema 300 (la carpeta de conexión 302, la figura 38, ofrece funcionalidades similares para el sistema CRM). Puede verse que la carpeta de conexión 342 incluye un solo objeto de conexión 343 que representa una conexión HTTP usada para comunicarse con el sistema de orden. El objeto de conexión 343 se configura usando el cuadro de diálogo 344 ilustrado en la figura 44. Un cuadro de texto 345 especifica el protocolo de conexión, que en este caso es HTTP. Un cuadro de texto 346 se utiliza para especificar una dirección IP o la URL de base para el servidor que aloja la aplicación fuente, y un cuadro de texto 347 se usa para especificar un número de puerto en ese servidor, generalmente el puerto 80 para conexiones HTTP no seguras. El cuadro de diálogo 344 también permite introducir datos indicando que debe usarse un servidor proxy. El uso de un proxy se indica marcando una casilla 348, una URL o IP introducidos en una casilla de texto 349, y un número de puerto proxy entra en un cuadro de texto 350. Un área 351 se usa para especificar encabezamientos HTTP, los cuales pueden usarse cuando se comunica con la aplicación fuente.
Como se puede apreciar, además de comunicación utilizando el protocolo HTTP descrito anteriormente, muchos otros protocoles de conexión pueden ser utilizados, entre ellos HTTP, JDBC y SOAP.
En referencia nuevamente a la figura 40, la configuración del objeto de la aplicación fuente 301 se describe a continuación. En general, las páginas de interfaz y los elementos suministrados por la aplicación fuente incluyen referencias a otros elementos de interfaz del usuario proporcionados por la aplicación fuente. Dichas referencias estarán presentes frecuentemente de forma más relativa que absoluta. Para garantizar que dichas referencias se puedan utilizar todavía cuando se usan elementos de la interfaz de la aplicación fuente en una aplicación compuesta, es necesario modificar dichas referencias. Por ejemplo:
<img src=”/images/somepictures.jpg”...>
puede convertirse en:
<img src=http://www.sourceappserver.com/images/somepicture.jpg…>
imagen36
Dicha reescritura puede ser especificada por un cuadro de diálogo 352 como se ilustra en la figura 45, donde se pueden introducir datos de expresión regular en un cuadro de texto 353 para que se produzca la reescritura apropiada. El cuadro de diálogo 352 suministra además un cuadro de texto 354, el cual se utiliza para referenciar el objeto de conexión 343 (figura 43) usado para comunicación con la aplicación fuente.
En referencia nuevamente a la figura 40, la carpeta de petición de página 323 incluye una pluralidad de objetos que indican cómo se deben solicitar páginas incluidas dentro de la carpeta de flujo original de resultados de clientes 321. Cada uno de estos objetos de petición puede ser configurado utilizando un cuadro de diálogo 355 ilustrado en la figura 46. Puede verse que el cuadro de diálogo 355 ofrece un cuadro de selección 356 que puede utilizarse para seleccionar un método HTTP usado para seleccionar la página original (frecuentemente GET, como en este caso), un cuadro de texto 357 al que se hace llegar una ruta a la que se dirige el pedido, y un cuadro de texto 358 en el cual pueden especificarse los parámetros de la petición.
Habiendo descrito la entrada de datos relevantes para modelar la aplicación fuente, se describe ahora la configuración de la aplicación compuesta. Las figuras 47 y 48 ilustran algunas partes de la ventana de exploración 295 mostrada en la figura 38 en más detalle. La figura 47 muestra el contenido de la carpeta CA 298. Puede verse que la carpeta CA incluye una carpeta de flujos compuestos 359 que contiene detalles de todos los flujos compuestos dentro de la aplicación compuesta. Puede verse que la carpeta de flujos compuestos 359 incluye una carpeta de registro 360, una carpeta de búsqueda de cliente 361, una carpeta de resultados de búsqueda 362, y una carpeta de búsqueda y orden 363.
Los contenidos de la carpeta de resultados de búsqueda y orden 363 se muestra en la figura 48. Puede verse que la carpeta 363 incluye objetos que definen un flujo compuesto. Se recordará que un flujo completo puede ser un flujo nuevo definido por la aplicación compuesta o, de lo contrario un flujo original vuelto a usar. En el caso del ejemplo descrito aquí, solo se usan nuevos flujos. Puede verse que la carpeta de resultados de búsqueda y orden 353 incluye un nuevo objeto de flujo 364 llamado orden de cliente, y un objeto de página compuesta 365 que es la página que se muestra dentro del flujo compuesto de búsqueda y orden. La carpeta de resultados de búsqueda y orden 363 incluye además una carpeta de composición 366 que se describe en más detalles a continuación.
La figura 49 ilustra un cuadro de diálogo 367 que se usa para configurar el objeto nuevo de puntos de flujo 364. Los detalles de flujos originales que pueden seguir el flujo original que está siendo configurado son especificados dentro de un área de puntos siguientes 368. Los puntos pueden ser añadidos en esta área utilizando el nuevo botón 369. Los detalles de condiciones previas para entrada al flujo fuente que se están considerando se introducen en un área de condiciones de entrada de puntos 370. Un cuadro de texto 371 se usa para especificar la página compuesta asociada con el flujo original compuesto. Puede verse que, en la figura 49, los datos introducidos hacen referencia al objeto página compuesta 365. Un menú desplegable se suministra con el botón 372 para permitir la elección de cualquier página compuesta dentro de la aplicación compuesta. Nuevas páginas compuestas pueden ser creadas usando un nuevo botón 373.
La figura 50 ilustra un cuadro de diálogo 374 utilizado para la configuración del objeto de la página compuesta 365 (figura 48). Puede verse que el cuadro de diálogo incluye una pestaña de propiedades 375, una pestaña de composición 376, y una pestaña about 377. La pestaña de propiedades 375 suministra un área de elementos de página 378 en la cual se introducen detalles de elementos de página para usar dentro de la página compuesta. Cada uno de estos elementos corresponderá a un elemento definido dentro de una página original de una de las aplicaciones fuente (descritas anteriormente). Un conjunto de botones 379 se suministra para poder añadir y manipular los elementos de la página en el área de elementos de la página 378. Si se leen los botones 379 de izquierda a derecha, el primer botón se usa para crear un nuevo elemento de página, un segundo botón se usa para agregar elementos de página al área de elementos de página 378, un tercer botón se usa para eliminar uno
o más elementos de página dentro del área de elementos de página 378, un cuarto botón se usa para editar uno
o más elementos de página seleccionados y los botones quinto y sexto se usan para cambiar el orden de los elementos de página dentro del área de elementos de página 378.
Un área de correlaciones de parámetros de pedido 380 se suministra para especificar correlaciones entre parámetros de pedido utilizados para acceder a la página compuesta y parámetros destinados a pasar a la aplicación fuente apropiada cuando se busca una página fuente. El uso de un nuevo botón 381 muestra un cuadro de diálogo 382 como se ilustra en la figura 51, lo cual permite añadir nuevas correlaciones al área de correlación de peticiones de parámetros 380. El cuadro de diálogo 382 permite introducir correlaciones de petición de parámetros utilizando un cuadro de texto de parámetros originales 383 y un cuadro de texto de parámetros de destino 384. Una correlación se crea entonces entre los parámetros introducidos.
La figura 52 ilustra la pestaña de composición 376 del cuadro de diálogo 374. Esta pestaña define un script de composición que se usa para combinar los elementos especificados de la página para generar la página compuesta. Un área 385 especifica el tipo de script (en este caso una secuencia de manipulaciones de elementos de página), y un área 386 especifica las acciones que deben llevarse a cabo. En este caso, puede verse que una primera acción implica ir en busca de la página de búsqueda suministrada por el sistema CRM, una segunda acción trae la página del sistema de orden, una tercera elimina el botón de búsqueda y una cuarta acción inserta detalles de la página de orden que fue traída. La figura 53 ilustra parte de la ventana de exploración 295 que muestra que la carpeta de composición contiene objetos relacionados con las cuatro acciones mostradas en el área 386 del cuadro de diálogo 52. La primera acción está representada por un objeto de carga de órdenes 387, la segunda acción está representada por un nano objeto de carga 388, la tercera está representada por un objeto OrderMapping 389, y la cuarta está representada por un objeto insert nano 390.
imagen37
Las figuras 54 y 55 ilustran un cuadro de diálogo 393 utilizado para definir una acción de composición. Una etiqueta de propiedades 394 y una etiqueta about 395 son suministradas. La propiedad de la etiqueta 394 se ilustra en la figura 54. Puede verse que esta etiqueta permite especificar un elemento de la página en un cuadro de texto de elementos de página 396. La ubicación del elemento de página especificado se especifica en relación con un elemento de página específico en un cuadro de texto 397, y la ubicación relativa (es decir, antes o después) se especifica en un cuadro de texto 398. Si el elemento de página especificado en el cuadro de texto de elementos de página 396 se fusiona con otro elemento de página, el otro elemento de página especificado en el cuadro de texto 399 y el tipo de fusión se especifican en un cuadro de diálogo 400. La figura 55 ilustra el cuadro de diálogo 393 cuando se usa simplemente para insertar un elemento de página relativo a otro elemento de página, es decir, cuando no se realiza ninguna operación de fusión.
Como se podrá apreciar, la entrada de datos por parte de un usuario que utiliza la GUI descrita anteriormente puede ser usada por uno o más modelos de aplicaciones fuente de la manera ilustrada en la figura 35 y un modelo de aplicación compuesta de la forma ilustrada en la figura 36. Una vez creados dichos modelos, es necesario generar a partir de los modelos, datos para inclusión en el IDM. Esto se logra utilizando un proceso aquí denominado publicación. La publicación puede ser convenientemente lograda suministrando un botón de publicación dentro de la GUI, cuando la aplicación compuesta se crea generando datos IDM adecuados.
El proceso de publicación se describe a continuación. La figura 56 ilustra las clases de Java usadas por el publicador. El proceso de publicación se inicia llamando a un método ofrecido por una clase IDMPublisherService
402. Esto se puede hacer de forma adecuada desde la GUI 403 o, de lo contrario, desde una interfaz de comando de línea. La clase IDMPubliserService 402 ofrece un método sobrecargado de publicación. Un primer método de publicación toma una sola bean de Java que representa una parte de la aplicación compuesta y lleva a cabo la publicación necesaria. Un segundo método toma una matriz de beans de Java. La clase IDMPubliserService 402 también ofrece un método publishAll() que puede ser utilizado para publicar todas las beans de Java dentro de un modelo.
Para publicar una sola parte de un modelo compuesto puede ser necesario que los datos se escriban en una pluralidad de partes de la estructura IDM descrita anteriormente. Cada parte del IDM tiene un escritor asociado que es responsable de escribir los datos en la parte específica del IDM, y de encontrar los datos dentro del IDM. Los escritores están implementados como instancias de clases que implementan una interfaz IDMWriter 404. Dos clases abstractas implementan la interfaz IDMWriter 404, una clase AbstractDataGroupWriter 405 se usa como una superclase por todos los escritores que son responsables de crear y escribir datos en grupos de datos dentro del IDM (por ejemplo, el grupo de datos g2config ilustrado en al figura 20). Cada grupo de datos tiene un solo escritor y solamente este escritor puede crear el grupo de datos y manipular los valores NVP. La figura 56 ilustra una clase CLSourceAppDGWriter 406 y una CLSourceAppConnectionDGWriter 407 que son responsables de escribir grupos de datos dentro del IDM en relación con la configuración CL. La clase CLSourceAppDGWriter 406 es responsable de escribir grupos de datos de la aplicación fuente 145, 147 (figura 21), mientras que la clase CLSourceAppConnectionDGWriter 407 es responsable de escribir grupos de datos de conexión 146, 148 de la aplicación fuente (figura 21)
Una clase AbstractGenientIDWriter 408 implementa otra vez la interfaz IDMWriter 404. Subclases de la clase AbstractGenientIDWriter 408 son responsables de escribir datos GenientID en el IDM. Estas clases de escritor ID, por lo tanto, permite crear y/o recoger las entidades dentro del IDM como se describe a continuación. Cinco subclases se ilustran en la figura 56, y se describen con referencia a la estructura de datos IDM de la figura 21. Una clase IDMConfigIDWriter 409 es responsable de la entidad CONFIG 129, un IDMServiceIDWriter clase 410 es responsable de la entidad SERVICE 135, una clase CLBaseConfigIDWriter 411 es responsable de la entidad BASE_CL_SERVICE 138, una clase CLExternaAppsConfigIDWriter 412 es responsable de la entidad EXT_APPS 140 y una CLSourceAppGenientIDWriter es responsable de entidades de la aplicación fuente como la entidad SrcApp1 143 y la entidad SrcApp2 144.
El IDMPublisherService crea y usa una instancia de una clase WriterLookup 414, la cual se utiliza para obtener detalles de cualesquiera escritores que sea necesario invocar para hacer publishing de beans Java. La clase WriterLookup 414 mantiene detalles de un conjunto de clases WriterFactory que se utilizan para crear escritores apropiados cuando es necesario.
La figura 56 también ilustra una clase AbstractIDMWriterFactory 415, que se usa como una superclase para todas las clases WriterFactory. Cada clase de escritor de grupo de datos (por ejemplo, todas las clases secundarias de la clase AbstractDataGroupWriter 405) tendrá una clase factory asociadas que es una secundaria de la clase AbstractDataGroupWriter 415. La figura 56 ilustra una clase CLSourceAppConnectionDGWriterFactory 416, la cual crea instancias de la clase CLSourceAppConnectionDGWriter 407, y una clase CLSourceAppDGWriterFactory 417 que crea instancias de la clase CLSourceAppDGWriter 406. La clases factory pueden lanzar una excepción BeanNotSupportedException
imagen38
418.
Finalmente, la figura 56 ilustra una interfaz FetchCriteria 420, la cual es implementada por una clase DataGroupFetchCriteria 421 y una clase GenientIDFetchCriteria 422. Use una de las clases que se describen a continuación.
Se describe ahora la publicación usando las clases ilustradas en la figura 56, La figura 57 ilustra como la clase PublisherService 402 se usa para crear clases de escritor apropiadas. Un usuario usa la GUI 403 que llama a un método de publicación público suministrado por un objeto PublisherService 425, suministrando un objeto para ser publicado como parámetro. El objeto Publisher Service 425 llama a un método getInstance suministrado por un objeto WriterLookup 426 para crear el objeto WriterLookup 426.
El objeto PublisherService 425 luego llama a un método de consulta (el cual toma el objeto para ser publicado como parámetro) suministrado por el objeto WriterLookp y este método suministra una matriz de objetos IDMWriter representando escritores que serán invocados para permitir la publicación del objeto especificado. Al recibir la llamada del método de consulta, el objeto WriterLookup 426 llama a un método privado createWriterInstances() para crear instancias de todas las clases de escritor requeridas para la publicación del objeto especificado y, para obtener los datos necesarios, el método createWriterInstances llama a un método privado lookupWriterClasses usando el objeto especificado como parámetro, y este método devuelve una lista de escritores que deberían ser invocados. Estos escritores serán instancias de una variedad de clases diferentes de escritores, todas las cuales son subclases de AbstractIDMWrierFactory. El procesamiento se simplifica almacenando cada uno de estos objetos escritores en una matriz del tipo AbastractIDMWriterFactory y llamando a métodos especificados por esta clase de abstracto que son invalidados dentro de la respectiva subclase.
Para cada objeto AbstractIDMWriterFactory (uno de los cuales, 427, está ilustrado en la figura 57) devuelto por el método lookupWriterClasses, un método público getWriters suministrado por el objeto AbstractIDMWriterFactory 427 es llamado para su publicación como parámetro para suministrar una instancia del escritor apropiado. Al llamar a este método, el objeto AbstractIDMWriterFactory 427 llama a un método getDefiningBeans suministrado por un objeto CLSourceAppDGWriterFactory 428 (un objeto CLSourceAppDGWriter 429 es un escritor necesario en este caso) para obtener detalles de cualquier otro objeto dentro del modelo de una aplicación fuente o compuesta que puede ser necesario para permitir la publicación. Por ejemplo, si se está publicando un objeto de una aplicación fuente, un objeto conexión correspondiente también será necesario. Del mismo modo, la publicación de un objeto de conexión puede requerir la publicación de uno o más objetos de aplicación fuente. El objeto CLSourceAppDGWriterFactory 428 llama a un método getBansToInvokeBy para obtener detalles de una pluralidad de objetos que pueden ser necesarios, y el método constructor suministrado por el escritor es llamado para crear una instancia del escritor apropiado para cada objeto especificado por el método getBeansToInvokeBy. Habiendo creado una o más instancias del escritor requerido de este modo, el objeto WriterLookup 426 añade detalles de estas instancias a una lisa y el objeto PublisherService 425 hace lo propio.
La clase CLSource AppDGWriter se usa para crear y escribir un grupo de datos que representan una aplicación fuente específica dentro de la estructura de datos IDM. En referencia nuevamente a la figura 21, escribir datos en el grupo de datos g2config 147 de SrcApp 2 utilizando el objeto CLSourceAppDGWriter 429 creada usando el proceso ilustrado en la figura 57 se describe con referencia a la figura 58. El objeto CLSourceAppDGWriter 429 ofrece un método fetch() que se usa para obtener un grupo de datos apropiado del IDM. Este método se llama luego de la creación de un objeto CLSourceAppDGWriter 429 como se ilustra en la figura 57. El método fetch() llama a un método loadFetchCriteria() el cual devuelve una instancia de la clase DataGroupFetchCriteria 421, y esta instancia permite que el grupo de datos apropiados se localice dentro del IDM.
La creación de un objeto DataGroupFetchCriteria se describe a continuación. loadFetchCriteria debe localizar dentro de la datastructure jerárquica IDM la posición del grupo de datos 147 para escribirlo. Como primer paso, usa el objeto WriterLookup 426 para obtener detalles de una clase ID escritor correspondiente a la clase del escritor del grupo de datos. Esta clase de ID escritor suministra un ID para la entidad SrcApp2 144 en la estructura de datos en el IDM. El método de consulta suministrado por el objeto WriterLookup 426 se llama para localizar un objeto factory apropiado y construye un escritor ID apropiado usando el método construct. En este caso, se crea un objeto CLSourceAppIDWriter 430. Una vez creado este objeto, el objeto CLSourceAppDGWriter 429 llama a un método fetch() suministrado por el objeto CLSourceAppIDWriter 430 para obtener el ID de la entidad SrcApp2 144 en el IDM. En respuesta a esta llamada de fetch(), el objeto CLSourceApIDWriter 430 llama a su método loadFetchCriteria (), que usa un método getinstance() para obtener un escritor responsable de escribir su ID dominante, es decir, el ID de la entidad EXT_APPS 140, lo que a su vez crea un objeto CLExternalAppsConfigIDWriter 431. El método loadFecthCriteria() del objeto CLSourceAppsConfigIDWriter 430 llama al método fetch() del CLExternalAppsConfigIDWriter 431, y este objeto a su vez llama a su método loadFetchCriteria() que a su vez llama al método fetch() suministrado por el objeto CLExternalAppsConfigIDWriter 432, el cual es responsable por la entidad BASE_CL_SERVICE 138 dentro del IDM. Una vez más, este objeto llama a su método loadFetchCriteria, que da lugar a una llamada al método fetch suministrado por un objeto IDMServiceGenientIDWriter 433, el cual es responsable de la entidad SERVICE 135 dentro del IDM. Este objeto, a su vez, llama a su método loadFetchCriteria y un método fetch() suministrado por el objeto IDMConfigIDWriter 434 es llamado entonces. Este escritor es responsable de la entidad del más alto nivel, CONFIG 129, en la estructura de datos IDM.
imagen39
El método loadFetchCriteria del objeto IDMConfigWriter 434 es llamado, y se puede devolver un objeto GenientIDFetchCriteria que identifica inequívocamente la raíz del árbol IDM. A su vez, el objeto IDMServiceGenientIDWriter 433, el objeto CLBaseConfigIDWrier 432, y el objeto CLExternalAppsConfig 431, crean instancias de GenientIDFetchCriteria (no se muestra) que se utilizan para localizar entradas apropiadas dentro de la estructura IDM. El objeto CLSourceAppIDWriter 430 llama entonces a un método getUniquieName para suministrar un ID único para que el grupo de datos se escriba utilizando las distintas instancias de GenientIDFetchCriteria descritas más arriba. Habiendo obtenido una ubicación dentro del IDM donde el grupo de datos debería ser escrito, se crea un objeto DataGroupFetchCriteria 435, el cual representa la ubicación donde debería ser escrito el grupo de datos.
Debe señalarse que cada uno de los escritores de ID anteriores ubicará las entidades apropiadas dentro del IDM donde dichas entidades existen, y creará entidades dentro del IDM donde sea necesario.
Una vez creado el objeto DataGroupFetchCriteria 435, el objeto CLSourceAppDGWriter 429 pueden entonces escribir los datos NVP apropiados en el grupo de datos de la aplicación fuente dentro del IDM. Este proceso se ilustra en la figura 59. Un método updatedNVPs() se llama para llevar a cabo la actualización. Como primer paso, el objeto CLSourceAppDGWriter 429 obtiene detalles de varios parámetros del objeto de la aplicación fuente 436, y actualiza cada NVP dentro del grupo de datos usando un método updatedNVP.
En realizaciones preferentes de esta invención, el objeto PublisherServices 425 suministra una bandera de ensayo que, si se define, significa que la publicación ocurre, pero los datos no se escriben en el IDM. El objeto CLSourceAppDGWriter 429 investiga el valor de esta bandera y, si se configura como FALSE, los NVP se almacenan dentro del IDM utilizando un método storNVP() y un método group.put().
A pesar de que el ejemplo anterior se ocupa de escribir datos relacionados con un grupo de datos de la aplicación fuente en una parte del IDM relacionado con la configuración CL, será obvio para los expertos en la materia que otros datos IDM pueden ser escritos de una forma muy similar.
Las realizaciones preferidas del mecanismo de publicación descrito anteriormente ofrecen varios servicios adicionales. Primero, una función de despublicar puede ser suministrada para eliminar datos del IDM relacionados con una o más aplicaciones compuestas que ya no se utilizan. La función despublicar se suministra en tres clases, una clase DTCleaner, una clase UXMCleaner y una clase CLCleaner. Estas clases son responsables de limpiar partes respectivas del IDM señaladas en sus nombres. Además, los datos en el IDM pueden ser localizados correctamente solo si tiene lugar bajo un identificador bien definido, o si se referencia correctamente desde un grupo de datos. Si existen datos que no es posible localizar correctamente de este modo, deberían ser periódicamente eliminados del IDM utilizando una rutina de limpieza.
Se apreciará que es deseable permitir la creación una pluralidad de aplicaciones compuestas que contengan una aplicación fuente comúnmente modelada, y las técnicas de modelación descritas anteriormente permiten dicha modelación. No obstante, al publicar, los datos apropiados se crean por separado para cada aplicación compuesta (dada la estructura del IDM descrita anteriormente). Por lo tanto, si un modelo de aplicación fuente se modifica, y publica posteriormente, esto afectará solamente la aplicación compuesta representada por el proyecto activo actual. Realizaciones preferentes de la invención, por lo tanto, suministran un mecanismo para informar al usuario de todos los proyectos que son afectados, y aconsejan que cada uno de estos proyectos afectados debería ser actualizado si no sirve para el nuevo modelo de aplicación fuente.
Cabe destacar que cuando los datos se publican en el IDM, es preferible hacerlo de forma transaccional de manera que, si ocurren problemas, se pueda lanzar una excepción y la función de retorno puede llevar el IDM al estado anterior al del proceso de publicación.
La descripción anterior ha presentado una forma flexible de modelar, crear y operar aplicaciones compuestas. No obstante, algunas realizaciones de la invención aportan más flexibilidad, como se describe ahora. En referencia nuevamente a la figura 2, se explicó que el servidor 13 recibe peticiones de usuarios que usan aplicaciones compuestas, genera peticiones de usuarios de aplicaciones completas, genera peticiones de datos originales que son dirigidas a las aplicaciones fuente, y producen páginas compuestas que se suministran a los usuarios.
En realizaciones preferentes de esta invención, el servidor 13 también ejecuta un módulo que controla las peticiones de los usuarios y produce datos de administración. Estos datos de administración se pueden usar posteriormente para reconfigurar la aplicación compuesta, si fuese necesario. Por ejemplo, si se determina que un gran número de usuarios introduce una secuencia de peticiones que requiere ver las mismas dos páginas originales, puede ser deseable suministrar dentro de la aplicación compuesta, una página compuesta adicional que combine toda la información solicitada. Esto se puede lograr modificando convenientemente los datos IDM o, de lo contrario, modificando una aplicación compuesta y publicando ese modelo posteriormente como se describe anteriormente. El uso de un módulo de monitorización de esta manera, permite monitorizar el uso de la aplicación compuesta para analizar el rendimiento del usuario y, si fuera apropiado, evaluar formas para mejorar la aplicación compuesta con el fin de aumentar el rendimiento.
imagen40
En algunas realizaciones de la invención se suministran dos configuraciones para aplicaciones compuestas. Cada aplicación ofrece esencialmente la misma funcionalidad, aunque utilice páginas compuestas diferentes. En algunos casos, las páginas compuestas pueden poner en peligro los mismos datos, pero con diferentes puntos de datos especificados como obligatorios. Es posible determinar la configuración utilizada en esta situación específica por varios factores diferentes. Por ejemplo, una configuración en la cual menos datos son obligatorios pueden ser utilizados cuando la aplicación compuesta se está usando mucho para ofrecer mayor rendimiento. De lo contrario, si una aplicación compuesta está siendo usada en un call centre dedicado a la venta, es posible determinar mediante investigaciones de mercado que las personas que llaman en momentos específicos del día encuentran diferentes ofertas especiales más atractivas. En dichos casos se pueden proporcionar dos aplicaciones compuestas, cada una de las cuales ofrece detalles de productos levemente diferentes en respuesta a las solicitudes de los clientes. La aplicación compuesta para ser usada puede entonces ser automáticamente seleccionada en base, por ejemplo, a la hora de día. Del mismo modo, comportamientos diferentes pueden ser configurados para distintas épocas del año, o en base a un customerID de entrada o un ID de inicio de sesión de usuario.
A pesar de que la realización de la invención aquí descrita es implementada usando el lenguaje de programación Java, se apreciará que la invención no está de forma alguna restringida a una implementación con Java. Es más, la invención puede ser implementada usando un lenguaje de programación orientado a objetos de alto nivel. Sin embargo, es preferible usar un lenguaje de programación orientado a objetos para obtener las ventajas de la reutilización y encapsulación inherentes a dichas técnicas de programación de computación.
A pesar de que esta invención ha sido descrita aquí con referencia a realizaciones específicas, será obvio para un experto en la materia que se pueden hacer modificaciones a las realizaciones descritas. Por ejemplo, se apreciará que el método para modelar aplicaciones compuestas descrito anteriormente puede ser utilizado en solitario si así se desea y, lo que es más, el modelo de modelación y el modelo de publicación suministrados por la invención no están de ninguna manera limitados a la estructura de datos IDM descrita más arriba a modo de ejemplo.
imagen41

Claims (45)

  1. REIVINDICACIONES
    1.
    Un método de configuración de un servidor (13) para proporcionar al menos una interfaz del usuario compuesta (5, 6) a una pluralidad de aplicaciones fuente, en que cada aplicación fuente proporciona una interfaz del usuario respectiva, y la interfaz del usuario compuesta comprende una pluralidad de elementos de interfaz del usuario proporcionados por dicha pluralidad de aplicaciones fuente; el método incluye el procesamiento de un modelo (252) que representa a dicha interfaz del usuario compuesta que genera reglas para la comunicación entre dicha interfaz del usuario compuesta (5, 6) y dicha pluralidad de aplicaciones fuente;
    en el que dicho modelo (252) comprende un modelo de al menos parte de una interfaz del usuario (1, 2, 3) proporcionada por cada aplicación fuente y un modelo de relaciones entre al menos parte de la interfaz del usuario proporcionada por cada aplicación fuente y la interfaz del usuario compuesta (5, 6).
  2. 2.
    Un método de acuerdo con la reivindicación 1, que comprende además:
    el almacenamiento de dichas reglas en una estructura de datos jerárquica que comprende una pluralidad de entidades.
  3. 3.
    Un método de acuerdo con la reivindicación 2, que comprende además:
    el almacenamiento en dicha estructura de datos jerárquica de una entidad que representa a la interfaz del usuario compuesta; y
    la asociación de dicha entidad con un grupo de datos que proporciona datos de configuración a la interfaz del usuario compuesta.
  4. 4.
    Un método de acuerdo con la reivindicación 3, que comprende además:
    el almacenamiento en dicha estructura de datos jerárquica de una pluralidad de entidades de servicio que representan módulos de procesamiento que juntos están adaptados para procesar peticiones del usuario introducidas en dicha interfaz del usuario compuesta para producir una o más peticiones para al menos una de dicha pluralidad de aplicaciones fuente.
  5. 5.
    Un método de acuerdo con la reivindicación 4, en el que al menos algunas de dichas entidades de servicio tienen un grupo de datos asociados que almacenan datos de configuración.
  6. 6.
    Un método de acuerdo con la reivindicación 5, en el que una de dichas entidades de servicio es una entidad de servicio de agregación que representa un servicio de agregación configurado para generar peticiones de aplicación fuente a partir de una petición del usuario.
  7. 7.
    Un método de acuerdo con la reivindicación 6, en el que dicha entidad de servicio de agregación comprende:
    una entidad hija que representa a la interfaz del usuario compuesta; y dicha entidad hija tiene al menos una entidad hija que representa a una aplicación fuente.
  8. 8.
    Un método de acuerdo con cualquiera de las reivindicaciones 2 a 7, en el que dichas reglas se generan usando una pluralidad de escritores, donde cada escritor está asociado a una entidad en dicha estructura de datos jerárquica, y está adaptado para escribir datos para un grupo de datos asociados a la entidad respectiva.
  9. 9.
    Un método de acuerdo con la reivindicación 8, en el que el procesamiento de dicho modelo comprende: seleccionar uno o más objetos en dicho modelo;
    determinar uno o más escritores a los que se solicitará que escriban datos desde el o cada objeto para dicha estructura de datos jerárquica; y
    solicitar al o a cada escritor que escriba datos para dicha estructura de datos jerárquica.
  10. 10.
    Un método de acuerdo con la reivindicación 9, que comprende además: determinar a partir de al menos un escritor al menos un objeto adicional en dicho modelo, y procesar dicho objeto adicional.
  11. 11.
    Un método de acuerdo con la reivindicación 9 ó 10, que comprende además:
    identificar un escritor adicional configurado para identificar una entidad en dicha estructura de datos jerárquica para la que deben escribirse los datos.
  12. 12.
    Un método de acuerdo con la reivindicación 11, en el que dicha identificación de una entidad comprende: intentar localizar una entidad en dicha estructura de datos jerárquica para la que deben escribirse los datos; y
    si dicho intento no tiene éxito, crear una entidad apropiada.
  13. 13.
    Un método de acuerdo con una cualquiera de las reivindicaciones 8 a 12, en el que cada escritor es un objeto de escritor que es una instancia de una clase de escritor Java respectiva.
  14. 14.
    Un método de acuerdo con la reivindicación 13, en el que cada clase de escritor tiene una clase de fábrica de escritor correspondiente.
  15. 15.
    Un método de acuerdo con la reivindicación 14, que comprende además:
    imagen1
    registrar cada clase de fábrica de escritor con un objeto de búsqueda de escritor; proporcionar detalles del o de cada objeto a procesar a dicho objeto de búsqueda de escritor; e
    identificar una o más clases de fábrica que deben usarse para crear objetos de escritor.
  16. 16.
    Un método de acuerdo con cualquier reivindicación anterior, en el que dicha al menos una interfaz del usuario compuesta comprende una pluralidad de páginas, comprendiendo cada página una pluralidad de elementos de interfaz del usuario proporcionados por al menos una de dicha pluralidad de aplicaciones fuente.
  17. 17.
    Un método de acuerdo con cualquier reivindicación anterior, en el que dicho modelo de al menos parte de la interfaz del usuario proporcionada por cada aplicación fuente comprende una pluralidad de elementos de flujo fuente comprendiendo cada uno una página de interfaz del usuario fuente especificada proporcionada por una aplicación fuente y define relaciones entre dicha pluralidad de elementos de flujo fuente.
  18. 18.
    Un método de acuerdo con la reivindicación 17, en el que dicho modelo de al menos parte de la interfaz del usuario proporcionada por cada aplicación fuente comprende al menos un elemento de página en cada página de interfaz del usuario fuente especificada.
  19. 19.
    Un método de acuerdo con la reivindicación 17 ó 18, en el que dicho modelo de al menos parte de la interfaz del usuario proporcionada por cada aplicación fuente comprende al menos una condición de control de flujo asociada a al menos uno de dicha pluralidad de elementos de flujo fuente.
  20. 20.
    Un método de acuerdo con la reivindicación 17, 18, 19, en el que dicho modelo de al menos parte de la interfaz del usuario proporcionada por cada aplicación fuente comprende parámetros de petición usados para obtener cada página de interfaz del usuario fuente especificada.
  21. 21.
    Un método de acuerdo con la reivindicación 17, 18, 19, 20, en el que dicho modelo de al menos parte de la interfaz del usuario proporcionada por cada aplicación fuente comprende al menos una regla para cada página de interfaz del usuario fuente especificada que puede aplicarse para permitir el reconocimiento de la página de interfaz del usuario fuente especificada asociada.
  22. 22.
    Un método de acuerdo con la reivindicación 21, en el que la o cada regla se especifica usando una expresión regular, o una expresión de trayectoria.
  23. 23.
    Un método de acuerdo con cualquier reivindicación anterior, en el que dicho modelo de al menos parte de la interfaz del usuario proporcionada por cada aplicación fuente comprende una pluralidad de objetos que son instancias de clases definidas en un lenguaje de programación orientado al objeto.
  24. 24.
    Un método de acuerdo con cualquier reivindicación anterior, en el que dicho modelo de relaciones entre la al menos parte de la interfaz del usuario proporcionada por cada aplicación fuente y la interfaz del usuario compuesta comprende una combinación de al menos parte de una pluralidad de modelos de aplicación fuente.
  25. 25.
    Un método de acuerdo con cualquier reivindicación anterior, en el que dicho modelo (252) comprende además una pluralidad de elementos de flujo compuestos, comprendiendo cada uno una página de interfaz del usuario especificada, y especifica relaciones entre dicha pluralidad de elementos de flujo compuestos.
  26. 26.
    Un método de acuerdo con la reivindicación 25 cuando depende de la reivindicación 17, en el que al menos un elemento de flujo compuesto es un elemento de flujo fuente, y dicha página de interfaz del usuario especificada es una página de interfaz del usuario fuente especificada.
  27. 27.
    Un método de acuerdo con la reivindicación 25 ó 26, en el que al menos una página de interfaz del usuario especificada es una página de interfaz del usuario compuesta.
  28. 28.
    Un método de acuerdo con la reivindicación 27 cuando depende de la reivindicación 18, en el que dicho modelo (252) comprende además un modelo de manipulaciones que se aplican a dicho al menos un elemento de
    página en una página de interfaz del usuario fuente especificada para crear dicha página de interfaz del usuario compuesta.
  29. 29.
    Un método de acuerdo con la reivindicación 28, en el que dicho modelo (252) especifica una pluralidad ordenada de manipulaciones a realizar para crear dicha página de interfaz del usuario compuesta.
  30. 30.
    Un método de acuerdo con cualquier reivindicación anterior, en el que dicho modelo (252) comprende además un modelo de al menos un elemento de interfaz del usuario adicional que se incluirá en la interfaz del usuario compuesta.
  31. 31.
    Un soporte de datos que soporta un medio de código de programa informático para hacer que un ordenador realice un método de acuerdo con cualquier reivindicación anterior.
  32. 32.
    Un servidor (13) configurado para proporcionar al menos una interfaz del usuario compuesta (5, 6) a una pluralidad de aplicaciones fuente, proporcionando cada aplicación fuente una interfaz del usuario respectiva, comprendiendo dicha interfaz del usuario compuesta una pluralidad de elementos de interfaz del usuario proporcionados por dicha pluralidad de aplicaciones fuente, comprendiendo el servidor:
    imagen2
    un procesador adaptado para procesar un modelo (252) que representa dicha interfaz del usuario compuesta para generar reglas para comunicación entre dicha interfaz del usuario compuesta (5, 6) y dicha pluralidad de aplicaciones fuente;
    en el que dicho modelo (252) comprende un modelo de al menos parte de una interfaz del usuario (1, 2, 3) proporcionada por cada aplicación fuente y un modelo de relaciones entre la al menos parte de la interfaz del usuario proporcionada por cada aplicación fuente y la interfaz del usuario compuesta.
  33. 33.
    Un servidor de acuerdo con la reivindicación 32, que comprende además un medio de almacenamiento que almacena una estructura de datos jerárquica que comprende una pluralidad de entidades, almacenando dicha estructura de datos jerárquica dichas reglas.
  34. 34.
    Un servidor de acuerdo con la reivindicación 33, en el que dicha estructura de datos jerárquica comprende una entidad que representa a la interfaz del usuario compuesta, y dicha entidad está asociada a un grupo de datos que proporcionan datos de configuración para la interfaz del usuario compuesta.
  35. 35.
    Un servidor de acuerdo con la reivindicación 34, en el que dicha estructura de datos jerárquica comprende una pluralidad de entidades de servicio que representan módulos de procesamiento que están adaptados juntos para procesar peticiones del usuario introducidas en dicha interfaz del usuario compuesta para producir una o más peticiones a al menos una de dicha pluralidad de aplicaciones fuente.
  36. 36.
    Un servidor de acuerdo con la reivindicación 35, en el que al menos alguna de dichas entidades de servicio tienen un grupo de datos asociados que almacenan datos de configuración.
  37. 37.
    Un servidor de acuerdo con la reivindicación 36, en el que una de dichas entidades de servicio es una entidad de servicio de agregación que representa un servicio de agregación configurado para generar peticiones de aplicación fuente a partir de una petición del usuario.
  38. 38.
    Un servidor de acuerdo con la reivindicación 37, en el que dicha entidad de servicio de agregación comprende:
    una entidad hija que representa a la interfaz del usuario compuesta; y
    dicha entidad hija tiene al menos una entidad hija que representa a una aplicación fuente.
  39. 39.
    Un servidor de acuerdo con una cualquiera de las reivindicaciones 33 a 36, que comprende además una pluralidad de escritores adaptados para generar dichas reglas, estando cada escritor asociado a una entidad en dicha estructura de datos jerárquica, y estando adaptado para escribir datos para un grupo de datos asociados a la entidad respectiva.
  40. 40.
    Un servidor de acuerdo con la reivindicación 39, en el que dicho procesador comprende:
    medios de selección para seleccionar uno o más objetos en dicho modelo;
    medios de determinación para determinar uno o más escritores a los que se solicitará que escriban datos a partir del o de cada objeto para dicha estructura de datos jerárquica; y
    medios para solicitar al o a cada escritor que escriba datos para dicha estructura de datos jerárquica.
  41. 41.
    Un servidor de acuerdo con la reivindicación 40, que comprende además medios para determinar, usando dicho al menos un escritor, al menos un objeto adicional en dicho modelo, y procesar dicho objeto
    adicional.
  42. 42.
    Un servidor de acuerdo con la reivindicación 40 ó 41, que comprende además un escritor adicional que comprende medios de identificación configurado para identificar una entidad en dicha estructura de datos jerárquica para la que se escribirán los datos.
    imagen3
    5 43. Un servidor de acuerdo con la reivindicación 42, en el que dichos medios de identificación comprenden: medios para intentar localizar una entidad en dicha estructura de datos jerárquica para la que deben
    escribirse los datos; y medios para crear una entidad apropiada si dicho intento no tiene éxito.
  43. 44.
    Un servidor de acuerdo con una cualquiera de las reivindicaciones 39 a 43, en el que cada escritor es 10 un objeto de escritor que es una instancia de una clase de escritor respectiva.
  44. 45. Un servidor de acuerdo con la reivindicación 44, en el que cada clase de escritor tiene una clase de fábrica de escritor correspondiente.
  45. 46.
    Un servidor de acuerdo con la reivindicación 45, que comprende además: un objeto de búsqueda de escritor, comprendiendo dicho objeto de búsqueda de escritor medios 15 adaptados para registrar cada clase de fábrica de escritor con dicho objeto de búsqueda de escritor, medios para proporcionar detalles del o de cada objeto a procesar a dicho objeto de búsqueda de
    escritor; y medios para identificar una o más clases de fábrica que deben usarse para crear objetos de escritor.
ES04707569T 2004-02-03 2004-02-03 Método y aparato para la creación de una interfaz de usuario para aplicación compuesta. Expired - Lifetime ES2362573T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/GB2004/000429 WO2005076130A1 (en) 2004-02-03 2004-02-03 Method and apparatus for composite user interface creation

Publications (1)

Publication Number Publication Date
ES2362573T3 true ES2362573T3 (es) 2011-07-07

Family

ID=34835375

Family Applications (1)

Application Number Title Priority Date Filing Date
ES04707569T Expired - Lifetime ES2362573T3 (es) 2004-02-03 2004-02-03 Método y aparato para la creación de una interfaz de usuario para aplicación compuesta.

Country Status (6)

Country Link
US (4) US9864610B2 (es)
EP (1) EP1711891B1 (es)
AT (1) ATE491987T1 (es)
DE (1) DE602004030621D1 (es)
ES (1) ES2362573T3 (es)
WO (1) WO2005076130A1 (es)

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060045461A1 (en) * 2004-08-06 2006-03-02 Microsoft Corporation Methods and apparatus for project management
US9766953B2 (en) 2004-12-16 2017-09-19 Openspan, Inc. System and method for non-programmatically constructing software solutions
US20060225037A1 (en) * 2005-03-30 2006-10-05 Microsoft Corporation Enabling UI template customization and reuse through parameterization
US20060224962A1 (en) * 2005-03-30 2006-10-05 Microsoft Corporation Context menu navigational method for accessing contextual and product-wide choices via remote control
US7667704B2 (en) * 2005-03-30 2010-02-23 Microsoft Corporation System for efficient remote projection of rich interactive user interfaces
US20060224575A1 (en) * 2005-03-30 2006-10-05 Microsoft Corporation System and method for dynamic creation and management of lists on a distance user interface
US8214754B2 (en) 2005-04-15 2012-07-03 Microsoft Corporation Registration of applications and complimentary features for interactive user interfaces
US20070220035A1 (en) * 2006-03-17 2007-09-20 Filip Misovski Generating user interface using metadata
US8566781B2 (en) * 2007-04-23 2013-10-22 Siemens Aktiengesellschaft Model-based view parts and reusable data source configurations
US9613079B2 (en) * 2008-03-14 2017-04-04 Palo Alto Research Center Incorporated System and method for providing a synchronized data rerepresentation
US8307277B2 (en) * 2010-09-10 2012-11-06 Facebook, Inc. Efficient event delegation in browser scripts
US9116600B2 (en) * 2010-12-17 2015-08-25 Sap Se Automatically personalizing application user interface
US9459846B2 (en) 2011-01-31 2016-10-04 Sap Se User interface style guide compliance
US9841956B2 (en) * 2011-01-31 2017-12-12 Sap Se User interface style guide compliance reporting
US9444640B2 (en) * 2011-03-28 2016-09-13 Sony Corporation Method to create a composite RUI from multiple RUIs
US20140149488A1 (en) * 2012-11-26 2014-05-29 Nice-Systems Ltd. System and method for engaging a mobile device
US10175953B2 (en) * 2014-04-02 2019-01-08 Microsoft Technology Licensing, Llc User interface control and communication
CN105577411B (zh) * 2014-10-17 2019-06-07 武汉科技大学 基于服务起源的云服务监控方法和装置
EP3015984A1 (en) 2014-10-29 2016-05-04 Hewlett-Packard Development Company, L.P. Providing data from data sources
CN107423037B (zh) * 2016-03-09 2021-04-02 阿里巴巴集团控股有限公司 应用程序接口定位方法及设备
US10560968B2 (en) * 2017-06-13 2020-02-11 Mueller International, Llc Broadcast messaging
US11082294B2 (en) 2017-08-15 2021-08-03 Mueller International, Llc Broadcast remote firmware update
US10419570B2 (en) * 2017-09-05 2019-09-17 Bank Of America Corporation Smart factory application integration
CN108920440A (zh) * 2018-06-26 2018-11-30 苏州蜗牛数字科技股份有限公司 一种配置文件的编辑方法、装置及存储介质
US11726995B2 (en) 2019-12-17 2023-08-15 Hewlett Packard Enterprise Development Lp System and method for value pack generation using generic SQL plugin for unified console
US11477258B2 (en) 2020-03-30 2022-10-18 Oracle International Corporation Serialization of objects using multiple serialization algorithms
US11599551B2 (en) 2020-03-30 2023-03-07 Oracle International Corporation Deserialization of stream objects using multiple deserialization algorithms
US11288045B1 (en) * 2021-02-09 2022-03-29 Oracle International Corporation Object creation from structured data using indirect constructor invocation
US11256480B1 (en) 2021-02-09 2022-02-22 Oracle International Corporation Deserialization of stream objects using constant-foldable method handles

Family Cites Families (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020156814A1 (en) * 1997-01-13 2002-10-24 Ho Bruce K. Method and apparatus for visual business computing
US6081263A (en) * 1997-10-23 2000-06-27 Sony Corporation System and method of a user configurable display of information resources
US6665687B1 (en) * 1998-06-26 2003-12-16 Alexander James Burke Composite user interface and search system for internet and multimedia applications
US6397384B1 (en) * 1998-12-18 2002-05-28 Adobe Systems Incorporated Run-time addition of interfaces
US6976210B1 (en) * 1999-08-31 2005-12-13 Lucent Technologies Inc. Method and apparatus for web-site-independent personalization from multiple sites having user-determined extraction functionality
US20020018078A1 (en) * 2000-06-07 2002-02-14 Khan Umair A. System, method, and article of manufacture for generating a customizable network user interface
WO2001090908A1 (en) * 2000-05-22 2001-11-29 Sap Portals Inc. Snippet selection
US6657647B1 (en) * 2000-09-25 2003-12-02 Xoucin, Inc. Controlling the order in which content is displayed in a browser
US7039875B2 (en) * 2000-11-30 2006-05-02 Lucent Technologies Inc. Computer user interfaces that are generated as needed
US8065620B2 (en) * 2001-01-31 2011-11-22 Computer Associates Think, Inc. System and method for defining and presenting a composite web page
US6986145B2 (en) * 2001-03-13 2006-01-10 Dipayan Gangopadhyay In-context access to relevant services from multiple applications and information systems by object schema traversal
EP1246059B1 (en) * 2001-03-26 2006-08-30 Sun Microsystems, Inc. Dynamic interface aggregation on demand
US7313621B2 (en) * 2001-05-15 2007-12-25 Sony Corporation Personalized interface with adaptive content presentation
US20040205554A1 (en) * 2001-08-22 2004-10-14 Goswami Kumar K. Systems and methods for accessing multiple internal information sources of a business from a composite web document
US7895522B2 (en) * 2001-09-28 2011-02-22 Ntt Docomo, Inc. Layout of platform specific graphical user interface widgets migrated between heterogeneous device platforms
US7454750B2 (en) * 2001-10-19 2008-11-18 Amberpoint, Inc. Integrator adaptor and proxy based composite application provisioning method and apparatus
WO2003077104A1 (en) * 2002-03-08 2003-09-18 Nokia Corporation Method and deice for providing a representation of applications for display on an electronic device
US7774791B1 (en) * 2002-04-24 2010-08-10 Informatica Corporation System, method and computer program product for data event processing and composite applications
JP2003345697A (ja) * 2002-05-27 2003-12-05 Hitachi Ltd 統合インタフェース提供方法、装置及び記憶媒体
US7076766B2 (en) * 2002-06-03 2006-07-11 Steve Wirts Software application development methods and framework
US7337401B2 (en) * 2002-12-18 2008-02-26 Microsoft Corporation User interface element representation with simplified view
US8510682B2 (en) * 2002-12-20 2013-08-13 Sap Ag Unifying navigation model
US20040168122A1 (en) * 2003-02-21 2004-08-26 Kobipalayam Murugaiyan Senthil Nathan System, method and computer readable medium for transferring and rendering a web page
US20040187140A1 (en) * 2003-03-21 2004-09-23 Werner Aigner Application framework
US20040207659A1 (en) * 2003-04-02 2004-10-21 International Business Machines Corporation Program creation by combining web services using graphic user interface controls
US7607110B2 (en) * 2003-10-23 2009-10-20 Microsoft Corporation Element persistent identification
US20050091584A1 (en) * 2003-10-23 2005-04-28 Microsoft Corporation Methods for applying styles to visual aspects of user interface elements
US7480664B2 (en) * 2003-10-23 2009-01-20 Microsoft Corporation Composite user interface and framework
US20050144226A1 (en) * 2003-11-10 2005-06-30 Churchill Software Services Systems and methods for modeling and generating reusable application component frameworks, and automated assembly of service-oriented applications from existing applications
US20050114378A1 (en) * 2003-11-24 2005-05-26 Microsoft Corporation System and method for providing a standardized adaptor framework
US8407718B2 (en) * 2003-12-23 2013-03-26 Corizon Limited Method and apparatus for composite user interface generation
US8176465B2 (en) * 2007-02-27 2012-05-08 Microsoft Corporation Pluggable model elements
US9032312B2 (en) * 2008-12-15 2015-05-12 Mastercard International Incorporated Platform for generating composite applications

Also Published As

Publication number Publication date
DE602004030621D1 (de) 2011-01-27
EP1711891B1 (en) 2010-12-15
US20200117486A1 (en) 2020-04-16
EP1711891A1 (en) 2006-10-18
US11138023B2 (en) 2021-10-05
US20180253323A1 (en) 2018-09-06
ATE491987T1 (de) 2011-01-15
US9864610B2 (en) 2018-01-09
US20220107820A1 (en) 2022-04-07
US10503528B2 (en) 2019-12-10
US11714665B2 (en) 2023-08-01
US20080163078A1 (en) 2008-07-03
WO2005076130A1 (en) 2005-08-18

Similar Documents

Publication Publication Date Title
ES2362573T3 (es) Método y aparato para la creación de una interfaz de usuario para aplicación compuesta.
US11171897B2 (en) Method and apparatus for composite user interface generation
US20040205473A1 (en) Method and system for implementing an enterprise information portal
US8650320B1 (en) Integration server supporting multiple receiving channels
CA2397647A1 (en) A method and system for implementing an enterprise information portal
JP2003518683A (ja) ユーザにデータを提示する方法および装置
US20150089408A1 (en) Method and framework for content viewer integrations
WO2000058873A1 (en) Workflow design engine
WO2002001388A2 (en) Portal server that provides a customizable user interface for access to computer networks
EP1061445A2 (en) Web-based enterprise management with transport neutral client interface
Kurniawan Servlet & JSP: A Tutorial
CA2592399C (en) Facilitating access to application data at an application server by a wireless communication device
Dallermassl Aspects of integration of heterogenous server systems in Intranets: the Java approach
Hillier Advanced SharePoint Services Solutions
Xue et al. The Definitive Guide to Yii 1.1
Janík Online Shop Web Tier in Java EE
Layka Building web applications using servlets and JSP
Cornell Building a dynamic Web/database interface
Leinecker ASP. Net Solutions: 23 Case Studies: Best Practices for Developers
Akin et al. Analysis of Java distributed architectures in designing and implementing a client/server database system
Xue et al. PRADO v3. 1.10 Quickstart Tutorial
Troelsen ASP. NET Web Pages and Web Controls
Kiura Versioned Access to a Content Management System Based on the Open Delta V Protocol
Ciftci Design and Implementation of Web Based Supply Centers Material Request and Tracking (SMART) System Using With JAVA and JAVA Servlets
Jörelid Servlet Examples