|
JXTA | |||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
java.lang.Objectnet.jxta.id.ID
net.jxta.platform.ModuleClassID
public abstract class ModuleClassID
A ModuleClassID uniquely identifies a particular local behaviour, that is, a specific API for each execution environment for which an implementation exists.
A ModuleClassID has two components: A base class identifier, and a role identifier. The role identifier may be zero. By convention the API uses the ModuleClassID with a zero role identifier to designate the base class in contexts where only the base class is significant. Nonetheless, a ModuleClassID with a zero role identifier is a valid ModulesClassID wherever a full ModuleClassID is expected. In many cases, only one role in a given class is ever used. Using role zero in such cases is an optimization because it may make the string representation of the ModuleClassID shorter. Each service of a group, that is, the role it plays in the group, is uniquely identified per the group definition. This identifier may be used by other modules in the group to designate this one, or by the service itself to identify its parameters in a PeerAdvertisement. In addition, by combining its PeerGroupID with its own ModuleClassID, a service may create a predictible identifier unique on their peer, suitable for registering listeners with the EndpointService or other services with similar listener interfaces. The standard PeerGroup implementation of the java reference implementation assigns to each service its ModuleClassID as its unique service identifier. Most of the times this ModuleClassID is a base classID, but groups that use the same Module Class for more than one service (same behaviour but playing a different role in the group, such as, for example, a data base engine with a different data base), may define multiple roles identified by the same base class identifier but different role identifiers. The standard PeerGroup implementation of the java reference implementation has the notion of main application: a default application which may be started automatically upon instantiating the group. This application implements Module and, therefore, is assigned a ModuleClassID. However applications are not expected to play any specific role in the group. As a result, they are assigned a role identifier allocated at run-time as need to garantee local unicity. As a result main applications cannot expect a predictible ClassID. A ModuleClassID is optionaly described by a published ModuleClassAdvertisement. There may be any number of embodiements of a module class. These are module specifications. A module specification represent the network behaviour of a module while its class represents its local behaviour. Different groups may use a common subset of classes, for example, the basic set defined by the platform should always be part of it. Each group may use different and network-incompatible specifications for common classes, optimized for various purposes. The local API of a given class on a given JXTA implementation will be invariant per the spec being used. Therefore, the difference will be transparent to applications which do not depend on the possibly different quality of service. A ModuleSpecID embeds a base class identifier, which permits to verify that a given Module specification is suitable for its intended use.
PeerGroup
,
Module
,
ModuleClassID
,
PeerAdvertisement
,
ModuleSpecAdvertisement
,
ModuleClassAdvertisement
,
EndpointService
,
ID
,
Serialized FormField Summary |
---|
Fields inherited from class net.jxta.id.ID |
---|
nullID, URIEncodingName, URNNamespace |
Constructor Summary | |
---|---|
ModuleClassID()
|
Method Summary | |
---|---|
static ModuleClassID |
create(URI fromURI)
Creates an ID by parsing the given URI. |
abstract ModuleClassID |
getBaseClass()
Return a ModuleClassID of the same base class but with the role portion set to zero. aka "the base class". |
ModuleClassID |
intern()
Returns a canonical representation for the ID object. |
abstract boolean |
isOfSameBaseClass(ModuleClassID id)
Returns true if this ModuleClassID is of the same base class than the given class. |
abstract boolean |
isOfSameBaseClass(ModuleSpecID id)
Returns true if this ModuleClassID is of the same class than the the given ModuleSpecID. |
Methods inherited from class net.jxta.id.ID |
---|
getIDFormat, getUniqueValue, getURL, toString, toURI |
Methods inherited from class java.lang.Object |
---|
clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait |
Constructor Detail |
---|
public ModuleClassID()
Method Detail |
---|
public static ModuleClassID create(URI fromURI)
This convenience factory method works as if by invoking the
IDFactory.fromURI(URI)
method; any
URISyntaxException
thrown is caught and wrapped in a
new IllegalArgumentException
object, which is then thrown.
This method is provided for use in situations where it is known that
the given string is a legal ID, for example for ID constants declared
within in a program, and so it would be considered a programming error
for the URI not to parse as such. The IDFactory
,
which throws URISyntaxException
directly, should be used
situations where a ID is being constructed from user input or from some
other source that may be prone to errors.
fromURI
- The URI to be parsed into an ID
NullPointerException
- If fromURI
is null
.
IllegalArgumentException
- If the given URI is not a valid ID.public ModuleClassID intern()
intern
in class ID
public abstract boolean isOfSameBaseClass(ModuleClassID id)
id
- Module class id to compare with
public abstract boolean isOfSameBaseClass(ModuleSpecID id)
id
- Module spec id to compare with
public abstract ModuleClassID getBaseClass()
|
JXSE | |||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |