characteristics of converged network based voice and data applications. This will be ... information storage systems including company databases,. ⢠and direct ...
Issues In Using an Agent Framework For Converged Voice and Data Applications D. Pinard, T. Gray, S. Mankovski, M. Weiss Mitel Corporation Debbie_Pinard, Tom_Gray, Serge_Mankovski, Michael_Weiss @Mitel.com -
ABSTRACT This paper describes the issues arising in the use of an agent framework as a technology platform for rapid development of next generation business communications systems. New communications systems will provide an enterprise wide multimedia environment for information delivery and communications services, and will be an integral part of the business process [7,27,8]. The architecture of such systems must enable customization and incremental evolution to accommodate the changing needs of an enterprise, its different work groups and individual users. The architecture must handle the rational management of resources, including automatic reconfiguration on failure and pervasive self-management. Despite the increased complexity of such systems, developers will be faced with users demanding greater ease of use, and quicker turn around time. Present voice systems cannot meet these requirements without a fundamental change in architecture. We have examined a variety of alternatives and decided that an agent based system can meet these requirements. Mitel has developed an agent based framework, MANA (Multi Agent Networking Architecture) [1,2,3,4,5] which we are using to develop a communication system which meets the service needs of customers and the business needs of the development organization.
1. Introduction The communication industries for both data and voice applications are entering an era in which their verities will no longer hold true. With the advent of technologies such as the Internet and fibre optics, these previously separate industries must confront the reality that their markets and technologies are converging. Within the next decade, new applications enabled by new infrastructures will supplant the old. The next generation of business communication systems will need to provide an enterprise wide, multimedia information delivery service and communications environment that is part of the enterprise process [27,7]. The enterprise may be geographically distributed and may have connections to other independent businesses. Such systems will unavoidably be supplied by multiple vendors and therefore must conform to open standards in both hardware and software. Despite the increased complexity of such systems, users will insist on greater ease of use, maintenance, administration and more rapid product development.
As we move into the future, companies are facing an ever increasing demand for quick turn-around of products with a large number of features. As systems become more complex, this becomes a much harder goal to attain. Company profits and share value will be related to the rate at which a company can foster product and technological innovation. It is imperative that the players in these industries understand this convergence and develop technologies, platforms and methodologies that will allow them to compete in the new environment. It was with these thoughts in mind that Mitel developed a next generation architecture to bring the company into the twenty-first century [6,16]. MANA (Multi-Agent Networking Architecture [1,2,3,4,5]) includes not only an agent and agency architecture but also a developmental methodology for applications. The paper has the following structure. There will be an introduction outlining the characteristics of converged network based voice and data applications. This will be extended in Chapters 2 and 3 to include issues surrounding the business and development aspects of such systems. Chapter 4 is an extensive examination of requirements of both these applications and the infrastructure that must be designed to support them. Chapter 5 concerns the applicability of agent systems to satisfy these business and technical requirements using a general reference to agent capabilities and examples from MANA. It is not the intent of this section to describe MANA fully or to make claims on its effectiveness in meeting these requirements. MANA is used as an example of how an agent system can tackle such problems.
1.1 Background We have begun our effort from the point of view of Mitel’s traditional business in PBX (Private Branch Exchange) systems [28]. A PBX is a voice system that provides enhanced telephony features to an enterprise. As the convergence of voice and data systems comes closer, the traditional proprietary PBX system will have to mold itself into the new paradigm. The future will provide a new communication model both within an enterprise and between enterprises. Gradually, the currently disparate systems of communication will coalesce into one communication entity. This process is commonly called the convergence of voice and data systems. Today, communication is carried out through: •
voice systems,
•
data systems including email,
•
information storage systems including company databases,
•
and direct human to human meetings.
New systems must manage the information base of a company and subsume all communication processes. In doing so, they will become an intrinsic part of the business processes of the enterprise. They will be used to facilitate the planning, control, operation and communication needs, by fostering asynchronous and real time discussions. In brief,
the converged communication system will become inseparable from (if it does not supplant) the Computer Supported Collaborative Work application of an enterprise. Inevitably, such a converged system will be both multi-vendor and heterogeneous; no single vendor will be capable of supplying all required resources. As a result, the system must function in an environment that is not precisely defined and is constantly changing. Since it is an essential part of the business process of the company, it is as a "mission critical" application; the system must remain stable in the face of failure. In this sense, the system must be adaptive enough to detect failures and it must function predictably while, at the same time, attempting to reconfigure its resources to meet the defined system requirements. Systems like this will be used to aid the human interaction within a company. They will supply the necessary tools to coordinate human behavior within the enterprise system. A user must be able to define a connection or application on the fly and be assured that it will work.
2. Business Requirements Best in class companies are able to provide systems that meet customer specifications and expectations and have quick time-to-market, sufficient or appropriate quality, and low cost at a profit [22]. The products themselves must be capable of being elegantly customized to the needs of each specific enterprise and customer.
3. Developmental Requirements To meet the needs of quick developmental response and product customization, best in class providers focus on product platforms that are independent of specific products. New technologies are introduced into the platforms, not into the products, but are linked tightly into product development so that technology building blocks are available when needed. These platforms must have understandable and well-defined layers. These must be enabled with tools which are easy to use, flexible, and OS independent. Best in class providers should also have a development process that is modular, multilevel, integrated, structured, facilitative, repeatable and predictive, with a set of metrics that provides for process improvement.
4. General Characteristics and Requirements Architectures provide a framework from which systems can be built. A base framework can be supplied from which converged applications can be developed. Convergent systems are marked by certain characteristics at both the framework and application level. They must be prepared to create applications by coordinating the activities of resources on this converged infrastructure. For a similar type of problem in the distributed database field, see [21].
4.1 Framework Level Requirements A converged communication application must be customized to the needs of a specific organization. However there are general characteristics of such applications that will be common for all organizations, which can be incorporated in a framework. Such applications can be described as: •
responsive
•
appropriately reliable
•
conversational
•
evolvable •
service transparent
•
technology transparent
•
location transparent
•
self-maintainable
•
self- configurable
•
evanescent
•
unattended
•
mobile
Responsive systems supply services that meet both absolute and relative timing constraints. Responsive systems do not necessarily have short time requirements. Responsiveness means that the system can meet the time guarantees of the applications using them. The time requirements may be short or long. It is necessary that the system be able to set up and monitor appropriate timing constraints and take remedial action if necessary. Appropriate reliability refers to the level of reliability that matches the needs of a system. For example, a mission critical system supplies services that are essential to the functioning of the enterprise that they serve. The framework must be able to supply an appropriate level of reliability, ranging from life critical to convenient, to meet the needs of specific applications and their place in the enterprise as a whole. Conversational systems imply the creation of peer to peer relationships among applications that go beyond the typical client/server case. Services in such converged systems will involve direct collaboration between humans, machines, and humans and machines. Conversational systems allow the participants of an application, both machine and human, to learn of each other’s capabilities and deficiencies. Each side can adapt its service strategy to conform to the capabilities and limitations provided by the other. This adaptation allows the system to make the most efficient use of resources and to create services that are specifically suited to the needs of the user.
Evolvable systems are systems that are designed to facilitate change. An evolvable system is both service transparent and technology transparent. It can create services independently of the technology supplied. It can concurrently modify the supplied technology without changing the definition of its services. This will allow the technology platform to adapt itself to the changing requirements of the enterprise it serves by adding and deleting services as needed while at the same time maintaining stability. Location transparent systems can utilize devices independently of where they are supplied in the network. With this the system can also provide services to any point in the network. Users can be located anywhere on the system at any time, and the application can adapt to the resources that the user currently has available. This is especially valuable for home based workers and workers operating from remote sites such as hotel rooms in distant cities. Systems will have unique configurations specifically selected for the enterprise they serve. Furthermore, an enterprise will customize the system by setting the priorities on the interaction of the individual applications to meet its specific needs. Therefore there is no standard system configuration. This means that systems must be self-maintaining. They must be able to provide help to users for a customized application. They must be able to realize when the application is not working correctly, since the customized application is the only entity that knows its configuration. Self-configuring systems can generate their own configuration from a specification of required applications and supplied equipment. A self-configuring system will need to generate the required configuration for the applications described to it. Such a system will require unambiguous specifications of applications and equipment. It will require the component applications be predictable so that it can reliably reason about them. Systems will be required to create new user services and configurations on the fly. Services and configurations created to fulfill urgent business needs will require people and devices drawn from across the enterprise. Such services will constantly be created and destroyed as the need arises, without the benefit of time for analysis and testing. Such systems can be called evanescent since these services will have only a fleeting existence. Unattended systems are designed to operate without the intervention of a human operator. Most small companies cannot afford resources for maintenance, and vendors cannot afford to fill this void. Therefore, systems must provide the capability of automatic repair and reconfiguration on failure. They must provide the ability to assess failures and provide alarm information and notification to appropriate recipients. Converged systems must be able to adapt and recover from routine failures and to strive as much as possible to maintain vital service; even if this means temporarily turning down less vital applications. Systems must be able to supply information and services that are mobile. This means that users must be able to obtain information, and carry it with them, with the ability to have periodic updates and resynchronization with the main information base. It also means that users can receive and send information without being wired to the system. It
can also mean that the user who is distant from the system (for example a sales representative in a distant hotel room) can use the Internet or similar system to make contact with his local system.
4.2 Application Level Requirements In contrast to previous data systems and more akin to voice systems, converged applications will be multi-user and multi-application. Instead of simple email or voice calls, converged systems will function as integral parts of an enterprise’s activities. They will be required to coordinate the activities of multiple users who are collaborating through the use of multiple applications concurrently.
4.2.1 Service Creation and Coordination in a Converged System Inevitably the need for converged systems to be multi-user and multi-application will lead to problems at the application level. This has been characterized as the ‘Feature Interaction Problem’ [17]. Many applications will be active at the same time; each trying to achieve its own goals and to share the resources of the network. These applications will have been developed in isolation from each other. The feature interaction problem concerns the coordination of disparate applications so that they cooperate to achieve a desired enterprise result. The parameters of the feature interaction problem have been described as [17]: •
conflicting goals
•
competition for resources
•
changing assumptions on services
•
design evolution through time and design by other organizations
4.2.1.1 Conflicting Goals This problem concerns applications that have the same preconditions but are attempting to achieve incompatible goals. This is most clearly seen through a voice system example of campon and call forward. In both cases, these features are triggered by a telephone call to a busy extension. However, their goals are incompatible. The campon feature wishes to play a tone announcing that a call is waiting and leave the calling party on hold listening to ringing. The call forward feature (in all its innumerable variants) wishes to leave the called extension and redirect the call to another. Any coordination mechanism must be able to recognize the incompatibility of certain features and provide means to resolve these incompatibilities gracefully. Other more subtle and complicated examples of this problem are common. Simple preference lists are ineffective.
4.2.1.2 Competition for Resources There will be a specific set of resources available to any system. Because of cost and other reasons, this set of resources will be finite. Applications will compete with each other for access to these resources. Coordination mechanisms need to be in place to
partition these resources among applications and optimize the performance of the overall system. Competition takes place on at least two different time scales: • at initialization, negotiation of the optimum partition, • at run time, resource selection to optimize performance and to overcome faults.
4.2.1.3 Changing Assumptions on Services Services designed today bring with them implicit assumptions about their operation. These assumptions become invalid with the addition of new services and new technologies. Techniques must be used to make these assumptions explicit and to protect existing applications as much as possible. This can clearly be seen in voice systems in the reliance on the concept of busy or engaged to trigger services. A common feature is Call Forward Busy in which a user can specify that if his telephone is busy, any incoming call should be forwarded to some other number. However, consider the case of a PC telephone that is capable of handling several calls and other applications such as word processing, simultaneously. How will ‘busy’ be defined in this case? Is someone busy, using a word processor? How can a central server gather knowledge about the specific ‘busy’ assumptions needed for any number of different clients each capable of terminating a telephone call?
4.2.1.4 Design Evolution and Design by Other Organizations A converged system is necessarily open ended. It will be necessary to add features to meet new customer needs and to remain competitive. A converged system has to interoperate gracefully with other vendors' systems. This provides specific problems for continued development. When a change is required: •
original designers will not necessarily be available to explain the assumptions that went into their design (if indeed they are still with the company).
•
new designers must be able to understand the operation of the system in order to propose modifications.
•
designers must be able to perform a change impact analysis to ensure that their proposed changes will not destabilize other parts of the system.
•
designers must be able to specify the operation of the system so that it can interoperate with other vendor’s equipment whose operation will likely only be known in part.
4.2.2 Service Maintenance In converged systems, the feature interaction problem is concerned with the coordination of applications. There is the need for a set of coordination methods for maintenance and diagnosis of cooperating applications. In previous systems, the application was generated as a whole. It was possible to construct a maintenance system that had intimate knowledge of the overall service architecture. With converged systems, applications will be constructed at run time from network based services. A maintenance system that
requires knowledge of the overall system will not be possible. As the applications of the system are constructed, the maintenance system must also be constructed. Since the applications know their goals, only they can maintain themselves [28]. Maintenance mechanisms for such services must be able to detect and cope with failure characteristics such as: •
failure of a an application due to an internal fault
•
failure of an application due to the failure of another application
•
failure due to an unexpected correlation of service requests
•
failure at the semantic level
•
failure of a distant application
•
failure on day one
4.2.2.1 Failure of Application Due to Some Internal Fault Applications cooperate with other applications to create a service. An application may fail, not because of problems in coordination with other applications, but because of an internal fault. Mechanisms must be provided to allow an application to identify and localize such faults.
4.2.2.2 Failure of Agent Due to Failure of Another Agent Since applications can cooperate with other applications to create their service, an application may fail due to the failure of another application on which it relies. Mechanisms must be provided to allow an agent to identify that a failure is external to itself and with the cooperation of other applications to localize one or more applications responsible for the failure.
4.2.2.3 Unexpected Correlation of Service Requests Applications cooperate by sharing their capacity among several other applications. This sharing is based on some model of the service capacity required for each application. Service capacity models are based on statistical assumptions. If these assumptions fail, agents supplying service may be overwhelmed by a number of simultaneous requests.
4.2.2.4 Failure At Semantic Level Two applications can negotiate an agreement to work together. However this negotiation may be based on a faulty assumption. An application may be working properly according to its own view of the world. However it may be causing the failure of another application because of conflicting assumptions about the semantics of the agreement. A clear example is the case of an application that can provide long distance connections. However if unknown to it these connections are suitable only for voice and not for data, it would cause the failure of an application that attempts to set up a data call. Only the data application would detect a failure. The long distance application would believe that it was functioning normally.
4.2.2.5 Failure in Distant Application Many applications may cooperate to provide a service. A failure may be noticed in an application that has no direct and perhaps only a distant indirect connection to the failing application. The mechanisms used to localize a failing application must be able to handle such lengthy indirect connections.
4.2.2.6 Failure on Day One Mission critical and other vital services require that any diagnostic mechanism be adequate on day one, or more specifically, during the first moments of service. Solutions that require extended periods of learning will not be adequate to handle this problem.
5. Agent Systems It is our opinion that agent technology offers the most promising solutions for the many requirements listed above. In traditional systems (functional and OO), software must behave in a predictable manner so that it can be modeled. However, as systems become large and complex, they grow to be difficult to understand, maintain and modify. As systems become more dynamic, their temporal characteristics become more obscure, making understanding and correlating their overall behavior very difficult and time consuming [17, 9,10,11,12,13,14,15]. In agent based approaches, the overall problem is partitioned into a number of smaller, simpler components, which are easier to develop, maintain and extend. This differs from the traditional divide and conquer methodology of object systems. The components derived are able to interact in a flexible, context dependent manner rather than through a set of fixed and predetermined interfaces. Agent based solutions provide a natural means of modeling complex real world problems. Real world entities and their interactions can be mapped onto agents with their own resources and expertise that can interact with other agents to accomplish their tasks. Software that performs organizational functions has to evolve to keep up with changing business needs and adapt to the changing needs of the enterprise and users. Traditionally this has been difficult. Agent design is effective in this situation since agents can be used to create a meta-level of interaction whose purpose is to manage applications and their interactions.
5.1 MANA (Multi Agent Networking Architecture) 5.1.1 General Characteristics of MANA The architecture [1,2,3,4,5] of next generation business communications system must take into account: • the criteria for a successful business, • the needs of a development team, • the general requirements of an application.
To this end, an agent architecture named MANA has been created. MANA provides a network of agents cooperating within an agency framework. Agents allow for standardization of a system architecture and its components. With this, new resources and services can be easily added. MANA agents have a common internal architecture with which to describe and process their particular functionality. All agents have similar characteristics, for example: • standard communication mechanisms • standard architectural components • standard fit within an agency framework • standard diagnostic techniques • standard resource allocation mechanisms • standard representation of tasks
5.1.2 General Description of MANA MANA is not an application in itself; it is a framework that allows for the creation of a network of agents, representing existing software and hardware, prescribed by an overall application. It is a common architecture describing how agents collaborate and communicate with each other and external interfaces. It provides the Application Design Tool (ADT) which describes applications to this framework. MANA provides a dynamic transformation entity that analyzes these descriptions and, by negotiation, provides the resources necessary for the required level of service to each agent. During run time each MANA agent dynamically monitors its own success and the success of the agents it is connected with, in fulfilling the ADT defined requirements. MANA dynamically detects deficiencies in both hardware and software and shifts resources to maintain the required level of service. MANA is based on the information processing model of organizational design [10 (especially) 8,9,11,12,13,14,15]. This is a well-established theory that has been successfully used to design organizational management for many years. This assures that MANA will be able to cope with the real world problems of an enterprise. MANA extends this theory to the problem of software system creation and management. MANA’s background in organizational theory opens the possibility of being able to guide the ADT design process, to assess the quality of the design and to make recommendations for its improvement.
5.1.3 MANA Mechanisms to Generate and Perform Services A system or enterprise has at its base, a set of goals and a set of resources (human and machine) with which to achieve these goals. MANA is an architecture that can describe and automate the joining of these resources into a configuration that will match the system goals to the capabilities of the resources. This is done by analyzing the goals and requirements using several levels of abstraction.
MANA along with its service providing agents, provides a jurisdictional hierarchy of management agents [1,2,3,4,5]. The jurisdictional hierarchy provides for the fair sharing of resources and customization of services. This will be essential for the next generation of communications services. The jurisdictional hierarchy is a management hierarchy whose role is to: • guide an agent in finding another agent which can supply a required service • act to resolve conflicts among lower level agents over conflicts over scarce resources • assess the current situation and guide lower level agent to select strategies which can overcome temporary problems such as overload • provide policies to lower level agents on how to deal with requests from agents outside of the direct hierarchy (this concerns security and classes of service and restriction --who cannot call whom -- among other things)
5.1.3.1 Agent Types Along with jurisdiction, there are four levels of agent abstraction; each represented by an agent type: functional group, abstract device, resource group, and resource type. The overall goals of the system are divided into smaller goals and distributed among functional group agents. Each of these agents will be responsible for a portion of the overall goal of the system. The achievement of the system goal will result from the cooperation among these functional group agents. A functional group agent’s goals will be captured as a set of services that can be used to make up a workflow. Each service will consist of a linked group of tasks provided by abstract devices and resources. An abstract device can be considered to be a complex resource that has been tailored to the idiosyncratic needs of the system. It is created by grouping together hardware and software and other abstract devices. Functional A resource group is created by grouping multiple similar Re-usability Abstract resources together. The Actors Devices resource group will create a common ontology for the Resource member resources or, in other words, a common API. Finally a resource agent Abstract Devices Business Specific Devices Technology represents the enterprise Dependency resources that can be any device that can be given an API including human beings (where the User Interface is the driver).
System
Each level of abstraction Behavior represents an ontology or self-contained domain. Functions Design effort can be encapsulated within each Abstract layer of abstraction since Devices each is small enough to be captured and reasoned Resources about. The goals and capabilities of the system can be captured as a set of Devices declarations within each layer. The linking of resource capability and system goals is done by the mapping of concepts between adjoining levels that constitutes a mapping of ontologies.
5.1.3.2 ADT -- Agent Design Tool ADT captures the definition of the system capabilities as well as its resources and service requirements at the enterprise level. ADT acts as the mediator between the system, the system designer and the operator. It consists of a Data Entry portion, an Information Model, and a Feedback Monitor. It provides the means by which the designer can enter the system declarations and observe their effect on system operation through the monitors. The system designer declares the resources that are needed by applications to meet a required level of service. These resources are allocated by MANA operation. Because of this, MANA must be provided with information on the importance of any service or resource to an application and the importance of any application to the system as a whole. This is done through ADT. In the event of insufficient resources due to failure or any other reason, MANA will use the importance information for the reallocation of resources among applications. The Information Model is the repository of facts and rules about applications. These are commonly referred to as system policies, and include the declarations of the services and resources of the system. It also contains the information that has been gathered in operation to improve the efficiency of the system. These policies are classified into two fundamental types: static and dynamic. Static policies are the declarations used to prescribe system structure and operation. These are entered into the Information Model by the Data Entry portion of ADT. These policies include: •
the basic social structure of the system -- i.e., the relations that create the reporting and responsibility structure among the agents,
•
the goals which the agents are motivated to fulfill for the system,
•
the capabilities which the agents are authorized to supply to the system,
•
the importance of a specified goal to the operation of the system,
•
the importance of a specified goal to the operation of a specified service.
Dynamic policy information is gathered in the course of operation. This is used by internal mechanisms to make the system more efficient. Many sorts of dynamic policies are collected. In operation, the agency uses feedback loops which continuously maintain and improve its efficiency. The agents also gather information on their own and collaborating agents' reliability and capabilities. This information is passed back to the Information Model. The returning information can trigger operations to redefine agents and reallocate resources. These operations correct failures and allow the system to meet the requirements of the defined service better. This information can also be passed back to the service designer for system tuning. Initial declarations by the service designer are necessarily estimates. Precise system loading estimates can only be obtained through a detailed analysis of the interactions of all applications running on the system. The feedback learning mechanisms can refine the initial estimates of the designer. These refinements both improve the operation of the current system and can be used to make better estimates for future designs.
6. Process In addition to the agent framework, it was necessary to establish a process for creating applications. A designer creates an application in ADT by defining its requirements and mapping them onto the necessary agents and resources. A traditional process (Unified Method [23]) is used to define the application in terms of the agent framework requirements and map them into an implementation. 6.1 Agent Mapping Details Others [19,20] have been working on the problem of agent oriented programming of large complex systems. Our work supports their ideas and extends them. The system uses basic object techniques to discover requirements as in [23], but the large coarse grained nature of agents requires that functional techniques be used to identify candidate agents. Briefly, the process steps are: •
Capture application requirements in use cases.
•
Analyze the use cases to find actors, and control objects. Actors are candidates to become functional agents. Control objects are candidates to become scripts within the functional agents [23,19,3].
•
Produce an entity relationship diagram for the system. An added twist is that the data is also analyzed from the point of view of which functional agent would have responsibility for it [19,20].
•
Analyze use cases to find the resources necessary to carry out the required functionality. These become candidates for resource agents.
•
Set up a proposed agent diagram. The corresponding data responsibilities and use case scenarios are run through them by hand. As this is done, the abstract devices begin to emerge. These are devices that ‘abstract’ the functionality away from the functional agents. For example, in a communication application, an abstract device emerged for handling PC desktops. This device abstracted the control of the phone, windows on the screen and voice switch connections. This abstract device can be used in the definition of a functional agent to defer the commitment to any specific way of handling a desktop until specification or even run time. This ability to defer commitment allows for both service and technology transparency. [1,2,3,4,5]
•
Enter the agency definition into ADT when satisfied and begin to test and redefine the application iteratively.
7. Conclusion 7.1 MANAs Addressing of Issues The following sections will be very brief indications of how MANA addresses the issues discussed here. Since MANA is not the main point of this paper (the issues are), the explanations will be very brief and the reader is asked to review the MANA references for more detailed descriptions.
7.1.1 Business Requirements 7.1.1.1 Time to Market As the number of resource agents and abstract device agents grow, the MANA architecture provides a library on which to draw from for the creation of new products. This will decrease the time needed to create new products, therefore enabling quicker time to market.
7.1.1.2 Quality MANA applications are created by selecting and combining well-tested reusable components from a library. Therefore, overall quality of the generated application is easier to ensure.
7.1.1.3 Cost As technology develops and new and cheaper solutions are found, they can be easily added into the system without affecting the overall application. As well, as the component library grows, the total development cost of the product is decreased.
7.1.1.4 Customer Expectations and Specifications The agent framework is inherently customizable, therefore basic systems can be tailored to a particular customer’s needs and expectations.
7.1.2 Developmental Requirements 7.1.2.1 Platform MANA provides a re-usable and flexible platform for the creation of products.
7.1.2.2 Well Defined Layers The system is broken into well-defined layers of abstraction represented by the agent types. This allows for designer specialization, since design can be constrained to within the specifications of the ontology of an agent type. Specialization leads to increased skill, improved quality and therefore reduced cost.
7.1.2.3 Tools ADT is a tool that facilitates system creation, and hides agent complexities. It allows for quick turn-around of ideas, so that product concepts can be tried early. A standard OS independent language, with a rich tool set is used for the coding of MANA. Distribution is provided by an off-the-shelf CORBA middleware layer. Rational Rose is used for capturing use-cases and design, for both the agent framework and the application. Our work is extending Rose to include our agent methodology and diagrams.
7.1.2.4 Process The Unified Method [23] has been appended with an agent level process in MANA. This has been used for the definition of the framework. With this, MANA provides a welldefined process for the creation of applications.
7.1.2.5 Metrics Off-the-shelf packages are used to collect metrics for operation of the framework and defined applications. The Simon Homer [24] method is used to determine the metrics for both the agent framework and the products.
7.1.3 Framework Level Requirements 7.1.3.1 Responsiveness Responsiveness has been addressed in the framework by providing mechanisms that can reduce the overhead required for agent operation. Additionally, diagnostic mechanisms have been provided which can determine if the system is meeting the responsiveness requirements entered. The system distributes resources to where they can most readily be used by end users, so that delay is minimized. As well, ever increasing backbone bandwidth and processor speed will alleviate this requirement.
7.1.3.2 Appropriate Reliability The ability to define abstract devices and resource groups allows the appropriate definition of redundancy. It provides methods for ranking agents on their importance to the system as a whole. This information can be used in the negotiation and renegotiation process. The most efficient assignment of resources to the most appropriate agents can be ensured in the event of a failure of any kind. [18,16,10]
7.1.3.3 Conversational The agents have inherently peer-to-peer relationships. The framework provides the agents with the means of determining the capabilities and deficiencies of the other party. The agents can automatically adapt and reallocate resources to attempt to overcome these deficiencies.
7.1.3.4 Evolvable The framework is both service transparent and technology transparent by design. Since the functional group level is separated from the resource level, new technology can be added without affecting the services, and new services can be added, or old services changed, without affecting the resources.
7.1.3.5 Location Transparent Resources can be located anywhere on the network, transparently to the application. As well, applications provide their services to any other agent anywhere on the network. This location transparency also applies to the people using the system, since they are considered as any other resource. People have agents representing them within the system. With this, they can ‘log in’ anywhere on the system and have their agent provide them with the services they expect.
7.1.3.6 Self-Maintaining The feedback loops provided in the basic agent framework provide a means for the agents to realize when a service is not functioning properly. The agents can attempt to automatically reallocate themselves to overcome a problem and report it to the appropriate place. Learning engines can be used to detect problems in an agent generated application. With this capability, they can be used by agents to facilitate the provision of help to users who have customized the system to their own unique needs. No vendor supplied help is suitable in this case.
7.1.3.7 Self-Configuring ADT is the tool used to make declarations to the system that form the basis for negotiation among agents to create a manageable system. These declarations include a ranking of agents about their importance [18,1,3]. Ranking provides adequate resources to agents and allows reallocation to alleviate failure.
7.1.3.8 Evanescent Agents can be created and programmed as needed, and just as easily destroyed when they have fulfilled their purpose. The negotiation process will allocate and reallocate resources to agents depending on the importance of their application.
7.1.3.9 Unattended As resources fail, MANA has provided a mechanism for reconfiguring and adjusting the use of the remaining resources. It also provides a means within each agent to report any failures to a higher jurisdictional agent that represents the maintainer of the system.
7.1.3.10 Mobile Having agents representing users and groups of users as well as having a location independent system means that people can have access to their own data at any time. They can re-synchronize at any time just by ‘logging in’ to the system. Wireless connections are handled since mobility management software can be treated as a resource, and is made part of the abstract device that defines the user's desktop.
7.1.4 Application Level Requirements 7.1.4.1 Service Creation and Coordination The feature interaction problem is addressed by: • mechanisms internal to the agent that identify conflicting goals and resolve the interaction as directed by context and agent preferences. • competition for resources being handled at two time levels. The agents provide internal mechanisms for the selection of suitable resources at run time to overcome environmental contingencies. As well, a system of economic rationality is provided by the jurisdictional hierarchy at system initialization. This rationality guides the agents to make choices with knowledge of overall system requirements. • localizing the effect of changing assumptions on services to the agents concerned, and making them explicit. When a new assumption is to be brought in, only the agents affected must be modified. This makes the system more stable and resilient.
7.1.4.2 Service Maintenance To handle identified diagnostic problems, mechanisms have been provided which observe the operation of the system on three different time scales. The quickest time scale is used to assist in the real time allocation of resources. Resources that fail their missions are less likely to be picked for the same job by the same agent in the future. The second time scale looks at a series of agents working together to perform a service. This mechanism will find semantic and distant failures. The third time scale looks for the unexpected correlation in requests for resources between services. This mechanism can be used to adjust the algorithm that determines how a specific resource can be shared.
8. Acknowledgments This has been a team effort. We wish to thank Mitel Corporation for its support.. We would like to thank Eliana Peres for her contributions to the editing of this paper. We would also like to thank John Lord, Ed Bijman, Helene St. Amour, Hector Guestrin, Gabriella Alexiu, Eddie Deogrades, Nancy Poon, Craig Frisch, Don Wade, Dave Jarvis, Richard Deadman, Prof. Nick Dawes, Prof. Ray Buhr, Mohamed Elammari and Mark Van Gulik who contributed to this work and Marie Paul, our company librarian, for finding references.
9. Selected References 1. ABU-HAKIMA, S., FERGUSON, I., STONELAKE, N., BIJMAN, E., DEADMAN, R., A Help Desk Application for Sharing Resources across High Speed Networks using a Multi-Agent Network Architecture, ICJAI Workshop on DIN, 1995. 2. GRAY,T.,PERES,E.,PINARD,D.,ABU HAKIMA,S., DIAZ, A., FERGUSON,I., A Multi-Agent Architecture for Enterprise Applications, Business Process Reengineering Workshop Notes AAAI-94. 3. GRAY,T., WEISS,M., DIAZ,A.., A Middleware for Developing Distributed Multimedia Applications, Proceedings of the ISCA International Conference on Parallel and Distributed Computing, Orlando 1995. 4. WEISS,M.,GRAY,T.,DIAZ,A., An Agent Based Distributed Multimedia Service Environment, International Conference on Tools with AI, Herndon VA. 1995. 5. WEISS,M.,GRAY,T.,DIAZ,A.,A Service Environment for Distributed Multimedia Applications, Workshop of Distributed Information Networks, IJCAI 95,Montreal 6. FERRARI, D., Client Requirements for Real-Time Communication Services, IEEE Communications Magazine, 65-72, November 1990. 7. HUHNS,M.,N., MURINDAR,P.S., Automating Workflows for Service Provisioning: Integrating AI and Database Technologies, IEEE ,1994. 8. FIKES, R.E., A Commitment-based Framework for Describing Informal Cooperative Work, Cognitive Science, 331-347, 1982. 9. FOX, MARK, An Organizational View of Distributed Systems, IEEE Transactions on Systems, Man, and Cybernetics January 1981. 10. GALBRAITH,J.R., Organization Design, Addison Wesley, 1977. 11. JIN,Y., LEVITT,R., i-Agents: Modeling Organizational Problem Solving in MultiAgent Teams, Intelligent Systems in Accounting, Finance and Management, Vol. 2 247-270, 1993. 12. MOFFETT, J.D,SLOMAN, M.S., The Representation of Policies as System Objects, Conf. OCS 1991. 13. MOFFETT, J, SLOMAN, M., TWIDLE, K., Specifying Discretionary Access Control Policy for Distributed Systems, Computer Communications, Vol. 13 no 9, November 1990. 14. MOFFETT, J.D., AND SLOMAN, M.S., Delegation of Authority, Integrated Network Management II, I. Krishnan and W. Zimmer (Eds), Elsevier Science Publishers B.V. (North-Holland), IFIP, 1991.
15. PATTISON, H.E., CORKILL, D.D., LESSER, V.R., Instantiating Descriptions of Organizational Structures, Huhns, M., Distributed Artificial Intelligence, Pitman, 1987. 16. REINHARDT, A., The Network with Smarts, BYTE, 51-64, October 1994. 17. VELTHUIJSEN, H., Distributed Artificial Intelligence for Runtime Feature Interaction Resolution, Computer, 48-55, August 1993. 18. WELLMAN D., A Microeconmic Approach to Load Balancing. 19. KENDALL, E.,A Methodology for Developing Agent Based Systems for Enterprise Integration, http://www.cse.rmit.edu.au/~rdesk/. 20. RAO,A.GEORGEFF,M.BDI Agents from Theory to Practice, Technical Note 56, AAII, April 1995. 21. HUHNS,M.,N., MURINDAR,P.S. Automating Workflows for Service Provisioning : Integrating AI and Database Technologies, IEEE ,1994. 22. DRUCKER,P.F., Post Capitalist Society, Harper Business, 1993. 23. BOOCH, GRADY, Managing the Object-Oriented Project, Addison Wesley,1995. 24. HOMER, S, Metrics and Object Oriented Development Process, Tutorial Notes, OOPSLA ’95 25. CHAPMAN et al, Overall Concepts and Principles of TINA, TINA Consortium, 331 Newman Springs Road, Red Bank N.J.,07701,USA,Feb 95 26. RIZZO, M.,UTTING,I.A., A Negotiating Agents Module for the Provision of Flexible Telephony Services, ISADS97 (in print) 27. SCACCHI,W, Modeling, Integrating, and Enacting Complex Organizational Processes: Approach and Experience, http://lsdis.cs.uga.edu/actvities/NSFworkflow/scaachi.html 28. FREEN, R., HAW, C., McLEOD, J., TOTTI, G., An Architecture Designed to Endure - The Mitel SX2000, Sixth International Conference on Software Engineering for Telecommunication Switching Systems (Conf. Publ. No.259) p.24-30
