Characterizing the Agent Grid

Abstract

Contents

• The Problem
• Examples of Grids
• General grid properties
• The basic idea of the CoABS agent grid
• Viewing the Agent grid from different perspecitives
• Viewing agent technology as a collection of mechanisms
• Viewing the grid as a composition or federation of agent systems
• Viewing grids as organizational units
• Others views of the CoABS grid
• Open issues about the coABS agent grid
• Other things to cover
• Conclusions
• Acknowledgements
• References

The problem

But even after the meeting most people had only a foggy notion of the grid's role in agent architectures and few knew much about services the grid might provide.  So far, there have been only a few attempts that we know of to characterize the grid [3, 4, 7, 8].

This paper is one more attempt.  Its goal is to help characterize the coABS grid.  Its approach is to look at the grid from several views to see what we might be able to learn.  Benefits of increasing our understanding of the grid are:

• increased understanding of agent system architectures and
• acceleration in making agent system capabilities pervasive.

Examples of grids

• Physical grids.  Generally, physical grids constitutes a physical network of things that can be used together (note that the connections are just as important as the things connected).
• Power Grid - Many might view the "electical power grid" as the preeminent grid.  If viewed globally, it uses wires connected in some physical topology to carry electricity across the world delivering power to enable a rich variety of applications that need and will pay for the power received.  At a slightly lower level of abstraction it is connected physically by wires and also by a collection of standards to provide a uniform quality of service, though standards and QoS vary in different locales.  Looking closer, there can be local grids that are disconnected from the power companies, run off of batteries and generators.  Also, power company grids can federate to provide power for surge times to neighbors.  The grid itself might narrowly be viewed as wires (more abstractly, a bus architecture or power server) or more broadly as not only providing an infrastructure for the applications but requiring its own implementation infrastructure (generators, linemen, billing, ...).  This grid has a notion of capacity, underload and overload, and market demand.
• Transportation Grid - Transportation grids carry vehicles or materiels (e.g., pipelines).  Examples are the national highway system, railroads, ships, planes.  Each of these can be viewed as a subgrid of the Transportation Grid distinguished by its own infrastructure.  The different grids have different properties (capacities, speeds, connection topologies).  But they federate so we can get goods by truck and plane from A to B.  Only some aspects of these grids federate though, not necessarily the ways of charging, roles of experts, ....  Mainly they interoperate (or federate) at bridge points. More specialized transportation grids may be enabled by other grids:  the Fed Ex grid might be viewed as superimposed on the transportation grid.  The transportation grid has an addressing scheme.  Much infrastructure is needed to enable and maintain the grids themselves - Detroit auto designers, oil imports, road maintenance crews.  The grid economy is a composite of many local economies:  taxes, tolls, vehicle purchases.  The capacity must meet the load for the grid to be economically viable.  While aspects of the grid may have decentralized government (many construction companies), some aspects are shared across large grids (traffic laws, railroad gauges, engineering principles).
• Information-bearing grids
• Digital grid, Internet, Email, WWW, distributed objects technology, distributed simulations - Digital connectivity via all these infrastructures depends on wires or wireless, tethered or not, low or high bandwidth, and 100s of fast changing standards.  Iridium satellites enable connectivity from the top of Everest to the middle of the Sahara Desert.  Logical grids can operate on top of physical ones to deliver email to Everest.  Some grid infrastructure is on everyone's desktop and enables rapid sharing of "documents" (e.g., Email with attachments, MS Office, Web browsers).  Much software can be purchased and downloaded via the web; some is self-installing (applets, viruses).  While object technology is pervasive, distributed object middleware technology is still used mainly to build local grids.  Neither is distributed simulation technology pervasive though confederations of simulations can span thousands of distributed users.  Some projects have discussed a national or global information infrastructure [10].  Note that "web", "grid", and "network" convey pretty much the same idea.
• Meta Computing Grid - The meta computing grid community [1] is focused on the computational grid, the view of the network as computer.  The basic abstraction is a computer that implements a computation - the main thing shared across nodes is computation.  This community views computers and networks as a mega computer tasked to do computation.  Their view covers resource description, system management, and load balancing  -- resources aggregate to a larger whole.  This contrasts to the basic abstraction in much agent work of a community of people and agents.
• ABIS Information Grid - The Advanced Battlespace Information System (ABIS) Task Force [2] describes a global Information Grid meant to support C4ISR.  The DARPA I*3, BADD and AICE programs describe information architectures for connecting thousands of data sources to thousands of queriers across global networks.  New infrastructure technologies needed include wrappers, caching, push-pull, channels, etc.  See slide 14 in [4]. MCC InfoSleuth is an example of an agent-based information grid.
• Geo Grid - Paper and digital maps as well as GPS provide infrastructure for a geo grid, which plays not only off the pervasive connected property of grids but also the view of grids as cross hatching coordinate systems.  The GIS community (including National Image and Mapping Agency (NIMA)) view such a grid as an underpinning for command and control.  Truely detailed maps provide detailed views of areas ranging from building layouts to the earth.  Domains that need geo grids include command and control, agriculture, real estate, etc.  In each of these, objects of interest are indexed relative to the backplane (grid) that the mapping system provides.
• Supply Chain Grid and Virtual Enterprises - While these are not referred to as grids, they could be viewed as the federation of a collection of organizations from the point of view of optimizing the production and delivery of goods and services so the community of organizations acts like one large virtual organization or logistics grid.  Insuring survivability and profit for each link in the chain could be done by an outside agency, by agreements and contracts, or by a market economy.
• Software Grid -  The observation is that we cannot today connect software together as easily as we do hardware components into the electrical grid.  If integration = power, we are not harvesting the ability to connect Meeting Maker, a weather service, and sendmail to build the travel agent.  COTS software is hard to glue together and doing so does not guarantee systemic properties.  Top-down architectures require too much consensus and fail to adapt to unforeseen requirements.  If software were self-describing, self-identifying, and self-licensing and came with performance guarantees, and if we could address the problem of a common semantics (via ontologies, ...), then would dynamic and automated integration be possible on an Internet-sized scale?  This is the vision of a software grid.
• Semantic Grid - This is like the software grid, except the term focuses on sharing meaning, e.g., semantic interoperability.  Ontologies and shared class libraries are one way to do this.
• coABS Agent Grid - the coABS program posits a grid that operates at a logical level to enable (and generalize) the latter eight kinds of grids listed above.  The assumption is that "agent technology" (viewed broadly) provides (or is) the glueware to enable these kinds of interactions:  component interaction standards, wrappers, trader/matchmakers, agent communication languages, planners, schedulers, resource and policy management, coordination patterns, conversational patterns, etc.  In this view, agent technology is broadly defined to include mechanisms for late binding, reconfiguration, load balancing optimizations, achieving and maintaining systemic properties like survivability and scalability, and coordinating teams and organizations.  As in other examples, the agent grid is likely to depend on pervasive grids below it, e.g., the Web, object services, etc.  More narrowly, we might claim that we have many individual agent systems (and many notions of agent) today consisting of a collection of agents and an agent biosphere (shared support services and resources), and that the grid is something that helps us connect these together so they will interoperate, possibly allowing agents to leave one system/biosphere and go to another, or leave one grid and go to another.  It might be a federation of agent systems which allows some sharing and interoperation (but how much) or a meta agent system that generalizes agent systems or something else.  Determining what is the point of this paper.
• Borg Collective - in Star Trek, Borgs share knowledge so that what one learns, others know.  It also addresses multiprocessing, tasking, survivability, adaptability, etc.
• Everything is alive - Where early man may have viewed a world where everything was alive and had a spirit, it might be that LEGO-like (micro) wrapper agent technology might within our lifetime create a world where many physical objects use standard sensors, actuators, communication, and knowledge sharing to communicate with each other. Toys that interact with each other as well as with humans are just appearing.  Other examples:  guns with voice locks, logistical items that know their own identity and what kind of larger whole they are packed into and that can log themselves, cheap micro-satellites that cooperate, smart land mines that coordinate with each other and sensors, objects that remember their maintenance history, trees that tell the sprinkler to water them, etc.  "Everything" extends to software components as well, so that wrappers can wrap information sources, new services can be added to running systems, resources can be added or taken away and systems will adapt, grow, evolve, and survive.
• Social and Cultural Grid *** - The following "grids" exist to hold our society together:  physical laws, families, tribes, religion, rules, laws, and law enforcement, unions, armies, government, common language, money system, banking, writing system, printing systems, home addresses, libraries, mail system, radio, TV, fast food, desktop personal computers, VCR standards, tethered and cell phones, HDTV standards.  For each, there was a time before that property was pervasive, there are local differences in how the grid operates, there are shared standards, there are conversion factors, there are QoS considerations.  Some variations we are used to (many fonts), others we are not (writing upside down).  Some enabled applications are hugely expensive (at present) like the movie industry but as grid cost-ratios change, new applications are enabled (video attachments).  These grids exist simultaneously (there is no overarching grid), each involves some notion of something being shared and a support infrastructure.  Some grids are decentralized (money) and depend on shared (cultural) assumptions as well as indexes of supply and demand.
*** These things aren't very often referred to as "grids", but are certainly sometimes referred to as cultural infrastructure or "networks" (e.g., you "network" among your acquaintences), which makes the earlier analogy between grid and network helpful.  Perhaps a most important point is that there is not just one grid but potentially many that interact.

