The Bio-Networking Architecture: Its Architectural Design and Platform ...

The Bio-Networking Architecture: Its Architectural Design and Platform Implementation Junichi Suzuki and Tatsuya Suda Department of Information and Computer Science University of California, Irvine Irvine, CA 92697-3425, USA {jsuzuki, suda}@ics.uci.edu http://netresearch.ics.uci.edu/bionet/

Abstract. Future networks will connect heterogeneous objects and services, and be much larger and more complex than the current networks. We believe that making this future a reality requires a network that exhibits selforganization with inherent support for scalability, mobility, adaptability to environmental changes in network, and survivability/availability from massive failures and attacks. In the Bio-Networking Architecture we have proposed, we apply biological concepts and mechanisms into network application design because biological systems have already realized the above desirable properties. This architecture is a new framework for developing large-scale, highly distributed, heterogeneous and dynamic network applications. This paper describes the key architectural goals and application level features in the BioNetworking Architecture, and identifies a set of requirements to the BioNetworking platform, or bionet platform, which is distributed object middleware to aid developing applications by providing reusable software components. Then, we present the design of bionet platform and describe how the identified requirements are satisfied in bionet platform. We also present our implementation status and several results of preliminary measurements to examine performance and scalability of bionet platform.

1 Introduction Future networks will connect heterogeneous objects and services, and be much larger and more complex than the current networks. In addition to conventional computing devices, most vehicles, appliances, tools, sensors, and even unmanned robotic devices in space will be nodes in network. Network spans locations engaged in every human endeavor, including the home, workplace, transportation vehicles, public facilities, and space facilities. Some aspects of this vision are already in progress today. However, a radical shift in network design paradigms is necessary to realize this vision. We believe that making this future a reality requires a network that exhibits self-organization with inherent support for scalability, mobility, adaptability to environmental changes in network, and survivability/availability from massive failures and attacks. Today’s networks are unable to satisfactorily meet such challenges.

2

Junichi Suzuki and Tatsuya Suda

We believe that key features of the future network applications, such as scalability, adaptability, and survivability/availability, have already been overcome elegantly by various large-scale biological systems. Accordingly, future network applications may be able to achieve these desirable properties by adopting certain key biological principles and mechanisms. In the Bio-Networking Architecture we have proposed, key biological principles and mechanisms are applied to network application design. It is designed to operate on large-scale, highly distributed, heterogeneous and dynamic network environments. A large number of objects and network nodes exist in network, and objects provide a wide variety of services and work on various network nodes ranging from workstations to cell phones. Network nodes may dynamically join and leave network. This paper presents the architectural principles in the Bio-Networking Architecture, and describes the design and implementation of the Bio-Networking platform. The Bio-Networking platform, or bionet platform, is middleware, which aids developing applications by providing high-level and reusable software components. These components abstracts low-level operating and networking details (e.g. I/O, concurrency, messaging and network connection management), and provides a series of runtime services that cyber-entities frequently use. We describe the design of bionet platform and the current implementation status with several results of preliminary measurements to examine performance and scalability of bionet platform. Remaining sections are organized as follows: Section 2 overviews key principles in the Bio-Networking Architecture. Section 3 presents the features and design strategies in the Bio-Networking Architecture, comparing with the existing related system architectures. Section 4 describes the design and implementation of bionet platform, and Section 5 presents preliminary performance measurement results. In Section 6, we conclude with discussion and future work.

2 Key Principles and Concepts in the Bio-Networking Architecture This section overviews the key biological principles and concepts that we apply in the Bio-Networking Architecture. 2.1 Decentralized Organization of Autonomous Biological Individuals Biological systems often consist of autonomous entities (e.g. bees in a bee colony and birds in a bird flock) which interact with each other. A key observation in such biological systems is that there is no centralized entity (e.g. a leader bird in a bird flock) that directs other entities to control an overall system. The decentralization helps biological systems increase their scalability and survivability [Kel94]. For example, a bird flock can last without significant damage (scalability problem) even when the number of birds in the flock is doubled by merging with another flock. It can also survive even when half of the birds in a flock are lost due to an attack by predators. In the Bio-Networking Architecture, a network application is modeled as a decentralized collection of autonomous distributed entities called cyber-entities. This

The Bio-Networking Architecture: Its Architectural Design and Platform Implementation 3

is analogous to a bee colony (an application) consisting of multiple bees (cyberentities). Each cyber-entity provides its own functional service and performs biological behaviors (e.g. reproduction and migration) autonomously. Cyber-entities are loosely-coupled, and no centralized entity exists in the Bio-Networking Architecture, as there is no such entity in biological systems. 2.2 Emergent Behavior In biological systems, useful behavior often emerges through autonomous interactions among biological entities with simple behaviors. For example, when a bee colony needs more food, a large number of bees will leave the hive and go to the flower patches to gather nectar. When the bee colony is near its food storage capacity, only a few bees will leave the hive. This adaptive food gathering function emerges from simple and local interactions among individual bees. The bee colony also exhibits other types of emergent behavior, such as self-organization and survivability. In the Bio-Networking Architecture, we apply the concept of emergent behavior by implementing interactions among cyber-entities, each of which autonomously senses local enviroument condition, performs its biological behaviors (e.g. migration and replication) based on the sensed environment information, and interacts with others. Through simulation studies, we have confirmed that useful system behaviors and characteristics (e.g. scalability, adaptability and survivability/availability) emerge as collective results of the simple behaviors and interactions among individual cyberentities [WS01]. 2.3 Evolution Biological evolution occurs as a result of the natural selection from diversity in biological entities. Through many successive generations, beneficial features are retained while detrimental behaviors become dormant or extinct, and the biological system specializes and improves itself according to environmental changes. The Bio-Networking Architecture allows cyber-entities to adapt to network environment through evolution by generating behavioral diversity among cyberentities and executing natural selection. Diversity of software entities can significantly increase their adaptability [MHM99, FSA97]. The Bio-Networking Architecture provides two mechanisms for generating behavioral diversity among cyber-entities. The first mechanism is manual diversity generation, in which a human developer can design multiple cyber-entities to implement the same service with different behavior policies. The second mechanism is automatic diversity generation, which introduces new behavior policies into a child cyber-entity through mutation and crossover during replication and reproduction [WS01]. Natural selection is executed based on the concept of energy. Each cyber-entity stores and expends energy for living, as biological entities naturally strive to gain energy by seeking and consuming food. Cyber-entities gain energy in exchange for providing their services, and they expend energy for performing their behaviors (see Section 2.5), invoking another cyber-entity’s service and utilizing resources (e.g. CPU

4


cycles and memory space). The abundance or scarcity of stored energy affect various behaviors and contributes to the natural selection process. For example, an abundance of stored energy is an indication of higher demand for the cyber-entity; thus the cyber-entity may be designed to favor reproduction in response to higher level of stored energy. A scarcity of stored energy (an indication of lack of demand or ineffective behaviors) may eventually cause the cyber-entity’s death. 2.4 Social Networking The dynamic and decentralized network environment produces the need for a discovery mechanism to search for cyber-entities without a centralized lookup service (e.g. directory). In human society, any two people are linked in a short path through relationships among people [Mil67]. The Bio-Networking Architecture applies the concept of social networks [Rag02, Wat99] to design a decentralized (i.e. peer-to-peer) discovery mechanism [MS02, Eno02]. Each cyber-entity has a set of relationships with others, and uses them to represent its acquaintances, discover other cyber-entities, communicate with other cyber-entities, or form a group of cyber-entities. Searches originate from a cyberentity and travel from cyber-entity to cyber-entity through relationships. Each cyberentity also contains descriptive information about itself (attributes), such as unique ID, functionality, location and owner name, in order to allow searches to distinguish cyber-entities. Each relationship keeps its strength, which is used for prioritizing different relationships. Each cyber-entity changes the strength of its relationship, for example, based on discovery accuracy. 2.5 Cyber-entity’s Structure and Behaviors As described in Section 2.1, a cyber-entity is the smallest component in a network application. A cyber-entity consists of attributes, body and behaviors. Attributes carry descriptive information regarding a cyber-entity. Examples include unique ID, service description and age. Body implements a functional service that a cyber-entity provides, and contains materials relevant to the service, such as data, application code, or owner’s profiles. Behaviors implement non-functional biological actions that are common to all the cyber-entities. Each cyber-entity decides if it invokes a behavior based on its policies in every certain time. [WS01, JS02] describe how to define these policies and make behavioral decisions. Energy exchange and storage: Cyber-entities may gain/expend and store energy, as described in Section 2.3. Communication: Cyber-entities communicate with others for requesting a service, fulfilling a service, or routing messages (e.g. discovery messages) for other cyberentities. Migration: Cyber-entities may migrate from bionet platform to platform.


