MXPA00007085A - Sistema de integracion de aplicacion de empresa distribuido extensible. - Google Patents

Abstract

Una arquitectura de agente-adaptador y un objeto de mensaje para utilizarse en sistemas y metodos, que integran aplicaciones del tipo normalmente desplegado a traves de una empresa en red. Un agente encapsula una pluralidad de adaptadores, cada uno de los cuales se adapta para realizar funciones separadas asociadas con las respectivas de una pluralidad de aplicaciones de la empresa. Este agente es extensible, e incluye uno o mas objetos empotrados. Cada objeto empotrado se adapta de una manera similar para realizar una funcion separada, que puede o no estar asociada con aquellas respectivas de la pluralidad de aplicaciones de la empresa. El objeto de mensaje incluye un esquema de mensaje, que se adapta para utilizarse con una pluralidad de accesores y una pluralidad de convertidores. El esquema de mensaje es una estructura de datos jerarquicos que incluye una pluralidad de elementos de mensaje, cada uno de los cuales se selecciona a partir de una pluralidad de elementos de seccion, una pluralidad de elementos de tabla, y una pluralidad de elementos de articulo. Los elementos de articulo contienen datos nativos de las seleccionadas de una pluralidad de aplicaciones de la empresa.

Description

00P0808 SISTEMA DE INTEGRACION DE APLICACION DE EMPRESA DISTRIBUIDO EXTENSIBLE RESUMEN Una arquitectura de agente-adaptador y un objeto de mensaje para utilizarse en sistemas y métodos, que integran aplicaciones del tipo normalmente desplegado a través de una empresa en red. Un agente encapsula una pluralidad de adaptadores, cada uno de los cuales se adapta para realizar funciones separadas asociadas con las respectivas de una pluralidad de aplicaciones de la empresa. Este agente es extensible, e incluye uno o más objetos empotrados. Cada objeto empotrado se adapta de una manera similar para realizar una función separada, que puede o no estar asociada con aquellas respectivas de la pluralidad de aplicaciones de la empresa. El objeto de mensaje incluye un esquema de mensaje, que se adapta para utilizarse con una pluralidad de accesores y una pluralidad de convertidores. El esquema de mensaje es una estructura de datos jerárquicos que incluye una pluralidad de elementos de mensaje, cada uno de los cuales se selecciona a partir de una pluralidad de elementos de sección, una pluralidad de elementos de tabla, y una pluralidad de elementos de artículo. Los elementos de artículo contienen datos nativos de las seleccionadas de una pluralidad de aplicaciones de la empresa . - .. _ > 2 imagen clara del negocio y, en breve, obstruirá las arterias corporativas. A pesar del hecho de que la integración de aplicación se ha vuelto crucial para una sobrevivencia competitiva de la corporación, no obstante en la técnica 5 anterior ha sido aceptable hacer a mano o "alquilar" el código hecho de acuerdo a las especificaciones para esos propósitos a un costo enorme a largo plazo para la corporación. Igualmente, se han hecho decisiones de integración de aplicación a largo plazo a los niveles más bajos posibles, basadas únicamente en 0 criterios de proyectos individuales. Debido a la naturaleza decididamente difícil de estos problemas, todavía se tiene que encontrar una solución de integración de aplicación de empresa (EAI) efectiva. La llegada de la Internet, la computación de 15 cliente/servidor, las fusiones y adquisiciones corporativas, la globalización y el rediseñamiento de procesos de negocios, han forzado juntos a los departamentos de tecnología de información (IT) corporativa a buscar continuamente nuevas, y frecuentemente manuales maneras para hacer que diferentes 0 sistemas hablen unos con los otros - sin importar qué tan antiguos puedan ser esos sistemas. En el consecuente caos, los sistemas de comunicaciones inadecuados han tenido un efecto debilitante en las capacidades de la tecnología de información para moverse tan rápido como necesita el negocio que lo hagan. 5 Las tendencias recientes en la IT solamente han agravado este problema por el incremento -frecuentemente por un orden de magnitud- de la cantidad de interconexión interaplicaciones que se necesita para soportarlas. Más recientemente, las aplicaciones de empresa han realizado funciones tales como almacenamiento de datos y planificación de recursos de la empresa (ERP) , y han facilitado el comercio electrónico. Una breve revisión de estas tres tecnologías, por lo tanto, sería provechosa para entender la necesidad sentida por largo tiempo pero todavía no resuelta por el EAI . Las técnicas de almacenamiento de datos requieren grandes volúmenes de datos históricos limpios que se deben mover, sobre una base regular, de muchos sistemas operacionales dentro del almacén. Los datos de la fuente usualmente están estructurados para el procesamiento transaccional en línea (OLTP) , mientras que el almacén de datos típico también acomoda formatos de procesamiento analítico en línea (OLAP) . Por lo tanto, los datos de la fuente deben experimentar agregación y reformación extensa a medida que éstos se transfieren al almacén . Un almacén típico de datos de conformidad con la técnica anterior se pobla en cuatro pasos: (a) extraer los datos de la fuente; (b) limpiar esos datos extraídos; (c) agregar los datos limpios, extraídos en un número de dimensiones; y (d) cargar el almacén. Cada fuente de almacén requiere la construcción de una rutina específica de extracción, limpieza, agregación, y carga de datos. Forrester Research estima que la compañía grande promedio tiene aproximadamente cuatro almacenes de datos. En dos años se espera que este número crezca a seis. También se espera que la cantidad promedio de datos contenidos en cada almacén se duplique en tamaño en el mismo período -de aproximadamente 130 gigabytes a aproximadamente 260 gigabytes . Los problemas asociados con esas grandes cantidades de datos que crecen a un paso siempre en incremento se agravan por la calidad de los datos de la fuente. De conformidad con un estudio conducido por el Grupo META, los almacenes de datos típicos se están cargando hoy con tanto como el 20 por ciento de datos de baja calidad. El mismo estudio indica que aproximadamente el 70 por ciento de sus respondedores usaron procesos de extracción, limpieza y carga que se codificaron a mano. Con respecto a los procesos de agregación requeridos, la evidencia anecdotal también revela que se pueden requerir tantas como 50 horas de tiempo de computadora para completar esta función sola. Es fácilmente evidente que con programas codificados de esa manera pudieran estar envueltos esfuerzos de mantenimiento significativos. Por otra parte, los sistemas ERP típicos (tales como la aplicación de empresa R/3 desarrollada por SAP AG de Walldorf, Alemania, así como aquellas desarrolladas por PeopleSoft, Oracle, y Baan) son aplicaciones empaquetadas integradas, esencialmente grandes, que soportan funciones de negocios de núcleo, tales como nómina de pago, fabricación, libro mayor general, y recursos humanos. Las corporaciones grandes encuentran particularmente atractivo comprar esas soluciones de software de una sola fuente, puesto que puede costar entre 10 a 20 veces más desarrollar la misma funcionalidad en casa que comprarla. La implementación de un sistema ERO, sin embargo, puede ser un proceso agobiante por muchas razones. Ante todo, la corporación está comprando un producto y no construyendo una solución. Esto significa que las unidades del negocio dentro de la corporación se deben adaptar al producto y a cómo trabaja éste, no al contrario. Además, los sistemas ERP de hoy no pueden reemplazar todas las soluciones de cliente de la corporación. Estas deben, por lo tanto, comunicarse de manera efectiva con otros sistemas legales en el lugar. Finalmente, no es atípico que una corporación emplee más de un sistema ERP completamente diferente, porque un solo vendedor usualmente no puede satisfacer toda necesidad organizacional . Como resultado, las opciones para obtener datos dentro y fuera de un sistema ERP imposibilitan los planteamientos que se usan para almacenamiento de datos. Cada sistema ERP tiene un modelo de datos propietario que mejora constantemente su vendedor. La escritura de las rutinas de · 6 extracción o carga que manipulan esos modelos no solamente es complicada, sino que además el vendedor la desaprueba puesto que es probable que se pasen por alto las reglas de validación y negocios inherentes en la aplicación de empresa. Más bien, los ERPs requieren de interacción al nivel del objeto de negocios que trata con las entidades de negocios específicas tales como libros mayores generales, presupuestos o cuentas pagaderas. Se pueden encontrar más detalles respecto a la implementación y el uso de un sistema ERP bien conocido y ampliamente aceptado en Special Edition Usinq SAP R/3 (2a. Edición), ISBN: 0-7897-1351- 9, de Que Corporation (1997) . De una forma u otra el comercio electrónico ha estado alrededor por muchos años. En esencia, éste tiene su comienzo con el intercambio electrónico de datos (EDI) . El EDI permite que las compañías comuniquen sus órdenes de compra y facturas electrónicamente, y continúa desarrollándose, de tal manera que las compañías de hoy usan el EDI para la administración de cadena de suministro. Sin embargo, no ha sido sino hasta el uso explotador más reciente de los sitios Web de Internet en línea para comprar, vender, y hasta subastar artículos de interés, que ha habido una extrema necesidad de un EAI robusto, efectivo. Ver, por ejemplo, la Patente de los Estados Unidos de Norteamérica Número 5,627,972. Las aplicaciones se han desarrollado con el objeto de cumplir con objetivos específicos del negocio en un marco de tiempo regular. En una organización grande típica, diferentes equipos de personas que usan una amplia variedad de sistemas operativos, DBMSs y herramientas de desarrollo desarrollan cientos de aplicaciones. En cada caso, los requerimientos específicos se satisfacen sin importar la integración con cualesquier otras aplicaciones. Muchas tendencias poderosas están conduciendo el mercado para la integración de aplicaciones. Por ejemplo, los desarrollos significativos en el trabajo por la red de par a par y el procesamiento distribuido han hecho posible que los negocios integren mejor sus propios departamentos funcionales, así como que se integren con sus socios y proveedores. La explosión de Internet/" intranet "/"extranet" mencionada anteriormente también está promoviendo la demanda de una nueva clase de aplicaciones "activas humanas" que requieren la integración con aplicaciones heredadas de fondo. El tremendo crecimiento alrededor del mundo en la adopción de paquetes de software de aplicación de empresa (por ejemplo, el SAP R/3) también requiere la integración con aplicaciones heredadas de fondo. Finalmente, el software especializado orientado a mensajes (MOM) -productos tales como el producto de lista lineal de mensajes QSeries de IBM- se está volviendo incrementadamente popular. Una vez que los clientes se dan cuenta de los beneficios de la conectividad simple de aplicaciones una-a-una con el MOM, se incrementa -». y - 8 significativamente su interés en la integración de aplicaciones de muchas-a-muchas . A medida que crece la necesidad de los negocios de integrarse, se incrementa rápidamente el número de dólares de IT gastados en la integración de las aplicaciones. De conformidad con diferentes analistas de la industria, la necesidad de la integración de aplicaciones de "misión crítica" conducirá al mercado combinado para que crezcan el MO y los "corredores de mensajes" de $300 millones en 1997 a más de $700 millones en 1999. De conformidad con una encuesta de IBM de clientes más grandes, casi el 70 por ciento de todos los códigos escritos hoy consisten de interfases, protocolos y otros procedimientos para establecer enlaces entre diferentes sistemas. Los ejecutivos de IT astutos pueden ver claramente los ahorros de dólares que se ganan por la adquisición de software del estante para satisfacer tantos de estos requerimientos como sean posibles. Un corredor de mensajes es un centro de software que registra y administra los contactos entre publicadores (es decir, los que envían) y suscriptores (por ejemplo, receptores) de mensajes. Cuando tiene lugar un evento de negocios, la aplicación publicará el (os) mensaje (s) que corresponde con ese evento de negocios. El corredor revisa sus listas de suscripciones y activa el envío a cada suscriptor para ese tipo de mensaje. Los suscriptores reciben únicamente los datos a los cuáles éstos están suscritos. Múltiples aplicaciones de consumidor pueden estar suscritas a un mensaje publicado por una aplicación. De manera similar, una aplicación de suscripción puede recibir mensajes desde múltiples aplicaciones publicadoras . Antes de que las aplicaciones puedan publicar o suscribirse a mensajes, éstas deben registrar su interés con el corredor. Existen dos métodos básicos y diferentes para que las aplicaciones registren interés en un tipo de mensaje direccionamiento basado en el tema, y filtración de contenido de mensajes. En el direccionamiento basado en el tema, el corredor usa el tema para identificar y encaminar el mensaje a todas las partes que expresen interés en ese tema. El tema es una palabra que se usa para describir el contenido del mensaje. Por ejemplo, un tema del nombre "hr. emp . new" , puede servir para distribuir información (por ejemplo, nombre, dirección, número de empleado, etcétera) sobre un empleado recién contratado. En el encaminamiento de contenido de mensaje, por otra parte, se hacen suscripciones basadas en el contenido de los campos adentro del mensaje. Las suscripciones se pueden basar en el tipo de mensaje y/o los criterios de selección específicos relativos a un campo adentro del mensaje. Por ejemplo, una aplicación de aprobación de préstamo podría suscribir a todas las órdenes de compra más de $100,000. Una ventaja de tener dos paradigmas de publicar/suscribir es que se evita la necesidad de dirigir mensajes a aplicaciones de suscripción individuales. Adicionalmente , se pueden añadir nuevas aplicaciones de suscripción sin ningún cambio a la aplicación publicadora. El corredor típico de publicación/suscripción usa un vehículo de envío robusto para la distribución real de mensajes entre aplicaciones. A medida que mensajes críticos por la misión viajan a través de una combinación de redes externas e internas, el software de sistemas asegura que los mensajes nunca se pierdan ni se dupliquen en el caso de fallas de la red. Más frecuentemente que lo contrario, se proporciona una capacidad de envío de mensajes asincrónico, la cual usa colocación en lista lineal de mensajes de almacenar-y-enviar . En este paradigma, la transferencia de lista lineal -a-lista lineal tiene lugar en tiempo seudo-real cuando está disponible la aplicación de suscripción. Si no está disponible la aplicación de suscripción, el mensaje se almacena en una lista lineal persistente para envío posterior. Para que sea efectivo, el vehículo de envío de mensajes debe incluir una función de coordinación de transacciones de negocios. Una transacción de negocios típicamente está constituida de muchas unidades de trabajo. Cada una y toda unidad de trabajo se debe completar, con el objeto de que ocurra la transacción. Si hasta una unidad de trabajo falla, toda la transacción falla, y se deben invertir todas las unidades completadas del trabajo. Estas transacciones son de ejecución larga y requieren de actualizaciones basadas en mensajes para múltiples bases de datos. La función de coordinación de transacciones de negocios proporciona este soporte administrativo. Otros dos componentes importantes son la máquina basada en reglas y el componente de transformación de datos. La máquina de reglas de negocios permite que las organizaciones procesen mensajes en base a los requerimientos únicos de su negocio. Típicamente, las máquinas de reglas de negocios proporcionan un extremo frontal visual para evitar la necesidad de programación en un lenguaje de procedimientos. Con este planteamiento flexible, se pueden reflejar fácilmente procesos de negocios en una configuración de reglas modificada. El componente de transformación de datos se usa para desarrollar adaptadores específicos a la aplicación. Estos adaptadores convierten los formatos de datos y la semántica de las aplicaciones de la aplicación de envío a la aplicación de recepción. Existen muchos requerimientos de conversión. Estos varían de la transformación básica de datos a la resolución de las incompatibilidades que existen entre la estructura (es decir, la sintaxis) , el significado (es decir, la semántica) y el cronometraje de la información que se debe compartir. De conformidad con la técnica anterior, existen dos estrategias principales para los adaptadores de aplicaciones.

Una estrategia es convertir todos los datos de la fuente y sincronizar (o "sync") las aplicaciones a una forma canónica estándar. Los mensajes se mueven del adaptador de la fuente al adaptador de sincronización en esta forma estándar. En el adaptador de sincronización, los mensajes se convierten al formato de la aplicación de sincronización. La segunda estrategia para los adaptadores de aplicación es convertir automáticamente el formato y la semántica de la aplicación de envío a la aplicación de recepción en un paso, sin ningún formato intermedio. En este planteamiento, solamente se requiere el adaptador para que dos aplicaciones se comuniquen una con la otra, y éste se puede integrar con cualquiera de las aplicaciones. La máquina basada en reglas y el componente de transformación de datos trabajan juntos para reconciliar las diferencias entre las aplicaciones. Por ejemplo, antes de que se puedan integrar dos aplicaciones alrededor de una orden, se deben definir las reglas del negocio respecto al procesamiento de órdenes adentro de cada sistema. Adentro de la Aplicación "A" , una orden debe comprender una colección de datos de múltiples archivos y bases de datos; mientras que adentro de la Aplicación "B", una orden debe existir como un mensaje individual anidado adentro de una fila más grande de transacciones de negocios. El reto difícil es resolver las incompatibilidades entre la estructura de los datos y el contenido subyacente de una orden según se defina en cada aplicación . Existen muchos beneficios potenciales para el negocio que proporciona el corretaje de mensajes. Antes que nada, está su facilidad de integración de aplicaciones. Con los corredores de mensajes, se puede realizar la integración de nuevas aplicaciones con aplicaciones heredadas o de terceros existentes, en un período de tiempo más corto. La integración puede tener lugar sin ninguna necesidad de entendimiento de la estructura interna y el diseño de cada aplicación. Por medio de enfocarse en la interfase como mensajes, se pueden integrar las aplicaciones existentes con mínima interrupción. El soporte para el comercio electrónico es un segundo beneficio que proporciona el corretaje de mensajes. A medida que los negocios empiezan a automatizar la cadena de suministro de sus vendedores y socios, existe una necesidad de que sus aplicaciones independientes se comuniquen de una manera libremente acoplada. Esta es precisamente la esencia y fuerza del corretaje de mensajes. El corredor de mensajes es completamente congruente con la necesidad del negocio. Finalmente, pero ciertamente no menos importante, es el soporte del corretaje de mensajes para la heterogeneidad continua. A medida que ha evolucionado la nueva tecnología, se han desarrollado nuevas arquitecturas, y la heterogeneidad se está incrementando a través del tiempo. Una metodología tal como el corretaje de mensajes está diseñada para acomodar al mundo heterogéneo de hoy, y será útil en el futuro. Se pueden añadir nuevas aplicaciones diferentes a través del tiempo ya sea como publicadores o suscriptores , sin ningún cambio a las aplicaciones existentes en el corredor de mensajes. En sumario, los corredores de mensajes tienen el potencial para proporcionar un planteamiento de mínimo común denominador para integrar las aplicaciones heterogéneas dentro de una empresa. Los usuarios pueden elegir la mejor tecnología para cada aplicación individual, sea Java® (una marca comercial registrada de Sun Microsystems, Inc., Mountain View, California, Estados Unidos) , Active X® (una marca comercial registrada de Microsoft Corporation, Redmond, Washington, Estados Unidos) , o CORBA® (una marca comercial registrada de Object Management Group, Inc., Framingham, Massachusetts , Estados Unidos) , sin importar cómo se integrará la aplicación con otras aplicaciones en la empresa. Los corredores de mensajes hacen un puente, mediante lo mismo, en el espacio intermedio entre las aplicaciones del futuro y los diferentes y complejos productos y tecnologías que existen actualmente en los catálogos de aplicación de hoy. Aunque hay muchos beneficios por adoptar una estrategia de corredor de mensajes, se debe tener en mente que también hay peligros ocultos potenciales. Las mismas fortalezas del corretaje de mensajes en términos de su libre flexibilidad de acoplamiento, también pueden ser sus mayores debilidades. La naturaleza del software corredor de mensajes, como se notó anteriormente, es muy generalizada. Debido a que éste está diseñado para manejar tantas condiciones diferentes, la prueba de todas las posibles trayectorias de código de extremo a extremo es una tarea infranqueable. Cuando existen errores indetectables en el software, los mensajes se pueden perder, enviar dos veces o suprimir. El daño por esos "accidentes" se sentiría más profundamente en empresas en donde se usan los corredores de mensajes para integrar aplicaciones de procesamiento de transacciones críticas por la misión. En las transacciones financieras, por ejemplo, el envío de un solo mensaje podría valer millones de dólares, mientras que al mismo tiempo su no envío o su envío retrasado podría dar como resultado la pérdida de millones. Un segundo riesgo por la implementación del corredor de mensajes es la posibilidad de que aplicaciones ajenas introduzcan mensajes no autorizados al corredor. Esto también puede dar como resultado pérdidas. Por ejemplo, en la industria bancaria, se podrían publicar mensajes falsificados y provocar mediante lo mismo el retiro o la malversación de fondos. Un tercer riesgo de la implementación del corredor de mensajes es el clásico "punto individual de falla". Los corredores de mensajes de la técnica anterior típicamente se han implementado en una arquitectura de "núcleo y rayo" . Esto significa que la mayor parte del tráfico de mensajes pasa a través de unos pocos núcleos centrales. En el caso de una interrupción de servicio o un desastre físico a uno de esos núcleos, las operaciones críticas por la misión de un negocio podrían llegar a una interrupción demoledora. Otro problema con los núcleos distribuidos es la dificultad para administrar el complejo corredor de mensajes. Debido a que un corredor de mensajes integra tantas diferentes aplicaciones del negocio en unos pocos núcleos consolidados, pudiera ser inasequible el talento y la pericia requeridos para administrar un corredor de mensajes complejo. La exposición a un riesgo potencial es grande siempre que se aplica la tecnología a aplicaciones de procesamiento de transacciones críticas por la misión de una empresa. Un problema para el corretaje de mensajes es que éste manipula información crítica por la misión. En términos relativos, el corretaje de mensajes es apenas nuevo. Sin embargo, aunque algunas compañías adoptantes tempranas han tenido gran éxito con el concepto de corretaje de mensajes, se necesita mucho más antes de que los corredores de mensajes y el EAI puedan entrar a la corriente principal . En los 1980 's el desarrollo de sistemas de software se concentró en la habilidad de los sistemas heterogéneos para comunicarse unos con los otros. Esto fue, en gran parte, debido a la proliferación de protocolos de comunicación propietarios.

Cualquier sistema recién desarrollado tenía que ya sea cumplir con la aplicación y los formatos de datos en el lugar para los sistemas con los cuales éste deseaba conectarse o comunicarse, o proporcionar a esa aplicación una traducción específica. De conformidad con lo anterior, todo el software se hacía de acuerdo a las especificaciones a un mayor o menor grado. En el medio ambiente actual rápidamente en cambio, los esfuerzos concertados de miles de desarrolladores alrededor del mundo están enfocados en el desarrollo de un sistema que satisfaga la necesidad de que aplicaciones diferentes se comuniquen unas con las otras, sin la necesidad de integrar múltiples esquemas de traducción hechos de acuerdo a las especificaciones, específicos a la aplicación. Esta necesidad hasta ahora no satisfecha está varada en lo imperativo de la economía global .

Sumario de la Invención De conformidad con lo anterior, es un objetivo general de la presente invención proporcionar sistemas y métodos para integrar aplicaciones de empresa, que al mismo tiempo proporcionen la administración completa de esas aplicaciones de empresa, incluyendo monitoreo, operación y configuración centralizados. Es un objetivo más específico de la presente invención proporcionar una arquitectura de agente-adaptador y esquema de mensajes, que juntos mejoren el recorrido y la manipulación del mensaje en esos sistemas y métodos. Otro objetivo de la presente invención es proporcionar en esos sistemas y métodos características de seguridad mejoradas, que incluyan aspectos tales como autentificación, autorización, privacidad, no rechazo, y auditoría . Todavía otro objetivo de la presente invención es proporcionar sistemas y métodos para integrar aplicaciones de empresa que incluyan elementos para recuperación de desastres, refinanciamiento con protección en caso de fallos, repetición de mensajes y registro de doble sitio. También es un objetivo global de la presente invención facilitar la integración rápida y simple de las aplicaciones ERP líderes, aplicaciones personalizadas/heredadas, aplicaciones empaquetadas , y bases de datos. Más específicamente, también es un objetivo de la presente invención reducir o sustancialmente eliminar la necesidad de codificación personalizada costosa que tradicionalmente se requiere para integrar las aplicaciones. Otro objetivo de la presente invención es proporcionar un sistema EAI , que tenga una arquitectura distribuida que facilite la conflabilidad a largo plazo, escalabilidad, flexibilidad, y extensibilidad que necesitan extensamente las empresas de hoy.

