MXPA00012058A - Improved method and system for providing client callbacks through a firewall within and between enterprises - Google Patents

Abstract

A system for providing client callbacks includes a client having a client application and a client firewall operable to block a client callback to the client application from a server. The server includes a server firewall and a server workspace. The server workspace has data protected by the server firewall and a permissibility framework associating a predefined type of the data with the client application. The server workspace is operable to generate a client callback for the client application in response to the presence of the predefined data type. A server-side proxy is operable to provide the client application access to the server workspace through the server firewall. The client application is operable to connect to the server workspace via the server-side proxy to receive the client callback.

Description

METHOD AND IMPROVED SYSTEM FOR PROVIDING CALLS RETURN OF CLIENT THROUGH A WALL AGAINST FIRE INSIDE AND AMONG THE COMPANIES.

TECHNICAL FIELD OF THE INVENTION This invention relates generally to the field of the supply chain of the company and the planning site and more particularly to an improved method and a system for providing calls back from the customer through a fire wall within and between Business.

BACKGROUND D? THE INVENTION.

The supply chain, business and site planning applications and their environments are widely used by the manufacturing entities for decision support and for aid management operations. The decision support environments for the supply chain, for the company and for site planning have evolved from single-domain, monolithic environments to 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 handle complex 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 step to evolve it for the planning environments to establish a heterogeneous architecture of multiple domains that supports the multiple product extension domains as well as the engines and multiple extension products. The integration of the various planning environments into 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 tracking the traces of transactions. In particular, the RHYTHM family of products available from 12 TECHNOLOGIES provides optimized functionality. However, with respect to planning in a company or at the supply chain level, many conventional applications, such as those available from SAP, use Enterprise Resource Planning (ERP) engines and do not provide optimization.

The success or failure of a company can depend to a large extent on the quality of decision making within the company. Therefore, decision support software, such as the RHYTHM family of 12 TECHNOLOGIS products, that support optimal decision making within companies can be particularly important to the success of the company. In general, optimal decisions are related to the domain of decision support where the domain is the extension of the "world" considered to reach the decision. For example, the decision that is being made may be how much of a given article 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 entire company or the supply chain of multiple companies. (These last two can be considered knowing the larger domains or the multiple domains). Typically, the larger the domain of decision support, the more optimal the decision will be. Consequently, it is desirable for decision support software to cover even larger domains in the decision making process. However, this expansion of coverage can create significant problems.

One problem is the efficient sharing of information among a large number of domains, each of which is typically protected by a fire wall. Existing methods typically use a substitute for each fire wall. The substitutes are remotely accessed to provide a path through the walls against fire. The use of such substitutes to each client in relation to a large domain system, however, is scostot time consuming since each client requires individually testing and implementing the substitute on their system. In addition, many customers are reluctant to implement such substitutes.

SYNTHESIS OF THE INVENTION.

According to the present invention, a method and system for providing back-to-back calls from a fire wall within and between companies are provided to essentially reduce and eliminate the disadvantages and problems associated with previously developed systems and methods. In particular, the present invention provides a method for enabling callbacks from the client in the absence of client-side substitution processes.

In one embodiment of the present invention, a system for providing customer return calls includes a client having a client application and a fire wall of operable client to block a client back call to the client application from a server . The server includes a fire wall server and a server workspace that has data protected by the fire wall of the server and a permission system that associates a predefined type of data with the client's application. The server workspace is operable to generate a call back from the client to the client application in response to the appearance of the predefined data type. A server-side substitute is operable to provide client application access to the server workspace through the server firewall. The client application is operable to connect to the server workspace through the server-side substitute to receive the call back from the client.

More specifically, in accordance with an embodiment of the present invention, the client application is operable to periodically connect the server through the server-side substitute to receive any call back from the client and to disconnect from the server at the server. absence of the client's return call. In another incorporation, the client application is operable to remain connected to the server through the server-side substitute and to download the predefined data type to any call back from the client.

The technical advantages of the present invention include providing an improved system and method for providing customer return calls through fire walls within and between the companies. In particular, the client's return calls are received by a client application by periodically putting them together or remaining connected to the server. As a result, calls back to the client are provided without the cost associated with employing individual client-side substitute processes for each client node. Therefore, the data; they are efficiently shared within and between the distributed nodes of one or more companies.

The additional technical advantages should be readily apparent to an expert 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; an architecture implemented by computer 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 an axis-to-axis case; Figure 10 is a diagram of an incorporation of the design of a workflow between companies that includes the formation of parameters on groups; Figure 11 is a diagram of an incorporation of change management by modifying a design of a workflow; Figure 12 is a diagram of an incorporation of the integration of a workflow 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 a division of data flow through multiple activities.