Replication and reproduction: Cyber-entities may make copies of themselves (replication). Two parent cyber-entities may create a child cyber-entity (reproduction), possibly with mutation and crossover (see Section 2.3). State change: Each cyber-entity may have autonomous, active and inactive (sleeping) states during its lifetime. Cyber-entities in different states consume resources differently; therefore they expend energy at different rates (see also Section 3.2 and 4.3). Death: Cyber-entities may die because of old age or energy starvation. Relationship establishment: Cyber-entities may have their own relationships with others, as described in Section 2.4. They establish, eliminate and keep track of relationships. Social networking: Cyber-entities may discover other cyber-entities by sending a discovery message through their relationships (see Section 2.4). Pheromone emission and sensing: Cyber-entities may leave their pheromones on their local platform when it migrates to another platform. A pheromone is a pointer to a cyber-entity, which helps other cyber-entities to find it. Cyber-entities may also emit their pheromones to neighboring platforms for attracting other cyber-entities to come or establish relationships with them. Resource sensing: Cyber-entities may sense the type, amount, and unit cost of resources (e.g. CPU cycles and memory space) available on both a local and neighboring platforms. Each platform determines the unit cost of resources provided on that platform based on their availability. 2.6 Existing and Motivating Applications of the Bio-Networking Architecture An existing application of the Bio-Networking Architecture is a distributed content distribution on the Web [WS01]. Each web server is designed as a cyber-entity, which contains one or more web pages. A bionet platform runs on each network node. A user sends energy units to a web server represented by a cyber-entity, when accessing a web page hosted by the web server. A cyber-entity (i.e. web server) gains more energy as it receives more content requests. It may replicate and move toward users when it has gained enough energy. Some cyber-entities die due to energy starvation when there is no interest from users. Simulation results have shown that cyber-entities (web servers) autonomously adapt to changing user demand and location [WS01]. Scalability and availability were also demonstrated through simulations [WS01]. Cyber-entities ensured that web pages are always available and delivered to users with minimal delay regardless of the amount of user demand [WS01]. Another existing application is peer-to-peer information sharing [MS02, Eno02]. Cyber-entities contain shared information exchanged with each other, and a bionet platform runs on each network node (e.g. PCs, PDAs, and cell phones). Cyber-entities exchange energy when they transfer and receive shared information. Depending on their energy levels, cyber-entities will replicate in locations where there is high demand, and die from locations where there is no interest. Each cyber-entity maintains relationships with other cyber-entities, and uses them effectively for searching a target cyber-entity that contains the information requested by a user. Simulation results have shown that each cyber-entity can improve its search

6


performance and accuracy by prioritizing its acquaintances with its relationship strength based on search quality (e.g. search delay, closeness between search requirement and result) [MS02, Eno02]. A possible application we are trying to develop is an ad-hoc devise networking infrastructure deployed at a disaster site (e.g. fire and earthquake), in which thousands of heterogeneous devices are connected with each other for improving the quality of disaster response [JS02b]. The devices that victims have (e.g. cell phones, PDAs and laptop PCs) will participate in the ad-hoc networks as well as the devices that emergency response crews carry or wear. Disposable sensor devises (e.g. temperature and infrared sensors) may be densely scattered over a disaster area, and participate in network. Each devise embeds a bionet platform and has a mechanism for communicating with other devises. Cyber-entities provide their own services (e.g. temperature sensing, wind force sensing, and information provision regarding a building’s floor plan and first aid treatment). A key challenge in disaster response networks is that the network is very dynamic. The topology, density, coverage and traffic of network will always change. Some devises move around a disaster area, and other devises often turn off power for saving their battery. New devises may be scattered over a disaster area additionally, and some of them that fall into regions affected by the disaster will be destroyed. Decentralized and self-organizing networking features in the Bio-Networking Architecture will potentially be able to handle these dynamics. Even if a specific node goes down or a lot of new nodes enter network, the remaining system will not be affected with fatal damages. Cyber-entities establish and maintain relationships with each other to discover other cyber-entities and interact with each other. For example, a cyber-entity running in a rescuer’s head-mounted display may discover and interact with neighboring cyber-entities (e.g. ones that represent sensors and ones owned by other rescuers) to map an affected region and compose multiple cyber-entities (e.g. ones that provide street maps and building’s floor plan) to direct the rescuer to an affected site. Also, using the concept of energy and the mechanism of replication/reproduction, cyber-entities that are used frequently by others will increase their populations, thereby increase their availability. Cyber-entities will be automatically placed in the locations where there are high demands and removed from the locations where there are low demands. Cyber-entities are aware of resource availability on a local and nearby platforms (i.e. devices). Resource awareness, combined with the concept of resource utilization cost, will allow cyber-entities to effectively run on networks where resource supply (e.g. power, bandwidth, etc.) is limited. The Bio-Networking Architecture will potentially make disaster response process, which is very human intensive today, more effective and faster.

3 Architectural Design This section describes object-level (i.e. cyber-entity level) and platform-level (i.e. bionet platform level) features in the Bio-Networking Architecture, comparing with existing five system architectures which have been proposed and deployed in highly


distributed and dynamic environments. We, first, desbribe object-level (cyber-entity level) features in Section 3.1. Then, we identify what kind of key features a bionet platform should implement for supporting the object-level features and for employing the architectural principles described in Section 2. Section 3.2 presents the platformlevel features in the Bio-Networking Architecture, comparing with other five existing architectures. The existing architectures that we compare with the Bio-Networking Architecture are the following: Peer-to-peer architecture: A goal of the peer-to-peer architecture is creating application-level networks with their message routing mechanisms that allow individual computers (participants) to share information and resources (e.g. strage spaces) directly, without dedicated administrative servers [MH01]. A key principle in this architecture is that each participant has equal power and participants share information and resources at network edges by acting as both clients and servers. Implementations of the peer-to-peer architecutre include Freenet [CSW+01], Gnutella [GNU], Chord [SMK+01] and JXTA Distributed Indexing [JXT01] and Jnutella [Jnu01]. The Bio-Networking Architecture is similar to the peer-to-peer architecture in that it provides a distributed message (discovery message) routing mechanism to locate cyber-entities, each of which has equal power, without a centralized entity. Mobile agent architecture: The mobile agent architecture allows an object to migrate from network node to node, searching for and interacting with services on its owner’s behalf. Aglets [LO98], SOMA [BCS01], LEAP [BBW01] and Hive [MGR+99] implement this architecture. The Bio-Netwoking architecture is similar to this architecture in that cyber-entity has mobility. Collaborative intelligent agent architecture: The collaborative intelligent agent architecture emphasizes learning and cooperation among objects in order to perform tasks for their owners. A goal in this architecture is that objects produce greater (or more intelligent) results than sum of the objects. Collaborative information filtering is a typical example implementing this architecture. [BS95] finds the things liked by people (represented by objects) who are similar to a user (represented by his/her object). [Fon97] performs matchmaking users by clustering the users (represented by objects) with similar interests. [KSS97] locates people with needed expertise. The Bio-Networking architecture is similar to this architecutre in that each cyber-entity improves its adaptability to environment through leaning and that cyber-entities collaborate with each other to form a group (a collective service) (see Section 3.1). Grid computing architecture: A goal of the grid computing architecture is to provide a networked virtual supercomputer, or metacomuter [CS92], which is constructed from globally distributed resources such as powerful workstations, normal PCs, and large archival storage devices [FK99, FKT01]. In this architecture, platform software finds available resources, and allocates them to application objects according to requirements defined by the objects (e.g. timeliness and delay). Globus [FK97], Legion [CKG99], Condor/G [BL99] and Nimrod-G [BAG01] fall into this

8


architecture. The Bio-Networking Architecture also targets resource sharing and sevice provision in globally distributed computing environment. Web service architecture (Service oriented architecture): Web services are objects running on the Web environment. They query others for their services (i.e. what they do) instead of their names or interface structures, and communicate with each other via Web technologies such as HTTP. A main goal of web service technologies is to implement Service-Oriented Architecture (SOA). The SOA promises to allow users or their applications to find and combine Web services on demand basis so that resulting combination of Web services meets the users’ requirements. E-Speak [KGS+02], Jini [Wal99] and Openwings [BC01] are examples implementing the SOA. The BioNetworking Architecture is similar to the web service architecture (or SOA) in that cyber-entities are loosely-coupled and dynamically discover other cyber-entities. It also targets a group formation to provide a composite service (see Section 3.1). As illustrated above, the Bio-Networking Architecture has similarity to each of existing distributed system architectures in some points. The following Section 3.1 and 3.2 describe the differences between the Bio-Networking Architecture and existing architectures.

3.1 Object-level Features This section describes six object-level (i.e. cyber-entity level) features in the BioNetworking Architecture, comparing with five existing architectures. Table 1 shows the comparison. Active Autonomous

Self describing

Adaptive

Composable

Accountable

Bio-Networking O O O O O O Architecture Peer-to-Peer * * Mobile agent O O * Collaborative O O O O O intelligent agent Grid O O Web service O O O Table 1. Architectural comparison in terms of six object-level features. O means that the architecture provides the feature, and * means that some implementations of the architecture provides the feature.

Active. Activeness of objects means that they provide functional services to compute application logic. The Bio-Networking Architecture hosts active objects such as printing service, temperature sensing service, and hotel reservation service, as well as passive objects such as files, data entiries and user profiles. It does not distinguish