Todavía otro objetivo de la presente invención es proporcionar un sistema EAI que incremente el rendimiento sobre la inversión de una empresa, por medio de capacitar a la empresa para que eleve sus inversiones IT existentes, incremente su velocidad para el mercadeo, implemente soluciones y consiga beneficios más rápidamente, y reduzca sus costos operacionales . Todavía otro objetivo de la presente invención es proporcionar un sistema EAI que proporcione acceso más rápido a la información sobre clientes y facturación de una empresa, de tal manera que la empresa pueda dar servicio a sus clientes de manera más efectiva y eficiente, creando relaciones más fuertes, más efectivas. Otro objetivo de la presente invención es proporcionar un sistema EAI con muchos -a-muchos puntos de integración, que sustancialmente elimine las preocupaciones de los sistemas convencionales de núcleo-y-rayo y sus riesgos de punto-de-falla-individual . Todavía otro objetivo de la presente invención es proporcionar un sistema EAI que simplifique la arquitectura IT de una empresa, por medio de proporcionar un punto central de integración para virtualmente todas las aplicaciones y plataformas . Todavía otro objetivo de la presente invención es proporcionar un sistema EAI que proporcione participación de información eficiente y efectiva por el costo. Los métodos, aparatos, y artículos de fabricación descritos en la presente conseguirán los objetivos, ventajas, y características novedosas anteriores y otros, de conformidad con la presente invención, mientras que evitan los problemas descritos anteriormente en la presente. De conformidad con un aspecto importante de la presente invención, el método comprende elementos implementados por computadora para pasar mensajes entre una primera aplicación de computadora y una segunda aplicación de computadora. Ese método generalmente incluye los pasos de: (a) proporcionar un primer mensaje que tenga una primera estructura de datos de la primera aplicación de computadora; (b) publicar el primer mensaje para obtener un primer mensaje publicado; (c) convertir la primera estructura de datos del primer mensaje publicado, a una segunda estructura de datos para obtener un segundo mensaje; (d) publicar el segundo mensaje para obtener un segundo mensaje publicado; y (e) proporcionar el segundo mensaje publicado a la segunda aplicación de computadora. De conformidad con otro aspecto importante de la presente invención, el aparato comprende un sistema para integrar una pluralidad de aplicaciones de computadora. Ese aparato generalmente incluye un elemento para encaminar mensajes adentro del sistema; un elemento para almacenar una pluralidad de configuraciones de transformación de datos, y una pluralidad de reglas; un elemento para aplicar las configuraciones de transformación de datos a los mensajes; un elemento para aplicar las reglas a los mensajes; y un elemento para encaminar los mensajes entre el elemento para encaminar mensajes adentro del sistema y las aplicaciones de computadora, y tiene un elemento dedicado para encaminar mensajes para aplicaciones de computadora respectivas. Alternativamente, el aparato de la presente invención comprende un sistema para integrar una pluralidad de aplicaciones de computadora. El sistema generalmente incluye un sistema de mensajería de empresa que pasa mensajes entre las aplicaciones de computadora; un sistema de almacenamiento de base de datos, acoplado al sistema de mensajería de empresa, que almacena una pluralidad de configuraciones de transformación de datos, y una pluralidad de reglas; un servicio de integración, acoplado también al sistema de mensajería de empresa, y que comprende una máquina de transformación de datos que usa las configuraciones de transformación de datos almacenadas en el sistema de almacenamiento de la base de datos, y una máquina de evaluación de reglas que usa las reglas almacenadas en el sistema de almacenamiento de base de datos; y una pluralidad de agentes -adaptadores, acoplada además al sistema de mensajería de empresa, con cada agente-adaptador acoplado a una respectiva de las aplicaciones de computadora, para pasar mensajes entre el sistema de mensajería de empresa y la aplicación de computadora respectiva . De conformidad con todavía otro aspecto importante de la presente invención, el artículo de fabricación comprende un medio legible por computadora que abarca segmentos de código para integrar una pluralidad de aplicaciones de computadora. Los ejemplos no limitantes de ese "medio legible por computadora" a este respecto incluye cualquiera de: disco duro magnético; disco flexible; disco óptico, (por ejemplo, un CD-ROM, un CD-R, un CD-RW, o cualquier disco compatible con los estándares DVD conocidos) ; disco magnético-óptico ; cinta magnética; chip de memoria; ondas portadoras que se usan para llevar datos electrónicos legibles por computadora, tales como las que se usan para transmitir y recibir correo electrónico, o para accesar una red, incluyendo la Internet, intranets, extranets, redes privadas virtuales (VPN) , redes de área local (LAN) , y redes de área amplia (WAN) ; o cualquier otro dispositivo de almacenamiento que se use para almacenar datos accesibles mediante una computadora. Los ejemplos no limitantes de esos "segmentos de código" incluyen no solamente los segmentos de código de la fuente y los segmentos de código del objeto, sino también programas de computadora en cualquier lenguaje, instrucciones, objetos, software, o cualquier elemento para controlar una computadora. Esos segmentos de código generalmente incluyen: (a) un primer segmento de código para pasar mensajes entre las aplicaciones de computadora; (b) un segundo segmento de código para realizar la transformación de datos de los mensajes; (c) un tercer segmento de código para aplicar las reglas a los mensajes; y (d) una pluralidad de cuartos segmentos de código, cada uno de los cuales pasa mensajes entre aplicaciones de computadora respectivas y el primer segmento de código. De conformidad con todavía otro aspecto importante de la presente invención, los sistemas y métodos están dirigidos a una computadora. Los ejemplos no limitantes de una "computadora" incluyen cualquiera de: computadora de propósito general; procesador central; PC; navegador Web; cliente de correo electrónico; servidor de correo electrónico; archivo de la red o servidor de mensajería; dispositivo de Internet; teléfono inalámbrico; localizador; asistente digital personal (PDA) ; máquina de fax; cámara digital fija o de video; grabadora digital de voz o video; copiadora digital o escáner; televisión interactiva; combinación híbrida de cualquiera de los elementos de computación anteriores y una televisión interactiva; o cualquier otro aparato que comprenda un procesador, memoria, la capacidad para recibir entrada, y la capacidad para generar salida. Otros aspectos novedosos e igualmente importantes de la presente invención serán más evidentes por una descripción detallada de los mismos, cuando se consideren en conjunción con los siguientes dibujos.

Breve Descripción de los Dibujos La Figura 1 (a) ilustra un sistema de integración de aplicación de empresa (EAI) de conformidad con la presente invención, como se incorpora éste adentro de un medio ambiente que incluye sistemas heredados, aplicaciones de software empaquetadas, y sistemas de administración de base de datos relaciónales . La Figura 1 (b) ilustra un primer escenario en el que se usa el sistema que se muestra en la Figura 1(a) para integrar una aplicación de software empaquetada de planificación de recursos de la empresa (ERP) con sistemas heredados personalizados. La Figura 1(c) ilustra un segundo escenario en el que se usa el sistema que se muestra en la Figura 1 (a) para integrar dos o más aplicaciones de software empaquetadas ERP diferentes . La Figura 1(d) ilustra un tercer escenario en el que se usa el sistema que se muestra en la Figura 1 (a) para integrar una o más aplicaciones de software empaquetadas de ejecutivos, con una o más aplicaciones de software empaquetadas de oficina general. La Figura 1 (e) ilustra un cuarto escenario en el que se usa el sistema que se muestra en la Figura 1 (a) para integrar aplicaciones de software de almacenamiento de datos, que usan dos o más sistemas de administración de base de datos relaciónales (RDBMS) diferentes, o sistemas de administración de base de datos de múltiples dimensiones. La Figura 2 es un diagrama de bloques del sistema EAI que se muestra en las Figuras 1(a) a 1(e). La Figura 3 ilustra un estuche de desarrollo de adaptador que se usa en el sistema que se muestra en la Figura 2. La Figura 4 (a) ilustra una arquitectura de agente-adaptador básica que es útil de conformidad con una primera modalidad de la presente invención. La Figura 4 (b) ilustra una arquitectura de agente-adaptador extensible, que es útil de conformidad con una segunda modalidad de la presente invención. La Figura 4 (c) es un diagrama de bloques que ilustra una modalidad actualmente preferida de un agente-adaptador de conformidad con la invención. Las Figuras 5(a) a 5(c) ilustran los objetos de diseño e integración que se usan en el sistema de conformidad con la presente invención. La Figura 6 ilustra un esquema de mensajes que se usa en el sistema de conformidad con la presente invención. La Figura 7 muestra otros objetos de conformidad con la presente invención.

La Figura 8 ilustra un proceso de transformación típico que se usa de conformidad con la presente invención. La Figura 9 también ilustra el proceso de transformación que se muestra en la Figura 8. Las Figuras 10 (a) y 10 (b) ilustran la conveniencia de los núcleos de mensajes de conformidad con la presente invención . Las Figuras 11(a) a 11(c) ilustran diferentes ambientes de operación en los que se administran los nodos y servicios de conformidad con la presente invención. La Figura 12 es un diagrama de bloques que ilustra los servicios del sistema de conformidad con la presente invención . La Figura 13 es un diagrama de flujo que ilustra los pasos necesarios para crear un mensaje de conformidad con la presente invención, sin convertir datos puros. La Figura 14 es un diagrama de flujo que ilustra los pasos necesarios para crear un mensaje de conformidad con la presente invención, por medio de convertir datos puros. La Figura 15 (a) ilustra un método para crear un mensaje a partir de una aplicación a un ejemplo de mensaje, de conformidad con una primera modalidad de la presente invención. La Figura 15 (a) ilustra un método para crear un mensaje a partir de una aplicación a un ejemplo de mensaje, de conformidad con una segunda modalidad de la presente invención.

La Figura 15(c) ilustra un método para crear un mensaje a partir de una aplicación a un ejemplo de mensaje, de conformidad con una tercera modalidad de la presente invención. La Figura 15 (d) ilustra un método para crear un mensaje a partir de una aplicación a un ejemplo de mensaje, de conformidad con una cuarta modalidad de la presente invención. La Figura 16 es un diagrama de primera clase de conformidad con la presente invención. La Figura 17 es un diagrama de segunda clase de conformidad con la presente invención.

Descripción Detallada de la Invención El Medio Ambiente de Tiempo de Ejecución de Computación de Empresa Refiriéndonos ahora a los dibujos, en donde los mismos caracteres de referencia o números designan las mismas partes o partes correspondientes a lo largo de cada una de las muchas vistas, en la Figura 1(a) se muestra una vista simplista de un medio ambiente de tiempo de ejecución 10 de computación de empresa. Los medio ambientes de tiempo de ejecución 10 típicos usan una pluralidad de aplicaciones de software empaquetadas, que incluyen aplicaciones de "oficina general" 20 para planificación de recursos de la empresa (ERP) , y aplicaciones de "ejecutivos" 30 para la administración de la relación con el cliente (CRM) , uno o más sistemas heredados personalizados 40, y uno o más sistemas de administración de base de datos de múltiples dimensiones/relaciónales (RDBMS) 50. A lo largo de las pasadas pocas décadas, las empresas de negocios han diseñado comprado muchas aplicaciones de software de un solo propósito grandes. Estas aplicaciones "heredadas" se continúan usando, y más frecuentemente se diseñaron para realizar una función específica (por ejemplo, inventario, finanzas, contabilidad, automatización de la fuerza de ventas, y recursos humanos) . Más recientemente, esas mismas empresas también han hecho inversiones sustanciales para procurar aplicaciones de software empaquetadas de los desarrolladores de software tales como SAP, PeopleSoft, Oracle, y Baan. Cada una de estas aplicaciones de software empaquetadas disfrutaron sus propias fortalezas únicas. De conformidad con lo anterior, la empresa de negocios típica usó dos o más aplicaciones de software empaquetadas diferentes en el mismo medio ambiente de tiempo de ejecución. Esas aplicaciones de software empaquetadas en el principio no estaban diseñadas para compartir información entre ellas mismas. Como resultado, se ha forzado a las empresas a integrar sus diferentes aplicaciones de software empaquetadas con códigos personalizados costosos. Esos esfuerzos de integración frecuentemente toman meses, si no años, para terminarse. El sistema de integración de aplicación de empresa (EAI) , tal como el sistema 100 que se muestra en la Figura 1(a) , por lo tanto, se vuelven una necesidad. Sin embargo, a diferencia de los sistemas EAI de conformidad con la técnica anterior, el sistema 100 comprende un software especializado orientado a soluciones, el cual facilita el que sus usuarios modifiquen o integren completamente la información que reside adentro de las diferentes aplicaciones, a través de una sola infraestructura común. Esto le permite al usuario mover información limpiamente, transparentemente, y rápidamente entre empleados, clientes, y proveedores, para conseguir la máxima productividad. De esa manera, el sistema 100 proporciona un sistema de mensajería confiable de almacenar-y-enviar, una instalación de corretaje de mensajes capaz, y una arquitectura de agente-adaptador fuerte para integrar diferentes aplicaciones de la empresa. Este está adaptado para distribuirse, y está diseñado para fácil administración y manejo. Este está dirigido para satisfacer los requerimientos de computación completos, heterogéneos de una organización grande. Este enlaza de manera inteligente diferentes aplicaciones, de tal manera que éstas puedan accesar y compartir información. Es el software especializado el que se adapta a las aplicaciones, en lugar de forzar a las aplicaciones a adaptarse a éste. El sistema 100 resuelve la mayor parte de los problemas del EAI por medio de habilitar a sus usuarios para enlazar aplicaciones ERP 20, aplicaciones empaquetadas 30, aplicaciones personalizadas y heredadas 40, y bases de datos 50, a lo largo de la empresa, con mínima codificación personalizada. Cuando está completamente integrado, una empresa puede sincronizar rápidamente los negocios y divisiones globales, y responder a las demandas de mercado siempre en cambio. Con el acceso más rápido a la información de clientes y facturación, la organización del usuario puede dar servicio a los clientes de manera más efectiva y eficiente, creando relaciones más fuertes, más efectivas. El sistema 100 es una solución de integración de empresa céntrica al negocio, con un medio ambiente de diseño del flujo de integración que se dirige al analista de negocios. El analista define el problema en términos de negocios, y el producto maneja los temas técnicos. Por ejemplo, como se muestra en la Figura 1(b), el escenario común de la integración de la planificación de recursos de la empresa (ERP) con los sistemas heredados demanda que la organización encapsule procesos complejos de manera apropiada dentro de implementaciones ERP estándares - una cosa no fácil de hacer. Muchas corporaciones eligen implementar aplicaciones empaquetadas para procesos de negocios estándares tales como inventario y administración de órdenes. Pero las aplicaciones empaquetadas raramente se usan para procesos verticales. Para estos propósitos, es ideal el sistema 100. Este proporciona interfases de objetos para los sistemas ERP 22, 24, 26, 28, así como tecnología de generación envolvente para enlazarse con sistemas heredados 44, 48. La extensión de la cadena de suministro global también requiere que el software especializado conecte dos o más sistemas ERP 22, 24, 26, 28 diferentes. Como se ilustra en la Figura 1 (c) , se puede notar fácilmente que nada puede ser más importante para una colaboración de negocio-a-negocio. El sistema 100, por lo tanto, juega un papel clave por medio de habilitar transacciones inter-ERP en las que los eventos del negocio en un sistema (por ejemplo, el sistema SAP 22) invoquen eventos correspondientes en otro sistema (por ejemplo, el sistema Baan 28), sin exponer los detalles de la tecnología subyacente . La integración de los "ejecutivos" con su "oficina general" de una corporación es una función importante, que permite que las aplicaciones de ejecutivos que interactúan con el cliente colaboren con las aplicaciones de producción especializadas. Por ejemplo, y refiriéndonos ahora a la Figura 1 (d) , es críticamente importante que los sistemas de soporte al cliente colaboren con los módulos de inventario ERP. El sistema 100, por lo tanto, facilita la integración de las mejores aplicaciones de ejecutivos y oficina general limpia y transparentemente . En el escenario de almacenamiento de datos que se muestra en la Figura 1(e) , los datos de los diferentes sistemas deben migrar a un almacén o depositario de datos central. El movimiento de información en tiempo real de muchos sistemas ERP (no se muestran en la Figura 1(e)) a una base de datos central relacional o de múltiples dimensiones, que contenga una pluralidad de diferentes bases de datos 53, 56, 59 es un ejemplo de este problema. Sin embargo, los desarrolladores de almacenes de datos puede elevar los servicios de traducción de datos del sistema 100, como se describe con mayor detalle posteriormente en la presente, para la agregación de datos en tiempo real u otras operaciones. Mediante lo mismo se traducen los datos a una condición entendible y con significado.

Definiciones A medida que se usan posteriormente en la presente, aquellos de experiencia ordinaria en la técnica deben considerar los siguientes términos de conformidad con su significado ordinario y acostumbrado. Al grado que las definiciones, que aparecen posteriormente en la presente, difieran de las definiciones de otra manera convencionales, conocidas para aquellos de experiencia ordinaria en la técnica, se debe notar que esos términos se declaran claramente posteriormente en la presente de una manera tal como para notificar a uno razonablemente experto en la técnica que el solicitante intentó redefinir así ese término reivindicado. Un "accesador" es una función especificada en las definiciones del mensaje que usa el sistema 100 para accesar datos. Los accesores identifican el inicio y el fin de los campos de datos de aplicación y los elementos del mensaje del sistema, y remueven o insertan marcadores. Las " implementaciones de adaptador" son códigos diseñados para una aplicación específica, que pueden extraer datos y producir mensajes del sistema; recibir mensajes del sistema y actualizar datos; o extraer datos en respuesta a solicitudes. Cuando el usuario crea un adaptador para usarlo en un flujo de integración, el usuario lo construye alrededor de una implementación de adaptador. Las implementaciones de adaptador del sistema proporcionan manejo de excepción básico, y pueden manejar cualquier definición del mensaje. Un usuario crea implementaciones de adaptador personalizadas usando un ADK, como se define y describe con mayor detalle posteriormente en la presente. Los "adaptadores" son objetos de flujo de integración que interactúan con aplicaciones de empresa para extraer datos o insertar, actualizar, o suprimir datos. La "consola de administración" es una interfase de usuario gráfica (GUI) a través de la cual un administrador de sistema configura y administra los nodos y servicios del sistema 100. Los "servicios de agente" proporcionan servicios del sistema a los adaptadores. Se requiere un servicio de agente en cada anfitrión que ejecute un adaptador.

Una "trayectoria de clase" es un medio ambiente variable que le dice a la máquina virtual de Java en dónde encontrar las bibliotecas de clase, incluyendo las bibliotecas de clase definidas por el usuario. Los "clientes" son procesos que accesan remotamente los recursos del servidor de computadora, tales como energía de computación y capacidad de memoria grande. Los clientes de sistema típicos son la mesa de trabajo de integración 120 y la consola de administración 160 (Figura 3) . Una "conexión" es un objeto que especifica los parámetros de arranque o conexión para los adaptadores. Por ejemplo, una conexión RDBMS especifica el controlador JDBC, el URL o la base de datos, el nombre del usuario, y la palabra clave . "Convertir" datos es un proceso en el cual los convertidores especificados en las definiciones del mensaje convierten los tipos de datos nativos de una aplicación a los tipos de datos de Java que soporta el sistema 100, y viceversa. Un "convertidor" es una función especificada en las definiciones del mensaje que usa el sistema 100 para convertir datos. De esa manera, los convertidores convierten tipos de datos nativos a los tipos de datos de Java que soporta el sistema 100, y viceversa. Las " implementaciones de adaptador personalizadas" son códigos diseñados para una aplicación específica, que pueden: ya sea extraer datos y producir mensajes del sistema; recibir mensajes del sistema y actualizar datos; o extraer datos en respuesta a solicitudes. Las implementaciones de adaptador personalizadas, creadas usando el ADK, pueden conectarse a las aplicaciones que en ese momento no soporta el sistema 100. Un "objeto de definición" es un objeto de flujo de integración que proporciona instrucciones para un proceso que va a implementar el sistema. Los "delimitadores" son contraseñas de paso o marcadores que separan campos de datos en datos de las aplicaciones de la empresa. Una "suscripción durable" es una propiedad de los núcleos de mensajes del sistema, que aseguran que los objetos objetivo del núcleo reciban todos los mensajes enviados a ellos. Si un objeto objetivo se vuelve inactivo, el sistema recuerda esos mensajes, que ha recibido el objetivo. Cuando el objetivo se vuelve después activo, el sistema envía los mensajes que todavía no ha recibido el objetivo. Las "aplicaciones de empresa" son aplicaciones a partir de las cuales los adaptadores extraen datos, o a los cuales propagan datos los adaptadores (por ejemplo, SAP R/3 o QSeries) . Un "Servicio de Mensajería de Empresa", de conformidad con esta invención, se implementa usando el Servicio de Mensajería de Java (J S) . Este le permite al sistema 100 usar múltiples nodos de mensajería, y soporta núcleos de mensajes y proporciona persistencia de mensajes. Las aplicaciones de "planificación de Recursos de la Empresa (ERP) " proporcionan una solución 'llave en mano' (por ejemplo, administración de almacén, administración de recursos humanos, y administración de materiales) para problemas comunes de los negocios. Los ejemplos de productos ERP son SAP R/3, PeopleSoft, y Baan. Un "EntireX Broker (ETB) " es un software especializado de plataforma transversal, orientado a mensajes, de conformidad con esta invención, que enlaza el procesador central, Windows NT, y las aplicaciones y componentes UNIX, clientes de Internet e intranet, y las estaciones de trabajo habilitadas por ActiveX y Java. Las "definiciones de filtro" son objetos de definición que especifican criterios para clasificar mensajes fuera de los flujos de integración. Un "anfitrión de funciones" es una plataforma de computación, tal como un servidor o estación de trabajo Windows NT, o procesador central OS/390. Los "núcleos" son objetos de flujo de integración que reciben mensajes de objetos de fuente, y retienen los mensajes hasta que el sistema 100 los envía a objetos objetivo especificados. Los núcleos permiten que los adaptadores y los transformadores intercambien mensajes de manera asincrónica. Estos también son útiles para concentrar los flujos de mensajes; múltiples objetos que produzcan la misma clase de mensajes pueden enviar, todos ellos, esos mensajes a un núcleo de mensajes, lo cual simplifica los enlaces entre los objetos. Un "Extractor de IDoc" lee los archivos planos producidos por la transacción WE63 de SAP R/3 para crear configuraciones de implementación y definiciones de mensajes, y las almacena en el servicio depositario del sistema. Los "ajustes de implementación" son parámetros de tiempo de ejecución para los adaptadores (por ejemplo, un intervalo de sondeo) . Un "flujo de integración" es una serie de objetos del sistema enlazados, que mueven datos de una o más aplicaciones de la empresa a otras aplicaciones de la empresa. Los "objetos de integración" son objetos de flujo de integración que envían mensajes, reciben mensajes, o ambos. Ver, por ejemplo, adaptadores, núcleos, y transformadores. Una "mesa de trabajo" de integración es una interfase de usuario gráfica (GUI) a través de la cual un usuario diseña los flujos de integración. Los "documentos intermedios (IDoc) " son un formato de datos SAP R/3 que usa el R/3 para intercambiar datos con otros sistemas R/3 y con otras aplicaciones. Un "elemento de mensaje de temas" es un elemento de mensaje que contiene datos. Los temas son los elementos de mensaje de nivel más bajo en la jerarquía de la definición de mensajes. Estos no pueden contener otros elementos del mensaje. La " Conectividad de Base de Datos de Java (JDBC) " es el estándar API de Java para el acceso de base de datos basado en SQL. Un "Estuche de Desarrollo de Java (JDK) " es un medio ambiente de desarrollo de software para escribir aplicaciones en el lenguaje de programación de Java. El "Servicio de Mensajes de Java (JMS) " es una API de Java especificada por Sun Microsystems para mensajería. Una "Interfase de Nombramiento y Directorio de Java (JNDI) " es un conjunto de APIs que ayudan con la interconexión de múltiples servicios de nombramiento y de directorio. El "Medio Ambiente de Tiempo de Ejecución de Java (JRE) " es un subconjunto del Estuche de Desarrollo de Java, que se usa para volver a distribuir el medio ambiente de tiempo de ejecución que consiste de la máquina virtual de Java, las clases de núcleo de Java, y archivos de soporte. Una "máquina virtual de Java (JVM) " es parte del Medio Ambiente de Tiempo de Ejecución de Java responsable de los códigos de bytes de interpretación. Los "marcadores de enlace" son contraseñas de paso o delimitadores que separan campos de datos en datos de las aplicaciones de la empresa.

