moduleclassid.java

jxme的一些相关程序,主要是手机上程序开发以及手机和计算机通信的一些程序资料,程序编译需要Ant支持

/*
 * Copyright (c) 2001 Sun Microsystems, Inc.  All rights
 * reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 *
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in
 *    the documentation and/or other materials provided with the
 *    distribution.
 *
 * 3. The end-user documentation included with the redistribution,
 *    if any, must include the following acknowledgment:
 *       "This product includes software developed by the
 *       Sun Microsystems, Inc. for Project JXTA."
 *    Alternately, this acknowledgment may appear in the software itself,
 *    if and wherever such third-party acknowledgments normally appear.
 *
 * 4. The names "Sun", "Sun Microsystems, Inc.", "JXTA" and "Project JXTA" must
 *    not be used to endorse or promote products derived from this
 *    software without prior written permission. For written
 *    permission, please contact Project JXTA at http://www.jxta.org.
 *
 * 5. Products derived from this software may not be called "JXTA",
 *    nor may "JXTA" appear in their name, without prior written
 *    permission of Sun.
 *
 * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
 * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED.  IN NO EVENT SHALL SUN MICROSYSTEMS OR
 * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
 * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
 * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
 * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 * ====================================================================
 *
 * This software consists of voluntary contributions made by many
 * individuals on behalf of Project JXTA.  For more
 * information on Project JXTA, please see
 * <http://www.jxta.org/>.
 *
 * This license is based on the BSD license adopted by the Apache Foundation.
 *
 * $Id: ModuleClassID.java,v 1.2 2001/11/03 00:06:12 jice Exp $
 */

package net.jxta.platform;

import net.jxta.id.ID;

/**
 * This interface defines a Module Class Identifier.
 * A ModuleClassID uniquely identifies a particular local behaviour, that is,
 * a specific API for each execution environment for which an implementation
 * exists.
 *
 * <p>
 * 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.
 *
 * <p>
 * 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.
 *
 * <p>
 * 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.
 *
 * <p>
 * A ModuleClassID is optionaly described by a published ModuleClassAdvertisement.
 *
 * <p>
 * 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.
 *
 * <p>
 * A ModuleSpecID embeds a base class identifier, which permits to verify that
 * a given Module specification is suitable for its intended use.
 *
 * @see net.jxta.peergroup.PeerGroup
 * @see net.jxta.platform.Module
 * @see net.jxta.platform.ModuleClassID
 * @see net.jxta.protocol.PeerAdvertisement
 * @see net.jxta.protocol.ModuleSpecAdvertisement
 * @see net.jxta.protocol.ModuleClassAdvertisement
 * @see net.jxta.endpoint.EndpointService
 * @see net.jxta.id.ID
 *
 * @version $Revision: 1.2 $
 * @since JXTA 1.0
 */
public abstract class ModuleClassID extends ID {

    /**
     * Returns true if this ModuleClassID is of the same base class than the
     * given class.
     * Note: This method is NOT named "isOfClass" because a ModuleClassID
     * may have two UUID; one that denotes a "base" class proper,
     * and an optional second one that denotes a "Role", or subclass.
     * Compatibility between ClassIDs is based on the "base" portion, hence the
     * "isOfSame" naming. This routine can be used for comparison with a base class
     * since a base class is just a class which role portion happens to be zero.
     *
     * @param id Module class id to compare with
     * @return boolean true if equals
     *
     * @version     $Revision: 1.2 $
     * @since JXTA 1.0
     */
    
    public abstract boolean isOfSameBaseClass ( ModuleClassID id );

    /**
     * Returns true if this ModuleClassID is of the same class than the
     * the given ModuleSpecID.
     *
     * @param id Module spec id to compare with
     * @return boolean true if equals
     *
     * @version     $Revision: 1.2 $
     * @since JXTA 1.0
     */
    
    public abstract boolean isOfSameBaseClass ( ModuleSpecID id );

    /**
     * Return a ModuleClassID of the same base class but with the role portion
     * set to zero. aka "the base class".
     *
     * @return ModuleClassID the base class.
     */

    public abstract ModuleClassID getBaseClass ( );
}