DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

[0066] A system and method for describing and identifying abstract software modules in peer-to-peer networking environments is described. In a peer-to-peer network, software modules may use the mechanism for abstract identity and definition to provide information about the programming interface and functionality of the software modules independently of protocols and behaviors that may be used to implement the software modules. Further, software modules in a peer-to-peer network may provide one or more implementations of a given functionality, using various protocols and behaviors, while retaining a common programming interface. The software modules may also provide one or more different network-compatible implementations for different execution environments.

[0067] While generally described herein for peer-to-peer environments implemented according to an exemplary peer-to-peer platform as described below, it is noted that embodiments of the system and method for describing and identifying abstract software modules in peer-to-peer networking environments may be used in peer-to-peer environments implemented according to other peer-to-peer platforms. Further, it is noted that embodiments may be used in other environments than peer-to-peer environments to describe and identify abstract software modules

[0068] Embodiments may use unique identifiers (e.g., UUIDs) and advertisements such as are described for the exemplary peer-to-peer platform described below to describe and identify software modules, such as services and applications, in a hierarchical manner. In one embodiment, a software module may be described in a module class advertisement and given a module class identifier. If that software module is used for different purposes in the same context, the software module may be further identified by an extension to its module class identifier that may be referred to as a role identifier or role extension. Each independent embodiment of the software module that provides an independent set of network protocols and behaviors may be assigned a module specification identifier.

[0069] In one embodiment, all implementations of all embodiments of a given module class for a given execution environment have the same programming interface. Therefore, software modules interacting locally may express their dependencies via their respective class identifiers (which may include a role extension), regardless of the particular execution environment and embodiment that was selected when configuring that environment.

[0070] In one embodiment, a software module may be assigned a module class identifier. Each independent embodiment of the software module that provides an independent set of network protocols and behaviors may be described by a module specification advertisement and assigned a module specification identifier. In one embodiment, a module specification identifier may be an extension of the identifier of the module class of which the module specification is an embodiment. In one embodiment, each implementation of each module specification may be described by a module implementation advertisement that may include one or more of, but is not limited to, the following information: a module specification identifier, an execution environment description, and a reference to a software environment (e.g. a software package which implements the module specification for the execution environment).

[0071] Embodiments may use a tiered architecture to define modules (e.g. services, advertisements, etc.) to abstract software modules in peer-to-peer networking environments. FIG. 2 illustrates a tiered architecture to define modules according to one embodiment. A first level of the tier may include one or more module classes 1000 . In one embodiment as illustrated in FIG. 2 , each module class 1000 may have one module specification 1002 . A module specification 1002 may have one or more module implementations 1004 . FIG. 3 illustrates the tiered architecture according to another embodiment. In this embodiment, each module class 1000 may have one or more module specifications 1002 . Each module specification 1002 may have one or more module implementations 1004 .

[0072] In one embodiment, the module class 1000 may include and/or define one or more of, but is not limited to, the “role” a module plays (e.g. in a peer group), how the module appears to other modules (e.g. services and applications), and the module's API in each supported binding. In one embodiment, the module specification(s) 1002 may include and/or define, but is not limited to, the module's behavior as it appears from the outside (e.g. from other modules), including the module's wire protocol and the module's compatibility with other instances of the same module, for example on other peers. In one embodiment, the module implementation(s) 1004 may include one or more implementations of each module specification 1002 , with each module implementation 1004 being specific for one or more of various execution environments, bindings and other constraints.

[0073] In one embodiment, each of these aspects of an abstract software module may be published separately in advertisements. One embodiment may provide module class advertisements, module specification advertisements, and module implementation advertisements to describe and identify abstract software modules in peer-to-peer networking environments. FIG. 4 illustrates a module class advertisement 1010 , a module specification advertisement 1012 , and a module implementation advertisement 1014 for a software module according to one embodiment.

