MXPA00012054A - Sistema y metodo para implementar agentes de espacio de trabajo de objeto en un ambiente de soporte de decision - Google Patents

Abstract

Un sistema de computadora para accesar remotamente datos en una colaboración de empresas múltiples que comprende un espacio de trabajo asociado con una primera empresa que tiene una pluralidad de objetos almacenados. El sistema de computadora además comprende un nodo de red asociado con una segunda empresa, el nodo de red estáen comunicación con el espacio de trabajo a través de la red. El sistema de computadora además comprende un agente generado en el nodo ed red, el agente es operable para accesar el espacio de trabajo a través de la red, el agente además es operable para manipular por lo menos uno de la pluralidad de objetos almacenados dentro del espacio de trabajo para llevar a cabo una actividad de colaboración.

Description

SISTEMA Y MÉTODO PARA IMPLEMENTAR AGENTES DE ESPACIO DE TRABAJO DE OBJETO EN UN AMBIENTE DE SOPORTE DE DECISIÓN CAMPO TÉCNICO DE LA INVENCIÓN Esta invención se refiere en general al campo de la cadena de suministro, de empresas y sitio de planeación, y más particularmente a un sistema y a un método para implementar agentes de espacio de trabajo de objeto en un ambiente de soporte de decisión.

ANTECEDENTES DE LA INVENCIÓN Las aplicaciones y los ambientes de cadena de suministro, de empresa y de sitio de planeación son ampliamente usados por las entidades fabricantes para el soporte de decisión y para la ayuda en las operaciones de administración Les ambientes de soporte de decisiór para la cadena de sumnistro, ce la empresa y del sitio de planeación han evolucionado de ambientes monolíticos de dominio único a ambientes monolíticos de dominios múltiples. Las aplicaciones de software de planeación convencionales están disponibles en un amplio rango de productos ofrecidos por varias compañías. Estas herramientas de soporte de decisión permiten a las entidades operaciones de fabricación complejas de administración más eficiente. Sin embargo, las cadenas de suministro están generalmente caracterizadas por ambientes de planeación múltiples, distribuidas y heterogéneos. Por tanto, hay limites a la efectividad de los ambientes convencionales cuando se aplican al problema de la planeación de la cadena de suministro debido a las arquitecturas de aplicación monolíticas. Además, éstos problemas son exacerbados cuando no hay un "propietario" de la cadena de suministro completa.

Es deseable para el siguiente paso evolucionarlo para los ambientes de planeación el establecer una arquitectura heterogénea de dominios múltiples que soporte dominios múltiples de expansión de productos, así como productos y motores múltiples de expansión. La integración de los varios ambientes de planeación en una solución sin costura puede permitir la planeación de cadena de suministro entre empresa y entre dominio. Además, una función importante proporcionada por algunas aplicaciones de planeación es al optimización del ambiente de objeto más bien que el simple-tente las transacciones de seguimiento. En particular, la familia de productos RHYTHM disponible de 12 Technologies proporciona una funcionalidad de optimización. Sin embargo, con respecto a la planeación en el nivel de cadena de suministro de empresa, muchas aplicaciones convencionales, tal como aquellas disponibles de SAP, usan motores de planeación de recurso de empresa (ERP) y no proporcionan la optimización.

El éxito o la falla de una empresa pueden depender en una gran extensión de la calidad de la decisión que se hace dentro de la empresa. Por tanto, el software de soporte de decisión, tal como la familia de productos RHYTH de 12 Technologies, que soporta una decisión óptima dentro de las empresas puede ser particularmente importante para el éxito de la empresa. En general, las decisiones óptimas están relacionadas al dominio del soporte de decisión en donde el dominio es la extensión del "mundo" considerado para llegar a la decisión. Por ejemplo, la decisión que se está haciendo puede ser de que tanto de un artículo dado debe producir una fábrica durante un período de tiempo dado. La respuesta "óptima" dependerá del dominio de la decisión. El dominio puede ser, por ejemplo, justo la fábrica misma, la cadena de suministro que contiene la fábrica, la empresa completa, o la cadena de suministro de empresas múltiples. (Los últimos dos pueden ser considerados como los dominios más grandes o los dominios múltiples). Típicamente, entre más grande el dominio del soporte ce decisión, más óptima será la decisión Consecuentemente, será deseable que el software de soporte de decisión cubra aún dominios más grandes en el proceso de realización de al decisión. Sin embargo, ésta ampliación de la cobertura puede crear problemas significantes.

Uno de tales problemas involucra las limitaciones del presente software de soporte de decisión que no permite entidades remotas en el ambiente de dominio o de dominios múltiples el accesar un espacio de trabajo de objeto local. El software no permite a tales entidades remotas el ejecutar fácilmente tareas administrativas, rutinas de optimización u otras formas de datos y manipulación de objetos en un espacio de trabajo local.

SÍNTESIS DE LA INVENCIÓN De acuerdo con la presente invención, están descritos un sistema y un método para implementar agentes de espacio de trabajo de objeto en un ambiente de soporte de decisión que proporcionan ventajas sobre los ambientes de cadena de suministro, de empresa y de planeación de sitio convencionales De acuerdo a un aspecto de la presente invención, un sistema de computaaora para accesar remotamente datos en una colaboración de empresas múltiples comprende un espacio de trabajo asociado con - a primera empresa q_e tiene una pluralidad de objetos almacenados. El sistema de computadora además comprende un nodo de red asociado con una segunda empresa, el nodo de red está en comunicación con el espacio de trabajo a través de la red. El sistema de computadora además comprende un agente generado en el nodo de red, el agente es operable para accesar el espacio de trabajo a través de la red, el agente además es operable para manipular por lo menos uno de la pluralidad de objetos dentro del espacio de trabajo para llevar a cabo una actividad de colaboración.

Una ventaja técnica de la presente invención es la capacidad de accesar un espacio de trabajo remoto con un agente para satisfacer objetivos programados del agente en ese espacio de trabajo remoto. Una ventaja técnica adicional de la presente invención es la capacidad del agente para llevar a cabo tareas en una primera empresa, nodo o plataforma a pesar de estar iniciado en un segundo nodo, empresa o plataforma con la cual el agente a ha perdido contacto. Una ventaja adicional de la invención es la de que el agente es capaz de comunicar los resultados de las tareas ejecutadas llevadas a cabo en un nodo de destinación de regreso a un nodo originante. Otra ventaja es la de que el agente es operable para ejecutar u operar sobre otros agentes los cuales están residiendo en un espacio de trabajo. Las ventajas técnicas adicionales serán fácilmente evidentes a un experto en el arte de la siguientes figuras, de ias descripciones y de las reivindicaciones BREVE DESCRIPCIÓN DE LOS DIBUJOS Un entendimiento más completo de la presente invención y de las ventajas de la misma pueden adquirirse con referencia a la siguiente descripción tomada en conjunción con los dibujos acompañantes, en los cuales los números de referencia iguales indican características iguales y en donde: La Figura 1 es un diagrama de una incorporación de un arquitectura implementada por computadora que puede soportar la colaboración de empresas.

La Figura 2 es un diagrama de una incorporación de los componentes de un administrador del sistema de colaboración global .

La Figura 3 es un diagrama del administrador del sistema de colaboración global de la Figura 2 en donde ciertos elementos de software que constituyen los módulos particulares están resaltados.

La Figura 4 es un diagrama de bloque de ura incorporación de un sistema que permite la colaboración dentro y entre las empresas para una decisión óptima La Fig-ra 5 es un diagra-ia de bloque de -a incorporación del uso de un espacio de trabajo de colaboración global.

La Figura 6 es un diagrama de una incorporación ae un ciclo de vida para una colaboración La Figura 7 es un diagrama de situaciones en donde el software común está presente sobre ambos lados de una relación y en donde no lo está.

La Figura 8 es un diagrama de bloque de una incorporación de una configuración de seguridad para un caso de eje a radio y de eje a red.

La Figura 9 es un diagrama de bloque de una incorporación de una configuración de seguridad de un caso de eje a eje .

La Figura 10 es un diagrama de una incorporación de un diseño de flujo de trabajo entre empresas que incluye la parameterización sobre grupos.

La Figura 11 es un diagrama de una incorporación del cambio de administración mediante el modificar un diseño de un flujo de trabajo.

La Figura 12 es un diagrama de una incorporación de la integración de un flujo de trabajo con el mundo exterior.

La Figura 13 es un diagrama de una incorporación de un flujo de datos que corre en una actividad única.

La Figura 14 es un diagrama de una incorporación de un flujo de datos dividido a través de actividades múltiples.

La Figura 15 es un diagrama de bloque de una incorporación de un modelo de datos común que está basado sobre el modelo de transformación La Figura 16 es un diagrama de una incorporación de una transformación directa La Figura 17 es un diagrama de una incorporación de diferentes niveles de acceso y transformación La Figura 18 es un diagrama de una incorporación de la sustitución de un motor de eje para un motor de radio dentro de una colaboración La Figura 19 es un diagrama de bloque de una incorporación de un sistema de computadora qae emplea un espacio de trabajo configurado de acuerdo a las ense-anzas de la presente invención La Figura 20 es un diagrama de una incorporación del espacio de trabajo de la Figura 19 corfigurado de acuerdo a las enseñanzas de la presente invención La Figura 21 es un diagrama de bloque de un espacio de computadora usando un agente para accesar un espacio de trabajo de objeto de acuerdo a las enseñanzas de la presente invención; y La Figura 22 es un esquema de flujo que ilustra una incorporación de un método del empleo del agente de la figura 21 para accesar un espacio de trabajo.

DESCRIPCIÓN DETALLADA DE LA INVENCIÓN La mejora de los procesos de soporte de decisión involucra la expansión para proporcionar un soporte de decisión de nivel de multiempresas y de nivel de empresas para una realización de la decisión óptima. Tecnológicamente y conceptualmente, el proporcionar un soporte de decisión de multiempresas o de nivel de empresa difiere de proporcionar soporte de decisión de nivel de fábrica y de nivel de cadena de suministro. Las razones para ésto pueden ser que en las situaciones de dominios rr itip^es (tales como las unidades de negocios dentro de una erpresa o de ercresas múltiples) , los diferentes dominios frecuentemente operan un software de soporte de decisión diferente. También, en las situaciones de dominios múltiples, un dominio generalmente no puede forzar a otro dominio a ser una decisión particular. En otras palabras, el soporte de la decisión óptima en éste ambiente frecuentemente requiere el ser llevado a cabo en un ambiente negociado en oposición a coercitivo.

