WO2000052593A1

WO2000052593A1 - N-tiered virtual collaborative network operating system

Info

Publication number: WO2000052593A1
Application number: PCT/US2000/005232
Authority: WO
Inventors: Atul Chowdhry; Jack Bernard Holden
Original assignee: Collective Communications Corp.
Priority date: 1999-03-01
Filing date: 2000-03-01
Publication date: 2000-09-08
Also published as: AU3507300A; IL145200A0

Abstract

A plurality of classes of software agents (64-1a, 64-2a), distributed over various electronic devices and communicating over a network, collaborate to provide an n-tiered virtual network operating system providing the combined resources of an entire collective from any device on the network. The system maintains application software and all data entirely within the network and keeps it's end-user device storage requirements for the system itself to a minimum. It thus provides users with access to their data and applications (70a, 70b, 70c, 70d, 70e) from any network device. The agents are distributed over multiple network devices. The collective is largely self-configuring. Agents collaborate with each other to establish network paths. When multiple copies of the agents are deployed, they collaborate to establish an administrative tree structure and provide fault tolerance.

Description

N-TIERED VIRTUAL COLLABORATIVE NETWORK OPERATING SYSTEM

FIELD OF THE INVENTION

The invention relates generally to large networks or wide area networks (WANs) comprising of computers and smaller network enabled electronic devices. More specifically, the invention is concerned with the set of problems that arise in interconnected networks of allowing users to access their data, applications and computer services from any network connected computing device. These devices may take the form of Personal Computers, Personal Digital Assistants (PDA), cellular phones and cable set top boxes. The following background material introduces various computer network concepts and definitions.

BACKGROUND OF THE INVENTION A computer network is simply a collection of autonomous computers connected together to permit sharing of hardware and software resources, and to increase overall reliability. The qualifying term "local area" is usually applied to computer networks in which the computers are located in a single building or in nearby buildings, such as on a college campus or at a single corporate site. When the computers are further apart, the terms "wide area network" or "long haul network" are used, but the distinction is one of degree and the definitions sometimes overlap.

A bridge is a device that is connected to at least two LANs and serves to pass message frames or packets between LANs, such that a source station on one LAN can transmit data to a destination station on another LAN, without concern for the location of nhe destination. Bridges are useful and necessary components, principally because the total number of stations on a single LAN is limited. Bridges can be implemented to operate at a selected layer of protocol of the network.

The basic function of a bridge is to listen "promiscuously," i.e. to all LANs to which it is connected, and to forward each message it hears onto other LANs other than the one from wnich the message was heard. Bridges also maintain a database of station locations, derived from the content of the messages being forwarded. Bridges are connected to LANs by paths known as "links." After the bridge has been in operation for sometime, it can associate practically every station with a particular link connection the bridge to a LAN, and can then forward messages in a more efficient manner, transmitting only over the appropriate link. The bridge can also recognize a message that does not need to be forwarded, because the source and destination stations are both reached through the same link. Except for its function of "learning" station locations, or at least station directions, the bridge operates as a message repeater.

As network topologies become more complex, with large numbers of LANs and multiple bridges interconnecting them, operational difficulties can arise if all possible LAN bridging connections are permitted. In particular, if several LANs are connected by bridges to form a closed loop, a message may be circulated back to the LAN from which it was originally transmitted, and multiple copies of the same message will be generated. In the worst case, messages will be duplicated to such a degree that the networks will be effectively clogged with these messages and unable to operate at all. To prevent the formation of closed loops in bridged networks, IEEE draft publication P802.ID purposes a standard for a spanning tree algorithm that will connect the bridges network into a tree configuration, containing no closed loops and spanning the entire network configuration. The spanning tree algorithm is executed periodically by the bridges on the interconnected network, to ensure that the tree structure is maintained, even if the pnysical configuration of the network changes. Basically, tne ondges execute the spanning tree algorithm by sending special messages to watch other bridges to establish the identity of a "root" bridge. The root bridge is selected, for convenience as the one with the smallest numerical identification. The algorithm determines which links of the bridges are to be active and which are to oe inactive, i.e. disabled, in configuring the tree structure. One more piece of terminology is needed to understand how the algorithm operates. Each LAN has a "designated" link, w7hιch means that one of the links connectable to the LAN is designated to carry traffic toward and away from the root bridge. The basis for this decision is similar to the basis for selecting the root bridge. The designated link is the one providing the least costly (shortest) path to the root bridge, with numerical bridge identification being used as a tie-breaker. Once the designated links are identified, the algorithm chooses two types of links to be activated or closed: first, for each LAN its designated link is chosen, and second, for each bridge is chosen, i.e. a link througn which the bridge received a message giving the identity of the root bridge. All other links are inactivated. Execution of the algorithm results n interconnection of the LANs and bridges in a tree structure, i.e. on having no closed loops.

The Internet is a collection of networks, including Arpanet, NSFnet, ana regional networks at a number of university and research institutions, and a number of military networks. The protocols generally referred to as TCP/IP were originally developed for use only through Arpanet and have subsequently become widely used in the industry. The protocols provide a facility to support services that permit users to communicate with each other across the entire Internet. The services supported by these protocols include file transfer, remote log-in, remote execution, remote printing, computer mail, and access to network file systems.

The basic function of the Transmission Control Protocol (TCP) is to make sure that the commands and messages from an application protocol, such as computer mail, are sent to their desired destinations. TCP keeps trac of what is sent, and retransmits anything that does not get to its destination correctly. If any message is too long to be sent as one "datagram, " TCP will split the message into multiple diagrams and makes sure that they arrive correctly and are reassembled for the application program at the receiving end. TCP simply hands IP a datagram with an intended destination; IP is unaware of any relationship between successive datagrams, and merely handles routing of each datagram to its destination. If the destination is a station connected to a different LAN, the IP makes use of routers to forward the message.

A router, like a bridge, is a device connected to two or more LANs. Unlike a bridge, however, a router operates at a network layer level, instead of the data link layer level. Addressing at the network layer level makes use of a 32-bit address field for each host and the address field includes a unique network identifier and a host identifier within the network. Routers make use of the destination network identifier m a message to determine an optimum path from the source network to the destination network. Various routing algorithms may oe αsed by routers to determine tne optimum paths. Typically, routers exchange information about the identities of the networks to which they are attached.

When a message reaches its destination network, a data link layer address is needed to complete forwarding to the destination host. Data link layer addresses are 48 bits long and are globally unique, i.e. no two hosts, wherever located, have the same data link layer address. There is a protocol called ARP (address resolution protocol) , which obtains a data link layer address from the corresponding network layer address (the address that IP uses) . Typically, each router maintains a database table from which it can look up the data link layer address, out f a destination nost is in this ARP database, the router can transmit an ARP request. This message basically means: "will the host with the following network layer address please supply its data link layer address." Only the addressed destination host responds, and the router is then able to insert the correct data link layer address into the message being forwarded, and to transmit the message to its final destination.

Object Orientated Programming

Object-oriented programming (OOP) s a powerful way to organize and develop software. OOP organizes a computer program into a set of sub-components called objects. An object is a software "packet" containing a collection of data elements and a set of procedures that are the only valid operations on that data. Those operations are called access methods, accessor methods, or simply methods. Once defined, oojects can be used as basic data types within a program. An object has a state, presents an interface, and exhibits a behavior. The state is determined by the value of the object's internal data, vnich results rrom the operations performed on that data by cnanging its state. The variables representing the internal state of an object are called instance variables. The collection of methods determines the object's interface and behavior. Objects exist independently of each other, have rules for communicating with other objects and for other objects to perform tasks.

Application software αesigned and written in an object orientated fashion improves software maintainability and reduces development costs by managing the intellectual complexity of modern software systems.

Virtual Macnmes

Most computers do the same kinds of things or tasks. For example, they store and retrieve files, run application software, and display information on their screens. Internally, different types of computers perform these tasks differently. These internal differences prevent software that runs on one kind of computer from running on other types of computers. The internal differences are so distinct that they cannot be addressed in the same ways by the same software application or program. This means that a program must be written for a specific type of computer, and that programs written for one type of computer cannot run on other types of computer .

Several efforts have been made to get around this limitation by creating virtual machines. A virtual machine is a layer of software that can reside on one type of computer and accept and use applications designed for another. The virtual macnine translates the internal commands from tne foreign computer into internal commands the host computer understands. In effect a virtual copy of the foreign computer resides in the host computer. This concept is currently useα to run Windows™ emulators on Sun or Macintosh computers, allowing applications developed for Windows™ to run without modification on Sun and Macintosh computers.

JAVA

Java is a general-purpose concurrent object-oriented programming language. Its syntax is similar to C and C++, but omits many of the complexities of C and C++. Java was initially developed to address the problems of building software for networked consumer devices. It was designed to support multiple electronic device architectures and to allow secure delivery of software components. To meet these requirements, Java applications had to survive transport across networks, operate on any client, and assure the client that it was safe to run.

Java is a general purpose OOP programming language and provides extensions that support graphical user interface, or GUI, application development. A graphical user interface gives a user access to program and data features (objects) via pictorial or graphical representations of those features. Examples include a picture of a printer for printing, or arrows or elevator bars for screen navigation. Users interact with a GUI with a mouse instead of using keyboard commands. JAVA also supports the development of client/server applications over local and wide-area networks. It is often referred to as a combination of constructs and features from other OOP programming languages.

The Java Virtual Machine is the cornerstone of Sun's Java programming language. It is the component of the Java technology responsible for Java's cross-platform delivery, the small size of its compiled code, and Java's ability to protect users from malicious programs. The Java Virtual Machine is an abstract computing machine. Like a real computing machine, it has an instruction set and uses various memory areas. It is reasonably common to implement a programming language using a virtual machine; the best-known virtual machine may be the P-Code macnine of UCSD Pascal.

The Java Virtual Machine knows nothing of the Java programming language, only of a particular file format, the class file format. A class file contains Java Virtual Machine instructions (or bytecodes) and a symbol table, as well as ancillary information.

In the most recent computer usage, virtual machine is a term used oy Sun Microsystems, developers of the Java programming language and runtime environment, to describe software that acts as an interface between compiled Java binary code and the microprocessor (or "hardware platform") that actually performs the program's instructions. Once a Java virtual machine has been provided for a platform, any Java program (which, after compilation, is called bytecode) can run on that platform.

