The IIOP marshaling specifications are an instance of the GIOP marshaling specifications, specialized for use with IIOP transports. In particular, the manipulated IORs typically support an IIOP profile, which specifies a TCP/IP address. Those aspects of IIOP marshaling that are independent of IIOP are contained in SstGiopMarshaling. This includes the type codes and Common Data Representation (CDR) streams. The IIOP-specific aspects are contained in SstIiopSupport.

In general, since a CORBA object is of a particular type (specified by an interface in the IDL repository), every operation that can be performed on the object is well-typed. As such, the type of each parameter and the result type of the operation is known. This information is used in the marshaling and unmarshaling of requests and replies.

IDL allows parameters to be specified as in, out, or inout parameters. Since standard Smalltalk semantics allow for only a single operation result (reply object), out and inout parameters must be passed such that they can be destructively modified and thus their values implicitly returned. The Smalltalk language binding specifies that this be done by wrapping parameters in a CORBAParameter object. The parameter wrapper holds the current parameter value and responds to value and value:.

SST fully supports this and, on method invocation, any out or inout parameters are automatically wrapped (if not already wrapped). You can manually wrap parameters using asCORBAParameter, which is supported by all objects.

Marshaling of most objects proceeds directly according to the type specification for the operation being performed. Before each object is marshaled, it is sent the sstGiopMarshalingValue: method. This operation allows the object to declare an alternative representation of itself to be marshaled. For example, IDL struct types are required to be instances of Dictionary. However, if a user object knows that it is to be marshaled as an IDL struct, it can create a Dictionary instance of itself. At present, there is no mechanism to automatically create the required user class object from an object defined to be an IDL struct.

In certain circumstances, however, it is impossible for SST to automatically determine how an object should be marshaled. For example, when marshaling an IDL any value, the type of the object is unknown. In order to manage these situations, SST requires that the method sstIdlTypeId be defined for all objects that may be passed as parameters or return values. The method should answer the repository ID of the interface to which the object conforms in the IDL repository specified for the context. When an object is marshaled, it is converted into an IOR with an IIOP profile, such that the typeId field of the IOR is set to the object's sstIdlTypeId value. This conversion is performed by the sstAsIorInContext: method.

Most unmarshaling proceeds directly according to the IDL-to-Smalltalk mapping definition and the type specification for the operation performed. However, IORs are converted automatically into instances of SstGiopRemoteReference, with an associated SstIor instance, to allow for seamless integration with SST's normal mechanisms for method invocation.