El proporcionar un soporte de decisión en situaciones de dominios múltiples puede ser logrado para el propósito de un acercamiento de colaboración para el soporte de decisión más bien que uno coercitivo. Varias tecnologías de procesamiento de comunicación y distribuidas pueden ser usadas para implementar tal ambiente, incluyendo el Internet, el Web, JAVA, XML, CORBA, etc., que ayudan a hacer posible la realización de una decisión de colaboración a gran escala. Los productos estarán pronto disponibles de 12 Technologies que permite un acercamiento colaborador para el soporte de decisión incluyendo RHYTHM-GLOBAL COLLABORATION MANAGER (GCM) y RHYTHM-GLOBAL COLLABORATION DESIGNER (GCD) .

El Sistema de Colaboración v los Componentes de Proceso La Figura 1 es un diagrama de una incorporación de una arquitectura mplementaca por computadora que puede sostener la colaboración de empresas Coro se mostró, una arquitectura de soporte de decisión global puede construirse sobre un enlace subyacente, visión, mensaje global y componentes de almacén de información. La colaboración puede entonces involucrar un diseñador de colaboración global (GCD) y un analizador de colaboración global (GCM) soportador por la arquitectura de soporte de decisión. El diseñador de colaboración global puede ser usado para diseñar y para instanciar colaboraciones, y el administrador de colaboración global puede ser usado para correr las colaboraciones. En éste esquema, las colaboraciones pueden ser mencionadas como módulos y pueden ser de versiones.

La Figura 2 es un diagrama de una incorporación de componentes de un administrador del sistema de colaboración global. Como se mostró, el administrador del sistema puede permitir a una empresa eje 2 el colaborar con una empresa radio 4 y una empresa red 6. La empresa eje 2 y la empresa radio 4 cada una incluyen un administrador de colaboración global 8. Los administradores de colaboración global 8 están acoplados y se comunican con los espacios de trabajo de colaboración global internos respectivos 10. Un espacio de trabajo de colaboración global externo 12 proporciona unos medios para compartir datos entre una empresa de eje 2, una empresa radio 4 y una empresa red 6. La empresa eje 2 también puede colaborar a través de un procesador de intercambio de datos electrónico (EDI) 14 con una red agregada de valor (VAN) Además, _a empresa e e 2 puede comunicarse y colaborar con c;ra empresa eje usardo un bus de mensaje global 15.

En la operació-. , el controlador primario de la colaboración puede ser el motor GCM 8 de una empresa eje 2. La relación de eje a eje puede ser facilitada por el bus de mensaje global 15, y las relaciones de eje a radio y de e e a red pueden ser facilitadas por el espacio de trabajo de colaboración global externo (GCW) 12. Como se mostró, una empresa eje 2 puede generalmente tener un espacio de trabajo de colaboración global 10 y un espacio de trabajo de colaboración global externo 12. El espacio de trabajo de colaboración global interno 10 puede ser usado para compartir e intercambiar información con interconexiones de usuario de internet así como con un procesador de intercambio de información electrónica 14. El espacio de trabajo de colaboración global 12 puede ser usado para compartir e intercambiar información con empresas radio 4 y empresas eje.

Por seguridad, el espacio de trabajo de colaboración global externo 12 puede ser instalado en un DM2 o afuera de una pared de fuego corporativa de una empresa eje 2. En ésta manera no hay conexiones directas necesarias que tengan que hacerse desde el exterior a la red corporativa protegida de la empresa eje 2. El espacio de trabajo de colaboración global externo puede aceptar, por ejemplo, conexiones IIOP, HTTP y HTTPS . En particular, las dos ltimas conexiones son útiles para puentear configuraciones de pared de fuego existentes En ésta manera, no es necesaria una configuración de pared de fuego sobre cualesquiera el lado del cliente (nodo de radio o nodo de red) o el servidor (nodo de e e) que puedan hacer la solución más rápidamente desplegable.

La Figura 3 es un diagrama de una red de colaboración global de la Figura 2 en donde ciertos elementos de software que constituyen módulos particulares están resaltados.

Como puede verse, el software para el módulo de administración de colaboración global puede estar presente en los siguientes lugares: en el motor de eje 8, en el motor de radio 8, en la interconexión de usuario de eje-usuario (Ul), en la Ul de radio-usuario y el Ul de red-nodo. Adicionalmente, el módulo puede comunicarse con aplicaciones nativas 17 sobre la empresa eje 2 y la empresa radio 4. Las comunicaciones con las aplicaciones nativas 17 pueden ser ya sea sincrónicas (línea punteada) o asincrónicas (línea sólida) . La comunicación asincrónica con las aplicaciones nativas 17 puede ser facilitada por el espacio de trabajo de colaboración global interno 10, como se mostró. Además, una base de datos de serie global (GSDB) puede estar presente sobre el lado 2 de la empresa eje.

La Figura 4 es un diagrama de bloque de una incorporación de un sistema, indicado generalmente con el número 16, que permite la colaboración entre y a través de .as empresas para una realización de decisión óptima Como se mostró, el sistema 16 incluye un nodo de eje 18 el cual puede ser un proceso dentro de un motor de eje que ejecuta un sistema de computadora. El nodo de eje 18 está acoplado a y se comunica cor. un nodo de radio 20 el cual también puede ser un proceso dentro de un motor de eje que ejecuta sobre un sistema de computadora. Como se mostró, el nodo de radio 20 puede estar afuera de un límite de empresa 22 del nodo de cubo 18. El nodo de cubo 18 también está acoplado a y se comunica con una pluralidad de nodos de radio 24 los cuales pueden ser procesados dentro de un motor de radio que ejecuta uno o más sistemas de computadora. El nodo de cubo 18 puede además estar acoplado a y comunicarse con una pluralidad de nodos de red 26 los cuales pueden ser procesados dentro de un explorador de red que ejecuta sobre un sistema de computadora. Además, el nodo de cubo 18 está acoplado a y se comunica con un representante del EDI (intercambio de datos electrónico) 28 el cual puede proporcionar una compuerta a los sistemas de intercambio de datos electrónicos.

Los motores de eje y los motores de radio, junto con el espacio de trabajo de colaboración global, pueden ser entidades primarias de un admir strador de colaboración global En éste ambiente, un motor de c_bo es el controlador primario de la colaboración. El motor de eje puede coordinar con ambas colaboraciones globales así come con colaboraciones locales. Las colaboraciones globales son ac-ellas que alcanzan nodos de e e 18, nodos de radio 20 y 24 y ncaos de red 26. Una colaooració-local puede correr sobre un papel único cualesquiera grupo de eje o de radio/radio. Estas colaboraciones pueden ser distribuidas, pero permanecer dentro de los ccnfines de una empresa única. Los motores de eje también pueden ser coordinados con las interconexiones de eje-usuario (Ul) así como con el procesador VAN-EDI de un representante de intercambio de datos electrónico 28. En una incorporación, los motores de eje son motores multitejidos que pueden coordinar simultáneamente colaboraciones múltiples así como versiones múltiples de la misma colaboración Además, los motores de eje pueden dinámicamente cargar y ejecutar las colaboraciones.

El motor de radio también puede operar para iniciar una colaboración. En éste ambiente, a diferencia de un motor de eje, un motor de radio no es una entidad independiente. En vez de ésto un motor de radio puede sólo coordinar una colaboración en conjunción con un motor de eje. Además, un motor de radio no puede coordinar con otros motores de radio u otros nodos de red. Como un motor de eje, un motor de radio puede ser multitejido y puede simultáneamente coordinar colaboraciones múltiples así como versiones múltiples de la misma colaboración Los motores de radio también pueden cargar dinámicamente y ejecutar las colaboraciones.

La Figura 5 es un diacra-a de bloque de u-a incorporación del uso de un espacie de traea o de colaboracic-global 30. En la Figura 5, el espacio de trabajo de colaboración global 30 proporciona a la entidad primaria usada para compartir información/objetos entre las varias entidades en la colaboración. Como se mostró, el espacio de trabajo 30 pueae mterconectar con los administradores de colaboración global (GCMs) 32, con un sistema local 34, con un servidor de red 36 y una interconexión de red 37 y aplicaciones nativas 38. En general, los objetos pueden ser colocados en un espacio de trabajo de colaboración global 30 por una entidad y recuperarse por otra entidad. La recuperación puede ser lograda ya sea mediante pregunta o por suscripción. En ésta manera, el espacio de trabajo de colaboración global 30 combina los atributos de una base de datos así como de un bus de mensaje.

El espacio de trabajo de colaboración global puede ser organizado como una jerarquía de ranuras las cuales pueden estar en la memoria o ser persistentes. Las ranuras también pueden estar en cola o regulares, y permisibilidades de grano fino pueden sujetarse a cada ranura. Las permisibilidades pueden ser asignadas por la operación por el usuario. Las operaciones primarias pueden ser leídas, escritas, tomadas y suscritas.

Las ranuras de memoria retienen sus datos en la memoria volátil. La escritura y recuperación de las ranuras de memoria es muy ráp.da pero se somete a la pérdida si e. espacio de trabajo de colaooraciór global 3^ se va hacia abajo Cuando se usó con memorias en ranura, el espacio de traoajo de colaboración global 30 puede ser considerado como una información de base de datos de objeto en memoria segura y rápida, con capacidades de seguridad y de mensaje. Las ranuras persistentes retienen sus datos en el almacenamiento estable. La escritura y recuperación de las ranuras persistentes es más lenta que para las ranuras en memoria, pero los datos no se pierden si el espacio de trabajo de colaboración global 30 se va para abajo.

La decisión de ya sea el usar ranuras en memoria o persistentes puede depender de la aplicación. El espacio de trabajo de colaboración global 30 almacena los datos en la forma de objetos y puede almacenar objetos Java, objetos CORBA, o arreglos de byte arbitrarios. Esto, acoplado con sus capacidades en memoria, hace al espacio de trabajo de colaboración global 30 apropiado como un mecanismo de compartir datos de alta velocidad entre otros motores en memoria orientados por objeto tal como el planificador de cadena de suministro y el planificador de fábrica de 12 Technologies.