Distributed Computing

Distributive computing can be thought of breaking down an application into individual computing agents that can be spread out over a network of computers, working together to do cooperative tasks. Distributed computing or applications are often used to solve the following types of problems. Computing things m parallel by breaking a problem down into smaller pieces enables users to solve large problems without resorting to large, bulky, expensive computers, by distributing the tasks among many smaller networked computers. Certain applications may be so computationally demanding that no single computer can perform the computations necessary in a reasonable timeframe, however the same task may be distributed across a network of computers for adequate speed. Redundant processing agents on multiple networked computers can be used by systems that need fault tolerance. For example, even if a machine crashes, the ob can continue on a redundant processing agent. Produces systems that can handle increased workload without being redesigned.

A distributed application is built upon several layers. At the lowest level, a network connects a group of host computers together so that they can talk to each other. Network protocols like TCP/IP let the computers send data to each other over the network by providing the ability to package and address data for delivery to another machine. Higher-level services can be defined on top of the network protocol, such as directory services and security protocols. Finally, the distributed application itself runs on top of these layers, using the mid-level services and network protocols as well as the computer operating system to perform coordinated tasks across the network.

At the application level, a distributed application can be thought of as being made up of multiple computing "Agents", whose actions are coordinated such that they work together to accomplish some goal. These agents can be thought of as being significant and self contained functional elements of the overall application or system. They may be distributed across multiple hosts and may comprise multiple programs and/or objects, each one communicating with one or more agents on the same or different machines.

A distributed application can be thought of being made up of processes, objects and agents. A process is a running program on a host computer. Resources (such as CPU time and I/O devices) needed for the program to do its work are provided through the computers operating system. Objects are a made up of a set of data, methods which perform operations on the set of data belonging to the object. A process can be made up of one or more objects. Agents are a functional element of a distributed application. Eacn agent may comprise of multiple objects and/or processes. Agents perform specific objectives for the distributed application, e.g., an agent may search and analyze information contained in a database.

Object orientation improves software maintainability and reduces development costs by managing the intellectual complexity of modern software systems, while distributed processing makes available far more computer power to solve complex problems at high speed. Both technologies improve the scalability of systems by allowing components to be changed or added without redesigning other components.

While networks, the Internet, distributed computing, object-oriented programming, virtual machines, and Java, have increased the computer power available to computer users, the present state of the art still constrains how readily computers can be interconnected to perform cooperative tasks, and the ease and expense of using them, managing them, and developing software for them.

This invention addresses the following constraints and limitations. First, traditional networks limit accessibility to provide for security. Because networks transmit information in easily readable packets, network security is best maintained by controlling access to network and the packets transmitted over it. User access to networks is thus limited to devices physically connected to the network or to specified remote access venues. Second, network software is typically device specific. This is because application software has been developed for end user device operating systems. Network operating systems have acted primarily as routing and communication extensions of device operating systems. If a new type of electronic device is developed, it generally is introduced with a new type of operating system. To run on the new device, existing applications need to be rewritten to run on the new operating system. This process is called porting an application. If the new device needs to be connected to a network, the network operating system needs new extensions to connect the device to the network and handle its network communication needs.

Third, existing network operating systems were not designed for large-scale integration. They have evolved from the model of a single server connecting a limited number of clients. This leads to a number of constraints. To start with, each additional server must be configured to communicate with the rest of the network; servers cannot just be plugged m. The configuration of the network requires careful planning and design, and the standardization of naming and pointing conventions to make understanding the network possible. Much end user education is required to enable users to specify the paths to the network resources they access. The migration of network resources is extremely complicated, as all user paths to these resources need to be remapped. In most instances it is not possible to be certain which users have access paths to the resources being migrated.

Globalization has added to the seriousness of these constraints by increasing network size and complexity and by eliminating time periods wnen network maintenance can be scheduled without user inconvenience. There are no globally recognized holidays or weekends especially since it is never the same day everywhere on the globe. Network administrators have been forced into providing abundant electronic device redundancy to overcome their inability to reroute services for the purposes of load balancing or scheduled maintenance.

Fourth, the potential of another network model, the Internet, is vastly underutilized. It is the global network, far greater in size than any private network. However, the legacy of the Internet is that it was designed for information exchange, not for data manipulation. The three most common uses of the Internet are browsing, message exchange (e.g. e-mail), and chatting. In all three cases, static information is either collected or distributed. There are commercial web sites, but the user's ability to manipulate them is limited by the commercial purposes of each site, which can be viewed as a structured form of information exchange. By and large, users cannot use the Internet the way they would use a LAN. The Internet lacks the operating system software and security services to allow users to run applications or access a large space for personal or shared data storage.

Fifth, this under utilization of the Internet's potential will increase as Internet communicability becomes a common property of many consumer devices, like personal digital assistants or PDAs, cell phones, and television sets. Manufacturers are including Internet awareness in these devices because the Internet is such a ubiquitous communication medium. However, these devices will only use the Internet in the limited ways their manufacturers envision. An Internet aware television, for example, may receive television signals over the Internet as an alternative to broadcast or cable reception. If every TV became Internet capable, the usage of the Internet would greatly increase. However, its utilization would remain as stunted as it is today because these electronic devices lack the ability to perform data manipulation, in the same fashion that computers use private LANs and WANs today. Until new software is developed, these capabilities remain potentials.

Sixth, the current paradigm of application software distribution constrains both users and developers, even when the software is freely distributed. Presently, most application software has to reside on the device that accesses it. This requirement imposes three limitations on devices that need applications software. First, they have to have sufficient storage to accommodate all the applications their users wish to use. Second, software nas to be device specific. New classes of devises require new versions of applications software. Not only do different classes of electronic devises differ in their internal architecture, but for each device there may be an array of optional components which may or may not be present. So not only must a different version of a software application be developed for each device class, the software must be custom installed or configured for each individual device. The third limitation is the inhibition this constraint places on software innovation. Many users avoid upgrading their applications because they find the upgrade installation and configuration process daunting.

This reluctance to adopt new software constrains other adopters, especially when version compatibility is an issue. Users own individual copies of applications software and exchange information formatted by those applications, such as documents, spreadsheets, and e-mail. In order to provide an ever-expanding suite of new features, many applications must be changed so radically that new versions store user data in file formats that older versions cannot recognize. In these cases, the fact that many users are disinclined to upgrade their applications prevents a large number of other users from upgrading. These users may want to upgrade, but they cannot. If they did upgrade, they would no longer be able to share information with users who had not upgraded.

This constraint on innovation is present even when applications software is distributed for free. Currently, both major Internet browsers are given away free of charge. In addition, many plug-in improvements to these browsers that enhance their video or audio performance, are readily available as free downloads from the Internet. Yet many users do not trouble themselves to upgrade their browsers or download the plug-in enhancements. This user behavior limits the deployment of new technology on the Internet and the Web. Many commercial sites still do not use frames (less than full page presentation areas) because a large installed base of older version browsers cannot make sense of them, even though browsers that can utilize frames were first introduced three years ago.

SUMMARY OF THE INVENTION

One of the objects of the present invention is to provide a collaborative virtual network operating system that would provide a uniform application interface and allow application developers to create applications that would not need to independently address the native processor or operating system of any device.

Another object of the invention is to provide a security framework within a collaborative virtual operating system that would allow the Internet to be used for data storage and application processing. Another object of the invention is to eliminate the need for devices to have mass storage to accommodate network operating system software, application software, and user or member data.

Another object of the invention is to provide secure inter device communications.

In accordance with these and other objects of this invention, there is described a method of permissioning a member access to a collective established on a network. The network includes a plurality of computers. Each of the plurality of computers has a memory and is connected to the network, and includes node software comprising a plurality of parts. The parts are distributed across and stored in the memories of selected of the plurality of computers. The computers execute the node software to implement a plurality of services. These services include routing services, storage services, security services, administrative services and application services. The storage services include a list of member profiles, one for each member permissioned for access to the collective. First a member's computer device is connected to the network to transmit an identification of the member to the security services. Then, the security services permissions the member by comparing the member's authentication information with a list of authentication informations of those members permitted access to the virtual collective. If the member is permissioned, the member profile of the permissioned member is downloaded from the security service and provides the member's computer device access to the collective.

In another aspect of this invention, a reconfigurable collective is established upon a network. The network includes a plurality of computers. Each of the plurality of computers has a memory and is connected to the network. The collective comprises node software, which comprises a plurality of parts. The parts are distributed across and stored in the memories of selected of the plurality of computers. The selected computers execute the distributed software parts to form the collective, whereby each distributed software part becomes a node of the collective. A collective administrative system that selects and transmits one of a plurality of objects to designated ones of the collective nodes, whereby each of the plurality of objects sets the particular configuration of its designated collective nodes .

In a still further aspect of this invention, a collective is adapted to be accessed by a member's computer device. The member's computer device includes a device memory and a device program stored in the memory. The device program runs on the member's computer device to generate and to apply to the collective a member's message bearing an I.D. indicative of the member. The collective is established on a network, which includes a plurality of computers. Each -of the computers has a network memory and is connected to the network. The member's computer device has a given processing power that is limited in comparison with the processing power of the collective. The collective comprises a node software, which includes a plurality of parts, that are parts distributed across and stored in the memories of selected of the plurality of computers, and a plurality of computers that execute the node software to implement a plurality of services including security services, storage services and other services. The collective includes security services which respond to the member's message to compare its I.D. with a list of I.D.s of members who have been granted permission to access the collective. If there is a match, a profile is downloaded from the storage services and is applied to the member computer device, whereby the profile instructs the member's computer device to download an interface from the collective bearing an indication of those services that may be accessed by the member. Thus, the member may access the services selected from the interface.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A depicts a generic electronic device capable of communicating with a network;

FIG. IB shows two computers and an electronic device connected to a network;

FIG. 2 shows several networks linked together to form a wide area network, or WAN;

FIG. 3 is a conceptual depiction of a Collective, a logical or virtual entity formed from groups of computers running node software and communicating with one another with interdependent services;

FIG. 4 illustrates a node manger, a software component that runs on the computers running node software;

FIG. 5A shows a configured Client Node;

FIG. 5B shows a configured Service Node;

FIG. 5C shows a configured Broker Node;

