WO2002097588A2

WO2002097588A2 - Distributed artificial intelligent agent network system and methods

Info

Publication number: WO2002097588A2
Application number: PCT/US2002/017170
Authority: WO
Inventors: Kris Dockx; Claudia BETZ-HAREBOLD; Rohit Bhargava; Yvan Deboeck; Ettore Di Lena; Steven Fraleigh; Duncan Mcgillivray; Christian Nester; Doug Raymond; Albert Ullrich; Anja Behrmann; Bhupinder Dhillon; Oliver Gros; Joerg Jonas; Kaj Kandler; Michael Lipton; Magnus Ljungberg; Brian Matthews; Guenther Moeckesch; Timothy O'donnell
Original assignee: Camelot Is-2 International, Inc. D.B.A. Skyva International
Priority date: 2001-05-31
Filing date: 2002-05-31
Publication date: 2002-12-05
Also published as: AU2002310236A1; WO2002097588A3

Abstract

Aspects of the invention effectuate a network of distributable agents (100) for conducting some or all sub-processes of an overall intra- or extra-business entitly process (e.g. in a business group, location, company, division, inter company operation, etc.) Aspects form a network of distributable, temporarily persistable agents (104a) for executing respective 'slices' of the business process. Aspects also populate the agents in a predetermined manner with combinations of prefabricated generic agent elements and customizable agent elements linkable thereto; aspects further provide separate functional agent element and data, and separate functional elements including business processing and operational elements. Aspects further enable agent operation to be varied by assigning a different role to the agent, and for agents to operate in a unitary, collaborative, propagated or combined agent/inter-agent manner. Aspects also enable agents to conduct efficient distributable agent condition or data persistence at predetermined processing states (e.g. upon completion of useful agent processing).

Description

DISTRIBUTED ARTIFICIAL INTELLIGENT AGENT NETWORK SYSTEM AND METHODS

PRIORITY REFERENCE TO RELATED APPLICATIONS This application claims benefit of and hereby incorporates by reference provisional application serial number 60/295,462, entitled "Distributed Artificial Intelligent Agent Network," filed on May 31, 2001 by inventors Kris Dockx, et al. This application also claims benefit of and hereby incorporates by reference provisional application serial number 60/343,788, entitled "Method and Apparatus for Implementing Roles in an Application Framework," filed on October 25, 2001 by inventors Alan Perry, et al. This application is also a continuation-in-part and incorporates by reference application serial number 09/152,494, entitled "Method and Apparatus for Business Modeling," filed on September 13, 1998 by inventors Anja Behrmann, et al. This application is also a continuation-in-part and incorporates by reference application serial number 10/084,850, entitled "Business Modeling Framework System and Methods," filed on February 25, 2002 by inventors Guenther

Moeckesch, et al. This application is also a continuation-in-part and incorporates by reference application serial number 10/142,644, entided "Loading and Saving System and Methods," filed on May 8, 2002 by inventors Yvan DeBoeck, et al.

BACKGROUND OF THE INVENTION

Field of the Invention

This invention relates generally to computer networks, and more particularly provides a system and methods for implementing business tasks within a vritual network of distributable agents.

Description of the Background Art

Business systems have long promised to improve the manner in which planning, ordering, manufacturing, delivery and various other aspects of business operations are conducted, and systems have appeared for handling certain ones of these aspects. Supply chain management ("SCM") systems, for example, continue to be used in planning and scheduling, enterprise resource planning ("ERP") systems are used in manufacturing, and customer management systems ("CMS") are used for more transactional order and customer management tasks. Unfortunately, such systems have proven problematic.

One problem is that the above and other such systems typically process and store information in unique, proprietary and incompatible manners. While an inter-connectivity industry has emerged to provide "bridging software," only limited success has at best been achieved, and even then, only among the specific systems and system functions to which the bridging software has been specifically targeted.

Such specialized systems have also been found to exhibit unique inherent problems. For example, conventional order and customer management systems are specially constructed to benefit from the robustness of in-memory operation. However, access requests can lock out users, tie up the systems and otherwise hinder access to information. On the other hand, transactional systems can lack needed flexibility, and can require substantial ongoing modification.

Conventional programs are also typically implemented based on traditional approaches to application programming. For example, despite a resurgence of obj ect oriented programming and its encapsulation, inheritance and delegation features, no specific object utilization is imposed. Programmers therefore tend to use familiar procedure-like approaches. OOP objects tend to mimic the highly integrated main and subroutine procedures, and to similarly provide a fixed system in which an object tightly integrates all aspects of a gross function and data. As a result, espoused "reuse" of objects tends -in actuality- to instead require considerable programming expertise. Adding or modifying object functions typically requires the addition/rewriting of objects for each included data instance, and modifications to data typically require a new/largely re-written object for each operability affected by the data modification. The above difficulties also tend to become exacerbated in network environments, such as a corporate intranet or the Internet. New network oriented tools have emerged. For example, mobile code can be produced using Java™ applets or JavaScript scripts (Sun Microsystems, Inc.), ActiveX™ controls (Microsoft Corporation) and Visual Basic (Microsoft Corporation). More standardized communications and messaging can also be provided using, for example, hypertext markup language ("HTML"), extended markup language ("XML") or simple object access protocol or "SOAP" (developed by a consortium including DevelopMentor, IBM, Lotus, Microsoft and Userland). However, many existing systems are not readily adaptable to a network environment. Accordingly, there is a need for systems and methods that enable the advantages of existing systems, but that are further capable of providing flexible, robust, lower resource and more inter-operable business solutions. There is further a need for such systems and methods that are capable of taking advantage of the potential benefits of emerging and future networking technologies.