Un diseñador de colaboración global (GCD) proporciona una herramienta para permitir la colaboración de diseñadores para interactivamente diseñar, iniciar y desplegar colaboraciones para que se corran usando el administrador de colaboración global. La salida del diseñador de colaboración global es un código que puede ser cargado automáticamente y correrse por el admm-strador de colaboración global El diseñador de colaboración global puede permitir a los diseñadores el crear nuevas colaboraciones, recuperar las colaboraciones existentes, y las colaboraciones de versión El diseñador de colaboración global también puede permitir a los diseñadores el diseñar la red de eje y de radio para colaboraciones y el diseñar los eventos y mensajes para la colaboración. El diseñador de colaboración global puede integrar una biblioteca de objeto estándar y una biblioteca de componente estándar para un uso fácil de desde dentro del diseñador de colaboración global. El diseñador de colaboración global puede ser usado para crear flujos de trabajo de empresas últ.ples sofisticados con sincrónicos, asincrónicos, de sub-flujo de trabajo, y divisiones, o divisiones, sincronización-juntas, divisiones-heterofraguado, uniones heterofraguado, etc. Los flujos de trabajo globales y los flujos de trabajo locales pueden ser creados ambos. El diseñador de colaboración global puede proporcionar la verificación automática de colaboraciones y la generación de código automático, c^yo código se corre por el administrador de colaboración global . ?l código generado puede ser editado manualmente si se desea. además, el diseñador de colaboración global puede proporc.cnar la instalación de una colaboración incluyendo la generación de configuraciones de administrador de seguridad y configuraciones de espacio de trabajo de colaboración global.

La Figura 6 es un dia ra-a de una incorporación de un ciclo de vida para una colaborac-ón. Como se mostró, en el paso, una colaboración puede ser diseñada usando el diseñador de colaboración global Después, en el paso 46, una colaboración puede ser instanciada usando el diseñador de colaboración global. La colaboración mstanciada puede entonces ser desplegada, en el paso 44, usando el diseñador de colaboración global y el administrador de colaboración global. Después del despliegue, la colaboración puede ser corrida usanco el administrador de colaboración global en el paso 46. Subsecuentemente, puede ser creado un nuevo caso o una nueva versión de la colaboración puede ser creada. Para crear un nuevo caso, el flujo regresa al paso 42. Para una nueva versión, el diseñador de colaboración global puede ser usado en el paso 48 para modificar la colaboración.

La extensión desde el soporte de decisión de dominio único al soporte de decisión de dominios múltiples puede ser complicada. En particular, la siguiente discusión describe un número de desafíos presentados por el soporte de decisión de dominios múltiples y las incorporaciones de como éstos desafíos son examinados por el sistema presente y el proceso que permite la colaboración dentro y entre las empresas para una realizacicr. de decisión óptima.

Heterogeneidad Representacional Un problema con la colaboración es el hacer -puente entre las empresas a través de una heterogeneidaa representativa. Antes de que pueda ocurrir una colaboración exitosa, la heterogeneidad de representación a través de las empresas requiere el ser puenteada. Las empresas frecuentemente representan los mismos datos en diferentes maneras. Estas diferencias varían de diferencias semánticas a diferencias tecnológicas, a diferencias en nombres etc. Una solución obvia para puentear éstas diferencias es la estandarización. Sin embargo, ésto hace surgir inmediatamente el asunto de cual es el estándar sobre el que se debe convenir. El presente sistema y el proceso evitan tal requerimiento.

Deberá notarse que puede haber tres categorías relevantes de estándares que requieren ser examinados. Estas tres categorías son estándares de formato, estándares de transporte y estándares semánticos. Los estándares de formato se refieren a los formatos tecnológicos en los cuales son codificados los datos/objetos. Por ejemplo, los ejemplos incluyen XML, Java Serial Streams, IIOP Serial Streams y el formato de información de intercambio de datos electrónico. Los estándares de transporte son usados para pasar datos. Estos pueden incluir HTTP, IIOP, RMI , DCOM, FTP, Redes de Valor Agregado, bus de mensaje asincrónico tales como MQSeries, etc. En tercer lugar, los estándares semánticos son la forma en la cual el contenido semántico ae los dates está descrito. Los ejemplos incluyen el mtercar_e?o de aatos electrónico, 12 modelo de datos común (CDM) .

Mediante el considerar los estándares en ésta luz, un entendimiento de los asuntos puede surgir. Una gran cantidad de la confusión actual se deriva del hecho de que pueden existir estándares que cubren dos o más de las categorías arriba mencionadas y que las discusiones de los varios estándares fallan en categopzar cual es la categoría que está siendo discutida.

Por ejemplo, el intercambio de datos electrónico es primariamente un estándar semántico, pero también típicamente implica un estándar de formato (el formato de expediente de intercambio de datos electrónico) y un transporte (una red de valor agregado) . Una vez que ésto se entiende, se hace claro que el estándar semántico de intercambio de datos electrónico puede ser separado de los otros dos. Por tanto, los objetos de intercambio de datos electrónico semánticos pueden ser codificados en otros formatos tales como Java Serial Streams y pueden pasarse sobre otros estándares de transporte tal como HTTP. Similarmente, el XML es primariamente un estándar de formato que puede ser usado para codificar varios estándares semánticos. Están realizándose los esfuerzos para codificar el intercambio de datos electrónico en XML.

Varios estándares de formato pueden ser soportados por el administrador ae colaboración global actual, incluyenao XML, el formato de intercambio de datos electrónico, las corrientes de serie Java (mencionadas como formato Java y no para confundirse con el lenguaje Java o la plataforma Java) y las corrientes de serie IIOP De éstos, en una incorporación, el formato Java es el formato primario, y el resto son formatos derivados . Debido a que el formato Java puede contener el comportamiento para producir los otros formatos, se ha escogido como el formato primario. Los formatos XML, EDI, y IIOP pueden ser derivados del formato Java.

La Figura 7 es un diagrama de situaciones en donde el programa de computadora común de 12 Technologies está presente sobre ambos lados de una relación en donde no lo está. Como se muestra, por ejemplo, cuando el ADMINISTRADOR DE COLABORACIÓN GLOBAL RHYTHM está sobre ambos lados, nada se ganará mediante el convertir a un formato intermedio. Esto introducirá una ineficiencia innecesaria, y sólo los datos (no los objetos) serían intercambiables, limitando el rango de aplicaciones. Por tanto cuando el mismo programa de computadora está presente sobre ambos lados, los objetos Java ordinarios pueden ser intercambiados directamente. Por otro lado, por ejemplo, cuando el ADMINISTRADOR DE COLABORACIÓN GLOBAL RHYTHM está presente sólo sobre un lado, pueden ser producidos los "objetos" formateados XML o EDI (salida) e interpretados (entrada) .

Con respecto a estándares de transporte, el presente administrador de colaboración global puede soportar una variedad de estándares de transporte incluyendo HTTP, IIOP, y buses de mensaje asincrónico. Mayores detalles son proporcionados abajo con respecto a los tipos de relación de manejo múltiple.

Con respecto a los etándares semánticos, el administrador de colaboración global presente puede soportar primariamente dos estándares semánticos, EDI y RHYTHM-CDM. El intercambio de datos electrónico puede ser soportado debido a que éste es generalmente el estándar semántico más popular. Sin embargo, éste sufre de la desventaja (entre otras) de no proporcionar una cobertura profunda del dominio de planeación. El RHYTHM-CDM, por otro lado, proporciona una cobertura profunda del dominio de planeación y proporcionará construcciones apropiadas para llevar a cabo un soporte de decisión de empresas múltiples. Adicionalmente, éste formato está soportado por todos los motores de planeación 12 Technologies.

En general, un problema con los estándares públicos, tal como el de intercambio de datos electrónico, es el de que éstos no pueden cubrir adecuadamente las clases de datos/objetos que las empresas desearían intercambiar. Además, el esperar que los cuerpos de estándares se estandaricen sobre un objeto particular puede no ser una opción, y una cadena de suministro no tendrá ninguna ventaja competitiva particular mediante el -sar estándares públicos. Por éstas y otras razones, el admir.strador de colaboración global presente soporta un acercamiento alterno a la estandarización mediante el soportar estándares de comunidad propietarios. Por ejemplo, usando el RHYTHM-GCD, una comunidad de empresas puede diseñar un juego de estándares que son relevantes a sólo ésa comunidad. El RHYTHM-GCM soportará y hará cumplir éstos estándares de comunidad propietarios. El RHYTHM-GCD también sostiene una biblioteca de objetos de bloque de construcción que pueden estar compuestos en estándares de comunidad propietarios. Los estándares de comunidad propietarios tiene un número de avances, incluyendo: éstos pueden ser diseñados para cubrir exactamente las clases de datos/objetos que las empresas desearían intercambiar; sólo las partes relevantes requieren el estar de acuerdo sobre el estándar particular, por tanto el proceso será más rápido que el esperar por un cuerpo estándar; los diferentes estándares pueden ser desarrollados para diferentes categorías de socios y, en el caso extremo, un estándar diferente para cada socio; y pueden ser desarrollados estándares que dan a la cadena de suministro una ventaja competitiva sobre los competidores.

Tipos de Relación Múltiples Otro problema para permitir la colaboración es el manejo de tipos de relación múltiples. Las empresas tienen relaciones de varios tipos con sus socios. Algunas formas de relaciones que pueden variar son. entre los socios de comercie principales por un laao y entre los socios de comercio menores por el otro; entre las empresas de aproximadamente una igual influencia sobre la cadena de suministro y entre empresas de influencia desigual sobre la cadena de suministro; y entre las empresas con un alto grado de sofistificación tecnológica por el otro lado y entre empresas con un grado desigual de sofistificación tecnológica por el otro. Como deberá entenderse, éstos tipos de relaciones diferentes deben ser manejados en forma diferente .

El presente administrador de colaboración global puede modelar las relaciones de empresas como una red de eje y radio, como se describió arriba y se muestra en la Figura 4. En ésta incorporación, los cuatro tipos de relaciones son de eje a red; de eje a -VAN- intercambio de datos electrónico; de eje a radio y de eje a eje. Cada tipo de relación tiene su uso apropiado.

Con respecto al eje a red, cuando la gente habla hoy de "E-Comercio" , frecuentemente implican una arquitectura en donde el explorador de la red habla a algún servidor centralizado. Esta arquitectura tiene algunas ventajas: la infraestructura para el soporte de ésta arquitectura está ya típicamente en el lugar; y toda la administración puede ser centralizada sobre el lado del servidor. Sin embargo, ésta arquitectura también tiene una gran desventaja en el sentido de que requiere la presencia de un humano sobre el lado del explorador de la red. Por tanto, la autcnatización de sistema a sistema no es posible. Basándose sobre éstas ventajas y desventajas, éste tipo de relación puede apreciarse cuando una empresa requiere el intercambiar información con ya sea un socio menor o un socio con menos sofisticación tecnológica.