Figure 15 is a block diagram of an incorporation of a base transformation model of the common data mode.

Figure 16 is a diagram of an embodiment of a direct transformation.

Figure 17 is a diagram of an incorporation of different transformation and access levels.

Figure 18 is a diagram of an incorporation of the replacement of an axle motor by a radio engine within a collaboration.

Figure 19 is a block diagram of an embodiment of a computer system employing a working space configured according to the teachings of the present invention.

Figure 20 is a tenuous diagram an embodiment of the workspace of Figure 19 configured according to the teachings of the present invention.

Figure 21 is a block diagram illustrating the client and server fire walls within the overall collaboration framework according to an embodiment of the present invention.

Fig. 22 is a flowchart illustrating a method for providing return calls from the client according to an embodiment of the present invention; Fig. 23 is a flowchart illustrating a method for providing return calls from the client according to another embodiment of the present invention.

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 for the realization of 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, er. situations of multiple domains (such as business units within a company or multiple companies), different domains frequently operate different decision support software. Also, in multiple domain situations, a domain can not usually 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.

The provide a decision support. In multiple domain situations mediants can be achieved by pursuing a collaborative approach for decision support rather than 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. In this way, there is no 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 HRRP 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 global collaboration system diagram of Figure 2 wherein certain software elements that constitute 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 8 motor, in the radio engine 8, in the user-axis user interconnection (VI), in the user-user interconnection and in 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 13. The axis node 18 can also be coupled to and communicate with a plurality of radio nodes 24 which can be processes within of a radio engine running 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 shaft 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 motor drives. Multiple yarn that can simultaneously coordinate multiple collaborations as well as multiple versions of the same collaboration. In addition, the axis motors can dynamically check 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 local system 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 collaborative workspace 30 by one entity and be retrieved by another entity. The recovery can be achieved either by question or by subscription. In this way, 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 is dropped 30.

The decision as to whether to use the memory or persistent slots may depend on the application. The global collaboration workspace 30 stores the data in the form of objects and can store JAVA objects, CORBA objects or an arbitrary BITE array, this, coupled with its in-memory capabilities, makes the overall collaboration work space 30 appropriate as a mechanism for sharing high-speed data between 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 and radio network for collaborations and design the events and messages of: collaboration. The global collaboration designer can integrate a standard object library and a standard component library for easy use from within the overall collaborative design. The global collaboration designer p > It can be used to create workflows of multiple sophisticated companies with synchrony to synchrony, their workflow and divisions or -divisions, unions-synchronization, divisions- heterofundido, heterofundido unions, 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 an incorporation. n of life cycle 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 the global collaboration manager. After the deployment, the collaboration can be run using the global collaboration manager 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 flow 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 which the data / object is sor-encoded. Examples include XML, Java series streams, IIOP series streams and the electronic data exchange format. The transport standards are used to pass data, these can include HTTP, I10 ?, RMI, DCOM, FTP, value-added networks, messaging buses; e asynchronous 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, 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.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. Electronic data exchange can be supported because this is generally the most popular semantic standard. However, he suffers from the disadvantage (among others) of not providing deep coverage of the planning domain. The RHYTHM-CDM, on the other hand, provides the deep coverage of the planning domain and will provide 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 the 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, this 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: they 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 RELATIONSHIP TYPES 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 administration can be centralized on the server side. However, it is: 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 network-electronic data exchange relationship, the vast majority of electronic commerce between companies currently 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 over 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 regard to the axis-to-radio ratio, this type of relationship also allows for 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, 12 -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 ratio of axis to radius that can be displayed centrally by the axis company.

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 for security in a collaborative context. A collaboration chart of any multiple companies must refer to all these different facets. The requirements for a collaborative security network may include that: data exchange between the two partners should only be seen by the two partners; that the data exchanged between the two partners should 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, verification, and information integrity. The privacy ensures that no unauthorized person can see the data. Authentication involves authenticating that the parties to the collaboration are really who they claim to be. Data integrity involves making it impossible for an unauthorized person to modify the data that is being sent in any form.

The precise safety approach may vary based on the type of relationship described above. For example, a schema is detailed in the Table below: TABLE As can be seen from the Table, all types of relationships, with the exception of the EDI value-added axis-to-network, can support security from SSL 3.0.

