trader_interfaces.h

这是广泛使用的通信开源项目,对于大容量,高并发的通讯要求完全能够胜任,他广泛可用于网络游戏医学图像网关的高qos要求.更详细的内容可阅读相应的材料

/* -*- C++ -*- */

//=============================================================================
/**
 *  @file    Trader_Interfaces.h
 *
 *  Trader_Interfaces.h,v 1.26 2003/07/21 23:51:33 dhinton Exp
 *
 *  @author Marina Spivak <[e-mail]>
 *  @author Seth Widoff <[e-mail]>
 *  @author Irfan Pyarali <[e-mail]>
 */
//=============================================================================


#ifndef TAO_TRADER_INTERFACES_H
#define TAO_TRADER_INTERFACES_H
#include /**/ "ace/pre.h"

#include "Trader_Utils.h"
#include "Constraint_Interpreter.h"
#include "Offer_Iterators_T.h"

#if defined(_MSC_VER)
#if (_MSC_VER >= 1200)
#pragma warning(push)
#endif /* _MSC_VER >= 1200 */
#pragma warning(disable:4250)
#endif /* _MSC_VER */

// Hack because g++ forced this inane circular dependecy!

class TAO_Constraint_Interpreter;
class TAO_Constraint_Evaluator;
class TAO_Constraint_Validator;
class TAO_Preference_Interpreter;

template <class TRADER_LOCK_TYPE, class MAP_LOCK_TYPE> class TAO_Lookup;
template <class TRADER_LOCK_TYPE, class MAP_LOCK_TYPE> class TAO_Register;
template <class TRADER_LOCK_TYPE, class MAP_LOCK_TYPE> class TAO_Admin;
template <class TRADER_LOCK_TYPE, class MAP_LOCK_TYPE> class TAO_Proxy;
template <class TRADER_LOCK_TYPE, class MAP_LOCK_TYPE> class TAO_Link;

#include "Trader_T.h"

/**
 * @class TAO_Lookup
 *
 * @brief This class implements CosTrading::Lookup IDL interface.
 */
template<class TRADER_LOCK_TYPE, class MAP_LOCK_TYPE>
class TAO_Lookup :
  public TAO_Trader_Components<POA_CosTrading::Lookup>,
  public TAO_Support_Attributes<POA_CosTrading::Lookup>,
  public TAO_Import_Attributes<POA_CosTrading::Lookup>
{
public:

  TAO_Lookup (TAO_Trader<TRADER_LOCK_TYPE,MAP_LOCK_TYPE> &trader);

  ~TAO_Lookup (void);

  virtual void
    query (const char *type,
           const char *constr,
           const char *pref,
           const CosTrading::PolicySeq& policies,
           const CosTrading::Lookup::SpecifiedProps& desired_props,
           CORBA::ULong how_many,
           CosTrading::OfferSeq_out offers,
           CosTrading::OfferIterator_out offer_itr,
           CosTrading::PolicyNameSeq_out limits_applied
           ACE_ENV_ARG_DECL)
    ACE_THROW_SPEC ((CORBA::SystemException,
                    CosTrading::IllegalServiceType,
                    CosTrading::UnknownServiceType,
                    CosTrading::IllegalConstraint,
                    CosTrading::Lookup::IllegalPreference,
                    CosTrading::Lookup::IllegalPolicyName,
                    CosTrading::Lookup::PolicyTypeMismatch,
                    CosTrading::Lookup::InvalidPolicyValue,
                    CosTrading::IllegalPropertyName,
                    CosTrading::DuplicatePropertyName,
                    CosTrading::DuplicatePolicyName));

  // BEGIN SPEC
  // The query operation is the means by which an object can obtain
  // references to other objects that provide services meeting its
  // requirements.

  // The "type" parameter conveys the required service type. It is key
  // to the central purpose of trading: to perform an introduction for
  // future type safe interactions between importer and exporter. By
  // stating a service type, the importer implies the desired interface
  // type and a domain of discourse for talking about properties of the
  // service.

  // The trader may return a service offer of a subtype of the "type"
  // requested. Sub-typing of service types is discussed in "Service
  // Types" on page 16-4. A service subtype can be described by the
  // properties of its supertypes. This ensures that a well-formed
  // query for the "type" is also a well-formed query with respect to
  // any subtypes. However, if the importer specifies the policy of
  // exact_type_match = TRUE, then only offers with the exact (no
  // subtype) service type requested are returned.

  // The constraint "constr" is the means by which the importer states
  // those requirements of a service that are not captured in the
  // signature of the interface. These requirements deal with the
  // computational behavior of the desired service, non-functional
  // aspects, and non-computational aspects (such as the organization
  // owning the objects that provide the service). An importer is
  // always guaranteed that any returned offer satisfies the matching
  // constraint at the time of import. If the "constr" does not obey
  // the syntax rules for a legal constraint expression, then an
  // IllegalConstraint exception is raised.

  // The "pref" parameter is also used to order those offers that
  // match the "constr" so that the offers returned by the trader are
  // in the order of greatest interest to the importer. If "pref" does
  // not obey the syntax rules for a legal preference expression, then
  // an IllegalPreference exception is raised.

  // The "policies" parameter allows the importer to specify how the
  // search should be performed as opposed to what sort of services
  // should be found in the course of the search. This can be viewed
  // as parameterizing the algorithms within the trader
  // implementation. The "policies" are a sequence of name-value
  // pairs. The names available to an importer depend on the
  // implementation of the trader. However, some names are
  // standardized where they effect the interpretation of other
  // parameters or where they may impact linking and federation of
  // traders.

  // The "desired_props" parameter defines the set of properties
  // describing returned offers that are to be returned with the
  // object reference. There are three possibilities, the importer
  // wants one of the properties, all of the properties (but without
  // having to name them), or some properties (the names of which are
  // provided).

  // The desired_props parameter does not affect whether or not a
  // service offer is returned. To avoid "missing" desired properties,
  // the importer should specify "exists prop_name" in the
  // constraint.

  // The returned offers are passed back in one of two ways (or a
  // combination of both). 癟he "offers" return result conveys a list
  // of offers and the "offer_itr" is a reference to an interface at
  // which offers can be obtained. The "how_many" parameter states
  // how many offers are to be returned via the "offers" result, any
  // remaining offers are available via the iterator interface. If the
  // "how_many" exceeds the number of offers to be returned, then the
  // "offer_itr" will be nil.

  // If any cardinality or other limits were applied by one or more
  // traders in responding to a particular query, then the
  // "limits_applied" parameter will contain the names of the policies
  // which limited the query. The sequence of names returned in
  // "limits_applied" from any federated or proxy queries must be
  // concatenated onto the names of limits applied locally and
  // returned.
  // END SPEC

private:

  /// Factory method for creating an appropriate Offer Iterator based
  /// on the presence of the Register Interface.
  TAO_Offer_Iterator* create_offer_iterator (const TAO_Property_Filter&);

  /// Traverse the type hierarchy to pull the matching offers from all
  /// subtypes of the root type.
  void lookup_all_subtypes (const char* type,
                            CosTradingRepos::ServiceTypeRepository::IncarnationNumber& inc_num,
                            TAO_Offer_Database<MAP_LOCK_TYPE>& offer_database,
                            CosTradingRepos::ServiceTypeRepository_ptr rep,
                            TAO_Constraint_Interpreter& constr_inter,