SUMMARY OF THE INVENTION Aspects of the invention provide for effectuating a propagative virtual service-based network of distributable agents capable of conducting some or all sub-processes of an overall intra or extra business-entity business process (e.g. pertaining to a business group, location, company, division, inter-company operation, etc.). Aspects provide for modeling an agent network or portions thereof, and for forming a virtual interconnected network of agents, the whole or portions of which can be overlayed onto one or more physical, logical and/or virtual networks; aspects also enable an agent network to be dynamically restructured/re-distributed and/or for agents to be dynamically re-configured within one or more domains (e.g. within or across networks of different entities and/or entity sub-divisions.

Aspects of the invention provide for distributing temporarily or more permanently persistable agents for executing respective "slices" of one or more business processes of portions of one or more entities, and further, for populating the agents in a predetermined manner with combinations of prefabricated generic agent elements and separate customizable agent elements linkable thereto. Aspects also provide for dynamic agent reconfiguration via agent modification or utilization of roles.

Aspects also enable agent elements to be provided as separated functional elements and data, and separated functional elements including business processing elements and operational elements. Aspects further enable agents to operate in a unitary or collaborative manner that can, for example, be propagated directly, indirectly and/or via multiple agents or levels of agents within one or more entities or entity sub-divisions. Aspects also enable agents to conduct efficient distributable agent condition or data persistence at predetermined processing states (e.g. upon completion of a useful agent processing), among still further aspects. A method embodiment according to the invention includes overlaying an interconnected network with an agent network of agents for performing respective slices of a business process, and populating the agent, via an underlying agent-element framework, with a predetermined collection of services and policies associated with the services, an agent state machine, and one or more roles according to which the agent is operable.

In another method embodiment according to the invention, a network node of a distributable agent network is formed by loading an agent into a Java Virtual Machine ("JVM") or other suitable code executor. (One or more agents might also share the same executor or executor portion.) The agent is further populated, via an underlying agent-element framework, with a predetermined "pattern" of generic objects, one or more respective business, user or machine specific object extensions ("policies") as might be applicable, and can also include an agent state machine, and one or more roles according to which the agent is operable.

In a further method embodiment, an agent within an agent network operates via an underlying framework, another agent or an intermediary agent ("broker agent") by retrieving/receiving data, performing a business sub-process and returning a next state condition and/or data, thereby causing user interaction, a collaborative response (e.g. an agent to agent outsourcing negotiation, such as a bidding process portion), process propagation (e.g. propagating a product/service order to/from order entry planning, manufacturing, local/remote inventory, delivery, billing, etc.), or by causing a processing result or condition to be persisted onto a more centralized or distributed storage device or both (e.g. into a database).

A network system embodiment comprises a plurality of agents distributed within one or more machines of one or more business entities (e.g. PCs, servers, remote devices, etc.), a framework including generic objects, policies, process state machines, roles and patterns, and a storage (e.g. database). The patterns provide predetermined combinations of the generic objects for causing respective agents to perform respective business process slices or application portions, and for providing communication, loading, saving or other services. The policies are linkable to predetermined ones of the generic objects for modifying or extending one or more generic object operabilities in accordance with business, user, machine and/or other parameters. The process state machines provide for agent or network condition-based processing (e.g. persisting a current agent condition) or communication of such condition in conjunction with saving, loading, collaborating, propagating or otherwise handling results of agent processing. The roles enable switchable operability modification of the agent elements, and the storage provides for persisting resultant policies, data and/or state machine conditions. An agent according to an embodiment of the invention comprises a predetermined combination ("pattern") of servlets, applets or other remotely operable ("mobile") code. The mobile code includes generic objects instantiated and communicated from an underlying framework of prefabricated order, process and resource elements for performing a unitary, collaborative or propagating business process slice of an intra or extra entity business process model. The mobile code also includes "policies" linkable to the generic objects for modifying or extending predetermined ones of the generic objects in accordance with one or more of business, user, machine or other operability needs, and a state machine and roles according to which the other agent elements are operable. The objects and policies are further organized to provide business services relating to business sub-processes of the slice/portion, and technical services for system/user communication, object loading/saving, agent condition or data persistence, and/or other "back-end" operations in conjunction with the framework, a persistent store, an intermediary or "broker" agent (that includes brokering services) or another non- broker agent. Advantageously, systems and methods according to embodiments of the invention enable benefits corresponding to prior business applications, but are not limited by the inherent problems of prior business applications or underlying programming techniques. Such systems and methods are further capable of even greater and more efficient operability that is also particularly well-suited to a network environment. Aspects enable a uniform, discretized input-output application model in which inputs and outputs are further discretized and organized as agents hosted in memory, that is particularly flexible and robust. An underlying business model is also capable of being defined in accordance with particular business applications or as overriding interoperable intra or extra-entity business process slices, among other suitable business or business aspect modeling that might be utilized. Enabling all business logic to be hosted in memory further provides for high performance, efficient operation and robust inter-element and inter-agent communication; an enabled uniform data model further facilitates reduced throughput requirements and better guaranteeing data integrity (e.g. storing data when appropriate and in an appropriate way); long run transactions (e.g. collaboration, propagation, etc.) are further facilitated. By enabling separation of data and logic and further separation of business and operation logic, and of generic and customizable agent elements, embodiments provide for loading and saving of only needed elements and data, and for robust modification. Such robustness is further facilitated through the use of roles, a state machine, and unique saving/loading and communication systems, among other advantages.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a flow diagram illustrating a underlying interconnected network in accordance with an embodiment of the present invention;

FIG. 2 is a block diagram illustrating a computer system in accordance with an embodiment of the invention;

FIG. 3 a is a flow diagram broadly illustrating an agent network according to an embodiment of the invention;

FIG. 3 b is a flow diagram illustrating an agent collaboration example according to an embodiment of the invention; FIG. 4 is a block diagram illustrating a non-broker agent according to an embodiment of the invention;

FIG. 5a is a block diagram illustrating a broker agent according to an embodiment of the invention;

FIG. 5b is a flow diagram illustrating hub-and-spoke messaging via a broker agent according to an embodiment of the invention;

FIG. 5 c is a flow diagram illustrating collaborative messaging via a broker agent according to an embodiment of the invention;

FIG. 6a is a flow diagram illustrating an agent net portion according to an embodiment of the invention; FIG. 6b is a flow diagram illustrating a further agent net portion according to an embodiment of the invention;

FIG. 7a is a flow diagram illustrating an agent net loading implementation according to an embodiment of the invention;

FIG. 7b is a flow diagram illustrating an agent net saving implementation according to an embodiment of the invention;

FIG. 8 a is a flow diagram illustrating a role implementation according to an embodiment of the invention;

FIG. 8b is a flow diagram illustrating a loading of core resource elements into transient agents according to an embodiment of the invention; FIG. 8c is a flow diagram illustrating a loading of core process elements into transient agents according to an embodiment of the invention;

FIG. 8d is a flow diagram illustrating a loading of core order elements into transient agents according to an embodiment of the invention; FIG. 9a is a flow diagram illustrating a shared cache mode according to an embodiment of the invention;

FIG. 9b is a flow diagram illustrating a loading implementation in conjunction with a shared cache mode according to an embodiment of the invention; FIG. 9c is a flow diagram illustrating a multiple cache mode according to an embodiment of the invention;

FIG. 9d is a flow diagram illustrating a loading implementation in conjunction with a multiple cache mode according to an embodiment of the invention;

FIG. 10a is a flow diagram illustrating a query implementation in conjunction with an agent net, according to an embodiment of the invention;

FIG. 10b is a flow diagram illustrating examples of querying alternatives in conjunction with an agent net, according to an embodiment of the invention;

FIG. 1 la is a flow diagram illustrating a shared cache persistence implementation in conjunction with an agent net, according to an embodiment of the invention; FIG. 1 lb is a flow diagram illustrating a configurable optimistic locking shared cache implementation according to an embodiment of the invention;

FIG. 1 lc is a flow diagram illustrating a multiple cache persistence implementation in conjunction with an agent net, according to an embodiment of the invention;

FIG. 1 Id is a flow diagram illustrating a configurable optimistic locking multiple cache implementation according to an embodiment of the invention;

FIG. 1 le is a flow diagram illustrating an application of a unit of work implementation to agent net synchronization according to an embodiment of the invention;

FIG. 1 If is a flow diagram illustrating a data securing implementation in conjunction with an agent net, according to an embodiment of the invention; FIG. 12 is a flow diagram illustrating an interested component update implementation in conjunction with an agent net, according to an embodiment of the invention;

FIG. 13 is a flow diagram illustrating grouping and post implementations according to an embodiment of the invention;

FIG. 14 is a flow diagram illustrating state machine operation including corresponding conditions according to an embodiment of the invention;

FIG. 15 is a flow diagram illustrating a multi-tiered agent network architecture, according to an embodiment of the invention; FIG. 16 is a flow diagram illustrating a multi-tiered agent network architecture, according to an embodiment of the invention;

FIG. 17 is a flow diagram illustrating inter-agent messaging according to an embodiment of the invention; FIG. 18 is a flow diagram illustrating an agent input/output model according to an embodiment of the invention;

FIG. 19 is a flow diagram illustrating an scheduling order sequence example according to an embodiment of the invention; and

FIG. 20 is a flow diagram illustrating a resource element in an ADM with policies according to an embodiment of the invention.

DETAILED DESCRIPTION

In providing for distributed artificial intelligent agent network system and methods, embodiments of the invention enable intra and inter-entity business and other systems to be modeled and implemented, in whole or part, using one or more virtual networks of distributable agents. Aspects provide for automatic or user-facilitated modeling/executing of system portions, launching and populating of independent or interoperable agents, implementing of modifϊably operational agent networks, and variable persisting of information. Aspects also enable agents to receive, unitarily or cooperatively process or communicate information including processing, configuration, device control or other information. Such "information handling" can further be conducted in conjunction with existing business or other applications, or at variable information handling granularities or centralizations, among still further aspects.

Note that the term "or", as used herein, is generally intended to mean "and/or," and "portion" is intended to be synonomous with "the whole or one or more continuous or discontinuous parts" and "in whole or part," unless otherwise indicated. The discussion might also reference various examples, including but not limited to particular "Skyva" implementations, or embodiments thereof, through which various aspects of the invention might be better understood. It should be noted, however, that such implementations are merely exemplary and should not be construed as limiting.

Underlying Network and Processing System Examples

Turning to FIG. 1, one or more virtual agent networks can be provided in which agent networks or elements thereof are deployable, executable and communicatingly couplable in more centralized/distributed manners that can be overlayed over varying underlying networks of interconnected devices. The agent networks can include one or more underlying "agent network frameworks" and one or more (typically a multiplicity) of remotely operable "agents." The agent networks or "agent nets" can also include one or more logic/data transfer, execution or other mechanisms for enabling ones of the the deploying, executing, persisting or other agent net portion operations. The underlying or "physical" networks can include a static or re- configurable wide area network ("WAN"), local area network ("LAN") or other coupling(s) of at least temporarily communicatingly couplable devices, one or more of such devices being capable of supporting an agent network framework, storage requirements and corresponding agents. Agent net portions are configurable and can be executed as runtime systems providing "intra-entity" or "extra entity" operation pertaining to one or more customer entities, e.g., facilitating business or other operations of one or more persons, business units, companies or other user-determinable groupings, portions thereof, and so on. Where multiple entity or "extra-entity" operation is conducted, two or more entities can utilize separate independently operating agent networks, separate interoperably operating ("inter-entity") agent networks, or composite agent networks that inclusively handle business or other operation of more than one entity. Agent networks are also configurable for providing combined such operation, for example, with respect to different entities, operation types or applications in whole or part. (While it will become apparent that a agent network portion is also implementable locally with regard to even a single host, e.g. on a user PC, server, other devices, or processes thereof for design simulation or other uses, a mobally executable and distributable agent implementation utilizing multiple underlying network devices of one or more entities is typically utilized for agent net operation as a runtime system.) Business system 100 of FIG. 1 , for example, comprises an underlying interconnected network including physical networks 101 a-c (here, the Internet and intranets of entities 1 and N), servers 102a-105a and 106, and connectable user devices (e.g., 105f, 106). In this example, an agent network framework 102d is initially loaded from a centralized storage 102b to server 102a (an agent network element host or "agent network server"). Agents are then deployed via agent network framework 102d and network 101a to server 103a of entity-1 (or to any further entity-1 agent network servers), and entity-N server 105a or any further entity-N agent network servers.

Broadly stated, agent network frameworks 102d, 103 d, 105d operate as distributable agent net integrators servicing one or more agents. They provide a distributable facilitating mechanism useable in conjunction with agent element deploying, data transfer, condition/data persistence, updating or other agent network coordination, among further aspects. Thus, agent network frameworks 103d and 105d can correspond with a single distributed framework, in accordance with the above example, or more than one framework (e.g., 103d or 105d) that can be utilized in deploying or servicing specific agent networks or agent network portions in a separate or coordinated manner. The depicted agents are configurable for performing application processing that can further be conducted in conjunction with other agents, and at variable, slice-based operational granularities. For example, server 104a can correspond to a separate entity-1, entity-N or other entity division, location group or other entity portion whose business processes might be conducted by an independent agent network including agents serviced by agent network framework 102d. Server 104a might also correspond to a separate entity (e.g., product/ service supplier of entity- 1/N) utilizing a separate agent network and having its own agent network framework for facilitating intra-entity business operations alone or in an interoperable manner with agent network elements of one or more of entity-1 through entity-N.

One or more of servers 102a, 103 a, 104a or 105a (or further couplable agent network hosts) can also include one or more storage devices (e.g. storage 105b) for providing more centralized or distributed storing of agent network information or a portion thereof. Such servers/storage can further be at least temporarily (i.e. or intermittently) communicatingly coupled in a wired or wireless manner to one or more user devices for communicating with or via a corresponding agent network, among other examples.

Ones of underlying network elements (e.g., servers, user devices, and so on) of system 100 that provide for executing agents or "agent hosts" further include code executors 110 for executing respective agents. System 100 code executors include Java Virtual Machines or "JVMs". It will be appreciated, however, that various code executors might be used in accordance with a particular application utilizing one or more of mobile code (e.g., Java, ActiveX, etc.) or various other agent network element implementations. The depicted agents also enable the use of a single application data model (see below) that can further provide separately implementable logic and data that can be associated. Thus, existing entity device/network configurations and conventional communication mechansims can not only be utilized, but can further be utilized in a more robust manner, and without requiring information conversion. Agent network hosts can also provide for deploying initial or new agents or agent modifications, for supplying and persisting data (via one or more agent network framework hosts in the present example), and so on. Selectable agent data/condition information portions (resulting from agent operation), new agents or agent modifications produced by such operation can further be persisted in a predetermined manner to one of more centralized or distributed data stores corresponding to the deployed agents, e.g., database 102b, 103b, 105b, others, other storage types or some combination.

It will be appreciated that underlying network elements other than servers 101a-105a and 106 might also be utilized, such as routers, gateways, additional servers, device controllers, etc. (which other network elements are not shown for clarity sake). Such devices that are capable of operation consistent with facilitating or utilizing an agent network, such as is discussed herein, can also be used for such purposes. (For convenience, all such devices capable of hosting one or more agents, agent network frameworks or portions thereof, including any user or other devices, will also be summarily referred to hereinafter as "agent network servers" or "agent net servers" unless otherwise indicated.)

User devices 105f and 106a can include one or more of PCs, personal information managers ("PIMs"), personal data assistants ("PDAs"), smart devices or any other device(s) that can enable direct or indirect communication between an agent network element and a user. In the present example, communication between user devices and agents can be conducted via conventional TCP/IP protocol and extended markup language ("XML") web pages or email. Communicated information can include business forms, charts, queries or other forms of static or dynamic information of one or more information types or "multimedia" information. Such information can be communicated as a static or interactive presentation by or via a suitable client running on a user device (e.g. browser, email program, etc., summarily depicted as client 107b of user device 107a). User device based agents (e.g., see above) or other alternatives can also be utilized alone or in conjunction therwith.

It will become apparent that, while hosted by underlying system elements, agent networks are otherwise configurable in a manner that is substantially independent of a particular underlying network configuration. For example, a one to one correspondence between agents and agent hosts (or agent types and agent host types) is not required, and different numbers/types of agents, hosts or correspondences therebetween can be implemented. Various configurable aspects facilitate such independence, e.g., separation of logic and data, slice-based agent operation, parameterized communication or communication alternatives, and so on, with combined such aspects being found to provide even greater agent network independence or underlying system accommodation.

For example, agent network elements are capable of communicating via mobile code, such as Java applets, ActiveX, etc., SOAP, or other suitable communication mechanisms in accordance with a particular implementation. Agent network elements can further communicate with each other, as well as with legacy business application elements or other system portions that are communicatingly couplable to an agent host (e.g., see below.) It will be appreciated that user device/agent network communication mechanisms further enable communication to pass through firewalls (e.g. 112c and 105c) or other protection mechanisms that might be utilized, among other examples. (However, conventional or other mechanisms can also be employed for navigating particular security measures in accordance with a particular application.)

FIG. 2 illustrates an exemplary computing system 200, that can comprise one or more of the elements of FIG. 1 or the remaining figures While other alternatives might be utilized, it will be presumed for clarity sake that such elements are implemented in hardware, software or some combination by one or more processing systems consistent therewith, unless otherwise indicated.

Computer system 200 comprises elements coupled via communication channels (e.g. bus 201) including one or more general or special purpose processors 202, such as a Pentium® or Power PC®, digital signal processor ("DSP"), etc. System 200 elements also include one or more input devices 203 (such as a mouse, keyboard, microphone, pen, etc.), and one or more output devices 204, such as a suitable display, speakers, actuators, etc., in accordance with a particular application. System 200 also includes a computer readable storage media reader 205 coupled to a computer readable storage medium 206, such as a storage/memory device or hard or removable storage/memory media; such devices or media are further indicated separately as storage device 207 and memory 208, which can include hard disk variants, floppy/compact disk variants, digital versatile disk ("DVD") variants, smart cards, read only memory, random access memory, cache memory, etc., in accordance with a particular application. One or more suitable communication devices 209 can also be included, such as a modem, DSL, infrared or other suitable transceiver, etc. for providing inter-device communication directly or via one or more suitable private, public, static, configurable networks or couplings that can include but are not limited to those already discussed. Working memory further includes operating system ("OS") elements and other programs, such as application programs, mobile code, data, etc. for implementing system 100 elements that might be stored or loaded therein during use. The particular OS can vary in accordance with a particular device, features or other aspects in accordance with a particular application (e.g. Windows, Mac, Linux, Unix or Palm OS variants, a proprietary OS, etc.). Various programming languages or other tools can also be utilized, such as those compatible with the Java 2 Platform, Enterprise Edition ("J2EE") or other languages consistent with corresponding Sun specifications. Embodiments can also include a network client such as the above noted browser or email client, e.g. as produced by Netscape, Microsoft or others, and a suitable mobile code executor, such as a Java Virtual Machine ("JVM"). (Embodiments might also be implemented in conjunction with a resident application or combination of mobile code and resident application components.)

One or more system 200 elements can also be implemented in hardware, software or a suitable combination. When implemented in software (e.g. as an application program, object, downloadable, servlet, etc. in whole or part), a system 200 element can be communicated transitionally or more persistently from local or remote storage to memory (or cache memory, etc.) for execution, or another suitable mechanism can be utilized, and elements can be implemented in compiled or interpretive form. Input, intermediate or resulting data or functional elements can further reside more transitionally or more persistently in a storage media, cache or more persistent volatile or non-volatile memory, (e.g. storage device 207 or memory 208) in accordance with a particular application.

Agent Network Example FIG. 3 a illustrates an agent network example 300 that is capable of being deployed and executed in an overlayed manner over a variety of underlying interconnected networks. For clarity sake, network 100 will continue to be utilized as a basis for the depicted interconnected network example.

Similar numbering of elements corresponding with those of FIG. 1 has been retained (here and elsewhere), to facilitate a better understanding. Accordingly, underlying interconnected networks are summarily labeled as lOla-b (e.g. including a LAN, WAN, oilier networks or couplings or combinations thereof, such as was already discussed). Firewalls other than that of entity-1 server 103 a (which server has been moved to the right side of the figure as compared with FIG. 1) are summarily labeled as 102c; the remaining entity-1 related firewalls are labeled 102-3c and 103c (i.e. the first corresponding to one or both of servers 301 and 103a, and the second to server 103a).

Server 102a, which in FIG. 1 provided a central agent network deployment node, has however been divided to demonstrate a less centralized (or "more distributed") agent-network host configuration example that includes servers 102a(l) and 102a(2). For simplicity, each of servers 102a(l), 102a(2) and 103a has at least one corresponding storage device, further corresponding to storage 102b, 103 b of FIG. 1. With regard to the present agent network example, however, distributed storage 301, 302, 303 comprises a dynamic or "live" persistence store that includes an agent-network framework operating in conjunction with a database. Also for simplicity, such stores will continue to be referred to as "live databases" regardless of distribution or database/other storage implementation that might otherwise be used, (A common distributed agent network framework will typically be used for a single enterprise, such as a company or multi-company corporation. However, more than one agent network framework can also be configured for use in such cases, e.g., in accordance with a particular user design constraints.) Finally, storage devices storing business-related data in a more conventional manner (and for which access by agent network elements can be provided) are labeled 301a and 301b.

For reference purposes, system 300 might, for example, represent an agent net configuration implemented for a company-X in which entities 1 and 2 correspond with business units of company-X (e.g., manufacturing and inventory) and entity 3 corresponds with company- wide planning and scheduling. Company-X might further be one of two or more in a product or service supply chain. It will become apparent, however, that the FIG. 3 example can correspond with a wide variety of business or other systems that might be implemented in conjunction with a configurable agent net embodiment according to the present invention.

Deployed agents 311, 312a-h, 321, 322a-c and 332a-g provide an operational network of what can be viewed as autonomous, intelligent computational entities that perceive their environment through sensors and act thereupon through effectors. The agents are autonomous in that they have control over their behavior and environment, and can be configured to act without the intervention of humans or other systems; they are also "intelligent" in that they can pursue goals and execute tasks in a manner that optimizes configurable performance measures, with or without more complex so-called "artificial intelligence" algorithms.

Agents can, for example, receive data, perform a business process/application slice operation and compare predicted versus actual results, a best match, or weighted best match of alternatives versus measurable criteria, such as agent or agent-role based rules, etc. Agents can also interact through the environment in which they are embedded, for example, by observing one another, carrying out an action that modifies the environmental state (e.g., a more inclusive process affectable in accordance with a communicated agent condition), or communicating with other agent network elements, other system elements or human users. Agents 311, 312a-h, 321 , 322a-c and 332a-g integrate a collection of operabilities via an interplay of knowledge about a problem type and of the environment in which they operate. Thus, an agent can receive and determine a reaction to an environment condition, and interact (e.g., cooperate via collaborating or propagating a process) with other agents in order to determine solutions to the problem or to report an inability to do so.

Without intending to be limited to a particular theory, agent design is thought to provide a balance between level of specificity and level of autonomy. That is, while each agent specializes in certain basic operations (e.g., in accordance with a business process/ application slice or function), such operations also represent a significant overall process/application portion that is merely limited in scope (e.g., in time if the agent performs in specific time periods, or in space if the agent acts on a reduced spatial environment.)

Agent efficiency and reusability are also gained by enabling the forming of an agent that includes only operabilities that are: (a) sufficient to accomplish its tasks in only its own business area or with respect to an operational slice encompassing one or more aspects of conventional or other applications, and (b) built upon component operabilities tending to serve in different business areas or "domains" (e.g., various manufacturing/ service industries or applications). Efficiency and flexibility are further gained by forming agents according to a common yet extensible agent model, thereby enabling agents to conduct substantially parameterized communication. Agents can also be populated with divided logic and data (here objects) which need only be utilized together or "associated" at runtime), thus facilitating variable granularity operation (e.g., operation slices, variable in-memory operation, and so on). Determinable agent configuration cooperation or populating of agents with persistence elements for providing variably secure and conditionally relevant agent-condition, state or resulting-data persistence can also be utilized, among other factors.