[0074] In a peer-to-peer environment implemented with the exemplary peer-to-peer platform as described below, network resources such as peers, peer groups, pipes, and modules such as services may be represented by advertisements. Advertisements are language-neutral metadata documents for describing the network resources. Advertisements are used to describe peers, peer groups, pipes, content, modules such as services and other types of network resources. Advertisement types provided by the peer-to-peer platform may include one or more of, but are not limited to, peer advertisements, peer group advertisements, module class advertisements, module specification advertisements, module implementation advertisements, pipe advertisements, and rendezvous advertisements. Advertisements may be exchanged as documents in peer-to-peer protocol messages. One or more of the peer-to-peer platform protocols may use advertisements to provide information to entities interested in the peer-to-peer resources represented by the advertisements. Peer-to-peer platform protocols may be used to pass advertisements between peers and/or to access published advertisements.

[0075] In one embodiment, advertisements may include a series of hierarchically arranged elements. An advertisement's elements may appear in arbitrary order within the advertisement. Each element may include data or additional elements. An element may also have attributes. In one embodiment, attributes are name-value string pairs. An attribute may be used, for example, to store meta-data that may describe the data within the element. In one embodiment, peer-to-peer platform advertisements may be represented in the eXtensible Markup Language (XML). Other embodiments may use other encodings such as HTML or WML. In one embodiment, advertisements may be specified using a schema definition language such as the XML Schema Definition Language. In one embodiment, XML advertisements may be translated into other encodings such as HTML and WML to allow peers that do not support XML to access advertised resources. Advertisements are further described in the Advertisements section as well as other sections of the description of the exemplary peer-to-peer platform included below.

[0076] In one embodiment, a software module (e.g. service, application, etc.) class may be described by a module class advertisement 1010 , identified by a module class identifier 1020 in the module class advertisement 1010 . The module specification advertisement(s) 1012 further describes the software module, e.g. the behavior of the software module. The module implementation advertisement(s) 1014 describe implementations of the software module (identified by a module specification identifier 1022 included in the module specification advertisement 1012 and the module implementation advertisement(s) 1014 ) for different platforms, e.g. Windows, Unix and Solaris platforms. The layers of advertisements (module class advertisement 1010 , module specification advertisement(s) 1012 , and module implementation advertisement(s) 1014 ) may be used to abstract software modules (e.g. services, applications, etc.) and platforms, to locate specifications for desired software modules, to locate implementations of the software modules, and to load and run the software modules.

[0077] Using advertisements, embodiments may provide a mechanism to identify a particular software module (e.g. a service) and its behavior. In one embodiment, no matter what platform a user (or other entity such as another software module) is on, the user or other entity may locate (e.g. by a discovery process) a particular implementation of the software module for the particular platform and be able to use the software module. In one embodiment, to access a software module, a peer (or other entity such as another software module (e.g. service, application, etc.)) may use a discovery process such as that described herein for the exemplary peer-to-peer platform to discover a module implementation advertisement 1014 corresponding to the execution environment of the peer. In one embodiment, the discovery process may search for and discover module specification advertisements 1012 that meet the specification requirements of the peer, and use the one or more discovered module specification advertisements 1012 to locate a particular module implementation advertisement 1014 for a module implementation suitable for use in the peer's execution environment.

[0078] As an example, a user or other entity may be able to locate and use a particular implementation of a printing service for use with the platform the user or other entity is on. In one embodiment, the user or other entity may first search for and locate a specification for the software module. Once the specification is located, the user or other entity may look for a particular implementation of the software module usable on the user or other entity's platform, load the implementation of the software module according to the advertisements for use on the platform, and run the software module.

[0079] The layers of advertisements may also serve to separate the specification from the implementation. This may reduce the size of the module implementation advertisements 1014 , as the advertisements do not need to include the full specification for the software module but instead may refer back to the specification advertisement via the module specification identifier. This may allow software modules to be initially located by specification for a particular class of functionality, rather than having to search through many implementation advertisements of software modules to find a desired implementation of a specification, preferably making the discovery process simpler.