Con respecto a eje-a-VAN-mtercambio de datos electrónicos, la gran mayoría del comercio entre empresas electrónico tiene lugar hoy por medio de enviar intercambio de datos electrónicos sobre redes de calor agregado. La ventaja de éste acercamiento puede ser que la integración de sistema a sistema sea posible y que estés sostenida actualmente el día de hoy. Las desventajas de éste acercamiento son: los grandes costos para enviar datos sobre VAN's propietarias; los altos costos administrativos debido a la falta de una verdadera estandarización; el requerimiento de herramientas de terceras personas justo para convertir del verdadero "estándar" a una forma apropiada para la empresa; no hay soporte para la integración de sistema-a-humano; y no hay soporte para estándares propietarios o estándares corporativos. Basándose sobre éstas y otras ventajas y desventajas, éste tipo de relación puede ser apropiado cuando se soporta un ambiente de legado VAN- intercambio de datos electrónico.

Con respecto al e e-a-radio, éste tipo de relación también permite una integración de sistema a sistema como el VA?-mtercambio de datos electrónico. Arquitectónicamente el eje a radio es una colaboración entre un motor de eje y un motor de radio. La relación de eje a radio puede tener las ventajas de VAN- intercambio de datos electrónico; ésta puede usar el internet público para reducir los costos de red; los costos administrativos son mucho más bajos que los de VAN- intercambio de datos eletrónico debido a que una gran parte de la infraestructura de red de e e a radio puede mostrarse centralmente y ser administrada; los verdaderos objetos (en adición a sólo la información) pueden ser intercambiados permitiendo mucho más avanzadas colaboraciones; y los estándares semánticos múltiples pueden ser soportados incluyendo el intercambio de datos electrónico, 12 -modelo de datos común y los estándares de comunidad propietaria. Basándose sobre las características arriba mencionadas, la relación de e e a radio puede ser apropiada cuando las empresas que desean llevar a cabo una colaboración de sistema a sistema sofisticada. También puede ser apropiado en donde no está presente un programa de software de 12 Technologies en cualesquiera de las empresas. Esto se debe a la relación de eje a radio que puede ser desplegada centralmente por la empresa de eje.

Con respecto al e e a e e, la relación es similar a la de e e a radio excepto porque tiene lugar entre los dos motores de eje más bien que un motor de eje y uno de radio Debido a ésta característica, la relación de e e a eje puede ser apropiada entre empresas que desean el llevar a cabo una colaboración de sistema a sistema sofisticada. Además, la relación de eje a e e puede ser apropiada cuando dos empresas tienen un RHYTHM-GCM comprado separadamente y han puesto sus motores de eje.

Hay diferencias entre los motores de eje y los motores de radio. En general, unas capacidades de motores de eje son sobrepuestas de unas capacidades de motor de radio. La siguiente Tabla proporciona un ejemplo de algunas de las diferencias .

TABLA 1 Seguridad Un prob.ema ad_e?onal cc- -na colaboración es el desafío de proporcionar una seguridad comprensiva.

Antes de que las empresas puedan colaborar efectivamente, necesita examinarse el asunto de la seguridad Hay muchas facetas diferentes para la segundad en un contexto de colaboración Un administrador del sistema de colaboración de empresas múltiples cualesquiera debe de referirse a todas éstas facetas diferentes. Los requerimiento para una red de seguridad colaborativa puede incluir que: intercambio de datos entre los dos socios deba ser sólo visto por los dos socios; que los datos intercambiados entre los dos socios deban ser a prueba de invasión,- una empresa debe ser capaz de verificar que un socio es quien dice que lo sea; el administrador del sistema no debe introducir nuevos agujeros de seguridad en la red de los socios,-y el administrador del sistema debe ser relativamente fácil de poner y de administrar.

Un administrador del sistema de colaboración de seguridad puede ser proporcionado mediante el implementar una estrategia de seguridad comprensiva para referirse a los requerimientos arriba mencionados. En una incorporación, la estrategia tiene tres aspectos diferentes para ésto: segundad tecnológica, un sistema de permisibilidad y división de datos.

La segundad tecnológica puede referirse a les medios tecnológicos usados para garantizar la segundad Esta seguridad puede ser usada para proporcionar: privada, verificación, e integridad de información. La privacía asegura que ninguna persona no autorizada pueda ver los datos. La autenticación involucra el autenticar que las partes en la colaboración son realmente quienes ellos reclaman ser. La integridad de datos involucra el hacer imposible para una persona no autorizada el modificar los datos que están siendo enviados en cualesquier forma.

El acercamiento de seguridad preciso puede variar basándose sobre el tipo de relación descrito anteriormente. Por ejemplo, un esquema está detallado en la Tabla que sigue abajo: TABLA Como puede verse de la Tabla, todos los tipos de relación, con la excepción de el eje-a-VAN EDI, pueden soportar la seguridad desde SSL 3.0.

El SSL 3.0 es un protocolo estándar de industria usado para soportar la codificación clave pública sobre una conexión de base de socket y proporciona: ppvacía, certificación de cliente así como de servidor, integridad de datos y manejo certificado. El SSL 3.0 es un protocolo de nivel superior en el cual varios algoritmos criptográficos de clave pública pueden ser conectados incluyendo RSA y Diffíe-Helman.

Una vez que el saludo SSL es completado, el siguiente paso es la autenticación de la palabra clave del nombre del usuario. Esto proporciona una certificación más allá de lo que proporciona el SSL 3.0 mismo. Las claves pueden ser almacenadas usando codificación a base de palabras clave P CS5 (una norma RSA) . Una vez que un usuario o radio es certificado, éste se regresa a una muestra de acceso. Esta muestra de acceso tiene una vida de tiempo especificable por el administrador. Un usuario puede entonces tener acceso al sistema por la duración de la validez de la muestra de acceso. Esto tiene el efecto benéfico de no requerir certificación para cada acceso. Cada aplicación la cual es accesada, certifica la muestra de acceso mediante la validación de la firma (la cual es ur resume-i codificado usando la clave privada del administrador ae seguridad) del administrador de dicha seguridad.

El administrador del sistema de seguridad tecnológica es una parte del esquema de seguridad. La otra parte tiene que ver con el diseño de las colaboraciones mismas. El administrador del sistema debe permitir a las empresas el dar fácilmente permisos a vanas acciones que otras empresas pueden llevar a cabo. El espacio de trabajo de colaboración global puede soportar un modelo de permiso jerárquico con los permisos individuales unidos a diferentes elementos de datos en la jerarquía. En particular, ésta puede soportar permisos de leer, escribir, tomar y suscribir de usuario específico y de hablante específico. Por tanto, las empresas pueden afinar detalladamente quien puede leer y que datos, quien puede escribir que datos, quien puede tomar que datos y quien puede suscribir para escribir notificaciones sobre que datos.

Un tercer elemento en la estrategia de segundad del administrador del sistema de colaboración es la capacidad de que la división de datos a través de varios espacios de trabajo de colaboración. En particular, los espacios de trabajo colaboradores son divididos en un espacio de trabajo colaborador interno y un espacio de trabajo colaborador externo. Sólo los datos que requieren el ser verdaderamente compartidos con los socios están en el espacio de trabajo colaoorador externo. El resto está en el espacio de trabajo colaoorador interno El espacio de trabajo colaborador externo está diseñado para asentarse ya sea afuera de la pared de fuego corporativa o en una extrared o DMZ . El diseño de administrador del sistema de colaboración no requiere el espacio de trabajo colaborador externo para hacer decisiones a través de la pared de fuego corporativa en el Intranet (aún cuando lo podría hacer) .

En una incorporación, las colaboraciones globales pueden usar ambos los espacios de trabajo colaboradores externo e interno. Las colaboraciones locales pueden usar sólo el espacio de trabajo colaborador interno y son por tanto invisibles a las empresas socias. Aún para los colaboraciones globales sólo las partes relevantes usan el espacio de trabajo colaborador externo. Además, debido al administrador del sistema de trabajo de permisibilidad descrito anteriormente, cada empresa socia puede sólo ver (leer, escribir, tomar, suscribir) sus propios datos .

La Figura 8 es un diagrama de bloque de una incorporación de una configuración de seguridad para un caso de eje a radio y de eje a red. Como se mostró, una empresa eje 50 está acoplada a y se comunica con un espacio de trabajo de colaboración global interno 52 y un espacio de trabajo de colaboración global externo 54. Una empresa radio 56 y una empresa red 58 se conectan a través de un servidor de red 60 a un espacio de trabajo de colaboración global externo 54 La empresa red 56, como la empresa eje 50, tiene un espacio de trabajo de colaboración global interno 62. Las empresas 50, 56 y 58 pueden ser protegidas por cortafuegos asociados, mientras que la extrared formada por el servidor de red 60 y el espacio de trabajo de colaboración global externo 54 pueden ser protegidos por un director de filtrado y la comunicación a través de HTTP sobre SSL 3.0.

La Figura 9 es un diagrama de bloque de una incorporación de una configuración de seguridad para un caso de eje a eje. Como se mostró, una empresa de eje 64 y una empresa de eje 66 pueden comunicarse a través de una conexión TCP/IP protegida SSL 3.0. La comunicación puede ser entre los agentes de mensaje globales 68 y 69. Ambas empresas de e e 64 y 66 están protegidas por un cortafuego, como se mostró.

Flujos de Trabajo Entre Empresas Uno de los problemas con el soporte de decisiones de empresas múltiples puede ser que no haya una colaboración de circuito cerrado. En vez de éste, los datos pueden ser lanzados de una empresa a la siguiente sin un flujo de trabajo coherente. A fin de implementar una colaboración de circuito cerrado, es necesario el soporte para crear flujos de trabajo de empresas múltiples. El presente administrador y diseñador de colaboración global hace posible el construir, desplegar, vigilar y camelar flujos de trabajo de empresas múltiples sofisticadas.

En general, un "flujo de trabajo" puede ser un juego de "actividades" unidas juntas por flujos de datos que juntos logran alguna tarea. Los flujos de trabajo son ejecutados típicamente sobre motores de flujo de trabajo. Un "flujo de trabajo distribuido" puede referirse a un flujo de trabajo que es ejecutado sobre motores de flujo de trabajo múltiples. En otras palabras, diferentes partes del flujo de trabajo se ejecutan sobre máquinas o motores diferentes. Un "nodo" puede referirse a las entidades abstractas sobre las cuales corren diferentes motores de flujo de trabajo de una corrida de flujo de trabajo distribuida y un "grupo nodo" puede ser un juego de nodos agrupados por algunas características. Un "flujo de trabajo distribuido de empresas múltiples" puede ser flujos de trabajo distribuidos en donde los nodos son empresas.