SSL 3.0 is an industry standard protocol used to support public key encryption over a socket-based connection and provides: privacy, client and server certification, data integrity and certified handling. SSL 3.0 is a higher level protocol in which several public key cryptographic algorithms can be connected including RSA and Diffie-Helman.

Once the SSL greeting is completed, the next step is authentication of the keyword of the user's name. This provides certification beyond what SSL 3.0 itself provides. Keys can be stored using keyword-based coding PKCS5 (an RSA standard). Once a user or radio is certified, it 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 the validity of the access sample. This has the beneficial effect of not requiring certification for each access. Each application 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 safety box is a part of the safety scheme. The other part has to do with the design of the collaborations themselves. The table should allow companies to easily give permits to various actions that other companies can carry out. 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 read, write, take and subscribe permissions of specific user and specific speaker. Therefore, companies can fine-tune in detail who can read and what data, who can write what data, who can take what data and who can subscribe to write notifications about what data.

A third element in the collaboration framework's security strategy is the ability for data sharing across multiple collaborative workspaces. In particular, collaborative workspaces are divided into an internal collaborative workspace and an external collaborative workspace. Only the data that requires being truly shared with the partners are in the external collaborative workspace. The rest is in the internal collaborative workspace. The external collaborative workspace is designed to sit either outside the corporate fire wall or in a DMZ or find you. The collaborative framework design does not require the external collaborative trailing space to make decisions through the corporate firewall on the Intranet (even though it could do so).

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

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

Figure 9 is a block diagram of an embodiment of a security configuration for an axis-to-axis case. As shown, a 64-axis company and a 66-axis company can communicate over a protected TCP / IP SSL 3.0 connection. The communication can be between the separate global message agents 68 and 69. Both companies of axis 64 and 66 are protected by a wall of fire, 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, data can be thrown from one company to the next without a coherent workflow. In order to implement a closed-loop collaboration, support is needed to create workflows for multiple companies. The current administrator and global collaboration designer makes it possible to build, deploy, monitor and change workflows of multiple sophisticated 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, the different parts of the workflow are executed on different machines or engines. A "node" can refer to the abstract entities on which different workflow engines run from 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 parameterization of workflows can be important for the collaboration of companies. A "parametric workflow" is a workflow that is parameterized over several variables and can be regular c distributed. The instantiation of the parametric workflow with different values of the parameter variables produces different instances of the workflow. A "distributed workflow parametized over nodes in a node group" can refer to distributed workflows where the workflow parameters are the nodes in a group r.odo. Therefore, when the workflow is instantiated it is made for a particular node in a node group.

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

Despite the strong typing there are, for example, two scenarios in which incorrect types of objects would be conceivably passed in the workflow: due to an error on the part of the designer of the workflow; and a malicious attempt by someone to harm the work flow. Both of these scenarios can be managed. The first can be handled by lacer impose that a design error leads to such a scenario. The second can be handled by making the data flow to proof of violation by using a public key encoding or other coding scheme (characteristic integrity) as described above.

Another important characteristic is the support for the workflows parameterized on the groups. Some workflows of multiple companies involve a large number of companies. In such cases, it would be impractical to create individualized workflows for each partner. Instead of this it can be advantageous to create workflows that are parameterized on groups of partners. For example, in the field of procurement, two groups can be primary providers and secondary suppliers. The primary provider group can have one type of workflow and the secondary provider group can have another type of workflow. Group-based workflows can be parametric in the sense that at the time run, a current workflow can be created specific to a member of a group.

In the context of multiple companies, a company can collaborate, for example, with hundreds or thousands potentialmer.ee of other companies. Each collaboration or workflow of multiple companies can be potentially (and typically) unique. However, designing hundreds or 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 trending flow. For example, a company A can be a collaborator (in sales) with retailers, distributors, direct sales, etc. Therefore, it makes sense to group the various partners. An example grouping can be: WalMart, Sears, - the rest of the retailers besides WalMart and Sears (group); primary distributors (group) and secondary distributors (group). Now, the workflows with all the members, for example, of the group of primary distributors are variations on an underlying parametric distributed workflow, parameterized on the particular distributor in that group.