General grid properties

*** (FM) What we ultimately want is not just properties or characteristics that we can associate with grids in the abstract, but rather properties that we want to associate with grids that distinguish them from other software concepts we are already familiar with (e.g., agent architectures, the Internet, the OMA). If there aren't any such characteristics, what's the point of introducing a new term?  The writeup in the original read-ahead material actually suggested some characteristics like that (e.g., One could see that one couldn't do those things with an unenhanced OMA, and had an idea of the additional things that would have to be added to the OMA to do them).

• Grids can be viewed as a unit.  We send email via the Internet or goods from point A to B via a transportation grid without having to say just how.
• Grids enable the integration or sharing of physical or logical things.  Physical examples are electricity, vehicles, water.  Logical examples include shared language, shared semantics and values, voice communications, adaptive connectivity, "knowledge".  The thing being shared may or may not be intrinsically sharable, but it's made sharable by virtue of the grid allowing it to be moved. e.g., the water moved by a water grid to me isn't sharable in the sense that it can be used by more than one person (if I drink it, you can't), but because the grid connects people to bodies of water, and enables it to be moved, the totality of water is sharable. Another example: a geogrid doesn't provide anything that's physical or logical that is sharable in any obvious sense. It does, however, enable the integration of things (in the sense that it locates them with respect to each other for various purposes).
• The something grids carry include resources, goods, services, and capabilities.  This is the main purpose of grids.
• Grid users are those that benefit from or are enabled by the grid.  Grid providers are those that participate to provide the grid.  Grid infrastructure providers are those that produce elements that are needed in grid composition or maintenance.
• New kinds of grids can enable new kinds of applications.  That is why we build them, to serve a purpose, to make something easier or cheaper.
• There can be local and global grids.  Generally, there may be a hierarchy of grids (not just global and local).  Global grids are usual constructed from local grids (sometimes recursively) by maintaining some invariant characteristic properties.  This is a system-of-systems fractal architecture view where the larger grid has the same (invariant) properties as smaller grids from which it is composed.  (e.g. it is a C4ISR system whether it is evacuating 20 people in a NEO or governing a major conflict.)
• Local grids can federate (up to a point) though not every aspect might federate
• Local grids can be operated disconnected from the global grid (unless there is a dependency relation between the grids, as in the UPS to transportation grid example).
• Local grids can provide heterogeneous enclaves where different standards, policies, or scaling properties hold.  For example, goods can be transported by truck or train.  Homogeneous/heterogeneous grids may interoperate without higher level grids to provide/manage interaction - examples include postal services from various countries, library systems, telephone systems -- how they interoperate is also useful to understand.
• Global grids provide what they provide pervasively.  The grid infrastructure must be widely deployed and available to support the widely shared capability.
• There may be adapters or conversion factors or bridges to map across heterogeneity boundaries.  Grids are only interoperable with respect to some of their properties (their characteristic properties, the invariants that are maintained when grids are federated).  The general rules may be invariant at the whole-grid level of abstration but may specialize at the local grid level.
• The connections within a grid can be physical or logical.  Some physical connections have a specific topology (e.g., wire routing); others have rules (e.g., planes travel at certain elevations, avoid storms, enter and leave airports according to rules, but do not necessarily have fixed roads in the sky; wireless communication is similar in not requiring a tethered, wire-based connectivity).
• (Secondary) grids can be enabled (implemented) on top of (primary) grids.  A supply chain grid can be implemented using Web connectivity (and/or by email, fax, snail mail, ...).  It is logically independent of the specific implementation.  But a mapping is needed to each implementation and bridges/adapters between them.
• The use of grid and grid services sometimes costs something (electricity bill).  The costs are needed to pay for maintaining the infrastructure.  Raising or lowering the cost can change "the way we do business" (e.g., the oil embargo in the 1970s raised the of most goods and services).
• Small and large grids might have a pay-once payment scheme (e.g., as when you buy a car or a software program) or a pay-for-use payment scheme (electicity bill, tolls) or other kinds of payment schemes (taxes, auctions).  The payments compensate grid maintainers.
• Grid government or management is needed to coordinate and control grids and subgrids.  The government consists of rules, policies, and mechanisms.  In some cases, rules cannot be broken (physical laws) but in other cases they are voluntarily followed or penalties (exceptions) exist to require governed entities to obey.  These help insure stability.
• *** (VV) I view the above point as a very important aspect of a grid (more so than a number of other points). To me an interesting grid necessarily implies autonomous behavior of units of the grid , decentralized control and democratic ..... Without these characteristics, there is no emergent behavior. Decentralization of control and emergent behavior is  to me the distinguishing aspect of the grid. A centralized architecture is an evolutionary imporvement on  componentware.  Emergent being defined in as "stable macroscopic patterns arising from the local interaction of agents".  Growing Artificial Societies [9] is a worthwhile reference (and a book I have, in case you want to borrow it).  Some taxonomy of emergent.vs.non-emergent system properties (and things in between) would be useful. A collective can have an emergent property that are entirely missing from the components. Take the "school of fish" example - assume each fish can only move in four directions (n-s-e-w). Yet the collective school of fish can move in an infinite number of directions. Properties may be non-emergent in a variety of ways. A system can have better availability than any of its constituents. On the other hand, security is based on the "weakest link" principle. One insecure component can compromise your entire system.
• Grid government might comes in many forms (central authority, de-centralized, democratic, etc.).
• Government (and the grid) has boundaries -- its rules only apply to locales of governed entities, not all entities.  Specialized rules may apply within subgrids which may have their own governments.  Different patterns may result from different control arrangements:  organizational hierarchies, federal-state-local or joint chiefs-service-allies, partnerships, matrix management, etc.  Governments also differ in the scopes of what things about the governed entities are controlled by the government. e.g., the governments of the US and China differ not only in terms of what people and territory are within the scopes of those governments, but also in terms of what aspects of the lives of the people are controlled. The same may be true of grids.
• Many governments define roles:  husband-wife, boss-employee, with different responsiblities.  The same entites might take on different roles when acting as members of different grids (both a wife and a boss).  So entity modeling must be extended to reflect dynamic property based typing.
• Not all grids are equal in resources or services offered.
• Grids often have evolvable, adaptable, economic aspects - they grow to cover needs, evolve over time, small grid suppliers consolidate or find niches, the fittest survive or regulation insures survival for the greater good.  This means that grids can shrink or disappear (e.g., Roman roads, the trolley system).
• Grids may have system qualities:  adaptable, scalable, secure, survivable, reliable, evolvable, etc.  Not all grids might provide all these.  Some grids might inherit these from surrounding grids. Eg a security unaware application is secure if it runs fully within a secure environment.  Firewalls create this kind of barrier.  Encapsulation boundaries around grids can also make grids opaque so it can be difficult to assure end-to-end properties if we cannot reason about all intermediate steps in a process.  To get these systemic properties, we need some guarantees or visibility into grid operations.  Also, you may build a grid with specific properties using a grid that doesn't have them (e.g., as you can build a reliable system from unreliable parts using redundancy).

• grids have a purpose: to provide or share some resource, goods, services or capabilities.  They facilitate communications and interaction via a fabric which weaves the bonds between its constituency.
• grids have end-users that depend on the invariants of the grid.  Grids may provide QoS or systemic property guarantees.
• grids have boundaries, and may be small or large
• grids have government consisting of rules and policies
• grids have an implementation infrastructure.  They may be dependent on one or a federation of other grids.
• grids have an economy
• grids evolve, adapt, scale up or down, survive, ...

• grids may be an abstraction layer (defined by emergent properties) rather than a concrete entity.
• are some grid governments inherently better than others?
• how can we accommodate heterogeneity in local grids and still guarantee systemic properties across grid federations

The idea of the CoABS agent grid

The notion of a grid is important with CoABS as one of the architectural constructs that might make a variety of C4ISR systems easier to build, scale, maintain, evolve, adapt, survive, ....  The presumption is that the Agent Grid is an enabler for many kinds of complex systems, including C4ISR systems.  These systems are characterized by:

• multi-year lifetimes and evolving and changing requirements
• more components than any group of designers can design or even understand
• design by groups that do not know about each other
• adaptable and scalable to large or small sizes
• systems management without explicitly monitoring all components all the time (there are too many components to do this)

• humans and agents connect to the grid anytime from anywhere and get the information and capability they need
• scale to millions of agents so agents are pervasive and information and computation is not restricted to machine or organization boundaries; if one agent goes down, another takes its place; add capability modularly; easier application connectivity
• enable teams led by humans and staffed by agents
• reduce the 60% of time in command and control systems spent manipulating the stovepipes; incrementally replace stovepipes
• connect up the $40B worth of equipment that currently only interoperates with one or two other components, permitting better knowledge sharing; another example is intelligence learned about a customer in TX is immediately available in CA; or similarly, a process improvement in factory 1 is broadcast immediately to factories 2..N
• agent-enable object and web applications to reconfigure as new data and function is added to the system
• intelligent automation - application connectivity where networks of agents self-organize at run time.
• the ability to rapidly configure and reorganize COTS components to create applications du jour.  Components come from a "software grid" and connect together easily by virtual of self-identifying, self-licensing, self-documenting, self-modifying components.
• the ability to scale, adapt, evolve collections of components to solve a variety of C4ISR problems, initially various NEO problems, eventually a range of major and minor warfighter and peacekeeping missions.
• a way to dynamically connect together heterogeneous agent systems that can interoperate
• the ability for agents to register with an agent system and draw on its resources and services and deal with additions and unavailability of services.  The ability for reassignment.
• agents that act for users and interact with them, wrap data sources, filter information, plan and execute tasks, and coordinate with other agents
• scaleable, evolvable, reliable, secure, survivable, pervasive, stable, ...
• global agent systems that are pervasive
• networked society where every software artifact, information source, and device is connected and running in parallel and can share/loan its capabilities and resources with/to other artifacts, sources, devices, etc. The business of grid participants being able to share or loan their stuff to others is a major "grid" characteristic (although we need to distinguish it from, e.g., OSAs).  It isn't strictly necessary for all grid participants to be connected or running all the time.

• Digitial Grid, Internet, Email, WWW, distributed objects technology, distributed simulations
• Meta Computing Grid
• ABIS Information Grid
• Geo Grid
• Supply Chain Grid and Virtual Enterprises
• Everything is alive
• Borg Collective
• Software Grid
• Semantic Grid
• coABS Agent Grid

*** (FM) I think "the agent grid", and this characterization into technology and application layers, as used here, is too imprecise. The CoABS grid use cases, for example, seem to suggest that in the CoABS context we're talking about both an "agent grid" as a technology grid (agents as providing "grid" services), and as an application grid (i.e., it's both a "grid provided by agents" and a "grid provided for agents"). Also, I don't see why it's clear that the agent grid is technology and the software grid is application. Why couldn't it just as easily be the other way around? I further think we're going to be mixing and matching stuff in terms of smaller units of granularity than whole "levels", and "levels" implies an architectural organization that may or may not be true.

• to understand what constitute the agent technology grid (abstraction layer)
• to understand how the agent technology grid complements related technology
• to demonstrate that higher level grids are enabled by the agent technology grid.

Viewing the Agent grid from different perspecitives

Viewing the grid as a collection of agent-related mechanisms

A partial list of agent-related mechanisms might include:

• trading, matchmaking, facilitating, advertising, negotiating, brokering, yellow pages [note: some of the terms above are redundant], constraints, rules, inference, planning, schedulers, control algorithms, ontologies, agent communication languages, agent system frameworks, conversational protocols, CIA model of untrusted agents, <what else>.  Note that, while these may be "agent-related", not all of them necessarily involve agents; e.g., trading and brokering don't need to involve agents.

• component and object distribution and mobility, messaging services, life cycle (start, stop, checkpoint), name service, event monitoring, leasing, compensation, catalog services, registry/repository, register, offer/accept/decline, publish, subscribe, security,  authenticate, encrypt, access control lists, firewall, transactions, persistence, query, profile (of metadata), data fusion, replication, groups, multicast, (scarce) resource mgmt, allocate, deallocate, monitor, local, global optimization, caching, pre-fetching, load balancing, performance monitoring, negotiation for resources, scheduling, time, geo-location, rules, versioning, configuration, property list, federation patterns, ... <what else>.  [To a reasonable extent, for architectural purposes, we can for now treat these services as black boxes.  Of course, if we want to implement real systems we need real instantiations of these services.]

• to insure that the agent mechanisms will interoperate with other useful non-agent mechanisms
• to insure that we do not just supply toolboxes with mechanisms (glue) in them, but also standard construction techniques for putting the parts together quickly

• The grid may then have the narrow purpose to be purely a registry mechanism (sense A2a) for tracking which agents, services, and resources are assigned to an agent system and monitoring key events associated with these.  Issues with this mechanistic grid include:  can agents exist and interoperate with others outside the grid; will one such grid support millions of agents, or are there many such grids; see other issues listed above.
• Or the grid may be the organizing framework itself into which all the agent and non-agent services and mechanisms plug (sense A2b - equivalent to sense B below).

• what new technologies and mechanisms can we identify and add to the agent technology list.  Can we more precisely define the ones we have already?  Can we get industry standards groups to adopt these specifications and make reference implementations available?  Can we influence COTS vendors to supply implementations?
• can we avoid reinventing non-agent technologies and mechanisms?  Can we stand on the shoulders and not the toes of so-called competing technologies, for instance,
• the meta computing grid and DARPA programs like Quorum define non-agent mechanisms for distributing computation and organizing resources.
• the distributed object community similarly provides ways of modeling and distributing applications and provides collections of middleware services.
• the distributed simulation community provides ways to federate collections of simulations with a shared transport, data model, and notion of time.
• what sort of (open) frameworks connect all the parts above (agent and non-agent) as well as future technologies?

Viewing the grid as a composition or federation of agent systems

This view opens the door to several issues:

• There is a tradeoff between autonomy and (logically) centralized control (or at least control external to an agent) .  Now the grid is a balancing act in providing services and resources.  How much does the grid have to understand about the tasks of the agents?  To what extent does the grid make these decisions or is it just a mechanism.  One could view an empowered active grid as the locus of control making the key decisions of whether agents can have resources and which agents have priority - an almost communist scheme in which the grid has the power to provide resources, rewards and benefits and is empowered to assign or remove tasks from agents.  Agents only have to report status to the grid and receive tasks and that is all.  At another end of a spectrum, the passive grid just supplies mechanisms for registration but the agents provide the control.  The mechanism might now be market driven with some notion of cost as the arbiter of decision making with agents making the decisions. In between, both the grid and the agents in it share control and must negotiate with each other.  In this variant, by a symmetry argument, the grid must effectively be an agent in so far as it itself negotiates as an equal to agents.
• If the grid only understands some kind of currency (money, electricity) then it may not have to understand much about the agents registered with the grid.  If it must be able to reason about different agents'  tasks (can it see their state, or must it ask nicely?), then it must have authority and control over them to make some decisions or task them.  So it itself is acting like an agent.  See the next section.
• A flat grid supplies services, resources and optimization to a very large collection of agents.  This may be the case even if the "flat grid" is really a federated composition of a large number of smaller grids or agent systems.  This is a view of grid as a backplane.  Some alternative architectures to consider are:
• agents register with agent systems and agent systems (not agents) register with the grid, which is effectively an agent system itself.  So there are hierarchies of agent systems.
• agents that are currently not registered with any agent system must be registered with the grid so they can be found.  This makes the grid a kind of agent system itself but one that manages homeless agents.
There are other variants.  But an issue is, does an agent system provide services and resources.  And isn't that also what grids do?  So isn't a grid just a variant of an agent system (or perhaps protocols and bridge mechanisms to federate agent systems).
• Finally, along these lines, the question of whether services are agents should be raised.  On the one hand, we'd like to reuse middleware object services that simply function as they are told.  So another issue about agent systems as well as the grid is whether non-agents (system supplied services or passive model entities) should exist in agent systems.  If so, it might be convenient but not necessary to represent them as objects.  The other end of this spectrum is the uniform agent system where everything (applications, system services, resources, data sources, an agent system, the grid) are uniformly viewed as agents.  A last issue for both approaches is, how do they interoperate with non agents like objects?  Do they just view objects as degenerate agents that are passive, speak when spoken to, reply to anyone who sends them a message, etc.  Or is it better to view all entites as agents, many of which are degenerate, do not negotiate, and wrap objects.  The object modeling world tends to view all entities of interest as objects and wraps legacy systems with object adapters.  An argument might be made to do the same with agents.  So for instance, a fuel tank as an agent continuously monitors its own state and negotiates with the vehicle it is part of and the mission when to refuel.  This might be very like objects but with each having its own continuously active thread of control (like Carl Hewitt's actors).   Some view that for any agent systems, dumb objects will outnumber smart agents 1000 to 1.  But that from the outside (interface), it will not be possible to tell which are which.
*** (FM) The distinctions being made in this paragraph (the differences between the various approaches mentioned) aren't very clear. One way to clarify the differences might be in terms of what languages the various components speak. If agents by definition communicate in (some) ACL, then anything you have to communicate with in some other language is by definition not an agent (not even a degenerate one). You can then imagine that either agents generally speak directly with these other things (ordinary objects or legacy systems) directly, or they need to have special adaptor agents assigned to them. Ordinary agents talk ACL to the adaptors, and the adaptors talk to objects/legacy systems using their conventional interfaces. Alternatively, an object could be considered a degenerate agent, which would involve characterizing agents not by their language, but by some combination of capabilities.