active objects from passive objects. Rather, it serves them uniformly by managing their representations as cyber-entities. The peer-to-peer architecture does not address active objects (see Table 1). It is limited to develop applications that share passive objects (e.g. files). Since the BioNetworking Architecture hosts both active and passive objects, it allows for building not only content-sharing applications but also a wide range of applications in various domains. The mobile agent, collaborative intelligent agent, and grid architectures address both active and passive objects. The web service architecture often addresses only active objects. Autonomous. Autonomy is the ability of an object to act without the intervention of their users, other objects and platforms [Cas95, EAC92]. Autonomous objects are goal-directed and control themselves in a proactive manner [LD95, BM99, Foner93]. They periodically take the initiative, performing actions that will support future goal achievement. An active object is not always autonomous: it may not have the features of self-control, goal-orientation and proactiveness. Passive objects cannot be autonomous. In the Bio-Networking Architecture, cyber-entities are autonomous objects as we described in Section 2.1. Each cyber-entity has its own goal (e.g. staying as close to users as possible, living as long as possible, and maximizing energy utility), and pursues the goal by sensing network environment and performing biological behaviors [WS01]. In the mobile agent architecture, objects are autonomous in that they decide when and where to migrate by themselves. Their autonomy is often limited, however, to migration behavior, while cyber-entities autonomously perform a lot of behaviors described in Section 2.5. Research efforts in the collaborative intelligent agent architecture have explored techniques for objects to make rational behavioral decisions according to the current environment condition. The Bio-Networking Architecture applies their findings. Objects in the peer-to-peer architecture are not autonomous because they are passive. Objects in the grid and web service architectures are often not autonomous: they do not possess the ability of self-control, goal-orientation and proactiveness. Self-describing. In order to make objects autonomous, they need to be deployed as loosely coupled (i.e. independent of other objects). One of the consequences of the loose coupling is that any objects which an object interacts with may not exist at the point of time the object is developed. New objects may be created dynamically, and existing objects should be able to discover and invoke such newly created objects without recompiling or changing any line of code. Therefore, objects need to keep its own descriptive information that specifies, for example, their capabilities, properties and requirements for interactions, and to make such descriptive information available to other objects. In the Bio-Networking Architecture, each cyber-entity has its own description, as described in Section 2.5. The description includes what functions a cyber-entity can perform, what kind of cyber-entities it can interact with, what inputs it requires, what outputs it produces, and what its attributes are. By using the selfdescriptive information, cyber-entities can dynamically discover others and interact with each other [IKMS01, FS02].

10


Objects in the intelligent collaborative agent architecture often possess their own descriptive information such as what kind of objects it interacts with, what its owner tries to do, and what its owner prefers. Objects in the web service architecture also possesses its own descriptive information such as what inputs it requires, what outputs it produces, and what its attributes are, and what kind of objects it can interact with. These efforts parallel ours. The peer-to-peer, mobile agent, and grid architectures do not assume that objects are self-describing. Adaptive. Adaptability is the ability of an object to increase its fitness to environment. Different evaluation of fitness is defined in different applications. They include response time to service requests, distance between objects and users, and energy utility. The Bio-Networking Architecture allows cyber-entities to adapt themselves to environmental changes in short-term and long-term fashions. The shortterm adaptation is executed by performing a rich set of biological behaviors (see Section 2.5) [JS02]. For example, a cyber-entity may migrate to neighboring platform when resource cost at a local platform becomes high. A cyber-entity may replicate when it receives a lot of service requests and gains much energy. The long-term adaptation is executed through evolution (see Section 2.3). Mutation and crossover dynamically change cyber-entity’s behavior policies at each generation (i.e. during replication and reproduction) [WS01]. In replication, a newly replicated cyber-entity may derive its behavior policies from its parent with possibly mutation. In reproduction, crossover (with possibly mutation) mixes the behavioral policies of two parents to produce a new set of behavioral policies in offspring. The Bio-Networking Architecture provides cyber-entities a wide range of mechanisms for increasing their adaptability, compared with the existing architectures. Our existing simulation studies have shown that the existence of those mechanisms allow cyber-entities to effectively adapt to environmental changes (e.g. changes in workload, user’s location and resource cost) [WS01]. Some implementations of the peer-to-peer architecture enable replication and migration of objects so that the number and location of objects can adapt to users’ demands (e.g. [CSW+01]). The replication and migration, however, are initiated and controlled by platform software rather than objects (Please note that objects in the peer-to-peer architecture are not active). The mobile agent architecture addresses a very limited adaptability through object migration. Objects can initiate their migration. However, unlike the mobile agent architecture, the mobile agent architecture provides neither a rich set of behaviors and evolutionary mechanisms. The intelligent collaborative agent architecture often allows objects to adapt to the requirements and/or preferences of their users, for example, with evolutionary mechanisms and reinforcement learning mechanisms. It, however, does not usually address adaptation through behaviors of objects. In the grid architecture, some implementations allow platform software to replicate and migrate objects; however they do not provide evolutionary mechanisms. The web service architecture does not address adaptability of objects usually. Composable. Composability is the ability of objects to form a group for providing a composite service which cannot be provided by a single object. The Bio-Networking Architecture adopts the view that a cyber-entity and a group of cyber-entities are both


units of computation. A group of cyber-entities is viewed as a single functioning collective entity. Cyber-entities dynamically form a group in a decentralized manner with their descriptive information [FS02, INMSA01]. The intelligent collaborative agent architecture addresses the formation of object group (or society of agents [Huh02]). Objects exchange and filter information with each other to generate value-added information for their users. The web service architecture tries to combine objects on demand basis using a static specification that defines the interactions among objects. The Bio-Networking Architecture tries to combine cyber-entities only using their descriptive information without any static definition of their interaction [FS02]. The other three architectures (i.e. the peer-topeer, mobile agent and grid architectures) do not address or emphasize the composability of objects. Accountable. Accountability is the ability of objects to be responsible for and explain their activities (e.g. what they did, when they did it, and whom they did it with). In large-scale social systems, self-interested (i.e. autonomous) individuals do not act to achieve their common or group interests unless there is coercion or some device to make individuals act in their common interest [Ols82]. In the context of network application, an object may maliciously or unintentionally overwhelm another object with a huge amount of load, or monopolize the utilization of resources such as bandwidth, CPU cycles and storage space. These activities cause disproportional availability of services and resources to other objects: no more services and resources will be available for other objects. The Bio-Networking Architecture prevents these potential problems by making cyber-entities accountable for their activities such as behavior invocation, service provision and resource utilization. Every action that a cyber-entity takes is governed through its energy level, as described in Section 2.3 and 2.5. This energy scheme prevents cyber-entities from overusing resources and other cyber-entities’ services, since all of their activities require energy and they will die when their energy levels become zero. The energy scheme also prevents the cyber-entities that have not been used by anyone continue to stay in network and use resources. Five existing architectures listed in Table 1 basically allow objects to consume unlimited services and resources, and to continue running until they cause loss of services or resources. A peer-to-peer system uses the concept of currency, which is used to exchange (i.e. buy and sell) objects (files) for prices [Moj]. The prices change based on supply and demand. It can prevent excessive utilization of specific objects and balance access load to objects. Some systems implementing the mobile agent architecture can define the upper limit of the resource amount consumed by objects. Compared with these systems, the Bio-Networking Architecture allows cyber-entities accountable for more activities (i.e. behavior invocation, service provision and resource utilization). 3.2 Platform-level Features This section identifies key platform-level (i.e. bionet platform-level) features required for supporting the object-level features described in Section 3.1 and for achieving the

12


architectural principles described in Section 2. Then, we compare the bionet platform with existing five architectures in terms of the identified platform-level features. Table 2 shows the key platform-level features in the Bio-Networking Architecture. Inter-object relationship management

Dynamic object discovery

Object migration

Ad-hoc topology management

Environment sensing

Object lifecycle management

Accountability maintenance through micropayment D C O *

D C D C D C D C D C D C Bionet O O O O O O Peer-to-peer O O * Mobile agent O O * * * * * Collaborative * O intelligent agent Grid O * * O O Web service O Table 2: Architectural comparison in terms of seven platform-level features. D means that the feature is addressed in a decentralized manner, and C means that it is addressed in a centralized manner. O indicates that the architecture provides the feature, and * indicates that some implementations of the architecture provides the feature.

Decentralization. Decentralization is a key design principle in the Bio-Networking Architecture as described in Section 2.1. The architecture is built as decentralized collections of cyber-entities and bionet platforms. There is no centralized entity in both levels of cyber-entity and platform for maximizing advantages of decentralization. As depicted in Table 2, all the features implemented in bionet platform are provided in a decentralized manner. In contrast, existing 5 architectures lack some of those features (see Table 2). Even when they address the features, they often provide them in a centralized manner. The ultimate advantage of decentralization is scalability [MKM99, Hon01]. Centralized systems break when the central entity (e.g. directory server and resource manager) is overwhelmed, but decentralized systems can spread the load. The bionet platform avoids potential bottleneck of scalability in large-scale systems by eliminating centralized entities. Decentralization is essential if the system grows beyond the management of a single administrative entity. Centralized entities also suffer from mobility of objects and platforms. They cannot eventually keep track of consistency of information regarding objects and platforms (e.g. object location, platform location and resource availability on platforms) in highly dynamic systems where objects and platforms join and leave network frequently. The bionet platform eliminates centralized entities, and provides decentralized solutions to this issue (see Section 4.3 for more details). There is an organizational advantage in decentralization [MGR+99]. New users need no setup; they can simply start a bionet platform and join the network. This lowers the barrier for use of the Bio-Networking Architecture. Users are free to develop their own cyber-entities without any central coordination. When users create cyber-entities, they have other cyber-entities use the new ones without explicitly teaching the platform about them.