Una "categoría de definición de mensajes" es un agrupamiento lógico para definiciones de mensajes. Las "definiciones de mensaje" son objetos de definición, que identifican que el sistema 100 va a extraer datos de, o propagar datos a una aplicación de la empresa. Las definiciones de mensajes también definen cómo el sistema 100 va a construir mensajes del sistema a partir de datos de aplicación de la empresa, o crear datos de aplicación de la empresa a partir de mensajes del sistema. Un "elemento de mensaje" es un objeto de datos que conforma el esquema del mensaje de una definición de mensaje. Los elementos de mensaje están configurados en una estructura jerárquica, y pueden ser secciones, tablas, o temas. El "Software especializado Orientado a Mensajes (MOM) " es un software que usa los mensajes para habilitar aplicaciones en la misma o diferentes plataformas para comunicarse. Los protocolos de comunicación están escondidos de las aplicaciones. Los ejemplos de MOMs son MQSeries, EntireX Broker, y JMS . La "persistencia de Mensajes" se relaciona con el almacenamiento de mensajes sobre medios que se pueden recuperar. El sistema escribe cada mensaje que envía desde un objeto de integración hasta otro, para poner el almacenamiento en una ubicación que especifique el usuario. Si ocurre una falla del sistema mientras un mensaje está en tránsito, el sistema 100 puede recuperar el mensaje del almacén cuando se restablezca el sistema 100, y enviar el mensaje a sus obj etivos . Un "esquema de mensaje" es esa parte de las definiciones de mensaje que define cómo estructurar un mensaje. Los esquemas de mensajes pueden incluir elementos de mensaje por sección, tabla, y tema, configurados en una estructura j erárquica . Los "Servicios de Monitoreo" almacenan datos de tiempo de ejecución del sistema, incluyendo registros del sistema e información estadística. Un "nodo" es un proceso físico (o máquina virtual de Java) que soporta uno o más servicios del sistema y de aplicación . Los "anfitriones de nodo" son software que habilita al usuario para configurar y ejecutar nodos en una máquina. El usuario debe instalar un anfitrión de nodo en toda máquina, aparte del administrador de nodo, que vaya a hospedar un nodo. Un "administrador de nodo" es una interfase a través de la cual se administran los nodos. La interfase permite que el usuario configure, inicie, pause, o detenga un servicio. Los administradores de nodo también inician y detienen nodos. El administrador de nodo mantiene el estado de todos los servicios que se distribuyen a los nodos. En adición, el administrador de nodo mantiene la información del estado (por ejemplo, el estado en curso, o el nivel de actividad) de un nodo o servicio. La "mensajería de punto-a-punto" es un estilo de mensajería para núcleos, en los cuales el sistema envía cada mensaje que llega al núcleo, únicamente a un objetivo de núcleo individual (es decir, el primer objetivo disponible) . Un "mensaje de entrada primario" son los datos de entrada principales para los procesos de transformación del sistema especificados en las definiciones transformadoras. El sistema toma los datos de entrada, los transforma, y crea datos de salida que necesitan las aplicaciones objetivo. La "mensajería de publicar/suscribir" es un estilo de mensajería para núcleos en los cuales el sistema envía cada mensaje que llega al núcleo a todos los objetivos del núcleo. Un "replicador" es un objeto del sistema, tal como un adaptador de respuesta, que proporciona datos cuando los transformadores los solicitan durante el proceso de transformación de datos. Los "adaptadores de respuesta" son objetos de integración que responden a las solicitudes de datos de otros objetos de integración, mediante la extracción de los datos desde las aplicaciones, y enviándolos a los objetos de solicitud. Los solicitadores envían mensajes del sistema que contienen datos en elementos de mensaje claves, y los adaptadores de respuesta insertan los datos en los elementos de mensaje relacionados, y envían los mensajes del sistema de regreso . Un "servicio depositario" se interconecta por medio de la Interfase de Directorio Nativa de Java, y almacena las configuraciones para todos los servicios configurados y los objetos de flujo de integración. Los "servicios de encaminamiento" habilitan al sistema para dirigir mensajes a través del sistema, en base al contenido de un mensaje, incluyendo el contenido del mensaje de filtración, de conformidad con los criterios que defina el usuario. El servicio de encaminamiento soporta a los filtros. Un "mensaje del sistema" es un mensaje, en el formato de plataforma-neutro, que usa el sistema para mover los datos de aplicación a aplicación. Los "elementos de mensaje de sección" son grupos no repetidores de los elementos de mensaje que no contienen datos reales. Estos contienen otros elementos de mensaje que contienen datos (es decir, contienen temas) . Las secciones pueden contener cualquier combinación de tipos de elemento de mensaje . Un "servicio" es un proceso que proporciona funcionalidad de producto. El sistema está conformado de servicios de sistema, mensajería, integración, y agente. Los "adaptadores de fuente" son objetos de integración que extraen datos de las aplicaciones de la empresa, construyen mensajes del sistema a partir de los datos, y envían los mensajes a otros objetos de integración del sistema . Un "objeto de fuente" es un objeto de flujo de integración que proporciona mensajes a otros objetos. Ver, por ejemplo, adaptadores de fuente, transformadores, y núcleos. Los "mensajes de entrada de soporte" son datos de entrada opcionales para los procesos de transformación del sistema, como se especifica en las definiciones del transformador. Los procesos de transformación usan datos de mensaje de entrada de soporte para complementar los datos de mensaje de entrada primarios. El sistema toma los datos de entrada, los transforma, y crea los datos de salida que necesitan las aplicaciones objetivo. Un "elemento de mensaje de tabla" es un grupo de elementos de mensaje de sección, llamados filas, que se pueden repetir cualquier número de veces. Los elementos de tabla no contienen datos reales. Más bien, contienen otros elementos de mensaje que contienen datos (es decir, contienen temas). 'Las tablas pueden contener cualquier combinación de tipos de elemento de mensaje. Los "adaptadores de objetivo" son objetos de integración que reciben mensajes del sistema desde otros objetos de integración, crean datos de aplicación a partir de los mensajes del sistema, y propagan los datos a aplicaciones obj etivo .

Un "objeto de integración objetivo" es un objeto de flujo de integración que recibe mensajes desde otros objetos. Ver, por ejemplo, adaptadores de objetivo, transformadores, y núcleos . El "Monitor de Procesamiento de Transacciones (TPM) " es un sistema de software diseñado para optimizar el uso de los recursos de computación, tales como almacenamiento y aplicaciones, para muchos usuarios. "Transformar datos" es un proceso en el cual los transformadores modifican los datos tomados de una o más aplicaciones de la empresa, a datos que necesitan otras aplicaciones de la empresa. Los "servicios de transformación" le permiten al sistema transformar mensajes, incluyendo datos de mensajes de división, de mensajes de combinación, y de mensajes de manipulación. El servicio de transformación soporta a los transformadores . Un "paso de transformación" es un comando que conforma el proceso de transformación. Cada paso ya sea lee los datos del mensaje, transforma y mapea datos de mensaje de entrada a definiciones de mensaje de salida, o escribe los datos transformados a mensajes de salida. Las "definiciones transformadoras" son objetos de definición que definen cómo va a transformar el sistema los mensajes del sistema extraídos de una o más aplicaciones de la empresa, a mensajes del sistema que necesitan otras aplicaciones de la empresa. Un "transformador" es un objeto de integración que implementa definiciones transformadoras. Los transformadores reúnen los mensajes de entrada de los objetos de integración de fuente, transforman el contenido y el formato de los datos del mensaje, y producen y envían mensajes de salida a los objetos de integración objetivo. Los "servicios de interfase del usuario (UIS) " proporcionan las instalaciones de interfase del usuario necesarias para ejecutar los componentes del cliente (es decir, la mesa de trabajo de integración 120 y la consola de administración 160) . Refiriéndonos ahora a la Figura 2, el sistema 100 generalmente comprende una pluralidad de componentes de diseño 110, y una pluralidad de componentes de administración de tiempo de ejecución 150. Los componentes de diseño 110, a su vez, comprenden más específicamente una mesa de trabajo de integración 120, un estuche de desarrollo de adaptador (ADK) 130, y un servicio depositario 140. Los componentes de administración de tiempo de ejecución 150, a su vez, comprenden más específicamente una consola de administración 160, un servidor de integración 170, que incluye una máquina de mensajería de empresa 180, un componente de servicios de nodo 190, y una pluralidad de agentes-adaptadores inteligentes 200.

La mesa de trabajo de integración 120 generalmente comprende una herramienta de modelaje y configuración gráfica para el desarrollo del proyecto de integración. Esta se usa para definir eventos, aquellos mensajes asociados con esos eventos, flujos de integración, y reglas del negocio asociadas con esos flujos de integración, así como para identificar a aquellos agentes que publican y se suscriben a los eventos definidos. En adición, la mesa de trabajo de integración 120 proporciona diagnósticos para la verificación de la consistencia y probar los flujos de integración. El ADK 130 se usa para configurar y generar agentes-adaptadores 200 inteligentes personalizados. En la Figura 3 se muestra con mayor detalle el ADK 130 que generalmente comprende una estructura de objetos que incluye bibliotecas de clase 132, asistentes 134, y plantillas 136. El ADK 130 genera objetos que se pueden accesar desde herramientas de desarrollo convencionales. Aunque el sistema 100 incluye una pluralidad de agentes-adaptadores 200 inteligentes estándares para una amplia diversidad de aplicaciones y recursos, puede haber aplicaciones específicas para las cuales no haya ningún agente-adaptador 200 inteligente estándar. En ese caso, el ADK 130 también permite que aquellos desarrolladores que estén más familiarizados con las interfases publicadas que proporciona el medio ambiente de aplicación objetivo, construyan un agente-adaptador 200 inteligente personalizado.

El servicio depositario 140 generalmente comprende una base de datos relacional, que contiene todas las especificaciones para el sistema 100, metadatos, y reglas de servicio del corredor de mensajes, y una interfase para esa base de datos relacional. La consola de administración 160 se usa para configurar y administrar el medio ambiente de tiempo de ejecución del sistema 100, y generalmente comprende una consola gráfica. Esta sirve como un punto de control para la configuración, el mantenimiento, el monitoreo, y el diagnóstico del sistema. A través de la consola de administración 160, se administra cada uno de los componentes individuales del sistema 100, incluyendo los servicios comprensivos tales como iniciación y terminación de componente, y distribución de software integrada. El servidor de integración 170 implementa mensajería inteligente por medio de activar y ejecutar los flujos de integración para los eventos del proceso. Este ejecuta reglas sensibles al contexto estáticas y dinámicas, que evalúan, modifican, y encaminan los datos de evento. Como se notó anteriormente en la presente, el servidor de integración 170 incluye la máquina de mensajería de empresa 180, que comprende un subsistema de mensajería distribuido, que administra todos los datos de evento. Este es, por una parte, un componente clave del sistema 100. Por otra parte, éste es bastante transparente para cualquier usuario del sistema 100, y generalmente opera detrás de las escenas. Este soporta la persistencia completa, el envío de un mensaje de una vez y solamente una vez, y un modo en-memoria para los requerimientos de mensajes de alto volumen, no críticos. El componente de servicios de nodo 190 administra la recuperación de inicio/reinicio, el manejo de excepción, y la configuración dinámica del sistema 100. Este proporciona instalaciones para la instalación automatizada del sistema, y la administración remota a través de todos los clientes y servidores participantes. Por otra parte, éste es fácilmente capaz de instalar y actualizar los componentes remotamente. Como se notó anteriormente en la presente, la pluralidad de agentes-adaptadores 200 inteligentes incluye no solamente aquellos agentes -adaptadores 200 inteligentes estándares que se distribuyen con el sistema 100, sino también aquellos agentes-adaptadores 200 inteligentes personalizados que se desarrollan mediante el ADK 130. Cada uno de esos agentes-adaptadores 200 inteligentes, sin importar su tipo, generalmente comprende un módulo de ínterfase de tiempo de ejecución que conecta uno particular de los recursos de aplicación externos 300 al sistema 100. Refiriéndonos por el momento a las Figuras 4(a) y 4 (b) , se puede notar que esos agentes-adaptadores 200 inteligentes, de conformidad con un aspecto particularmente importante de la presente invención, combinan la funcionalidad de los agentes autónomos con la tecnología del adaptador. El componente del agente 210 actúa como un proceso de software independiente, que hospeda uno o más componentes de adaptador 220 (Figura 4(a)), ó 222 y 224 (Figura 4(b)). Este encapsula funcionalidad sofisticada tal como almacenar y enviar almacenamiento en memoria caché, filtración, concentración de recursos, y planificación. Una ventaja primaria de esta arquitectura de agente -adaptador es su capacidad para hospedar lógicos de negocios complejos, con el objeto de mantener el estado y negociar transacciones con los recursos de aplicación 300. Se puede pensar de esta habilidad como "procesamiento de modo conversacional", que es particularmente crítico cuando se integran los recursos de aplicación 300 de una naturaleza transaccional . Más frecuentemente que lo contrario, los elementos de datos que se pueden requerir para el corretaje de mensajes desde esos recursos de aplicación 300, estén profundamente anidados adentro de las subtransacciones . Estos elementos de datos profundamente anidados se pueden obtener, por lo tanto, solamente por medio de participar en una conversación con el recurso de aplicación transaccional 300. Otros adaptadores "primitivos" que se han usado en el pasado, no dirigen adecuadamente el complejo comportamiento de los recursos de aplicación transaccionales 300.

Como se muestra en la Figura 4 (a) , un agente-adaptador 200 inteligente típico, de conformidad con la presente invención, incluye un componente de agente 210 y un componente de adaptador 220. En un lado de esta arquitectura, el agente 210 se conforma a un evento especificado y modelo de mensajería del sistema 100. El adaptador 220, en el otro lado de esta arquitectura de agente -adaptador, usa una interfase de programación de aplicación (API) nativa 510 de un recurso de aplicación particular 300, u otro mecanismo de interfase adecuadamente publicado. Juntos, el agente 210 y el adaptador 220 reconcilian las diferencias en los protocolos de interfase y las estructuras de datos para proporcionar una vista uniforme, normalizada de los eventos de negocios que ellos publican y consumen. A diferencia de los planteamientos del pasado al EAI , la arquitectura anterior de agente -adaptador es extensible. Esto no sólo facilita una habilidad para acomodar limpiamente cambios a las APIs existentes, sino que ésto también continúa habilitando el uso de esas APIs existentes con sistemas heredados. Como se muestra más claramente en la Figura 4(b), esta arquitectura de agente-adaptador extensible generalmente comprende un agente 210 que encapsula un primer adaptador A' 222 y un segundo adaptador A'' 224. El adaptador A' 222, por ejemplo, corresponde con un recurso de aplicación 300 que tiene un conjunto básico de APIs A' . Por otra parte, el adaptador A'' 224 corresponde con el mismo recurso de aplicación 300 que tiene un conjunto más nuevo de APIs A' ' . Los usuarios de esa arquitectura de agente-adaptador extensible pueden elegir, mediante lo mismo, adaptarse simultáneamente a ambas interfases A' y A' ' . Por ejemplo, el conjunto básico de APIs A' puede corresponder con un medio ambiente de producción, mientras que el conjunto más nuevo de APIs A' ' puede corresponder a un medio ambiente de producción previa de una versión más nueva de un recurso de aplicación 300 particular. El conjunto más nuevo de APIs A' ' se puede, así, probar "vivo" adentro del sistema 100, al mismo tiempo que el conjunto básico de APIs A' se usará para mantener la funcionalidad previamente probada y comprobada. De esa manera, esta arquitectura de agente-adaptador extensible habilita la negociación perfectamente limpia de cambios increméntales al recurso de aplicación 300 dentro del medio ambiente de integración. Refiriéndonos ahora a la Figura 4(c) , allí se muestra una vista muy agrandada de un agente-adaptador 200, de conformidad con una modalidad actualmente preferida de la invención. Al igual que los agentes-adaptadores que se muestran en las Figuras 4(a) y 4(b), el agente-adaptador 200 que se muestra en la Figura 4 (c) se usa para comunicarse entre el sistema 100 y la API nativa 510 de una aplicación de empresa (no se muestra) . El agente-adaptador 200 de conformidad con esta modalidad, sin embargo, incluye tres adaptadores 222, 224, y 226. Como se describe con mayor detalle posteriormente en la presente, el adaptador 222 es de la variedad de adaptador de fuente, el adaptador 224 es de la variedad de adaptador de objetivo, y el adaptador 226 es de la variedad de adaptador de respuesta. Para uno de experiencia ordinaria en la técnica puede ser fácilmente entendible, por lo tanto, que el agente-adaptador 200 de conformidad con esta modalidad de la presente invención, no está limitado a ningún número dado de adaptadores dirigidos específicamente que pueda encapsular el agente 210.