In FIG. 3a, for example, each of agents 311, 312a-h, 321, 322a-c and 332a-g is initially deployed and populated via a distributed agent network framework of "live database" 301, 302, 303 for conducting a slice or slices of an overall business system of entity-1, entity-2 or entity- 3. Live database 301-303 is hosted by servers 102a(l), 102a(2) and 103a respectively. A slice, as will be discussed in greater detail, provides a configurable operational granularity that can, for example, distribute a more conventional function or other user-determinable operational requirement for processing: by more than one agent, by cooperative agent combinations or in conjunction with different agent network servers. Such configurations might, for example, be utilized for conducting processing of different business units of a single entity in separate, accumulative or otherwise cooperative manners. Agents 32 lj and 331 are illustrative of third party agents with which ones of the depicted agents can directly or indirectly communicate and thus conduct extra-entity operation; conversely, outsourcing agent 33 lg is configured for facilitating system 300 extra-entity operation, outsourcing in this example, with other agent nets or other systems (e.g., a common or foreign entity raw material, component or support service supplier corresponding to one or more of system 300 entities 1 through 3).

As was already noted, particular agent network configurations can be rendered user configurable. For example, an agent network framework corresponding to live database 302 or one corresponding to live database 303 might provide separate but interoperable agent networks, or agent network framework corresponding to server 102a(l) might facilitate deploying or persisting of all agents, and so on. The operational configuration of agents within the depicted agent net of system 300 can also be made substantially independent of the underlying or "hosting" network. For example, while server 102a(l) hosts broker agent 311, agents 312a-h might, in a particular implementation, be hosted by one or more other entity-1 servers. Such hosting might be user determinable in a static or reconfigurable manner (e.g., see below). Such hosting might also be automatically (e.g., programmatically) determinable in accordance with a resource utilization or other model, or some combination (e.g., enabling user modification of some algorithmic framework or agent distribution).

Operationally, broker agent 311 is deployed to and hosted by a code executor (here, a JVM) of server 102a(l). Broker agent 321 is similarly hosted by a JVM of server 102a(2), and agents 332a-g are hosted by one or more JVMs of entity-1 server 103 a. (It will become apparent that a single JVM or other code executor can host one or more agents.) The remaining agents are similarly executed by additional code executors which can be hosted, alone or in determinable combinations, by various configurations of servers of entities 1, 2 or 3. Broker agents, as will be further discussed, can provide agent network framework extensions, extra-framework centralization points or perform other agent network facilitation operations, such as in conjunction with one or more of agent loading/saving, communication, communication initiating operations, agent operation coordination, data modification updating, and so on (e.g., see below). FIG. 3 a also illustrates how agent-network element communication can be conducted via agent-framework, broker/non-broker agent to broker/non-broker agent communicative coupling therebetween. As shown, agents 312a-c and 312f-h can be coupled for communicating in a "hub and spoke" configuration in conjunction with broker agent 311, which broker agent is further coupled to agent network framework 301. Agents 322a and 322b are coupled to each other via agent network framework 302, and further to other agents via agent network framework 302 connection to an agent network hub formed by broker agent 321. Agents 332a, 332c and 332f are communicatingly coupled in an agent-to-agent "chain" configuration, which chain is further coupled via broker agent 311 to agent network framework of live database 301. Such communication can also be conducted interoperably with extra- network systems (e.g. via outsourcing agent 332g or third party agents 312j and 332j), or for incorporating extra-network information (e.g. as with agent 312a coupling to ERP 303a, agent 312f coupling to legacy store 301a, etc.). Agents 332c, 332d, 332e and 332f are further coupled in an aggregating/disaggregating (hereinafter summarily "aggregating") type of hub- and-spoke configuration. (Typically, the hub agent, here 332c, will be configured as a broker agent. The broker agent in this case can also perform non-broker like processing, e.g., compiling, evaluating, and so on, in addition to performing broker operation as a communicatingly coupling hub.) Agents 312a-c and 312f-h are also capable of persisting data via such coupling. Agent condition or other data results can be conducted by communicating the data directly or indirectly (e.g., via broker agent 311): to a corresponding agent network framework (e.g. 301) to a more centralized storage device, or directly to an agent host storage or remotely accessible storage (e.g. via 3^rd party agent 332j). (While aggregating non-broker agent to non-broker agent communication is possible generally or in conjunction with persisting, such persisting is generally found to add unnecessary complexity where system modification is likely.) >

More typically, initial agent code and data, agent condition/pertinent processing result storage and agent modifications will be stored in a common live database, thereby avoiding additional complexity for populating an agent net, propagating data changes to other system elements, and so on. A "local" storage corresponding to an agent host might further be used in such cases to store only locally pertinent, "temporarily significant" or other such information, such as an intermediate result, prediction, offline operation result, testing information, optimization (of an agent or agent network), or reproduceable agent information.

More centrally persisted information might lack certain more recent information (e.g., upon reinitialization of an agent network portion). Agent nets can, however, be configured such that a pertinent condition of an agent network that has not been centrally saved will be recoverable and only non-critical local information, that is otherwise discarded as needed, will be lost. (Local storage might also be used alone or in addition to more centralized storage for redundancy purposes, where a catastrophic network failure is more likely, or in conjunction with maintaining or otherwise utilizing a legacy store, among other configurable possibilities.)

FIG. 3 a also depicts how, at runtime, the use of such communication and a common extensible agent model can be used to provide robust business solutions that have a low process/application implementation complexity. As noted earlier, each agent need only be able to perform its particular unitary or cooperative process/application slice according to an awareness of its particular view of the overall environment (e.g. a user, sending/receiving agent -typically a broker agent- and possibly the agent network framework). Agents summarily referred to "exchange agents" (agents 312a-k) can, for example, be populated to perform a variety of slices in accordance with the needs of Entity-1 or other entities interacting with entity-1. One or more of agents 312b-f might, for example, provide for receiving requests for quote ("RFQs"), inventory level checking, etc.; agent 312a might determine a known or retrievable credit rating (e.g. via ERP 301a or network lOla-b), which results might be further processed or merely propagated to another agent network element by broker agent 311. Agent 332a of entity-1 server 103a (labeled "corporate plan agent") might further receive propagated such results and collaborate with lower level (e.g. production facility) plan agents 332b-c to determine whether outsourcing is required. If so, agent 332a might further cause a different agent to check extra-entity parts/service capability, request/ compare quotes, etc. (e.g. via a multiply directed broker agent 311 request to entity-N hosted agents of server 321 or "outsourcing" agent 332g). Conversely, agents 332b-c might collaborate with agent 332a to determine their respective production orders, and so on. (Further examples of enabled agent collaboration are illustrated in FIGS. 3b and 5c with regard to manufacturing and quotation respectively.)