Another advantage of decentralization is robustness (or fault tolerance, survivability) [AJB00]. When a central entity goes down in a centralized system, the overall system will not work. The Bio-Networking Architecture can avoid fatal errors due to failures of centralized entities. Even when some cyber-entities fail, the remaining system will survive (i.e. failures are localized). Inter-object relationship management. As described in Section 3.1, cyber-entities use their relationships to interact with each other, search other cyber-entities, and form a group (i.e. a composite service). Therefore, the bionet platform provides bionet relationship management service, which allows cyber-entities to establish, examine, update and eliminate their relationships (see Section 4.3 for more details). The peer-to-peer architecture provides a concept of relationship between platforms; however there are no relationships between objects. In the other four existing architectures, an object often acquaints itself with another object by obtaining a reference to the peer. In the Bio-Networking Architecture, a cyber-entity uses a higher abstraction, relationship, for representing its acquaintances (see Section 4.3). Dynamic object discovery. The self-describing, adaptive and composable features of cyber-entities (see Section 3.1) produce the need for a method to dynamically locate cyber-entities (Section also Section 2.4 and 2.5). For example, when a cyber-entity reproduces a child cyber-entity with another cyber-entity, it may want to find a partner whose fitness to the current network environment is high so that the child will be more likely to survive. Therefore, the bionet platform provides dynamic and decentralized discovery mechanisms. The discovery mechanisms are provided at both cyber-entity level and platform level (see Section 4.3 for more details). The peer-to-peer architecture provides decentralized discovery mechanisms, which are implemented in platform level. The peer-to-peer systems often suffer from long delay to discover a target object due to message crawling among platforms. The bionet platform alleviates this problem with several techniques [MS02, Eno02]. The other four existing architectures provide discovery mechanisms through centralized entities such as directory server (Table 2). Object migration. Since cyber-entities autonomously move around network (see Section 2.1 and 3.1), each bionet platform needs to provide a mechanism that allow them to migrate from a platform to another platform. The bionet platfrom provides bionet migration service for supporting this functionality (see Section 4.3). The mobile agent architecture addresses object migration capability. The bionet platform basically resuses the migration mechanism that has been explored in the mobile agent architecture. The other four architectures often lack the mechanisms for object mobility, except for some implementations of grid architecture (Table 2). Ad-hoc platform topology management. As described in Section 1 and 2.6, the BioNetworking Architecture may operate on not only static networks with fixed topology but also dynamic ad-hoc networks where network nodes dynamically come and go. Therefore, each bionet platform needs a mechanism to keep track of topology with neighboring platforms. It provides bionet topology sensing service that allows bionet

14


platforms to exchanges their knowledge of neighboring platforms with each other in a decentralized manner (see Section 4.3 for more details). The peer-to-peer architecture allows each platform to discover the connectivity with neighboring platforms in a decentralized manner. However, it generates a huge amount of control overhead because every platform sends and forwards ping messages (e.g. [GNU]). The bionet platform basically uses the same mechanism to continuously sense the connectivity with neighboring platforms with some techniques to alleviate the above flooding problem (see Section 4.3). Some implementations of the mobile agent and grid architectures are designed to operate on ad-hoc networks with centralized entities that know of all the platforms and connectivity among them (Table 2). The collaborative agent and web services architectures do not address adhoc topology management. Object lifecycle management. As cyber-entities can autonomously replicate and reproduce (Section 2.5 and 3.1), bionet platform provides bionet lifecycle service, which provides lifecycle operations to them (see Section 4.3 for more details). This service is also used to change cyber-entity’s execution state (see Section 2.5). Some implementations of the peer-to-peer architecture provide replication functionality (Table 2). The bionet platform provides cyber-entities a wider range of lifecycle operations. Some mobile agent systems allow objects to change their states, but often do not employ massive replication as a fundamental mechanism. Some implementations of the grid architecture replicate objects through a centralized entity (e.g. replication manager), rather than in a decentralized manner. The other two architectures do not emphasize lifecycle of objects (Table 2). Environment sensing. The bionet platform needs to provide a mechanism that allows cyber-entities to sense the current environment condition so that they can make their behavioral decisions for adapting themselves to environmental changes (see also Section 2.5 and 3.1). The bionet platform provides bionet resource sensing service, with which cyber-entities can monitor the type, amount and unit cost of resources (e.g. CPU cycles and memory space) available on both a local and neighboring platforms (see Section 4.3 for more details). Some systems implementing the mobile agent architecture enable objects to sense their resource utilization on a local platform (Table 2). This functionality parallels ours. In the bionet platform, cyber-entities can sense resource availability on neighboring platforms as well. In some implementations of the grid architecture, centralized entities (e.g. resource manager) keep track of network-wide environment information. The bionet platform performs this in a decentralized manner. Other three architectures do not address this feature (Table 2). Accountability maintenance through micropayment. Cyber-entities are accountable for their behaviors, service invocation and resource utilization through their energy consumption, as described in Section 3.1. In the bionet platform, the energy exchange is a means for each cyber-entity to maintain its accountability through micropayment. For maintaining as much accountability of cyber-entities as possible, the bionet platform implements bionet energy management service. It


manages the energy level of cyber-entities, allows them to make energy payment and records their energy consumption (see Section 4.3 for more details). The existing five existing architectures do not provide a means of objects to create their accountability through micropayment (Table 2), except for a very limited number of implementations in the peer-to-peer architecture (e.g. [DFM00]). While Section 3.2 described the differences between the bionet platform and the implementations of existing five architectures, the Bio-Networking Architecture shares several architectural goals with the other five architectures, as described earlier. Therefore, the bionet platform can be used as a foundation component to implement existing architectures. For example, the bionet platform could work well as middleware for peer-to-peer systems and grid computing systems.

4 Bionet Platform Design and Implementation This section describes the design and implementation of bionet platform to present how it supports the platform-level features identified in Section 3.2. 4.1 Overview of Architectural Components in the Bionet Platform Each bionet platform is hosted by a network node, which has wired or wireless network connectivity. It runs using a Java virtual machine, which in turn runs atop a native operating system (Figure 1). Each cyber-entity lives on a specific bionet platform to provide its functional service and perform its behaviors. CE

CE

CE Context Bionet Services

Bionet Container Bionet Message Transport Bionet Platform Java VM

Figure 1. Architectural components in the bionet platform. CE stands for cyber-entity.

The bionet platform consists of four components: cyber-entity context (CE context), bionet services, bionet container and bionet message transport (Figure 1). A

16


CE context is an entry point for a cyber-entity to access bionet services. It examines if a bionet service requested by a cyber-entity is available, and if it is, the CE context provides the cyber-entity a reference to the service. Each cyber-entity has its own CE context. A CE context is created and associated with a cyber-entity by a bionet lifecycle service (one of bionet services, see Section 4.3), when a cyber-entity is created, replicated, reproduced, or arrives from another host. Bionet services provide a set of runtime services that are frequently used by cyberentities. Cyber-entities use bionet services in order to perform their behaviors (see Section 2.5). Section 4.3 describes more details of bionet services. A bionet container dispatches incoming messages to appropriate target cyberentities. A bionet message transport takes care of marshaling/unmarshaling of messages issued by cyber-entities, I/O, concurrency, and network connection management. Bionet container and message transport implement a subset of the CORBA POA and IIOP, respectively. Section 4.4 describes more details of them. 4.2 Design of Cyber-entity Since the current bionet platform uses Java as an implementation language and CORBA IIOP as a message transport protocol, a cyber-entity is designed as a Java class implementing a CORBA interface. Every cyber-entity must implement the following CORBA interface. # pragma edu.uci.ics module bionet { interface CyberEntity { oneway send(in string message); string metadata(); }; }; The send() operation is a oneway operation for cyber-entities to communicate with each other in an asynchmorous manner. It takes a message exchanged between cyber-entities as its parameter. We use a subset of the FIPA agent communication language for the message format [FIP] with some extensions specific to the BioNetworking Architecture [INMSA01]. A message is encoded with XML. The metadata() operation is used for a cyber-entity to obtain another cyber-entity’s metadata. The mandatory information that every cyber-entity has to specify in its metadata includes the cyber-entity’s GUID (globally unique ID), the cyber-entity’s reference, the format of input message that the cyber-entity accepts, the energy units that the cyber-entity requires for providing its service, the format of output message that the cyber-entity sends out, and the type of service the cyber-entity provides. Developers can specify any additional information in metadata. Cyber-entity’s GUID and service type are 128bit string data. Metadata is encoded with XML.

The Bio-Networking Architecture: Its Architectural Design and Platform Implementation 17 Cyber-entity send() messages

metadata() messages

Environment sensing Behavior invocation Message queue

Behavior selection

Figure 2. Internal structure of a cyber-entity

When a cyber-entity receives a message through the send() operation, it inserts the message in its message queue (Figure2). Each cyber-entity uses an independent thread to continuously sense the nearby environment, identify behaviors suitable for the current environment condition and invoke the most suitable behavior (Figure 2). For example, if a cyber-entity determines to invoke a behavior of processing a message in its message queue, it will fetch a message to process it. Please see [JS02b] for more details of behavior selection of cyber-entities.

Figure 3. Class diagram showing CyberEntityImpl

Figure 3 shows the design of a base class for cyber-entities, named CyberEntityImpl. This class defines the instance variables and methods that are common among all the cyber-entities. Developers define their own cyber-entities by extending CyberEntityImpl. It implements CyberEntity1, Runnable and Seriarizable interfaces. CyberEntityImpl has GUID and metadata as its instance variables. Metadata is maintained as a form of parsed DOM (Document Object Model) tree. 1

Precisely, CyberEntityImpl extends a skeleton class for the CyberEntity interface.

18