La parameterización de los flujos de trabajo puede ser importante para la colaboración de las empresas. Un "flujo de trabajo paramétrico" es un flujo de trabajo que está parametepzado sobre varias variables y puede ser regular o distribuido. El instanciar el flujo de trabajo paramétrico con diferentes valores de las variables de parámetro produce diferentes instancias del flujo de trabajo. Una "flujo de trabajo distribuido parametizado sobre noaos en un grupo nodo" puede referirse a flujos de trabajo aistribuidos de los parámetros del flujo de trabajo son los ncdos en un grupo nodo Por tanto, cuando el flujo de trabajo es mstanciado éste es confeccionado a un nodo particular en un grupo nodo.

Hay varias características importantes para los flujos de trabajo que puedan ser soportados por la colaboración global presente. Estos flujos de trabajo pueden ser tipificados fuertemente. La tipificación fuerte ser esencial para producir flujos de trabajo libres de error y robustos. En esencia, la tipificación fuerte garantiza el tipo de un mensaje en u tiempo de diseño. Por ejemplo, si el flujo de trabajo está diseñado para enviar una cuenta de materiales, entonces la tipificación fuerte asegura que sea físicamente imposible el que un objeto distinto a una cuenta de materiales se envíe. Para un flujo de trabajo diseñad con el diseñador de colaboración global y ejecutado con el administrador de colaboración global, éste puede hacer imposible el aún enviar un objeto de un tipo incorrecto. Esta capacidad es importante para producir flujos de trabajo libres de error y robustos.

A pesar de la tipificación fuerte hay, por ejemplo, dos escenarios en los cuales los tipos de objetos incorrectos serían concebiblemente pasados en el flujo de trabajo: debido a un error de la parte del diseñador del flujo de trabajo; y a un intento malicioso de alguien para perjudicar el flujo de trabajo. Ambos de éstos escenarios pueden ser manejados. El primero puede ser manejado mediante el hacer imposible que un error en diseño lleve a tal escenario. El segundo puede ser manejado mediante el hacer que los datos fluyan a prueba de violación mediante el usar una codificación clave pública u otro esquema de codificación (integridad característica) como se describió arriba.

Otra característica importante es el soporte para los flujos de trabajo parameterizados sobre los grupos. Algunos flujos de trabajo de empresas múltiples involucran un gran número de empresas. En tales casos, sería impráctico el crear flujos de trabajo individualizados para cada socio. En vez de ésto puede ser ventajoso el crear flujos de trabajo que sean parameterizados sobre grupos de socios. Por ejemplo, en el campo de la procuración, dos grupos pueden ser los proveedores primarios y los proveedores secundarios . El grupo proveedor primario puede tener un tipo de flujo de trabajo y el grupo de proveedores secundarios pueden tener otro tipo de flujo de trabajo. Los flujos de trabajo a base de grupos pueden ser paramétricos en el sentido de que al tiempo corrido, un flujo de trabajo actual puede ser creado específico para un miembro de un grupo.

En el contexto de empresas múltiples, una empresa puede colaborar, por ejemplo, con cientos o miles potencialmente de otras empresas. Cada colaooración o flujo de trabajo de empresas múltiples puede ser poter.cialmente (y típicamente) único. Sin embargo, el diseñe de miles de flujo de trabajo especializados con socios de empresas ni es deseable ni posible. Por otro lado, muchos de éstos flujos de trabajo son simplemente variaciones paramétricas sobre _JI flujo de trabajo parametepzado subyacente. Por ejemplo, una compañía A puede ser colaboradora (en las ventas) con los detallistas, distribuidores, ventas directas etc. Por tanto, hace sentido el agrupar los varios socios. Un agrupamiento de ejemplo puede ser: WalMart, Sears; el resto de los detallistas además de WalMart y de Sears (grupo) ; distribuidores primarios (grupo) y distribuidores secundarios (grupo) ; ahora, los flujos de trabajo con todos los miembros, por ejemplo, del grupo de distribuidores primarios son variaciones sobre un flujo de trabajo distribuido paramétrico subyacente, parameterizado sobre el distribuidor particular en ése grupo.

Los flujos de trabajo parameterizados sobre grupos pueden soportarse mediante una técnica de definición de flujo de trabajo de HETEROCASTING. La técnica de definición HETEROCASTING generalmente involucra el usar una definición de flujo de trabajo con parámetros para iniciar flujo de trabajo heterogéneos basados sobre diferencias en los parámetros. Por tanto, la técnica de definición HETEROCASTING permite un flujo de trabajo distribuido no en parámetros para ser fácilmente hecho (a través de una herramienta de diseño visual) con parámetros sobre nodos en un grupo ae nodo. Puede haber dos actividades de flujo de trabajo primarias usadas para lograr ésta def_-??c?ón una actividaa dividida HETEROCAST y una actividad unida HETREOCAST. Todas las actividades entre dividido HETEROCAST y unido HETEROCAST son puestas en parámetros sobre los nodos de un grupo de nodo a les que corresponden éstas actividades.

La Figura 10 es un diagrama de una incorporación del diseño de un flujo de trabajo entre empresas que incluye el poner parámetros sobre grupos. Como se mostró, el flujo de trabajo puede comenzar con una actividad de escucha 70 que espera algún evento. La actividad 70 puede ser enlazada a las actividades paralelas 71 que enlazan a un sub-flujo de trabajo 72 y a una división de HTEROCAST 73. El sub-flujo de trabajo mismo puede incluir una definición de flujo de trabajo. Con respecto a HETEROCASTING, el flujo de trabajo después de la división heterocast 73 se hace con parámetros. Por tanto, en el ejemplo de la Figura 10, la actividad 74 es una actividad con parámetros. Después de la actividad 74, un heterocast unido 75 recibe el flujo de la actividad 74. El sub-flujo de trabajo 72 y el heterocast unido 75 son enlazados a una unión sincrónica o asincrónica 76 la cual, a su vez, enlaza a un evento integrado 77 (por ejemplo, multireparto) . Un tipo de flujo de trabajo de la Figura 10 puede ser diseñado usando el diseñador de colaboración global presente y puede permitir una representación completa del flujo de trabajo para el soporte de decisión entre empresas. Este flujo de trabajo pueae entonces ser mstanciado e implementado a través del administrador de colaboración global presente.

La Figura 11 es un diagrama de una incorporación del cambio de administración mediante el modificar un diseño de un flujo de trabajo. Como se mostró, un diseño de flujo de trabajo inicial puede tener un evento 70 enlazado a una división de actividad paralela 71. Entre al división de actividad 71 y una unión 76 puede haber por ejemplo, dos actividades 78. Este flujo de trabajo, una vez diseñado, puede ser instanciado e implementado usando el administrador de colaboración global . Si requiere hacerse un cambio al flujo de trabajo, el diseñador de colaboración global alivia grandemente el problema de hacer el cambio. Por ejemplo, una nueva actividad 79 puede ser agregada entre la división 71 y la unión 76. El flujo de trabajo puede entonces ser remstanciado e implementado centralmente.

En particular, la técnica HETEROCAST puede permitir la construcción de flujos de trabajo distribuidos y en parámetros sobre nodos en un grupo de nodo. Esto puede permitir una ganancia de productividad enorme sobre el diseño de flujos de trabajo individuales para miembros de grupos individuales.

Además, ésta técnica hace un diseño rápido y un prototipo de flujos de trabajo de entre empresas sofisticados con cientos o miles de socios posibles. La técnica debe ser distinguida del "multireparto" convencional en el cual mensajes idénticos son enviados a los varios nodos (socios) En esencia, el multireparto permite a una persona el diseñar un flujo de trabajo único que corre idénticamente a través de nodos múltiples. Esto difiere de la técnica del heteroreparto, en donde los flujos de trabajo corren diferentemente basándose sobre que nodo están éstos corriendo.

Una tercera característica importante es el soporte para los flujos de trabajo a base de reparto. Los flujos de trabajo basados en el reparto permiten que dichos flujos de trabajo sean usados específicamente para repartos genéricos. Esta capacidad permite la creación de flujos de trabajo genéricos o templados que pueden ser instanciados en varios escenarios. Por ejemplo, los tipos de papeles o reparto pueden ser: papeles de socios, papeles de ejes; papeles de grupo de radio; papeles de red; papeles de grupo de red; papeles de usuario. Como un ejemplo de los papeles o repartos, los papeles de socios se refieren a los diferentes papeles o caracteres jugados por los socios. Por tanto, un papel de socio en el caso de la procuración es el de proveedor primario y de proveedor secundario.

Los flujos de trabajo a base de reparto pueden llevar al concepto de tres diferentes fases en el diseño y ejecución de un flujo de trabajo. La fase de diseño es la fase en la cual los flujos de trabajo a base de reparto son definidos. La fase de la instancia es la fase en la cual los repartos son mapeados a instancias. Por ejemplo, el proveedor primario puede ser mapeado a una primera compañía, y el aprobador PO puede ser mapeado a John Doe. En tercer lugar, la fase de tiempo de corrida puede ser la fase en la cual el flujo de trabajo en instancia corre.

Una característica importante adicional es la integración de flujos de trabajo automatizados con flujos de trabajo orientados por el usuario. Los flujos de trabajo pueden frecuentemente ser descritos como que tienen dos variedades: los flujos de trabajo de sistema a sistema automatizados, y los flujos de trabajo de interconexión de usuario. Aún cuando hay flujos de trabajo que son completamente automatizados, y hay flujos de trabajo que son completamente impulsados por el usuario, la mayoría de los flujos de trabajo tienen elementos de interconexión automatizados así como de interconexión de usuario. La colaboración global presente de administrador y diseñador no requiere el hacer ésta distinción artificial entre los tipos de flujo de trabajo. Por tanto, los flujos de trabajo pueden ser automatizados en partes e interactuar con los usuarios en otras partes. Ambas las partes automatizadas y las partes de usuario pueden abarcar empresas múltiples.