FIG. 6 illustrates a pouch, a messaging object used in the transport of data and applications between collective components;

FIG. 7 illustrates the services that make up a Collective and the components that make up the individual services; FIG. 8 shows several Collective nodes and the course of a pouch between an applet of a client node and the service of a service node;

FIG. 9 shows seve-i-ai Collective nodes and the course of a pouch between the service of one service node and another service on a different service node;

FIG. 10 shows several Collective nodes and the course of a pouch between an applet on one client node and another applet on a different client node;

FIG. 11 shows that the administrative service component, the registrar is comprised a number of modules that communicate with each other via a central component, the engine, and shows the registrar's links with other collective elements and with Universal Time Co-ordinate (UTC) time servers on the Internet;

FIG. 12 shows all the possible routes that the pouch can take within a collective. This can be seen from the perspective of the registrar and is called the PCM (pouch communications mechanism) view;

FIG. 13 illustrates how collective components are managed. It can also be seen from the perspective of the registrar, and is called the ACM or administrative communications mechanism view;

FIG. 14 shows the components of the collective seen from the persistence manager service and is called a PM view, and shows the components of the collective visible to a member, and illustrates how a member view is a subset of the persistence manager or PM view; FIG. 15 shows how every running software component in the collective can be seen from a session manager, and is called a session manager view and

FIG. lβ is a graphical representation of the entire collective. It is called the Universal Model, and it shows the interrelationships among the five views illustrated in FIGs. 12 through 16.

List of Reference Numerals 20 computer

21 physical storage media, or hard disk

22 software

23 generic electronic device

24 network connection of a computer

25 central processing unit, or CPU

26 network

27 electronic memory

28 router

29 network interface

30 digital data communication link

32 WAN, or wide area network

33 input/output or I/O device

34 node

34a client node b service node

c broker node

collective

routing services

storage services

security services

administrative services

member services

node manager

management communication plug-in

UTC time plug-in

log plug-in

configuration object

software components

foundation container

container

applet

distributor

service manager

services

apersistence manager service 70b session manager service

70c authentication service

70d registrar service

70e third-party service

72 broker component

74 pouch

76 pouch header

78 pouch body

80 pouch footer

82 routing label

84 information component of pouch header

86 JEMStone

88 PCM links

90 ACM links

94 member links

96 session links

98 engine

100 plug-in sub-components of the registrar

100a ACM queue manager

100b PCM queue manager

100c time plug-in lOOd error logs plug-in

lOOe event logs plug-in

lOOf configuration plug-in

lOOg security plug-in

lOOh storage plug-in

lOOi third-party plug-in

102 UTC time server located on the Internet

104 directory

104a "root" directory

104b Logs directory

104d Applications directory

104e R directory

104f Members directory

104g member 1

104h member 2

104i member 3

104j member 4

104k sessions directory

1041 files directory

104m sessions directory

104n session 1 104o session 2

104p session 3

105 member view of the collective

108 file

DESCRIPTION OF THE PREFERRED EMBODIMENT

FIG. 1A shows a generic electronic device 23 capable of interfacing with a network. The generic electronic device 23 is meant to illustrate a variety of present and future devices that can connect with other electronic devices via a network 26, as shown in FIG. IB. The network 26 can be any of an assortment of network types, including a local area network, a wide area network, an intranet or the Internet. The electronic device 23 comprises a central processing unit 25, an input/output or I/O device 33, some form of memory 27, and a network interface 29. A computer 20 is a more detailed instance of the electronic device 23. However, it can also be a wide variety of other devices, including a television set with modem or cable modem connectivity, a cell phone that is capable of communicating with the Internet, a home alarm or monitoring system that can communicate with a an alarm monitoring station, a personal digital assistant, or PDA. The only requirements for the current invention are a central processing unit 25, a means for I/O 33, memory 27, and a network interface 29.

FIG. IB shows a plurality of computers 20 and a generic electronic device 23 that are connected to the network 26. Each of the computers 20 is capable of running one or more software applications 22 in their memory and/or on their physical storage media 21 or hard disks. By using a connection 24, e.g., a modem, each computer 20 can connect to the network 26 using, for example, a telephone circuit. Alternatively, the connection 24 may take the form of a network interface card, which allows the computer 20 to be physically connected to the network or LAN 26 using a fiber optic cable or various types of copper-based cables. Other illustrative examples of the network connection 24 include wireless, microwave, and infrared. The software applications 22 running on the computers 20 and electronic device 23 if so designed, can communicate with the network 26 using the computer's connection 24 to the network.

FIG. 2 illustrates how computers 20 are connected together by a plurality of LANs 26-1,-2, ..n. The networks 26 are connected to each other by routers 28. The routers 28 are connected to one another by digital data communication links 30a, b, ...n, as are well known in the art. A combination of networks 26 connected to one another by routers 28 make up a wide area network or WAN 32. An illustrative example of the largest WAN 32 is the Internet. As shown in FIG. 2, computers 20 scattered on the WAN 32 running node software 34 can communicate with each other over their network 26 via cables to connect to other computers 20, performing in a distributive computing environment.

As shown in FIG. 2, groups of computers 20 and other electronic devices 23 running distributed node software 34 communicating with one another, form a logical or virtual entity called a collective 36 as shown in FIG. 3. When computers 20 and other electronic devices 23 are running node software 34, they become nodes 34 of the collective 36. The collective 36 is comprised of a collection of software implemented services 38-46, parts of which are distributed across one or more computers 20 on the network 26, each distributed part comprising one of the plurality of the pieces of the node software 34. As FIG. 3 illustrates, these services 38-46, can be broken up into five major categories: 1) software implemented routing services 38 that direct data within the collective 36 enabling users, or members, to use certain services, which in turn use other services; 2) storage services 40 that store and retrieve data that members or services may wish to access or store; 3) security services 42 that control access to the collective's services 38-46 and resources and restrict access for both members and services; 4) administrative services 44 that configure, start and stop services on the computers 20; and 5) member services 46 that are typically provided by third parties. Fax services or a Rolodex™ service are two illustrative examples of member services 46 that could be supplied within the context of the invention. Other types of services could be contact management, file access, calendaring, data base management, and LAN management, for example.

Two instances of the collective 36 are shown in FIG. 2. Each of the plurality of LANs 26a-n that are part of the WAN 32 comprises several computers 20 or electronic devices 23 that can communicate with each other on their own LAN 26. Each of these computers 20 may or may not have privileges to communicate with computers 20 on other LANs 26, within the WAN 32. In FIG. 2 computers 20-2e, 20-3a, and 20-4d are running respectively node software 34-2, 34-3, and 34-4, and form one instance of the collective. A second instance of the collective comprises computers 20-nc, 20-na, and 20-ld running node software 34-nc, 34-na, and 34-ld. Any of the other computers 20 or electronic devices 23 illustrated could potentially be part of either collective, but would have to start running node software 34 to do so. Of particular interest is LAN 26-1. This could be in an illustrative embodiment of this invention a LAN within a home. It comprises illustratively one computer 20-ld and four electronic devices 23-la, 23-lb, 23-lc, and 23-le. These devices 23 could illustratively be a PDA, a cell phone, a television, or a home security monitoring station. Were they to run node software 34, they would be part of the collective 36 too.

FIG. 4 illustrates a node manager 48, which is a sub-component of the node software 34 that runs on computers 20, as shown in FIG. 2, that make up the collective 36. The node manager 48 has three defined functions. First, the node manager 48 communicates with the administrative services 44 on the collective 36 over the network 26 and receives from the administrative services 44 configuration objects 56 containing configuration data for software components. The configuration object 56 contains configuration information for the node manager 48 and a set of other software components 58a, b...n or applications that the node manager 48 must manage. The configuration object 56, as will be described in detail below, is a software instruction set that instructs the node manager 48 what role it is to take on and how to perform that role. Second, the node manager 48 manages the software components 58 or applications under its control as defined by the configuration object. The node manager 48 retrieves software components 58 from the storage service 40, and starts, stops, and configures them. Third, the node manager 48 provides the software components 58 or applications under the node manager's 48 control with some basic services. The node manager 48 determines the collective or UTC (universal time coordinate) time 52, a standard synchronized time used throughout the collective 36 and all collective communications. The node manager 48 provides an event and error logging facility 54 that records, stores and forwards logs of events and errors that occur within the components 58 under the node manager's 48 control. These logs 54 are sent to the administrative services 44 on a periodic basis, as defined by the configuration object 56. If a critical error is encountered, the node manager 48 will send the critical error followed by all other logs 54 to the administrative services 44 immediately.

As shown in FIGS. 5A, 5B, and 5C, nodes 34 can be configured to be a client node 34a (FIG. 5A) , a service node 34b (FIG. 5B) , or a broker node 34c (FIG. 5C) . Each node's 34 role depends on which components 58 the node manager 48 is told to run by the configuration data stored in the configuration object 56. The configuration data is sent over the network 26 by the administrative services 44 as in FIG. 4.

Members use electronic devices 23 or computers 20 running node software 34 to access the collective 36. These nodes 34 are called client nodes 34a and are used by members to access the collective's services 38-46. The client node 34a is made up of four components. A client node 34a comprises a simplified node manager 48a responsible for starting one required component. The first is a foundation container 60, a subcomponent of the routing service 38 as shown in FIG. 7, which provides the basis for the communications between the components on the client node 34a and a service running in the collective 36 over the network 32, as shown in FIG. 4. The second component, a container 62, is the user's interface with the collective 36 and is downloaded form the collective storage service 40 based on a user's or member's preference settings or member profile. The container 62 typically provides members with mechanisms to access the collective's 36 resources. An applet 64 is downloaded from the collective storage service 40 and runs under the control of the container 62. An applet 64 is any software or service provided through the collective 36. Applets are illustratively produced by third parties and can include for example software like a Rolodex™ program, a word processor, a spreadsheet, a database, a Fax viewer, or a contact management program. One or more containers 62 can run on the client node 34a controlling one or more applets 64. Only for the duration that the member is logged into the collective 36, is the client node 34a active.