[0080] In one embodiment, on a Java platform, after locating a desired module implementation advertisement 1014 , using a PURI (Package Uniform Resource Identifier) included in the module implementation advertisement 1014 , a URI or URL to the actual code and/or other data of the software module may be specified. In one embodiment, on other platforms such as Unix and Linux, one or more locations for software module code and/or other data may be specified by URL, URI, or other mechanisms. The code may be downloaded, referenced on disk, or referenced by the URI or other mechanism. The SURI (Specification URI, described below) of the module specification advertisement may function similarly to retrieve a document containing the module specification. In one embodiment, on some platforms, software module code and/or other data may be included in the module implementation advertisement 1014 .

[0081] In one embodiment, a peer node may include a module advertisement and identifier generator for describing and identifying abstract software modules in peer-to-peer networking environments by generating module identifiers (e.g. module class identifiers 1020 and module specification identifiers 1022 ) and module advertisements (e.g. module class advertisements 1010 , module specification advertisements 1012 , and module implementation advertisements 1014 ) for classes of software modules. If a software module is used for different purposes in the same context, the software module may be further identified by an extension to its module class identifier that may be referred to as a role identifier or role extension, which may also be generated by the module advertisement and identifier generator.

[0082] FIG. 5 illustrates an exemplary network with a peer node including a module advertisement and identifier generator according to one embodiment. Peer node 1032 A may be any of various types of devices, including, but not limited to, a personal computer system, desktop computer, laptop or notebook computer, mainframe computer system, workstation, network appliance, network computer, Internet appliance, or other suitable device. Peer node 1032 A may include at least one processor 1034 . The processor 1034 may be coupled to a memory 1036 . Memory 1036 is representative of various types of possible memory media, also referred to as “computer readable media.” Hard disk storage, floppy disk storage, removable disk storage, flash memory and random access memory (RAM) are examples of memory media. The terms “memory” and “memory medium” may include an installation medium, e.g., a CD-ROM or floppy disk, a computer system memory such as DRAM, SRAM, EDO RAM, SDRAM, DDR SDRAM, Rambus RAM, etc., or a non-volatile memory such as a magnetic media, e.g., a hard drive or optical storage. The memory medium may include other types of memory as well, or combinations thereof. Peer node 1032 A may couple over network 1030 to one or more other network devices such as other peer nodes 1032 B and 1032 C via one or more wired or wireless network interfaces (not shown).

[0083] Peer node 1032 A may include, in memory 1036 , a module advertisement and identifier generator 1038 that may serve as a means for generating module advertisements and module identifiers (including role extensions) for classes of modules in memory 1036 on host machine 1032 A. Module class identifier 1020 may serve as a means for uniquely identifying a class of software module 1000 on peer node 1032 A as well as on network 1030 . Module specification identifier 1022 may serve as a means for uniquely identifying a module specification 1002 on peer node 1032 A as well as on network 1030 . A role extension (not shown) to the module class identifier 1020 may serve as a means for uniquely identifying a software module used for different purposes in the same context. Module class advertisement 1010 , module specification advertisement 1012 , and module implementation advertisement 1014 may serve as means for describing and advertising module class 1000 , module specification 1002 , and/or module implementation 1004 , respectively, to other entities (e.g. peers, services, applications, etc.) on network 1030 . Note that while FIG. 5 illustrates one module specification 1002 for module class 1000 , and one module implementation 1004 for module specification 1002 , in one embodiment, there may be two or more module specifications 1002 for module class 1000 . In addition, there may be two or more module implementations 1004 for each module specification 1002 .

[0084] Each peer node 1032 may host one or more peers (not shown). A peer may be defined as any entity or collection of resources that runs some or all of one or more protocols used in a particular peer-to-peer network environment, for example one or more of the peer-to-peer protocols in a particular peer-to-peer network environment implemented according to the exemplary peer-to-peer platform described below. As such, a peer may manifest in the form of a processor, a process, a device, or even a collection of devices. A peer may be implemented on any device with a digital heartbeat that supports the peer-to-peer environment, including sensors, servers, PCs, computers up to and including supercomputers, PDAs, manufacturing and medical equipment, phones and cellular phones. As mentioned above, a peer node 1032 may include one or more peers. In one embodiment, two or more devices may be configured to perform as a single peer in a peer-to-peer network. In this case, the two or more devices may be considered a single peer node.