Workflows that are parameterized on groups can be supported by a HETEROCASTING workflow definition technique. The HETEROCASTING definition technique generally involves using a workflow definition with parameters to initiate heterogeneous workflow based on differences in the parameters. Therefore, the HETEROCASTING definition technique allows a distributed workflow not in parameters to be easily done (through a visual design tool) with parameters on nodes in a node group. There may be two primary workflow activities used to achieve this definition: a HETEROCAST split activity and a HETEROCAST linked activity. All the activities between divided HETEROCAST and the HETEROCAST junction are set on 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 an inter-company workflow that includes putting parameters on groups. As shown, the workflow can begin with a listening activity 70 waiting for an event. The activity 70 can be linked to the parallel activities 71 that link to a sub-workflow 72 and to a division of HETEROCAST 73. The sub-workflow itself can include a workflow definition. With respect to HETEROCASTING, the workflow after the HETEROCAST 73 division is done with parameters. Therefore, in the example of Figure 10, activity 74 is an activity with parameters. After activity 74, a joined HETEROCAST 75 receives the flow of activity 74. The sub-workflow 72 and the bound HETEROCAST 75 are linked to a synchronous or asynchronous union 76 which, in turn, links to an event integrated 77 (for example, multi-delivery). A type of workflow of the Figure 10 can be designed using the present global collaboration designer and can allow a complete representation of the workflow for decision support between companies. This workflow can then be instantiated and implemented through the present global collaboration administrator.

Figure 11 is a diagram of an administration change incorporation 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. There can be, for example, two activities 78 between the activity division 71 and a union 76. This workflow, a Once designed, it can be instantiated and implemented using the global collaboration manager. If a change to the workflow is required, 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 union 76. The workflow can then be reinstated and implemented centrally.

In particular, the HETEROELENCO p > It can allow the construction of distributed workflows and with parameters on nodes in a node group. This can allow a huge productivity gain over the design of individual workflows for members of individual groups. In addition, this technique makes a rapid design and prototype of workflows between sophisticated companies with hundreds or thousands of possible partners. The technique must be distinguished from the conventional "multi-part" in which identical messages are sent to the various nodes (partners). In essence, multireparting allows a person to design a unique workflow that runs identically through multiple nodes. This differs from the HETEROELENCO technique, where workflows run differently based on which node is running.

A third important characteristic is the support for workflows based on distribution. Workflows based on the distribution allow these workflows to be used specifically for generic deals. This capability allows the creation of generic or tempered workflows that can be instantiated in various scenarios. For example, the types of roles or distribution may be: partner roles, axle roles; radio group papers; network papers; network group papers; user roles. As an example of the roles or distributions, the socics papers refer to the different roles or characters played by the partners. Therefore, a role of partner in the case of procurement is that of primary provider and secondary supplier.

Work-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 workflows based on distribution are defined. The phase of the instance is the phase in which the distributions are mapped to instances. For example, the primary provider can be mapped to a first company, and the approver_PO can be mapped to John Doe. Third, the run-time phase may be the phase in which the work-in-run flow runs.

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 when there are workflows that are fully automated, there are workflows that are completely user-driven, most workflows have automated interconnection elements as well as user interconnection. The present global collaboration of administrator and designer does 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, workflows can be created between companies and within companies. These workflows can be composed of activities tied together in various configurations. There is no restriction on what different activities of the workflow can do, 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 a component-based approach to integration. The components may include accessors 80, transformations 82, transection 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: primitive components and composite components. Primitive components may include accessors 80, transformers 82, and transient objects 84. Compound components include adapters and flows 86. Compound components are constructed in terms of primitive components. In this scheme, accessors 80 are used to access an external source such as SCP (supply chain planner), SAP, a relationship database, network servers, e-mail, message buses, and so on. . Accessors 80 may be used to read, write or listen to data sources and destinations. The S2 transorders can be used to transform the data from one form to another form. Transfer objects 84 are objects that can be passed from an activity to an activity or from a company to a company. Transfer objects 84 can optionally be converted to EDI, XML, CORBA, etcetera. The accessors 80 and the transformers 82 can be tied 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 can be accessible from and provide data to an accessor component 94. The accessor component 94 then it can pass 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 data flow division through multiple activities 104 and 106. As shown, the flow of Figure 14 differs from that of Figure 13 in that the components of Transformer 96 and 98 are within separate activities 104 and 106 and communicate with a transfer object. The data flows of multiple companies can be based on the model of Figure 14 rather than that of Figure 13.

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