Viewing grids as organizational units

• family units with roles from mother, father, children, grand parents, etc.  Federations of these make up the human race.
• org charts containing a hierarchy of responsibilities including management, direct and overhead activities.  Military force structures and company org charts are historically predominantly hierarchical.  They reduce information flows from bottom to top and so handle information overload and comm. bandwidth.
• teams that come together for a short time to do some task
• enterprises including virtual enterprises that have articles of confederation including IP rules and some profit or non-profit objectives
• herds, flocks, ... with emergent behavior based on rules

Responsiblities are related to and help define roles.  An agent might be a member of many grids simultaneously - the religion grid, the family grid, the work force grid, the political grid, the consumer grid, the social grid, the legal grid, the transportation grid, and many more.  The grids all account for some of the agents objectives.  Organizational grids interact so some principles (high level rules) govern attempts to separate church and state, the social rule of the 40 hour work week guides a separation of work from the rest of life, etc.  Grids themselves can simply co-exist or they can cooperate with each other or they can compete. Grids can be organized in multiple ways simultaneously, e.g., matrix organizations.

We may or may not choose to call organizational units grids - we might rather call them ensembles or event ensemble agents, since the grids themselves act like separable entities.  But they must be modeled in many DoD scenarios.  Their existence accounts for many use cases of why we, our co-workers, or our competitors do what we do.  Agents will have to model and understand command hierarchies.  So it is most likely that some of the most important agent contributions will happen while modeling organizational units.