Por ejemplo, se puede usar el adaptador de solicitud 228 (no se muestra en la Figura 4 (c) ) del tipo que se describe con mayor detalle posteriormente en la presente, en conjunción con, o en sustitución de esos adaptadores 222, 224, ó 226, como se muestra. Por otra parte, de conformidad con otro aspecto particularmente importante de la presente invención, el agente 210 comprende una pluralidad de objetos 230-240 útiles para extender las habilidades del agente-adaptador 200. Por ejemplo, el objeto 230 comprende actualmente un objeto de transformación, el cual facilita el funcionamiento de las funciones de otra manera centralizadas del sistema 100, localmente adentro del agente-adaptador 200 mismo. El objeto 231 igualmente comprende un objeto de administración de errores, el objeto 232, un objeto de administración de conexiones, y el objeto 234, un objeto de administración de reglas. La extensibilidad adicional del agente-adaptador 200 solamente está limitada por el número de objetos adicionales 235-240 que pueden estar colocalizados con el agente 210. El anterior es un aspecto particularmente importante de la presente invención, puesto que éste facilita la descentralización de los aspectos del manejo de mensajes del sistema 100. Por lo tanto se asegura la integración de aplicaciones de empresa distribuida, puesto que el agente- adaptador 200 de conformidad con esta modalidad de la presente invención se puede asociar con cualquier nodo a través del sistema 100. La manera en la que el sistema 100 comparte los datos entre las aplicaciones de la empresa se determina mediante los flujos de integración, como se describirá con mayor detalle posteriormente en la presente. Los flujos de integración típicos usan uno o más mensajes del sistema. Cada uno de los mensajes del sistema generalmente comprende una comunicación, en un formato de plataforma-neutro, que mueve datos seleccionados de una aplicación de software a otra aplicación de software. Los flujos de integración, a su vez, están conformados de una pluralidad de objetos y enlaces entre esos objetos. Cada uno de los objetos realiza una tarea específica con relación a los mensajes del sistema que llevan los datos de aplicación de la empresa a aplicación de la empresa. ·· ,·: *v * 1 Por ejemplo, y refiriéndonos ahora a las Figuras 5(a) a 5(c), un objeto en un flujo de integración 540 comprende ya sea un objeto de definición 510 ó un objeto de integración 530. Existen tres tipos básicos de objetos de definición 510, que se pueden usar de conformidad con la presente invención: (1) una definición de mensaje 512; (2) una definición de transformador 514; y (3) una definición de filtro 516. Los objetos de definición 510 se pueden usar repetidamente en cualquier flujo de integración 540 dado. Por ejemplo, se debe asignar la misma definición de mensaje 512 a todos los objetos 510, 530 que manejarán los mensajes del sistema producidos usando esa definición de mensaje 512. Por otra parte, se puede usar la misma definición de filtro 516 en múltiples secciones de un flujo de integración 540. El objeto de definición de mensaje 512 identifica los datos que el sistema 100 va a extraer de, o propagar a una aplicación de empresa 541, 549. Este también define cómo el sistema 100 no solamente construirá mensajes del sistema a partir de datos de la aplicación de empresa, sino que también creará datos de aplicación de empresa a partir de los mensajes del sistema. Los objetos de definición de transformador 514 definen cómo el sistema 100 transformará los mensajes de sistema extraídos de una o más aplicaciones de empresa a mensajes de sistema que necesitan otras aplicaciones de empresa . Un objeto de definición de filtro 516 define los criterios que usará el sistema 100 para filtrar mensajes de sistema no deseados fuera de los flujos de integración. En un flujo de integración que transforma nuevos datos del cliente a facturas, por ejemplo, un objeto de definición de filtro 516 que pudiera ser útil sería uno en el que se filtraran fuera los mensajes de sistema acerca de clientes que ya hayan pagado. Los objetos de integración 530, de los cuales hay tres tipos básicos, envían o reciben de hecho mensajes de sistema. Los tres tipos básicos de objetos de integración 530 son: (a) un adaptador 220; (2) un núcleo de mensajes 518; y (3) un transformador 520. Además, y como se notó brevemente anteriormente en la presente, existen cuatro tipos básicos de adaptadores 220; (a) adaptadores de fuente 222; (b) adaptadores de objetivo 224; (c) adaptadores de respuesta 226; y (d) adaptadores de solicitud 228. Un adaptador de fuente 222 extrae los datos de una aplicación de empresa de fuente, construye mensajes de sistema a partir de esos datos, y envía esos mensajes de sistema a otros objetos de integración 530 (por ejemplo, el núcleo de mensajes 518) . Un adaptador de objetivo recibe mensaje de sistema desde otros objetos de integración 530 (por ejemplo, el transformador 520 a través del objeto de definición de filtro 516) , crea datos de aplicación a partir de esos mensajes de sistema, y propaga esos datos a una aplicación de empresa objetivo. Un adaptador de respuesta 226 responde a las solicitudes por datos de algunos otros objetos de integración 530, mediante la extracción de los datos desde las aplicaciones, y entonces enviándolos al objeto de solicitud 530. En general, los núcleos de mensajes 518 se usan para recibir mensajes de sistema de uno o más objetos de integración de fuente 530 , y para contener esos mensajes de sistema hasta que el sistema 100 pueda enviar los mismos a uno o más objetos de integración objetivo 530. Los transformadores 520 generalmente se usan para implementar definiciones del transformador en tres pasos. Estos primero reúnen los mensajes de sistema de los objetos de integración de fuente 530 (por ejemplo, el núcleo de mensajes 518) . Después del paso de reunión, éstos transforman después el contenido y el formato de los datos contenidos adentro de esos mensajes de sistema. Estos finalmente producen y envían mensajes de sistema de salida a los objetos de integración objetivo 530 (por ejemplo, el adaptador de objetivo 224) . Las definiciones de mensaje 512 son los objetos primarios alrededor de los cuales se construye el flujo de integración 540, de conformidad con la presente invención. Cuando un usuario crea un flujo de integración, se asigna una definición de mensaje a todo objeto 510, 530 en ese flujo. Una definición de mensaje 512 no solamente identifica la clase de mensaje de sistema que va a manejar el objeto 510, 530, sino que ésta también define la estructura jerárquica o esquema de ese mensaje de sistema. Por ejemplo, se debe asignar una definición de mensaje 512 a todo adaptador de fuente 222 en el flujo de integración 540 del usuario. Cada adaptador de fuente 222 conoce qué clase de mensaje se va a producir, en base a la definición de mensaje 512 que el usuario le ha asignado. Los adaptadores 220, los núcleos 518, y los filtros 516 manejan únicamente una definición de mensaje 512. Las definiciones de transformador 514 y los transformadores 520, por otra parte, son capaces de manejar múltiples definiciones de mensaje 512, como entradas y salidas. Algunas aplicaciones pueden crear los tipos de datos de Java especificados en su definición de mensaje 512, y almacenarlos directamente en un mensaje de sistema. De la misma manera, un adaptador de objetivo 224 puede recuperar los tipos de datos a partir de un mensaje de sistema, e insertarlos directamente dentro de la aplicación (por ejemplo, una aplicación de empresa objetivo 549) . Otras aplicaciones usan un formato de mensaje bien definido para describir la disposición de sus datos nativos. En esos casos, la definición de mensaje 512 para un adaptador de fuente 222 debe incluir instrucciones para crear tipos de datos de Java a partir de los datos de aplicación. De manera similar, la definición de mensaje 512 para un adaptador de objetivo 224, debe incluir instrucciones para crear datos de aplicación a partir de objetos de Java del sistema . Los objetos de integración 530 usan una clase especial de definición de mensaje 512 para solicitar datos de los otros objetos del sistema 510, 530. Por ejemplo, las definiciones de mensaje 512 también pueden especificar los criterios de validación de mensajes. El sistema 100 usa estos criterios para determinar si los mensajes de sistema producidos por los adaptadores 220 y los transformadores 520 contienen datos válidos (por ejemplo, en donde el usuario incluye una definición de mensaje 512 que define los mensajes, que contiene información de nómina de pago de los empleados) . El usuario, de conformidad con lo anterior, puede evitar que entren datos sobre salarios inexactos al sistema 100. Si la definición de mensaje 512 contiene un elemento de tema "Salario", por ejemplo, el usuario puede entonces definir los criterios de validación para el tema, declarando que el mensaje únicamente es válido cuando el valor en "Salario" es un número positivo. El usuario puede organizar definiciones de mensaje 512 relacionadas, en grupos lógicos llamados categorías de mensaje. Suponga, por ejemplo, que el usuario está integrando tres aplicaciones usando el sistema 100. El usuario puede agrupar los mensajes en el proyecto del usuario en tres categorías de mensaje, una para cada aplicación. En esta coyuntura se debe notar que el esquema de mensaje 600 particular de una definición de mensaje 512 está conformado de objetos de datos, llamados elementos de mensaje, que están configurados en una estructura jerárquica, como se muestra en la Figura 6. En general, un esquema de mensaje 600 comprende una o más secciones 620, una o más tablas 640, y uno o más temas 660. Ya sea una sección 620 o una tabla 640 debe aparecer en la parte superior de la jerarquía de mensajes 600. Una sección 620 es un grupo no repetidor de elementos de mensaje. Esos elementos de sección no contienen ellos mismos datos reales. Más bien, éstos contienen otros elementos de mensaje que contienen datos (es decir, éstos contienen los temas 660). Las secciones 620 pueden contener cualquier combinación de tipos de elementos de mensaje. Una tabla 640 es un grupo de elementos de sección, llamados filas, que se pueden repetir cualquier número de veces. Los elementos de tabla tampoco contienen datos reales. Estos contienen otros elementos de mensaje que contienen datos (es decir, éstos contienen temas) . Las tablas 640 pueden contener cualquier combinación de tipos de elementos de mensaj e . Un tema 660 es un elemento de mensaje que contiene datos. Los temas 660 son los elementos de mensaje de nivel más bajo en la jerarquía de la definición de mensaje. Estos no pueden contener otros elementos de mensaje. Cada definición de mensaje 512 puede contener criterios para validar mensajes, en base a esa definición. Esto es, cuando el usuario define una definición de mensaje, el usuario puede especificar los criterios que deben satisfacer los datos en los elementos de mensaje individuales para que un mensaje se considere válido adentro del sistema 100. El usuario puede especificar los criterios de validación para todos los niveles de un mensaje. Esto es, el usuario puede especificar los criterios para los temas del mensaje adentro de secciones o adentro de tablas. El mensaje completo ya sea pasa los criterios de validación y continúa a través del flujo, o no pasa y se desecha. Si hasta una fila de una tabla no pasa los criterios especificados, no pasa todo el mensaje. El sistema 100 valida todo mensaje producido por un adaptador 220 o transformador 520, usando los criterios de validación en la definición de mensaje apropiada. Los adaptadores 220 se conectan con las aplicaciones de empresa para extraer o propagar datos. Cada adaptador 220 produce, recibe, o responde a los mensajes, usando la definición de mensaje 512 que el usuario le asigna a éste. El sistema 100 proporciona adaptadores 220 estándares para las aplicaciones que éste integrará. Cada adaptador 220 estándar, como se notó anteriormente, es un adaptador de fuente 222, un adaptador de objetivo 224, un adaptador de respuesta 226, o un adaptador de solicitud 228, y está diseñado para un tipo de servicio de agente específico. Por ejemplo, para el EntireX Broker, el sistema ofrece un Adaptador de fuente Estándar ETB y un Adaptador de Objetivo Estándar ETB. Los adaptadores estándares son genéricos. Estos proporcionan manejo de excepción básico y pueden manejar cualquier definición de mensaje. Si un adaptador estándar 220 no incluye todos los códigos que necesita el usuario para interactuar con una aplicación (por ejemplo, el usuario desea especificar un manejo de excepción más detallado) , el usuario puede crear un adaptador 220 personalizado usando el ADK 130. El usuario también puede usar el ADK 130 para crear los adaptadores 220 personalizados para aplicaciones que el sistema 100 no esté soportando en ese momento. De la misma manera, el usuario puede usar el ADK 130 para crear adaptadores 220 personalizados que se conecten a cualquier aplicación con una interfase de programación de aplicación (API) de Java. Para usar un adaptador 220 estándar o personalizado en un flujo de integración 540, el usuario debe configurarlo para manejar una definición de mensaje 512 específica. El usuario puede configurar tantos como sean necesarios de cada tipo de adaptadores 220 para manejar todos los mensajes que el usuario necesite incluir en los flujos de integración 540. Los adaptadores de fuente 222 extraen datos de las aplicaciones de empresa, y producen mensajes que envían a otros objetos de integración 530. Específicamente, un adaptador de fuente 222: (1) encuesta o se le notifica mediante su aplicación de un tipo particular de evento que ha ocurrido en la aplicación (por ejemplo, se han introducido datos sobre un nuevo cliente) ; (2) extrae los datos relacionados con el evento, a partir de la aplicación; (3) usando las instrucciones de la definición de mensaje, construye un mensaje de sistema a partir de los datos; y (4) produce un mensaje y lo envía a uno o más objetos de integración 530 objetivo. Los adaptadores de objetivo 224 reciben mensajes desde otros objetos del sistema 510, 530 en los flujos de integración 540, y propagan los datos del mensaje a las aplicaciones de empresa 541, 549. Específicamente, un adaptador de objetivo 224: (1) recibe mensajes de sistema desde uno o más objetos de integración 530 de fuente; (2) usando las instrucciones de la definición de mensaje 512, crea datos de aplicación a partir del mensaje de sistema; y (3) propaga los datos a la aplicación objetivo 549 por medio de insertar datos nuevos, actualizar datos, o suprimir datos según sea apropiado. Los adaptadores de respuesta 226 extraen datos de las aplicaciones de empresa 541, 549 cuando lo solicitan los objetos de integración 530, tales como los transformadores 520. Específicamente, un adaptador de respuesta 226: (1) recibe un mensaje de solicitud desde un objeto de integración 530; (2) extrae los datos solicitados de su aplicación de empresa 541, 549; y (3) envía los datos al transformador 520 en un mensaje de respuesta, en base a la misma definición de mensaje 512 como el mensaje de solicitud. Los adaptadores de solicitud 228, en conjunción con los tranformadores 522 de respuesta, se usan para extraer datos a partir de las aplicaciones de empresa 541, 549, sin solicitudes específicas de esas aplicaciones. Como se muestra en la Figura 7, éstos recuperan la información que ellos anticipan que pudiera necesitar un objeto de aplicación 710 haciendo otra solicitud. Por ejemplo, la solicitud del objeto de aplicación 710 puede ser tan simple como "Deseo ver los datos de embarque del cliente" . Todos los datos que comprenden esos datos de embarque del cliente se extraen con anticipación, se ponen en la misma definición de mensaje de la solicitud, y se "empujan" al objeto de aplicación 710. Específicamente, un adaptador de solicitud 228: (1) recibe un mensaje de solicitud desde un objeto de aplicación 710; (2) extrae los datos anticipados ya sea directamente desde otro objeto 540 en el sistema 100, o con la ayuda de un transformador de respuesta 522, a través del transformador de respuesta 522; y (3) envía los datos al objeto de aplicación 710 en un mensaje basado en la misma definición de mensaje 512 como el mensaje de solicitud . Los servicios de agente hospedan a los adaptadores 220, como se describe con mayor detalle posteriormente en la presente. Los servicios de agente proporcionan los adaptadores de información 220 necesarios para conectarse a sus aplicaciones (por ejemplo, palabras clave e IDs del usuario) . El sistema 100 ofrece servicios de agente para toda aplicación de empresa que éste pueda integrar. Esto es, éste ofrece un servicio de agente SAP R/3, un servicio de agente EntireX Broker, etcétera. El sistema 100 también ofrece servicios de agente para adaptadores personalizados que crea el usuario usando el ADK 130. El usuario necesita un servicio de agente para cada aplicación de empresa que desee integrar el usuario usando el sistema 100. Por ejemplo, si el usuario desea integrar tres sistemas SAP R/3 con un RDBMS, el usuario necesita tres servicios de agente SAP R/3 y un servicio de agente RDBMS. Cada servicio de agente hospeda a todos los adaptadores 220 para la aplicación de empresa a la cual se conecta el agente. Las definiciones de transformador 514 definen un proceso que transforma los mensajes que contienen los datos extraídos desde una o más aplicaciones, a mensajes que contienen los datos que necesitan una o más aplicaciones. Los transformadores 520 implementan definiciones de transformador 514 por medio de reunir los mensajes de entrada de los objetos de fuente, transformar los datos, y enviar mensajes de salida a los objetos objetivo. Los procesos de transformación definidos en una definición de transformador 514 siempre envuelven cuando menos dos clases de mensajes: el mensaje de entrada primario, y uno o más mensajes de salida, como se muestra en la Figura 8. El mensaje de entrada primario típicamente contiene la mayoría o todos los datos que el usuario desea enviar en los mensajes de salida a las aplicaciones objetivo. Los mensajes de salida contienen datos de los mensajes de entrada, transformados según sea necesario para aplicaciones objetivo. Cuando el usuario crea una definición de transformador 514, el usuario primero especifica en 805 el nombre del mensaje de entrada primario. Entonces, en 810, el usuario identifica la definición de mensaje 512 que define los mensajes que el usuario desea usar como la entrada primaria. Entonces, en 815 se especifican cualesquier mensajes de entrada de soporte. Después, el usuario identifica, en 820, las definiciones de mensaje 512 que definen esos mensajes de entrada de soporte. Un solo proceso de transformación puede producir cualquier número de salidas. De conformidad con lo anterior, el usuario debe especificar esos mensajes de salida en 825, e identificar las definiciones de mensaje 512 que definan los mensajes que el usuario desea producir como salidas . El usuario entonces crea, empezando en 835, una secuencia de pasos 840, 845, 850, 855, 860, 865 que definen cuándo leer los datos de entrada, cómo transformar los datos de entrada, cómo mapear los datos de entrada a partir de las definiciones de mensaje de entrada hasta las definiciones de mensaje de salida, y cuándo escribir los datos transformados a los mensajes de salida reales. El usuario transforma los datos de entrada de cualquier manera necesaria para crear los mensajes de salida que necesita el usuario. Por ejemplo, el usuario puede crear una expresión de transformación que especifique el encadenamiento de un tema de mensaje que contiene el nombre del cliente y un tema de mensaje que contiene el apellido del cliente, porque una aplicación objetivo requiere el nombre completo del cliente en un campo de datos. El usuario crea una expresión de transformación que especifica la selección de únicamente ciertos caracteres de un tema de mensaje, o rellenar un tema de mensaje con espacios para hacerlo de la longitud correcta para el campo de datos correspondiente en la aplicación objetivo. El usuario produce entonces diferentes mensajes de salida por medio de escribirlos en diferentes puntos en el proceso de transformación. Cuando el mensaje de entrada primario no contiene todos los datos necesarios para producir los mensajes de salida, el usuario puede obtener entrada de soporte para el proceso de transformación, usando definiciones de mensaje de solicitud/respuesta. Por ejemplo, suponga que el mensaje de entrada primario que está usando el usuario en la definición de transformador usa abreviaturas para los nombres de los estados de Estados Unidos (por ejemplo, VA para Virginia) . Suponga, por ejemplo, que la aplicación objetivo requiere los nombres completos de los estados. Para obtener los nombres completos de los estados necesarios para producir los mensajes de salida, el usuario usaría una definición de mensaje de solicitud/respuesta que puede enviar las abreviaturas a una aplicación, y recibir los nombres de los estados de regreso. Después de que el usuario ha creado una definición de transformador 514, el usuario puede probarla para asegurarse de que ésta produce los mensajes de salida apropiados, antes de usarla en un flujo de integración. El usuario entonces puede asignar la definición de transformador a uno o más transformadores 520. Un transformador 520 implementa una definición de transformador 514. Cuando el usuario crea un transformador 520, el usuario especifica los objetos 510, 530 para usarse como las fuentes del mensaje de entrada primario y los objetos 510, 530 que serán objetivos para los mensajes de salida. El usuario también especifica los objetos que van a responder a las solicitudes de entradas de soporte. Cuando el transformador 520 recibe un mensaje de entrada primario de un objeto de fuente 540, éste ejecuta la secuencia de pasos definida en la definición de transformador 514, que conforma el proceso de transformación. Este puede leer los mensajes de entrada primario y de soporte, transforma los datos de entrada, escribe los datos transformados en uno o más mensajes de salida, y envía los mensajes de salida a los objetos objetivo 540. En la Figura 9 se muestra un proceso de transformación típico. El transformador 520 recibe un mensaje de entrada primario 920 desde un núcleo 518. Este obtiene entonces un mensaje de entrada de soporte 940 de un adaptador de respuesta 226. Finalmente, el transformador 520 envía dos mensajes de salida 960, 980 diferentes a dos adaptadores de objetivo 224 diferentes . Los núcleos 518 son áreas contenedoras de mensajes para los adaptadores 220 y los transformadores 520. Los núcleos 518 permiten que los adaptadores 220 y los transformadores 520 intercambien mensajes de manera asincrónica, y simplifican los enlaces entre los objetos. Por ejemplo, el usuario puede tener un adaptador de fuente 222 que produzca mensaje para un transformador 520. El usuario puede desear que el adaptador 222 produzca y envíe estos mensajes, sin importar si el transformador 520 está listo para recibirlos. El usuario puede establecer el adaptador 222 para enviar sus mensajes a un núcleo de mensajes 518, y establecer el transformador 520 para recibir los mensajes del adaptador desde ese núcleo 518. El sistema 100 envía entonces los mensajes desde el núcleo 518 al objeto objetivo 540 cuando el objetivo está listo para recibirlos .

Además, el usuario puede tener tres adaptadores de fuente 222 que envíen mensajes en base a la misma definición de mensaje 512 a cinco objetivos 224, 520. Si el usuario no usara un núcleo 518 (como se muestra en la Figura 10 (a) ) , el usuario tendría que crear un total de 15 enlaces entre esos objetos. Por otra parte, si el usuario usa un núcleo 518 (como se muestra en la Figura 10 (b) ) , el usuario tendría que crear y mantener únicamente ocho enlaces. Los núcleos de mensajes 518 pueden contener una clase de mensaje solamente (es decir, mensajes producidos a partir de una sola definición de mensaje 512) . Los objetivos de los núcleos 518 tienen suscripciones durables. El sistema 100 mantiene el recorrido de los mensajes que ha recibido cada objeto objetivo 224, 520 desde el núcleo 518, así como aquellos que no hayan recibido todavía los objetos objetivo 224, 520. Si un objeto objetivo 224, 520 se vuelve inactivo, el sistema 100 recuerda el último mensaje que ha recibido el objeto objetivo 224, 520. Cuando ese objeto objetivo 224, 520 se vuelve activo después, el sistema 100 envía solamente aquellos mensajes que el objeto objetivo 224, 520 todavía no haya recibido. Si las suscripciones de núcleo no fueran e de otra manera durables, los objetos objetivo 224, 520 recibirían los mensajes que llegaran a los núcleos 518, mientras los objetos objetivo 224, 520 estuvieran activos, pero nunca recibirían los mensajes que llegaran a los núcleos 518 cuando los objetos objetivo 224, 520 no estuvieran activos.