Figure 15 is a block diagram of an incorporation of a transformation model based on 12 -CDM. As shown, transformers and accessors can be coupled to transform a data application into a CDM data object 110 and vice versa. For example, a supply chain planner (SCP) object 112 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 supply chain glider transformer-CDM into a CDM 110 object. Similarly, an SAP 116 object can be created by an SAP data accessor SA? 118. The SAP 116 object can then be transformed by an SAP-CDM transformer into a CDM 110 object. The SAP accessor and the transformer, as with other accessories and transformers can be combined into a standard SAP-CDM 120 adapter that can be used for transformations based on CDM and other components. As another example, a VAAN 122 object can be created by ur. VAAN accessor from VAAN data 124. The VAAN object 122 can then be transformed into a common data model object 110 by a VAAN-CDM transformer. These transformations work in another direction as well.

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 an SCP object 132. The supply chain glider object 132 can then be transformed directly in a factory glider (FP) object 134. The far glider object 134 can then be converted into 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 granulation to which access and transformation can take place including the relation (table), the generic object (tree, graph, matrix, etc.) and the specific object (material account, plan, etcetera) to levels. Sometimes access can only be available at one level (say table) but the transformation 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 can 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 may involve transformations and access to the table. A second level 142 may involve an access and transformations of a generic object (tree, graph, etc.) and a third level may involve a specific object access (construction of materials, plan, etc.), and transformations. In addition to the transformations between the application formats, there may also be transformations between three levels as shown.

Development of Collaborations An important factor in a multi-company collaboration system 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 value-added network-EDI. Of these four, the network axis has all the characteristics of deploying traditional network applications. The EDI value added axis-to-network can be deployed to the extent that it levels an existing EDI-value added network 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 realism from axis to radio, the radio engine is analogous to the network browser, and the radio part of the collaboration is analogous to a network page. Similar to the network page, the radio part of the collaboration can be designed centrally and deployed to remote radio engines. Unlike the network page, there may still be integration that needs to be done remotely. This remote integration may be inevitable but it can be circumscribed and defined precisely by the network part of the collaboration.

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

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

Many-to-Many Collaborations Support The present radio-to-axis architecture provides easy administration and deployment. However, in practice, companies collaborate with many companies which in turn collaborate with other companies. Therefore, companies often form a graph or collaborative network.

This can be supported through the ability to replace an axle motor with a radio engine at any time. This substitution capacity allows many to many collaborative networks to be organically grown rather than all at once.

Figure 18 is a diagram of an incorporation of the replacement of a network engine by a radio 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 collaboration, it can replace the radio engine 154 with an axis motor 156. From El's perspective, E2 can still be a radio in the collaboration of the However, this radius now runs on an axis motor 156 which can control its own ccr collaborations. the radio motors 158. In addition, the radio masters 160 and 162 may be associated with a third entity (E3) which interacts with both the hub motor 150 and the spindle motor 156 in the name of the company E3.

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

The present invention provides an improved method and system for supporting remote company client return calls as well as return calls from internally protected regions of a single enterprise. Generally described, the present invention provides a computer-implemented process for returning calls from clients from a workspace and in the use of substitute processes on the client side. As a result, customer return calls are provided without the hassle associated with the use of individual client side substitute processes for each client node. Therefore, the data is efficiently shared within and between the distributed nodes of one or more companies. Figure 19 is a block diagram of an incorporation of a computer workspace 200 into a computer system 205. The computer workspace 200 includes a probability of memory slots 210 in communication with a permission system 220 and an event manager 230. The computer workspace 200 is accessed by the network nodes 240 through the network 250. Generally, the permission system 220 controls access to the memory slots 210 within the computer workspace 200 by the network nodes 240. The event manager 230 generates events for the network nodes 240 in response to the conditions associated with the data or objects that are stored er. the memory slots 210.

The network 250 comprises any combination or number of axes, routers, bridges, gates, switches or any other association of suitable communication devices and the related software that transmits data between the network nodes 240. In one embodiment, the network 250 comprises a network implemented independently or in relation to a wide area network (WAN) or a local area network (LAN), such as the Ethernet network, a sample ring network or an interconnected network of distributed fiber data; (FDDI). Network 250 supports protocols without higher-level connection such as internet protocol (IP), higher level connection oriented protocolor such as the frame relay, or any other suitable network protocol. Network 250 can be used er. a multiple company collaboration to implement workflows including activities that take place between more than one company. Each network node 240 of network 250 in a multi-company collaboration can be associated with a different company, allowing the communication and coordinated operation of activities and workflows between companies.

The network nodes 240 may be a network endpoint, a peripheral device, terminal, server, client, hub, radio, or other device connected to the network 250. Each network node 240 is associated with a particular company. The network nodes 240 may or may not participate in a particular workflow, activity or other process. Network nodes 240 can access workspace 200 as part of a workflow or collaboration or as part of other activities or processes not associated with a workflow or collaboration.

