MXPA00012051A - System and process for multi-enterprise collaboration - Google Patents

Abstract

A computer implemented process for multi-enterprise collaboration includes designing a workflow having at least one heterocast split and at least one heterocast join. The heterocast split and heterocast join allow at least one activity to be parameterized, at least one of the parameters including nodes within a node group. The workflow is instantiated such that the activity is instantiated as a plurality of activities each tailored to a particular node in the node group. The workflow is deployed, including distributing the activities over the nodes in the node group, and executed to provide multi-enterprise collaboration. In another embodiment, an object-oriented workflow including objects associated with activities to be performed within the workflow is instantiated. The objects are deployed, across enterprise boundaries to nodes on which associated activities are to be performed, and executed to provide multi-enterprise collaboration. The activities communicating data using objects that carry both data and behavior.

Description

SYSTEM AND PROCESS FOR COLLABORATION OF MULTIPLE COMPANIES TECHNICAL FIELD OF THE INVENTION.

This invention relates in general to the field of supply chain, business and site planning and, more particularly as a system and process for multiple enterprises. BACKGROUND OF THE INVENTION.

The supply chain, enterprise, and site planning applications and their environments are widely used by manufacturing entities for decision support and for aid management operations. The decision support environments for the supply chain, for the company and for the planning of the site have evolved d mono domain environments into monolithic environments of multiple domains. Conventional planning software applications are available in a wide range of products offered by several companies. These decision support tools allow entities to more efficiently manage manufacturing operations. However, supply chains are generally characterized by multiple, distributed and heterogeneous planning environments. Therefore, there are limits to the effectiveness of conventional environments when applied to the problem of supply chain planning due to monolithic application architectures. In addition, these problems are exacerbated when there is no "owner" of the entire supply chain.

It is desirable for the next evolutionary step for the planning environments to establish a heterogeneous architecture of multiple domains that supports the multiple domain of product extension as well as the multiple product extension engines. The integration of various planning environments in a seamless solution can enable supply chain planning between companies and between domains. In addition, an important function provided by some planning applications is the optimization of the subject environment rather than simply following the trace of the transactions. In particular, the RH? THM family of products available from 12 TECHNOLOGIES provides optimized functionality. However, with respect to planning at a company or at the supply chain level, many conventional applications, such as those available from SAP, use the enterprise resource planning (ERP) engines and do not provide optimization.

The success or failure of a company can depend to a great extent on the quality of decision making within the company. Therefore, decision support software, such as the RHYTHM product family of 12 TECHNOLOGIS, which supports optimal decision making within the company can be particularly important for the success of the company. In general, the optimal decisions are relative to the domain of decision support where the domain is the extension of "world" considered to arrive at the decision.

For example, the decision that is being made may be how much of an item a factory can produce during a given period of time. The optimal answer depends on the domain of the decision, the domain can be, for example, just the factory itself, the supply chain that contains the factory, the complete company or the supply chain of multiple companies. are considered knowing the larger domains or the multiple domains.) Typically, the larger the decision support domain, the more optimal the decision will be, consequently, it is desirable for the decision support software to cover even larger domains in the decision making process, however, this extension of coverage can create significant problems.

SYNTHESIS OF THE INVENTION.

In accordance with the present invention, an object-oriented overflow for enterprise collaboration is described and provides advantages over conventional supply chain, enterprise and site planning environments.

According to one aspect of the present invention, a computer-implemented process for collaborating with companies involves initiating an object-oriented workflow where the object-oriented workflow comprises objects associated with activities that are to be carried out. within the workflow. The objects of the object-oriented workflow are then displayed across the enterprise boundaries to nodes over which the associated activities are to be carried out. After deployment, the deployed objects are executed to provide collaboration of multiple companies with the communication data of activities using objects that carry both behavior information. In addition, in an environment, the process also includes creating models of objects in memory in nodes whose objects executing the nodes can access.

According to another aspect of the present invention, a computer-implemented process is provided for information access and transformation for an object-oriented workflow. The process includes supporting the communication of objects as a primary information format and supporting the construction of format objects derived from underlying native data formats. In addition, transformations are supported between native data formats, derived format objects and objects. The process also involves communicating the information between the activities of a performing workflow using object objects of derived format and using transformations between the native data formats and objects of derived format objects.

A technical advantage of the present invention is the implementation of object-oriented workflows that communicate information between activities using the objects. This provides increased capabilities by carrying the objects both information and behavior.

Another technical advantage of the present invention is the local implementation of object models in memory that can be achieved through activities during execution. This access may include creating, modifying and destroying objects.

An additional technical advantage is an access to information and the manipulation of the work table that provides considerable flexibility for the communication of information between activities and workflows for the collaboration of multiple companies.

The additional technical advantages should be readily apparent to one skilled in the art of the following figures, descriptions and claims.

BRIEF DESCRIPTION OF THE DRAWINGS.

A more complete understanding of the present invention and the advantages thereof can be gained by referring to the following description taken in conjunction with the accompanying drawings in which the reference numbers indicate reference characteristics, and wherein: Figure 1 is A diagram of incorporation of a computer-implemented architecture that can support the collaboration of companies.

Figure 2 is a diagram of an incorporation of components of a global collaboration system; Figure 3 is a diagram of a global collaboration system of Figure 2 wherein certain software elements having particular modules are highlighted; Figure 4 is a block diagram of an incorporation of a system that allows collaboration within companies for optimal decision making; Figure 5 is a block diagram of incorporating the use of a global collaborative workspace; Figure 6 is a diagram of an incorporation of a life cycle for a collaboration; Figure 7 is a diagram of situations where common software is present on both sides of the relationship and where it is not; Figure 8 is a block diagram of an embodiment of a security configuration for a case of axis to radio and axis to network; Figure 9 is a block diagram of an embodiment of a security configuration for a case of eg the axis; Figure 10 is a diagram of an incorporation of the design of a work flow between companies that includes the formation of parameters on groups; Figure 11 is a diagram of an implementation of change management by modifying a design of a workflow; Figure 12 is a diagram of an incorporation of the integration of a world of work with the outside world Figure 13 is a diagram of an incorporation of a data flow that runs in a single activity.

'Figure 14 is a diagram of an incorporation of the data flow divided through multiple activities.