As shown in FIG. 5B, the service node 34b runs one or more of the collective's services: storage 40, security 42, administrative 44 or user 46 services. The service node 34b is made up of three required components 58 (FIG. 4) . The first component is the node manager 48b, responsible for starting a distributor component 66, a subcomponent of the routing services 38 as shown in FIG. 7 and a service manager component 68. The distributor 66 on the service node 34b communicates with other collective routing services 38, components 58 over the WAN 32, as shown in FIG. 2. The distributor 66 in FIG 5B sends data from the service manager 68 to the routing services 38, components 58 to another applet 64 residing on a client node 34a or to another service 70 via its service manager 68. This process is described in greater detail further below. Multiple service managers 68 can run on a service node 34b. These service managers 68 are responsible for managing one or more services 70. Examples of these services 70 are authentication services 70c, session manager services 70b, registrar services 70d, persistence manager services 70a, and third party services 70e, which are discussed below with respect to FIG. 7. Service managers 68 send data from one of the services 70 to the distributor 66 and from the distributor 66 to other nodes. Each of the service 70 may take the form of an application that performs a specific task, such as a fax service, Rolodex™ service, financial portfolio calculator, regional weather service, news service, or storage service 40. Each such service 70 communicates with a specific service manager 68.

A broker node 34c is among the simplest nodes. The broker node 34c is comprised of a node manager 4C and a broker component 72. The broker component 72 provides routing services 38, as described further below, within the collective 36. A plurality of client nodes 34a and service nodes 34b send and receive data across the collective 36. The broker component 72 receives the data over the network 26, as shown in FIG. 2, from a client node 34a or service node 34b and forwards the data to the appropriate recipient node.

The client nodes 34a and the service nodes 34b communicate with one another by creating and inserting the data into pouches 74 and sending them off to the routing services 38. As illustrated in FIG. 6, each pouch 74 comprises three pieces: the header 76, the body 78 and the footer 80. The header 76 is composed of two pieces: a routing label 82 and an information component 84. The routing label 82 contains the pouch's 74 route history, its following destination, and the pouch's 74 final destination within the collective 36. The information component 84 is a general storage location for miscellaneous data. The body 78 contains a JEMStone 86 which comprises the data and applications that client nodes 34a and the service nodes 34b send to one another via routing services 38, and components through the collective 36 over a network 26. JEMStones 86 are like postal letters. Just as letters get placed into envelopes, JEMStones 86 are placed into pouches 74 and are routed through the collective 36 to the proper destination, much like the Post Office routes private mail. Since JEMStones 86 are private exchanges among applets 64 and services 70, no collective 36 component is inherently capable of interrogating JEMStones 86. JEMStones 86 can contain, for example, data, applications, error information, control information, etc. The footer 80 contains information to ensure data integrity. The pouches 74 are sent through a pouch communications mechanism or PCM communications, the general means of communication throughout the collective 36. PCM communications links 88 are depicted in FIGs. 8, 9, 10 and 12. In PCM communications, routing services 38 are responsible for delivering pouches 74 to their correct locations and updating the pouch's 74 history.

Routing services 38 are provided by the core collective 36 components. As shown in FIG. 7, the routing services 38 are made up of three core collective 36 components, namely the foundation container 60 of FIG. 5A, the distributor 66 of FIG. 5B, and the broker 72 of FIG. 5C. The broker 72 is the primary routing layer. The distributor 66 and the foundation container 60 make up the intermediate routing layer. The broker 72 routes the pouches 74 between the distributors 66 and the foundation containers 60. The pouches 74 may be routed from the applet 64 to the service 70 or the service 70 to the applet 64 (FIG. 8), from one service 70 to another service 70 (FIG. 9) or from one applet 64 to another applet 64 (FIG. 10) .

FIG. 8, FIG. 9, and FIG. 10 show the same five nodes 34a-l, 34a-2, 34b-l, 34b-2, and 34c. These figures differ only in the pouch paths 88 they illustrate. Although only three nodes are needed in each figure, all five nodes are retained to illustrate the modularity and variety of the collective and to emphasize the key role of the broker node 34c in pouch communications.

FIG. 8 illustrates the PCM links 88 of the pouch 74, from the applet 64-1 of the client node 34a-l to the service 70-1 of the service node 34b-l vice versa. The applet 64-1 in the client node 34a-l forwards the data to the container 62-1. The container 62-1 puts the data into a JEMStone 86 in the pouch 74, as shown in FIG. 6, and sends the pouch 74 to the foundation container 62-1. The foundation container 62-1 then sends via one of the PCM links 88 the pouch 74 to the broker 72 of the broker node 34c. By referring to the information in the routing label 82, the broker 72 forwards the pouch 74 to the appropriate distributor 66-1 of the service node 34b-l. The distributor 66-1 determines the appropriate service manager 68-1 of the service node 34b-l from the information in the routing label 82 of the transmitted pouch 74 and sends the pouch 74 to the appropriate service manager 68-1. The service manager 68-1 then removes the data from the pouch 74 and forwards via link 88 the data to the service 70-1. To send the data from the service 70-1 of the service node 34b-l to the applet 64-1 of the client node 34a-l, the links 88 of the pouch 74 are simply reversed. The service 70-1 sends the data to the service manager 68-1, which places the data in the pouch 74 and forwards the pouch 74 to the distributor 66-1. The distributor 66-1 routes the pouch 74 to the broker 72 of the broker node 34c, which then routes the pouch 74 via link 88 to the appropriate foundation container 60-1. The foundation container 60-1 sends the pouch 74 to the appropriate container 62-1, which removes the data and forwards the data to the applet 64-1.

FIG. 9 illustrates how the PCM links 88 are interconnected to convey pouches 74 from the service 70-1 on the service node 34b-l to another service 70-2a or 70-2b on a different service node 34b-2. The service 70-1 on the service node 34b-l sends the data to the service manager 68-1. The service manager 68-1 places the data into the JEMStone of the pouch 74 and sends the pouch 74 to the distributor 66-1. The distributor 66-1 routes the pouch 74 according to the information in the routing label 82 of the header 76 to the broker 72 of the broker node 34c, which forwards the pouch 74 to the appropriate distributor 66-2 of the service node 34b-2. The pouch 74 is routed to the appropriate service manager 68-2a or 68-2b, which removes the JEMStone 86 containing the data from the pouch 74 and sends the data off to the service 70-2a or 70-2b. The procedure is simply reversed for alternate communication. The data travels from the service 70-2a or 70-2b to the service manager 68-2a or 60-2b, which packages the data into a JEMStone 86 of a pouch 74. The pouch 74 is sent by the distributor 66-2 via the broker 72 and the distributor 66-1 to the service manager 68-1, which removes the data from the pouch 74 and forwards the data to the service 70-1. When more than one service 70 is present on the same node, the pouch 74 follows a slightly different set of links 88. The service 70-2a sends the data to the service manager 68-2a, which places the data in the pouch 74 and sends the pouch 74 to the distributor 66-2. The distributor 66-2 routes the pouch 74 to the appropriate service manager 68-2b, which removes the data and forwards the data to the service 70-2b. This course of the pouch 74 is reversed to send the data from the service 70-2b to the service 70-2a.

FIG. 10 illustrates how the PCM links 88 are interconnected to transmit the pouch 74 from the applet 64-1 on the client node 34a-l to another applet 64-2a on a different client node 34a-2. The applet 64-1 on the client node 34a-l sends the data to the container 62-1. The container 62-1 places the data into the JEMStone of the pouch 74 and sends the pouch 74 to the foundation container 60-1. The foundation container 60-1 routes the pouch 74 using the information in the routing label 82 of the header 84 to the broker 72 of the broker node 34c, which forwards the pouch 74 to the foundation container 60-2 of the client node 34a-2. The pouch 74 is routed to the appropriate container 62-2a, which removes the JEMStone 86 containing the data from the pouch 74 and sends the data to the appropriate applet 64-2a. The procedure is simply reversed for th» return communication. The data travels from the applet 64-2a to the container 62-2a, which packages the data into a JEMStone 86 of a pouch 74. The pouch 74 is sent via the foundation container 60-2, the broker 72, and the foundation container 60-1, to the container 62-1, which removes the data from the pouch 74 and forwards the data to the applet 64-1. When more than one applet 64 is present on the same node, the pouch 74 follows a slightly different course. The applet 64-2a sends the data to the container 62-2a, which places the data in the pouch 74 and sends the pouch 74 to the foundation container 60-2. The foundation container 60-2 routes the pouch 74 to the appropriate container 62-2b, which removes the data and forwards the data to the applet 64-2b. This path established by the links 88 is reversed to send the pouch 74 from the applet 64-2b to the applet 64-2a.

The storage services 40, as shown in FIG. 7, are comprised of one or more service nodes 34b running a persistence manager service 70a. The persistence manager service 70a is the service 70 that accepts requests from the collective's 36 members and services 70 to create, modify, read, delete, copy and move files, directories, view links and grant member access permission. Upon accepting the request, the persistence manager 70a stores the request, along with the time and date, in one of transaction logs 54 of the service node's node manager 48b. The request or transaction is executed, and the data is stored or retrieved to or from the service node's 34b physical storage media 21, typically a hard disk drive as shown in FIG. IB. Once the transaction is completed, the acknowledgment of the transaction is sent back to the member or service 70 which issued the request. The transaction is then removed from the transaction log 54. To complete a request, the persistence manager 70a may need to access data residing on another persistence manager 70a. In that case, the persistence manager 70a will send a request to the other persistence manager 70a via PCM communications.

The security services 42 as shown in FIG. 7 have three broad functions: 1) the security services 42 validate the authenticity of members accessing the collective 36; 2) the security services 42 allow and restrict members' access to resources within the collective 36; and 3) the security services 42 allow members to view their outstanding tasks. The security services 40 are comprised of an authentication service 70c and a session manager 70b. The collective 36 contains one or more of each security service 42. The authentication service 70c allows the member access if the member I.D. and password, which a member enters from a client node 34a to access the collective 36, match an I.D. and password previously entered in an encrypted database or denies access if the member I.D'. and password do not match. Only the session manager 70b accesses the authentication service 70c. Each session manager 70b has three functions. First, login when a member logs into the collective 36 and his/her login request is sent to the session manager 70b, which in turn forwards the member I.D. and password to the authentication service 70c to validate the member. Upon successful validation, the authentication service 70c informs the session manager 70b to allow the member entry to the collective 36. Second, the session manager 70b allows other resources in the collective 36, such as the broker 72, to verify if the member is given access to the collective 36. Third, the session manager 70b allows members to view applications they are currently running in the collective 36. In particular, the session manager receives information from client notes 34a regarding which members are running or exiting which software components, i.e., applets 64-fa or containers 62-la, and creates objects in the session directory 104 for the members 104g in the persistence manager service 70a-l.