El usuario puede elegir a partir de dos estilos de mensajería que el usuario quiere que use el sistema 100 cuando envía mensajes desde el núcleo 518: (1) de punto-a-punto, en donde el sistema 100 envía cada mensaje al primer objetivo disponible solamente; ó (2) de publicar/suscribir, en donde el sistema 100 envía cada mensaje a cada objeto que el usuario haya identificado como un objetivo del núcleo 518. Si el usuario desea clasificar una cierta clase de datos fuera de una parte de un flujo de integración 540, el usuario debe usar una definición de filtro 516. Las definiciones de filtro 516 especifican criterios basados en los datos del mensaje (es decir, los datos que pasan los criterios continúan a través del flujo) , mientras que se desechan los datos que no pasan los criterios. Cuando el usuario desea filtrar una cierta clase de mensaje, el usuario crea una definición de filtro 516, y la asigna a uno o más enlaces entre los objetos 540 que manejan esa clase de mensaje. El sistema 100 aplica los criterios en la definición de filtro 516 a todos los mensajes enviados a lo largo de esos enlaces. Por ejemplo, considere la situación en la que un núcleo 520 envía mensajes que contienen datos sobre nuevos clientes a un adaptador de objetivo 224. El usuario pudiera desear únicamente datos sobre clientes que todavía no hayan pagado para llegar al adaptador de objetivo 224. Con el objeto de hacer eso, el usuario crearía una definición de filtro 516, que especifique el criterio "Estado = Pagado", y la asigna al enlace entre el núcleo 518 y el adaptador de objetivo 224. El usuario puede crear una o más definiciones de filtro 516 para cada definición de mensaje 512 en el flujo de integración 540 del usuario. El usuario puede asignar una sola definición de filtro 516 a múltiples enlaces, o el usuario puede asignar diferentes definiciones de filtro 516 para la misma clase de mensaje a diferentes enlaces. Por ejemplo, considere la situación en la que un núcleo 518 envía mensajes que contiene datos sobre clientes nuevos a dos adaptadores 220. El usuario podría querer que un adaptador 220 recibiera solamente los datos sobre los clientes que han pagado, y que el otro adaptador 220 recibiera solamente los datos sobre los clientes que todavía no han pagado. El usuario, por lo tanto, crearía dos definiciones de filtro 516. Uno especifica el criterio "Estado = No pagado", y el otro especifica el criterio "Estado = Pagado" . El usuario entonces asignaría cada definición de filtro 516 al enlace apropiado. Cuando el usuario crea una definición de filtro 516 para mensajes que no contienen tablas de datos, los criterios que especifica el usuario afectan a todo el mensaje. Todo el mensaje ya sea pasa los criterios del filtro y continúa a través del flujo, o no pasa y se desecha. Cuando el usuario crea una definición de filtro 516 para mensajes que contienen tablas de datos, el usuario puede especificar criterios que afecten a todo el mensaje, o que afecten solamente a los datos adentro de una tabla. Si el usuario especifica criterios para temas de mensaje en una sección 620, todo el mensaje ya sea pasa los criterios y continúa a través del flujo, o no pasa y se desecha. Si el usuario especifica criterios para temas de mensaje en una tabla 640, el mensaje continúa a través del flujo con solamente esas filas de datos que pasan los criterios. Las filas que no pasen los criterios se desechan. Por ejemplo, considere la situación en la que un mensaje contiene una tabla 640 con nueve filas de datos, una por cada uno de nueve clientes nuevos. Si el usuario establece una definición de filtro 516 que filtre fuera a los clientes que gastaron $1000 o menos, las filas que contengan datos sobre clientes que gastaron más de $1000 continuarían a través del flujo, mientras que las filas que contengan datos sobre clientes que gastaron $1000 o menos, se desecharían. Después de que el usuario ha creado una definición de filtro 516, el usuario puede probarla para asegurarse de que ésta trabaja apropiadamente, antes de usarla en un flujo de integración 540. Una vez que existen los objetos del sistema que el usuario desea usar en un flujo de integración 540, el usuario puede indicar cómo desea el usuario que el sistema 100 encamine los mensajes entre ellos. Para hacer eso, el usuario establece enlaces entre los objetos de integración 530. Cada enlace establece un objeto como una fuente y el otro como un objetivo, o un objeto como un solicitante y el otro como un contestador. Los adaptadores de fuente siempre son fuentes de mensajes. Estos pueden enviar mensajes a los adaptadores de objetivo del mismo tipo de servicio de agente (por ejemplo, un adaptador de fuente SAP R/3 puede enviar mensajes a un adaptador de objetivo SAP R/3), a núcleos de mensajes 518, y a transformadores 520. Los transformadores 520 pueden ser objetivos, solicitantes, y fuentes. Estos pueden recibir mensajes de entrada primarios 920 de los adaptadores de fuente 222, núcleos de mensajes 518, y otros transformadores 520. Estos también pueden solicitar mensajes de entrada de soporte 940 de los adaptadores de respuesta 226 y los núcleos de mensajes 518, y enviar mensajes de salida 960, 980 a adaptadores de objetivo 224, núcleos 518, y otros transformadores 520. Los núcleos de mensajes 518 pueden ser objetivos y fuentes. Los adaptadores de objetivo 224 siempre son objetivos. Estos pueden recibir mensajes desde los adaptadores de fuente 222 del mismo tipo de servicio de agente, desde los núcleos 518, y desde los transformadores 520. Por omisión, el sistema 100 usa la "persistencia del mensaje" . Esto es, éste escribe cada mensaje que envía desde un objeto de integración 530 a otro para almacenamiento estable en una ubicación que especifique el usuario. Si ocurre una falla del sistema mientras el mensaje está en tránsito, el sistema 100 puede recuperar el mensaje del almacenamiento cuando se restablece el sistema, y enviar el mensaje a sus objetivos. Debido a que la persistencia del mensaje incrementa la carga general del sistema, el sistema 100 permite que el usuario apague la persistencia para cualquier objeto de integración 530. Sin embargo, si ocurre una falla del sistema mientras los mensajes a, o desde ese objeto, están en tránsito, se pudieran perder esos mensajes. El sistema 100 ofrece otras opciones relacionadas con el envío que le ayudan al usuario a administrar los recursos del sistema del usuario. El sistema 100 mantiene áreas de contención de mensajes para cada objeto de integración en un flujo de integración. El usuario también puede controlar el tamaño de estas áreas de contención. El usuario puede limitar el número de mensajes que contiene el sistema 100 para cada objeto en un momento, y el usuario puede limitar la longitud de tiempo que el sistema 100 contiene cada mensaje. Si un objeto de integración 530 produce mensajes más rápidamente de lo que los pueden recibir sus objetivos, estos límites pueden evitar que el área de contención del objeto crezca a un tamaño que estire los recursos del sistema. El usuario diseña todos los flujos de integración adentro de un proyecto en la mesa de trabajo 120. Esos flujos de integración que el usuario diseña y salva (es decir, la definición 530 y los objetos de integración 530 que crea el usuario, y los enlaces entre ellos) se almacenan todos en el depositario 140. El proyecto es una estructura lógica que le deja ver al usuario el depositario 140. Cada instalación del sistema 100 tiene un proyecto y un depositario 140. Ahora se describirán la estructura general y la filosofía del diseño del objeto de mensaje que usan todos los productores de mensajes en el sistema 100. El modelo de mensaje, como se describe en la presente, es infinitamente extensible y útil para convertir a, y desde formatos de archivo nativos, así como para enviar mensajes internos de nodo a nodo en el sistema 100. El mensaje es jerárquico en naturaleza, y usa un paradigma de par de nombre/valor para representar los datos. Los datos representados mediante el modelo de mensaje, de conformidad con la presente invención, siempre se basa en el objeto. Esto es un ejemplo de un objeto de Java de una cierta clase. Cada nodo de datos es seguro por su tipo, en el sentido de que éste pudiera contener únicamente los datos que son de la clase especificada. La estructura de un mensaje se activa por metadatos . Esto es, los mensajes bien construidos siempre se construyen usando el esquema exhibido en un objeto conocido como la definición de mensaje 512. Todo mensaje de un cierto "tipo" se construye a partir de la misma definición de mensaje 512. La definición de mensaje 512 es ella misma una instancia de un mensaje, aunque sus nodos se han extendido para contener información sobre cómo construir instancias del formato que describe ésta, así como información adicional acerca de cómo convertir los datos a y desde un formato de archivo de aplicación nativo. Como se notó brevemente anteriormente en la presente, un mensaje 600 es una colección estructurada como árbol de objetos simples y compuestos. Todos los objetos que pueden aparecer en un mensaje son tipos diferentes de "entradas del mensaje". En una modalidad actualmente preferida de la invención, una entrada del mensaje comprende uno de los siguientes tipos: (1) un elemento de datos; (2) un elemento de configuración; (3) un elemento de tabla; y (4) un elemento de sección o "enlace de mensaje". El mensaje siempre tiene un solo elemento de sección en la parte superior del árbol, conocida como la "sección de nivel superior" . Esta y otras secciones pueden contener instancias de cualquiera de los cuatro tipos de elemento . Un elemento de datos contiene datos "atómicos", aunque los datos están envueltos en una clase de Java. Por ejemplo, los datos enteros se almacenan en un objeto j ava . lang . Integer, la información de fecha/hora se encapsula en un objeto j ava . útil . Calendar, etcétera. Un elemento de configuración es una colección de uno o más elementos primitivos . La longitud de una configuración se especifica en los metadatos, aunque esta longitud se puede especificar como un rango admisible, en cuyo caso la longitud se determina mediante el análisis sintáctico de un registro de archivo de la aplicación nativa. Un elemento de tabla es de hecho una colección isomórfica de elementos de sección, lo que significa que cada "fila" de la tabla es una sección que contiene exactamente la misma combinación de nombres y tipos. Este también tiene una especificación de rango potencialmente variable. Un enlace de mensaje es un apuntador a otra definición de mensaje persistente en el sistema, y se usa para combinar formatos. Esto es útil para implementar "redefiniciones". El mensaje puede representar datos opcionales, así como valores por omisión, según lo dicte la definición de mensaje. En su uso más simple, uno crea un mensaje genérico vacío por medio de invocar un método de fábrica estático en la clase de definición de mensaje. Esto crea un mensaje con todos los pares de nombre/valor apropiados, pero cada tema de los datos se establece a nulo. El único constructor de mensaje públicamente exportado requiere una definición de mensaje como un parámetro, asegurando una forma apropiada. La API del mensaje proporciona una manera para accesar sus elementos, ya sea mediante búsqueda nombrada o a través de repetidores de sección. En esta coyuntura se debe notar que el mensaje soporta un esquema de nombramiento jerárquico, usando un separador configurable, permitiendo que el "nombre de trayectoria" completo o relativo accese a cualquier componente en la j erarquía . Una sección 620 es un grupo no repetidor de elementos de mensaje. Esos elementos de sección no contienen ellos mismos datos reales. Más bien, éstos contienen otros elementos de mensaje que contienen datos (es decir, éstos contienen temas 660) . Las secciones 620 pueden contener cualquier combinación de tipos de elementos de mensaje. Una tabla 640 es un grupo de elementos de sección, llamados filas, que se pueden repetir cualquier número de veces. Los elementos de tabla tampoco contienen datos reales. Estos contienen otros elementos de mensaje que contienen datos (es decir, éstos contienen temas) . Las tablas 640 pueden contener cualquier combinación de tipos de elementos de mensaj e . Un tema 660 es un elemento de mensaje que contiene datos. Los temas 660 son los elementos de mensaje de nivel más bajo en la jerarquía de la definición de mensaje. Estos no pueden contener otros elementos de mensaje. El usuario diseña todos los flujos de integración 540 dentro de un proyecto en la mesa de trabajo 120. Esos flujos de integración 540 que diseña y salva el usuario (es decir, la definición 610 y los objetos de integración 620 que crea el usuario, y los enlaces entre ellos) se almacenan, todos ellos, en el depositario 140. El proyecto es una estructura lógica que deja al usuario ver el depositario 140. Cada instalación del sistema 100 tiene un proyecto y un depositario 140. De conformidad con otro aspecto importante de la presente invención, el sistema 100 comprende un sistema distribuido. Esto es, el usuario puede ejecutar los componentes del sistema que conforman el sistema 100 en una o más máquinas físicas (es decir, anfitriones) , pero todos los componentes trabajando juntos como una aplicación. Un nodo es un proceso físico que se ejecuta en un anfitrión y soporta uno o más servicios. Cada nodo es una máquina virtual de Java (JV ) y la reconoce el sistema operativo como un proceso javaw.exe. El usuario debe crear cuando menos un nodo para cada anfitrión que ejecute una aplicación de empresa que desee integrar el usuario. El usuario puede tener tantos nodos como dicten los requerimientos del negocio del usuario. Existen dos interfases primarias adentro del sistema 100: (1) · la mesa de trabajo 120; y (2) la consola de administración 160. La mesa de trabajo 120 proporciona herramientas para crear y modificar los flujos de integración 540, mientras que la consola de administración 160 proporciona todas las herramientas para administrar los nodos y servicios del sistema. Ambas se describen con mayor detalle posteriormente en la presente. La creación de un flujo de integración 540 de conformidad con la presente invención se puede hacer como sigue. El usuario primero debe obtener servicios de agente del sistema 100. Entonces, en la consola de administración 160, el usuario configura los nodos del sistema de cada máquina principal en la cual se esté ejecutando una aplicación que el usuario desee integrar. Entonces, el usuario configura los servicios requeridos en los nodos, incluyendo un servicio de agente para cada aplicación que vaya a integrar el usuario. Con el objeto de planear un flujo de integración, el usuario debe determinar los siguientes factores. Por ejemplo, el usuario debe determinar las clases de datos que el usuario necesita extraer de las aplicaciones y propagar a las aplicaciones. El usuario debe considerar además: (1) cómo desea el usuario encaminar los mensajes entre los objetos del sistema; (2) cómo necesita el usuario transformar los datos de una aplicación, de tal manera que otras aplicaciones puedan usar éstos; y (3) si el usuario necesita filtrar ciertos datos fuera del flujo. En la mesa de trabajo 120, el usuario debe crear primero un proyecto, y después crear un flujo de integración de la siguiente manera. Primero, el usuario debe configurar los adaptadores 220 para interactuar con las aplicaciones del usuario, y crear las definiciones de mensaje 512 que necesita el usuario para producir los mensajes apropiados en el flujo de integración 540. Estas definiciones de mensaje 512 deben probarse entonces para asegurarse de que éstas producen los mensajes apropiados. Después, el usuario debe crear núcleos 518 para contener los mensajes de los adaptadores 220 y los transformadores 518. El usuario puede entonces crear definiciones de mapeo 514 para transformar los mensajes de la aplicación de fuente 541 a los mensajes para la aplicación de objetivo 549. Además, el usuario puede crear mensajes de entrada de muestreo 920, 940 y los usa para probar cada definición de mapeo 514, para asegurarse de que ésta produce los mensajes de salida 960, 980 apropiados. Entonces, el usuario debe crear los transformadores 520 necesarios para implementar esas definiciones de mapeo 514. Según sea necesario, se deben enlazar los adaptadores 220, los transformadores 520, y los núcleos 626. Si el usuario necesita filtrar ciertos datos fuera del flujo 540, el usuario debe crear entonces las definiciones de filtro 516. Usando de preferencia los mensajes de muestra, el usuario debe probar después las definiciones de filtro 516 para asegurarse de que éstas filtran fuera los datos apropiados. Después, el usuario puede asignar las definiciones de filtro 516 a los enlaces entre objetos. En la mesa de trabajo 120, el usuario debe verificar entonces la validez del flujo de integración 540 y corregir según sea necesario. El usuario puede entonces salvar y cerrar el proyecto. En la consola de administración 160, el usuario debe entonces configurar el visor de registros, de tal manera que el usuario pueda ver los mensajes sobre la actividad del sistema. Si el usuario desea ver las estadísticas sobre la actividad del sistema (por ejemplo, el número de mensajes producidos en intervalos de tiempo específicos por transformadores individuales) , el usuario debe configurar entonces el visor de estadísticas. Nuevamente, en la consola de administración 160, el usuario puede iniciar el flujo de integración por medio de iniciar los nodos y servicios relevantes del sistema, incluyendo los servicios de agente para las aplicaciones que va a integrar el usuario. Después, el usuario verificará el registro y las estadísticas para asegurarse de que el flujo de integración 540 esté funcionando apropiadamente. Si el usuario necesita hacer cambios al flujo de integración 540, el usuario debe detener, de conformidad con eso, los servicios relevantes en la consola de administración 160, modificar el flujo de integración 540 en la mesa de trabajo 120, y reiniciar los servicios en la consola de administración 160. Lo que sigue describe, para uno de experiencia ordinaria en la técnica, los procedimientos que se pueden usar con un asistente de adaptador de fuente, un asistente de adaptador de objetivo, y un asistente de adaptador de respuesta, todos de conformidad con la presente invención, para configurar apropiadamente un adaptador 220. En general, existen cuatro proceso separados. Primero, uno debe realizar los siguientes pasos generales: (1) nombrar al adaptador 200; (2) elegir el servicio de agente que uno desea que hospede al adaptador 220; y (3) elegir la definición de mensaje 512 para los mensajes que va a producir, recibir o contestar el adaptador 220. En segundo lugar, uno de be realizar los siguientes pasos generales: (1) elegir un adaptador particular 220 que se vaya a configurar (es decir, estándar o personalizado) ; (2) proporcionar información de conexión; y (3) proporcionar información de implementación . Más frecuentemente que lo contrario, el paso de proporcionar la información de implementación incluye el paso de extraer la definición de mensaje 512 de ese adaptador 220. El tercer proceso depende del tipo de adaptador 220 que se vaya a crear. Si uno va a crear un adaptador de fuente 222, uno debe especificar los objetivos para los cuales se va a usar el adaptador 222 para enviar mensajes. Por otra parte, si uno está creando un adaptador de objetivo 224, uno debe especificar las fuentes a partir de las cuales se va a usar el adaptador 224 para recibir mensajes. Si uno está creando un adaptador de respuesta 226, además, uno debe especificar los solicitantes (es decir, los transformadores 520) para los cuales se va a usar el adaptador 226 para enviar mensajes de respuesta . Uno debe especificar finalmente las opciones de envío (por ejemplo, tiempo de vida del mensaje) para los mensajes del adaptador. Sin embargo, antes de que uno pueda crear un adaptador 220, debe existir el servicio de agente que vaya a hospedar al adaptador en la consola de administración 160. Por ejemplo, antes de que uno pueda crear un adaptador EntireX Broker, debe existir el servicio de agente para el EntireX Broker. Si uno desea especificar además los objetos de fuente, objetivo, o solicitante para un adaptador 220, usando el asistente de adaptador, esos objetos deben existir antes de que uno abra el asistente de adaptador. Refiriéndonos nuevamente a las Figuras 4 (a) y 4 (b) , los agentes-adaptadores 200 se interconectan con los recursos de la aplicación por un lado, y la infraestructura del sistema 100 por el otro. Por una parte, la mitad del adaptador de cada agente-adaptador 200 usa la API de su recurso de aplicación particular, o cualquier otro mecanismo de interfase publicado. Por otra parte, el lado del agente se conforma al evento y al modelo de mensajería del sistema 100, como se describe con mayor detalle posteriormente en la presente. En combinación, el agente y el adaptador concillan las diferencias en los protocolos de interfase y las estructuras de datos, proporcionando una vista uniforme, normalizada de los eventos del negocio que éstos publican y consumen. A diferencia de otras soluciones de integración de aplicación, el diseño extensible de la arquitectura de adaptador proporciona la habilidad para acomodar limpiamente el cambio a las interfases de aplicación, mientras que todavía soporta el conjunto en curso de las interfases básicas. Esto es particularmente importante con los sistemas que ya están en producción. Por ejemplo, una aplicación empaquetada que tenga un conjunto básico de interfases A' que soporte una versión particular del agente-adaptador 200. Si una versión más nueva de la aplicación incorpora un conjunto más nuevo de interfases A' ' , el usuario puede elegir adaptarlas simultáneamente a las interfases más antiguas A' para el medio ambiente de producción, mientras que se adaptan a A' ' para un medio ambiente de producción previa, con el objeto de probar las nuevas interfases. Con esta instalación, se puede negociar limpiamente el cambio incremental dentro del medio ambiente de integración . Todo componente del sistema 100 se puede distribuir a través de todas las plataformas soportadas, los agentes -adaptadores 200 extienden flexiblemente éstas a las aplicaciones participantes. Los componentes clave del sistema 100 (por ejemplo, los agentes-adaptadores 200 o el servidor de integración 26) pueden, entonces, reubicarse con las aplicaciones, o accesarse remotamente, o ambos. Son posibles numerosas configuraciones de despliegue - el medio ambiente se optimiza para equilibrar los requerimientos de disponibilidad, funcionamiento y administración. Muchos adaptadores 200 estándares se suministran con el sistema 100, incluyendo SAP, MQSeries, ENTIRE Broker, RDBMS y CICS. Como tales, los adaptadores 200 soportan el desplegado rápido y la fácil integración de estos recursos de información. Estos también reduce la capacitación y las habilidades requeridas. El ADK 130, incluyendo todas sus plantillas de asistentes de automatización, proporcionan alta productividad. Este es adaptable a cualesquier IDEs del usuario, y éste facilita la personalización de los adaptadores proporcionados y el desarrollo de interfases personalizadas. Los adaptadores 200 están conformados de lenguaje popular y vinculaciones de interfase, incluyendo C++, Java, EJB, CORBA, COM, y Natural . De esa manera, éstos se conectan en cualquier medio ambiente y herramientas del usuario. Estos elevan la pericia del lenguaje en casa, y son adaptables a los requerimientos de interfase de recursos complejos. La arquitectura de agente-adaptador de conformidad con la presente invención, por lo tanto, proporciona una instalación robusta que soporta interfases mucho más que simplistas. Esta asegura un evento uniforme a través del portafolio de recursos. El subsistema de agente-adaptador comprende los módulos de interfase de tiempo de ejecución que conectan las aplicaciones externas al EAI. En el lado del adaptador, ésta es la interfase física a la aplicación externa. El lado del agente actúa como un anfitrión para el adaptador, administra los recursos y publica eventos en beneficio del adaptador. Las clases de adaptador base adentro del sistema 100 son como sigue. La clase de "Adaptador Principal" proporciona la habilidad para que el adaptador se inicie a sí mismo y procese sus definiciones de configuración. Este también es responsable de ejemplificar los ejemplos de las clases que van a usar los cuatro tipos posibles de comunicaciones de adaptador. La clase de "Adaptador Receptor" proporciona la habilidad para que el adaptador reciba un documento del EAI, y lo pase al paquete de la tercera parte y lo pase al EAI . La clase de "Adaptador de Respuesta" proporciona la habilidad para que el adaptador reciba un documento desde el EAI, lo pase a un paquete de tercera persona, reciba una respuesta del paquete de tercera persona, y regrese la respuesta al EAI para procesamiento. La clase de "Adaptador Solicitante" proporciona la habilidad para que el Adaptador reciba un documento desde un paquete de tercera persona, lo pase al EAI para procesamiento, reciba una respuesta del EAI, y regrese la respuesta al paquete de tercera persona. La interfase de agente-adaptador del EAI, de conformidad con la presente invención, la realiza el adaptador implementando muchas interfases de Java, mientras que la interfase de adaptador a agente la realiza el adaptador usando métodos conocidos para los componentes de nodo/agente. De conformidad con todavía otro aspecto importante de la presente invención, todo adaptador debe implementar la siguiente interfase. Para el AdapterBridge , el agente invoca el método : initialize (Agent-adapterConfig) durante la inicialización, y lo usa el adaptador para introducirse las instrucciones iniciales a sí mismo. El puente del adaptador está dentro del método de que el adaptador 220, 220', 220'' debe consultar al agente 210 para determinar cuáles definiciones de documento se van a procesar, y el tipo de procesamiento que se proporciona para cada documento. Esto se consigue usando los siguientes métodos de agente: GetSendDocumentDefinitions () getReceiveDocumentDefinitions () getRequestDocumentDefinitions () getResponseDocumentDefinitions () Entonces este método analizará sintácticamente el documento AdapterConfigura ion para localizar la subsección referente a la definición de documento específica, albergar la información de configuración específica del documento, y crear un ejemplo de una clase específica, en base al tipo de procesamiento (enviar, recibir, solicitar o responder) . Subsecuentemente éste ya sea iniciará un Thread (tipos Enviar o Solicitar) , emitirá el Agent . setReceiveListener ( ) (Tipo Recibir) , o emitirá el Agent . setResponseListener ( ) (tipo Respuesta) para registrar las devoluciones de llamadas del agente que se van a invocar cuando llegue un mensaje. El agente 220, 220', 220'' invoca el método RestartO para provocar que el adaptador 210 termine toda la actividad, recargue los datos de configuración y se reinicie a sí mismo. El agente 220, 220', 220'' invoca el método shutdownO durante el procesamiento de terminación. Los adaptadores 220 también implementan las siguientes interfases como se describen posteriormente en la presente. Para la interfase ReceiveListener , el agente 210 invoca un método onReceiveMessage (ReceiveData) sobre la recepción de un mensaje JMS, y el agente pasará el documento al adaptador para procesamiento. Este procesamiento ocurrirá bajo el control del subproceso de sesión JMS. El procesamiento del adaptador consistirá básicamente de un encaminamiento en una sola dirección del documento de la aplicación de software de tercera persona, usando las interfases que proporciona la aplicación. Se debe notar, sin embargo, que no se espera ninguna respuesta de la aplicación sobre este tipo de llamada. El adaptador 220, 220', 220'' estará esperando únicamente una respuesta de éxito o falla de la aplicación. Si el EAI está esperando una respuesta real del sistema de tercera persona, se debe usar más bien la interfase ResponseListener . Para la interfase SendListener, el agente 210 invoca un método onSendTimerEvent (SendData) si el adaptador 220, 220', 220'' está utilizando la característica de cronómetro del nodo/agente. Esta característica es útil cuando la interfase de tercera persona no tiene manera de implementar una notificación de evento accionado para los documentos que va a enviar al EAI para procesamiento . Para la interfase RequestListener , el agente 210 invoca un método onRequestTimerEvent (RequestData) si el adaptador 220, 220', 220'' está utilizando la característica de cronómetro del nodo/agente. Esta característica es útil cuando la interfase de tercera persona no tiene manera de implementar una notificación de evento accionado para los documentos que se van a enviar al EAI para procesamiento. En esta coyuntura se debe notar, sin embargo, que la interfase RequestListener difiere de la interfase SendListener, en el sentido de que ésta enviará el documento al EAI y esperará un documento en respuesta. Entonces esta respuesta se pasará de regreso al sistema de tercera persona. Para la interfase ResponseListener, el agente 210 invoca un método onResponseMesage (ResponseData) sobre la recepción de un mensaje JMS, y el agente 210 pasará el documento al adaptador 220, 220', 220'' para procesamiento. Este procesamiento ocurrirá bajo el control del subproceso de sesión JMS. El procesamiento del adaptador consistirá del encaminamiento del documento a la aplicación de software de tercera persona, usando las interfases proporcionadas por la aplicación, y después el envío de la respuesta de regreso dentro del Sistema 100 para procesamiento adicional. Sin embargo, si el sistema 100 no está esperando una respuesta real del sistema de tercera persona, se debe usar más bien la interfase ReceiveListener . Cuando un usuario instala el sistema 100, el componente principal que instala el usuario es un administrador de nodo 1210, como se muestra en la Figura 12. El administrador de nodo 1210 es una máquina virtual de Java (JVM) , que proporciona servicios a todos los otros nodos y servicios que instale el usuario en el sistema. La instalación del sistema crea automáticamente el servicio depositario 1220, el servicio de interfase del usuario (UIS) 1230, y el servicio de monitor 1240 en la máquina que hospeda al administrador de nodo 1210. Antes de que el usuario pueda iniciar una sesión de cliente 1205 (por ejemplo, la consola de administración 160 o la mesa de trabajo de integración 120) , el usuario debe iniciar el administrador de nodo 1210. Como se notó anteriormente, el administrador de nodo 1210 inicia automáticamente el servicio depositario 1230 y el UIS 1240. De otra manera, el usuario no puede usar la consola de administración 160, ni la mesa de trabajo de integración 120, a menos que se estén ejecutando esos servicios. Dependiendo de la tarea particular de la consola de administración 160 o la mesa de trabajo de integración 120 que esté realizando el usuario, se pudieran requerir otros servicios. Una vez que está funcionando el administrador de nodo 1210, el usuario debe configurar los nodos y servicios del sistema, incluyendo los servicios de agente 1250, para las aplicaciones que el usuario desee integrar. El usuario inicia ésto por medio de primeramente usar una sesión de la consola de administración 160. Entonces el usuario puede iniciar una sesión de mesa de trabajo de integración 120 y empezar a diseñar los flujos de integración 540, como se muestra en la Figura 5(c). Cuando el usuario termina de diseñar esos flujos de integración 540, el usuario puede, después de lo mismo, iniciarlos por medio de iniciar los nodos y servicios a partir de una sesión de consola de administración 160. Cuando el usuario inicia una sesión de cliente, el usuario identifica al administrador de nodo 1210 como el servidor del cliente 1215. El usuario puede conectar tantas sesiones de mesa de trabajo de integración 120 y consola de administración 160 al administrador de nodo 1250, como lo dicten los requerimientos del negocio del usuario. Todas esas sesiones de mesa de trabajo de integración 120 y consola de administración 160 serán de sólo lectura. Las sesiones de consola conectadas al administrador de nodo 1250 tienen acceso al contenido del servicio depositario 520 que se esté ejecutando en ese administrador de nodo 1210. Cuando se trabaja con el sistema 100, el usuario debe ejecutar el administrador de nodo 1210, una sesión de consola de administración 160, y una sesión de mesa de trabajo de integración 120.

Nodos Como se notó anteriormente en la presente, y refiriéndonos ahora también a las Figuras 13 (a) a 13 (c) , en conjunción con la Figura 12, un nodo 1310 es un proceso físico que se ejecuta en un anfitrión 1300, y soporta uno o más servicios. Cada nodo 1310 es una máquina virtual de Java (JVM) , y el sistema operativo lo reconoce como un proceso javaw.exe. El usuario debe crear cuando menos un nodo 1310 para cada anfitrión 1300 que ejecute una aplicación de empresa que desee integrar el usuario. El usuario puede tener tantos nodos 1310 como lo dicten los requerimientos del negocio del usuario. Un servicio es un objeto que proporciona funcionalidad de producto. El sistema 100 generalmente comprende servicios del sistema y servicios de aplicación. Una interfase de usuario gráfica (GUI) del cliente, tal como la mesa de trabajo de integración 120 y la consola de administración 160, le permite al usuario trabajar con el sistema 100. Los clientes 1205 (Figura 12) pueden funcionar en el mismo anfitrión físico 1300 en el que se estén ejecutando los nodos 1310 y los servicios, o éstos pueden funcionar en un anfitrión diferente 1200. Cada empresa también debe tener un administrador de nodo 1210. El administrador de nodo 1210 proporciona servicios a todos los otros nodos 1310 en el sistema 100. Este ejecuta el servicio de interfase del usuario (UIS) 1230 y el servicio depositario 1220. La Figura 13(a) ilustra un medio ambiente que tiene tres anfitriones 1300. el Anfitriónl está ejecutando el Administrador de Nodo 1210, mientras que el Anfitriónl y el Anfitrión2 están ejecutando, ambos, los nodos 1310. El sistema 100 es una colección de servicios de sistema y servicios de aplicación. Los servicios de sistema soportan nodos y servicios. Por ejemplo, el servicio de monitor 1240 almacena datos de tiempo de ejecución del sistema, para los nodos 1310 y los servicios. Los servicios de aplicación proporcionan funcionalidad al sistema 100. Por ejemplo, los servicios de agente CICS soportan adaptadores que necesitan conectarse a aplicaciones CICS.

Servicios del Sistema Los servicios del sistema de conformidad con la presente invención generalmente comprenden un servicio de interfase del usuario (UIS) 1230, un servicio depositario 1220, y un servicio de monitor 1240. El UIS 1230 más específicamente proporciona las instalaciones necesarias para ejecutar componentes del cliente (es decir, la mesa de trabajo de integración 120 y la consola de administración 160) . De la misma manera, el servicio depositario 1220 almacena las configuraciones para todos los servicios configurados y los objetos de flujo de integración 540. Finalmente, el servicio de monitor 1240 almacena datos de tiempo de ejecución del sistema, incluyendo registro del sistema e información estadística.

Servicios de Aplicación Refiriéndonos nuevamente a la Figura 12, se puede ver que los servicios de aplicación que se usan en el sistema 100 incluyen el servicio de mensajería de empresa (EMS) 1260, que habilita al sistema 100 para usar múltiples modos de mensajería, incluyendo mensajería de punto-a-punto, de publicar/suscribir, y de solicitud/respuesta. El EMS 1260 también soporta núcleos de mensajes y proporciona persistencia de mensaje. Los servicios de aplicación incluyen además un servicio de integración (IS) 1270, que habilita al sistema 100 para transformar mensajes, incluyendo datos de mensajes divisores, mensajes de combinación, y mensajes de manipulación. El IS 1270 soporta adicionalmente transformadores. Los servicios de fábrica RMI (no se muestran) se pueden usar opcionalmente como un servicio de aplicación para administrar enlaces de invocación de método remotos para aplicaciones externas. Los servicios de encaminamiento 1280 también comprenden un servicio de aplicación, que habilita al sistema 100 para dirigir mensajes a través del sistema, en base al contenido del mensaje, incluyendo la filtración del contenido del mensaje de conformidad con los criterios que defina el usuario, y la determinación de si los mensajes son válidos. El servicio de encaminamiento 1280 también soporta filtros. Los servicios de agente 1250 soportan adaptadores. El usuario debe instalar un servicio de agente en cada anfitrión 600 que ejecute una aplicación de empresa que desee integrar el usuario. Como se muestra en la Figura 13(b) , el Anfitriónl y el Anfitrión 2 están, ambos, ejecutando servicios. El Anfitrión3 no puede ejecutar servicios porque éste no tiene un nodo 1310.