Integración con el Mundo Exterior La Figura 12 es un diagrama de una incorporación de la integración de un flujo de trabajo con el mundo exterior. Como se describió en la sección previa, pueden ser cerrados los flujos de trabajo ínter e intra empresas. Estos flujos de trabajo pueden ser compuestos de actividades insertadas juntas en varias configuraciones. No hay una restricción sobre que diferentes actividades del flujo de trabajo pueden hacerlo, pero una de las tareas principales de éstas actividades es el de integrarse con el mundo exterior. La Figura 12 muestra como un flujo de trabajo puede ser integrado con el mundo exterior usando un acercamiento a base de componentes para la integración. Los componentes pueden incluir los accesorios 80, las transformaciones 82, los objetos de transferencia 84, los adaptadores y los flujos 86.

El administrador de colaboración global puede soportar un modelo de integración a base de componente. El modelo de integración a base de componente permite la flexibilidad en estructurar la integración. Puede haber dos tipos de componentes: componentes primitivos y componentes compuestos. Los componentes primitivos pueden incluir accesorios 80, los transformadores 82 y los objetos de transferencia 84. Los componentes compuestos incluyen los adaptadores y los flujos 86. Los componentes compuestos son construidos en términos de componentes primitivos. En éste esquema, los accesorios 80 son usados para accesar una fuente externa tal como un SCP (PLANIFICADOR DE CADENA DE SUMINISTRO) , un SAP, una base de datos relativa, servidores de red, E-correo electrónico, buses de mensajes etc. Los accesorios 80 pueden ser usados para leer, escribir o escuchar a las fuentes y destinos de los datos. Los transformadores 82 pueden ser usados para transformar datos de una forma a otra forma. Los objetos de transferencia 84 son objetos que pueden ser pasados de una actividad a otra actividad o de empresa a empresa. Los objetos de transferencia 84 pueden ser convertibles opcionalmente a estructuras EDI, XML, CORBA, etc. Los accesorios 80 y los transformadores 82 pueden ser insertados juntos para formar flujos. Un flujo completo puede ser ejecutado en una actividad única como se mostró en la Figura 13.

La Figura 13 es un diagrama de una incorporación de un flujo de datos que corre en una actividad única 92. Como se mostró, una fuente de datos 90 puede ser accesible desde y proporcionar datos a un componente de accesor 94. El componente accesor 94 entonces puede pasar datos a través de los componentes de transformador 96 y 98 los cuales proporcionan los datos a un segundo componente accesor 100. Los datos pueden entonces ser almacenados en un destino de datos 102.

La Figura 14 es un diagrama de una incorporación de un flujo de datos dividido a través de actividades múltiples 104 y 106. Como se mostró, el flujo de la Figura 14 difiere de aquel de la Figura 13 en el sentido de que los componentes de transformador 96 y 98 están dentro de actividades separadas 104 y 106 y se comunican mediante un objeto de transferencia. Los flujos de datos de empresas múltiples pueden estar basados sobre el modelo de la Figura 14 más bien que sobre aquel de la Figura 13.

Con respecto a las transformaciones, en una incorporación, pueden ser soportados dos tipos de transformación fundamentales: transformaciones a base de I2-CDM y transformaciones directas. Las transformaciones a base de I2-CDM están basadas sobre el modelo de datos comunes de la tecnología 12 (CDM) . El modelo de datos común es un esquema abstracto que está disponible en ambas formas racional y objeto.

La Figura 15 es un diagrama de bloque de una incorporación de un modelo de transformación a base de 12 -CDM. Como se mostró, los transformadores y accesores pueden ser acoplados para transformar unos datos de aplicación en un objeto de datos de modelo de datos común 110 y vice versa. Por ejemplo, un objeto PLANEADOR DE CADENA DE SUMINISTRO (SCP) puede ser creado mediante un accesor de planeador de cadena de suministro desde los datos de planeador de cadena de suministro 114. Un objeto planeador de cadena de suministro 112 puede entonces ser transformado mediante un transformador planeador de cadena de suministro-modelo de datos común en un objeto de modelo de datos común 110. En forma análoga, un objeto SAP 116 puede ser creaao por un accesor SAP desde los datos SAP 118. El objeto SAP 116 puede entonces ser transformado mediante un transformador SAP-planeado de cadena de suministro en un objeto de modelo de datos común 110. El accesor SAP y el transformador, como con otros accesores y transformadores puede ser combinado en un adaptador SAP-modelo de datos común estándar 120 que puede ser usado para las transformaciones a base de modelo de datos común de otros componentes. Como otro ejemplo, un objeto BAAN 122 puede ser creado por un accesor BAAN de los datos BAAN 124. Un objeto BAAN 122 puede entonces ser transformado en un objeto CDM 110 mediante un transformador BAAN-CDM. Estos transformadores trabajan en otra dirección también.

La Figura 16 es un diagrama de una incorporación de una transformación directa. En los transformadores directos, los objetos son convertidos de una forma a otra sin pasar a través de un formato intermedio. Por ejemplo, como se mostró en la Figura 16, los datos de planeador de cadena de suministro (SCP) 130 pueden ser accesados por un accesor de planeador de cadena de suministro para crear un objeto de planeador de cadena de suministro 132. El objeto del planeador de cadena de suministro 132 puede entonces ser transformado directamente en un objeto PLANEADOR FÁBRICA (FP) 134. El objeto planeador de fábrica 134 puede entonces convertirse en los datos de planeador de fábrica 136 a través de un accesor de planeador de fábrica. Este flujo de datos puede operar en la dirección distinta también.

En éstos procesos, hay vanos niveles de granulos a los cuales pueden tomar lugar el acceso y la transformación incluyendo niveles de relación (tabla) objeto genérico (árbol, gráfica, matriz, etc.) y objeto específico (cuenta de materiales, plan, etc.) . Algunas veces el acceso puede sólo estar disponible a un nivel (dígase tabla) pero la transformación puede ser más apropiada a otro cualesquier nivel (dígase objeto genérico) . Por ejemplo, el agregado jerárquico (una forma de transformación) es frecuentemente apropiada sobre un objeto de árbol. Sin embargo, los datos pueden ser sólo accesibles en forma tabular. En éste caso, por ejemplo, los datos deben ser accesados al nivel tabular, deben ser transformados en un árbol y después tener el agregado jerárquico aplicado a éstos.

La Figura 17 es un diagrama de una incorporación de diferentes niveles de transformación y acceso. Como se mostró, el acceso y la transformación pueden tener tres niveles. Un primer nivel 140 puede involucrar un acceso de tabla y transformaciones. Un segundo nivel 142 puede involucrar transformaciones y acceso de objeto genérico (árbol, gráfica, etc.) y un tercer nivel puede involucrar transformaciones y acceso de objeto específico (acumulación de materiales, plan, etc.) . Además de las transformaciones entre los formatos de aplicación, también pueae haber transformaciones entre los tres niveles como se mostró.

Desarrollo de Colaboraciones Un factor importante en un sistema de colaboración de empresas múltiples es la facilidad con la cual puede desplegarse la colaboración. Como se discutió, el presente administrador de colaboración global puede soportar cuatro diferentes clase de relaciones de sociedad: eje a red, eje a radio, eje a e e y eje a-VAN-EDI . De éstas cuatro, la de eje a red tiene todas las características de desplegado de las aplicaciones de red tradicional. La de eje a-VAN-EDI puede desplegarse a la extensión en que nivela una infraestructura VAN-EDI existente. Aún cuando la relación de e e a red es altamente desplegable, ésta puede sufrir del problema de requerir un humano sobre el lado de la red de la relación. En otras palabras, puede no ser adecuada para una colaboración de sistema a sistema.

La solución de eje a radio puede proporcionar un despliegue máximo en el ambiente de colaboración de sistema a sistema. En el campo de eje a radio, el motor de radio es análogo al explorador de red, y la parte de radio de la colaboración es análoga a la página de red o applet. En forma similar a una página de red o applet, la parte de radio de la colaboración puede ser diseñada y desplegada centralmente a los motores de red remotos A diferencia de una página de red o applet, aún puede haber integración que requiera el hacerse remotamente. Esta integración remota puede ser inevitable pero puede ser circunscrita y definida precisamente por la parte de radio de la colaboración Otro aspecto del despliegue es el manejo de versiones. Las colaboraciones una vez diseñadas y desplegadas son factibles de requerir cambios (en diferentes maneras) al transcurrir el tiempo. Puede ser importante que las versiones subsecuentes de las colaboraciones sean fácilmente desplegables como versiones iniciales. El presente administrador de colaboración global puede proporcionar un soporte completo para las versiones y el redespliegue centralizado de las colaboraciones. Además, las diferentes versiones de las colaboraciones pueden correr simultáneamente sin impactar unas a otras. Esto permite a una versión existente el ser faseada graciosamente mientras que otra versión está siendo faseada.

Otro elemento del despliegue del presente administrador de colaboración global es el nivel de infraestructura existente Este elemento es evidente. Por ejemplo, en el soporte de la relación de eje a radio sobre protocolos de red existentes. El soporte de eje a radio sobre protocolos de red existentes puede ser importante para un despliegue rápido ya que no se requiere una modificación e reconfiguración de una infraestructura ae red existente Les ahorros de tiempo grandes en éste aspecto pueden venir de re tener que modificar cuidadosamente la cartafuego y las infraestructuras de seguridad que pueden ya estar en el lugar.

Soporte de Muchas a Muchas Colaboraciones La presente arquitectura de radio a eje proporciona un manejo y desarrollo fácil. Sin embargo, en la práctica las empresas colaboran con muchas empresas las cuales a su vez colaboran con aún otras empresas. Por tanto, las empresas frecuentemente forman una gráfica o red colaboradora. Esto puede soportarse a través de la capacidad de sustituir un motor de eje por un motor de radio en cualquier momento. Esta capacidad de sustitución permite a las redes de colaboración de muchas a muchas el ser cultivadas orgánicamente más bien que todas a la vez .

La Figura 18 es un diagrama de una incorporación de sustituir un motor de red por un motor de radio dentro de una colaboración. Como se mostró, una empresa (El) puede desplegar un motor de eje 150 sobre sí misma y un motor de radio 152 en todos los sitios de socios. En particular, un motor de radio 154 puede ser un sitio de socio (E2). Si el sitio de socio (E2) desea el diseñar y controlar su propia colaboración, éste puede reemplazar el motor de radio 154 con un -otor de eje 156. Desde la perspectiva de la empresa 1, la empresa 2 puede aún ser un radio en la colaboración de la empresa 1. Sin embargo, éste radio ahora corre sobre un motor de eje 156 el cual puede controlar sus propias colaboraciones con los motores de radio 158. Además, los motores de radio 160 y 162 pueden estar asociados con una tercera entidad (E3) que mteractúa con ambos el motor de eje 150 y el motor de eje 156 a nombre de la empresa E3.