[0085] In order to interact with other peers (e.g. to form or join peer groups), a peer needs to be connected (e.g. by one or more network interfaces of its hosting peer node 1032 ) to some kind of network 1000 (wired or wireless), such as IP, Bluetooth, or Havi, among others. A peer is typically associated with one network location represented by a unique identifier.

[0086] In one embodiment, each peer node 1032 on the network 1030 may include one or more instances of module advertisement and identifier generator 1038 for generating module advertisements and module identifiers for module classes 1000 on the peer node 1032 . In one embodiment, there may be one instance of module advertisement and identifier generator 1038 for each peer on a peer node 1032 . In another embodiment, a module advertisement and identifier generator (e.g. a service) may be provided by one or more peer nodes 1032 on the network 1030 for use by other peer nodes 1032 on the network 1030 in generating module advertisements and module identifiers for module classes 1000 on the peer nodes 1032 . In one embodiment, module advertisement and identifier generator 1038 may be provided by a peer-to-peer platform such as the exemplary peer-to-peer platform described below.

[0087] In one embodiment, generated module advertisements. (e.g. module class advertisement 1010 , module specification advertisement 1012 , and module implementation advertisement 1014 ) may be stored locally on peer node 1032 A and published on the network 1030 for discovery by other peer nodes 1032 . In one embodiment, generated module advertisements may be provided to one or more other nodes on network 1030 , including one or more other peer nodes 1032 , to be published for discovery on the network 1030 .

[0088] In one embodiment, a module class advertisement 1010 may be used to describe a class of software modules. A module class advertisement 1010 may describe an expected local behavior and an expected API for each peer-to-peer platform binding that supports the class of software modules. A module class advertisement 1010 may provide a description of what a particular module class identifier 1020 stands for. Module class identifiers 1020 may be used by a software module or other code in the peer-to-peer network environment to designate software modules upon which the software module or other code depends. In one embodiment, a module class advertisement 1010 may not fully describe the corresponding module's behavior and API; instead, the module's behavior and API may be further described in module specification advertisement(s) 1012 and module implementation advertisement(s) 1014 . In one embodiment, a module class advertisement 1010 may be used to create modules with similar functionality.

[0089] The following illustrates an exemplary module class advertisement 1010 schema that may be used in embodiments and is not intended to be limiting: 1

[0090] where the elements may include one or more of, but are not limited to:

[0091] MCID—Module class identifier 1020 that uniquely identifies the module class. Each module class may have a unique identifier. In one embodiment, this is a required element.

[0092] Name—A name associated with the module class. In one embodiment, the name is not required to be unique unless the name is obtained from a centralized naming service that guarantee name uniqueness. In one embodiment, this is an optional element.

[0093] Desc—Description. A string that may be used to describe and search for a module class. In one embodiment, this is an optional element.

[0094] In one embodiment, a module specification advertisement 1012 may be used to describe the specification of a software module. A module specification advertisement 1012 may describe, for example, an expected on-wire behavior and protocol for the module. A module specification advertisement 1012 may provide a description of what a particular module specification identifier 1022 represents. A module specification identifier 1022 may be used by a software module or other entity in the peer-to-peer environment to designate a particular network-compatible family of implementations of a given module class described by a corresponding module class advertisement 1010 and identified by a module class identifier 1020 .

[0095] In some embodiments of a peer-to-peer platform, one or more core peer group services (e.g. discovery, membership, resolver, etc.) may be implemented as software modules. In one embodiment, module specification identifiers 1022 may be used by a peer group implementation to designate the components that provide the various services that the peer group supports.