Clientes El sistema 100 incluye dos GUIs de cliente que le permiten al usuario trabajar con los flujos de integración 540. Los clientes se pueden ejecutar en cualquier anfitrión 1300, sin importar si el anfitrión 1300 ejecuta el administrador de nodo 1210, ejecuta los nodos 1310 y los servicios, o no ejecuta ningún nodo 1310 ni servicio. El usuario puede instalar tantos clientes como los dicten los requerimientos del negocio del usuario. Por ejemplo, un usuario pudiera desear instalar clientes 1205 en un anfitrión unido a la red, para trabajar con los flujos de integración 540 del usuario desde una ubicación remota. En la Figura 13(c), tanto el Anfitrión2 como el Anfitrión3 están ejecutando los clientes de la consola de administración 160 y la mesa de trabajo de integración 120. El Anfitriónl, por otra parte, no está ejecutando los clientes ni de la consola de administración 160 ni de la mesa de trabajo de integración 120. Existen dos interfases primarias adentro del sistema 100: (1) la mesa de trabajo de integración 120 y (2) la consola de administración 160. La mesa de trabajo de integración 120 proporciona herramientas para crear y modificar flujos de integración 700, mientras que la consola de administración 160 proporciona todas las herramientas para administrar los nodos y servicios del sistema. Ambas se describen con mayor detalle posteriormente en la presente. La creación de un flujo de integración 700 de conformidad con la presente invención se puede hacer como sigue. El usuario primero debe obtener agentes deservicio del sistema 100. Entonces, en la consola de administración 160, el usuario configura los nodos del sistema de cada máquina principal en la cual se esté ejecutando una aplicación que el usuario desee integrar. Entonces, el usuario configura los servicios requeridos en los nodos, incluyendo un servicio de agente para cada aplicación que vaya a integrar el usuario. Con el objeto de planear un flujo de integración, el usuario debe determinar los siguientes factores. Por ejemplo, el usuario debe determinar las clases de datos que el usuario necesita extraer de las aplicaciones y propagar a las aplicaciones. El usuario debe considerar además: (1) cómo desea el usuario encaminar los mensajes entre los objetos del sistema; (2) cómo necesita el usuario transformar los datos de una aplicación, de tal manera que otras aplicaciones puedan usar éstos; y (3) si el usuario necesita filtrar ciertos datos fuera del flujo.

El Proceso de Conversión - Accesores y Convertidores Como se notó anteriormente en la presente, otra función importante del modelo de mensaje es importar a, y exportar desde formatos de archivo nativos de cualquier aplicación. Los archivos que contienen tanto caracteres como datos binarios en la aplicación, y los formatos específicos a la plataforma se traen a la forma "canónica" descrita, en donde los datos se representan como objetos de Java. Una meta clave en el diseño de este esquema es maximizar el uso repetido. Por lo tanto, una definición de mensaje dada se puede configurar a la medida con lo que conceptualmente es un "controlador de dispositivo" . Esto es, dos formatos de archivo nativos, que estructuralmente representan el mismo formato de datos, pueden producir mensajes canónicos estructurados de manera idéntica cuando se configuran con los controladores apropiados. El "controlador de dispositivo" es de hecho un conjunto de objetos de Java llamadas "accesores" y "convertidores", que están unidos a sus nodos apropiados en los metadatos de definición de mensaje, y metadatos globales. Una definición de mensaje completamente configurada que ha persistido por medio de la serialización de objetos de Java se vuelve entonces un analizador sintáctico de formato de archivo nativo empaquetado, listo para irse, y el formateador para un proceso de conversión de formato de archivo nativo dado aprovecha completamente las últimas instalaciones de codificación y localización del conjunto de caracteres que proporciona el Estuche de Desarrollo de Java (JDK) . Todas las cadenas de caracteres nativas se ven como configuraciones de bytes, y se convierten internamente a Unicode para que los usen las rutinas de análisis sintáctico y formateo. Se puede notar que la Versión 1.1.6 del JDK soporta casi 100 diferentes codificaciones de caracteres, y que el modelo del mensaje, de conformidad con la presente invención, los maneja a todos ellos con el mismo lógico. El modelo de mensaje también procura usar la herencia de los atributos del artículo tanto como sea posible. De esta manera, se supone que los datos específicos a la aplicación tienen un orden de bytes, codificación y localidad por omisión. Los accesores individuales pueden pasar por alto a cualquiera de éstos, pero en la práctica ésto no debe pasar muy frecuentemente. Los accesores y convertidores son objetos de dos direcciones. Estos pueden convertir datos nativos a un objeto de Java para almacenarse en un árbol de mensajes, y además pueden transformar un objeto de Java de regreso a su representación nativa. En el espíritu del uso repetido, un objeto de la presente invención fue minimizar el número total de clases de conversiones que se necesitan escribir. De conformidad con lo anterior, el proceso de conversión descrito en la presente se puede ver como un problema con dos ejes, la formación de contraseña/formateo en un eje y la conversión de bytes en el otro. Un ejemplo de una clase de accesador es un objeto de Java que sabe cómo seleccionar a través del "azúcar sintáctico" en un campo nativo, y aislar los bytes reales que necesite producir o convertir un convertidor específico a partir de un objeto de Java. Considere, por ejemplo, el caso en donde se marca un campo de datos de punto flotante en ambos lados, por medio de un byte o secuencia de caracteres determinado previamente. Estos se conocen como "marcadores" en el sistema 100. Una clase específica de accesador (en este caso un accesador de marcador de cola) sabe como pasar por alto el marcador guía y encontrar la ubicación del marcador de cola, para aislar los cuatro bytes que son de hecho la "carne" de los datos de punto flotante. El convertidor de bytes de punto flotante previamente configurado en la definición de mensaje produce un objeto Flotador de Java a partir de los bytes. En la otra dirección, el accesador escribe el marcador guía, le dice al convertidor que escriba los bytes nativos, y entonces el accesador termina con la cola. Una ventaja distinta de este esquema es que solamente se necesitan escribir un manojo de accesores y aproximadamente dos docenas de convertidores. Puesto que los accesores y convertidores de la presente invención son esencialmente objetos de sólo lectura una vez configurados, el tamaño de la definición de mensaje se puede mantener relativamente pequeño debido a que se comparte el objeto en donde es posible. El recolector de basura de Java remueve convenientemente los temas de quién posee qué objeto en este caso. Algunos accesores y convertidores se necesitan configurar con ajustes iniciales, mientras que otros no lo necesitan. Estos objetos están empaquetados como JavaBeans, con diálogos de propiedad simples en donde sean necesarios. De conformidad con una modalidad actualmente preferida de la invención, la siguiente tabla expone los accesores que soportan al sistema 100. A medida que se necesiten nuevos tipos, éstos se pueden añadir limpiamente al sistema 100, sin la necesidad de escribir nuevos convertidores.

Tipo de Accesador Característica Longitud fija El campo de accesador siempre es de longitud fija. Esta longitud fija indica ya sea la longitud de todo el campo, o su longitud menos cualesquier marcadores.

Longitud indicada Esencialmente el mismo que un accesador de longitud fija, excepto que otro campo compatible con el entero en los datos contiene el especificador de longitud. Estos indicadores de longitud son lo que se conoce como objetos "enlazados", y opcionalmente se pueden abanderar como objetos "transitorios" , los detalles de ambos de los cuales se describen con mayor detalle posteriormente en la presente.

Marcador de cola El campo termina en el marcador de cola.

Longitud Implicada La longitud de campo está implícita en el tipo de convertidor - mayormente usado para formatos binarios Delimitado por secciones Si la sección contenedora usa un esquema delimitador, el delimitador puede señalizar el fin del objeto.

Objeto basado en Sintaxis El objeto se acopla a una cierta expresión regular, Se debe notar que ^ada uno de los acce sores de scritos anteriormente son accesores de tema . Aunque mucho más s imple s , igualmente se pueden usar accesores de sección. Esos accesores de sección tienen marcadores opcionales, y también pueden usar un esquema delimitador. Hasta cierto grado, la inclusión de ese esquema delimitador depende del análisis sintáctico exitoso de sus elementos contenidos. Los delimitadores usan ya sea un esquema de prefijo, afijo, o sufijo, y de hecho son los mismos elementos de marcador que se usan para restringir campos. Los accesores de tabla extienden los accesores de sección para trabajar con un tema enlazado que indica un conteo de registro. El número inicial de convertidores que soportan el sistema 100 es relativamente pequeño, pero es muy completo en base a un análisis de los formatos de archivo comerciales. Los convertidores, de conformidad con la presente invención, comprenden dos tipos básicos: ya sea un convertidor basado en caracteres o un convertidor binario. Todos los convertidores de carácter heredan de una clase base común que proporciona la noción de justificación y caracteres de relleno. Esos caracteres de relleno se pueden especificar como caracteres de valor de byte absolutos o como caracteres Unicode, que se mapean a la codificación nativa. Los convertidores de caracteres, de conformidad con la presente invención, incluyen: Tipo de Convertidor de Caracteres Característica Decimal Formatea y analiza sintácticamente de conformidad con una "máscara de formato", derivada de aquella especificadaenjava.text.DecimalFormat. Lamáscara es de la forma #,##0.0##, y puede especificar características tales como signos de menos guía o de cola, etcétera. La gramática de la máscara se extenderá según sea necesario para habilitar cualquier procesamiento previo o posterior, en donde la gramática sea insuficiente.

Entero Igual que el convertidor decimal, pero no se permiten lugares decimales.

Moneda También soportado por Java, otro refinamiento del convertidor digital.

Fecha/Hora Usa la especificación de máscara java.text.SimpleDateFormat. este formato es muy extenso, y debe satisfacer todas las necesidades.

Cadena genérica Depende del marcador de longitud fija, de cola o el delimitador de sección para demarcación. Los convertidores binarios heredan el orden de bytes especificado por el mensaje por omisión, pero se pueden anular por medio de un argumento constructor. Esos convertidores binarios, de conformidad con la presente invención, incluyen: Tipo de Convertidor Binario Característica Firmado/no firmado 2's Números complementarios de 8, 16, 32 y 64 bits asimismo. Los tipos no firmados se promueven al siguiente tipo integral de Java más grande si se necesita. Se debe notar que Java incluye un paquete de precisión arbitrario en java.math para largos no firmados.

IEEE 754 flotante y doble Se puede usar el JNI para éste, así como los convertidores (especificación de 1985) IntegerBits y LongBits que se proporcionan en las clases Flotante y Doble. Se debe notar que éste solamente puede ser soportado en plataformas de un tipo flotante nativo. Decimal empaquetado Los convertidores pueden producir o consumir más de un tipo de Java. Por ejemplo, un convertidor flotante nativo puede mapearse razonablemente a un Flotante, Doble, Entero, Largo o de Cadena, entre otros. Todos los convertidores implementan una interfase de convertidor nativa, la cual especifica una funcionalidad de "Object load (Class) , ... ) " y "void store (Object ...)" . Sin embargo, la subclase real producida depende de cuáles otras interfases de convertidor implementa el objeto. Estas son esencialmente interfases de marcador, que no contribuyen a ningún método nuevo. Por ejemplo, en el sistema 100 se puede usar un Convertidor Doble (DoubleConverter) , un Convertidor Entero ( IntegerConverter) , Convertidor de Cadena (StringConverter) , etcétera, sin apartarse del verdadero espíritu y alcance de la presente invención. Una herramienta de configuración, tal como una interfase de usuario gráfica (GUI) puede, a través de la introspección de clase, determinar una lista apropiada de convertidores para presentarse para usarse en un caso particular. Adentro de los métodos de carga y almacenamiento, el convertidor examina cuál de sus interfases soportadas que éste implementa que corresponden a una clase de Objeto es un "instanceof" (ejemplo de) o la Clase suministrada. El Objeto genérico que se regresa o se procesa es ahora realmente de un subtipo apropiado.

Marcadores Se puede pensar de los marcadores como azúcar sintáctico, útiles tanto como delimitadores de campo, y como contraseñas de tema individuales. Todos los objetos, sean secciones o temas, pueden incluir un marcador guía, un marcador de cola, o ambos. De conformidad con una modalidad actualmente preferida de la invención, existen tres formatos de marcador básicos. Dos formatos, conocidos como un marcador de patrón fijo, y un marcador del estilo "strtok", especifican ya sea un patrón de bytes o una cadena Unicode que se mapea a la codificación de caracteres nativos. Comprendiendo un conjunto de caracteres de los cuales se encuentran 0 ó más ocurrencias, el marcador de estilo "strtok" es útil para indicar espacios en blanco o relleno binario. El tercer formato, marcadores basados en claves, tienen un patrón en el que la clave de un objeto que se está procesando se sustituye en un patrón. Por ejemplo, el par marcador <X-> y </-X-> se volverían <Clientes> y </Clientes>, que serían útiles para analizar sintácticamente los mensajes de estilo XML, y en general para ayuda para localizar temas opcionales.

Argumentos Opcionales El análisis sintáctico y reconocimiento de argumentos opcionales es un proceso difícil. Por ejemplo, si los datos de entrada especificados son cinco cadenas opcionales de cualquier longitud, y se leen exitosamente tres cadenas, pudiera no ser posible saber cuál cadena es cuál . Los temas opcionales que no se encuentren se establecerán a nulo en el mensaje. A continuación sigue un conjunto de condiciones bajo las cuales se pueden reconocer temas opcionales, de conformidad con la presente invención. Considere el caso en el que una sección usa delimitadores, y se encuentra un delimitador para un campo vacío. Por ejemplo, un usuario sabría que falta el segundo elemento si la entrada fuera "Able , , Charley" en un esquema de afijo. Otra condición en la cual se pueden reconocer temas opcionales ocurre cuando los campos usan el marcador basado en clave para autoidentificación . En el estilo de los argumentos de función por omisión C++, surgiría todavía otra condición, si todos los argumentos opcionales vienen al final de la lista, y se detecta el final de la sección, el análisis sintáctico es exitoso. En general, siempre que un usuario no logra analizar sintácticamente un campo correctamente, y el campo es opcional, el usuario salta al siguiente campo y trata nuevamente, hasta que se alcanza el final de la sección. Aquí se requeriría una sección con un marcador de cola (o fin-de-archivo) . Al final de esta sección, si no se les ha asignado un valor a los temas no opcionales, el análisis sintáctico falla. Esto no garantizaría resultados correctos si el formato de temas sucesivos fuera ambiguo . Las omisiones trabajan de manera diferente, como para si ésta es una sección o un tema. Los metadatos de mensajes para un tema contienen un objeto por omisión. Por omisión, si el objeto soporta la interfase clonable, el objeto se clona de los metadatos a la instancia de mensaje. Si éste no soporta la interfase, el valor se almacena como una Cadena en los metadatos, junto con su clase, y se usa la API de Reflexión de Java para invocar el constructor basado en Cadena del objeto, para suministrar el mensaje con un objeto. Por secciones, la omisión es un enlace a otra definición de mensaje almacenada persistentemente. La sección de nivel superior de la definición de mensaje de referencia se injertaría en los metadatos de mensaje y se produciría mejor un mensaje de la estructura combinada .

Temas Enlazados y Transitorios En algunos casos, los datos nativos son autodescriptivos . Por ejemplo, una tabla puede estar precedida por su cuenta de filas. Los usuarios no desearían incluir este conteo en el mensaje canónico final producido, sin embargo, porque éste es autoevidente por la longitud de la configuración de Java que representa la tabla. En este caso, el nodo puede marcarse opcionalmente como transitorio. Este se añade temporalmente al mensaje, y se remueve una vez que se ha construido y añadido la tabla. De esta manera, el usuario puede configurar una definición de mensaje con dos controladores diferentes, para producir el mismo mensaje canónico. Esto es, si en un caso se determinara la longitud de la tabla sin un indicador de conteo, ésto no produciría ese campo entero en el nodo. Las tablas deben ser isomórficas en este caso, de tal manera que el argumento debe ser transitorio. Continuando con el ejemplo anterior, uno puede notar que existe una conexión inherente entre el conteo y la tabla. Como resultado, ambos se marcarán como teniendo una relación de enlace. Ambos se encontrarán adicionalmente sobre el nombre de ruta relativo y absoluto del otro objeto, más un indicador de estado en sus accesores, como se ve posteriormente. COUNT-PROVIDER (CONTEO- PROVEEDOR) COUNT-USER (CONTEO-USUARIO) LENGTH-PROVIDER (LONGITUD-PROVEEDOR) LENGTH-USER (LONGITUD-USUARIO) REDEFINE-PROVIDER (REDEFINIR- PROVEEDOR) REDEFINE-USER (REDEFINIR-USUARIO) En el caso de las redefiniciones, el proveedor proporciona un discriminante ya sea de cadena o integral . En la dirección del análisis sintáctico debe aparecer el tema del proveedor, antes que su usuario en el recorrido y conversión. En la dirección de formateo, primero se escribe el proveedor con un apartador de lugar, y subsecuentemente se llena con su valor apropiado. Se debe notar que el proveedor de conteo debe usar un formato de longitud fija para que trabaje el anterior.