Extensión del Administrador del Sistema de Trabajo Un aspecto importante del presente administrador del sistema de trabajo es su extensión. Sin extensión, el administrador del sistema de trabajo puede no ser capaz de manejar nuevas situaciones y desafíos que confronte. Puede haber varias dimensiones diferentes para ésta extensión. Por ejemplo, un área primaria de extensión está en el área de las normas de objeto semántico. Si los estándares soportados no son suficientes para un problema particular, entonces el administrador del sistema de trabajo puede ser aumentado con nuevos estándares semánticos. Adicionalmente, el administrador del sistema de trabajo permite la construcción de estándares semánticos propietarios. Además, el administrador del sistema de trabajo puede ser extendido mediante el agregar nuevos accesores, transformadores, adaptadores, etc. La biblioteca de componente estándar puede extenderse ambos generalmente y por los usuapcs finales .

Espacio de Trabajo de Objeto La Figura 19 es un diagrama de bloque de una incorporación de un espacio de trabajo de computadora 200 en un sistema de computadora 205. El espacio de trabajo de computadora 200 incluye una pluralidad de ranuras de memoria 210 en comunicación con un administrador de sistema de permiso 220 y un administrador de evento 230. El administrador de sistema de permiso y el administrador de evento 230 pueden o no estar residiendo dentro del espacio de trabajo de computadora 200. El espacio de trabajo de computadora 200 es generalmente accesado por los nodos de red 240 a través de la red 250. Generalmente, el administrador de sistema de permiso 220 controla el acceso a las ranuras de memoria 210 dentro de un espacio de trabajo de computadora 200 por los nodos de red 240. El administrador de evento 230 genera mensajes a los clientes de red 240 en respuesta a los eventos o condiciones asociados con los datos u objetos que están almacenados en las ranuras de memoria 210.

La red 250 comprende cualesquier combinación o número de ejes, dipgidores, puentes, compuertas, conmutadores o cualesquier otra asociación de dispositivos de comunicación adecuados y programa de software relacionado que transmite datos entre los nodos de red 240. En una incorporación, la red 250 comprende una red implementada independientemente o en relación con una red de área amplia (WAN) o una red de área local (LAN) , tal como una red Ethernet, una red de anillo de muestra, o una red de interconexión de datos distribuidos de fibra (FDDI) . La red 250 soporta los protocolos sin conexión de nivel superior tal como el protocolo Internet (IP) , los protocolos orientados por conexión de nivel superior, tal como el relevador de administrador del sistema, o cualesquier otro protocolo de trabajo de red adecuado. La red 250 puede ser usada en una colaboración de empresas múltiples para implementar flujos de trabajo incluyendo las actividades que tienen lugar entre o en medio de más de una empresa. Cada nodo de red de trabajo 240 de la red de trabajo 250 en una colaboración de empresas múltiples puede estar asociada con una diferente empresa, permitiendo la comunicación y el funcionamiento coordinado de las actividades y de los flujos de trabajo entre las empresas.

Los nodos de red 240 pueden ser cualesquier terminal, servidor, cliente, eje, radio u otros dispositivos conectados a la red de trabajo 250. Cada nodo de red de trabajo 240 está asociada con una empresa particular. Los nodos de red 240 pueden o no participar en un proceso o flujo de red particular. Los nodos de red 240 pueden accesar el espacio de trabajo 200 como parte de un flujo de trabajo o colaboración o como parte de otras actividades o procesos no asociados con un flujo de trabajo o colaboración.

Cada ranura de memoria 210 almacena datos y objetos. Como se usó aquí, cada uno de los medios de por lo menos un subjuego de los artículos identificados. Los objetos pueden ser objetos Java, objetos C++, objetos CORBA, u otras estructuras que son capaces de almacenar ambas la información y el comportamiento. Las ranuras de memoria 210 pueden ser cualesquier estructura de memoria, ya sea accesada en cola o al azar, capaz de retener datos u objetos. Las ranuras de memoria 210 pueden incluir, por ejemplo, cualesquier estructura de datos, o arreglo de memoria. Las ranuras de memoria 210 pueden, por ejemplo, contener una pluralidad de objetos en cola dentro de las ranuras de memoria 210 o pueden contener sólo un objeto único. Las ranuras de memoria 210 pueden ser almacenadas en un disco u otro medio de almacenamiento o pueden ser mantenidas en la memoria durante cualesquier procesos o actividades llevadas a cabo por el sistema de computadora 205. Las ranuras de memoria 210 mantenidas en la memoria pueden ser almacenadas sobre una memoria de acceso al azar, por ejemplo, incrementando la velocidad a la cual sus contenidos son accesados sobre aquellas ranuras de memoria 210 almacenadas en un disco o componente periférico. Las ranuras de memoria 210 almacenadas en un disco u otros medios de almacenamiento son accesibles a una velocidad más baja que las ranuras de memoria 210 almacenadas en una memoria pero no son volátiles permitiendo el almacenamiento de datos persistentes o de objetos. Las ranuras de memoria 210 pueden ser arregladas en una jerarquía de organización definida por un programador, usuario u otro mecanismo adecuado. Tal jerarquía permite una fácil categorización de cualesquier referencia a las ranuras de memoria 210 como se describió abajo con referencia a la Figura 20.

El administrador del sistema de permisibilidad 220 mantiene y controla el acceso a las ranuras de memoria 210. El administrador de sistema de permisibilidad 220 puede incluir cualesquier combinación de programa de computadora y de software capaz de mantener derechos de acceso a las ranuras de memoria 210 y controlar el acceso a las ranuras de memoria 210 basándose sobre los derechos de acceso mantenidos. En una incorporación, los derechos de acceso incluyen el derecho de un nodo a: leer de los contenidos de cada una de las ranuras de memoria 210, escribir a los contenidos de cada una de las ranuras de memoria 210, remover cualesquiera de los contenidos para cada una de las ranuras de memoria 210 y suscribir a y no suscribir de la notificación de eventos para una o más de las ranuras de memoria especificadas 210.

El administrador de eventos 230 genera mensajes a los nodos 240 en respuesta a un evento particular dentro de las ranuras de memoria 210. El administrador de eventos 230 puede incluir cualesquier combinación de aparatos y de software capaces de generar mensajes y de iniciar la dirección de tales mensajes a un nodo de red particular 240 u otro elemento adecuado del sistema de computadora 205. Los nodos de red 240 que tienen derechos de acceso para suscribirse a la notificación de evento para una ranura de memoria particular 210, como se determinó por el sistema de permisibilidad 220, y que ejercita tal suscripción a la ranura de memoria particular 210, son notificados por un mensaje generado por el administrador de eventos 230 cada vez que un evento que requiere una notificación ocurre que está relacionado a la ranura de memoria particular 210.

Por ejemplo, uno de los nodos de red 240 puede tener derechos de acceso para suscribir a la notificación para una ranura de memoria particular 210, como se verificó mediante el administrador de sistema de permisibilidad 220, y puede suscribir a la notificación para la ranura de memoria particular 210 cada vez que la ranura de memoria particular 210 es escrita por uno de los nodos de red 240. Hasta que el nodo de red 240 no suscriba esa notificación para esa ranura particular, cada vez que la ranura de memoria particular 210 es escrita por uno de los nodos de red 240, el administrador de eventos 230 generará un mensaje e iniciará la dirección de tal mensaje al un nodo de red 240 indicando que se ha escrito a la ranura de memoria en particular 210.

En una incorporación, los derechos de acceso para suscribir y no suscribir a la notificación de evento para ura ranura de memoria particular 210 pueden variar basándose sobre la clasificación de un evento. Por ejemplo, un nodo de rea particular 240 puede tener derechos de suscripción para ser notificados siempre que una ranura de memoria particular 210 tenga datos removidos pero no cuando se le escribe a la misra ranura de memoria 210, o el nodo de red 240 puede tener derechos de suscripción a ambos, o la suscripción puede abarcar la notificación en respuesta a cualesquier datos que son removidos o escritos en la ranura de memoria 240. Los derechos de acceso concedidos por el sistema de permisibilidad 220 y la suscripción a los mensajes desde el administrador de eventos 230 pueden también agruparse en cualesquier combinación adecuada. Por ejemplo, la notificación de eventos puede ser suscrita por una ranura de memoria individual 210, a todas las ranuras de memoria 210, o a un subjuego de ranuras de memoria 210 seleccionado basándose sobre los criterios indicados. En forma similar, los derechos de acceso pueden ser concedidos por el sistema de permisibilidad 220 a todas las ranuras de memoria 210 o a cualesquier subjuego de las mismas.

La Figura 20 ilustra una incorporación del espacio de trabajo ilustrado en la Figura 19. El espacio de trabajo 300 es un espacio de trabajo para almacenar datos y objetos en las ranuras de memoria 310 de manera que estos son arreglados en un sistema jerárquico. La naturaleza exacta de la jerarquía y de la colocación de las ranuras de memoria particular dentro del sistema es definible por un administrador de espacio de trabajo, por otro usuario u otro mecanismo adecuado.

Generalmente, el espacio de trabajo 300 es organizado en secciones 305 que son además separadas en ranuras de memoria individuales 310 y en los grupos 320. Los grupos 320 pueden a su vez contener ranuras de memoria 310 y/o estar separados en subgrupos adicionales. En la Figura 20, las ranuras de memoria 310 son designadas por el número de sección, el número de grupos si es aplicable, y después se designan por s y un número de identificación dentro de la sección aplicable 305 o el grupo 320. Por ejemplo, la ranura de memoria 310 identificada por la nomenclatura "sección 2.grupol.s2" denota una ranura llamada "s2" en el grupo 1 de la sección 2 del espacio de trabajo. Otra jerarquía o esquema de organización puede ser sustituido por la jerarquía descrita aquí. Una jerarquía tal como una descrita permite una categopzación fácil y el agrupamiento de las ranuras de memoria 310. Tal categopzación puede ser usada para fácilmente agrupar ranuras de memoria 310 para los propósitos de mantener derechos de acceso. Por ejemplo, a un nodo de red 240 de la Figura 20 puede sólo concedercele un derecho de acceso particular a una hilera específica de ranuras de memoria 310. Tal hilera puede ser todas las ranuras de memoria 310 en el nivel de grupo, por ejemplo, o las ranuras de memoria 310 designadas por la sección l.sl y la sección 2. si en la Figura 20. Los derechos de acceso también pueden ser otorgados a una sección particular 305, al grupo 320, al subgrupo, o a una combinación de los mismos.