Figure 14A is a diagram of an object-oriented workflow incorporation for the collaboration of companies including object models in local memory Figure 15 is a block diagram of the incorporation of a common data model based on the transformation model; Figure 16 is a diagram of an incorporation of a direct transformation; Figure 17 is a diagram of an incorporation of different access and transformation levels; Figures 17A and 17B are diagrams of an incorporation of a data and transformation access allowing the data to be manipulated in various formats during the execution of the workflow; Y Figure 18 is a diagram of an embodiment of the replacement of an axle motor by a radio engine within a collaboration.

DETAILED DESCRIPTION OF THE INVENTION.

The improvement of the decision support processes involves the expansion to provide a level of companies and decision support at the level of multiple companies to make optimal decisions. Technically and conceptually, providing decision support at the level of multiple companies and enterprise level differs from providing decision support at the factory level and supply chain level. The reasons for this may be that, in situations of multiple domains (such as business units within a company or multiple companies), different domains frequently operate different decision support software. Also, in situations of multiple domains, one domain generally can not force another domain to make a particular decision. In other words, optimal decision support in this environment often requires being carried out in a negotiated environment as opposed to a coercive one.

Providing decision support in multiple domain situations can be achieved by pursuing a collaborative approach to decision support rather than a coercive one. Several communication and distributed processing technologies can be used to implement such an environment, including the internet, the network, JAVA, XML, CORBA, etc., which helps make possible a large-scale collaborative decision making. Soon 12 TECHNOLOGIES products will be available that will allow a collaborative approach to decision support, including the collaboration manager RHYTHM-GLOBAL (GCM) and the collaboration designer RHYTHM-GLOBAL (GCD).

COLLABORATION SYSTEM AND PROCESS COMPONENTS Figure 1 is a diagram of an implementation of a computer-implemented architecture that can support the collaboration of companies. As shown, a global decision support architecture can be built on the underlying link, global messaging, vision, and information store components. The collaboration can then involve a global collaboration designer (GCD) and a global collaboration manager (GCM) supported by the decision support architecture. The global collaboration designer can be used to design and put collaborations in instances, and the global collaboration manager can be used to run the collaborations. In this scheme, collaborations can be mentioned as modules and can have versions.

Figure 2 is a diagram of an incorporation of components of a global collaboration system. As shown, the system can allow an enterprise axis 2 to collaborate with a radio company 4 and a company network 6. The company axis 2 and the company radio 4 each include a global collaboration manager 8. Global collaboration managers 8 are coupled to and communicate with the respective internal global communication workspaces 10. An external global collaborative workspace 12 provides a means to share information between the company axis 2, the company radio 2 and the company network 6. Axis 2 company can also collaborate through an electronic data exchange processor (EDI) 14 with an added value network (VAN). In addition, the axis 2 company can communicate and collaborate with other axis companies using a global message bus 15.

In operation, the primary controller of the collaboration can be the global collaboration workspace engine 8 of the company axis 2. The axis-to-axis relationship can be facilitated by the global message bus 15, and the axes relationships to radio and from axis to network can be facilitated by the external global collaboration workspace (GCW) 12. As shown, an axis 2 company can generally have an internal global collaborative workspace 10 and a collaborative workspace external global 12. The internal global collaboration workspace 10 can be used to share and exchange data with the internal user interconnections as well as with the electronic data exchange processor 14. The global collaborative workspace 12 can be used to share and exchange data with radio companies 4 and network companies.

For security, the external global collaboration workspace 12 can be installed in a DMZ or outside a corporate fire wall of an axis 2 company. This way you do not need to make direct connections from outside to the protected corporate network of the company axis 2. The global collaboration workspace can accept, for example, IIOP, HTTP, and HRRPS connections. In particular, the last two connections are useful for bridging wall configurations against existing fires. In this way, a wall configuration against fires is not necessary on any client (radio node or axis node) or server (node axis) which can make the solution more quickly deployable.

Figure 3 is a diagram of the overall collaboration system of Figure 2 wherein certain software elements constituting the particular modules are highlighted. As can be seen, the software for the global collaboration manager module can be present in the following places: in the axis motor 8, in the radio engine 8, in the user-user-axis interconnection (VI), in the radio-user user interconnection and the axis-node user interconnection. Additionally, the module can communicate with the native applications 17 about the company axis 2 and the company radio 4. The communications with the native applications 17 can be either synchronous (dotted line) or asynchronous (solid lines). The asynchronous communication with the native applications 17 can be facilitated by the internal global collaboration workspace 10, as shown, furthermore, a global serial database (GSDB) can be present on the enterprise side axis 2 side.

The fiber 4 is a block diagram of a system indicated generally at point 16, which allows collaboration within and between the companies for an optimal decision making. As shown, a system 16 includes an axis node 8 which can be a process within an axis motor running on a computer system. The axis node 18 is coupled to and communicates with a radio node 20 which can also be a process within an axis motor running on a computer system. As shown, the radio node 20 can be outside an enterprise boundary 22 of the axis node 18. The axis node 18 can also be coupled to and communicate with a plurality of radio nodes 24 which can be processes within an engine of radio that runs on one or more computer systems. The axis node 18 can also be coupled to and communicate with a plurality of network nodes 26 which can be processed within a network explorer running on a computer system. In addition, the axis node 18 is coupled to and communicates with the substitute EDI (Electronic Data Interchange) 28 which can provide a gate to the electronic data exchange systems.

Axis engines and radio engines together with a global communication workspace can be the primary entities of a global collaboration manager.

In this environment, an axis motor is the primary controller of the collaboration. The axis motor can coordinate both the global collaboration as well as the local collaborations. Global collaborations are those that span axis 18 nodes, radio nodes 20 and 24, and network nodes 26. A local collaboration can run on a single paper axis or a radio / radio group. These collaborations can be distributed, but remain within a single company. Shaft motors can also be coordinated with user and shaft interconnections (Ul) as well as the value-added network processor-electronic data exchange of an electronic data substitute 28. In one embodiment, the shaft motors are motors of Multiple yarn that can simultaneously coordinate multiple collaborations as well as multiple versions of the same collaboration. In addition, the axis motors can dynamically load and execute collaborations.