FIG. 7 also illustrates that the member services 46 are third party services 70e that are accessed by members of the collective 36 via PCM communications. Examples of member services 46 include an e-mail service, an area weather service, a contact management service, and a calendaring service. The member accesses his service 46 through an applet 64 on the container 62 of a client node 34a. Another example of a member service 46 is a Rolodex™ service where an applet 64 recalls names stored in the member's Rolodex™. This example also shows how the member services 46 can utilize the collective's core services 38-42. The Rolodex™ service stores the member's data in the persistence manager 70a of the storage services 40. Once the member requests a Rolodex™ entry, the request is sent to the Rolodex™ service, which runs a service node 34b using the routing services 38. The security services 42 verify the member's I.D. in order to allow access to this service 70.

The administrative services 44 are responsible for managing the collective's services 38-46 and member access to the collective 36. As shown in FIG. 7, these tasks are performed by a specialized service 70 called the registrar 70d. The collective 36 may contain one or more registrars 70d for load balancing and redundancy. Each node 34 in the collective 36 is assigned to a specific set of one or more registrars 70d. The node manager 48 residing on each node 34 is responsible for sending and receiving data to and from the registrar 48. The node manager 48a-l of each client node 34a sends event and error logs 54 to the registrar 70d as shown in FIG. 4 via PCM communications. The node manager 48b-l as shown in FIG. 5B of each service node 34b and the node manager 48c of each broker node 34c send and receive administrative information to and from the registrar 70d. First, each node manager 48 receives the configuration object 56 containing configuration information from the registrar 70d. The administrative configuration information includes 1) node 34 configuration information, such as whether the node will act as a broker node 34c or client node 34a or service node 34b; 2) the components 58 the node manager 48 needs to run (for example, if it is a service node 34b, it can run a service manager component 68 (see FIG. 5B) , a distributor component 66 (see FIG. 7), and several individual services including another registrar service 70d, a persistence manager service 70a, a session manager service 70b, and an authentication service 70c); and 3) the component 58 (see FIG. 4) state commands, such as starting, stopping or suspending a set of components 58. For example, the registrar service 70d might request a service node 34b to start, suspend, or stop individual applications and services, and other nodes would be instructed to maintain logs 54 of their activities. Second, each node manager 48 determines the collective or UTC time 52 by passing time information between the node manager 48 and the registrar 70d. The time information takes the form of time stamps. Each node manager 48 uses the time stamps to determine the difference between the local time on the computer 20 that the node 34 is running on, shown in FIG. 2, and the collective time, as determined by the registrars 70d subcomponent time plug-in 100c as will be explained with respect to Fig 11. This calculation of the time difference or offset is performed by the node managers 48 time plug-in 52 as shown in FIG. 4. The time offset is calculated through the use of algorithms and allows each node manager 48 to determine the collective time 52 by subtracting the time difference from the local time of the computer. Third, each node manager 48 sends event and error logs 54 to the registrar 70d. These three forms of data exchange between the node manager 48b of each service node 34b and the node manager 48c of each broker node 34c and the registrar 70d occur via the administrative communications mechanism or ACM communications illustrated in FIGs. 13 and 16. ACM communications are a simpler form of communications than PCM communications. ACM communications are point to point, eliminating the use of the pouch 74 and the routing services 38.

FIG. 11 illustrates the registrar 70d, comprised of multiple sub-components. The central sub-component is an engine 98. The engine 98 facilitates data exchange between other sub-components of the registrar 70d. The other sub-components are multiple plug-ins 100, since the other sub-components communicate in a well-defined, standardized method via the engine 98. One plug-in 100 cannot communicate with another plug-in 100 directly. The engine 98 is capable of many simultaneous transactions, and allows the collective 36 to be configured to any size or functionality needed. For example, if additional data storage is needed by the collective 36, additional storage plug-ins lOOh might be added to manage these resources. Alternatively, third parties may supply the collective 36 with new functionality such as a contact management service, a data base service, or a local weather service. Each such new service potentially may have a plug-in lOOi to manage its functionality. Plug-ins 100 can be added and removed from a live collective 36 without the need to interrupt the operation of the collective 36. Each plug-in 100 may communicate with other resources outside of the registrar 70d. These resources include software components 22 within or outside of the collective 36, network resources or the host computer's resources. Pluralities of plug-ins 100 are used to manage and use specific collective 36 components and resources.

As FIG. 11 illustrates, there are eight different types of plug-ins 100. The ACM queue manager 100a sends and receives data to and from each service node 34b and broker node 34a via ACM communications. The PCM queue manager 100b sends and receives data to and from the collective 36 via PCM communications. The time plug-in 100c communicates with a UTC time server 102 on the Internet using UTC time protocols to ensure the exact time. The time plug-in 100c then provides each service node 34b and each broker node 34c with the correct collective or UTC time 52 through the time stamp exchange. These communications are sent from and received by the ACM queue manager 100a via ACM communications. There are two different log plug-ins 100, one for error logs lOOd and one for event logs lOOe. The two log plug-ins lOOd-e receive error and event logs 54 from the node manager 48a-l of each client node 34a through the PCM queue manager 100b via PCM communications, and from the node manager 48b-l of each service node 34b and the node manager 48b-3 of each broker node 34c through the ACM queue manager 100a via ACM communications. The log plug-ins lOOd-e process the errors and events and notify other plug-ins 100 when necessary. For example, if a large number of log-in attempts have been made from a single device 23 without a successful member verification, this information would not only be logged, but the system administrator would be notified of the situation. Error and event logs 54 are sent to the storage services 40 of the collective 36 by the PCM queue manager 100b via PCM communications. The configuration plug-in lOOf assembles configuration objects 56 in the registrar 70d and then sends the configuration objects 56 via the ACM queue manager 100a and its ACM communications to various nodes, as shown in FIG. 13. The configuration objects 56 are instructions to each node 34 on what role it is to play in the collective 36. From the configuration object, the node manager 48 determines whether it is to act as a client node 34a, a broker node 34c, or service node 34b, and how it is to manage the collective components it controls. The security plug-in lOOg creates and modifies user I.D.s and passwords for collective 36 members and stores the user I.D.s and passwords in the storage services 40 of the collective 36 by use of the PCM queue manager 100b via PCM communications. The security plug-in lOOg also provides session I.D.s to the configuration plug-in lOOf for starting new service nodes 34b in the collective 36. Each service node 34b running in the collective 36 must have a valid session I.D. created by the security plug-in lOOg. The storage plug-in lOOh generates that portion of the configuration object 56 specifically associated that part of the persistence manager service 70a that is associated with a physical storage media 21 of a computer 20. This configuration information is then sent to the configuration plug-in lOOf where it is incorporated in the configuration object 56 for the service node 34b running the persistence manager service 70a. The third party plug-ins lOOi allows optional or custom third party services 70e to be added to the collective 36. The third party service plug-in lOOi generates the configuration information for the custom services 70e. The configuration information is then sent to the configuration plug-in lOOf where the configuration information is incorporated in the configuration object 56 for the service node 34b running the third party service 70e.

The registrar 70d is comprised of all the above mentioned sub-components 98-100i. The subcomponents 98-100i allow for the complete monitoring and management of the collective 36. The registrar 70d is able to manage other registrars 70d. However, a registrar 70d is simply a service 70 running on a service node 34b, since registrars 70d resides on selected service nodes 34b and communicates via the PCM links 88 shown in FIG. 12. The registrar 70d and all of the registrar's 70d sub-components 98-100i are managed by one of the applets 64, which is typically provided by the administrator's user interface for monitoring and configuring the components of the collective 36. The registrar 70d user interface presents the system administrator with six distinct views of the collective.

PCM and ACM communications are illustrated in FIGs. 8, 12, and 13. The links shown in FIG. 8 and FIG. 12 are the same, i.e., they are PCM 88 links. FIG. 8 shows one possible PCM path from an applet 64-1 to a service 70-1. FIG. 12 shows all possible PCM links 88 for a particular instance of the collective 36. FIG. 12 represents member data flows and is a PCM view of the collective 36. FIG. 13 is an ACM view of the collective 36 and represents all possible pathways of the administrative communications mechanism (ACM) for the transmission of configuration objects 56, and administrative data such as logs, in a particular instance of the collective 36.

Two client nodes 34a are represented in FIG. 13. They are represented by node managers 48a, foundation containers 60, containers 62, and applets 64. Client nodes 34a are only capable of PCM communications. Yet the node managers 48a are administrative components of the client nodes 34a. They must occasionally transmit logs and other administrative information to registrars 70d. To do this, the node manager 48a-l acts as an applet 64 and transmits the log or other administrative information to container 62-la, which passes it on to foundation container 60-1. The foundation container 60-1 places the log or other administrative information as a JEMStone 86 in a pouch 74 and composes a header 76 to route the pouch to registrar service 70d-3 via broker 72-1 and PCM links 88. The registrar service 70d accepts the data via its PCM queue manager plug-in 100b and passes it to the engine 98 for processing as shown in FIG. 11.

PCM communications represent all the possible pouch 74 communications between the components of the collective 36. FIGs. 8-10 represent the routes that the pouch 74 takes within the collective 36. All the components of the collective 36 capable of PCM communications are drawn on a single diagram shown in FIG. 12, and are connected to one another via permissible pouch 74 transfer. This illustrates all the possible courses of pouch 74 travel within the collective 36. This diagram is known as the PCM view.

A member might use the collective 36 to access the service 70e in the following manner. First, the member would use an electronic device 23 as shown in FIG. 1A or a computer 20 as shown in FIG. IB. The member would interact with the device via some input/output or I/O device 33. If the device 23 were a PDA, the I/O device 33 could illustratively be a touch screen and stylus. If the device 23 were a cell phone, the I/O device 33 could illustratively be a key pad, but could also include the processors that translate the member' s analog voice sounds into a digital signal and translate incoming digital signals into analog voice sounds for the member to hear. If the member were using a computer 20, the I/O mechanism could illustratively be a keyboard, mouse, and screen combination. Other devices 23 would have other I/O devices 33. This example assumes the member is using either a computer 20 or an electronic device 23 such as a PDA.