Each memory slot 210 can store data and objects. As used here, each means each by a subset of the identified items. Objects can be JAVA objects, C ++ objects, CORBA objects, or other structures that are capable of storing both information and behavior. The memory slots 210 may be any memory structure, whether accessed in queue or randomly, capable of retaining data or objects. Memory slots 210 may include such as, for example, any data structure, or memory array. The memory slots 210 may, for example, contain a probability of objects queued within the memory slots 210 or may contain only a single object. The memory slots 210 can be stored in a disk or other storage medium can be kept in the memory during any process their activity is to carry them out by the computer system 205. The memory slots 210 held in the memory can be stored in the memory. the random access memory for example, by increasing the speed at which its contents are accessed over the memory slots 210 that can be stored in a disk or peripheral component. Many memory slots 210 which are associated with a disk or other storage medium are accessible at a lower storage medium speed than the memory branches 210 which are stored in memory but which are non-volatile allowing storage of the memory. persistent data or objects The memory slots 210 can be arranged in an organization hierarchy defined by a programmer, user, or other suitable mechanism, such hierarchy allows easy categorization of and with reference to the memory slots 210 as described below. with reference to figure 20.

The permission system 220 maintains and controls access to the memory slots 210. The permission system 220 may include any combination of apparatus and software capable of maintaining the access rights to the memory slots 210 and controlling access to the memory slots 210. 210 slots based on the access rights maintained. In an embodiment, the access rights include the right of a node to: read from the contents of each of the memory slots 210, write to the contents of each of the memory slots 210, remove any of the contents for each of the memory slots 210 and subscribe to and not subscribe to the event nortification for one or more specified memory slots 210.

The event manager 230 generates events for the nodes 240 in response to a particular modification within the memory slots 210. The event manager 230 may include any combination of apparatus and software capable of generating events and initiating the address of such events. to a particular network node 240 or other suitable computer system element 205. Network nodes 240 having access rights to subscribe to an event notification for a particular memory slot 210, as determined by the permission system 220 and exercising such a subscription to the particular memory slot 210 are notified by events generated by the event manager 230 each time a notification that requires a modification that is related to the particular memory slot 210 occurs.

For example, one of the network nodes 240 may have access rights to subscribe to the notification for a particular memory slot 210, as verified by the permission system 220 may subscribe to the notification for the particular memory slot 210 each once the particular memory slot 210 is written by one of the network nodes 240. Until one of the network nodes 240 waives the subscription of the notification for this particular slot, each time the particular memory slot 210 is written by one of the network nodes 240, the message manager 230 will send the message and initiate the address of such message to the node 240 indicating that the particular memory slot 210 has been written.

One embodiment, the access rights to subscribe and waive the subscription, the notification of events by a particular memory slot 210 may vary based on the classification of an event. For example, a particular network node 240 may have the subscription rights to be notified when a particular memory slot 210 has removed the data but not when the same memory slot 210 has been written to it, or when the network node 240 may have subscription rights to both, or the subscription may encompass the notification in response to entries being removed or written in such memory slot 210. The access rights granted by the permission system 220 and the subscription of messages from the event manager 230 may also be maintained in a suitable combination. For example, the notiofication of slots can be subscribed to and for a single memory slot 210, all memory slots 210 or a sub-set of memory slots 210 selected based on the indicated criteria. Similarly, access rights may be granted per system 220 to all memory slots 210 or any sub-game thereof.

Figure 20 illustrates an embodiment of the workspace illustrated in Figure 19. Work space 300 is a workspace for storing data and objects in memory slots 310 that are arranged in a hierarchical system. The exact nature of the hierarchy and the placement of the memory slots 310 within the system is definable by a workspace administrator, by another user or by another suitable mechanism.

Generally, workspace 303 is organized into sections 305 that are generally separated into individual memory slots 310 and groups 320, Groups 320 may in turn contain memory slots 310 and / or be separated into additional subgroups. . In Figure 20, the memory slots 310 are designated by section number, group number or subgroup number if applicable, and are then designated by s and by an identification number within the applicable section 305 or group 320. For example, the memory slot 310 identified by the nomenclature "section 2.grupol.s2" denotes the second slot of group 1 of section 2 of the workspace. The slot can be in sequence. Another hierarchy or organizational scheme can be replaced by the hierarchy described here. Such a hierarchy as described allows grouping and easily cataloging the memory slots 310. Such a catalog can be used to easily catalog the memory slots 310 for the purposes of maintaining access rights. For example, a network node 240 of Figure 19 can only grant a right of access to a row of specific memory slots 310. Such a row can be all of memory slots 310 at the group level, for example, memory slots 310 designated by section l.sl and section 2. if in figure 19. Access rights can also be granted to a particular section 305, group 320 or subgroup or a combination thereof.