Others' views of the CoABS grid

Some of the work on agent grids has focused on the grid as a sort of meta agent system (see the second interpretation of the coABS grid above).  The read-ahead material very definitely talks as if sense B is the one meant.

• There was initial and continued excitement about Javasoft's Jini technology [5] as a possilbe agent system infrastructure testbed (proto grid).  Draws are possible pervasiveness, close tie-in to industry, source code availability (with license), and availability of a starter kit of services.  Jini consists of an interlocking collection of built-in services:  federated trader service, licensing service, distributed events service, persistence service, transactions service, along with the presumption that other services can be added via the trader.  Initial examples show Jini running in embedded systems like hotel rooms, TVs, printers, etc. so there is a presumption that Jini frameworks can be used to model complex systems.
• Al Piszcz' paper [7] focuses on the namespace and trader aspects of a global grid.  It mainly views the grid as a namespace and registry that must scale.
• Brian Kettler's paper [8] takes a use case view of the grid and generates a grid abstract machine that takes the view of the grid as similar to an agent system and consisting of a backplane registry of events that describe agent, service, and resource operations and status.  The paper is insightful in that it captures our second view of a grid while trying to make minimal assumptions.  It does not commit to any control tradeoff between agents and the grid and so is underspecified.  In fact, the use case paper [8] seems to be diverging somewhat from that sense in that the use case paper seems to be getting away from the idea of the grid having a fair bit of control over the participating agents (or their resources).  By itself the paper does not identify or answer many of the grid issues we raise here.  But it provides a framework for doing so more precisely.