In both the device or the PDA 23 and the computer 20, some portion of the screen would display the container 62 of the client node 34a. The container 62 is a member interface to the collective 36. On a screen (not shown), it could be a graphical interface like a window or menu bar in which different icons may represent access to a member's data files 108, as will be explained with respect to FIG. 14, and services 70. Before a connection was established with the collective 36, however, the node software 34 would only display an icon for the collective 36. The member would click on the icon and be prompted to supply a member I.D. and password, to allow access to the resources contained within the collective 36 that the member wishes to access.

This feature of the invention means that the programmed device 23 or the client node 34a requires a minimal amount of software, just enough to ask for a member I.D. and communicate the log-in request to the collective 36. All the other software the member needs, i.e., node software, application software, and data files, are downloaded from the collective 36 upon successful log-in. The collective 36 can thus operate in very small devices 23. The devices 23 need no large permanent storage, just sufficient memory for running the member's applications.

As can be seen in FIGS. 7 and 12, the member I.D. and password are sent via PCM links 88 from the container 62-2 to the session manager service 70b-2 of the security services 42 (FIG. 7) via the routing services 38. Specifically, the container 62-2 transmits the member I.D. and password to the foundation container 60-2, which places them in a pouch 74 and transmits the pouch 74 to the broker 72-2, which transmits it via distributor 66-3 and the service manager 68-3 to the session manager service 70b-2. The session manager service 70b-2 retrieves the member's profile from the persistence manager 70a-3 (FIG. 12) of the storage services 40 (FIG. 7). The session manager service 70b-2 (FIG. 12) then asks the authentication service 70c-2 of the security services 42 (FIG. 7) to authenticate the password. The authentication service 70c-2 validates the member and notifies the session manager service 70b-2, which generates a session I.D. and transmits this back to the foundation container 60-2 via the service manager 68-3, the distributor 66-3, and the broker 72-2. At the same time, the session manager service 70b-2 accesses the member's container 62-2 from the persistence manager service 70a-3 and sends it to the foundation container 60-2, providing the member with the same interface to the collective 36 that the member is accustomed to. This could be a graphic interface like a window or menu bar with icons for all the applications the member was authorized to run and icons accessing all the member's files.

In the case of a member using a computer 20 or PDA, authentication confirmation would most likely use a password. However, depending upon the I/O capabilities of the device 23, authentication could be effected by voice recognition, a retinal scan, fingerprint, or any other unique and secure identifier.

If the member chooses to access a Rolodex™ service, the member would click on or point to the icon displayed by the graphic interface for that service within his/her container 62 of his client node 34a-2. In this example, it is assumed that the Rolodex™ service is a client/server application which provides the member with an interface for locating, viewing, creating, and editing records, while the bulk of the application operates on the collective 36 and all the data resides there as well. Other applications, like word processors, could be downloaded to the memory 27 of the client device 23.

As shown in FIG. 8 and FIG. 12, the container 62-la of the client node 34a-l would generate a request for the Rolodex™ applet and pass it to the foundation container 60-1. The foundation container 60-1 would package the request as a JEMStone 86 in a pouch 74 and pass it on to a broker 72-1. The broker 72-1 would forward the pouch 74 to the persistence manager service 70a-l via the distributor 66-1 and the service manager 68-1. The broker 72-1 would first check that the member had authorization to contact the persistence manager service 70a-l, before passing the pouch 74 to the distributor 66-1 of the service node on which the persistence manager service 70a-l is running. The persistence manager service 70a-l would check to determine that the member was authorized to access the Rolodex™ applet or service 70e-2a, and if so, access the Rolodex™ service 70e-2a and send this service or applet to an applet 64-la via the service manager 68-1, distributor 66-1, broker 72-1, foundation container 60-1 and container 62-la. The applet 64-la would then become the member interface to access information stored in the Rolodex™ service. If the member were querying the Rolodex™ service via the applet 64-la for a phone number, the member would have a screen that would allow him/her to enter or find a name.

This data, i.e., the name of the person whose phone number the member wanted, would then be transmitted back to the Rolodex™ service 70e-2a via the container 62-la where it would be incorporated in a pouch 74, forwarded via the foundation container 60-1, the broker 72-1, and the distributor 66-1 to the service manager 6«-l. Tne poucn' s 11 contents, i.e., the JEMStone 86 (FIG. 6) would be passed to the Rolodex™ service 70e-2a. The Rolodex™ service would then find the desired phone number and return it to the member in another pouch 74 via the same set of PCM links 88.

In FIG. 12, there are two instances of a Rolodex™ service, 70e-2a and 70e-2b. In a robust collective 36, there might be more. The broker 72-1 is capable of communicating with any of them. The broker 72-1 acts like a dispatcher or traffic policeman. In addition to checking whether members have authorization for the requests they make, the broker 72-1 has the ability to choose the most available instance of a requested service. If Rolodex™ service 70e-2a were slow to respond, or off line, or if distributor 66-1 or service manager 68-1 failed to respond, broker 72-1 would automatically route the Rolodex™ service requests to Rolodex™ service 70e-2b.

It is important to note that the member is shielded from any of the complexity of the collective 36. Members have access to data only via member links 94 shown on FIG. 14 as dot-dashed lines. A member mainly sees his/her container 62, or interface and the applets 64 that he/she has running. He/she can also see his/her files directory 104 and the files 108 therein. If desired, the member could query his/her sessions directory 104k to view and manipulate his/her sessions. For example, from container 62-la, which runs applets 64-la, 64-lb, and 64-lc, the member could query the sessions directory 104k and see containers 62-lb and 62-2 and the applets they are running. The member could get a status report from applet 64-3b or shut it down, even though container 62-2 was on a device 23 or a computer 20 disposed in a different location. The management of the collective 3b is merarcnica . This hierarchy is represented by the ACM view illustrated in FIG. 13. In FIG. 13, the registrar service 70d-l is the uppermost management component. In each service node 34b and each broker node 34c (not shown in FIG. 13) , the node managers 48b-l and 48b-3 communicate directly with the registrars 70d-3 and 70d-2 (not shown in FIG. 13) , respectively via ACM communication links 90. It is configuration information from the registrar services 70d that controls the broker 34c and service nodes 34b and the services they run. Client nodes 34a-l and 34a-2 are not configured by registrars 70d and do not communicate with them directly. Client nodes 34a-l and 34a-2 mainly use PCM links 88, as their primary purpose is member data manipulation. FIG. 13 shows not only the ACM communications over links 90 between the plurality of the registrars 70d and the plurality of the node managers 48, but also the distribution of the configuration information from the plurality of the node managers 48 over the PCM links 88 to the components and sub-components of the collective 36.

Although the client node 34a-l does not communicate directly with the registrar 70d-3, its node manager 48a-l is an administrative component of the client node 34a-l and needs to send management communications, such as logs, to the registrar 70d-3. It does this by posing as an applet 64 of the container 62-la or 62-lb and informing the foundation container 60-1 that it has data to transmit. The foundation container 60-1 can only perform PCM communications, so it takes the data from the node manager 48a-l and places it in a pouch 74 and routes it to the registrar 70d-3 through the broker 72-1 and the PCM links 88.

By limiting client nodes 34a-l and 34a-2 to PCM communications, the client node 34a-l and 34a-2 and spared the computational overhead of managing two αirrerent communications systems. It is also a much more secure network device. As explained above, PCM communications are a secure communication mode, since none of the routing software on the collective 36, brokers 72 and distributors 66 are capable of reading the contents of the pouch 74. By having only this one secure mode of communicating, client nodes 34a are much more acceptable as devices to be used on the secure side of firewalls. Most corporate security managers would look in askance at devices that required two means of communication through the corporate firewalls.

There are four other fault tolerant operations that the collective 36 performs without the knowledge of the member. As shown in FIG. 12, if one of the brokers 72-1 or 72-2 becomes unavailable to the foundation container 60-1 of client node 34a-l, the foundation container 60-1 automatically attempts to connect to the next available broker 72 from a list of available brokers 72 that the foundation container 60-1 is configured to use. Once the client node 34a-l connects to another broker 72-2, the broker 72-2 does not know if the client node 34a-l is validated to the collective 36. The broker 72-2 does not forward any information to the services 70. The broker 72-2 sends the client node's 34a-l information to the session manager 70b-l of the security services 42 (FIG. 7), and asks the session manager 70b-l if the client node 34a-l has a valid session I.D. If the client node 34a does have a valid session I.D., then all communications proceed as normal.

Service 70 replication ensures that if one service 70 becomes unavailable, there is another instance of that service

70 running in the collective 36. The collective 36 may have multiples of the same service 70 running, e.g., authentication services 70c-l and 70c-2, as shown in FIG. 12. If the service 70 becomes unavailable, the request is forwarded to the next available service 70.

The collective 36 guarantees storage of data. FIG. 12 shows that data is routed from the foundation container 60-1 of the client node 34a-l to the broker 72-1 where its sent to two different instances of the persistence manager service 70a-l and 70a-2. Each of the persistence manager services 70a-l and 70a-2 copies the data into its transaction log. From the transaction logs, the data is saved on the physical media storage 21 shown in FIG. 1 of each persistence manager service 70a-l and 70a-2. Each of the persistence managers 70a-l and 70a-2 notifies the other that the data has been stored. Then each of the persistence manager services 70a-l and 70a-2 sends an acknowledgment back saying that the notification has been received and also forwards the acknowledgments via the broker 72-1 to the client node 34a-l via its foundation container 60-1. If this process is not completed, an error log 54 is generated and sent to the registrar 70d.

The management of the collective 36 is also fault tolerant. FIG. 13 shows three registrar services, 70d-l, 70d-2, and 70d-3. In this configuration, registrar service 70d-l is the root or primary registrar service and can give administrative instructions to the rest of the collective 36 via registrar service 70d-2, and through it to registrar service 70d-3, and all the nodes and services they control. Should registrar service 70d-3 fail, its responsibilities would be assumed by registrar service 70d-2, and should that fail, registrar service 70d-l would assume full control of the collective 36. In such a case, if more nodes could not be immediately added to the collective, registrar service 70d-l would immediately send configuration objects 3b to tne nuut--- managers 48b-4 and 48b-2 to have them create other registrar services 70d. Alternatively, registrar service 70d-l could fail. In this case, its responsibilities would be assumed by registrar service 70d-2.