Figure 21 is a block diagram illustrating the fire walls of the client and the server within the overall collaboration system 360 in accordance with an embodiment of the present invention. Referring to Figure 21, the global collaboration system 360 includes a server company 362 and a remote client 364 connected to the server company 362 by a network 366. The network 366 can be the internet, an intranet or another suitable network.

The server enterprise 362 includes the firewall fire wall 370 and a server workspace 372 protected by the fire wall 370 of the server. The server workspace includes data store 370 and permission system 376. The server workspace may be workspace 200, workspace 300 or other suitable workspace. A record for the permission system associates predefined data types 368 in the data warehouse 374 with one or more client applications. The record can be part of the permit system or another associated with the workspace. The registration associates the predefined data type by allowing client applications to subscribe to the types of data. The data types can be identified by the slots or other structural components of the data warehouse 374. The data can be data related to the operation of a workflow or to the collaboration on the server company 362 or other suitable information.

An internal fire wall 360 on the server company 362 protects a client application 384 and a client work space 3 = 2 from the server workspace 372 or from other hostile attacks. The internal fire wall 380 allows access to the workspace of the server 372 from the workspace of the client 382 or of the application 384 but prevents access to the workspace of the client 382 from the server workspace 372. The wall fire alarm 380 therefore allows customer application 384 to freely access data store 374 but blocks access from server work space 372 to client application 374. In this configuration workspace 372 placed between the wall fire protection 370 and fire wall 380 may be referred to as "DMZ".

The client application 384 includes an application program interconnect (API) 386. As described in more detail below, API 386 is operable to connect to the server workspace 372 to receive the return calls generated by the workspace. 372 The client 364 includes a customer fire wall 390 and a customer application 392 protected by the customer fire wall 390. The customer fire wall 390 is operable to create a customer callback and other communications initiated by the customer. server company 362 for client application 392. Client firewall wall 390 is operable to block the client's call back in the sense that it does not have a client-side substitute or other similar mechanism to allow the enterprise server 362 access to customer 364 through fire wall 390.

The client application 392 includes an interconnect of the application program (API) 394. As described in connection with API 386, the API 394 is operable to connect to the workspace of the server 372. For a remote client application 392, the API 394 connects to the server workspace 372 through a substitute 396 in the fire wall of the server 370. Once the client applications 384 and 392 are connected to the workspace of the server 372, the client applications can each receive a call back from the client and download the associated data. In this way, the customer's return calls are provided without the substitute process of the customer's ladc.

Fig. 22 is a flowchart illustrating a method for providing return calls from the client according to an embodiment of the present invention. In this embodiment, the client application 392 communicates with the server workspace 372 using the TCP protocol. The method of Fig. 22 will be described in relation cor. the client application 392 on the client 364. It will be understood that the method can be used for the local client application 384 and for other client applications otherwise connected to the server company 362.

Referring to Figure 22, the method begins at step 400 in which the API client application 394 connects to the server workspace 372 through the server-side substitute 396. As previously described, the server-side substitute 396 provides access through the fire wall of the 370 server.

Then, in the server state 402, the client application 392 remains connected to the server workspace 372 and waits for a client return call or other suitable notification of the registry or of another suitable element of the permission system 370 or the space of work 372. In response to the callback, the wait state 402 leads to step 404 in which the predefined data type is downloaded to the client application 392. After the data is downloaded, step 404 returns to the 402 state of waiting. The predefined data type can be a legacy of the server workspace 372.

As previously described, in the wait state 402, the client application 390 remains connected to the server workspace 372 and waits for the additional client return calls in response to the presence or appearance of the predefined data type. The client application 392 may remain connected to the server workspace 372 until the information is no longer needed for the client application 392. In this case, the client application 392 may terminate the connection to the server workspace 372 which leads to the end of the process.

Fig. 23 is a flowchart illustrating a method for providing return calls from the client according to another embodiment of the present invention. In this embodiment, the client application 392 communicates with the workspace of the server 372 using the HTTP protocol. The method of Figure 23 is described in relation to the remote client application 392. It will be understood that the method can be used in connection with the local client application 384 and other client applications otherwise connected to the server enterprise 362.