A radio engine can also operate to initiate a collaboration. In this environment, unlike an axis motor, a radio engine is not an independent entity. Instead of this a radio engine can only coordinate in conjunction with an axis motor. In addition, a radio engine can not coordinate with other radio engines or other axis nodes. As an axis motor, a radio engine can be multi-threaded and can simultaneously coordinate multiple collaborations as well as multiple versions of the same collaboration. Radio engines can also be loaded dynamically and execute collaborations.

Figure 5 is a block diagram of an incorporation of the use of a global collaboration workspace 30. In Figure 5, the global collaboration workspace 30 provides the primary entity used to share data / objects between the entities in the colaboration. As shown, the workspace 30 can interface with the global collaboration managers (GCMs) 32, a system 1 (= local 34, a network server 36 and a network interconnect 37 and the native applications 38. In general, the objects can be placed in the global collaboration workspace 30 by an entity and be retrieved by another entity Recovery can be achieved either by question or by subscription.Thus, the global collaboration space 30 combines the attributes of a database as well as a message bus.

The global collaboration workspace can be organized as a hierarchy of slots which can be in memory or be persistent. Slots can also be queued or be regular, and fine-grained permits can be attached to each slot. Permits can be signed per user per operation. The primary operations can be read, write, take and subscribe.

The memory slots retain data in the volatile memory. The writing and recovery of the slots in memory is very fast but is subject to loss if the global collaborative workspace 30 is dropped. When used in the memory slots, the global collaboration workspace 30 can be considered a fast and secure memory object database, with security and messaging capabilities. Persistent slots retain your data in a stable warehouse. Writing and recovering persistent slots is slower than for memory slots, but data is not lost if the global collaboration workspace 30 is dropped.

The decision as to using the memory or persistent slots may depend on the application. The global collaboration work space 30 stores the data in the form of objects and can store JAVA objects, CORBA objects, an arbitrary BITE array, this, coupled with its in-memory capabilities, makes the global collaboration workspace 30 appropriate as a high-speed data sharing mechanism among other object-oriented memory engines such as the factory glider and the 12 TECHNOLOGIES supply chain glider.

A Global Collaboration Designer (GCD) provides a tool to allow collaborative designers to interactively design, put into instances and deploy collaborations that are to be run using the global collaboration manager. The output of the global collaboration designer is a code that can be automatically loaded and run by the global collaboration manager. The global collaboration designer can allow designers to create new collaborations, retrieve existing collaborations and version collaborations. The global collaboration designer can also allow designers to design the axle network and radio pair collaborations and design events and collaboration messages. The global collaboration designer can integrate a standard object library and a standard component library for easy use from within the overall collaboration design. The global collaboration designer can be used to create workflows of multiple sophisticated companies with synchrony to synchrony, their workflow divisions or -divisions, unions-synchronization, divisions-heterofundido, unions-heterofundido, etc. Global workflows and local workflows can both be created. The global collaboration designer can provide automatic verification of collaborations and automatic code generation, whose code is run by the global collaboration manager. The generated code can be manually edited if desired. In addition, the global collaboration designer can provide the initiation of a collaboration that includes the generation of security administrator configurations and global collaboration workspace configurations.

Figure 6 is a diagram of a life cycle incorporation for a collaboration. As shown, in the step, a collaboration can be designed using the global collaboration designer. Then, in step 46, a collaboration can be instantiated using the global collaboration designer.

Instanced collaboration can then be deployed, in step 44, using the global collaboration designer and global collaboration administrator. After the deployment, the collaboration can be run using the global collaboration administrator in step 46. Subsequently, a new instance can be created or a new version of the collaboration can be created. To create a new instance, the fluj returns to step 42. For a new version, the global collaboration designer can be used in step 48 to modify the collaboration.

The extension of single domain decision support to multiple domain support can be complicated. In particular, the following discussion describes a number of challenges presented by the decision support of multiple domains and the incorporations of how these challenges are examined by the system present in the processes that allow collaboration within and between companies for a decision making optimum HETEROGENEITY OF THE REPRESENTATION.

A problem with collaboration is bridging the heterogeneity of representation through companies. Before collaboration can occur successfully, the heterogeneity of representation across companies must be bypassed.

Companies often represent the same data in different ways. These differences vary from semantic differences to technological differences, to differences in names, etc. The obvious solution to bridge these differences is standardization. However, this immediately raises the issue about what standard should be agreed upon. The present system and the process avoid such a requirement.

It should be noted that there may be three relevant categories of standard that need to be examined. These three categories are: format standards, transport standards and semantic standards. The format standards refer to the technological formats for which the data / objects are encoded. Examples include XML, Java series streams, IIOP series streams and the electronic data exchange format. Transport standards are used to pass data, these can include HTTP, IIOP, RMI, DCOM, FTP, value-added networks, asynchronous message buses such as MQSeries, etc. Third, semantic standards are the way in which the semantic content of the data is described. Examples include electronic data exchange, the common data model 12 (CDM).

By considering the standards in this light, an understanding of the issues may arise. A majority of the current confusion arises from the fact that there are many standards that cover two or more of the above-mentioned categories and those discussions of the various standards fail to categorize which category is being discussed. For example, electronic data exchange is primarily a semantic standard, but also typically involves a format standard (the electronic data exchange file format) and a transport (an added value network). Once this is understood, it becomes clear that the semantic standard of electronic data exchange can be separated from the other two. Therefore, semantic electronic data exchange objects can be encoded in other formats such as Java serial streams and can be passed over other transport standards such as HTTP. Similarly, XML is primarily a format standard that can be used to encode several semantic standards. Efforts are being made to codify the electronic data exchange in XML. or Several format standards can be supported by the present global collaboration manager, including XML the electronic data exchange format, the Java series streams (mentioned as Java format and not to be confused with the Java language or the Java platform) and the IIOP series currents. Of these, in an incorporation, the Java format is the primary format and the rest are derived formats. Because the Java format can contain the behavior to produce the other formats, it has been chosen as the primary format. The XML, electronic data exchange and IIOP formats can be derived from the Java format.

Figure 7 is a diagram of situations where the common software of 12 TECHNOLOGIES is present on both sides of a relationship and where it is not. As shown, for example, when the global communication manager RHYTHM is on both sides nothing will be gained to convert to an intermediate format. This will introduce unnecessary inefficiency, and only data (not objects) would be interchangeable by limiting the range of applications. Therefore, when the same software is present on both sides, binary Java objects can be directly exchanged. On the other hand, for example, when the GLOBAL RHYTHM COLLABORATION ADMINISTRATOR is present on only one side, the EDI or XML formatted objects can be produced (output) and interpreted (input).

With respect to transportation standards, the present global collaboration manager can support the variety of transport standards, including HTTP, IIOP, and asynchronous message buses. Further details are provided below regarding handling multiple types of relationship.

With respect to semantic standards, the present global collaboration manager can primarily support two semantic standards and electronic data exchange and RHYTHM-CDM. The exchange of electronic data can be supported because this is usually the most popular semantic standard. However, this suffers from the disadvantage (among others) of not providing deep coverage of the planning domain. The RHYTHM-CDM, on the other hand, provides deep coverage of the planning domain and provides appropriate constructions to carry out decision support of multiple companies. Additionally, this format is supported by all the 12 TECHNOLOGIES planning engines.

In general, a problem with public standards such as electronic data exchange, is that many can not adequately cover the kinds of data / objects that companies would exchange. In addition, waiting for standard bodies to standardize on a particular object may not be an option, and the supply chain has no particular competitive advantage over the use of public standards. For this and other reasons, the present global collaboration manager supports an alternative approach to standardization by supporting proprietary community standards. For example, using the RHYTHM-GCD, a community of companies can design a set of standards that are relevant only to that community. The RHYTHM-GCM will support and enforce these proprietary community standards. The RHYTHM-GCD also supports a library of building block objects that can be composed in proprietary community standards. The proprietary community standards have a number of advantages including: these can be designed to exactly cover the kinds of data / objects that companies will exchange; only the relevant parts require agreement on the particular standard, therefore the process will be much faster than expected by a standard body; different standards can be developed for different categories of partners and, in an extreme case, a different standard for each partner; and standards can be developed that give the supply chain a competitive advantage over competitors.

MULTIPLE TYPES OF RELATIONSHIP.

Another problem to allow collaboration is the management of multiple relationship types. Companies have some relationships of various types with their partners. In some ways the relationships that can vary are: between the main trading partners on the one hand and between the smaller trading partners on the other; between companies of approximately equal influence over the supply chain and between companies of unequal influence over the supply chain; and between companies with a high degree of technical sophistication on one side and between companies with an uneven side of technological sophistication on the other. As will be understood, these types of different relationships must be handled differently.

The present global collaboration manager can model the relationships of companies as an axis and radio network, as described above and shown in Figure 4. In this way, the four types of relations are: axis-to-network; Axis-to-Van-Electronic data exchange; axis-to-radius and axis-to-axis. Each type of relationship has an appropriate use.

With regard to the axis-to-radio relationship, when people talk about e-commerce today, people often involve an architecture where a network explorer speaks to a centralized server. This architecture has some advantages: The infrastructure to support this architecture is already typically; and all the administration can be centralized on the side of the. server. However, this architecture also has a great disadvantage in the sense that it requires the presence of a human on the side of the network explorer. Therefore, automation from system to system is not possible. Based on these advantages and cons this type of relationship may be appropriate when a company requires to exchange data with either a junior partner or a partner with less technological sophistication.

With respect to the axis-to-value added relationship network-electronic data exchange, the vast majority of electronic commerce between companies now takes place by sending an electronic data exchange over value-added networks. The advantage of this approach may be that system-to-system integration is possible and is currently currently supported. The disadvantages of this approach are: the large costs to send data on the owner's value-added network; the high administrative costs due to the lack of true standardization; requirement of third-party tools just to convert from the true "standard" to an appropriate form for the company; no support for system-to-human integration and no support for proprietary standards and corporate standards. Based on these and other advantages and disadvantages, this type of relationship may be appropriate when supporting an environment of a legacy value-added network-electronic data exchange.

With respect to the axis-to-radio relationship, this type of relationship also allows a system-to-system integration as a value-added network-electronic data exchange. Architecturally the axis to radio is a collaboration between an axis motor and a radio engine. The axis-to-radio relationship can have advantages as a value-added network. electronic data exchange. It can use the public internet to reduce network costs; administrative costs are much lower than those of value-added network-electronic data exchange because much of the infrastructure of the axis-to-radio relationship can be deployed centrally and managed. True objects (in addition to data only) can be exchanged allowing much more advanced collaborations; and multiple semantic standards can be supported including electronic data exchange, I2-CDM and proprietary community standards. Based on the above mentioned characteristics, the axis-to-radio ratio may be appropriate when companies wish to carry out system-to-system collaboration. It may also be appropriate where a software program of 12 Technologies is not present in any of the companies. This is due to the axis-to-radio ratio that can be deployed centrally by the company of eg.

With respect to the axis to axis, the ratio is similar to that of axis to radius except that it takes place between the two axis motors rather than an axis and a radius motor. Based on this characteristic, the axis-to-axis relationship may be appropriate among companies wishing to carry out a system-to-system collaboration. In addition, the axis-to-axis relationship may be appropriate when two companies have a separately purchased RHYTHM-GCM and have placed their axis motors.

There are differences between shaft motors and radio motors. In general, shaft motor capacities are superimposed on radio motor capabilities. The following Table provides an example of some of the differences.

TABLE Security An additional problem with a collaboration is the challenge of providing a comprehensive security. Before companies can collaborate effectively, the security issue needs to be examined. There can be many different facets to security in a collaborative context. A table of collaboration of any multiple companies must refer to all these different facets. The requirements for a collaborative security re may include that: exchange of data between the two partners should only be seen by the partners; that the data exchanged between the two partners must be invasion proof; a company must be able to verify that a partner is who says it is; the box should not introduce new security holes in the partners' network; and the table should be relatively easy to set up and administer.

A security collaboration system can be provided by implementing a comprehensive security strategy to address the aforementioned requirements. In an incorporation, the strategy has three different aspects for this: technological security, a frame allowance and data division.

The technological security can refer to the technological means used to guarantee security.

This security can be used to provide: privacy, certification and information integrity. The privacy ensures that no authorized person can see the data. Certification involves certification that the parties to the collaboration are really who they claim to be. Data integrity involves making it possible for an unauthorized person to modify the data that is being sent in any form. The precise security approach can be based on the relationship described above. For example, a schema is detailed in the following table: As can be seen from the table, all types of relationships, with the exception of axis-to-VAN EDI, can support security through SSL 3.0.

SSL 3.0 is an industrial standard protocol based on a public key coding of support over a soquet base connection and provides: privacy, client and server certification, information integrity and certificate handling. SSL 3.0 is a higher level protocol in which several public key cryptographic algorithms can be connected including the RSA and the Diffie-Helman.

Once the SSL greeting is completed, the next step is the user name-password word certification. This provides certification beyond what SSL 3.0 itself provides. Passwords can be stored using PKCS5 password-based encryption (an RSA standard). Once a user or speaker is certified, this is returned to an access sample. This access sample has a time life specifiable by the administrator. A user can then access the system for the duration of validity of the access sample. This has the beneficial effect of not requiring certification at each access. Each request which is accessed, certifies the access sample by validating the signature (which is a summary encoded using the private key of the security administrator) of the administrator of said security.

The technological security system is a part of the security scheme. The other part has to do with the design of the collaborations themselves. The system should allow companies to easily hold permits to various actions that other companies can carry out on it. The global collaboration workspace can support a hierarchical permission model with individual permissions attached to different data elements in the hierarchy. In particular, it can support permissions of reading, writing, taking and subscribing permissions of specific user and specific speaker. Therefore, companies can tune specifically who can read and what data, who can write what data, who can take that data and who can subscribe to write notifications about what data.

A third element in the security strategy of the collaboration system is the ability to divide the data through several collaborative workspaces. In particular, collaborative workspaces are divided into internal collaboration work spaces and an external collaborative workspace. Only the data that needs to be truly shared with the partners are in the external collaboration workspace. The rest is in the internal collaboration workspace. . The external collaboration workspace is designed to settle either outside the company's fire wall or in an extranet or DMZ.

Collaborative system design does not require the external collaboration workspace to make connections through the corporate fire wall in the internal network (even though it could do so).

In an incorporation, global collaborations can use both intern and external collaborative workspaces. Local collaborations can use only the internal collaborative workspace and therefore are completely invisible to the partner companies. Even for global collaborations only the relevant parties use the external collaboration work spaces. In addition, due to the permission system described above, each partner company can only see (read, write, take, subscribe) their own data.

Figure 8 is a block diagram of an embodiment of a security configuration for an axis-to-network and axis-to-radio case. As shown, a 50-axis enterprise is coupled to and communicates with an internal global collaboration workspace 52 and an external global collaboration workspace 54. A 56 radio company and a 58 network enterprise are connected through a 6C network server to the external global collaboration workspace 54. The company to speak 56, as the core company has an internal global collaboration workspace 62. Companies 50, 56 and 58 can be protected by the walls of associated fire, while the extranet formed by the network server 60 and the external global collaboration workspace 54 can be protected by a filtering director and communicate over HTTP over the SSL 3.0.

Figure 9 is a block diagram of an embodiment of a security configuration for a case d axis to axis. As shown, a 64-axis company and a 66-axis company can communicate through an SSL 3.0 protected by the TCP / IP connection. The communication may be between the global message brokers separated 68 and 69. Both companies axes 64 and 66 are protected by a fire wall, as shown.

Work Flows Between Companies One of the problems with the decision support of multiple companies may be that there is no closed-loop collaboration. Instead of this, the data can be obtained from one company to the next without a coherent workflow. In order to implement a closed-loop collaboration, the support to create multiple enterprise workflows is necessary. The present designer and global collaboration management can make it possible to build, deploy, monitor and change the workflows of sophisticated multiple companies.

In general, a "workflow" can be a set of "activities" linked together by data flows that together achieve some task. Workflows are typically executed on workflow engines. A "distributed workflow" can refer to a workflow that is executed on multiple workflow engines. In other words, different parts of the workflow are executed on different engines. A "node" can refer to abstract entities on which different workflow engines of a distributed workflow run, and a "node group" can be a set of nodes grouped by some characteristics. A "distributed workflow of multiple companies" can be distributed workflows where the nodes are companies.

The parameters of workflows can be important for the collaboration of companies. A "parametric workflow" is a workflow that is with parameters on some variable and can be regular or distributed. Putting in instances the parametric workflow with different values of the parameter variables produces different instances of the workflow. A "distributed workflow with parameters on nodes in a group of nodes" can refer to distributed workflows where the parameters on the workflow are the nodes in a node group. Therefore, when the workflow is put into instances it is made for a particular node in a node group.

There are several important features for the workflows that can be supported through the present global collaboration. These workflows can be strongly keyed. The strong keyboard is essential to produce error-free and robust workflows. In essence, the strong keyboard guarantees the type of a message at a designated time. For example, if the workflow is designed to be sent to a material account, then the strong keyboard ensures that it is physically impossible for an object other than a materials account to be sent. For a workflow designed with the global collaboration designer and executed with the global collaboration manager, it may be impossible to still send an object of the wrong type. This capability is important to produce error-free and robust workflows.

Despite the keyboard there are, for example, scenarios in which the wrong types of objects can conceivably be passed in the workflow: due to an error in the part of the designer of the workflow; and malicious attempt by someone to undermine the workflow. Both of these scenarios can be managed. The first can be managed by making it impossible for an error in the design to lead to such a scenario. The second can be handled by making the data flows tamper-proof by using a public-key cryptography or other coding scheme (integrity feature) as described above.

Another important feature is the support for workflows with parameter on groups. Some workflow of multiple companies involve a large number of companies. In such cases it becomes impractical to create individualized work flows for each partner. Instead of this it can be advantageous to create workflows that have a parameter on groups of partners. For example, in the branch of procurement, two groups can be primary suppliers secondary suppliers. The primary provider group can have a workflow type, and the secondary providers can have another type of workflow. Group-based workflows can be parametric in meaning, at a running time, a real workflow can be created specifically for a member of a group.

In the context of multiple companies, a company can collaborateFor example, hundreds or thousands potentially from other companies. Each collaboration or workflow of multiple companies can be potentially (and typically) unique. However, designing thousands of specialized workflows with business partners is neither desirable nor possible. On the other hand, many of these workflows are simply parametric variations on an underlying parameterized workflow. For example, a company A can be a collaborator (in sales) with retailers, distributors, sales managers, etc. Therefore, it makes sense to group the various partners. An example grouping can be: alMart, Sears; the rest of the retailers besides WalMart and Sear (group); primary distributors (group) and secondary distributors (group). Now, workflows with all the members, for example, of the group of primary distributors are variations on an underlying parametric distributed workflow, with parameters on the particular distributor and that group.

Workflows with parameters on a group can be supported with a workflow definition technique of HETEROCASTING. The HETEROCASTIN definition technique generally involves using a working flow definition with parameters to put heterogeneous work flows in instances based on differences in the parameters. Therefore, the definition technique of HETEROCASTING allows a non parametric distributed workflow that is easily made parametric (through a visual design tool) on nodes in a group of nodes. There may be two primary workflow activities used to achieve this definition: a HETEROCAST division activity and a HETREOCAST activity together. All activities between a HETEROCAST division and a HETEROCAST union have parameters on the nodes of a node group to which these activities correspond.

Figure 10 is a diagram of an incorporation of the design of a workflow between companies that includes the parameters on groups. As shown, the workflow can begin with a listening activity that waits for some event. The activity 70 can be linked to parallel activities 71 that link to a work sub-flow 72 and to a division of HETEROCAST 73. The sub-workflow itself can include a workflow definition. With respect to HETEROCASTING, the workflow after dividing HETEROCAST 73 becomes parameterized. Therefore, in the example of Figure 10, activity 74 is a co-parameter activity. After activity 74, a board of HETEROCAST 75 receives the flow from activity 74. Work sub-flow 72 and a board of HETEROCAST 75 are linked to a synchronous or asynchronous board 76 which, in turn, is linked to an integrated event 77 (for example, the multifragmented one). A workflow of Figure 10 can be designed using the global collaboration designer preser.ee and can allow a complete workflow representation for inter-firm decision support. This workflow can then be instantiated and implemented through the present global collaboration administrator.

Figure 11 is a diagram of an incorporation of the management change by modifying a design of a workflow. As shown, an initial workflow design can have an event 70 linked to a parallel activity division 71. Between activity division 71 and a board 76, there can be, for example, two activities 78. This workflow , once designed, it can be instantiated and implemented using the global collaboration manager. If a change needs to be made to the workflow, the global collaboration designer greatly alleviates the problem of making the change. For example, a new activity 79 can be added between division 71 and board 76. The workflow can then be centrally reinstated and implemented.

In particular, the HETEROCAST technique can allow the construction of parameterized distributed workflows over nodes in a node group. This can allow a huge productivity gain over the design of individual workflows for individual work members. In addition, this technique makes rapid design and prototype workflows among sophisticated companies with hundreds or thousands of potential partners. The technique must be distinguished from the "multielenco" in which identical messages are sent to the various nodes (partners). In essence, the multielenco allows the design of a unique workflow that runs identically through the multiple nodes. This differs from the HETEROCASTING technique, where workflows run differently based on which node of them should run.

A third important characteristic is the support for workflows based on paper or role. Paper-based workflows allow workflows to be specified using generic papers. This capability allows the creation of generic or tempered workflows that can be instantiated in various scenarios. For example, the types of paper can be: partner papers, radio papers; radio group papers; network papers; network group papers; user roles. As an example of the roles, the roles of partners refer to the different roles played by the partners. Therefore, a partner role in the case of procurement is the primary provider and secondary supplier.

Paper-based workflows can lead to the concept of three different phases in the design and execution of a workflow. The design phase is the phase in which paper-based workflows are defined. The phase of putting instances is the phase in which the papers are mapped to the instances. For example, the primary provider can be mapped to a first company, and the PO approver can be mapped to John Doe. Third, the run-time phase can be the phase in which the workflow runs with instances.

An additional important feature is the integration of automated workflows with user-oriented workflows. Workflows can often be described as having two varieties: automated system-to-system workflows, and user interconnection workflows. Even though there are workflows that are completely automatic, and there are workflows that are completely driven by the user, most workflows have elements of automated as well as user interconnection. The present administrator and global collaboration designer do not require making this artificial distinction between the types of workflow. Therefore, workflows can be automated in parts and interact with users elsewhere. Both automated parts and user parts can span multiple companies.

Integration with the outside world Figure 12 is a diagram of an incorporation of the integration of a workflow with the outside world.

As described in the previous section, work flows between companies and companies can be closed. These workflows can be composed of strong activities together in various configurations. There is no restriction on what different activities of the workflow can be done however, one of the main tasks of these activities is to integrate with the outside world. Figure 12 shows how a workflow can be integrated with the outside world using the component-based approach to integration. The components may include accessories 80, transformations 82, transfer objects 84, adapters and flows 86.

The global collaboration manager can support a component-based integration model. The component-based integration model allows flexibility in structuring the integration. There can be two types of components: the primitive components and the composite components. The primitive components may include accessories 80, the transformers 82 and the transfer objects 84. The composite components include the adapters and the flows 86. The composite components are constructed in terms of primitive components. In this scheme, the accessories 80 are used to access an external source such as SCP (SUPPLY CHAIN PLANER), an SAP, a relationship database, the network servers, the uses of email messages, etc. The accessories 80 can be used to read, write or listen to sources and data destinations. The transformers 82 can be used to transform the data from one form to another form. The transfer objects 84 are objects that can be passed from activity to activity or from company to company. The transfer objects 84 can optionally be converted to EDI, XML, CORBA, etc. structures. The fittings 80 and the transformers 82 can be joined together to form flows. A complete flow can be executed in a single activity as shown in Figure 13.

Figure 13 is a diagram of an incorporation of a data stream running in a single activity 92. As shown, a data source 90 may be accessible from and provide data to an accessor component 94. Accessor component 94 may then passing data through the transformer components 96 and 98 which provide data to a second accessor component 100. The data can then be stored in a data destination 102.

Figure 14 is a diagram of an incorporation of a division of data flow through multiple activities 104 and 106. As shown, the flow of Figure 14 differs from that of Figure 13 in that sense that the components of transformer 96 and 98 are within separate activities 104 and 106 and are communicated by a transfer object. The data flows of multiple companies can be based on the model of Figure 14 rather than that of Figure 13.

Figure 14A is a diagram of an object-oriented workflow incorporation for business collaboration including local memory object models. As shown, a workflow can be logically represented, as indicated by 170, or physically, as indicated by number 172. Logical workflow 170 can have a number of activities executed by particular companies in a flow of physical work 172. For example, a logical workflow 170 may comprise an activity 174 (Al) running in a first company (El) followed by an activity 176 (A2) running in a second company (E2). The logical workflow 170 may also comprise the additional activities 178 (A3) and 180 (A4) executing back on the first company (El). Therefore, the physical work flow 172 may comprise the activities (Al, A2, A3 and A4) executed on the first company 182 (El) and the activities (A2) executed on the second company 184 (E2). Furthermore, as shown, the company 182 may have an object model in memory 186 accessible by means of the activities (Al, A3 and A4) executed on the company 182. Similarly, the company 184 may have an object model in memory 188 accessible by the activities (A2) executed on the company 184. The respective access to object models in memory 186 and 188 allows the activities (Al, A2, A3, A4) to obtain information of objects as well as to create , modify and destroy objects.

According to the present invention, an execution workflow such as workflow 170, communicated information through the objects rather than documents com with the execution of the conventional workflow. This nature oriented by the workflow object 170 provides an increased functionality since the objects generally carry with them both data and behavior. In addition, allowing the activities (Al, A2, A3 and A4) within the workflow 170 to create, modify and access the shared memory object models 186 and 188 provides additional advantages. These advantages include maintaining the state and reducing the complexity of workflows by means of the workload in the object model in memory. Therefore, by embedding the object models in memory in the workflow machine in companies 182 and 184, each engine is allowed to have local access and control over the required information. For example, an object model in memory 182 or 184 can be a procurement model that models the procurement behavior in a supply chain where workflow 170 is related to the procurement process. In addition, object models in memory 186 can be accessed by activities that are part of the same instance and from the same workflow, multiple instances of the same workflow or instances of multiple workflows that are executed in enterprises. and 184.

The present global collaboration administrator can implement object-oriented workflows which pass objects as events and messages as opposed to passing simple documents. Such objects contain both data and behavior and are executable on the enterprise platforms that run the global collaboration manager. Using these objects, for example, events can be used to trigger or start workflows and can be sent to signal that a workflow has finished. Messages can send information between subsequent activities within a workflow. In this way, the global collaboration manager implements an object-centric workflow as opposed to a document-centric workflow. In addition, a transformation / access object model is exposed and allows developers to build object models in memory, as shown in Figure 14A, which are complemented by the workflow.

With respect to the transformations, in an incorporation, two fundamental types of transformation can be supported: the transformations based on I2-CDM and the direct transformations. Transformations based on I2-CDM are based on MODEL D? COMMON DATA of 12 TECHNOLOGIES (CDM). The common data model is an abstract scheme that is available in both relationship and object forms.

Figure 15 is a block diagram of an incorporation of a transformation model based on I2-CDM. As shown, transformers and accessors can be coupled to transform application data into a common data model data object 110 and vice versa. For example, a SUPPLY CHAIN PLANNER (SCP) object can be created by a supply chain glider accessor from the supply chain glider data 114. The supply chain glider object 112 can then be transformed by a CDM supply chain glider transformer in a CDM 110 object. Similarly, an SAP 116 object can be created by an SAP accessor from the SAP 118 data. The SAP 116 object can then be transformed by an SAP-CDM transformer in a CDM 110 object. The SAP accessor and the SAP transformer, as with other accessors and transformers, can be combined into a standard SAP-CDM 120 adapter that can be used for CDM-based transformations of other components. As another example, a BAAN object 122 can be created by a BAAN accessor from BAAN data 124. The BAAN object 122 can then be transformed into a CDM object 110 by means of a BAAN-CDM transformer. These transformers work in another direction too.

Figure 16 is a diagram of an embodiment of a direct transformation. In direct transformers, objects are converted from one form to another without passing through an intermediate format. For example, as shown in Figure 16, the supply chain glider (SCP) data 130 can be accessed by an SCP accessor to create a supply chain glider object 132. The supply chain glider object 132 can then be transformed directly to a FACTORY PLANER (FP) 134. The factory glider object 134 can then be converted to the factory glider data 136 through a factory glider accessor. This data flow can operate in another direction as well.

In these processes, there are several levels of granules whose access and transformation can take place including the relation (table), the generic object (tree, graph, matrix, etc.), a specific object (material account, plan, etc.) . Sometimes access can only be available at one level (say table) but transformations may be more appropriate at another level (say generic object). For example, the hierarchical aggregate (a form of transformation) is often appropriate over a tree object. However, the data may only be accessible in a tabular form. In this case, for example, the data must be accessed at the tabular level, transformed into a tree and then have the hierarchical aggregate applied to it.

Figure 17 is a diagram of an incorporation of different levels of access and transformation. As shown, access and transformation can have three levels. A first level 140 involves table access and transformations. A second level 142 can involve a generic object (tree, graph, etc.) access and transformations and a third level can involve a specific object (construction of materials, plan, etc.) access and transformations. In addition to the transformations between application formats, there may be transformations between the three levels as shown.

Figures 17A and 17B are diagrams of an incorporation of data access and transformation allowing the data to be manipulated in various formats during the execution of the workflow.

As shown, Figure 17A presents a detailed access model implemented within the global collaboration manager to provide access and manipulation of data in various formats. As mentioned above, objects 190 are generally used to communicate information between activities in the execution of the workflow. As a result, the primary data format is based on the object. As shown, the objects 190 can be of various types of elementary objects 192 including file, stream, hack, DCOM and OODM. These types of external objects can be directly accessed both as sources and destination. However, other derived object formats are supported to provide flexible handling of data in various native formats such as EDI 194 data, XML data 196 and relationship data 198. For each derived and supported format, there may be a object of derived format (DFO) which comprises an object construction of the corresponding format. The supported derived formats (DFOs) can comprise an EDFO DFO 200, an XML DFO 202 and a DFO of relation 204. It should be understood that the elementary formats 194, 196 and 198 can be extracted to their respective derived format objects (DFOs) and objects 190 as necessary.

Figure 17B is a diagram of a detailed transformation model using the objects and derived format objects discussed above. As shown, an object 206 can be passed directly between two activities. In addition, the data can be passed between the activities as derived format objects 207. Furthermore, the data can be passed in elementary data formats 208. In general, this scheme can involve two categories of supported transformations. The first is a direct transformation in which the format objects are directly transformed providing efficient transformation and order. A second transformation is a common data model transformation where the format objects are transformed through an intermediate representation mentioned as a common data model (CDM). The transformations are also described above with respect to Figures 13-16. This information manipulation access system provides a considerable flexibility for the communication of data between workflow activities for the collaboration of multiple companies.

Deployed Collaborations An important factor in a collaborative system of multiple companies is the ease with which collaboration can be deployed. As discussed, the present global collaboration manager can support four different kinds of partner relationships: from axis to network, from axis to radio, from axis to axis and from axis to-YAN-EDI. Of these four, the axis to network relationship has all the deployment characteristics of traditional network applications. The a-VAN-EDI axis relationship can be deployed to the extent that it levels an existing VAN-EDI infrastructure. Even though the relationship from axis to network is highly deployable, it may suffer from the problem of requiring a human on the network side of the relationship. In other words, it may not be suitable for a system-to-system collaboration.

The axis-to-radio solution can provide maximum deployment in the system-to-system collaboration environment. In the axis-to-radio field, the radio engine is analogous to the network browser, and the radio portion of the collaboration is analogous to the network page. Similar to a network page, the radio part of the collaboration can be centrally designed and deployed to remote radio engines. Unlike the web page, there may still be integration that requires doing remotely. This remote integration may be inevitable but it can be circumscribed and defined precisely by the radio part of this collaboration.

Another aspect of the deployment is the version management. Collaborations once designed and deployed are feasible to require change (in different ways) over time. It may be important that subsequent versions of collaborations are easily deployable as initial versions. The present global collaboration administrator can provide full support for the versions and centralized redeployment of the collaborations. further, the different versions of the collaborations can run simultaneously without impairing one another. This allows an existing version to be phased amusingly while another version is phased inward.

Another element of the deployment of this global collaboration manager is the leveling of existing infrastructure. This element is evident, for example, in the support of the network to radio relationship over the existing network protocols. The support of axis to radio on the existing network protocols can be important for the rapid deployment since information or reconfiguration of an existing network infrastructure is not required. A large time savings in this aspect can come from not having to carefully modify the fire wall and safety infrastructures that may already be in place.

Many-to-Many Collaborations Support The present network and radie architecture provides easy administration and deployment. Sir. However, in practice, companies collaborate with many companies which in turn collaborate with other companies. Therefore, companies often form a graph or collaboration network. This can be supported through the ability to replace an axis motor with a network motor er. a given moment. This capacity for substitution allows networks to collaborate with many to grow organically rather than all at the same time.

Figure 18 is a diagram of an embodiment of the replacement of an axle motor by a network engine within a collaboration. As shown, a company (El) can deploy a 150-axis motor on itself and a radio engine 152 on all partner sites. In particular, a radio engine 154 can be a partner site (E2). If the partner site (E2) wishes to design and control its own collaborations, it can replace the radio engine 154 with an axis motor 156. From El's perspective, E2 can still be a radio in the El collaboration. However, this radio now runs on an axis motor 156 which can control its own collaborations with radio engines 158. In addition, the radio engines 160 and 162 can be associated with a third entity (E3) that interacts with both the motor of axis 150 and the motor of axis 156 to name of the company E3.

System Extension An important aspect of the present system is its extension. Without extension, the system may not be able to handle new situations and challenges with which it is confronted. There may be several different dimensions to this extension. For example, a primary area of extension is in the area of semantic object standards. If the standards supported are not sufficient for a particular problem, then the system can be augmented with new semantic standards. Additionally, the system allows the construction of proprietary semantic standards. In addition, the system can be extended by adding new accessors, transformers, adapters, etc. The standard component library can be extended to both generally and by end users.

Although the present invention has been described in detail, it should be understood that various changes, substitutions and alterations may be made thereto without departing from the spirit and scope of the invention as defined by the appended claims.

Claims (6)

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

1. A process implemented by computer for the collaboration of companies that includes: designing a workflow, the workflow includes at least one heteroelenic division and at least one heteroelenco union; the heteroelenc division and the heteroelenc junction allows at least one activity that is subject to parameters, at least one of the parameters comprises nodes within a node group; the instances of the workflow so that at least one activity is put into instances as a plurality of jobs each tailored to a particular node in the node group; deploy the workflow including the distribution of activities over the nodes in the node group; execute the workflow to provide the collaboration of multiple companies.

2. A process implemented by computer for the collaboration of multiple companies that includes: put in instances a workflow oriented by the object, the workflow oriented by the object includes objects associated with activities that are going to be carried out within the workflow; deploy the objects of the object-oriented workflow across the boundaries of companies to node over which the associated activities are going to be carried out; execute the objects deployed to provide the collaboration of multiple companies, the communication data of activities using objects that carry out behavior data.

3. The process implemented by computer as claimed in clause 2 characterized in that it also comprises creating the object models in memory in one or more nodes so that the objects that are executed in one or more nodes can access the object model in memory.

4. A computer-implemented process for data access and transformation for an object-oriented workflow comprising: support the communication of objects as a primary data format; support the construction of objects in a way derived from underlying native data formats; support transformations between native data formats, derived from format objects and objects; communicate information between activities a workflow using objects and objects of derived format and using transformations between native data formats, derived format objects and objects.

5. The process implemented by computer as claimed in clause 4, characterized in that the supported objects comprise file objects, current objects, CORBA objects, DCOM objects and OODBM objects.

6. The computer-implemented process as claimed in clause 4 characterized in that the supported derived format objects are constructed from native data formats comprising EDI data, XML data, relationship data. SUMMARY A computerized process for collaborating with multiple companies includes designing a workflow that has at least one heterogeneous division and at least one heterogeneous board. The heteroelenic division and the heterogeneous junction allows at least one activity that is with parameters, at least one of the parameters includes nodes within a group of nodes. The workflow is in instances so that the activity is and instances as a plurality of activities each made for a particular node in the group of nodes. Workflow is deployed including distributing activities over the nodes in the group of nodes and executed to provide multiple enterprise collaboration. In another incorporation, an object-oriented workflow includes objects associated with activities that are to be carried into the workflow that is instantiated. Objects are deployed, across enterprise boundaries to nodes in which associated activities are to be carried out, and s executed to provide multiple enterprise collaboration. The activities communicate data using objects to carry out both data and behavior.