FIG. 13 also illustrates that registrar services 70d, like all services 70 run under the control of service managers 68. Even though registrar service 70d-l is the primary service for the administrative control of the network 32, it is a creation of service manager 68-1. Similarly, registrar service 70d-2 is a creation of service manager 68-2b and registrar service 70d-3 of service manager 68-3.

FIG. 14 illustrates an inverted tree directory structure for storing and retrieving data objects within the collective 36, and how the directory structure is linked via persistence manager (PM) links 94 to the persistence manager service 70a of the storage services 40 (FIG. 7). This is the persistence manager 70a or PM view of the collective 36. In the discussion of PCM and ACM communications in FIG. 12 and FIG. 13, the role of persistence manager service 70a in controlling access to applications and files was mentioned, but the details were left out to clarify AMC and PCM communications .

The persistence manager service 70a-l saves and retrieves a plurality of files 108 and applications, tracks their locations, and tracks which members 104g-j are associated with them. If a portion of the hierarchy, from a file to several branches within the tree, needs to be moved from one physical device to another, the persistence manager service 70a is responsible for maintaining the abstract directory hierarchy, so that the data objects can be accessed from within the collective 36 in a consistent and reliable fashion. Still referring to FIG. 14, member view 105g illustrates an object hierarchy for a member 104g. There are shown files 108, the files directory 1041, and a sessions directory 104k which is a view of the applets 64, containers 62, and sessions 104n-o, which the member is running on the collective 36. Member's view 105g of the collective 36 is also a subset of the persistence manager service 70a as shown in FIG. 14. Typically, a member interacts with the collective 36 via a container 62, which is member interface software running on a node 34. A window is an example of a container 62. Within the container 62 are access icons for a member' s 104g applets 64-la to -3b, and an interface for access to his files 108. It is important to note that when applets 64 or files 108 are invoked by means of a graphical interface, the user, e.g., the member 104 in the case of the collective 3b, is freed from being required to know the physical location of the objects being invoked. Within the collective 36, the mapping of storage locations is handled internally by brokers 72 and persistence manager services 70a as shown in FIG. 12. If storage locations need to be changed by the system administrators, member 104 interfaces do not need to be modified. The view of the member 104 of his/her files 108 and applets 64 is always the same, no matter where the member 104 is or what electronic device 23 the member 104 uses to access his applets 64 and files 108 on the collective 36. A view 105j of another member 104j of the collective 36 is also shown in FIG. 15.

FIG. 15 illustrates how the session manager service 70b-2b tracks the members 104g-j on the collective 36 and the sessions 104n-o that are currently active. Each of the sessions 104n-o is an instance of a member 104 accessing the collective 36. Each of the sessions 104n-o remains active until the member 104g-j properly terminates it by logging out. During one of the sessions 104n-o, the corresponding member 104g-j may interact with one or more of the applets 64 available to him through his containers 62. The member can also manipulate the sessions 104n-o, containers 62, and applets 64 by manipulating these components in a session's directory 104k. In many ways, the session manager service 70b parallels the persistence manager service 70a illustrated in FIG. 14. A major difference, however, is that the session manager service 70b does not track data files, while the persistence manager service 70a does.

In particular, FIG. 15 shows that member 104g has accessed via session links 96 the collective 36 twice, in session 104n and session 104o. This would normally imply the member 104g was using two separate electronic devices 23 to access the collective 36, but this need not be the case. In session 104n, the member 104g is using two different containers or interfaces 62-la and 62-lb. With container 62-la, the member 104g has invoked three separate applets 64-la, while the member 104g has used container 62-lb to invoke only one applet 64-lb. In session 104o, the member 104g has used container 62-2 to invoke two applets 64-2a and 64-2b. These sessions 104n-o are tracked by a sessions directory 104k, which can restore the member's 104g access to either or both sessions 104n and 104o and their respective containers 62 and applets 64 if the member's 104g connectivity is disrupted or improperly terminated. The session manager service 70b-2b is the collective's 36 means of tracking a large number of members 104g-j who are interacting with the collective 36. FIG. 15 displays this as the view of the session manager service 70b of the collective 36. It is a depiction of what is running on the collective 36 and which member 104 is running it. In FIG. 16, a Universal Model is shown as a depiction of the collective 36 in terms of the interrelationships of the views depicted in Figs. 12 though 16. It clarifies that sessions 104n-o are running under the control of both the session manager 70b-l and the member 104g. It also shows that the foundation container 60-2 supports the container 62-2 and its applets 64-3a and 64-3b that are running in the session 104o controlled by the session manager 70b-l. The same foundation container 60-2 is used by the container 62-2 and its applets 64-3a and b to send and receive information over the collective 36 via PCM links 88 to the broker 72-2 and distributors 66-2 and 66-3. The same foundation container 60-2 and its container 62-2 and applets 64-3a and 64-3b can also be controlled by the registrars 70d-l and 70d-2 via ACM links 90.

The Universal Model is a fundamental concept to the invention. The structured interrelationships of the components of the collective 36 allow for easy (drag and drop) administrative control and security management. From an administrative point of view (ACM) , the interconnections are traceable and can be moved about without breaking any of the connections. The member's access interface or container 62-1 gives the member 104 a consistent view of the collective 36, irrespective of his physical location or access device or changes in storage locations or routing devices made by the administrators of the collective 36. The collective 36 handles the problem of connecting a member 104 with his/her files 108 and applications 104d. The container 62 of the member 104g is his/her view of the collective 36, and that container 62 is supplied by the collective 36 each time the member I04g connects. This makes for a resilient and fault tolerant environment. If the collective 36 is set up with a modest amount of redundancy so that the withdrawal of any device from service for maintenance or failure would be transparent to all members 104, who would be unaware of the changes .

To illustrate these points using FIG. 16, suppose that member 104g is running session 104o with container 62-2 from an electronic device 23 such as a PDA. The container 62-2 is the member's interface with the collective 36. Two instances of the foundation container 60 are shown for member 104g to indicate that he has two open connections to the collective 36. With one of the foundation containers 60-1 the member has logged in twice and has two containers 62-la and 62-lb. However, the appearance of these containers 62 is identical. The member 104g has only one interface and therefore only one view of the collective 36. The administrative and mapping concerns of the collective 36 are not part of the member's view and not a member concern.

The member 104g controls two applets 64-3a and 64-3b and the files 108a and 108b. This control is tracked by session manager 70-bl and persistence manager 70a-3. If the member's electronic device 23 fails or the member 104g drops it and destroys it, session manager 70b-l and persistence manager 70a-3 note that the session 104o was interrupted, but not properly terminated. These managers will maintain the state of the session exactly where it was at the point of interruption. The member 104g could go to his laptop computer 20 and reconnect to the collective 36. After an authentication service 70c-l authorized the member's access, the member would again be presented with container 62-2, the same view of the collective 36 the member had on his PDA device 23. The member 104g could query his sessions directory 104k and session manager 70b-l, and the persistence manager 70a-2 would reestablish his connection with his applets 64-3a and 64-3b and files 108a and 108b exactly where the member left off.

As elaborated under the discussion of FIG. 12, the collective 36 is capable of automatically bypassing failed or out of service components. Should a distributor 66 or member service 46 become unavailable, the broker 72 is capable of querying the collective 36 for an alternate component in a manner transparent to the members. System administrators can actively restructure the network 32 for purposes of load balancing or hardware maintenance.

Persons with system administrator roles can easily restructure the network 32 for purposes of load balancing or hardware maintenance. System administrators are members with sufficient privileges to manage the collective 36. Like ordinary members, system administrators can access the collective 36 from any point from which they can establish connectivity. However, the container 62 that an ordinary member 104 receives from the persistence manager 70a limits the member's view of the collective 36 to his own files 108, applets 64, and sessions 104. The system administrator has access illustratively to all of the components of the network 32 and can view on a suitable display the Universal Model, enabling the system administrator to control the entire collective 36. System administrators use registrar services 70d to establish new service nodes 34b and reconfigure old ones. Because the collective 36 is designed to be controlled by graphical interfaces, services 70 and other components can easily be moved from one node 34 to another by dragging and dropping.

As can be seen in FIG. 16, all dependencies within the collective 36 are known. Session managers 70b know what is running at any given time, and which members 104 are accessing which applications. Persistence managers 70a know the directory structure for all member files 108, applications, and system logs, and how these map to physical storage media 21 on the collective 36. Persistence managers 70a also know which members 104 have privileges to access any of these files 108 and applications. When files 108 and applications need to be moved to other storage media 21 for load balancing, system maintenance, or other administrative purposes, these dependencies can be tracked and modified accordingly. Since the collective 36 allows both hot swapping and mirroring, and since the user interfaces that are maintained by the containers 62 do not require members 104 to know the structure of the collective 36, these changes are always transparent to members 104. Because the collective 36 components track these dependencies, the management of resources remains simple irrespective of how large and complex the collective 36 becomes .

The invention can be thought of as an n-tiered collaborative virtual distributed network operating system. While the invention retains the concept of "client" for end user functionality, the capabilities of the invention require several new constructs. In the context of the invention, "collective" is used to describe an instance of the invention itself along with all of the devices and software that interact with the invention. Computers are one kind of device that can interact with a collective. However, a large number of other electronic devices, given the proper communications capability, and with an appropriate portion of the collective software, could also be part of a collective. Examples of these kinds of devices include PDAs, cell phones, television sets and VCRs, and home monitoring and security systems. The term collective is used to escape the concept of a fixed array of devices connoted by the term network. A collective is a dynamic structure that changes as devices and software are added and subtracted from it. In this context, software refers to the distributed components of the operating system itself and to applications and services provided by third parties to add to the functionality of the collective. Individual devices operating in the context of the collective are called nodes.

The invention uses the concept member instead of user, defining a member as a verifiably authorized access account. A collective is a dynamic set of capabilities with collaborative features that enhance member productivity. An alternate embodiment of a collective is a set of computing resources accessible to members in a secure manner from any network, for example the Internet, capable device. From the member's perspective the collective is the set of available computing resources. It is location independent; it looks the same from every member's network access device.