The methods with the prefix on are callback methods, which are called at runtime by a bionet lifecycle service (explained in Section 4.3), when specific events occur on a cyber-entity. For example, onCreated() is called to initialize internal configuration of a cyber-entity when it is created. Implementation of callback methods is left to developers. CyberEntityImpl provides their default implementations. 4.3 Design of Bionet Services The bionet platform defines nine bionet services (see Table 2). This section describes how they support the seven platform-level features identified in Section 3.2. Each of bionet services runs on per-platform basis. Any cyber-entities are not allowed to use bionet services running on remote platforms. IIOP is used for the communication between a cyber-entity and bionet service and between bionet services. Bionet services Bionet Relationship Mgt. Service Bionet Social Networking Service Bionet CE Sensing Service Bionet Pheromone Emission Service Bionet Migration Service Bionet Topology Sensing Service Bionet Lifecycle Service Bionet Resource Sensing Service Bionet Energy Management Service

Explanation allows cyber-entities to establish, examine, update and eliminate their relationships. allows cyber-entities to search other cyber-entities through their relationships. allows cyber-entities to sense the cyber-entities running on local and remote bionet platforms reachable in N hops. allows cyber-entities to emit their pheromones and sense pheromones emitted by other cyberentities. allows cyber-entities to migrate to another bionet platform. allows cyber-entities to sense remote bionet platforms reachable in N hops. provides cyber-entities lifecycle operations. allows cyber-entities to sense the type, amount and unit cost of available resources. keeps track of energy level of cyber-entities running on a local platform.

Table 3. A list of bionet services

Inter-object relationship management. Cyber-entities can use bionet relationship management service to manipulate their relationships (see Table 3). As depicted in Figure 3, each cyber-entity has a list (vector) of Relationship objects, each of which represents a relationship with another cyber-entity. Relationship is a Java inner class of CyberEntityImpl, which is not accessible directly from other cyber-entities. Each Relationship object contains a flag showing the relationship is bi-directional or uni-directional, GUID and reference of a peer cyber-entity, strength of the relationship, and date when the relationship is established. Developers of cyber-entities can put any additional information (e.g. the


number of messages exchanged through a relationship) in properties instance variable. Relationship defines the accessor methods to get/set its attributes (e.g. strength). Figure 3 omits the specification of these methods due to space limitation (see [BPD02] for complete method specification). Bionet relationship management service provides the operations to establish, examine, update and eliminate a relationship. The establishRelationship() operation is used to establish a relationship with peer’s GUID and reference specified as parameters. The operation checks if the peer cyber-entity exists, and if it does, sends the peer a message to request establishing a relationship. The discovery mechanisms described in the next section are used to find nearby cyber-entities for establishing relationships with them. The updateRelationships() operation notifies a cyber-entity’s new reference to the cyber-entities that it has bi-directional relationships with, after it moves from a platform to another platform. The operation obtains a list of the cyber-entity’s relationships with its getRelationsips() method (see Figure 3), and sends its peer cyber-entities messages to inform its new reference. The relationship strength changes dynamically (as described in Section 2) when a cyber-entity receives a reward message or satisfaction message. A reward message is used for a cyber-entity to pay energy for a service provided by another cyber-entity. The relationship strength changes in proportion to the energy amount exchanged between the cyber-entities. A satisfaction message is used for a cyber-entity to indicate how much it satisfies with a service provided by another cyber-entity. The relationship strength changes in proportion to the degree of satisfaction, which can be positive and negative. The relationship whose strength becomes zero will be eliminated. [INMSA02] describes some results of simulations to control relationship strength. The bionet relationship management service is implemented based on these simulation results. Dynamic object discovery. Cyber-entities can use bionet social networking service, bionet CE sensing service and bionet pheromone emission service for searching other cyber-entities (see Table 3). Bionet social networking service allows cyber-entities to locate other cyber-entities through their relationships (see also Section 2.4 and 3.2). Discovery using this service is called cyber-entity level discovery because the discovery is performed with the knowledge that cyber-entities have. Bionet social networking service uses the relationships among cyber-entities in two phases: (1) discovery query forwarding and (2) discovery hit backtracking. The discovery query forwarding process moves discovery queries through relationships, seeking cyber-entities that would satisfy the discovery query. The forwardDiscoveryQuery() operation is used for a cyber-entity to forward a discovery query (Figure 4), which contains the query’s GUID to distinguish it from other discovery queries, the query’s hops-to-live count to determine discovery termination, and the parameters describing which cyber-entities are being searched for (e.g. GUID, service type or any information described in cyber-entity’s metadata). Upon receiving a discovery query, a cyber-entity first examines whether it has already received a query for the particular discovery, and if it already has, the discovery query

20


is discarded. In order to examine that, the cyber-entity uses a discovery message table, which is maintained by a bionet social networking service (Figure 4).

CE A (1) forwardDiscoveryQUery()

(3) Discovery query forwarded

(6) Discovery query forwarded

(4) forwardDiscoveryQUery()

Bionet social networking service (2) m sg. id=5 pre-current ref=null ref=nullpre-current pre-current id=“null” Discovery message table

CE B

Bionet social networking service (5) m sg. id=5 pre-current ref= A

pre-current id=“A”

Discovery message table

Figure 4. Discovery query forwarding. A bionet social networking service maintains a discovery message table for each cyber-entity. The table contains the information on forwarded discovery queries.

Then, the cyber-entity checks whether it can respond to the discovery query or not. If the cyber-entity itself does not satisfy the discovery query, it decides to which cyber-entity (or cyber-entities) it forwards the discovery query. A decision is made based on which relationship is more likely to lead towards a cyber-entity satisfying the discovery by using several measures. The measures include the ratio of successful discovery queries over the relationships [MS02, Eno02]. They are maintained in a properties instance variable of a Relationship object (see Figure 3). Before forwarding, a cyber-entity decreases a hops-to-live value in a received discovery query, and if the value becomes zero, stops forwarding. In the discovery hit backtracking process, discovery hits are returned back towards the discovery originator along the path used for discovery query forwarding. A discovery hit message contains the GUID and reference to the responding cyberentity, the query hit’s GUID to distinguish it from other query hit messages, the GUID of the corresponding discovery query, and hops-to-live count to determine backtracking termination. Upon receiving a discovery hit, a cyber-entity examines with its discovery message table whether it has forwarded a discovery query that corresponds to the discovery hit, and if it has not, the discovery hit is discarded. The cyber-entity also examines its discovery message table whether it has already received the discovery hit, and if it already has, the discovery hit is discarded. Then, the cyberentity backwards the discovery hit to the cyber-entity that is recoded in its discovery message table, and discards a table entry regarding the discovery forwarding/backtracking. Before backwarding, a cyber-entity decreases a hops-to-live value in a received discovery hit, and if the value becomes zero, stops backtracking. The cyber-entities that involves in discovery hit backtracking adapt their relationships so that future discoveries can take advantage of the information gathered during the backtracking. The information includes discovery history based on what results a cyber-entity has received from each relationship [MS02, Eno02]. It is contained in a properties instance variable of Relationship (see Figure 3). Bionet CE sensing service is another option for cyber-entities to search other cyberentities. The service knows cyber-entities that exist on a local platform. Each cyberentity registers its GUID and reference to a local bionet CE sensing service so that other cyber-entities can find the cyber-entity. Through this service, a cyber-entity can


search the cyber-entities running on remote bionet platforms reachable in N hops (if N = 0, cyber-entities running on a local platform will be located). It can ask a bionet CE sensing service to obtain a reference to a specific cyber-entity using its GUID, or a set of references to cyber-entities running on N-hops away platforms. When a cyberentity tries to search the cyber-entities running on remote platforms, the service contacts other bionet CE sensing services running on remote platforms to obtain references to the cyber-entities that exist on the remote platforms. Bionet topology sensing service is used to know N-hops away bionet platforms (this service is described later). The functionalities of bionet CE sensing service is called platformlevel discovery because the discovery is performed with the knowledge that bionet platforms have. The third option for cyber-entities to search other cyber-entities is to use bionet pheromone emission service. Cyber-entities can use this service to leave its pheromone (or trace) on a local platform when it migrates to another platform so that other cyber-entities will be able to find the cyber-entity on the destination platform. Bionet pheromone emission service also allows a cyber-entity to let neighboring cyber-entities know of its existence by broadcasting its metadata (i.e. pheromone). Object migration. Cyber-entities can use bionet migration service for moving from a bionet platform to another platform. The service is responsible for sending out a cyber-entity and receiving an incoming cyber-entity. When a cyber-entity migrates, it asks a bionet migration service to transfer the cyber-entity’s state and class file to a bionet migration service running on a destination platform. Cyber-entity’s state is serialized on an origin platform and de-serialized on a destination platform by using Java serialization mechanism. The class file of a migrating cyber-entity is loaded into a destination-side Java virtual machine using a class loader provided by bionet platform. Ad-hoc topology management. Cyber-entities can use bionet topology sensing service to obtain representative references of neighboring bionet platforms reachable within N hops (Table 3). A platform representative is an object representing a bionet platform and it knows a set of reference s to bionet services running on the platform. A reference to a platform representative is called representative reference. Bionet topology sensing service defines four sensing policies; proactive, reactive, hybrid and static sensing. In proactive sensing, each bionet platform (i.e. bionet topology sensing service) continuously leans the topology among platforms by exchanging topological information among platforms. We use a customized version of Mobile Mesh link discovery/routing protocol, which is a link state routing protocol with an extension of fisheye routing technique [Gra00a, Gra00b]. Each bionet platform periodically broadcasts its own representative reference to neighboring platforms so that they can know of its existence. It keeps a table that contains rows of hop count and platform representative references. It inserts platform representative references obtained from a broadcast message to the table, and removes a representative reference from the table if it does not hear a broadcast message for the representative reference within a certain period. Every bionet platform periodically sends out the table to all the bionet

22