It will be appreciated in view of the foregoing that distributable storage or cache/memory variable persistence can also be used in an offline manner, in an online but locally persisted manner that does not require persistence in a manner accessible (e.g., directly coupled via a common live database or broker agent) to other agent-network elements, etc. For example, a user of a coupled user device (see FIG. 1) might utilize plan agent planning/scheduling operations or operations of other agents or agent combinations to perform localized or more entity-wide hypothetical or actual planning/scheduling or other scenarios applicable to information only temporarily supplied ("loaded") to or persisted from applicable agents. (Particularly offline operation might also be used to simulate agent-network operation, to test and verify policies/application components, for agent or agent network optimization, or in defining agent roles (see below), among other uses.

Agent Configuring Examples Having considered the above examples in accordance with varying entity needs, we now turn to more examples of agent net element implementations. We will then again consider runtime operations (e.g. deploying agents, runtime agent structures, commumcation, persistence, etc.), returning to FIG. 3 as might facilitate a better understanding.

Beginning with the FIG. 4 example, an agent typically employs several reusable parts that are combinable and extensibly modifiable at different levels, the extensions being modifiable as well. Such variable configuring enables the formation of an agent configuration for deciding a course of action that the agent will take in a given circumstance. Variable configuration can also enable an agent to function within differing environments (e.g. with respect to different underlying interconnected networks, code executors, user devices, underlying/agent network elements, user requirements, etc.). However, as a result, reusability of agent elements need not be sacrificed for configurability, and even more extensively modified/extended agent operabilities or a portion thereof have been found to remain reusable for different purposes.

A common abstract data model ("ADM") is also found to facilitate inter-operability and efficient communication. Thus, agent logic and data as persisted via an underlying framework (according to a decomposed live database model) can be more aptly viewed as a generic business component or "GBC" that is more suitable for storage, and within a runtime agent (in a more flattened form suitable to agent opration) as a "deployed ADM" (e.g., see FIGS. 6a and 6b). In the FIG. 4 example, agent 400 is populated in conjunction with its deployment or thereafter to include business services 401, business policies 402, technical services 403, technical policies 404, an "empty" ADM 405, and an agent state machine 406. Business services 401 provide logic for processing data objects received from a user or agent-network element (typically a broker agent) during runtime, and thereby performing one or more business slices. (As noted, data can also be received upon deployment or during runtime via an agent network framework or other storage.)

The reusable business logic provided by business services is also extensible by associating, with a service, one or more service initiated business patterns 413a, further via business pattern initiation of one or more business pattern policies ("P -policies") 414a or still further via one or more use/user directed non-pattern policies 421, 422. Business pattern policies 141a and the non-pattern policies or business "user policies" 421, 422 can include one or more of rules, procedures, other formulae or other information for completing, extending or refining the more grossly operative or "generically-oriented" business patterns.

(Typically, patterns are "cross domain" and applicable to [often many] different applications that can further apply in varying industries or other disciplines, such as producing manufacturing/service planning, process control, configuration, and so on. Pattern-narrowing pattern policies and user policies can, for example, successively constrain the manner in which policy results are deived, the selection of pattern results to be used, or the manner in which the results are used, e.g., relating to a particular user/machine, operation, utilization, and so on. Conversely, broading policies might also be used to add extrapolations or otherwise expand the results, selections or manner(s) of use. Some combination incorporating user-entity criteria might also be utilized in conjunction with one or more agent network elements.) Technical services 403, as with business services, provide logic that is extensible via technical patterns (e.g., 43 lb), technical pattern policies (e.g., 43 lc) or technical user policies 441 in essentially the same manners as with business services, patterns or policies. Technical service, however, provide for more implementational or "back-end" agent processing, such as in effectuating or facilitating agent network element communication, persistence, and so on. For example, loader and saver services 432 provide a type of glue for loading ADM objects via an underlying framework and for persisting agent state/condition information or pertinent resultant data via the framework. (Implementationally, various persistence mechanisms can thus be utilized, and no knowledge as to an underlying persistence mechanism is needed by a programmer, should programming (most often merely component selection) be desirable. See also the below discussed agent network framework examples.) Chart 1 below provides examples of business and technical services that are useable in conjunction with the FIG. 4 agent example.

Business and technical patterns, which represent core agent logic or "operational" granularity, comprise executable code implemented as a collection of objects, and more particularly, as executable or "code" objects which can be implemented as Java objects (as in the present example) or otherwise in accordance with a particular application. (Note that the term "patterns" will hereinafter include pattern policies unless otherwise indicated.)

Pattern/user policies are also extensible, such that a user policy might initiate one or more further associated patterns/policies, which might initiate one or more still further patterns/policies, and so on. Thus, a high degree of flexibility is provided at different levels that can further coincide with variable operational refinement, and at variable agent-operation granularities, from which one or more operational slices to be performed by an agent can be configured (e.g. see above). Such flexibility can be rendered user or automatically (e.g., programmatically) determinable in accordance with a particular embodiment. Such flexibility can further be implemented via selection of services and patterns, via selection, modification or extension of policies, or via coupling of patterns/policies, and so on. (It will be appreciated that user/automatic determination can also be provided via selection of refϊnable situation specific combinations or defaults, system polling based analysis, user entered configuration or more specific component selection, formulae or other information, and so on.)

In the present implementation example, policies are embodied in instances of Java classes and are not directly part of the ADM; however, object management services provide for identifying an applicable policy interface and retrieving the correct associated policy. For example, in any given context, a resource may be used in a policy lookup to return a policy that determines how that resource can be used, e.g., various capacity and fulfillment policies or capacity/fulfillment policy types. (Policies serve, in the present example, as key customization points of an agent network application. Thus, while the structure of the ADM relies on reusable patterns with their often recursive algorithms, it is frequently the policies that are used to determine specific and unique aspects of agent behavior.

Of the remaining agent 400 elements, ADM 405 provides an empty container for receiving data objects during runtime. Finally, agent state machine 406 provides a logical sequence of states for operation of agent 400 according to the agent function with respect to a particular agent role; state machine 406 also provides conditions corresponding to particular ones of the states that can be communicated to other agent-network elements alone or with resultant data to cause a particular response by such elements (e.g. the aforementioned collaboration or propagation) .

Operationally, the business patterns, including any applicable business policies, establish agent 400 actions. The function, process slice or other "agent operation" performed by an agent can, for example, encompass planning, scheduling, order execution, manufacturing, other processing, or some combination, in a business application, and at a configurable granularity according to the configuration of agent elements (including any modification/extension). Agent 400 operation is accomplished by receiving input (e.g. a condition, data obj ect or copy of a data obj ect if from a framework) and creating output based on the prescribed steps of an applicable pattern (corresponding to the input, such as a condition, a current agent state or a role implemented in conjunction with a policy/particular agent state machine state).

Agent 400 can execute decisions according to which it can operate based upon one or more of user input (e.g., an order), the configuration of rules or other information in corresponding business policies or data. Technical services 403 (including any technical policies) conduct communication of any new data from a user, another agent or a framework, and transfer the data to applicable ones of business policies 401 using a suitable service invocation mechanism. The business services then conduct business processing in accordance with any associated business policies. The results and any pertinent state condition are then transferred to the technical services for any further communication or persistence.

Among other aspects or implementation possibilities, agents enable a mapping of a suitable business model to a corresponding agent network and executable code. A complete model representing the manner in which business is conducted can -in effect- be received and sliced according to combinations of one or more available more generally applicable services, with particular entity characteristics, e.g., available resources, interconnected network elements, user/use characteristics, and so on being accommodated via readily modifiable and extensible policies. In addition to aspects such as those already discussed, the slices can be inherently mapped to logic generating or selecting of prefabricated code portions at determinable operational granularities, and resultant agents can be overlayed onto an available interconnected network.

Such other aspects can include, for example, the aforementioned separation of logic and data and communication flexibility, which can be further facilitated through the use of unique broker agents (discussed next), among still further aspects. Notice that the aforementioned separation of logic and data can be carried through services, patterns and policies in the present example, such that each can be completely absent of operating data (which operating data can be loaded to ADM 405 in conjunction with runtime agent net operation). Thus, flexibility and reusability can be improved with regard to the particular distribution of functionality, placement within an underlying network, with a particular host or host storage media configuration, unitary or cooperative agent operation, or adaptability to changing user needs (e.g., using one or more function/rule based policies to describe operation or interaction with an underlying device), among other factors. (More conventional "application" type implementations can also be similarly effectuated, such as was already discussed, or such implementations are also producible in accordance with the above and other aspects.

The ability to change business patterns or to assign different policies (which are themselves configurable) to business patterns adds agent flexibility and, combined with an ability to populate agents with only needed logic/data agent information, further enables agents to be rather lightweight entities.

FIG. 5 a, for example, illustrates how a broker agent embodiment 500 can be implemented in essentially the same manner as non-broker agent 400 of FIG. 4 for performing one or more of agent operations and "broker operations" in a runtime system. As shown, broker agent 500 can include business services 501 and any applicable business/user patterns 513a or policies 502 for performing its own business process/ application slice. Broker agent 500 also includes technical services 503 (and any applicable technical patterns, policies or technical user policies (e.g., 531b, 53 lc and 504 respectively) for conducting user/underlying system interaction or other implementational services.

Broker agent 500 further includes one or more transfer maps 507. Transfer map(s) 507 enable broker agent 500 to determine a correspondence between one or more agent net elements for communicating via broker agent 500, e.g., in conjunction with loading, saving (including any persisting), runtime messaging of agent/framework information, querying, and so on. Broker agent 500 can, for example, be configured (by populating broker agent 500 with applicable technical services, patterns or policies) to respond to messaging initiated by a sender agent net element by polling a transfer map, determining therefrom one or more corresponding recipient agent net elements, and facilitating a communication of information from the sender to the recipient(s), or to initiate a communication (e.g., upon a time/event trigger).

The content and utilization of the transfer maps can further be configurable. For example, a transfer map can include a lookup table, array or other data structure including a sender list and recipient list corresponding to each possible sender or each possible send-or- receive communication between a sender-and-recipient pair. A transfer map can also include transfer type information, such as for conducting element(s)-to-element(s), broadcasting, multicasting, particular transaction types (that can include multiple transfers), and so on, in accordance with a particular application. Various utilizations can also be conducted, such as broker agent 500 transferring received information from a sender to one or more recipients, or receiving a transfer request, determining a correspondence via a transfer map and establishing a communication link over which the sender and recipient can communicate.

(In a current implementation, the broker agent determines any recipients corresponding to a current sender, establishes a communication link between itself and the recipient and then transfers its own link to the sender. In this implementation, a transfer map includes a path or location address or "handle" of the recipient, and linking establishes a physical link in a conventional manner via a hosting application server. Messaging is then conducted using RMI for any transfer portions within a server and SOAP/XML for transfer portions between servers.)

Agent-network configurations can also use similar or other mechanisms within non- broker agents or a framework for conducting non-brokered such transactions. However, an agent-agent communication is not currently used for remote persistence, and no need would exist in such cases for determining recipients of varying sender agents, since only the one directly connected sender agent would utilize such services.

Transfer map configurations or manners of navigating the one or more transfer maps, e.g. via policies, roles or runtime modified broker/non-broker agent information, can also be utilized in accordance with a particular application. A more specific transfer map utilization or runtime modification might, for example, be used to redirect communication or operation in accordance with a failed device or a new vendor (by using different map portions or replacing map portions upon a time/event trigger), to accommodate a legacy/user device configuration, to conduct a particular pattern of collaboration, or for agent network portion reconfiguration, among numerous other uses.

It will be appreciated in view of the discussion herein that the particular operation of a broker agent can vary considerably, for example, depending on whether one or more broker agents are also configured reconfigured for non-brokering (e.g., slice processing) operation, whether brokering operation is configured as framework/agent operation extensions or modifications (e.g., see above), as an independent operational element or to facilitate distributed or centralized processing of an agent network portion (e.g., such as with facilitating communication, loading or saving relating to one or more of agents and frameworks, or providing for sub-nets), whether broker agent operation portions are static or can be utilized in a more dynamic, as-needed or time/event triggered manner (e.g., according to a current state or service), among other considerations.

A user configurable broker operation might, for example, include further processing of data received from one or more agent network or underlying network elements (e.g. formatting/otherwise processing data for a particular extra agent-network system, interconnected network element, entity or user device). Such configuration might also include technical operation, such as loading or saving support (e.g., for locally/remotely storing or persisting its own or other agent information, where the broker agent conducts persistence for other coupled agents, and so on), among numerous other examples. In the above-noted hub-and-spoke configuration, for example, a broker agent can receive a message from another agent (including agent data or a condition), determine that it is to conduct a transfer, determine the manner of transfer (e.g. transfer, query, load or persist), ascertain a connected recipient corresponding to the sending agent (e.g. one or more agents, agent network frameworks or local/remote storage) and initiate the transfer (e.g. via one or more of individual, multicast, other broadcast or other transfers or transfer types). A better understanding might also be gained by reviewing the exemplary broker and non-broker agent implementions of FIG. 3 a and FIG. 5b.

The FIG. 6a agent network embodiment illustrates a live database example in greater detail. In this example, live database 601 is coupled via a transfer engine 621 for facilitating the aforementioned populating and persisting of one or more agents, including agent 620. As shown, live database 601 includes agent network framework 610 and persistence store 614. Agent network framework 610 further includes framework interface 610a and framework 610b, and storage 614 includes persistent store interface 614a and persistent store 614b. Additionally, in this example, agent 620 includes executable code and data (which can, for example, he configured in the same manner as agent 401 of FIG. 4), and further includes one or more roles 420b.

As was noted earlier, an agent network framework can provide for storing agent code/data with which agents can be populated in conjunction with deploying, or that is returned via one or more agent network elements. An agent network framework can further use returned information for updating agent network elements that might be affected by modifications included in the returned agent information, and can provide for persisting agent information in a persistent store, among other aspects. Such operation can further be wholly relegated to the agent network framework or such framework operation portions can also be facilitated or conducted by agents, and particularly in through configurations of brokering services, patterns or policies of one or more broker agents.

From the perspective of an agent that conducts transfers of information with or via agent network framework 610, framework interface 610a is configured to appear as a source and repository for the agent information. From this perspective, framework interface 610a provides for isolating agent 120 from particular data store types, configurations or interfaces that might be utilized. However, framework interface 610a can also be configured to provide a common data transfer interface that is optimized for conducting transfers among some or all agents inter-operating with or via agent network framework 610, or further, some or all agents interoperating with live database 601.

(It should be noted that storage 614, and particularly persistent store 614b, might also provide storage for other agent nets, such as in the case of a trusted entity providing such services or access to such services. Portions of live database 601 can also be configured in a distributed manner which, as a general matter, need not be known to corresponding agents or of concern to a user of the agents, given the isolation provided by 610a framework interface. Framework interface 610a, which is implemented as a more centralized/distributed cache in the present example, can also be implemented using other mechanisms or some combination in accordance with a particular application.)

Framework 610b includes associateable framework elements (e.g., elements 611a-n) to which one or more data aspects (e.g., 612a-m) can further be associated for storing and retrieving agent network information (e.g., agent elements and data), and which provide for mapping the information to storage elements (not shown) of persistence store 614. Aspects 612a-m include parameters relating to corresponding ones of framework elements 61 la-n, which elements can be organized in accordance with an application conducted by a corresponding agent net. (Framework elements and aspects will be discussed in greater detail with reference to FIG. 6b.) Persistence store control 613 provides, in the current example, for initiating operations of persistent store interface 614a (see below), but can also provide for directly accessing data storage elements of a persistent store in accordance with a particular application.

Of the remaining live database 601 elements, data store interface 614a provides for interfacing to particular data store types, or further, to particular data stores (keeping in mind that the data store might be distributed and might include data stores of more than one type or configuration). Persistence store 614b provides for persisting agent network information portions of corresponding agent network elements, and can further provide for storing portions of program code or data of an underlying system or can be used for other purposes as well.

For example, where a relational database is used as persistent storage mechanism 614, persistent store interface 614a will typically be a database manager or "database engine" that is capable of receiving commands for accessing data persisted within corresponding elements of tables or other "data structures" stored on a suitable storage medium (e.g., see FIG. 2). A portion of persistent store control 613 of framework 610b that corresponds with the relational database can provide for initiating control commands of database engine 614a for storing or retrieving data (e.g., load or "get" commands for the retrieving) to/from data locations indicated by pointers or "handles" stored in corresponding ones of aspects 612a-M. The particular data to be stored or retrieved can be determined by: accessing one or more of corresponding framework elements 61 la-N with which targoted aspects are associated, according to the type of aspects, aspect portions or framework elements, or by reference to a particular aspect or aspect portion of a particular framework element, among other examples. (It will be appreciated that one or more persistent store controls or portions thereof can be used to access different ones or types of persistent stores or for direct data storage loaction access. It will also become apparent that framework 610b or other agent net elements are capable of utilizing dedicated persistent storage mechanism query functions, which provide only gross data access functions according to the storage-optimization that is typically necessitated. However, more robust querying and other data utilization can also be conducted, e.g., by the above discussed data access mechanisms: in accordance with utilization of data within an application or portion thereof provided by an agent net portion, in a manner consistent with other agent net information portion utilization, such as messaging, loading, saving, and so on, and substantially independently of the particular persisting mechanism, mechanism type or mechanism distribution. Varying persistence types or "modes" can also be rendered user configurable, particularly where application slice operation, code and data separation or other agent net embodiment aspects are enabled, and especially where such aspects are provided in combination.)

FIGS. 6a and 6b also illustrate how a data transfer mechanism, such as data transfer engine 621 or one or more roles 620c (FIG. 6a) can also be used in conjunction with transfering agent information between an agent and a live database or non-framework store (e.g., "local" underlying system store) or for other agent net operation. Initial or runtime transfer loading of agent information to an agent (or "populating" an agent) is typically triggered by a framework initialization control. However, initialization can also be triggered by a user, external system element timing/event trigger or first initialized broker agent (e.g., via a current state or technical service, pattern or policy), in accordance with a particular application. Thereafter, additional runtime transfer (including any loading of existing or added new agents) of code or data can also be triggered by an agent, corresponding broker agent or framework, for example, for predetermined runtime agent modification or to respond to a transfer of modified agent information of a first agent by updating one or more other corresponding agents.

Saving (temporary or persisting) is typically conducted as a response to runtime agent information modification that is predetermined (during agent network design) in accordance with a particular agent configuration, e.g., a save state or broker agent service, pattern or policy (e.g., see FIGS. 4 and 5a). However, user or other initiated saving (including persisting) can also be used in accordance with a particular application.

Various loading/saving mechanisms can, however, be used, and such mechanisms can further be distributed (e.g., integrating data transfer engine portions within one, more than one or all agents, such as with agent 602 of FIG. 6a). Loading or saving mechanisms can, for example, include those of above mentioned co-pending application entitled "Loading and saving system and methods."

In the implementation of FIG. 6b, for example, agent roles provide a variable mechanism according to which loading and saving can be conducted. While a role might otherwise be configured as corresponding to other agent portions (e.g., one or more agents, services, states other data/code portions, associated broker, framework, cache, server, entity or some portion/combination), one configuration consistent with the FIG. 6b implementation provides a role that corresponds with each different policy, and further, with a corresponding transfer engine. Thus, not only can loading and saving (or other operations) be conducted in a variable manner according to association of a role with an agent, or further, agent slice or agent elements generally, but such operations can also be conducted at variable, or further, core granularities according to association with an operational slice and at a core, policy granularity. A further implementation associates each unique role within an agent network with a separate transfer engine. (Roles used by one agent can, however, be reused by other agents in the FIG. 6b example.)

In summary, each transfer engine 630a-d in the agent net given by FIG. 6b includes a loader 63 la-d for conducting loading operations, a saver 633a-d for conducting saving operations and an integrator 632a-d for indicating agent data to be loaded or saved and facilitating the loading/saving. Each role, via its configurable association to one or more agent net implementation portions (here, reusable policies, e.g., 621a and 621b) indicates the subset or "view," within the totality of data available to agent net 600b, that corresponds to the associated policy. (Code views, which can also include state or broker agent transfer map based or other role bases, can also be implemented via role embodiments in a particular implementation.)

Data within the view of available data corresponding to a role can be stored in framework interface 640 (via association with a corresponding business object or "BO"), or further, via framework 650 (via association with one or more corresponding common business objects or "CBOs" and CBO aspects) in a persistent store portion corresponding to a CBO. (As in the FIG. 6a example, data handles rather than actual data are stored in framework 650 of FIG. 6b, the access to which can further be conducted as with persistent store control 613 of FIG. 6a.) As with FIG. 6a, an aspect associated with a CBO includes a grouping of parameters according to the business model implemented by the framework. In this example, the model is implemented as an object-based business model including resource, process and order core elements and subclassed elements thereof, and each aspect type includes a user-configurable portion of a group of parameters corresponding to the element/subclass type and further element subtype/subclass (e.g., see modeling below). Thus, data loaded to or saved from an agent can be substantially parameterized separately from code (including any service, state, pattern algorithm, policy formulae, and so on) utilizing such data according corresponding associations, such as in the present example. Initial data, which can be provided as data object parameters or "data objects," can be associated during system configuration, while new/modified data can be associated, for example upon creation modification, or saving as in the present example.

Thus, using a flattened database cache configuration framework interface, for example, data can be loaded to an agent directly or indirectly (e.g., via one or more broker/non-broker agents) from a shared cache (see below), another agent, or a corresponding framework interface 640 (via a BO) if the data has been loaded. If the data has not been loaded, is otherwise not available or if otherwise desirable (e.g., more efficient resource utilization, use of a particular data portion that might be less straight forward to collect from agents/framework interface(s), and so on), data can also be loaded via associated BOs and further associated CBOs 651 , from a persistent store (e.g., via a mapping of CBOs to persistent store elements that can further utilize a persistent store control or interface (see FIG. 6a). Saving can further be conducted by substantially the reverse process. Combined operations can further be used. While other mechanisms can also be used, an arrangement having an agent network framework incuding a framework interface and framework, such as those depicted in FIGS. 6a or 6b, enables agent network agents to be serviced in a manner corresponding to an agent implementation. Such an arrangement further enables persisting can be conducted in accordance with optimized use of various information store types or configurations, among other advantages. Examples of loading and saving further in conjunction with a load list of agent data to be loaded to an agent via CBO aspects from a persistent store or a save list of data to be saved from an agent via CBO aspects to a persistent store are illustrated by FIGS. 7a and 7b respectively. (It will become apparent the referenced "parent" refers to a first or "highest" CBO in a hierarchical group of CBOs corresponding to an agent role, while a "child" or "children" refer to lower level CBOs associated with the first CBO that also correspond with the agent role. Such correspondence is stored, in the present example, by the BO corresponding to the agent role, for example, by a particular pointer or "handle" to each related CBO, aspect or parameters within an aspect ("data indicator", a handle to a first data indicator and relative next data indicator(s), by other suitable indication mechanism or some combination. See, for example, FIG. 6B.

Further loading and saving examples consistent with FIGS. 6 A and 6B are also provided by the above referenced copending application entitled "Loading and Saving System and Methods". Examples of loading of multiple agents in conjunction with the aforementioned core components (resource, process and order elements) from a persistent store or "physical layer" to the agents or "transient-logical layer" is further illustrated in FIG. 8a, and examples of loading resource, process and order elements from a persistent store to agents in accordance with roles are illustrated respectively by FIGS. 8b, 8c and 8d.

Variable Transient Agent Examples

As was already noted, the enabling of variable granuarity operation, application based operation or other aspects or aspect combinations according to embodiments of the invention facilitates providing a high degree of flexibility in various respects. Among these is the ability to provide for variable transient agent or persistence implementations.

Turning now to FIGS. 9a through 9d, agents can be provided as transient elements (e.g., applets or servlets) within an agent container, such as a cache. Working in cached memory with copies of persisted data (e.g. data objects persisted in a persisted framework, but in their ADM form) enables the creation of temporary scenarios that can be examined, then subsequently revised, removed, or saved back to the framework. For example, an process order to use a certain manufacturing machine at the earliest date possible (perhaps when the necessary capacity is first available) might return a result that is unacceptable to the user (i.e., too late for the user's purpose). Because the ADM can model scenarios transiently, the user can initiate an order for an alternate machine or abort the process without affecting persisted data in any way.

Caching of agents can, for example, be conducted in more than one manner. A present implementation, for example, is provided according to an observation that two cache mechanisms that can be selectively configured (e.g., during agent net design) can separately or together provide more optimal execution of most business or other scenarios: a single shared cache (FIGS. 9a and 9b) and a multiple cache (FIGS. 9c and 9d).

In the FIG. 9a through 9d examples, cache management is implemented via a kernel manager called the cache manager ("CacheMgr"). Every container holds, in memory, an instance(s) of the ADM, and instances of the ADM is called a cache. Loaders and savers aid in moving the data back and forth between the cache (memory) and the database. Data traveling from a skyva Container to the database is "saved," while data moving from the database back to memory to fill the cache is "loaded." The configuration file for the cache manger configures the loaders and savers. So, while the loaders and savers populate the cache with data, the cache manager manages the relationships (bindings) of contexts to caches. Two different policies called single cache mode and multiple cache mode dictate the configuration of the data model for a particular agent cache. The single policy enforces that multiple clients share one single cache (data model) simultaneously. The multiple policy enforces that each client obtains its own private cache (or "work context") for access to the data model.

Typical scenarios in which a single or multiple cache mode might be used are in business planning and execution respectively. (Corresponding agents, for purposes of the following variable caching examples, will therefore be referred to as "plan agent" and "execution agent" types.) Assume, for example, that a factory produces steel rods. While conducting planning, different workers may need to access the same portion of data for different purposes. The data portion might, for example, be provided by initial loading, conducting a data query (e.g., utilizing a data query service, such as in the FIG. 10a example) or one or more other transfer types, such as those already discussed. Some workers may want to check the quantity of two- inch rods being produced, while other workers might only want to check what machine is being used at what time. Most of the time, the workers might simply visually check the data without entering many changes. However, because they need to know the complete picture in order to plan, it is important that they view the entire system. Configuring a single or "shared" cache enables the workers to look at the same cache of the data model. (If, for example, a customer decided to order polishing of three-inch rods, a worker would then take polishing into consideration for the day's planning and change the order of the ^■ customer's rods. If each worker had his or her own data model, any time a change was made by any worker, the entire model might have to be saved to the database. Sharing a cache enables ready access to the data, including any modification, with the further ability to persist a composite of modifications to the data.)

Continuing with the rod example, during execution, which typically occurs following planning, numerous shop floor machines might constantly need to make changes to the data. In this case, working with one large shared cache might be problematic due, for example, to a need to reconcile changes or to frequently load and save data. Further, during execution and despite some overlap, the workers typically only need data relevant to their distinct task.

Using the multiple policy, data can be loaded or saved with regard a series of interactions or "units of work" that are configurable as a "transaction" for saving/loading purposes. FIG. 9a illustrates how, in a single cache mode 900a example, cache manager 905 is invoked to cause container 902a to hold at least one agent (e.g., service broker agent 903a) and a corresponding single cache 93 la accessed via agent services 921a through 923a by one or more clients 91 la through 913a. A configured transaction save stores the data (or modified data portion) to be saved in persistent storage 904.

FIG. 9b further shows how a single mode implementation startup of loading 951 initiates loader 952 which finds node object 953. (A node object can, for example correspond with the above-discussed parent CBO, for a load from a persistent store, or a framework node corresponding BO indicator for a load from a framework interface. As will be further discussed with regard to modeling, a node identifies a stored starting point for locating applicable data in a data hierarchy or other suitable structure that defines a collection of data in within which targoted data can be found (e.g., lower levels in a top-down or top-down and bottom up model hierarchy or a post). The data can be loaded directly from an XML file 954 or obtained via an application server 955. Once found (e.g., via a node object handle), the node object is then placed in load list 956 along with a corresponding integrator called by the loader, which load list is executed in integrator 957, and so on, until a load operation is completed (see the FIG. 7a loading example).

FIG. 9c illustrates how, in a multiple cache mode 900b example, cache manager 905 is invoked to cause container 902b to hold at least one agent (e.g., service broker agent 903b) and corresponding multiple caches 931b, 932, 933 accessed separately via agent services 921b through 923b by corresponding ones of one or more clients 91 lb through 913b. A configured transaction save stores the data (or modified data portion) to be saved in persistent storage 904 according to the configured transaction.

FIG. 9d further shows how a multiple mode implementation startup of loading 961 can be initiated by a trigger from a client (e.g., a user request for a data utilizing operation. Client 961 triggers a business service 962, which service passes object references 963 from one or more of, for example, queries 964, state model events 965 or prior service calls 966. Business service 962 either resolves the object references 963 to ADM objects 968 or, if resolution cannot be conducted (e.g., if an entry is not in a configuration file), passes the object references to contextualizable support load service 967. Service 967 then finds a cache manager 969 which finds loader via a configuration in an XML file, and then initiates a new cache and triggers loader 971. Cache manager 969 further initiates and passes to load list 972 the object references and a corresponding integrator. Load list is further executed in an integrator 973 that is called by the loader, and so on, until a load operation is completed (see the FIG. 7a loading example).

Note that single mode caching is not limited to internal agent net processing and multiple mode caching is not limited to user access via a client. Both can further benefit from the use of brokering services or small granularity process slice operation. For example, single mode caching can be used in conjunction with querying or other data transfer to return a pool of data usable by various other agents, for example, in a hub and spoke configuration (FIG. 3a) or as a precurser to further querying by the other agents. Additionally, since a slice granularity can be flexibly configured at variable, and particularly small granularity slices, processing of data portions in diverse unrelated conventional functional areas can be achieved without requiring all data that might otherwise be combined with a more conventional function, among other uses. Extra-entity processing can further be securely conducted by enabling a limited process slice or utilizing a role corresponding with limited parameters, for example, to provide for status or other information to be returned to a third party, e.g., via third party agent 304j of FIG. 3a.

FIGS. 10a and 10b, for example, illustrate how querying can be conducted in a similar manner as with loading or other communication, substantially independently of a particular persistent store or store type, or for directly or indirectly querying any one or more agent network elements. FIG. 10a illustrates an example of a service based query engine including target engine 1001, navigator 1002, selector 1003, navigator 1004 and visitor/operator ("operator") 1005. In this example, target engine 1001 and navigator 1002 policies (and corresponding parameters) are required, while the remaining policies 1003 through 1005 (and corresponding parameters) are optional.

Target engine 1001 provides for determining a starting point, and more particularly, a starting agent network element for conducting a query. As will be discussed, a hierarchy can be similarly used in conjunction with agent network elements and information, not for merely establishing an importance, prominance or business equivalent, but also for wrapping or "bounding" the elements or information. (While other bounding mechanisms or structures might also be used in certain cases to provide for such bounding, a hierarchical approach has been found to be more readily and generally applicable to varying desired purposes, such as in establishing a configurable prominance within a determinable grouping. See, for example, "parent" and "child" CBOs of FIG. 6B and "posts" below.) In this case, a configurable or otherwise selectable target (e.g., during design, by user entry during runtime, etc.) determines a selectable "top node" agent, broker agent, BO, CBO, and so on, or default node if none is otherwise selected, at which navigator 1002 will begin collecting data.

Defining targets allows navigator 1002 to jump to locations as close as possible to the requested data, eliminating the need to traverse long paths to reach the same or a similarly point that is substantially similarly close to requested point. In the current agent network example, a definition of targets is made in a corresponding manner with an entity hierarchy.

Navigator 1002 receives targets from target engine 1001 as input and uses them as starting points from which to locate and obtain collections of associated data (or indicators of such data). Navigator 1002 further examines the target parameters and determines therefrom whether the target parameters are compatible with the navigator's current needs. A customer order, for example, presented as a target to a navigator for purchase orders yields no results. Whether navigating within a framework, a business object model or data structures underlying the agents, once a navigator locates and obtains a set of data, that data becomes a static "snapshot" of the data requires a new query for providing an update of the data collection. (However, updating that can include but not limited to the below examples, can also be used in accordance with a particular application.) The output of navigator 1002a is a raw collection of data 1002a.

Selector 1003, when used, provides for refining a collection of data returned by navigator 1002. More specifically, selector 1003 determines, in accordance with selection criteria (e.g., formulae) which, if any, data portions in the returned collection of data should be further processed and which, if any, should be dropped from the collection. The output of selector 1003 is a filtered collection of data 1003 a.

Comparator 1004, when used, can operate even in the absence of selector 1003. Comparator 1004 sorts the raw or filtered collection results to produce a sorted collection of data 1004a

Visitor/operator 1005 provides for performing calculations on data within data collection that is sorted, navigated or both (requiring the prior use of one or both optional elements). Visitor/operator 1005 is canned an "operator" when operating within an agent query, and a visitor when operating within a BO or pushdown query. Continuing with FIG. 10b, the execution of a query can vary depending on the query type. Query types include agent queries 1012, which query data present with the memory (ADM) of one or more agents, and persistence queries, which can query data present in the BO data model (BO Queries 1021) or query data contained within extent groups in the data store, which querying can use native persistence store language (Pushdown queries 1022). BO query 1021 can pass through an agent and drill down into the BO layer (option A) or invoke directly on the BO layer (option B). (Option A is more typical for using data within an agent, while option B is a more direct way of simply returning collected data to a user. Each query type can originate at a client 1011. Server queries can originate on a server and can invoke directly on business patterns or technical services, returning actual data or data references.

Variable Persistence Examples

FIG. 11a illustrates how a unit of work management has clients access a single cache in an agent and where loading and saving always occur against the single cache or a single work context. FIG. 1 lb is an example of a single mode of the cache manager for a planning style application. Upon agent start up, the Loader is invoked against a Node in the Business Object world. This node is that Post or a Group node beneath it. The Loader then accesses this Node and iterates through it obtaining all the relevant Business Objects in the scope of this agent. The Loader takes the Business Objects and transforms them via the Integrator into the Roles for the agent Business Services and their Policies, in order to execute the business logic. Upon completion of the business logic, which is declared as a Promote or an Update of the changes Objects and their associations, the Save List is created, which is then executed by the Integrator and the corresponding updates to the Business Object occurs. An event issued from the Saver to the state model of the Business Object may also cause the Business Object to change groups and thus go out of the scope of one agent and into the scope of another.

The concept of a transaction or unit of work comes into play here, with the Loader being a single unit of work and the combined execution of the business logic and its Saving of its results logically another, with the Saving being the actual second unit of work, which may occur minutes, hours or even days after the Loading occurred.

FIG. 1 lc provides a review of the above discussed multiple cache mode, wherein each client has accesses to its own cache in an agent, and loading and saving can always occur against each of these caches or work contexts.

FIG. 11 shows an example of A multiple cache mode of the cache manager for an execution style application (e.g., see above). Instead of being triggered upon agent start up, the loader service is invoked by another service or by a user via a client user interface. After invoked, the loader passes a context with it, such as a node or, more typically, a collection of direct object references or pointers to individual business objects, as contained in the load list. The loader iterates through loading all the relevant business objects (e.g., via relationships) contained in the load list. The loader transformsthe business objects via the integrator into the roles for the agent business services and their policies (e.g., via business object to role mapping), in order to execute the business logic. Upon completion of the running of business logic (services), a promote or an update of the changes to objects and their associations, a save list is created. The save list is then executed by the integrator and corresponding updates to the business object are conducted. An event issued from the saver to the state model of the business object may also cause the business object to change groups, and thus go out of the scope of one agent and into the scope of another. (Note that one or more states or a state machine can be associated with or used to affect behavior of any agent net framework element.

FIG. lie illustrates how a saving mechanism can align a unit of work concept. Changes that are made to the data in an agent are tracked in an agent at run time and when a saver is invoked; an optimistic concurrency control further checks to see via decision relevance checks, whether the data has changed in the interim since the data was last loaded or since the last data modification notification to the agent for that object. If so and the change was decision relevant, the application unit of work can roll-back and applicable business service logic can handle the further processing to resolve the data disparity. If so, but the change was not decision relevant or if not, the update (save) can commit to the persistent store (e.g., database) as an optimistic commit (in which any persistent store level locking occurs at the time of update or save rather than at the time of a load.

In an distributed agent environment, broker agents and their "subsidiary agents" (that utilize the broker agent brokering services) can communicate with one another via the service broker, which typically implements SOAP/XML as the messaging protocol and via a Java Messaging Service (JMS) implementation. The "conversations" between the agents are coordinated via the broker agent, which may be a communicating agent needing to coordinate its state with the persistent store (e.g., database). The broker agent can use the same mechanisms as previously illustrated, using the single or multiple modes in accordance with an existing application or situation. Turning now to FIG. 12, the complex requirements of notifications in the business object design arise due to the needs of synchronizing the data cached in the ADM schema running on various agents with the data stored in the framework, for example, using IBM San Francisco. Since the business objects are a facade that maps to the various framework objects or elements in the persistent store, changes made to the framework can only be sent to the various agents through the business objects and their integrators. For this reason, when changes are made to the framework elements, change notification events are generated. These notification events are collected and dispatched when a database transaction commits. When the notification events are dispatched, the change is mapped back through the business object facade and eventually mapped back to the ADM schema to synchronize the ADM cache running on the agent.

The mechanism of FIG. 12 can also be utilized in conjunction with a broker agent. However, while other mechanisms might be used, the examplary mechanism of FIG. 12 is closely tied to database issued notifications, and thus, will be applicable only in conjunction with a database or other mechanism providing such notifications. (For example, event-driven messaging, flagging or other mechanisms might also be used.)

Agent Network Modeling Examples Because every business is unique, each entity customer will likely utilize agents in a different way. The manner in which agents are to be used can be determined in conjunction with modeling an overall business process, and various methods might be used, such as that of the above-identified application entitled "Business Modeling Apparatus and Methods". For example, a target domain such as a entity or entity grouping can be broken down into areas of responsibility, business functions, and even more specialized business services (a top-down approach). Business objects can then be defined, resource hierarchies created and state models defined. A further detailed design or "bottom-up approach" can then be used to transform the conceptual business process model into a functional agent. While necessary agents can be identified during the top-down modeling, bottom-up modeling or "deep modeling" provides for elaborating agents into more useful forms applicable to an efficient agent network.

In an exemplary one top-down approach, an assessment can be as to the goals and scope of an intended business operation facilitating solution. The solution can, for example, be identified according to an existing or desired business process. Thus, the real world business process can be defined so that its elements, hierarchies, and utilization patterns can be provided -even replicated in many cases- by resulting agent network elements. Thus, an analysis of the business process can be conducted to isolate business functions, inputs and outputs of these functions, supporting elements, and the organizational context in which they interact with one another. Many if not most of the functions will involve planning and scheduling events that take place as part of the process (which often includes several such functions). For example, scheduling shipments is a function that is frequently carried out as part of an overall business process that may involve other functions, such as planning transportation, planning storage or executing shipping orders. Each of these functions receives some type of input (i.e., a specific type of order, various resources, a prescribed way of doing things, etc.) and provides some type of output (i.e., orders, resources, a predicted process to follow, etc.). Thereafter, business objects and elements capable of comprising the business process can be identified.

Note, however, that data objects reflecting business interactions are found to be more suitable to an efficient agent-network solution than functional ones or combinations of function and data. In a Skyva implementation, for example, business objects (which can be applied to the above ADM model for agent network utilization) include: "resource elements" or materials, labor, facilities or just about anything else that is to be used, consumed, or produced; "order elements" or requests, instructions or other initiators that drive the process; and "execution elements" that describe steps that are to be taken.

The above top-down analysis is, however, found to be of only limited utility, and a significant improvement is found to result by establishing relationships among and life cycles for resultant object selections. While other advancing mechanisms might be used, state models capable of providing states, transitions and (agent) conditions corresponding to states/transitions are found to enable a more useful solution. FIG. 7, for example, illustrates an exemplary order state model of an overall process (e.g. maintained by a framework or broker agent). As shown, an order input defines an initial state condition which, during processing (by one or more agents) transitions to a further state corresponding to an order changing state condition, and finally, a final state, which can be reflected and communicated via agent- messaging in a corresponding order ending state condition (e.g. order shipped or bill paid, as might be applicable in a given instance).

Additional efficiency can also be gained by organizing and defining a basis for operation in accordance with the resulting implementation, which is again found to provide a more efficient solution according to a common data model rather than by function or function- data combination. Such basis can, for example, be provided in accordance with determining resource hierarchies and areas of responsibility and providing accessible views into resulting hierarchical nodes; such definition can be conducted as an added step of a top-down analysis. Accordingly, determinations can be made as to available: resources (see above), whether varius levels more generic categories of resources can be formed (e.g., based on resource purpose), and categories for indicating entity resources within which the categories are to be managed. Such categorization can often reduce the number of descriptive processes or state models needed to describe changes that can occur with regard to the resources. Such categorizating can also be used to provide a reduced, "node based" data communication mechanism wherein an aggregate node encompassing applicable data can also be used for identifying, transferring or processing pertinent data (rather than merely on an individual basis that might result in processing of data that is not applicable in a similar instance.) Any object can, as a general rule, be a member of a hierarchy, and an object can belong to more than one hierarchy. However, an agent should not have a hierarchy that contains the same object more than once. A worker in production, for example, might belong to a hierarchy of company employees whose schedules are similar at the company level (same holidays, vacation rules, etc.); this same worker might also belong to a hierarchy of production workers who are scheduled for use as orders are received. These two different functions can thus use two different agents, which separately utilize two hierarchies for this resource (e.g., the worker in both instances).

As the prior example suggests, the use of resource hierarchies and other business object types can be facilitated by associating the objects with an appropriate level within an organizational model that identifies Areas of Responsibility (AORs). AORs are levels that control the circumstances regarding the business object. For example, an "organization" or "enterprise" for which an application is being developed might extend across multiple entities and might further include suppliers and customers. AORs can also be described as hierarchical in nature, with responsibilities of higher level nodes controlling a broader range of activities than those established at the lower levels. For example, planning at the enterprise or company level is generally different than planning at the level of the lowest unit. It will be appreciated that the formation of such hierarchies is facilitated through the use of business process slices that can be provided at variable processing granularities (e.g., that can relate, as needed, to one or more of order planning, personnel planning, various scheduling, execution, etc.). Contrastingly, bottom up or "deep modeling" can be used to transform a more generic collection of objects into a specialized reproduction of a physical process in which the configuration of elements becomes a determining factor as to how orders will be processed. An order net can, for example, be formed by modeling order elements in accordance with input and output orders of business functions. Resource elements can further be modeled as objects in a resource element hierarchy, and the manner in which they are used, consumed or produced based upon a description of order data. Descriptive processes for describing how a process is to be conducted can further be efficiently modeled as corresponding to an associating of resources and orders. Descriptive process models can still further be rendered more generally applicable using parameterized formulas derived as encapsulating a large number of the possible variables in a business process.

Deep modeling can also provide for optimizing a business process/application representation in the agent network. For example, it is found that a separation of functional elements into generic elements that are not modified by a consumer and modifiable elements yield a more flexible and efficient agent-network implementation. For example, forming a solution based on a particular current problem has, in the past, yielded extremely short-lived solutions involving situation-specific rules (e.g. providing a function to accommodate an existing low throughput machine). Describing a problem in more abstract terms according to generic situational description and variation (e.g. such as the above-noted service, pattern, policy model), as facilitated during deep modeling, provides for more flexible and long lived solutions (e.g. defining a machine/user throughput and its application to different machines or alternative order accommodation, such as outsourcing). Such solutions are, for example, adaptable to typically evolving business process needs (e.g. interactively or automatically changing a manufacturing machine/user output attribute in accordance with a purchase, performance or personnel adjustment). Providing variable combinations of basic logic and modifiable extensions at different levels (e.g. the above-noted services, policies, patterns and pattern policies) is also found to enable a useful added degree of flexibility for accommodating more complex scenarios.

Thus, deep modeling, which is generally more applicable following a top-down analysis, shifts the focus from characterizations of a business process or physical elements that might be utilized, to core objects (e.g., resource, order and execution or "process" elements, in a Skyva implementation) and a definition of the objects and their inherent qualities. One result is a drastic decrease in model maintenance in accordance with modeling the physical world in a generic way using parameters (e.g. rather than modeling policies for every possible business rule. Further, properties of entire groups of objects can be maintained in a single place (e.g. versus having to maintain the same property with each individual object). Thus, while necessary agents are generally identifiable during top-down modeling, it is during deep modeling that agents are elaborated from a conceptual model into functional agent-network elements.

An effective deep model also drastically reduces the number of objects to be maintained, and the complexity of a deep model allows for a very compact description. A deep model can further be easily and drastically changed with minimal effective changes to the existing model, and a deep model reveals insights into the underlying physical reality, providing an opportunity to improve the business process. Such benefits not only produce deep models requiring less storage space and a reduced time for decision-making and access, but such factors as a generic foundation and its reduced maintenance also facilitate the modeling of global supply chains across entity boundaries. The following are examples of the use of deep modeling.

Using orders to drive a process, it is generally found to be more practical to deep model orders before resources, as this tends to uncover and detail applicable resources, as well as requirements associated with the resources involved in a descriptive process. However, an important factor is in identifying the information that a given order has to pass on to an agent responsible to fulfill the demand. Thus, deep modeling of an order might include: providing an order-ID, quantity and due date, modeling the requirements (i.e. demand) for the order, describing these requirements as used, produced or consumed, and identifying the different order roles needed to communicate decisions throughout the business process. (Note that orders, as described herein, can be utilized as input and output, and can include customer orders, purchase orders, purchase requisitions, and transport orders, among others.

Deep modeling of resources might, however, be easier to identify than order elements, since they are often the most physically identifiable business objects. A useful deep modeling of resources, for example, includes enumerating each resource element at its most detailed level (materials, machines, labor, etc.), which can be derived from the business process model (discussed next). This step includes deciding which final, intermediate, or raw materials need to be modeled, and determining which facilities, labor, and tools are used or consumed, and at the aggregation levels at which these resources will be modeled. Further resource deep modeling steps include providing a name and description for each resource, establishing a quantity, identifying a method for handling capacity, and using that to identify the correct capacity policy for the resource. Still further steps include identifying fulfillment policies with each resource element (e.g. by selection out of a catalog of these policies), determining which of the resource element's attributes should be parameterized to account for alternatives/variations inherent in the business process, grouping the resources from the bottom up into resource element hierarchies. Another step includes identifying the different "roles" needed to represent the resources, for example, by stepping back from the instance model described above and abstracting a metamodel from the instance model. (Note that not every resource might qualify for each step; for example, some resources may not have a "capacity" or other characteristic. However, understanding how each step provides for more deeply defining a resource is found to be useful.)

Deep modeling of a descriptive process, once order modeling has provided the requirements and resource modeling has provided a preliminary view of the resources involved, begins with identifying resource/process elements needed to execute the process; many of these may have already been identified during the earlier modeling. Descriptive process modeling further includes identifying the quantity of the resources needed for the process, identifying the sequence in which the resources are used in the process, identifying the formula(s) needed to articulate any parameters that define the resource elements.

Still further descriptive process modeling steps include stipulating the duration for which the resources are required, composing the Descriptive Processes (often as a nested structure of descriptive process elements or "DPEs") and requirements for resource elements or "REs", structuring the DPEs (if more than one exists) as a recursive series of steps, and identifying and naming the parameters to be used at the right place in the DP structure. Additional steps include identifying parameterized formulas to be associated with the parameters (by selection out of a library of these parameterized formulas), and identifying how a descriptive process will be looked up for use in the fulfillment of a demand triggered by an order. It should be noted that particularly policies benefit from both top-down and deep modeling. Extremely low model maintenance effort with maximal runtime customization flexibility can, for example, be achieved in especially an object-oriented environment. The meeting point between top-down business process modeling and bottom-up deep modeling is situated in the selection, editing, and creation of policies. Each collaboration model can provide for policy extension points, which represent essential focal points for deep modeling. This policy specification captures the customer-specific business rules, which work relative to the customized resource, process, and order hierarchies already identified. Alternatively or in conjunction with top down modeling, the organization of data, (or in effect, the partioning of the data) in an agent network application is an important piece of modeling effort. This organization of the data occurs by creating a post as an intersection of business function and area of responsibility and then aligning the post with an organization hierarchy. What this does is defines the scope of each of the agent applications at run time according to the post. Beneath the post are group associations, which can be n levels deep. But, at the simplest, you have a group for resource elements, order elements and process elements, which are then the inputs (coming into scope of the agent) and a separate set of group for the output (results of the agent). The scope is given by the post, which is a function of the business function (planning, scheduling, execution, etc.) and the area of responsibility (Company 4711, Plant A, Manufacturing Area C45, etc.). What occurs here, is that the input groups are used for loading and the output groups are used for saving, groups act as secondary indices for business objects. A business object can be placed into n groups, so long as the group names are not the same. (Otherwise, duplicate record faults can result.)

Agent-Framework Architecture Examples

Thus far, various aspects have been considered largely from perspectives of an agent network, logic-data utilization, particularly common model agents and agent modeling techniques. We will now consider an agent-network and agent-network elements from an architectural perspective. It is believed that further consideration of the relationship between agents, frameworks and the data that ultimately determines actions advanced by such elements will provide a better understanding as to the manner in which an agent uses information to perform its function.

Beginning with the FIG. 8 multi-tiered architecture example, when a user interacts with an agent (e.g. using a GUI interface, web browser or other suitable interface mechanism), they are in effect issuing commands to a receiving agent to cause the agent to present data back to the user or as a request for a decision. As noted earlier, an agent is configured with business logic for performing a process slice that, in this case, enables the agent to provide the presentation or decision alone or in conjunction with other agents. An agent can only make decisions based on data which has been loaded into its ADM via a loader from the underlying persistent framework, a user interface or another agent). Once a decision has been made as represented by execution logic, a changed condition of the ADM can be communicated to the UI, via the agent network (e.g. a broker agent) to other agents, or saved persistently to the framework. Based on an object's condition in the ADM as it is saved, its condition may result in an underlying state change of that object as persisted or other persisted objects. In the Skyva implementation, transfer of persisted objects to and from the database is facilitated by the use of transaction, persistent and query management, such as is provided by IBM San Francisco (a provider of application server services capable of translating from an object implementation to a relational implemented on the database).

FIG. 9 further illustrates an example of how a user can interact with an agent network via a browser, which browser issues commands to a web server via HTTP. The commands invoke servlets on the web server, which pass on the request to a data transfer service, typically using remote method invocation (RMI) or Java messaging service (JMS). (Commands via the HTTP cause a service invocation to an agent configured as responsive to such user action, and the agent responds as given above with reference to FIG. 8. It should be noted, however, that loading and saving typically interact with business objects, which provide a single point of access for all agents requesting or receiving data from framework objects and their extensions or subclasses. (Loading and saving interact solely against business objects and have no visibility into the underlying framework.)

FIG. 10 illustrates how communication between agents or a non-broker agent and a broker agent can be conducted using standard protocols, such as soap and xml. It should be noted, however, that all agents speak the same language using syntax based on the ADM (i.e. the message traffic is primarily data driven among agents who understand the deeper meaning of the data based on the ADM). Thus bandwidth can be minimized.

The above multi-tier configuration also provides for variably secure transactions enabling slices of business processes to maintain data integrity against an underlying database. In prior application-based systems, data integrity would be guaranteed by only one of either pessimistic or optimistic locking schemes depending on the particular type of business application, thus dividing business applications into different non-interoperable categories. However, in a transaction system according to an embodiment of the invention, an optimistic locking scheme is used as its base, but with two types of transactions: short run and long run. Short run transactions provide for loading, execution of business logic and saving in a single transaction, while long run transactions provide for loading, execution of business logic, saving in three separate transactions. As a result, both optimistic and pessimistic locking schemes are enabled. Abstract Data Model Examples

Finally, FIGS. 11-13 illustrate the above-noted Skyva abstract data model or "ADM" embodiment in greater detail. As was discussed, based on a user's configuration, an agent loads the necessary data from the objects persisted in the framework, and only those objects that are required by the agent are loaded to provide a workable view of that data. This "view" of the data structure, the ADM, allows the user to interact with a transient set of objects and then promote those objects to the framework when the necessary changes have been made. While the ADM employs only those objects and that data required by the business service that the agent is undertaking, the Framework persistently maintains all the business objects as well as the state model(s) that have been defined for the current application. In effect, the agent makes the decisions required between the discrete workflow steps based upon the information loaded from the framework and the orders/requests provided by the user. Once the agent has made its decision, the user can examine the resulting information manually or that information can automatically trigger an action based upon the agent's logic. In turn, this information can be promoted to the framework where the data is made available for other agents at other posts.

1. Abstract Data Model Elements

Agents deal with the way in which the input from an order stipulates the resources that are used to fill requirements, and those orders that correspond to the responsibilities of the post. The method or plan that outlines what is required to be done with the appropriate resource element(s) is found in the descriptive process.

To reduce the amount of model maintenance required for this descriptive process, the process employs parameters and formulas that are used to define the orders, resources, and requirements. Because parameters and formulas define these elements and not the process itself, the need for maintenance of the descriptive process is minimal. Through this "parameterization of the process," the business patterns (in conjunction with policies) hold the information that dictates the next step to be taken in the process. This design avoids the need to duplicate processes that have several elements in common. For example, a process called "Packaging" does not need to be changed whenever changes to the material being packaged takes place. Instead, parameters can be modeled that account for many of the variables that are possible. In this way, the "Packaging" process remains the same while the packaged materials, the duration of the process steps, the boxes that are used to package those materials, or even the line where the packaging takes place may change. Parameters, often in conjunction with formulas, determine which possible choices the agent may make. In a similar manner, policies can be attached that allow decisions to be made at runtime based on specific business rules that apply to a given situation. Many policies are transparent to the user and may even be switched with other policies.

The following example shows how an agent can use the data and configuration of various ADM objects to produce a set of objects that can then be saved to a framework. As illustrated in FIG. 10, the results of an agent's decision-making may include the predicted processes that outline what is to be done with the data (the "operational requirements") regarding the order, resource elements that have changed their states (have updated attributes), or one or more order elements (with their operational requirements) that initiate additional steps in the process; these changes consequently move the chain of decisions known as the order net forward.

Turning to FIG. 11, as an example of this process, a post assigned to perform planning (its business function) for the use of machines in a shop (its area of responsibility) might receive multiple orders for various parts that subsequently need to be assigned to the various machines for fabrication. Using the data (e.g., quantities, sizes, or other descriptive features) from the incoming parts orders, the agent determines the data (e.g., machine assigned, schedule, etc.) to be included on the outgoing fabrication orders. Many of these decisions may be made by policies that apply rules to a given circumstance (or set of data attributes) to prioritize and choose a particular action.

Once the necessary decisions have been made, the changes initiated by the agent can then be promoted to the Framework objects that served as the original source of the ADM objects. It is important to note that changes made by the agent very often include the creation of totally new objects for which there is not yet a counterpart in the framework. There is a mapping between an ADM object and a framework object that facilitates this action.

2. Abstract Data Model (ADM)

The Abstract Data Model is a transient cache of objects copied from the persistent framework. More specifically, only those objects that are necessary for the post to perform its function are loaded from the framework to create the ADM. The ADM provides the interface for the application, while the framework offers an interface for persistent objects. In the Skyva implementation, the agent's transient model is comprised of pure Java objects that are instances of the agent's ADM. Within the ADM, the requirements placed upon a resource element can be examined and directed. Allocations between these requirements capture the complex structure created by the supply/demand match. In addition, constraint violations are used to reflect behavior that does not conform to predefined standards.

3. Resource Element (RE)

Turning now to FIG. 12, a resource element or "RE" can be any kind of facility, tool, means of supply, labor source, or other possible resource. The manner in which that resource element is used, consumed, or produced establishes the process that takes place and is often determined by policies attached to the resource element. In addition, a work calendar could be linked to the resource element to provide the availability (in time) of that resource. Plus, a resource element may be kept in one view on time-based variables (TBVs), which may be used to track the use/consume/produce of resource elements over time. In other words, a resource element in this context has a time dimension to it that represents, for instance, the past, present, and future capacity of that resource element.

Consider, for example, the process that describes the use of a truck (RE) to transport materials. This use of a truck is a requirement (DReq) that might specify which track to use, the quantity of trucks to use, or the duration that the truck will be used in the process. Once an order occurs, the information provided by the order determines which truck is required (the relationship between the OReq and the RE). Frequently, policies will exist that govern these requirements. A capacity policy, for example, might check to see if the value provided to the requirement violates that resource's (the truck's) capacity (is too large for the truck to hold). In this case, the value that the capacity policy considers might be a pool of values that have been added together until capacity or a preset time of shipment is reached. Additionally, the truck in this scenario might also be associated with a TBV that uses some of the data regarding duration and capacity to show the use of the truck over time. Finally, a work calendar could be used to designate days when the track would be inactive due to servicing requirements.

4. Descriptive and Operational Requirements

The descriptive requirements (DReq) that are linked to a resource are part of the descriptive process (DP) that prescribes the steps to be taken regarding that resource. Descriptive requirements are subclassed by the way in which the resource that they reference is employed in the process. The three resulting subclasses are the Descriptive Use (DUseReq), Consume (DConsumeReq), and Produce (DProduceReq) Requirements. Since a descriptive process only shows how resources could be used in a process, a descriptive requirement must be instantiated as an operational requirement (OReq) for a predicted or an actual process. Like Descriptive Requirements, Operational Requirements are subclassed into Operational Use (OUseReq), Consume (OConsumeReq), and Produce (OProduceReq) Requirements based upon what happens to the linking resource element. In addition, a requirement that expresses the availability of capacity during a specific duration, called the Operational Work Calendar Requirement (OWorkCalendarReq), can be attached to a resource to show when a resource cannot be used.

5. Time-Based Variables (TBVs)

Time-based variables or "TBVs" track the use/consume/produce of REs over time and therefore provides, for example, the capacity information as a function of time. In order to accomplish this, the TBV uses data that is recorded during specific periods of time. This period during which the value of a TBV remains constant is called a variable snapshot. The variable snapshot holds the data from one and only one predefined period of time; each variable snapshot has an absolute start time and an end time determined by the absolute start time of the succeeding variable snapshot. The data contained in the variable snapshot depends upon the OReq(s) associated with the RE whose capacity usage is being tracked.

For example, within a manufacturing order, you might have a process (an OPE) that requires a quantity of 1,000 widgets (an OReq) to be produced by an aggregate pool of machines (the RE). A TBV would monitor the status of this machine through its associated variable snapshots. The variable snapshots, in this instance, would provide the value of the quantity of machines to be used, and this information could be used to calculate available capacity on the machine.

Variable snapshots operate by recording the data associated with an OReq. Since more than one OReq may be associated with an RE, a variable snapshot becomes an aggregation of all these associated OReqs. Currently, only one TBV on an RE is permitted in an ADM according to the Skyva implementation.

6. Work Calendars A work calendar encapsulates the availability, in time, of a certain resource element. In its simplest form, a work calendar identifies whether a work period is considered productive time or nonproductive time. For example, a manufacturing facility may have a shutdown period for maintenance, and the work calendar would be used to represent the fact that the facility is not available for use during that period.

The foregoing description of preferred embodiments of the invention is provided by way of example to enable a person skilled in the art to make and use the invention, and in the context of particular applications and requirements thereof. Various modifications to the embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles, features and teachings disclosed herein. The embodiments described herein are not intended to be exhaustive or limiting. The present invention is limited only by the following claims.

Claims

WHAT IS CLAIMED IS:

1. A method, comprising: overlaying an interconnected network with an agent network of agents for performing respective slices of a business process; and populating the agent, via an underlying agent-element framework, with a predetermined collection of services and policies associated with the services, an agent state machine, and one or more roles according to which the agent is operable.

2. An agent network produced according to the method of claim 1.

3. A system, comprising: means for overlaying an interconnected network with an agent network of agents for performing respective slices of a business process; and means for populating the agent, via an underlying agent-element framework, with a predetermined collection of services and policies associated with the services, an agent state machine, and one or more roles according to which the agent is operable.