The invention is a distributed collaborative virtual network operating system. It eliminates the need for application software storage on the client nodes, or electronic devices, members use to access their collective. It also requires very little electronic device or client node storage for itself. The portion of the invention permanently stored on an client node is just large enough to communicate with the rest of the collective, and small enough to fit in common consumer electronic devices like personal digital assistants and cell phones. The remaining portion of the invention is distributed over other nodes in a collective.

The invention also stores user or member data remotely, eliminating the need for storage on client nodes. This accomplishes a number of benefits. Members are guaranteed device independent access to their data from anywhere they can access the network that supports their collective, be it a LAN, WAN, or the Internet. Additionally, members no longer have to maintain copies of their data and applications on every device they use. Nor do they have to worry about coordinating modifications of the data or upgrades of the applications on every device they use, since they will no longer maintain multiple copies of their applications or data. Any device capable of accessing the invention grants a member access to the member's current data and applications. Further, if the member's device is lost, stolen, or fails, the member' s data and software remain secure and accessible because they did not reside on the lost device.

The collective-based installation of applications software greatly facilitates the distribution of application software. Not only can one installation of an upgrade suffice for all members, but the installation can be handled by professional system administrators who maintain the collective. This eliminates the need for members to install software on every device they use. Further, all members of a collective will always be using the same version of application software. User reluctance to install new software and/or upgrade the software they already have will no longer inhibit the widespread adoption of innovation.

The invention is not limited to the paradigm of password authorization. Instead, it is organized around the concept of member verification: access is granted after a member's identity is verified. The verification routine can be a password, but could also be voice recognition, fingerprint matching, retinal scanning, or any set of verification schemes that administrators of the collective choose to implement.

A second form of security arises from the invention' s form of information transfer. As information among various components of the collective, a small portion is encrypted and can only be decrypted by another recognized component of the collective. Information sent between two components is time sensitive so as to deny opportunities for unauthorized devices to pose as legitimate components of the collective and spoof it. Complete data encryption is also available for circumstances that justify the computational burden that complete encryption/decryption imposes.

A third level of security is available at the application level. Application developers can add application level security with additional encryption and authorization verification.

Communications within the collective are managed by routing services. Routing services are able to organize themselves with an awareness of the entire collective. If the collective is set up to maintain primary and secondary copies of all software resources, it is automatically fault tolerant. When access to a primary instance of a resource fails, the routing services will automatically reroute to the back up resource. This capability enables system administrators to redistribute the locations of files and applications and adjust the corresponding internal access paths with relative ease. This makes load balancing, even in large collectives, so simple an exercise that there will no longer be a need for an abundant redundancy of collective components. This ease of rerouting also makes the collective highly hardware and software fault tolerant, as failures are quickly bypassed or routed around, even while the collective is live. This hot swap capability also facilitates the withdrawal of hardware resources for servicing.

This feature of the invention also frees members from concern over data and application mapping. A member's view of the collective would be constant and location independent. Members could concentrate on using the features of the collective rather than learning and remembering its structure. This "learn once, run anywhere" capability would even extend to yet to be invented hardware because the virtual environment in which the collective runs is device independent.

Although the present invention has been described in terms of various embodiments, it is not intended that the invention be limited to these embodiments. Modification within the spirit of the inventions will be apparent to those skilled in the art. The scope of the present invention is defined by the claims that follow.

Claims

We claim:

1. A virtual entity established from a network, said network including a plurality of computers, each of the plurality of computers having a memory and being connected to the network, said virtual entity comprising:

a) node software comprising a plurality of parts, said parts being distributed across and stored in the memories of selected of the plurality of computers;

b) said selected computers which execute said distributed parts of said node software form a collective, each of said selected computers that executes said node software becomes a node of said collective;

c) said collective implementing routing services, storage services, security services, administrative services and member services.

2. The virtual entity as claimed in claim 1 , wherein said administrative services issues at least one configuration object and said node is connected to the network and whose node software implements at least a first function, said first function comprises communicating over the network with said administrative services of said collective and to receive therefrom said configuration object that includes configuration information and to determine the role of said node in accordance with said configuration information.

3. The virtual entity as claimed in claim 2, wherein said configuration object further includes at least one software application and said node is a node manager that manages said received software application in accordance with said configuration information.

4. The virtual entity as claimed in c aim J, wherein said node manager records events occurring during the execution of said software application and periodically transmitting said recorded events over the network to said administrative services.

5. The virtual entity as claimed in claim 2, wherein said node is configured as a client node in accordance with said received configuration object, said client node comprising a foundation container that is subcomponent of said routing service for establishing communication over the network and said collective.

6. The virtual entity as claimed in claim 5, wherein said client node further comprises a container that establishes an interface for a member with said collective.

7. The virtual entity as claimed in claim 2, wherein said node is configured as a service node in accordance with said received configuration object for managing one or more of said authentication services, said session manager services, said persistence manager services and said third party services.

8. The virtual entity as claimed in claim 7, wherein said service node comprises a service manager for managing one or more of said authentication services, said session manger services, said persistence manger services and said third party services, and a distributor that is a subcomponent of said routing services and accesses and transmits data from said service manger to said routing services over the network.

9. The virtual entity as claimed in claim 2, wherein said node is configured as a broker node in accordance with said received configuration object ror implementing broker subcomponent of said routing services for receiving data from one node and forwards the data to said appropriate node .

10. The virtual entity as claimed in claim 9, wherein data transmitted from one node to another is inserted into a pouch which also carries data indicative of the next node to which said data is routed, said broker subcomponent responding to said routing data for directing said data to said indicated next node.

11. A method of permissioning a member access to a collective established on a network, the network including a plurality of computers, each of the plurality of computers having a memory and being connected to the network, and node software comprising a plurality of parts, the parts being distributed across and stored in the memories of selected of the plurality of computers, the computers executing the node software to implement a plurality of services, the plurality services including routing services, storage services, security services, administrative services and application services, the storage services including a list of member profiles, one for each member permissioned for access to the collective, said method comprising the steps of:

a) connecting a member's computer device to the network to transmit an identification of the member to security services; '

b) the security services permissioning the member by comparing the member's authentication information with a list of authentication informations of those members permitted access to the virtual collective; and c) if the member is permissioned, downloading from tne security service the member profile of the permissioned member and providing the member's computer device access to the collective.

12. The method of permissioning a member access to a collective as claimed in claim 11, wherein each member profile is unique to a particular member, each profile including an interface that presents a list of the application programs to which the member has been permissioned access to, said method further comprising the step of the member selecting from the member's interface a particular application program.

13. The method of permissioning a member access to a collective as claimed in claim 12, wherein the selected application is run in the collective to access one or more permissoned services, and running at least one permissioned service to transmit objects between the connected member's computer device and the service being run on the collective.

14. The method of permissioning a member access to a collective as claimed in claim 11, wherein said application services comprise a plurality of software applications available to run by the member's computer device, said method further comprises the step of downloading one of the available software applications to be run by the member's computer device.

15. The method of permissioning a member access to a collective as claimed in claim 11, wherein each profile includes a list of a plurality of permissioned application programs, and permitting the member to select one or more of the list of application programs, and downloading the selected application program to be run on the member's computer device.

16. A reconfigurable collective established upon a network, the network including a plurality of computers, each of the plurality of computers having a memory and being connected to the network, said collective comprising:

b) the selected computers execute said distributed software parts to form said collective, each distributed software part becomes a node of said collective; and

c) a collective administrative system that selects and transmits one of a plurality of objects to designated ones of said collective nodes, each of said plurality of objects setting the particular configuration of its designated collective nodes.

17. The reconfigrable collective as claimed in claim 16, wherein said collective comprises a plurality of distinct services, and there are replicated instances of said distinct services .

18. The reconfigurable collective as claimed in claim 17, wherein said administrative system is responsive to the inaccessibility of one or more services to provide and transmit an object to a selected node, whereby said selected node is reconfigured to permit access to another instance of said inaccessable service.

19. A reconfigurable collective established upon a network, the network including a plurality of computers, each of the plurality of computers having a memory and being connected to the network, said collective comprising: a) node software comprising a plurality of parts, said parts being distributed across and stored in the memories of selected of the plurality of computers;

b) the selected computers execute said distributed software parts to form said collective, each distributed software part becomes a node of said collective;

c) said collective comprising a plurality of distinct services, and there are replicated instance of said distinct services; and

d) selected of said collective nodes being broker nodes, at least one of said broker nodes is responsive to the inaccessibility of at least one of said services to be reconfigured to permit access to another instance of said inaccessible service.

20. A collective adapted to be accessed by a member's computer device, the member's computer device including a device memory and a device program stored in the memory, the device program runs on the member's computer device to generate and to apply to said collective a member's message bearing an I.D. indicative of the member, said collective being established on a network, the network including a plurality of computers, each of the plurality of computers having a network memory and being connected to the network, the member's computer device having a given processing power that is limited in comparison with the processing power of said collective, said collective comprising:

a) node software comprising a plurality of parts, said parts being distributed across and stored in the memories of selected of the plurality of computers; b) the plurality of computers executing said node software to implement a plurality of services including security services, storage services and other services;

c) said security services responding to the member's message to compare its I.D. with a list of I.D.s of members who have been granted permission to access said collective and, if there is a match, downloading from said storage services and applying to the member computer device a profile that instructs the member's computer device to download an interface from the collective bearing an indication of those services that may be accessed by the member, whereby the member may access said services selected from said interface.

21. A method of permissioning a member to access a collective established on a network and to initiate a session utilizing the resources of said collective, the network including a plurality of computers, each of the plurality of computers being connected to the network and having a memory and node software, the node software comprising a plurality of parts, the parts being distributed across and stored in the memories of selected of the plurality of computers, said method comprising the steps of:

a) executing on selected of the plurality of the computers the node software to implement security services, storage services and other services;

b) using the security services to compare an unique ID of the member with a list of members who are permissions to access the collective;

c) if there is a match, permissioning the matched member to initiate a session with the collective; d) using the storage services to down load a profile associated with the matched member, said profile comprising instructions to download an interface bearing an indication of those services applications which the member may access;

e) permitting the member to select from the interface certain services and applications and to use the selected services to process data;

f) creating data objects to store the processed data; and

g) terminating the member's session with the collective, whereby the storage services stores the member's data object and the member's profile in a member's directory, whereby the member may initiate at any point on the network another session and to readily access the stored profile of the member and the data object retaining the member's processed data.