Cláusulas y Relaciones de Validación La definición de mensaje tiene aparta lugares en sus temas de metadatos para una lista de cláusulas de validación y relaciones intermensaj e . De conformidad con una modalidad actualmente preferida de la invención, las cláusulas de validación se ejecutan, todas ellas, en el mensaje convertido únicamente después de que se ha convertido todo el mensaje. El diseño del objeto permite, sin embargo, cláusulas de validación por tema, si se desea . También hay un apartador de lugar para especificar las relaciones entre las columnas de una tabla en un mensaje, y las columnas en otro. Esto facilita el mapeo de valores y uniones. En las Figuras 13 y 14 se muestra la manera en la que se puede crear el mensaje, sin y con conversión de los datos puros. La Figura 13 ilustra un método 1340 sin convertir los datos puros que empiezan en la aplicación 541. El usuario crea un mensaje vacío (por ejemplo, "DocDef . createNewInstance) en 1320, y el mensaje vacío se pobla con los datos de la aplicación a través de la API de definición de mensaje 1330. Así se crea una ejemplo de mensaje 1340. El ejemplo de mensaje 1340 puede pasar entonces a través de otra API de definición de mensaje 1350 de la aplicación, con el objeto de enviar el mensaje a esa aplicación 1360. Cuando aparece lo que se necesita para convertir los datos puros, se emplea el método que se muestra en la Figura 14. En el principio se reciben los datos específicos de la aplicación 1410 desde la aplicación 1420. Se crea un mensaje vacío en 1430 y se pobla con no solamente esos datos específicos de la aplicación 1410, sino también con información de conversión pura. Los datos específicos de la aplicación 1410, por medio de los accesores y convertidores 1440, se envían a un ejemplo de mensaje 1450, que también recibe la información poblada en el documento vacío en 1430. Por ejemplo, esto se puede hacer mediante: DocDef . createDocumentFromFile La API soporta los dos siguientes métodos para crear el mensaje : DocDef . createDocumentFromFile DocDef . createDocumentFromBytes Entonces, a través de otros accesores y convertidores 1460, se puede convertir el mensaje a otros datos específicos de aplicación 1470 de la aplicación, y recibirse mediante esa aplicación 1480. Refiriéndonos ahora a las Figuras 15(a) a 15(d), ahora se describirán los beneficios del objeto de mensaje, de conformidad con la presente invención. La Figura 15(a) ilustra un método 1510 para crear un mensaje sin convertir los datos de aplicación puros, de conformidad con la presente invención. Como un primer paso la aplicación 1512 crea un mensaje vacío. Esto se hace mediante la creación de una definición de mensaje 512 (por ejemplo, "def ; //inicializar en otra parte def . createEmptyDocument (docna e) ;") . La API de la aplicación 1514 se acopla a la API de la definición de mensaje 1516, con el objeto de poblar el mensaje mediante el uso de la API de la definición de mensaje 1516. Entonces se pueden aplicar después la omisiones de mensaje (por ejemplo, "def . applyDocumentDefaultValues (docname) ") , y así se crea un ejemplo de mensaje 1518. En la Figura 15(b) se muestra el método inverso 1520, en donde el ejemplo de mensaje 1522 se envía a través de la API de la definición de mensaje 1524, que se acopla a la API de la aplicación 1526, y se usa para poblar valores de campo. Entonces se envía el mensaje a la aplicación 1528. r La creación de mensajes con la conversión de los datos de aplicación es un asunto más difícil. Como se muestra en la Figura 15(c), un método 1530 para convertir mensajes de conformidad con la presente invención, a partir de una aplicación 1532 a un ejemplo de mensaje 1538, empieza con el mensaje que se envía desde la aplicación 1532 a través de un convertidor. La API de la definición de mensaje 1536 crea un mensaje vacío, pobla el mensaje vacío con los datos de la aplicación 1532 (es decir, ya sea de un archivo o de bytes) , y añade información de conversión pura de los accesores y convertidores, de conformidad con la presente invención. Por ejemplo : Definición de Documento def ; //Añadir Accesores y Convertidores Inicializar en otro lugar def . createDocumentFromFile {docname, filename) o, def . createDocumentFromBytes ( docname, hyte [] ) En la Figura 15(d) se muestra el método inverso 1540, en donde se envía un ejemplo de mensaje 1542, a través de la API de la definición de mensaje 1544, para poblar una configuración de archivos o bytes 1546 con los datos del ejemplo de mensaje 1532, y después a la aplicación 1548. Por ejemplo Definición de Documento def ; //Añadir Accesores y Convertidores Inicializar en otro lugar def . storeDocumentToFile (filename) o, def . storeDocumentToBytes (byte [] ) En las Figuras 16 y 17 se muestran diagramas de clase para procesos similares. De conformidad con otro importante aspecto de la presente invención, el sistema 100 comprende un sistema distribuido. Esto es, el usuario puede ejecutar los componentes del sistema que conforman el sistema 100, en una o más máquinas físicas (es decir, anfitriones) , pero todos los componentes trabajando juntos como una aplicación. Todo componente del sistema 100 se puede distribuir a través de todas las plataformas soportadas. Los agentes -adaptadores 200 extienden flexiblemente éste a las aplicaciones participantes. Los componentes clave del sistema 100 (por ejemplo, los agentes-adaptadores 200 o el servidor de integración 26) puede, de esta manera, estar colocalizados con las aplicaciones, o se pueden accesar remotamente, o ambos. Son posibles numerosas configuraciones de despliegue - el medio ambiente se optimiza para equilibrar los requerimientos de disponibilidad, funcionamiento y administración.

Operadores La siguiente tabla describe generalmente todos los operadores del sistema actualmente contemplados, que puede usar un usuario para construir expresiones para definiciones de mensaje, definiciones de transformador, y definiciones de filtro. El sistema 100 soporta estos operadores Operador Descripción && "Y" lógico ¡ ¡ "0" lógico ! "NO" lógico Asignación = "Igual" lógico != "No igual" lógico + Más unario Menos unario * Multiplicación / División < Menor que <= Menor que o igual a > Mayor que >= Mayor que o igual a Funciones La siguiente tabla describe generalmente todas las funciones del sistema actualmente contempladas, que puede usar un usuario para construir expresiones para validar o filtra mensajes, y transformar datos de mensaje. Cada descripción incluye lo que hace la función, lo parámetros que ésta requiere, y el valor que ésta regresa. Cuando se transforman datos de mensajes, el usuario típicamente usa estas funciones para tomar los valores del tema del mensaje de los mensajes de entrada, y crear los valores del tema del mensaje para los mensajes de salida. Cuando se validan o filtran mensajes, el usuario usualmente usa estas funciones para crear expresiones booleanas. Los valores del parámetro para estas funciones pueden ser ya sea temas del mensaje o valores constantes (es decir, literales) . Tipo de Datos Ejemplos Literales Integer (Entero) 1234, OxFF, 077, -1234 Long (Largo) 1234, 1234L, - OxFF, 077L Double (Doble) 12.34 String (Cadena) "Sagavista" Boolean (Booleano) verdadero o falso BigDecimal 12.34a, en donde "a" significa (Decimal Grande) precisión arbitraria Calendar #FECHA (2000, 2, 13) (Calendario) #FECHA_HORA(2000, 2, 13, 23, 59) #FECHA_FORMATO ( "M/d/yyyy " , "2/13/2000") El sistema 100 también proporciona las funciones descritas posteriormente, aunque un usuario puede escribir las propias funciones del usuario para usarlas con el sistema 100.

Función Descripc ión addToDate Añade un número especificado de días a una fecha del objeto de Calendario y regresa la fecha del objeto de Calendario resultante bigDecimalTo Boolean Convierte un objeto BigDecimal a un objeto Booleano bigDecimalToDouble Convierte un objeto BigDecimal a un objeto Doble bigDecimalToLong Convierte un objeto BigDecimal a un objeto Largo bigDecimalTo String Convierte un objeto BigDecimal a un objeto de Cadena booleanToBigDecimal Convierte un objeto Booleano a un objeto BigDecimal booleanToLong Convierte un objeto Booleano a un objeto Largo booleanToString Convierte un objeto Booleano a un objeto de cadena calendarToString Convierte un objeto de Calendario a un objeto de cadena compareDates Compara dos valores de datos de objeto de Calendario, e indica si la primera fecha es menor que, igual a, o mayor que la segunda fecha doubleToBigDecimal Convierte un objeto Doble a un objeto BigDecimal doubleToLong Convierte un objeto Doble a un objeto Largo doubleToString Convierte un objeto Doble a un objeto de cadena findString Busca un objeto de Cadena adentro de otro objeto de Cadena, y regresa la posición del primer carácter de Cadena encontrado, adentro de la otra Cadena findWord Busca una palabra adentro de un objeto de Cadena, y regresa la posición del primer carácter de la palabra adentro de la Cadena foundString Busca un objeto de Cadena adentro de otro objeto de Cadena, y regresa un objeto Booleano foundWord Busca una palabra adentro de un objeto de Cadena, y regresa un objeto Booleano getDate Encuentra la fecha en un objeto de Calendario y regresa el mes como un objeto Entero getMonth Encuentra el mes en un objeto de Calendario y regresa el mes como un objeto Entero getYear Encuentra el año en un objeto de Calendario y regresa el año como un objeto Entero getTokenAt Analiza sintácticamente un objeto de Cadena en unidades lógicas, encuentra una unidad lógica particular, y regresa la unidad lógica como un objeto de Cadena integerToString Convierte un objeto Entero a un objeto de Cadena isAlpha Determina si todos los caracteres en un objeto de Cadena son alfabéticos, y regresa un objeto Booleano isAlphaNumeric Determina si todos los caracteres en un objeto de Cadena son alfanuméricos, y regresa un objeto Booleano isNumeric Determina si todos los caracteres en un objeto de Cadena son numéricos, y regresa un objeto Booleano justifyCenter Crea un objeto de Cadena de una longitud especificada, y centra otro objeto de Cadena adentro de éste justifyLeft Crea un objeto de Cadena de una longitud especificada, y justifica a la izquierda otro objeto de Cadena adentro de éste justifyRight Crea un objeto de Cadena de una longitud especificada, y justifica a la derecha otro objeto de Cadena adentro de éste longToBigDecimal Convierte un objeto Largo a un objeto BigDecimal longToBoolean Convierte un objeto Largo a un objeto Booleano longToDouble Convierte un objeto Largo a un objeto Doble longToString Convierte un objeto Largo a un objeto de Cadena lookup Busca un objeto de Cadena en una tabla de búsqueda especificada en otro objeto de Cadena, y regresa el valor correspondiente lowercase Convierte todos los caracteres en un objeto de Cadena a letras minúsculas replaceString Busca un objeto de Cadena para un objeto de Cadena particular, reemplaza el objeto de Cadena encontrado con un objeto de Cadena de reemplazo, y regresa el objeto de Cadena con la Cadena de reemplazo en su lugar replaceWord Busca un objeto de Cadena para una palabra particular, reemplaza la palabra encontrada con una palabra de reemplazo, y regresa el objeto de Cadena con la palabra de reemplazo en su lugar sizeOf Determina el tamaño de un objeto de Cadena o un objeto de ByteArray y regresa el tamaño como un objeto Largo stringToBigDecimal Convierte un objeto de Cadena a un objeto BigDecimal stringToBoolean Convierte un objeto de Cadena a un objeto Booleano stringToCalendar Convierte un objeto de Cadena a un objeto de Calendario stringToDouble Convierte un objeto de Cadena a un objeto Doble stringToInteger Convierte un objeto de Cadena a un objeto Entero stringToLong Convierte un objeto de Cadena a un objeto Largo Subarray Encuentra un objeto ByteArray adentro de otro objeto ByteArray, y regresa el objeto ByteArray encontrado substring Encuentra un objeto de Cadena adentro de otro objeto de Cadena, y regresa el objeto de cadena encontrado trim Remueve el espacio en blanco de antes y después de una Cadena uppepcase Convierte todos los caracteres en un objeto de Cadena a letras mayúsculas addToDatg Esta función añade un objeto Largo que especifica un cierto número de días, a una fecha del objeto de Calendario, y regresa la fecha del objeto de Calendario resultante. CalendaraddToDate (Calendar, Long) Tipo de Parámetro Valor (Calendar , Long) Fecha, número de días a añadir a la fecha Tipo de regreso Valor Calendario Fecha resultante Ejemplo: Se define un tema de mensaje llamado DatePurchased como un objeto de Calendario. Para otro mensaje, el usuario necesita el valor de DatePurchased más cinco días en un objeto de Calendario. El usuario introduciría la función como sigue: addToDate (MsgDef . DatePurchased, 5) Si el valor de DatePurchased fuera equivalente a 13 de febrero de 2000, la función regresaría un objeto de Calendario cuyo valor fuera equivalente a 18 de febrero de 2000. bigDecimalToBoolean Esta función convierte un objeto BigDecimal a un objeto Booleano. Boolean bigDecimalToBoolean (BigDecimal) Tipo de Parámetro Valor (BigDecimal) BigDecimal para conversión Tipo de Regreso Valor Cuando Booleano Verdadero BigDecimal es cualquier valor diferente a 0 Falso BigDecimal es 0 bigDecimalToDouble Esta función convierte un objeto BigDecimal a un objeto Doble. Double bigDecimalToDouble (BigDecimal) Tipo de Parámetro Valor (BigDecimal) BigDecimal para conversión Tipo de Regreso Valor Doble Doble Resultante bigDecimalToLonq Esta función convierte un objeto BigDecimal a un objeto Largo. Long bigDecimalToLong (BigDecimal) Tipo de Parámetro Valor (BigDecimal) BigDecimal para conversión Tipo de Regreso Valor Largo Largo Resultante biqDecimalTo String Esta función convierte un objeto BigDecimal a un objeto de Cadena. String bigDecimalToString (BigDecimal) Tipo de Parámetro Valor (BigDecimal) BigDecimal para conversión Tipo de Regreso Valor Cadena Cadena Resultante booleanToBiqDecimal Esta función convierte un objeto Booleano a un objeto BigDecimal . BigDecimal booleanToBigDecimal (Boolean) Tipo de Parámetro Valor (Boolean) Booleano para conversión Tipo de Regreso Valor Cuando BigDecimal 1 Booleano es verdadero 0 Booleano es falso booleanToLong Esta función convierte un objeto Booleano a un objeto Largo . Long booleantoLong (Boolean) Tipo de Parámetro Valor (Boolean) Booleano para conversión Tipo de Regreso Valor Cuando Largo 1L Booleano es verdadero OL Booleano es falso booleanToStrinq Esta función convierte un objeto Booleano a un objeto de Cadena. String booleantoString (Boolean) Tipo de Parámetro Valor (Boolean) Booleano para conversión Tipo de Regreso Valor Cadena Cadena Resultante calendarToString Existen dos versiones de esta función. La siguiente función convierte un objeto de Calendario a un objeto de Cadena. String calendarToString (Calendar) Tipo de Parámetro Valor (Calendar) Calendario para conversión Tipo de Regreso Valor Cadena Cadena Resultante La siguiente función convierte un objeto de Calendario a un objeto de Cadena, usando una máscara de formato para formatear el objeto de Cadena.

String calendarToString (Calendar, String) Tipo de Parámetro Valor (Calendar , String) Calendario para conversión, máscara de formato Tipo de Regreso Valor Cadena Cadena Resultante, en el formato especificado por la máscara Ejemplo: Se define un tema de mensaje llamado DatePurchased como un objeto de Calendario. Para otro mensaje, el usuario necesita el valor de DatePurchased en un objeto de Cadena, en el formato M/d/yyyy. El usuario introduciría la función como sigue : calendarToString (MsgDef .DatePurchased, "M/d/yyyy") Si el valor de DatePurchased fuera equivalente a 13 de febrero de 2000, la función regresaría un objeto de Cadena cuyo valor sería "2/13/2000". compareDates Esta función compara dos valores de datos de objeto de Calendario, e indica si la primera fecha es menor que, igual a, o mayor que la segunda fecha. Long compareDates (Calendar, Calendar) Tipo de Parámetro Valor (Calendar, Calendar) Primera fecha a comparar, segunda fecha a comparar Tipo de Regreso Valor Cuando Largo - 1 La primera fecha es menor que la segunda fecha 0 La primera fecha es igual a la segunda fecha La primera fecha es mayor que la segunda fecha doubleToBigDecimal Esta función convierte un objeto Doble a un objeto BigDecimal . BigDecimal doubleToBigDecimal (Double) Tipo de Parámetro Valor (Double) Doble para conversión Tipo de Regreso Valor BigDecimal BigDecimal Resultante doubleToLong Esta función convierte un objeto Doble a un objeto Largo . Long doubleToLong (Double) Tipo de Parámetro Valor (Double) Doble para conversión Tipo de Regreso Valor Largo Largo Resultante doubleToStrina Hay dos versiones de esta función. La siguiente función convierte un objeto Doble a un objeto de Cadena. String doubleToString (Double) Tipo de Parámetro Valor (Double) Doble para conversión Tipo de Regreso Valor Cadena Cadena Resultante La siguiente función convierte un objeto Doble a un objeto de Cadena, usando una máscara de formato para formatear el objeto de Cadena. String doubleToString (Double, String) Tipo de Parámetro Valor (Double , String) Doble para conversión, máscara de formato Tipo de Regreso Valor Cadena Cadena Resultante, en el formato especificado por la máscara Ejemplo: Se define un tema de mensaje llamado Discount como un objeto Doble. Para otro mensaje, el usuario necesita el valor de Discount en un objeto de Cadena, en el formato #.##. El usuario introduciría la función como sigue : doubleToString (MsgDef .Discount, "#.##") Si el valor de Discount fuera 0.04531, la función regresaría un objeto de Cadena cuyo valor sería "0.05". findString Esta función busca un objeto de Cadena adentro de otro objeto de Cadena. Si la función encuentra el objeto de Cadena especificado, ésta regresa la posición del primer carácter de Cadena adentro de la otra Cadena. Long findString (String, String) Tipo de Parámetro Valor (String, String) Cadena a buscar, Cadena a encontrar Tipo de Regreso Valor Cuando Largo Posición del primer Se encontró carácter dentro de la cadena la otra cadena -1 No se encontró la Cadena findWord Esta función busca una palabra adentro de un objeto de Cadena. Si la función encuentra la palabra especificada, ésta regresa la posición del primer carácter de la palabra adentro de la Cadena. La función solamente puede encontrar la palabra en donde ésta esté unida por el espacio en blanco adentro de la cadena. Long findWord (String, String) Tipo de Parámetro Valor (String, String) Cadena a buscar, palabra a encontrar Tipo de Regreso Valor Cuando Largo Posición del primer Se encontró carácter de la palabra la palabra dentro de la Cadena -1 No se encontró la palabra foundString Esta función busca un objeto de Cadena adentro de otro objeto de Cadena, y regresa un objeto Booleano. Boolean foundString (String, String) Tipo de Parámetro Valor (String, String) Cadena a buscar, palabra a encontrar Tipo de Regreso Valor Cuando Booleano Verdadero Se encontró la Cadena Falso No se encontró la Cadena foundWord Esta función busca una palabra adentro de un objeto de Cadena. La función solamente puede encontrar la palabra si ésta está unida por el espacio en blanco adentro de la Cadena. Boolean foundWord (String, String) Tipo de Parámetro Valor (String, String) Cadena a buscar, palabra a encontrar Tipo de Regreso Valor Cuando Booleano Verdadero Se encontró la palabra Falso No se encontró la palabra qetDate Esta función encuentra la fecha en un objeto de Calendario y regresa la fecha como un objeto Entero. Integer getDate (Calendar) Tipo de Parámetro Valor (Calendar) Calendario a leer Tipo de Regreso Valor Entero Entero resultante, de 1 a 31 Ejemplo: Se define un tema de mensaje llamado DatePurchased como un objeto de Calendario. Para otro mensaje, el usuario necesita la fecha del valor de DatePurchased en un objeto Entero. El usuario introduciría la función como sigue: GetDate (MsgDef .DatePurchased) Si el valor de DatePurchased fuera equivalente a 13 de febrero de 2000, la función regresaría un objeto Entero cuyo valor sería 13. getMonth Esta función encuentra el mes en un objeto de Calendario y regresa el mes como un objeto Entero. Integer getMonth (Calendar) Tipo de Parámetro Valor (Calendar) Calendario a leer Tipo de Regreso Valor Entero Entero Resultante, de 1 a 12 Ej emplo : Se define un tema de mensaje llamado DatePurchased como un objeto de Calendario. Para otro mensaje, el usuario necesita el mes del valor de DatePurchased en un objeto Entero. El usuario introduciría la función como sigue: getMonth (MsgDef .DatePurchased) Si el valor de DatePurchased fuera equivalente a 13 de febrero de 2000, la función regresaría un objeto Entero cuyo valor sería 2. qetTokenAt Existen dos versiones de esta función.

La siguiente función analiza sintácticamente un objeto de Cadena en unidades lógicas, encuentra una unidad lógica particular, y regresa la unidad lógica como un objeto de Cadena. La función supone que una coma delimita las unidades lógicas, y deja que el usuario indique la posición de la unidad lógica a regresar. Si la Cadena que se va a analizar sintácticamente contiene un valor nulo, o la posición especificada de la unidad lógica está fuera de rango, la función regresa un valor nulo. String getTokenAt (String, Integer) Tipo de Parámetro Valor (String, Integer) Cadena a analizar sintácticamente, posición de la unidad lógica a encontrar (empezando con 0) Tipo de Regreso Valor Cadena Unidad lógica indicada, o un valor nulo La siguiente función analiza sintácticamente un objeto de Cadena en unidades lógicas, encuentra una unidad lógica particular, y regresa la unidad lógica como un objeto de Cadena. La función deja que el usuario especifique el carácter que delimite las unidades lógicas, y deja que el usuario indique la posición de la unidad lógica a encontrar. Si la Cadena para analizar sintácticamente contiene un valor nulo, o la posición especificada de la unidad lógica está fuera de rango, la función regresa un valor nulo. String getTokenAt (String, String, Integer) Tipo de Parámetro Valor (String, String, Integer) Cadena a analizar sintácticamente, delimitador, posición de la unidad lógica a encontrar (empezando con 0) Tipo de Regreso Valor Cadena Unidad lógica indicada, o un valor nulo Ejemplos: (1) Se define un tema de mensaje llamado Date como un objeto de Cadena que contiene una fecha en el formato M/d/yy. Para otro mensaje, el usuario necesita el mes del valor de Date en un objeto de Cadena. El usuario introduciría la función como sigue: getTokenAt (MsgDef .Date, »/"# 0) Si Date contenía "2/13/00", la función regresaría un objeto de Cadena cuyo valor es "2". (2) Se define un tema de mensaje llamado Date como un objeto de Cadena que contiene una fecha en el formato M .dd.yy. Para otro mensaje, el usuario necesita la fecha del valor de Date en un objeto de Cadena. El usuario introduciría la función como sigue: getTokenAt (MsgDef .Date, "/", D Si Date contenía "02.10.00", la función regresaría un objeto de Cadena cuyo valor es "13". (3) Se define un tema de mensaje llamado Date como un objeto de Cadena que contiene una fecha en el formato M/d/yyyy. Para otro mensaje, el usuario necesita el año del valor de Date en un objeto de Cadena. El usuario introduciría la función como sigue: getTokenAtMonth (MsgDef .Date, "/"» 2) Si Date contenía "2/13/2000", la función regresaría un objeto de Cadena cuyo valor es "2000". getYear Esta función encuentra el año en un objeto de Calendario y regresa el año como un objeto Entero. Integer getYear (Calendar) Tipo de Parámetro Valor (Calendar) Calendario a leer Tipo de Regreso Valor Entero Entero Resultante Ejemplo: Se define un tema de mensaje llamado DatePurchased como un objeto de Calendario. Para otro mensaje, el usuario necesita el año del valor de DatePurchased en un objeto Entero.

El usuario introduciría la función como sigue: getYear (MsgDef .DatePurchased) Si el valor de DatePurchased fuera equivalente a 13 de febrero de 2000, la función regresaría un objeto Entero cuyo valor sería 2000. integerToString Existen dos versiones de esta función. La siguiente función convierte un objeto Entero a un objeto de Cadena. String integerToString (Integer) Tipo de Parámetro Valor (Integer) Entero para convertir Tipo de Regreso Valor Cadena Cadena Resultante La siguiente función convierte un objeto Entero a un objeto de Cadena, usando una máscara de formato para formatear el objeto de Cadena. String integerToString (Integer, String) Tipo de Parámetro Valor ( Integer, String) Entero para convertir, máscara de formato Tipo de Regreso Valor Cadena Cadena Resultante, en el formato especificado por la máscara Ejemplo: Se define un tema de mensaje llamado Quantity como un objeto Entero. Para otro mensaje, el usuario necesita el valor de Quantity en un objeto de Cadena, en el formato #,###. El usuario introduciría la función como sigue: IntegerToString (MsgDef .Quantity, "#,###") Si el valor de Quantity fuera 2540, la función regresaría un objeto de Cadena cuyo valor sería "2,540". isAlpha Esta función determina si todos los caracteres en un objeto de Cadena son alfabéticos, y regresa un objeto Booleano. Boolean isAlpha (String) Tipo de Parámetro Valor (String) Cadena a verificar Tipo de Regreso Valor Cuando Booleano Verdadero Todos los caracteres son alfabéticos Falso No todos los caracteres son alfabéticos isAlphaNumeric Esta función determina si todos los caracteres en un objeto de Cadena son alfanuméricos , y regresa un objeto Booleano .

Boolean isAlphaNumeric (String) Tipo de Parámetro Valor (String) Cadena a verificar Tipo de Regreso Valor Cuando Booleano Verdadero Todos los caracteres son alfanuméricos Falso No todos los caracteres son alfanuméricos isNumeric Esta función determina si todos los caracteres en un objeto de Cadena son numéricos, y regresa un objeto Booleano. Boolean isNumeric (String) Tipo de Parámetro Valor (String) Cadena a verificar Tipo de Regreso Valor Cuando Booleano Verdadero Todos los caracteres son numéricos Falso No todos los caracteres son numéricos iustifvCenter Existen dos versiones de esta función. La siguiente función crea un objeto de Cadena de la longitud indicada por un objeto Entero, y centra un objeto de Cadena adentro de éste. Si la Cadena centrada es más corta que la longitud especificada, la función rellena la Cadena en cada lado con un número igual de espacios . Si la Cadena centrada es más larga que la longitud especificada, la función regresa un valor nulo. String justifyCenter (String, Integer) Tipo de Parámetro Valor (String, Integer) Cadena a centrar, longitud de la Cadena a regresar Tipo de Regreso Valor Cadena Cadena resultante, o un valor nulo La siguiente función crea un objeto de Cadena de la longitud indicada por un objeto Entero, y centra un objeto de Cadena adentro de éste. Si la Cadena centrada es más corta que la longitud especificada, la función rellena la Cadena en cada lado con un número igual de caracteres especificados en otra Cadena . Si la Cadena centrada es más larga que la longitud especificada, la función regresa un valor nulo. String justifyCenter (String, Integer, String) Tipo de Parámetro Valor (String, Integer , String) Cadena a centrar, longitud de la Cadena a regresar, y carácter usado para rellenar la Cadena Tipo de Regreso Valor Cadena Cadena resultante, o un valor nulo Ejemplo: Se define un tema de mensaje llamado Ñame como un objeto de Cadena. Para otro mensaje, el usuario necesita el valor de ame, centrado en un objeto de Cadena de longitud 20, y relleno si es necesario con asteriscos (*) . El usuario introduciría la función como sigue: JustifyCenter (MsgDef .Ñame, 20, "*") Si el valor de Ñame fuera " olfgang A. Mozart", la función regresaría un objeto de Cadena cuyo valor sería "*Wolfgang A. Mozart*" . justifyLeft Existen dos versiones de esta función. La siguiente función crea un objeto de Cadena de la longitud indicada por un objeto Entero, y justifica a la izquierda un objeto de Cadena adentro de éste. Si la Cadena justificada a la izquierda es más corta que la longitud especificada, la función rellena la Cadena con espacios en el lado derecho. Si la Cadena justificada a la izquierda es más larga que la longitud especificada, la función regresa un valor nulo. String justifyLeft (String, Integer) Tipo de Parámetro Valor (String, Integer) Cadena a justificar a la izquierda, longitud de la Cadena a regresar Tipo de Regreso Valor Cadena Cadena resultante, o un valor nulo La siguiente función crea un objeto de Cadena de la longitud indicada por un objeto Entero, y justifica a la izquierda un objeto de Cadena adentro de éste. Si la Cadena justificada a la izquierda es más corta que la longitud especificada, la función rellena la Cadena en el lado derecho con los caracteres especificados en otra Cadena. Si la Cadena justificada a la izquierda es más larga que la longitud especificada, la función regresa un valor nulo. String justifyLeft (String, Integer, String) Tipo de Parámetro Valor (String, Integer, String) Cadena a justificar a la izquierda, longitud de la Cadena a regresar, y carácter a usar para rellenar la Cadena Tipo de Regreso Valor Cadena Cadena resultante, o un valor nulo E emplo : Se define un tema de mensaje llamado ame como un objeto de Cadena. Para otro mensaje, el usuario necesita el valor de ame, justificado a la izquierda en un objeto de Cadena de longitud 20, y relleno si es necesario con espacios. El usuario introduciría la función como sigue: JustifyLeft (MsgDef .Ñame, 20, "*") Si el valor de ame fuera "Franz Shubert", la función regresaría un objeto de Cadena cuyo valor sería "Franz Shubert" . iustifyRiqht Existen dos versiones de esta función. La siguiente función crea un objeto de Cadena de la longitud indicada por un objeto Entero, y justifica a la derecha un objeto de Cadena adentro de éste. Si la Cadena justificada a la derecha es más corta que la longitud especificada, la función rellena la Cadena con espacios en el lado izquierdo. Si la Cadena justificada a la derecha es más larga que la longitud especificada, la función regresa un valor nulo. String justifyRight (String, Integer) Tipo de Parámetro Valor (String, Integer) Cadena a justificar a la derecha, longitud de la Cadena a regresar Tipo de Regreso Valor Cadena Cadena resultante, o un valor nulo La siguiente función crea un objeto de Cadena de la longitud indicada por un objeto Entero, y justifica a la derecha un objeto de Cadena adentro de éste. Si la Cadena justificada a la derecha es más corta que la longitud especificada, la función rellena la Cadena en el lado izquierdo con los caracteres especificados en otra Cadena. Si la Cadena justificada a la derecha es más larga que la longitud especificada, la función regresa un valor nulo. String justifyRight (String, Integer, String) Tipo de Parámetro Valor (String, Integer , String) Cadena a justificar a la derecha, longitud de la Cadena a regresar, y carácter a usar para rellenar la Cadena Tipo de Regreso Valor Cadena Cadena resultante, o un valor nulo Ej emplo : Se define un tema de mensaje llamado Ñame como un objeto de Cadena. Para otro mensaje, el usuario necesita el valor de ame, justificado a la derecha en un objeto de Cadena de longitud 20, y relleno si es necesario con asteriscos (*) . El usuario introduciría la función como sigue: JustifyRight (MsgDef .Ñame, 20, "*") Si el valor de Ñame fuera "Sergei Rachmaninoff " , la función regresaría un objeto de Cadena cuyo valor sería "*Sergei Rachmaninoff " . lonqToBigDecimal Esta función convierte un objeto Largo a un objeto BigDecimal . BigDecimal longToBigDecimal (Long) Tipo de Parámetro Valor (Long) Largo a convertir Tipo de Retorno Valor BigDecimal BigDecimal resultante lonqToBoolean Esta función convierte un objeto Largo a un objeto Booleano . Boolean longToBoolean (Long) Tipo de Parámetro Valor (Long) Largo a convertir Tipo de Retorno Valor Cuando Booleano Verdadero Largo es de cualquier valor diferente de 0 Falso Largo es 0 lonqToDouble Esta función convierte un objeto Largo a un objeto Double . Double longToDouble (Long) Tipo de Parámetro Valor (Long) Largo a convertir Tipo de Retorno Valor Doble Doble resultante longToString Existen dos versiones de esta función. La siguiente función convierte un objeto Largo a un objeto de Cadena. String longToString (Long) Tipo de Parámetro Valor (Long) Largo a convertir Tipo de Retorno Valor Cadena Cadena resultante La siguiente función convierte un objeto Largo a un objeto de Cadena, usando una máscara de formato para formatear el objeto de Cadena. String LongToString (Long, String) Tipo de Parámetro Valor (Long, String) Largo para conversión, máscara de formato Tipo de Regreso Valor Cadena Cadena Resultante, en el formato especificado por la máscara Ejemplo: Se define un tema de mensaje llamado CustID como un objeto Largo. Para otro mensaje, el usuario necesita el valor de CustID en un objeto de Cadena, en el formato ##,###. El usuario introduciría la función como sigue: longToString (MsgDef .CustID, "##,###" Si el valor de CustID fuera 10321, la función regresaría un objeto de Cadena cuyo valor sería "10,321". lookup Existen dos versiones de esta función. La siguiente función busca un objeto de Cadena en una tabla de búsqueda especificada en otro objeto de Cadena, y regresa el valor correspondiente. Si la función no encuentra un valor correspondiente en la tabla de búsqueda, ésta regresa un valor nulo. String looku (String, String) Tipo de Parámetro Valor [String, String) Cadena a buscar, tabla de búsqueda Tipo de Regreso Valor Cadena Valor encontrado en la tabla de búsqueda, o un valor nulo La siguiente función busca un objeto de Cadena en una tabla de búsqueda especificada en otro objeto de Cadena, y regresa el valor correspondiente. Si la función no encuentra un valor correspondiente en la tabla de búsqueda, ésta regresa un valor por omisión, especificado en un tercer objeto de Cadena. String looku (String, String, String) Tipo de Parámetro Valor (String, String, String) Cadena a buscar, tabla de búsqueda, valor por omisión Tipo de Regreso Valor Cadena Valor encontrado en la tabla de búsqueda, o el valor por omisión Ejemplo: Se define un tema de mensaje llamado State como un objeto de Cadena. State siempre contiene una abreviatura de dos letras para el nombre de uno de los tres estados en los Estados Unidos. Para otro mensaje, el usuario necesita el nombre completo del estado en un objeto de Cadena. Si ningún nombre completo corresponde con la abreviatura, el usuario desea que el objeto de Cadena contenga "N/A" . El usuario introduciría la función como sigue. lookup (MsgDef . State, "MD = Maryland, PA = Pennsylvania, VA=Virginia" , "N/A" ) lowercase Esta función convierte todos los caracteres en un objeto de Cadena a letras minúsculas. String lowercase (String) Tipo de Parámetro Valor (String) Cadena a convertir Tipo de Retorno Valor Cadena Cadena resultante replaceString Esta función busca un objeto de Cadena para un objeto de Cadena particular, reemplaza el objeto de Cadena encontrado con un objeto de Cadena de reemplazo, y regresa el objeto de Cadena con la Cadena de reemplazo en su lugar. Si la función no puede encontrar la Cadena a reemplazar, ésta regresa la Cadena que buscó sin cambiarla. String replaceString (String, String, String) Tipo de Parámetro Valor (String, String, String) Cadena a convertir, Cadena de reemplazo, Cadena a buscar Tipo de Retorno Valor Cadena Cadena con Cadena de reemplazo en su lugar Ejemplo : Se define un tema de mensaje llamado Address como un objeto de Cadena. Para direcciones en el estado de Virginia, el valor en Address incluye algunas veces la abreviatura de dos letras VA. Para otro mensaje, el usuario necesita un objeto de Cadena que contenga el valor de Address, pero con el nombre completo del estado sustituido por la abreviatura. El usuario introduciría la función como sigue: replaceString ("VA", "Virginia" , MsgDef .Address) Si el valor de Address fuera "Reston, VA 20191", la función regresaría un objeto de Cadena cuyo valor sería "Reston, Virginia 20191" . replaceWord Esta función busca un objeto de Cadena para una palabra particular, reemplaza la palabra encontrada con otra palabra, y regresa el objeto de Cadena con la palabra de reemplazo en su lugar. La función puede encontrar solamente la palabra especificada adentro del objeto de Cadena si la palabra: (1) está precedida y seguida por espacio en blanco; (2) está justificada adentro del objeto de Cadena, y está seguida por espacio en blanco; y (3) está justificada adentro del objeto de Cadena y precedida por espacio en blanco. Si la función no puede encontrar la palabra, ésta regresa la Cadena que buscó, sin cambiarla. String replaceWord (String, String, String) Tipo de Parámetro Valor (String, String, String) Palabra a reemplazar, palabra de reemplazo, Cadena a buscar Tipo de regreso Valor Cadena Cadena con palabra de reemplazo en el lugar Ej em lo : Se define un tema de mensaje llamado Address como un objeto de Cadena. Para direcciones en el estado de Maryland, el valor en Address incluye algunas veces la abreviatura de dos letras MD. Para otro mensaje, el usuario necesita un objeto de Cadena que contenga el valor de Address, pero con el nombre completo del estado sustituido por la abreviatura. El usuario introduciría la función como sigue: replaceWord ("MD" , "Maryland", MsgDef .Address) Si el valor de Address fuera "Bethesda, MD 20904", la función regresaría un objeto de Cadena cuyo valor sería "Bethesda, Maryland 20904" . sizeOf Existen dos versiones de esta función. La siguiente función determina el tamaño de un objeto de Cadena, y regresa el tamaño como un objeto Largo. Long sizeOf (String) Tipo de Parámetro Valor (String) Cadena cuyo tamaño se va a determinar Tipo de Regreso Valor Largo Tamaño de la Cadena La siguiente función determina el tamaño de un objeto ByteArray, y regresa el tamaño como un objeto Largo. Long sizeOf (ByteArray) Tipo de Parámetro Valor (ByteArray) ByteArray cuyo tamaño se va a determinar Tipo de Regreso Valor Largo Tamaño de ByteArray StringToBigDecimal Esta función convierte un objeto de Cadena a un objeto BigDecimal. BigDecimal stringToBigDecimal (String) Tipo de Parámetro Valor (String) Cadena a convertir Tipo de Regreso Valor BigDecimal BigDecimal resultante stringToBoolean Esta función convierte un objeto de Cadena a un objeto Booleano.

Boolean stringToBoolean (String) Tipo de Parámetro Valor (String) Cadena a convertir Tipo de Regreso Valor Booleano Booleano resultante stringToCalendar Existen dos versiones de esta función. La siguiente función convierte un objeto de Cadena a un objeto de calendario. stringToCalendar (String) Tipo de Parámetro Valor (String) Cadena a convertir Tipo de Regreso Valor Calendario Calendario resultante La siguiente función convierte un objeto de Cadena a un objeto de calendario, usando una máscara de formato para interpretar el objeto de Cadena. Calendar stringToCalendar (String, String) Tipo de Parámetro Valor (String, String) Cadena a convertir, máscara de formato Tipo de Regreso Valor Calendario Calendario resultante Ejemplo: Se define un tema de mensaje llamado DatePurchased como un objeto de Cadena que contiene una fecha en el formato M/d/yy. Para otro mensaje, el usuario necesita el equivalente de Calendario del valor de DatePurchased en un objeto de Calendario. El usuario introduciría la función como sigue: stringToCalendar (MsgDef .DatePurchased, "M/d/yy") Si el valor de DatePurchased fuera "2/13/00", la función regresaría un objeto de Calendario cuyo valor sería el equivalente de 13 de febrero de 2000. stringToDouble Existen dos versiones de esta función. La siguiente función convierte un objeto de Cadena un objeto Doble. Double stringToDouble (String) Tipo de Parámetro Valor (String) Cadena a convertir Tipo - de Regreso Valor Doble Doble resultante La siguiente función convierte un objeto de Cadena un objeto Doble, usando una máscara de formato para interpreta el objeto de Cadena. Double stringToDouble (String, String) Tipo de Parámetro Valor (String, String) Cadena a convertir, máscara de formato Tipo de Regreso Valor Doble Doble resultante Ejemplo: Se define un tema de mensaje llamado TotalCost como un objeto de Cadena que contiene una cantidad en dólares en el formato ##,###,##. Para otro mensaje, el usuario necesita el valor de TotalCost en un objeto Doble. El usuario introduciría la función como sigue: stringToDouble (MsgDef .TotalCost, "##,###,##") Si el valor de TotalCost fuera "5,137.29", la función regresaría un objeto Doble cuyo valor sería 5137.29. stringToInteger Existen dos versiones de esta función. La siguiente función convierte un objeto de Cadena a un objeto Entero. Integer stringToInteger (String) Tipo de Parámetro Valor (String) Cadena a convertir Tipo de Regreso Valor Entero Entero resultante La siguiente función convierte un objeto de Cadena a un objeto Entero, usando una máscara de formato para interpretar el objeto de Cadena. Integer stringToInteger (String, String) Tipo de Parámetro Valor (String, String) Cadena a convertir, máscara de formato Tipo de Regreso Valor Entero Entero resultante Ej em lo : Se define un tema de mensaje llamado Quantity como un objeto de Cadena que contiene una cantidad en el formato #,###. Para otro mensaje, el usuario necesita el valor de Quantity en un objeto de Cadena. El usuario introduciría la función como sigue : stringToInteger (MsgDef . Quantity, "#,###") Si el valor de Quantity fuera "2,540", la función regresaría un objeto Entero cuyo valor sería 2540. stringToLong Existen dos versiones de esta función. La siguiente función convierte un objeto de Cadena un objeto Largo. Long stringToLong (String) Tipo de Parámetro Valor (String) Cadena a convertir Tipo de Regreso Valor Largo Largo resultante La siguiente función convierte un objeto de Cadena un objeto Largo, usando una máscara de formato para interpret. el objeto de Cadena.

Long stringToLong (String, String) Tipo de Parámetro Valor (String, String) Cadena a convertir, máscara de formato Tipo de Regreso Valor Largo Largo resultante Ejemplo: Se define un tema de mensaje llamado CustID como un objeto de Cadena que contiene un número en el formato ##,###. Para otro mensaje, el usuario necesita el valor de CustID en un objeto Largo. El usuario introduciría la función como sigue: stringToLong (MsgDef . CustID, "##,###") Si el valor de CustID fuera "10,321", la función regresaría un objeto Largo cuyo valor sería 10321. subarrav Esta función encuentra un objeto ByteArray adentro de otro objeto ByteArray, y regresa el objeto ByteArray encontrado . Si la función no puede encontrar el ByteArray, ésta regresa un valor nulo. ByteArray subarray (Long, Long, ByteArray) Tipo de Parámetro Valor (Long, Long, ByteArray) Posición del primer byte del ByteArray a encontrar, posición del último byte del ByteArray a encontrar, ByteArray que contiene Bytearray a encontrar; las posiciones empiezan con 0 Tipo de Regreso Valor ByteArray ByteArray que se ha encontrado El tema de mensaje del Ejemplo A llamado Array se define como un objeto ByteArray. Para otro mensaje, el usuario necesita los primeros ocho bytes de Array en un objeto ByteArray. El usuario introduciría la función como sigue: subArray (0, 7, MsgDef .Array) substring Esta función encuentra un objeto de Cadena adentro de otro objeto de Cadena, y regresa el objeto de cadena encontrado . Si la función no puede encontrar la Cadena, ésta regresa un valor nulo. String substring (Long, Long, String) Tipo de Parámetro Valor (Long, Long, String) Posición del primer carácter de la Cadena a encontrar, posición del último carácter de la Cadena a encontrar, Cadena que contiene la Cadena a encontrar Tipo de Regreso Valor Cadena Cadena que se ha encontrado trim Esta función remueve el espacio en blanco de antes y después de un objeto de Cadena. String trim(String) Tipo de Parámetro Valor (String) Objeto de Cadena a partir del cual remover el espacio en blanco Tipo de Retorno Valor Cadena Cadena Resultante uppepcase Esta función convierte todos los caracteres en un objeto de Cadena a letras mayúsculas. String uppercase (String) Tipo de Parámetro Valor (String) Cadena a convertir Tipo de Retorno Valor Cadena Cadena Resultante Los ejemplos que se muestran y describen en la presente no son para limitar el alcance de la invención. De conformidad con lo anterior, para aquellos de experiencia ordinaria en la técnica serán evidentes modificaciones y variaciones de conformidad con la presente invención, sin apartarse del espíritu y alcance de las reivindicaciones anexas.

Claims (32)

REIVINDICACIONES

1. Un sistema para integrar una pluralidad de aplicaciones de computadora, que comprende: un sistema de mensajería de empresa, el sistema de mensajería de empresa pasando mensajes entre las aplicaciones de computadora; un sistema de almacenamiento de base de datos, acoplado al sistema de mensajería de empresa, el sistema de almacenamiento de base de datos almacenando una pluralidad de configuraciones de transformación de datos, y una pluralidad de reglas ; un servicio de integración, acoplado al sistema de mensajería de empresa, el servidor de integración comprendiendo una máquina de transformación de datos que usa las configuraciones de transformación de datos almacenadas en el sistema de almacenamiento de la base de datos, y una máquina de evaluación de reglas que usa las reglas almacenadas en el sistema de almacenamiento de base de datos; una pluralidad de agentes -adaptadores, acoplada al sistema de mensajería de empresa, cada agente -adaptador acoplado a una respectiva de las aplicaciones de computadora, cada agente -adaptador pasando mensajes entre el sistema de mensajería de empresa y la aplicación de computadora respectiva; y un esquema de mensajes que opera en conjunción con dichos agentes-adaptadores para analizar sintácticamente los elementos de mensaje de las aplicaciones de computadora.

2. El sistema, de conformidad con la reivindicación 1, en donde el sistema de servicio de integración divide y combina los mensajes recibidos desde el sistema de mensajería de empresa, y realiza el encaminamiento basado en el contenido, de los mensajes a las aplicaciones de computadora.

3. El sistema, de conformidad con la reivindicación 1, en donde cada uno de los agentes -adaptadores traduce los mensajes que se están pasando del sistema de mensajería de empresa a la aplicación de computadora respectiva, de un formato del sistema a un formato de aplicación de computadora respectiva, y traduce los mensajes que se están pasando de la aplicación de computadora respectiva al sistema de mensajería de empresa, del formato de la aplicación de computadora respectiva al formato del sistema.

4. El sistema, de conformidad con la reivindicación 1, en donde cada uno de dichos agentes -adaptadores pasa mensajes entre otros agentes-adaptadores y la aplicación de computadora respectiva.

5. El sistema, de conformidad con la reivindicación 1, en donde cada uno de los agentes -adaptadores comprende una porción de adaptador y una porción de agente que encapsula dicha porción de adaptador.

6. El sistema, de conformidad con la reivindicación 1, en donde cada uno de los agentes-adaptadores comprende una o más porciones de adaptador, y una porción de agente que encapsula todas de la una o más porciones de adaptador.

7. Un sistema de integración de aplicación de empresa mejorado, que incluye un agente-adaptador para usarse en el mismo, la mejora comprendiendo: un adaptador configurado para una seleccionada de las aplicaciones de empresa; un servicio de agente que hospeda al adaptador; una definición de mensaje para cada uno de la pluralidad de mensajes que el adaptador producirá, recibirá, o responderá ; un elemento para conectar el adaptador a la aplicación de empresa seleccionada; y un elemento para implementar el adaptador a través del elemento de conexión.

8. La mejora, de conformidad con la reivindicación 7, en donde el adaptador se selecciona a partir del grupo que consiste de un adaptador de fuente, un adaptador de objetivo, un adaptador de respuesta, y un adaptador de solicitud.

9. Un método para pasar mensajes entre una primera aplicación de computadora y una segunda aplicación de computadora, que comprende los pasos de: proporcionar un primer mensaje que tiene unos primeros datos a partir de esa primera aplicación de computadora ; publicar el primer mensaje para obtener un primer mensaje publicado; convertir dichos primeros datos del primer mensaje publicado a unos segundos datos, para obtener un segundo mensaj e ; publicar el segundo mensaje para obtener un segundo mensaje publicado; y proporcionar el segundo mensaje publicado a la segunda aplicación de computadora.

10. El método, de conformidad con la reivindicación 9, caracterizado porque además comprende los pasos de: traducir el primer mensaje de un primer formato de aplicación de computadora, a un formato del sistema, antes de publicar el primer mensaje; y traducir el segundo mensaje publicado del formato del sistema a un segundo formato de aplicación de computadora, antes de proporcionar el segundo mensaje publicado a la segunda aplicación de computadora.

11. El método, de conformidad con la reivindicación 9, en donde el paso de convertir los primeros datos comprende: solicitar los segundos datos de una base de datos; y recibir los segundos datos de la base de datos.

12. Un agente-adaptador para usarse en un sistema de integración de aplicación de empresa, que integra una pluralidad de aplicaciones de empresa, que comprende: un adaptador configurado para una seleccionada de las aplicaciones de empresa; un servicio de agente que hospeda al adaptador; una definición de mensaje para cada uno de la pluralidad de mensajes que el adaptador producirá, recibirá, o responderá; un elemento para conectar el adaptador a la aplicación de empresa seleccionada; y un elemento para implementar el adaptador a través del elemento de conexión.

13. El agente-adaptador, de conformidad con la reivindicación 12, en donde el adaptador se selecciona a partir del grupo que consiste de un adaptador de fuente, un adaptador de objetivo, un adaptador de respuesta, y un adaptador de solicitud.

14. El agente-adaptador, de conformidad con la reivindicación 13, en donde el adaptador comprende un adaptador de fuente, y además comprende un elemento para designar seleccionados de una pluralidad de objetivos, el adaptador de fuente está adaptado para enviar uno o más mensajes.

15. El agente-adaptador, de conformidad con la reivindicación 13, en donde el adaptador comprende un adaptador de objetivo, y además comprende un elemento para designar seleccionados de una pluralidad de fuentes, a partir de las cuales el adaptador de objetivo está adaptado para recibir uno o más mensajes.

16. El agente-adaptador, de conformidad con la reivindicación 13, en donde el adaptador comprende un adaptador de respuesta, y además comprende un elemento para designar seleccionados de una pluralidad de solicitantes, a los cuales el adaptador de respuesta está adaptado para enviar uno o más mensajes de respuesta.

17. Un método para pasar mensajes entre una primera aplicación de computadora y una segunda aplicación de computadora, que comprende los pasos de: proporcionar un primer mensaje que tenga unos primeros datos de la primera aplicación de computadora; publicar dicho primer mensaje para obtener un primer mensaje publicado; convertir los primeros datos del primer mensaje publicado, a unos segundos datos para obtener un segundo mensaje ,· publicar el segundo mensaje para obtener un segundo mensaje publicado; y proporcionar el segundo mensaje publicado a la segunda aplicación de computadora.

18. El método, de conformidad con la reivindicación 17, caracterizado porque también comprende los pasos de: traducir el primer mensaje de una primera aplicación de computadora a un formato del sistema, antes de publicar el primer mensaje; y traducir el segundo mensaje publicado del formato del sistema a un formato de la segunda aplicación de computadora, antes de proporcionar el segundo mensaje publicado a la segunda aplicación de computadora.

19. El método, de conformidad con la reivindicación 18, en donde el paso de convertir los primeros datos comprende: solicitar los segundos datos de una base de datos; y recibir los segundos datos de la base de datos.

20. El método, de conformidad con la reivindicación 19, caracterizado porque también comprende los pasos de: proporcionar un adaptador configurado para una seleccionada de dichas aplicaciones de computadora; proporcionar un servicio de agente para hospedar al adaptador; definir una definición de mensaje para cada uno de la pluralidad de mensajes que el adaptador producirá, recibirá, o responderá; y conectar el adaptador a la aplicación de computadora seleccionada .

21. En un sistema de integración de aplicación de empresa que integra una pluralidad de aplicaciones de empresa, cada una de las cuales tiene un formato nativo respectivo para crear, enviar, recibir, almacenar, y procesar una pluralidad de mensajes, la mejora comprendiendo: un agente-adaptador que incluye una pluralidad de adaptadores encapsulados por un agente; en donde cada uno de dicha pluralidad de adaptadores encapsulados por el agente, incluye un elemento para realizar una función discreta mientras está encapsulado por el agente.

22. La mejora, de conformidad con la reivindicación 21, en donde el agente comprende además una pluralidad de objetos incrustados en el mismo, cada uno de la pluralidad de objetos adaptado para realizar una función discreta.

23. La mejora, de conformidad con la reivindicación 22, en donde uno primero de la pluralidad de objetos incrustados en el agente comprende además un elemento para administrar las conexiones del agente-adaptador entre los seleccionados de la pluralidad de aplicaciones de empresa y el sistema .

24. La mejora, de conformidad con la reivindicación 23, en donde uno segundo de dicha pluralidad de objetos incrustados en el agente también comprende un elemento para administrar los errores detectados en el agente-adaptador, entre las seleccionadas de la pluralidad de aplicaciones de empresa y el sistema.

25. La mejora, de conformidad con la reivindicación 23, en donde uno tercero de la pluralidad de objetos incrustados en el agente también comprende un elemento para administrar la transformación de la pluralidad de mensajes adentro del agente-adaptador, entre las seleccionadas de la pluralidad de aplicaciones de empresa y el sistema.

26. La mejora, de conformidad con la reivindicación 22, caracterizada porque también comprende una pluralidad de nodos y una pluralidad de servicios de sistema residentes en dichos nodos .

27. La mejora, de conformidad con la reivindicación 26, en donde el agente también comprende una pluralidad de objetos incrustados en el mismo, cada uno de la pluralidad de objetos adaptado para realizar una función discreta.

28. La mejora, de conformidad con la reivindicación 27, en donde cada uno de la pluralidad de objetos en el agente está adaptado para realizar su función respectiva en cualquiera de la pluralidad de nodos.

29. La mejora, de conformidad con la reivindicación 27, en donde cada uno de la pluralidad de objetos en el agente está adaptado para realizar su función respectiva en conjunción con unos respectivos de los objetos incrustados en otro agente en el sistema.

30. Un sistema para integrar una pluralidad de aplicaciones de computadora, que comprende: un sistema de mensajería de empresa, el sistema de mensajería de empresa pasando mensajes entre las aplicaciones de computadora; un sistema de almacenamiento de base de datos, acoplado a dicho sistema de mensajería de empresa, el sistema de almacenamiento de base de datos almacenando una pluralidad de configuraciones de transformación de datos, y una pluralidad de reglas; un servicio de integración, acoplado al sistema de mensajería de empresa, el servidor de integración comprendiendo una máquina de transformación de datos que usa las configuraciones de transformación de datos almacenadas en el sistema de almacenamiento de la base de datos, y una máquina de evaluación de reglas que usa las reglas almacenadas en el sistema de almacenamiento de base de datos; y una pluralidad de agentes -adaptadores, acoplada al sistema de mensajería de empresa, cada agente-adaptador acoplado a una respectiva de las aplicaciones de computadora, cada agente-adaptador pasando mensajes entre el sistema de mensajería de empresa y la aplicación de computadora respectiva .

31. El sistema, de conformidad con la reivindicación 30, caracterizado porque también comprende: un esquema de mensaje, que incluye una pluralidad de elementos de mensaje; una pluralidad de accesores, cada uno de los cuales está adaptado para una seleccionada de las aplicaciones de computadora; y una pluralidad de convertidores, cada uno de los cuales está adaptado para una seleccionada de las aplicaciones de computadora, y adaptado para acoplarse a unos seleccionados de la pluralidad de accesores; en donde los seleccionados de la pluralidad de elementos de mensaje que corresponden a una de las aplicaciones de computadora, están adaptados para accesarse y convertirse para comunicación con otras de las aplicaciones de computadora.

32. El sistema, de conformidad con la reivindicación 31, en donde la pluralidad de accesores y la pluralidad de convertidores se están distribuidos a lo largo del sistema.