platforms it knows. This proactive sensing can immediately produce a required list of neighboring platforms (i.e. representative references), but it may waste much of network resources (e.g. bandwidth) in the attempt to always maintain the updated platform topology [Per00]. The fisheye routing technique is used to alleviate this problem. The exchange of table entries is performed at different rates, depending on the hop distance between source and destination platforms. The exchanging (or refreshing) rate decreases as a function of the hop distance. Reactive (or on-demand) sensing does not attempt to continuously maintain the upto-date topological information. Rather, a bionet topology sensing service invokes a procedure to learn topology among neighboring platforms only when a cyber-entity asks to do so. Upon receiving a sensing request from a cyber-entity, a bionet platform (i.e. bionet topology sensing service) sends out a ping message to all the neighboring platforms it knows. A ping message contains a representative reference of a sender platform and hops-to-live count. When a bionet platform receives a ping message, it sends back its own representative reference to a sender platform of the ping message, and forwards the ping message to the platforms it knows. The hops-to-live count in a ping message will decrease hop by hop, and a bionet platform stops forwarding when it becomes zero. Each platform keeps a list of 1 hop away platform representative references. Although this reactive sensing can lead to less control traffic and less resource consumption, as compared with proactive sensing, in particular when cyberentities do not access bionet topology sensing services and the topological changes frequently, the delay associated with the flooding of ping messages may be considerable [Per00]. We are in the process to design the third sensing policy, hybrid sensing, which incorporate some aspects of the proactive sensing and some aspects of the reactive sensing. Our design is based on a customized version of Zone Routing Protocol [Haa97]. Each bionet platform proactively maintains the topology of its close neighborhood only, thus reducing the amount of control traffic relative to the proactive sensing. To discover bionet platforms outside its neighborhood, the platform reactively sends out ping messages, which reduces the sensing delay, as compared with purely reactive policy. The last policy is static sensing, which a bionet topology sensing service uses a set of well-known representative references that are statically assigned by a platform administrator. In this policy, each platform does not acquire new representative references of neighboring platforms at runtime. Administrators of bionet platform can choose one of these four policies depending on the characteristics of underlying network and application requirements. Object lifecycle management. A cyber-entity can use a bionet lifecycle service to change its execution states, replicate itself, and reproduce a child cyber-entity with a partner cyber-entity (see Table 3). Each cyber-entity can have 4 states: autonomous, active, inactive and dead (Figure 5). An autonomous cyber-entity can receive messages from other cyber-entities, process them, and perform behaviors. Each autonomous cyber-entity runs on an individual thread, and expends energy continuously for a thread and memory space. An active cyber-entity is ready for receiving messages from other cyber-entities, but it does not perform behaviors (i.e. messages are queued within a cyber-entity, but they


are not processed immediately). Each active cyber-entity consumes memory; therefore it expends energy continuously for using memory space. The inactive state is “sleeping” state in which a cyber-entity is externalized into a file with Java serialization mechanism. An inactive cyber-entity does not expend energy because it does not consume any resources. autonomous

Not exists (dead)

active

inactive

Figure 5. Four execution states of cyber-entity

Each cyber-entity decides to change its execution state based on its own policy. For example, a cyber-entity may change its state from autonomous to active for saving its energy consumption when it has not received a service request in a certain time period. A bionet lifecycle service maintains a thread pool, which assigns an idle thread to a cyber-entity when it transits its state to autonomous (from active or not-exist). The thread pool defines the maximum number of threads and avoids creating unlimited number of threads. If there is no idle thread in a thread pool when a cyber-entity tries to become autonomous, the cyber-entity will need to wait until an idle thread is available. If it does not want to wait, it may migrate to a nearby platform whose thread pool has idle threads. Bionet lifecycle service is also used for cyber-entities to replicate and reproduce. When a cyber-entity asks the service to replicate, the service makes a copy of the cyber-entity using Java serialization mechanism, and calls onReplicated() callback method on the replicated cyber-entity (see Section 4.2 for callback methods). Mutation can be executed in this method. For example, inherited relationship list and other parameters can be modified through mutation process. When a cyber-entity asks a bionet lifecycle service to reproduce a child with a partner, the service makes a copy of the cyber-entity using Java serialization mechanism, and calls the onReproduced() callback method on the reproduced cyber-entity (see Section 4.2). Crossover and mutation can be executed in this operation. For example, inherited relationship lists and other parameters may be merged and modified. The implementation of onReplicated()and onReproduced()is left to cyberentity’s developer. Environment sensing. A cyber-entity can ask a bionet resource sensing service for the availability and unit cost of resources (CPU and memory space) available on a local platform, on a specific remote platform by specifying a platform representative reference, or on remote platforms reachable within N hops by specifying hop count.

24


A bionet resource sensing service prices higher unit cost of a resource, based on a rule of demand and supply, as the resource availability gets scarce. The CPU availability is emulated, using a thread pool managed by a bionet lifecycle service, as Nidle_threads/Nmax_threads where Nidle_threads is the number of idle threads in a thread pool and Nmax_threads is the maximum number of threads in a thread pool. The memory availability is calculated as Mfree/Mmax where Mfree is the amount of free memory available on Java VM and Mmax is the maximum size of memory that can be allocated to Java VM. When a bionet resource sensing service examines the availability and unit cost of resources available on a remote platform, it contacts a bionet resource sensing service running on the remote platform. Accountability maintenance. A cyber-entity can use a bionet energy management service to manage its energy level, record its energy consumptions, and pay energy for invoking a service provided by another cyber-entity, using resources and performing behaviors (Table 3). The energy level of each cyber-entity is maintained by bionet energy management service (i.e. bionet platform) rather than cyber-entity itself. This prevents a cyber-entity from cheating on its energy level. Cheating on energy level has damaging effects on resource utilization and other cyber-entities’ behaviors. A bionet energy management service keeps an energy table that contains cyberentity’s GUID and its current energy level. An entry associated with a cyber-entity is inserted to the table by a bionet lifecycle service when the cyber-entity is created. When a cyber-entity performs a behavior (i.e. it uses a bionet service corresponding to the behavior), the cyber-entity needs to give the bionet service its GUID. The invoked bionet service asks a bionet energy management service to check if its energy table has an entry for the cyber-entity, and if not, the cyber-entity will be rejected to access the bionet service. After the cyber-entity uses the bionet service, the bionet service asks a bionet energy management service to decrease the cyber-entity’s energy level by the predefined usage cost. To account for resource utilization, each bionet energy management service periodically scans its energy table to decrease the energy levels of registered cyberentities by the unit cost of resource utilization according to their execution state. It obtains resource utilization cost from a bionet resource sensing service. An energy management service is also used when a cyber-entity (service consumer) pays energy to the cyber-entity that has provided its service (service provider). A service provider always specifies a reference to an energy management service that keeps its energy level in a message exchanged between service provider and consumer. After a service provider finishes providing its service, a service consumer asks an energy management service running in service consumer side to pay the cost of the provided service to the service provider. The consumer-side energy management service decreases the energy level of the service consumer by the specified cost, and notifies the provider-side energy management service the energy payment. The provider-side energy management service checks if the service provider is registered in its energy table, and then increases the energy level of the service provider by service provision cost. As such, the energy payment between cyberentities is executed by two bionet energy management services (i.e. in platform level).


4.4 Design of Bionet Container and Bionet Message Transport Bionet container and bionet message transport reuse the design and interfaces in traditional object request brokers. Bionet message transport is responsible for network connection setup, message transmission and I/O. It uses the CORBA GIOP version 1.1 to transfer messages between cyber-entities, between a cyber-entity and bionet service, and between bionet services. It implements three GIOP message types: Request, Reply and CloseConnection. The current implementation of bionet message transport uses the mapping of GIOP transfer to TCP (i.e. IIOP). The cyberentity’s reference is implemented by CORBA IOR that contains IIOP IOR profile. For interactions between cyber-entities, bionet message transport does not create a socket for each target cyber-entity. Instead, a cyber-entity sends messages to multiple target cyber-entities running on a remote platform over the same TCP connection. Likewise, a single TCP connection is shared by all the target cyber-entities in message receiver side. Bionet container uses the interfaces of the CORBA POA. It works in message receiver side to demultiplex incoming messages and dispatch them to target receiver cyber-entities. The following POA policies are used to implement bionet container. • Thread policy: ORB_CTRL_MODEL (thread-per-request) • Lifespan policy: TRANSIENT • Object id uniqueness policy: UNIQUE_ID • Id assignment policy: SYSTEM_ID • Servant retention policy: RETAIN • Request processing policy: USE_SERVANT_MANAGER • Implicit activation policy: IMPLICIT_ACTIVATION Bionet container implements a hash-based demultiplexing scheme whose performance is O(1) [GS97] so that it can scale well as the number of cyber-entities grows. 4.5 Implementation Status We have completed detailed design in bionet services, bionet container and bionet message transport, and implemented bionet message transport, bionet container and four bionet services (lifecycle, relationship management, energy and resource sensing). See [BNP02] for comprehensive design and implementation specifications. We are using an IDL-to-Java compiler provided by ZEN 2 , which is a Java implementation of CORBA, while bionet message transport and bionet container were implemented from scratch.

2

www.zen.uci.edu

26