Referring to FIG. 23, the method begins at step 410, in which API 394 of client application 392 connects to server workspace 372 through the client-side substitute 396. Next at decision step 412, the client application 392 determines whether it has a client return call from the server's working space 372. If a callback is present or indicated, the SI branch of the decision step 412 leads to step 414 in which the data is downloaded to the client application 392. Step 414 leads to step 416 in which the client application 392 disconnects from the workspace of the server 372. Returning to the decision step 412, if a client return call does not is present or indicated, the NO branch of the addition step 412 also leads to step 416 where the client application 392 is disconnected from the work space of the servodrive 372. In step 418, the client application 392 for an interval and then repeat the method by restarting at step 410 to allow the client application 392 to obtain data from the server workspace 372 with a minimum bandwidth and without a client-side substitute or other similar mechanism. In this manner, the present invention provides multiple access mechanisms to the workspace without a substitute on the client side. If a periodic connection for return calls is no longer desired, step 416 leads to the end of the process.

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

Claims (18)

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

1. A system to provide calls of return of client, that includes: a client that has a client application and a fire wall of operable client to block a client back call to the client application from a server; the server has a fire wall server and a server workspace, the server workspace includes data protected by the fire wall of the server and a permission system associating a predefined type of data with the client application; the server workspace is operable to generate a client return call for the client application in response to the presence of the predefined data type; a server-side substitute operable to provide access to the client application to the server workspace through the server firewall; and the client application is operable to connect to the server workspace through the server-side substitute to receive the call back from the client.

2. The system, as claimed in clause 1, characterized in that the client application is operable to periodically connect to the server workspace through the server-side substitute to receive any call back from the client and to disconnect from the client. Server workspace in the absence of a call back from the client.

3. The system, as claimed in clause 2, characterized in that the client application communicates with the workspace of the server using the HTTP protocol.

4. The system, as claimed in clause 1, characterized in that the client application is operable to remain connected to the server's working space through the server-side substitute and to download the predefined data in response to any call from the server. return of the client.

5. The system, as claimed in clause 4, characterized in that the client application is operable to communicate with the workspace of the server using the TCP protocol.

6. The system, as claimed in clause 1, characterized in that the client application includes an application program interconnection for connection to the server workspace through the server-side substitute.

7. A system to provide return calls from the client that includes: a server that includes a server workspace and a client workspace separated by an internal fire wall; The inner wall is operable to block a client's call back for a client application. the client workspace from the server workspace; the workspace of the server has ur. permission system associating a predefined type of stored data with the client's application; the server workspace is operable to generate a client return call for the client application in response to the presence of the predefined data type; Y the client application is operable to connect to the server workspace to receive the call back from the client.

8. The system, as claimed in clause 7, characterized in that the client application is operable to periodically connect to the server workspace to receive any client calls and to disconnect from the server workspace in the absence of the client. call back from the client.

9. The system, as claimed in clause 8, characterized in that the customer's application communicates with the server's workspace using the HTTP protocol.

10. The system, as claimed in clause 7, characterized in that the client application is operable to remain connected to the workspace of the server and to download the predefined data type in response to any call back from the client.

11. The system, as claimed in clause 10, characterized in that the client application is operable to communicate with the workspace of the server using the TCP protocol.

12. The system, as claimed in clause 7, characterized in that the client application includes the interconnection of the application program to connect to the workspace of the server.

13. A method to provide a call back to the customer through an operable fire wall to block the transmission of the call back from the customer to the customer comprising: provide a server workspace that has a permission system; associate in the permission system a predefined type of data in the server workspace with a client application in the client; generate a client return call for client application in response to the presence of the predefined data type; and connect the client application to the server workspace to receive the call back from the client.

14. The method, as claimed in clause 13, characterized in that it also comprises periodically connecting the client application to the server workspace to receive any call back from the client; Y Disconnect the client application from the server workspace in the absence of the client's call back.

15. The method, as claimed in clause 14, characterized in that the client application communicates with the server workspace using the HTTP protocol.

16. The method, as claimed in clause 13, characterized in that the client application remains connected to the server workspace; Y Download the predefined data type in response to any call back from the client.

17. The method, as claimed in clause 16, characterized in that the client application communicates with the server workspace using the TCP protocol.

18. The method, as claimed in clause 13, characterized in that the client application includes an application program interconnection for the connection to the server workspace. SUMMARY A system for providing customer return calls includes a client that has a client application and a fire wall of operable client to block a client back call to the client application from a server. The server includes a fire wall of the server and a server workspace. The workspace of the server has data protected by the fire wall of the server and a permission system associating a predefined type of data with the client's application. The server workspace is operable to generate a call back from the client to the client application in response to the presence of a predefined data type. A server-side substitute is operable to provide client application access to the server workspace through the fire wall :; of the server The client application is operable to connect to the server workspace through the server-side substitute to receive the call back from the client.