[0096] A module specification advertisement 1012 may also describe how to invoke and use a software module. In one embodiment, a software module may be accessed through an API (application programming interface) of the module by locating an implementation of the software module, loading the module, and starting the module. In one embodiment, a software module may be accessed via a peer-to-peer communications channel (e.g. a peer-to-peer platform pipe as described below). In one embodiment, an advertisement for the communications channel (e.g. a pipe advertisement as described below) may be included in the software module's module specification advertisement 1012 . In one embodiment, a software module may be accessed through a proxy module accessed using a module specification identifier 1022 of the proxy module included in the software module's module specification advertisement 1012 .

[0097] The following illustrates an exemplary module specification advertisement 1012 schema that may be used in embodiments and is not intended to be limiting: 2

[0098] where the elements may include one or more of, but are not limited to:

[0099] MSID—module specification identifier 1022 . May uniquely identify this module specification. Each module specification may have a unique module specification identifier 1022 . In one embodiment, this is a required element.

[0100] Vers—The version of the module specification that this advertisement advertises. In one embodiment, this is a required element.

[0101] Name—Name that may be associated with a module specification. The name may not be required to be unique. In one embodiment, the name may be obtained from a centralized naming service that guarantee name uniqueness, and therefore in this embodiment the name may be unique. In one embodiment, this is an optional element.

[0102] Desc—Description. A string that may be used to describe and search for a module specification. In one embodiment, this is an optional element.

[0103] CRTR—Creator. This element designates the creator of this module specification. In one embodiment, this is an optional element.

[0104] SURI—Specification URI (Uniform Resource Identifier). This element is a resource identifier that permits the retrieval of a document containing the module specification that this advertisement advertises. In one embodiment, this is an optional element.

[0105] Parm—May include one or more arbitrary parameters that may be interpreted by each implementation.

[0106] xxxx:PipeAdvertisement—Identifies a pipe advertisement which this module binds to an input pipe, and which thus may be used to establish a pipe to an implementation of this module specification. In one embodiment, this element name may be identical to the pipe advertisement document type since the entire element is an embedded pipe advertisement document. In one embodiment, this is an optional element.

[0107] Proxy—Proxy specification identifier. This is a module specification identifier 1022 of a proxy module that may be used in order to communicate with modules of this specification. Note that the process may be recursive. The proxy module may be usable via pipes, or optionally through a subsequent proxy module, and may require a subsequent authenticator. In one embodiment, this is an optional element.

[0108] Auth—Authenticator specification identifier. This is a module specification identifier 1022 of an authenticator module that may be used to authenticate entities that desire to communicate with modules of this specification. Note that the process may be recursive. The authenticator module may be usable via pipes, or optionally through a subsequent proxy module, and may require a subsequent authenticator. In one embodiment, this is an optional element.

