5.6 Access to the Sending Context Run Time

   There are two cases where a receiving context might want to access the run time environment of the sending context:

• To attempt the downloading of some missing implementation for the value.

• To access some meta information about the version of the value just received.

   In order to provide that kind of service a call back object interface is defined. It may optionally be supported by the sending context (it can be seen as a service). If such a callback object is supported its IOR may be added to an optional service context in the GIOP header passed from the sending context to the receiving context.

   A service context tagged with the ServiceID SendingContextRunTime (see Section 13.7, “Service Context,? on page 13-28) contains an encapsulation of the IOR for a SendingContext::RunTime object. Because ORBs are always free to skip a service context they don’t understand, this addition does not impact IIOP interoperability.

   module SendingContext {

   interface RunTime {}; // so that we can provide more // sending context run time // services in the future

   interface CodeBase: RunTime { typedef string URL; // blank-separated list of one or more URLs typedef sequence<URL> URLSeq; typedef sequence

   <CORBA::ValueDef::FullValueDescription> ValueDescSeq;

   // Operation to obtain the IR from the sending context CORBA::Repository get_ir();

   // Operations to obtain a location of the implementation codeURL implementation(in CORBA::RepositoryId x);URLSeq implementations(in CORBA::RepositoryIdSeq x);

   // Operations to obtain complete meta information about a Value// This is just a performance optimization the IR can provide// the same informationCORBA::FullValueDescription meta(in CORBA::RepositoryId x);ValueDescSeq metas(in CORBA::RepositoryIdSeq x);

   // To obtain a type graph for a value type// same comment as before the IR can provide similar// informationCORBA::RepositoryIdSeq bases(in CORBA::RepositoryId x);

   };};

   Supporting the CodeBase interface for a given ORB run time is an issue of quality of service. The point here is that if the sending context does not support a CodeBase, then the receiving context will simply raise an exception with which the sending context had to be prepared to deal. There will always be cases where a receiving context will get a value type and won’t be able to interpret it because:

• It can’t get a legal implementation for it (even if it knows where it is, possibly due to security and/or resource access issues).

• Its local version is so radically different that it cannot make sense out of the piece of state being provided.

   These two failure modes will be represented by the CORBA system exception NO_IMPLEMENT with identified minor codes, for a missing local value implementation and for incompatible versions (see Section 4.12.4, “Standard Minor Exception Codes,? on page 4-73).

   Under certain conditions it is possible that when several values of the same CORBA type (same repository id) are sent in either a request or reply, that the reality is that they have distinct implementations. In this case, in addition to the codebase URL(s) sent in the service context, each value that has a different codebase may have codebase URL(s) associated with it. This is encoded by using a different tag to encode the value on the wire.

   The sending context does not need to resend the same value for this service context on subsequent requests over the same underlying connection. Resending a different value for this service context is only necessary if the callback object reference in use is changed by the sending context within the lifetime of the underlying connection.