La Figura 21 es un diagrama de bloque de un sistema de computadora 405 que usa por lo menos un agente 460 iniciado en uno de una pluralidad de nodos de red 440 para accesar un espacio de trabajo de objeto 400 a través de una red 450. Los nodos de red 440 están conectados a través de la red 450 al espacio de trabajo 400. Generalmente en el sistema de computadora 405, el agente 460 está iniciado en uno de los nodos de red 440 para desplazarse a través de la red 450, del espacio de trabajo de acceso 400 y llevar a cabo operaciones o tareas en el espacio de trabajo 400 basándose sobre los comandos programados .

El espacio de trabajo 400 incluye las ranuras de memoria 410 y está involucrado con cualesquiera o todas las características de los espacios de trabajo 200 y 300 como se describió con referencia a las Figuras 19 y 20. Los nodos de red 440 están asociados con una empresa particular y están involucrados como se describió en la referencia a los nodos de red 240 de la Figura 19. La red 450 es una red que conecta los nodos de red que están involucrados en una colaboración particular y están embebido como se describió en la referencia a la red 250 de la Figura 19.

El agente 460 puede ser cualesquier agente orientado por el oojeto u otro artículo que posea la característica de autonomía. La autonomía como se definió aquí, es la capacidad de ser programado cuando uno o más objetos y el intentar el satisfacer aquellos objetivos independientemente del programa originante o de la aplicación, aún cuando se mueva en una red y a otras plataformas tales de manera que el contacto se pierda con el programa originante. Los agentes 460 son programados con el objeto de llenar las actividades de colaboración. Las actividades de colaboración pueden ser actividades involucradas en el desempeño de un flujo de trabajo o actividades llevadas a cabo fuera de un flujo de trabajo que una empresa o instalación dentro de una colaboración puede iniciar para llevar a cabo la administración, optimización o tareas de ejecución relacionadas a los datos u objetos que están en el espacio de trabajo 400. Las actividades de colaboración también pueden ser cuestiones intentadas para recolectar datos o manipular datos u objetos que están en el espacio de trabajo 400. Un agente administrativo 460, por ejemplo, puede ser iniciado para modificar las características de la jerarquía de ranura de memoria como se describió con relación a la Figura 20. Un agente administrativo 460 también puede ser iniciado para cambiar el perfil de suscripción de un nodo de red originante 440, alterando por tanto el tipo de una notificación de evento recibida por el nodo de red 440. Un agente específico 460 puede aún originarse de un nodo de red específico 440 que tiene la autoridad para alterar el sistema de permisibilidad, y por tanto permitir al agente 460 el modificar los derechos de acceso a uno o más nodos de red 440 para las ranuras de memoria especificadas 410. Un agente de optimización 460 puede ser iniciado para modificar las características o el comportamiento de un objeto almacenado en el espacio de trabajo 400 para mejorar el funcionamiento del objeto durante la ejecución o la determinación del flujo de trabajo. Un agente de ejecución 460 puede llevar a cabo una serie de tareas o cálculos usando los objetos en el espacio de trabajo 400 y regresar un resultado de tales tareas o cálculos a su nodo de red de iniciación 440. Un agente de cuestionamiento 460 puede llevar a cabo preguntas complejas en el espacio de trabajo 400 y regresar un resultado de tales preguntas a su nodo de red de iniciación 440. Los agentes 460 pueden cooperar dentro del espacio de trabajo 400 también, regresando los resultados a otro agente 460 o al nodo de red 440.

El espacio de trabajo 400 puede, como los espacios de trabajo 200 y 300, tener un sistema de permisibilidad y/o un administrador de evento capaz de mteractuar con o responder al agente 460. Por ejemplo, el agente 460 puede necesitar el mteractuar con un sistema de permisibilidad, como se describió en la Figura 19, a fin de verificar que el nodo de red originante 440 del agente 460 tenga derechos de acceso a una ranura de memoria particular 410 que contenga objetos o datos con los cuales el agente 460 desea interactuar. Similarmente, un administrador de eventos puede responder a una operación llevada a cabo por el agente 460 dentro de una ranura de memoria particular 460 mediante el emplear un mensaje de notificación de evento para suscribir los nodos de red 440 como se describió con referencia a la Figura 19.

La Figura 22 es un esquema que ilustra una incorporación de un método para usar el agente de la Figura 21 para accesar un espacio de trabajo. En el paso 510, un nodo de la red inicia un agente programado para ejecutar por lo menos una tarea en un espacio de trabajo remoto. En el paso 520, el agente es enviado a través de la red a un espacio de trabajo que está acoplado a un segundo nodo de la red. El espacio de trabajo tiene una pluralidad de ranuras de memoria, cada una operable para almacenar por lo menos un objeto, un sistema de permisibilidad, y un administrador de evento. En el paso 530, el agente indica al sistema de permisibilidad una ranura de memoria específica que el agente desea accesar. El paso 540, el sistema de permisibilidad verifica que el nodo de la red que inició el agente tenga derechos de acceso a la ranura de memoria indicada. En el paso 550, el agente lleva a cabo una o más operaciones como se describió con referencia a la Figura 21. En el paso 560, el agente regresa los resultados de las operaciones, si hay alguna, al nodo de iniciación. En el paso 570, un administrador envía un evento a un nodo de la red que ha suscrito a la notificación de evento que corresponde a una operación que el agente ha llevado a cabo y a la ranura de memoria accesada por el agente Aún cuando la presente invención se ha descrito en detalle, deberá entenderse el que varios cambios, sustituciones y alteraciones pueden hacerse aquí sin departir del espíritu y alcance de la invención como se definió por las reivindicaciones anexas .

Claims (19)

R E I V I N D I C A C I O N E S

1 Un sistema de computadora para accesar remotamente datos en una colaboración de empresas múltiples, que comprende : un nodo de red asociado con una primera empresa, el nodo de red estando en comunicación con un espacio de trabajo a través de la red, el espacio de trabajo está asociado con una segunda empresa y tiene una pluralidad de objetos almacenados, y un agente generado en el nodo de red, el agente siendo operable para accesar el espacio de trabajo a través de la red, el agente además siendo operable para manipular por lo menos uno de la pluralidad de objetos almacenados dentro del espacio de trabajo para llevar a cabo una actividad de colaborac.ón

2 El sistema de computadora tal y como se reivindica en la cláusula 1 caracterizado porque el agente es un agente administrativo

3 El sistema de computadora tal y como se reivindica en la cláusula 1 caracterizado porque el espacio de trabajo está organizado de acuerdo a una jerarquía y en donde el agente es un agente administrativo operable para modificar las características de esa jerarquía.

4. El sistema de computadora tal y como se reivindica en la cláusula 1 caracterizado porque el agente es un agente de ejecución.

5. El sistema de computadora tal y como se reivindica en la cláusula 1 caracterizado porque el agente es un agente de optimización.

6. El sistema de computadora tal y como se reivindica en la cláusula 1 caracterizado porque el agente es un agente de cuestionamiento .

7. El sistema de computadora tal y como se reivindica en la cláusula 1 caracterizado porque comprende además el espacio de trabajo en donde el espacio de trabajo incluye una pluralidad de ranuras de memoria, cada ranura siendo operable para almacenar por lo menos un objeto.

8. El sistema de computadora tal y como se reivindica en la cláusula 1 caracterizado porque las ranuras de memoria son accesibles por una pluralidad de nodos de red y en donde el acceso a las ranuras de memoria por los nodos de red es controlado por un sistema de permisibilidad.

9. El sistema de computadora tal y como se reivindica en la cláusula 1 caracterizado porque el espacio de trabajo es un espacio de trabajo de memoria y en donde el agente es un agente de optimización.

10. El sistema de computadora tal y como se reivindica en la cláusula 1 caracterizado porque el espacio de trabajo es un espacio de trabajo persistente.

11. El sistema de computadora tal y como se reivindica en la cláusula 1 caracterizado además porque comprende el espacio de trabajo, en donde el espacio de trabajo incluye un administrador de evento, el administrador de evento siendo operable para notificar al nodo de red en respuesta a los cambios al espacio de trabajo.

12 Un método para accesar remotamente datos en un espacio de trabajo de objeto que comprende. iniciar un agente en un primer nodo de una red; enviar al agente a través ae la red a un espacio de trabajo en un segundo nodo de la red, el espacio de trabajo tiene una pluralidad de ranuras de memoria, cada ranura de memoria es operable para almacenar por lo menos un objeto, el espacio de trabajo además tiene un sistema de permisibilidad para controlar el acceso a las ranuras de memoria; usar el sistema de permisibilidad para verificar que el agente tenga derechos de acceso a la ranura de memoria específica; y llevar a cabo una operación usando el agente y por lo menos un objeto almacenado en la ranura de memoria específica.

13. El método tal y como se reivindica en la cláusula 12 caracterizado además porque comprende el enviar los resultados de la operación al primer nodo.

14. El método tal y como se reivindica en la cláusula 12 caracterizado además porque comprende el enviar un mensaje a un tercer nodo de la red en respuesta a llevar a cabo la operación.

15. El método tal y como se reivindica en la cláusula 12 caracterizado además porque comprende el cambiar una jerarquía de organización del espacio de trabajo en respuesta a llevar a cabo la operación.

16. El método tal y como se reivindica en la cláusula 12 caracterizado además porque comprende el primer nodo suscribiendo a una notificación de evento en respuesta a llevar a cabo la operación.

17. El método tal y como se reivindica en la cláusula 12 caracterizado además porque comprende el alterar el sistema de permisibilidad en respuesta a llevar a cabo una operación.

18. El método tal y como se reivindica en la cláusula 12 caracterizado porque el llevar a cabo la operación comprende el llevar a cabo tareas administrativas en el espacio de trabajo.

19. El método tal y como se reivindica en la cláusula 12 caracterizado porque el llevar a cabo la operación comprende la optimización del funcionamiento del objeto. R E S U M E Un sistema de computadora para accesar remotamente datos en una colaboración de empresas múltiples que comprende un espacio de trabajo asociado con una primera empresa que tiene una pluralidad de objetos almacenados. El sistema de computadora además comprende un nodo de red asociado con una segunda empresa, el nodo de red está en comunicación con el espacio de trabajo a través de la red. El sistema de computadora además comprende un agente generado en el nodo de red, el agente es operable para accesar el espacio de trabajo a través de la red, el agente además es operable para manipular por lo menos uno de la pluralidad de objetos almacenados dentro del espacio de trabajo para llevar a cabo una actividad de colaboración.