5 Preliminary Performance Measurements This section describes several results of measurements to examine the performance and scalability of bionet message transport and bionet container. The measurements were conducted on Java 2 SDK VMs (version 1.4 from Sun Microsystems) atop of a Windows XP machine running on Intel Pentium 3 processor (1 GHz) and 256 MB RAM. All the interactions between cyber-entities were measured within a single network node. Since the Bio-Networking Architecture assumes that a number of cyber-entities run on network and they interact frequently (e.g. for producing emergent properties), each bionet platform should be able to efficiently handle message transmission between cyber-entities. Therefore, we examined the latency for message transmission between two cyber-entities (see Section 5.1). The bionet platform should be also able to handle high workload situation. Especially, it should be able to receive a number of messages and dispatch them to cyber-entities efficiently so that cyber-entities can process as many messages as possible in a timely manner. Thus, we examined the throughput of a cyber-entity (Section 5.2). In bionet platform, a number of threads may be spawned because a cyber-entity is an autonomous entity that works on an individual thread. We examined how autonomous cyber-entities affect the performance of bionet platform compared with active cyber-entities (Section 5.3). 5.1 Latency for Message Transmission between Cyber-entities This measurement examined how long it takes for a cyber-entity (sender cyber-entity) to send a message to another cyber-entity (receiver cyber-entity). It also evaluated the scalability of bionet message transport and bionet container to determine how the number of receiver cyber-entities affects the message transmission efficiency. The latency for message transmission consists of GIOP marshaling in sender side, TCP connection setup, message delivery on the TCP connection, message demultiplexing, GIOP unmarshaling in receiver side and message dispatching to a receiver cyber-entity. As shown in Figure 6, the efficiency of message transmission in bionet platform is comparable with well-known Java implementations of CORBA (JacORB3 and Java IDL4). We confirmed that message transmission between cyberentities is fairly efficient. Increasing the number of receiver cyber-entities increases, in general, the number of TCP connections for receiver cyber-entities, and the demultiplexing effort required to dispatch incoming messages to receiver cyber-entities. However, the latencies remain relatively constant as the number of receiver cyber-entities grows, rather than it increases linearly (Figure 6). This result indicates that the implementation techniques described in Section 4.4 (i.e. connection sharing and hash-based demultiplexing) work effectively for reducing overheads in TCP connection setup and message demultiplexing, and that bionet message transport and bionet container scale well in terms of the number of receiver cyber-entities. 3 4

www.jacorb.org java.sun.com/products/jdk/idl/

The Bio-Networking Architecture: Its Architectural Design and Platform Implementation 27 0.35

Latency (msec)

0.3 0.25 Bionet

0.2

JacORB

0.15

Java IDL

0.1 0.05 0 1

100

200

300

400

500

600

700

800

900 1000

# of objects (cyber-entities )

Figure 6. Latency for a cyber-entity to send an empty string message to another cyber-entity

5.2 Throughput of Cyber-entities This measurement examined how many messages a cyber-entity can receive and process in a second. This measurement also evaluated the scalability of bionet container to determine how the number of receiver cyber-entities affects the message demultiplexing efficiency of bionet container. 3500

Throughput (calls/sec)

3000 2500 2000

Bionet JacORB Java IDL

1500 1000 500 0 1

100

200

300

400

500

600

700

800

900

1000

# of objects (cyber-entities)

Figure 7. Throughput of a cyber-entity. Each message contains an empty string data.

The message demultiplexing and GIOP unmarshaling dominantly affect the throughput of a cyber-entity. As shown in Figure 7, the throughput in bionet platform is competitive with that of an object in existing CORBA implementations. As increasing the number of receiver cyber-entities, the demultiplexing effort increases in general. Figure 7 shows that the throughput remains fairly constant as the number of receiver CEs grows, rather than it increases linearly. This result indicates that the hash-based message demultiplexing (see Section 4.4) works effectively for reducing overheads against the increased number of cyber-entities, and that bionet container scales well in terms of the number of cyber-entities.

28


5.3 Effect of Cyber-entity’s Autonomy on Latency The above measurements are conducted with active cyber-entities. This measurement evaluates how autonomous cyber-entities affect the latency for message transmission. Our experiment used five variations in the density of autonomous cyber-entities (see Figure 8). 100% means that all the receiver cyber-entities were autonomous, and 0% means that all the receivers were active (same as the measurement described in Section 5.1). 350

Latency (msec)

300 0%

250

20%

200

50%

150

80%

100

100%

50 0 1

10

20

30

40

50

# of objects

Figure 8. Effect of cyber-entity’s autonomy on latency

As Figure 8 shows that the latency increases linearly as the number of autonomous receiver cyber-entities grows. The latency gradient becomes steeper as the density of autonomous cyber-entities increases. This overhead is mostly generated by the synchronization of threads that a receiver cyber-entity and message demultiplexing/dispatching effort are executed on. Bionet platform implements three techniques to alleviate this problem; (1) a thread pool in bionet lifecycle service in order to avoid assigning unlimited number of threads to cyber-entities (see Section 4.3), (2) a thread pool in bionet message transport in order to avoid assigning unlimited number of threads to message demultiplexing/dispatching effort, and (3) the concept of energy for allowing cyberentities to voluntarily change their execution states from autonomous to active (see Section 4.3).

6 Concluding Remarks This paper describes the key architectural principles and object-level features in the Bio-Networking Architecture, and identifies a set of requirements to platform software. Then, we present the design of bionet platform and describe how the identified requirements are satisfied in bionet platform. We also present several results of preliminary measurements to examine performance and scalability of bionet platform. As future work, we will continue completing the design of the hybrid sensing policy in bionet topology management service (see Section 4.3). We are also planning


to implement another version of bionet social networking service with the interfaces of the OMG Trading Service (its current version is based on our own interface specification). We will investigate the implications of implementing a trading service in a decentralized manner (the OMG Trading Service interface has been implemented only in a centralized manner). Once we complete the implementation of all the bionet services, we will conduct more comprehensive measurements. For example, we will investigate efficiency, scalability and robustness of decentralized discovery mechanisms for cyber-entities, and analyze the measurement results by comparing with our existing simulation results [MS02, Eno02]. We will also investigate how decentralized platform topology sensing impacts on efficiency, scalability and robustness. While we have deployed the bionet platform on wired networks, we will investigate its design and configurations specializing mobile ad-hoc networks through empirical measurements. Authentication of cyber-entities and bionet platforms is another future work we will need to work on. To authenticate cyber-entities on bionet platform, we are planning to implement some decentralized authentication techniques such as [CY01] as well as an authentication framework that was designed for the Bio-Networking Architecture [ES00]. Since cyber-entities autonomously behave, it is not clear whether the BioNetworking Architecture can operate at an equilibrium point. By implementing a mathematical model that was developed for the Bio-Networking Architecture [Miy01], we will evaluate stability of the Bio-Networking Architecture in actual network environment through empirical measurements. Finally, standardization effort is also our future work. We have actively worked in the Super Distributed Objects (SDO) DSIG (Domain Special Interest Group) in OMG. The OMG SDO DSIG focuses on exploring the characteristics of super distribution (i.e. massive numbers of objects, decentralization, autonomy of objects, and cooperation between objects) in distributed object systems [SAS01], and specifying the standards that allow us to develop super distributed systems by leveraging existing OMG specifications [SSS02]. We will continue to work on proposing key concepts and mechanisms in the Bio-Networking Architecture for OMG standard specifications.

References [Kel94] Kevin Kelly, “Out of Control,” Brokman Inc., 1994. [WS01] M. Wang and T. Suda, “The Bio-Networking Architecture: A Biologically Inspired Approach to the Design of Scalable, Adaptive, and Survivable/Available Network Applications,” Proc. of the 1st IEEE Symposium on Applications and the Internet, 2001. [MHM99] N. Minar, K. Hultman and P. Maes, “Cooperating Mobile Agents for Dynamic Network Routing,” Software Agents for Future Communications Systems, Springer, 1999. [FSA97] S. Forrest, A. Somayaji, and D. Ackley, “Building Diverse Compuer Systems,” Proc. of the Sixth Workshop on Hot Topics in Operating Systems, 1997. [Mil67] S. Milgram, “The Small World Problem,” Psychology Today, vol. 2, pp. 60-67, 1967.

30