Open issues about the coABS agent grid

• requirements - from the point of view of DoD applications, what do we expect from agent technology. There are many answers:
• replace stovepipe systems with more reliable, scalable, survivable, evolvable, adaptable systems.  Make it much easier to snap together future systems to meet flexible needs in uncertain environments
• reduce complexity - simplify agent technology so it is useful to the masses
• solve data blizzard, information starvation problems
We need to write these down and then provide mappings to agent architecture capabilities that make these domain capabilities possible.
• There seem to be related capabilities in several systems that are somewhat like agent systems - e.g. distributed object systems, simulation systems, network management systems, meta computing.  What mechanisms does agent technology provide and how are they related to distributed object and component technology?  How can we avoid yet-another-architecture - the agent reference architecture cannot be a wholly different architecture than near-by relatives.  It should overlay or augment architectures like ORBs, Web, HLA, Jini, ODP, Quorum, AICE, ALP.  Or it may be that it provides local agent architectures that can interoperate.  Coordinate with DDB, AICE, and Quorum on design of an open decentralized global grid.  Borrow and unify ideas of clusters, federates, enclaves from OMG, ALP, HLA, IA, Jini.  Unify agent architecture with HLA, Web, ORB, workflow, ...
*** (FM) The Bradshaw presentation explicitly makes the points that agents are smarter objects, and that (in typical architectures) dumb objects will outnumber smart agents by orders of magnitude.  The agents will interact with the objects the way, e.g., you interact with a dog (or. another example, a machine with controls), but if you design the interfaces properly, no one will know whether you're dumb or not ("On the Internet, no one knows you're a dog").