[0109] In one embodiment, a module implementation advertisement 1024 may be used to describe a particular implementation of a module specification. Implementations of a given specification may be searched for using the module specification identifier 1022 . An implementation may be selected, for example, by the type of environment in which the implementation may be used (specified in the implementation advertisement's compatibility element) as well as by its name, description, and/or the content of its parameters element.

[0110] A module implementation advertisement 1024 may provide a mechanism to retrieve data that may be required or desired in order to execute the module implementation being described. In one embodiment, this information may be encapsulated in the <Code> and <PURI> (Package Uniform Resource Identifier) elements. The interpretation of these elements may be subject to the module's compatibility. For example, a standard peer group implementation of a Java reference implementation may expect the <Code> element to specify a fully qualified Java class name that designates a subclass such as net.xxxx.platform.Module and PURI to be the URI (Uniform Resource Identifier) of a downloadable package (e.g. a jar file). Other execution environments may expect the code to be inline within the <Code> element or may offer two or more options.

[0111] The following illustrates an exemplary module implementation advertisement 1024 schema that may be used in embodiments and is not intended to be limiting: 3

[0112] where the elements may include one or more of, but are not limited to:

[0113] MSID—module specification identifier 1022 . May uniquely identify the module specification being implemented. In one embodiment, this is a required element.

[0114] Comp—Compatibility. An arbitrary element that may describe the environment in which this module implementation may be executed. Each framework capable of loading and executing the module may have its own requirements on the contents of this element. In one embodiment, this is a required element.

[0115] Code—This arbitrary element may include anything that is needed in addition to the package in order to load and execute the code of this module implementation. In one embodiment, for Java module implementations, this element may include a fully qualified class name containing the module's entry points. In one embodiment, this element may include the entire code.

[0116] PURI—Package URI (Uniform Resource Identifier). This element is a resource identifier that permits the retrieval of a package containing the code of this module implementation. In one embodiment, this is an optional element.

[0117] Prov—Provider. The provider of this module implementation. In one embodiment, this is an optional element.

[0118] Desc—Description. A string that may be used to describe and search for a module specification. In one embodiment, this is an optional element.

[0119] Parm—Parameter. May include one or more arbitrary parameters that may be interpreted by the module implementation's code.

[0120] FIG. 6 is a flowchart illustrating a method for describing and abstracting a software module according to one embodiment. As indicated at 1100 , for a class of software module, a module class advertisement, for example the module class advertisement described above, may be generated. A module class identifier may be generated and included in the module class advertisement. As indicated at 1102 , one or more module specification advertisements may be generated. A module specification identifier may be generated for each software module specification and included in the corresponding module specification advertisement. As indicated at 1104 , one or more module implementation advertisements may be generated for each module specification advertisement. The module specification identifier for the corresponding module specification may be included in each module implementation advertisement. These advertisements may be published in the peer-to-peer network, for example a peer-to-peer network implemented according to the exemplary peer-to-peer platform described herein to provide discovery of and access to the corresponding software module to peers in the peer-to-peer network.

[0121] FIG. 7 is a flowchart illustrating a method for describing and identifying abstract software modules according to one embodiment. One or more of a plurality of peers in a peer-to-peer network environment may host a class of software module. As indicated at 1110 , a module class advertisement may be generated for the class of software module. The module class advertisement may define a local behavior and an Application Programming Interface (API) for each of one or more peer-to-peer bindings that supports the class of software module. As indicated at 1112 , a module class identifier may be assigned to the class of software module that uniquely identifies the class of software module. In one embodiment, the module class identifier may be included in the module class advertisement. In one embodiment, a role extension to the module class identifier may be generated for each instance of the class of software module configured to perform different roles in a context. In one embodiment, the role extension may be included in the module class advertisement.

[0122] As indicated at 1114 , a different module specification identifier may be assigned to each of one or more module specifications of the class of software module. Each module specification identifier uniquely identifies its corresponding module specification. In one embodiment, each module specification indicates an expected on-wire behavior and one or more network protocols for a particular embodiment of the class of software module. In one embodiment, a module specification advertisement may be generated for each module specification. In one embodiment, each module specification advertisement includes a corresponding module specification identifier. In one embodiment, each module specification advertisement includes or describes one or more mechanisms to invoke and use the class of software module.

[0123] In one embodiment, one or more module implementations may be generated for each module specification of the class of software module. Each module implementation is configured to execute within a particular execution environment. In one embodiment, a module implementation advertisement may be generated for each module implementation. In one embodiment, each module implementation advertisement includes a module specification identifier of the module specification implemented by the module implementation described and advertised by the module implementation advertisement. In one embodiment, two or more module implementations of the class of software module configured to execute within a particular execution environment may provide a common programming interface. As a result, software modules interacting locally may express their dependencies via their module class identifiers (including role extensions, if any), regardless of the particular execution environment and embodiment that was selected when configuring the execution environment.

[0124] FIG. 8 is a flowchart illustrating a method for providing multiple embodiments of abstract software modules according to one embodiment. One or more of a plurality of peers in a peer-to-peer network environment may host a class of software module. As indicated at 1120 , a module class identifier may be assigned to the class of software module. In one embodiment, a module class identifier uniquely identifies a corresponding class of software module. As indicated at 1122 , one or more module specification advertisements may be generated for the class of software module. In one embodiment, each module specification advertisement describes a module specification including an expected on-wire behavior and protocol of the class of software module. In one embodiment, each module specification advertisement further describes one or more mechanisms to invoke and use the class of software module. In one embodiment, a module specification identifier may be generated for each module specification that uniquely identifies the module specification. In one embodiment, the module specification identifiers may be included in the corresponding module specification advertisements.

[0125] As indicated at 1124 , one or more module implementation advertisements may be generated for each module specification advertisement. In one embodiment, each module implementation advertisement describes a particular module implementation of a corresponding module specification configured to execute within a particular execution environment. In one embodiment, a module specification identifier of the corresponding module specification may be included in each module implementation advertisement. In one embodiment, each module implementation advertisement may include an indication of a mechanism for accessing code of the particular module implementation. In one embodiment, each module implementation advertisement may include a description of the particular execution environment in which the corresponding module implementation is configured to execute. In one embodiment, each module implementation advertisement is discoverable by peers on the peer-to-peer network for use by the peers to implement corresponding module specifications in particular execution environments of the peers.

[0126] FIG. 9 is a flowchart illustrating a method for multiplatform implementation of an abstract software module according to one embodiment. One or more of a plurality of peers in a peer-to-peer network environment may host a class of software module. As indicated at 1130 , a module class identifier may be assigned to the class of software module. In one embodiment, a module class identifier uniquely identifies a corresponding class of software module. As indicated at 1132 , a module specification identifier may be assigned to each of one or more module specifications of the class of software module. In one embodiment, each module specification identifier uniquely identifies a corresponding module specification. In one embodiment, each module specification indicates an expected on-wire behavior and one or more network protocols for a particular embodiment of the class of software module.

[0127] As indicated at 1134 , one or more module implementation advertisements may be generated for each module specification advertisement. In one embodiment, each module implementation advertisement describes a particular module implementation of a corresponding module specification configured to execute within a particular execution environment. In one embodiment, each module implementation advertisement may include a module specification identifier that uniquely identifies the module specification implemented by the module implementation corresponding to the module implementation advertisement. In one embodiment, each module implementation advertisement may include an indication of a mechanism for accessing code of the particular module implementation. In one embodiment, each module implementation advertisement may include a description of the particular execution environment in which the corresponding module implementation is configured to execute. In one embodiment, each module implementation advertisement is discoverable by peers on the peer-to-peer network for use by the peers to implement corresponding module specifications in particular execution environments of the peers. In one embodiment, two or more module implementations of the class of software module configured to execute within a particular execution environment may provide a common programming interface. As a result, software modules interacting locally may express their dependencies via their module class identifiers (including role extensions, if any), regardless of the particular execution environment and embodiment that was selected when configuring the execution environment.

[0128] The following are descriptions of embodiments of peer advertisements and peer group advertisements that may be used in embodiments of the system and method for describing and identifying abstract software modules in peer-to-peer networking environments.

[0129] A peer advertisement may describe a peer and the resources it provides to the group. A peer advertisement may include specific information about the peer including one or more of, but not limited to, its name, its unique identifier, its group identifier and descriptive information. A peer advertisement may also include endpoint addresses and any run-time attributes that individual peer services want to publish (such as being a rendezvous peer for a group).

[0130] The following illustrates an exemplary peer advertisement schema that may be used in embodiments and is not intended to be limiting: 4

[0131] where the elements may include one or more of, but are not limited to:

[0132] PID—Peer identifier that may uniquely identify the peer. Each peer may have a unique identifier. In one embodiment, this is a required element.

[0133] GID—The peer group identifier. This element may identify canonically which peer group this peer belongs to.

[0134] Name—A string that may be associated with the peer. In one embodiment, the name may not be required to be unique. In one embodiment, the name may be obtained from a centralized naming service that guarantees name uniqueness. In one embodiment, this is an optional element.

[0135] Desc—A string that may be used to index and search for a peer. In one embodiment, the string is not guaranteed to be unique. Two peers may have the same keywords. In one embodiment, this is an optional element.

[0136] Svc—Service. In one embodiment, any number of service elements may be included. In one embodiment, ach of the service elements may describe the association between a group service which may be denoted by its module class identifier (the value of an MCID (module class identifier) element), and arbitrary parameters encapsulated in a Parm (parameter) element. For example, all accessible endpoint addresses may be published in association with the Endpoint Service Module Class Identifier. The TLS Root certificate may be published under the Peer group Module Class Identifier (There may be a module class identifier for a Peer Group as well). The flag that denotes that this peer is a rendezvous for this group may be published under the Rendezvous Service module class identifier. In one embodiment, each service may be responsible for what is published under its module class identifier. The Service section may also optionally include an element (e.g., “isOff”) that may be used to indicate if this service is enabled or disabled. This element may be used to convey a configuration choice made by the owner of the peer.

[0137] A peer group advertisement may be used to describe peer group-specific resources including one or more of, but not limited to, name, group identifier, description, specification, and service parameters. The following illustrates an exemplary peer group advertisement schema that may be used in embodiments and is not intended to be limiting: 5

[0138] where the elements may include one or more of, but are not limited to:

[0139] GID—This element provides the peer group identifier. The peer group identifier is the canonical way of referring to a group and uniquely identifies the peer group.

[0140] MSID—Peer group specification identifier. This designates the module that provides the peer group mechanism for the group. The specification identifier may include an abstraction of that mechanism. This abstraction may be optionally described by a module specification advertisement, and one or more implementations may exist, which may each be described by a module implementation advertisement. In one embodiment, these advertisements may all be searched by peer group specification identifier. In one embodiment, this is a required element.

[0141] Name—A name that may be associated with the peer group. In one embodiment, the name is not required to be unique. In one embodiment, the name may be obtained from a centralized naming service that guarantee name uniqueness. In one embodiment, this is an optional element.

[0142] Desc—This element provides descriptive information that may be used to index and search for a peer group. In one embodiment, the content of this element may not be unique. For example, two peer groups may have the same keywords.

[0143] Svc—Service. In one embodiment, any number of service elements may be included. Each service element may describe the association between a group service denoted by its module class identifier (the value of an MCID element), and one or more arbitrary parameters encapsulated in a Parm element. This optional parameter may only be meaningful to some services. It may be used to configure a service specifically in relation with its use by this group. For example, a simple membership service may find an encrypted password list there. In one embodiment, this is an optional element.

[0144] The following describes in greater detail various types of peer-to-peer platform identifiers that may be used in embodiments of the system and method for describing and identifying abstract software modules in peer-to-peer networking environments.

[0145] In embodiments of peer-to-peer platforms such as the exemplary peer-to-peer platform described herein, peer-to-peer platform protocols may need to refer to peers, peer groups, pipes and other peer-to-peer platform resources. In one embodiment, these references may be presented in the protocols as peer-to-peer platform identifiers. Peer-to-peer platform identifiers may provide a mechanism for uniquely identifying specific peer groups, peers, pipes, contents and service instances, among other resources. Peer-to-peer platform identifiers may provide unambiguous references to the various peer-to-peer platform entities. There may be several types of peer-to-peer platform entities which may have peer-to-peer platform identifier types defined including one or more of, but not limited to: peer groups, peers, pipes, content, module classes and module specifications.

[0146] In one embodiment, peer-to-peer platform identifiers may be presented as Uniform Resource Names (URNs). URNs are a form of URI (Uniform Resource Identifier) that are intended to serve as persistent, location-independent, resource identifiers. Like other forms of URI, peer-to-peer platform identifiers are presented as text. See IETF RFC 2141 for more information on URNs.

[0147] In one embodiment, a peer-to-peer platform identifier is a standard URN in the peer-to-peer platform identifier namespace. Peer-to-peer platform identifier URNs are identified by a namespace identifier, for example “xxxx”. Each peer-to-peer platform identifier URN may also include an identifier format keyword. The identifier format keyword ma