[Rag02] P. Raghavan, “Social Networks,” IEEE Internet Computing, vol. 6, no. 1, pp. 91-94, January 2002. [Wat99] D. Watts, “Small Worlds,” Princeton Univ Press, 1999. [MS02] M. Moore and T. Suda, “Distributed Discovery in Peer-to-Peer Network,” Proc. of the First Annual Symposium on Autonomous Intelligent Networks and Systems, May 2002. [Eno02] A. Enomoto, “Community Based Discovery in Peer to Peer Networks,” master thesis, Kyoto University, March 2002. [JS02] J. Suzuki and T. Suda, “Adaptive Behavior Selection of Autonomous Objects in the BioNetworking Architecture,” short paper presentation, Proc. of the First Annual Symposium on Autonomous Intelligent Networks and Systems, May 2002. [JS02b] Junichi Suzuki and Tatsuya Suda, “Middleware Support for Disaster Response Infrastructure,” Proc. of The First IEEE Workshop on Disaster Recovery Networks, June 2002, to appear. [MH01] N. Miner and M. Hedlund, “A Network of Peers,” Peer-to-Peer, (ed.) A. Oram, Chapter 1, Wiley, 2001. [CSW+01] I. Clarke, O. Sandberg, B. Wiley and T. W. Hong, “Freenet: A Distributed Anonymous Information Storage and Retrieval System,’ Proc. of the International Workshop on Design Issues in Anonymity and Unobservability, LNCS 2009, Springer, 2001. [GNU] http://www.gnutelliums.com/ [SMK+01] I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, and H. Balakrishnan, “Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications,” Proc. of ACM SIGCOMM 2001, August 2001. [JXT01] JXTA Distributed Indexing Project Overview, 2001. http://di.jxta.org/. [Jnu01] Jnutella Specification, 2001. http://www.jnutella.org/presentation/umeda/jppp/spec/index_en.shtml [LO98] D. B. Lange and M. Oshima, “Programming and Deploying Java Mobile Agents with Aglets,” Addison-Wesley, 1998. [BCS01] P. Bellavista, A. Corradi and C. Stefanella, “Mobile Middleware for Mobile Computing,” IEEE Computer, March 2001. [BBW01] M. Berger, B. Bauer and M. Watzke, “A Scalable Agent Infrastructure,” Proc. of the 2nd Workshop on Infrastructure for Agents, MAS and Scalable MAS, 2001. [MGR+99] N. Minar, M. Gray, O. Roup, R. Krikorian and P. Maes, “Hive: Distributed Agents for Networking Things,” Proc. of ASA/MA 99, August 1999. [BS95] M. Balabanovic and Y. Shoham, “Learning Information Retrieval Agents: Experiments with Automated Web Browsing,” Proc. of AAAI Spring Symp. Information Gathering from Heterogeneous, Distributed Resources, 1995. [Fon97] L. Forner, “Yenta: A Multi-Agent, Referral Based Matchmaking System,” Proc. of the First International Conference on Autonomous Agents (Agents 97), 1997. [KSS97] H Kauz, B. Selman and M. Shah, “ReferralWeb: Combining Social Networks and Collaborative Filtering,” Communications of the ACM, vol. 10 no. 3 1997. [CS92] C. Catlett and L. Smarr, “Meta Computing,” Communications of the ACM, 35, 1992. [FK99] I. Foster and C. Kesselman (eds.), “The Grid: Blueprint for a New Computing Infrastructure,” Morgan Kaufmann Publishers, 1999. [FKT01] I. Foster, C. Kesselman, S. Tuecke, “The Anatomy of the Grid: Enabling Scalable Virtual Organizations,” Intl. J. Supercomputer Applications, 15(3), 2001. [FK97] I. Foster and C. Kesselman, “Globus: A Metacomputing Infrastructure Toolkit,” International Journal of Supercomputer Applications, 11(2): 115-128, 1997. http://www.globus.org [CKG99] S. Chapin, J. Karpovich, A. Grimshaw, “The Legion Resource Management System, ” Proc. of the 5th Workshop on Job Scheduling Strategies for Parallel Processing, April 1999.

The Bio-Networking Architecture: Its Architectural Design and Platform Implementation 31 [BL99] J. Basney and M. Livny, “Deploying a High Throughput Computing Cluster,” High Performance Cluster Computing, Vol. 1, Prentice Hall PTR, May 1999. [BAG01] R. Buyya and D. Abramson and J. Giddy, “A Case for Economy Grid Architecture for Service Oriented Grid Computing,” Proc. of the 10th IEEE International Heterogeneous Computing Workshop (HCW 2001), April 2001. [KGS+02] W. Kim, S. Graupner, A. Sahai, D. Lenkov, C. Chudasama, S. Whedbee, Y. Luo, B. Desai, H. Mullings and P. Wong, “Web E-Speak: Facilitating Web-based E-Services,” IEEE Multimedia, vol. 9 no. 1, 2002. [Wal99] J. Waldo, “The Jini Architecture for Network-Centric Computing,” Communications of the ACM, vol. 42 no. 7, 1999. [BC01] G. Bieber and J. Carpenter, “Openwings: A Service-Oriented Component Architecture for Self-Forming, Self-Healing, Network-Centrinc Systems,” Openwings Technical Paper, 2001. [Cas95] C. Castelfranchi, “Guarantees for Autonomy in Cognitive Agent Architecture,” Proc. of ECAI-94 Workshop on Agents Theories, Architectures, and Languages, Springer, 1995. [EAC92] M. Evans, J. Anderson and G. Crysdale, “Achieving Flexible Autonomy in MultiAgent Systems Using Constraints,” Applied Artificial Intelligence, vol. 6, pp.103-126, 1992. [LD95] M. Luck and M. P. D'Inverno, “A Formal Framework for Agency and Autonomy,” Proc. of the First International Conference on Multi-Agents Systems, 1995. [BM99] S. K. Barber and C. Martin “Specification, Measurement, and Adjustment of Agent Autonomy: Theory and Implementation,” Technical Report TR99-UT-LIPSAGENTS-04, University of Texas, 1999. [Foner93] L. N. Foner, “What's an Agent, anyway?,” MIT Media Lab, Technical Report, Agents Memo 93-01, 1993. [IKMS01] M. Imada, Y. Katayama, M. Matsuo, T. Suda, “A Service Composition Method based on Service Property,” 2001. [FS02] K. Fujii and T. Suda, “Loose Interface Definition: An Extended Interface Definition for Dynamic Service Composition,” short paper, Proc. of the First Annual Symposium on Autonomous Intelligent Networks and Systems, May 2002. [INMSA01] T. Itao, T. Nakamura, M. Matsuo, T. Suda and T. Aoyama, “The Model and Design of Cooperative Interaction for Service Composition,” Proc. of the DICOMO, 2001. [Huh02] M. N. Huhns, “Agent Societies,” IEEE Internet Computing, January 2002. [Ols82] M. Olson, “The Logic of Collective Action, Rational Man and Irrational Society,” Beverly Hills, 1982. [Moj] http://www.mojonation.net/ [MKM99] N. Minar, K. H. Kramer and P. Maes, “Cooperating Mobile Agents for Dynamic Network Routing,” Software Agents for Future Communications Systems, Chapter 12, Springer, 1999. [Hon01] T. Hong, “Performance,” Peer-to-Peer, A. Oram (ed.), Chapter 14, Wiley, 2001. [AJB00] R. Albert, H. Jeong and A. Barabasi, “Error and Attack Tolerance of Complex Networks,” Nature 406. [DFM00] R. Dingledine, M. J. Freeman and D. Molnar, “The Free Haven Project: Distributed Anonymous Storage Service,” Proc. of the Workshop on Design Issues in Anonymity and Unobservability, Springer LNCS 2009, July 2000. [FIP] www.fipa.org [BPD02] netresearch.ics.uci.edu/bionet/resources/ [Gra00a] K. Grace, “Mobile Mesh Link Discovery Protocol,” Internet draft, IETF MANET Working Group, September 2000. [Gra00b] K. Grace, “Mobile Mesh Routing Protocol,” Internet draft, IETF MANET Working Group, September 2000. [Per00] C. Perkins, “Ad Hoc Networking,” Addison-Wesley, 2000.

32


[Haa97] Z. Haas, “A New Routing Protocol For The Reconfigurable Wireless Networks,” Proc. of the IEEE Int. Conf. on Universal Personal Communications, 1997. [GS97] A. Gokhale and D. C. Schmidt, “Evaluating the Performance of Demultiplexing Strategies for Real-time CORBA,” Proc. of GLOBECOM '97, November, 1997. [CY01] R. Chen and W. Yeager, “Poblano - A Distributed Trust Model for Peer-to-Peer Networks,” JXTA Security Project White Paper, 2001. [ES00] Y. I. Eom and T. Suda, “Authentication for Clone Cyber-entities in Bio-net Environments,” technical paper, University of California, Irvine, July 2000. [Miy01] N. Miyamoto, "An Equilibrium Model of a Self-organizing Network Architecture," Master Thesis, Kyoto University, March 2001. [SAS01] S. Sameshima, S. Arbanowski and J. Suzuki, "OMG Super Distributed Objects White Paper," Object Management Group, July 2001. [SSS02] S. Sameshima, S. Steglich and J. Suzuki (ed.), "PIM and PSM for Super Distributed Objects," Request for Proposal, Super Distributed Objects Domain SIG, Object Management Group, January 2001.

The Bio-Networking Architecture: Its Architectural Design and Platform ...

The Bio-Networking Architecture: Its Architectural Design and Platform ...

Suggest Documents

The Architecture and Design of a Community-Based Cloud Platform ...

Architecture and the Environment - Architectural Histories

ARCHITECTURAL DRAFTING AND DESIGN

ARCHITECTURE L'espace architectural

Light and its architectural effects

Architectural Design Rewriting as an Architecture Description Language

Design of a Distributed Food Traceability Platform and Its Application ...

Software Architecture as a Set of Architectural Design Decisions

Architectural Engineering and Design Management Linking design ...

ARCHITECTURAL DESIGN EDUCATION AND THE PROBLEMATIC ...

Connection to Architecture: Architectural Acoustics

Networks, Architecture and Architectural Education - University of ...

PORTUGUESE ARCHITECTURE IN INDIA â THE ARCHITECTURAL ...

Sharing and Reusing Architectural Knowledge - Architecture ...

Architectural design influences the diversity and ... - BioMedSearch

Architectural Association School of Architecture

Architectural and Material Techniques (Architecture ... - Google Sites

seratio platform architecture - MyPAD

The Platform Domination - Platform Design Toolkit

Exploitation Platform Open Architecture - Thematic Exploitation Platform

Exploitation Platform Open Architecture - Thematic Exploitation Platform

An Engineering Approach to Enterprise Architecture Design and its ...

1 ARCHITECTURAL SERVICES AGREEMENT Architectural Design ...

Intelligent Network Design: User Layer Architecture and its ... - CiteSeerX

The Bio-Networking Architecture: Its Architectural Design and Platform ...