I see agents as being like objects in the sense that they are encapsulated units, and present interfaces to the rest of the world; they talk to anything outside them via interfaces too.  People are like that too (I don't know what's going on inside your head, all I know is what's presented to me by your interfaces;  and when you're on the other end of an email link, the analogy is even stronger).  So are machines like cars and TV sets;  I don't muck around with their internals, I deal with them via their interfaces (knobs, dials, steering wheels, screens, and gauges).  The interfaces with machines are relatively simple, and (hopefully) imperative and deterministic--I turn the wheel right and the car goes that way.  The interfaces with people are pretty complicated (e.g., natural language is pretty complicated, in general), and may be more or less imperative depending on our relationship--I may be in a position to order you to do something, or I may have to persuade you to do it, and in any event you may refuse.

So I see this "grid" as a sea of objects (encapsulated things having identity that deal with each other via messages sent to interfaces).  In some cases, the interfaces encapsulate smart things (more or less smart agents, or even human beings, in the case of messages sent to people:  "fmanola@objs.com" is the identifier of an interface to which messages can be sent), and in some cases the interfaces encapsulate dumb things (ordinary pieces of software that simply do what they're told).  In some cases the messaging protocol is simple (conventional object RPC), and in other cases it's more complicated (like the email flow between people).  The Internet is along the lines of being such a grid.  We can negotiate via email with other people to arrive at various agreements.  However, via the same email interface, I can tell an email list server to subscribe me (admittedly the contents of the messages are of different complexity, but it's the same interface at least syntactically).  Via another kind of messaging format (but using the same infrastructure), Java programs on client and server can communicate with each other.

All this is based on my concept of an object as simply being an encapsulated unit that has an interface, and communicates via messages with the "outside".  I don't impose other characteristics on objects.  They can be smart or dumb, internally concurrent or not, etc.  I think all the agent assumptions I've seen involve the idea of an agent being an object in this sense.  So, for example, agents have distinct identity, you can tell when one agent ends and another begins, a piece of software is not part of the implementation of more than one agent, and so on.  In the agents systems I'm familiar with, an agent is distinguished by its ability to communicate in an ACL in some specific messaging protocol.  But that doesn't mean it can't communicate with other types of software artifacts (like objects, or conventional procedures), by sending the appropriate kinds of messages using the appropriate protocols.  In the same way, we distinguish people by various characteristics (many of which are determined by their interfaces, even when they can't communicate via some of them, as with people who are deaf or dumb), but that doesn't mean that people can't "communicate" with artifacts (software or cars);  they just use different interfaces, and assume different protocols of operation.

It seems to me both of these presentations embody themes that are highly-related to the Web-object stuff, esp. the idea that you create SW by linking bits of code (and, presumably, data) to form a "software grid".  So you have bits of code and data sitting on the Web, identified by URIs, and you connect them up.  The Web, here, is the "global software grid", from which you form individual "views" by defining which bits of the global grid you intend to use in a specific case, and how you want them connected.  Of course, all you have to do is figure out how to define the interfaces so the linking-up is easy!.  But concepts like the DOM (which provide a generalized interface to the "data" bits, are a start in this direction as far as the Web is concerned.  This might be a hook we can use to talk about the relationship between the Web-object stuff and the agent-based architecture work.

• what are agents? - thin, thick, smart, dump, mobile, stationary, chatty, objects that use ACLs to communicate, … We must tease these (possibly orthogonal) properties apart and understand what our technology is adding to the picture.  Especially if we want a large body of industry and DoD to adopt this next generation technology.  Our working assumption is that agents are (some of):
• autonomous - agents are proactive, goal directed and act on their own performing tasks on your behalf
• adaptive - agents dynamically adapt to and learn about their environment.  They are adaptive to uncertainty and change.
• mobile - agents move to where they are needed
• cooperative - Agents coordinate and negotiate to achieve common goals.  They are self-organizing and can delegate.
• interactive - Agents interoperate with humans, other, legacy systems, and information sources
• social - they work together in communities, may have personality.
*** (FM) they have identity, and interfaces by/through which they communicate with each other and with other system components, and they have their own state and behavior, i.e., they are objects/components. One point illustrating this is that if they aren't objects, and are mobile, it seems to me you have a lot of difficulty describing exactly what it is that moves. Similarly, it seems to me that an agent must have its own state and behavior in order to be adaptive, autonomous, etc.
• Can the grid or other agents examine the state of an agent (even against its will) or is such a request always a negotiation or are there a spectrum of possibilities.
• Can agents exist and interoperate with others outside the grid?
• If computational grids support sharing computations, then what do agent grids support sharing?  information, knowledge, decisions, requests and responses, plans?  They support sharing agent capabilities of all kinds (as well as, in the read-ahead description, the resources that can be assigned to agents, like processor usage, disk space, etc.)
• Will one grid scale to support millions of agents, or are there many such grids?
• Are there many agent grids that federate or interoperate.
• Is the Agent grid a kind of (super) agent system itself.  Grids and agent systems both provide services within their biosphere (boundary).  In the sense that the grid has its own goals (as suggested, e.g., in the read-ahead material)?
• Is the Agent grid an agent in that both can control resources?
• Are services themselves agents and does this matter if they are or not?  Is there a difference between a service being an agent and being controlled by an agent?
• Does the grid actively control services, resources and optimization and can it take these away from participants that have them?
• Are agents actively part of the grid or are they end users of the grid?
• How much does the grid have to understand about the tasks of the agents?
• Are some agents dependent on services in such a way that they will fail to complete their mission if the service becomes unavailable?  Other agents may be service-independent of services within a grid.  Another dimension is Service-Awareness.  An agent is service-aware if it is dependent on a service and also can manipulate the services policies in some way.  It is service-unaware if it cannot manipulate them but it may still be service-dependent.
• criterial (defining) characteristics, minimal, maximal, lite or heavy weight - Are there criterial properties of agent based systems?  is there any minimal or maximal set of properties that we can agree on for something to be an agent-based system.  Is it based on technical mechanisms (e.g., makes use of an ACL) or just any system with (some of) these properties:  autonomy, adaptive, cooperative, mobile, interoperable.  How can we keep the architecture lite weight and still accommodate all the services?
• grid-agent separation - agents are autonomous but they cooperate and compete in some context which we are terming the grid.  The grid provides some global systemic properties and some basic shared services.
• are agents really autonomous (including being independent of the grid)?
• is there an explicit grid or is it implicit in the way agents interact with each other?
• are some “services” (like planning) optionally distributed into agents or are they available from the grid’s planing service.  Does this matter?
• is there a maximal or minimal (lite-weight) grid?  for instance, how freely can one add services to a running grid?
• what happens if agents interoperate that come from differently configured grids?
• do agents ask other agents for their properties and grid capabilties
• can new services be autoloaded into a grid that does not have them?
• agent-agent separation - can agents access each other’s state directly
• agent-service separation - how are agents and services related?  For instance, do agents implement the long list of services that the grid provides or is that underlying component software?  Does each agent contain a planner or is a planning service global to a collection of services?  It might be a wave-particle distinction.
• embracing heterogeneity - it is clear we must do this if agents will live in internet settings.  But we also cannot  expect systems to work with complete heterogeneity.  The Web works partly because widespread agreement on HTTP, HTML, XML, .. and DBMSs work because of SQL and related standards.  So we must identify the specific kinds of heterogeneity we want agent system architectures to support.  It is not enough to say we are embracing heterogeneity.  The DARPA ATAIS architecture recognized a useful spectrum of interoperablity:
• "Successive tiers of interoperation, which also correspond to levels of achievable capability for systems built by composing predefined components, are termed isolated, co-habitable, syntactic, semantic, seamless, and adaptive, in increasing order of interoperability."
• As vendor-specific agent systems implementations can be viewed as homogeneous mini-grids, interoperability of heterogeneous systems is the most important factor / goal of the grid.  What is the scope of heterogeneity that needs to be addressed by the grid? Can inter-agent interoperability be completely separated from agent-grid & grid-grid interoperability issues? E.g. while the postal systems have some constraints/rules, neither they (or the telcos) regulate or constrain the content.
• semantic interoperability - how far beyond the standard OO class model or DBMS schema do ontologies go; do they scale (most ontologies are pretty narrow), specifically which interoperability problems are solved
• licensing - like many grid services, licensing’s degenerate form is no licensing.  But agents and component software cannot succeed without an economic model that makes broad communities get value from them.  One way to do this is via licensing space on your machine, capabilities and services, data sources, …  A model of licensing might be critical for coABS to succeed in the large.
• Agent Communication Language (ACL)
• is the ACL compositional and extensible so one can define new speech acts from existing ones?
• How many speech acts is enough?  20 or 5000?
• is this the only way agents communicate to each other, to humans, to non-agents?
*** (FM) The answer is obviously that it can't be, if agents are going to communicate with, e.g., legacy software (which doesn't understand ACL). The alternative would be to insist that in order to communicate with, e.g., legacy software, the agent must communicate in ACL with a mediator, which by definition is not an agent, since it must communicate with the legacy software not using ACL.
• control points - where are the control points where different control algorithms might be substituted into the architecture
• grid federation issues
• how are grids federated - flat model, hierarchical
• if different grids contain different policy choices or different services, how does that affect agents communicating across grid boundaries?
• can we add new services and -ilities to a grid once it is deployed?  how transparent is addition or subtraction of services and ilities
• if COTS technology today is not easy to compose, what changes are needed to make this vision possible?  a layer on top of MS office?
• What is the relation of the agent grid or an agent system to environment or context
• Risks:  silver bullet, overpromising, pin-down coABS unique contribution
• Do planning techniques scale for Internet and programming language communities?
• Define agent functions, keep complexity manageable for the programmer in the street.  Insure the systems are implementable via prototyping; share toolkits where possible; build on COTS and GOTS where possible.
• Insure coABS reference architecture provides template for next generation unified OMG, FIPA, and W3C standards and that reference implementations (toolkits) exist and are widely available.
• How do we foster an economy of componentized agent software?
• micro licensing component software and leasing resources across the network
• crossing organizational boundaries so the net is the DBMS, the net is the computer
• how to populate space with 100,000 advertisements?
• What are the properties of a grid?  stability? if the system has an ility, is the grid tasked with monitoring or full enforcement?  Is -ility maintenance local or global?
• *** (PP) Given that each member host / biosphere may have different capabilities & therefore different abilities to support different ilities (e..g some hosts may not have security or performance monitoring), the grid will not be able to enforce/guarantee some ilities which are host-level, nor require that the individual hosts provide those ilities (e.g. controlling cpu usage).
• Some other questions:
• Are grids always up & running? Can agents start grids as needed? Can agents start different kinds of grids depending upon their goals? Do agents seek out / lookup different kinds of grids depending upon needs? Can agents belong to multiple grids simultaneously? Do grids seek out agents/systems to join their grid?

Other things to cover?

Here are some areas where more work is needed:

• issue resolution
• ilities
• interoperability
• technology underpinnings like XML and web-objects
• listing the services in more detail

Conclusions

• there are several kinds of grids, some like the software and the information grid that are applications of infrastructure technology that likely includes agent technology
• there is a body of agent technology that could constitute the agent layer.
• grid might be related to agent systems either as master registry mechanisms or meta agent systems or similar.
• organizational units (ensembles) act like grids in that they control resources.  So do agents.

But the paper raises many issues that it does not address.  So there is more work to be done.

Acknowledgements

References

[2] Advanced Battlespace Information System (ABIS) Task Force Report,  (protected access).  Identifies the global information grid as a key for DoD C4ISR systems.

[3] DARPA CoABS Read Ahead Package and CoABS Kickoff Meeting, Pittsburgh, July 22-23, 1998.  Identifies the grid as a key agent technology.

[4] Craig Thompson.  Strawman Agent Reference Architecture.  Presentation to DARPA ISO Architecture Working Group, August 13, 1998 and OMG Agent Working Group, September 14-15, 1998.  See especially foils 13, 15, and 19.

[5] Paul Pazandak, A Rough Guide to Sun's Jini, August 1998.  This is a getting-started document as there is now more info available on Jini.  We and a few others in coABS are Jini beta test sites.

[6] Paul Pazandak, Agent System Comparison, draft, 10/19/98.  This is part of a reference model for agent systems.

[7] Al Piszcz, Grid Metaservice Considerations for Control of Agent Based Systems, draft, 3 September, 1998.

[8] Brian Kettler, The CoABS Grid Vision, draft 2.1, 11/18/98, Brian Kettler, ISX Corporation. This paper provides a use case analysis and a grid system abstract machine based on it.

[9] Joshua Epstein and Robert Axtell,  Growing Artificial Societies: Social Science from the Bottom Up, MIT Press. The use of cellular automata theory to model phenomena in large agent populations (birth, death, starvation, moving to a place where there is more food, genetics and survival of the fittest etc.).

[10] J. Knight, M. Elder, J. Flinn, P. Marx. Summaries of Three Critical Infrastructure Applications. UVa Technical Report.  November 14, 1997.

© Copyright 1998 Object Services and Consulting, Inc. Permission is granted to copy this document provided this copyright statement is retained in all
copies. Disclaimer: OBJS does not warrant the accuracy or completeness of the information in this survey.

Last revised: December 31, 1998.  Send comments to Craig Thompson.