CORBA GIOP消息格式学习

想要深入理解ORB的工作过程与原理，学习与了解GIOP消息格式必不可少。我们知道GIOP是独立于具体通信的更高级别的抽象，因此这里针对GIOP在TCP/IP上的实现IIOP协议进行学习与分析（IIOP是规范中要求所有的ORB厂商都必要实现的协议，因此GIOP规范中也对IIOP协议进行了具体的定义）。

根据CORBA Specification的相关阐述，GIOP规范主要包括了以下三个方面：

1、Common Data Representation(CDR) definition（公共数据表达定义），CDR定义了IDL数据类型序列化为底层的byte流的规范。

2、GIOP Message Formats（GIOP消息格式），GIOP消息是ORB之间的通信最小单元。GIOP消息的类型有对象请求，对象定位和通信连接管理等等。

3、GIOP Transport Assumptions（GIOP传输层注意项，不知道这里翻译成”注意项“是否合适）。GIOP规范描述了一些底层协议的实现在传输GIOP消息时需要关注的事项，GIOP给出了一些假设/建议，另外规范还描述了应该如何去管理连接（建立与断开），保证GIOP消息顺序等等。

通常情况下我们并不会去关注第三点。

好了，我们一点一点学习以上三点（大部分情况下我只是作为规范的搬运工而已）。

Common Data Representation(CDR)：

CDR描述了IDL数据类型应该如何序列化。包括了以下几点：

1、Byte Ordering，也就是我们所说的大端小端，这里不多陈述大端小端的知识了，读者如有不懂可以自行baidu/google之。每个GIOP消息/Encapsulation（Encapsulation的阐述请点这里）都包含了一个用于标识大小端的标识。

2、Aligned Primitive Types基本类型（如int, short, string)的对齐，就像我们在c/c++接触到的内存对齐情况一样，如此可以使得我们更快地序列化/反序列化消息。

3、Complete OMG IDL Mapping完整的IDL类型映射：CDR描述了所有IDL类型的底层表示，除了基本类型以外，还包括了可以传输的pseudo-object（伪对象）比如TypeCodes（用于在DII和Any中表示参数的类型信息），Object Reference和异常等等（说它们是伪对象，是因为它们并不是真实的对象，而是对象的另一种表达，比如Object Reference可以用来传送一个对象，但Object Reference只是一个IOR）。

首先来看一下第二点，基本类型的序列化。

首先在边界对齐上，数据类型必须对齐到它的大小的倍数的位置上。比如依次序列化下面的struct：

module alignmenttest{
    struct TestStruct{
        short sa;
        short sb;
        char ca;
        char cb;
        long la;
    }
}

octet index-------------------
    0
    1            short sa
           -------------------
    2
    3            short sb
           -------------------
    4            char ca
           -------------------
    5            char cb
           -------------------
    6
    7
           -------------------
    8
    9
    10           long la
    11
           -------------------

这与我们的C语言在大部分机器的上的内存对齐规则是一致的。因此GIOP甚至可以不经过任何处理直接搬到内存中去就可以操作，使用。

Encapsulation

这里不知道怎么去翻译这个词，也许用”封装“比较合适吧，它就像是我们C语言中的struct，java中的class，代表一个集合，并且可以相互嵌套。GIOP规范这里所指的Encapsulation，还有以下两个含义：

1、Encapsulation与Encapsulation，Message之间的Byte Ordering可以是不相同的，即使它们之间是嵌套关系。

2、Encapsulation是一个抽象的表示，通常具体地它将会被编码成sequence<octet>，编码成sequence<octet>时，第一个octet代表着Byte Ordering。

Value Types

valuetype类似于一个加强版本的struct，但valuetype支持继承并且可以定义本地方法（包括构造函数）等而struct不支持，详细请看CORBA规范的说明。基于上面这些特性，在传输valuetype时候，需要包含valuetype的基类信息以便客户端进行向上转类等操作。在进行序列化的时候，需要首先序列化基类的元素，再序列化子类的元素。valuetype支持自定义序列化，但客户端和服务端的一致性由用户自己保证。需要注意的是，valuetype中的方法是作用于本地的，它并不会像interface中的方法论一样被传递到远程Servant。

Pseudo-Object Types 伪对象类型

这里主要说一下TypeCode，关于Object Reference的说明在后面IIOP消息中会有说明。TypeCode的作用上面已经提到，这里再重复一遍，TypeCode提供了一块数据中各个成员的信息，一般在确定动态类型Any的时候会用到。比如：

module...{
    interface...{
        void add(in long a, n long b, Any c);
    }
}

在运行时Any c的具体类型才可以得知，那么在传输c的时候，需要附上c的序列化结构信息，服务端才能正确地反序列化/还原c，我们可以看一下Any类型的序列化过程相关代码:

public class CDROutputStream_1_0 extends CDROutputStreamBase {
    ....
    public void write_any(Any any) {
        if (any == null) {
            throw wrapper.nullParam();
        }

        write_TypeCode(any.type());//首先写出TypeCode信息
        any.write_value(parent);//写出值信息。
    }
    ....
}

下面是写出TypeCode信息的相关代码，它根据当前any类型的_kind来写出相对应的信息。比如对应于struct类型，那么写出的TypeCode信息将包括struct中每个成员的类型信息，这可能是为了应对IDL在客户端与服务端不致的问题。

public final class TypeCodeImpl extends TypeCode {
    ....
    public void write_value(TypeCodeOutputStream tcos) {
        ...
        TypeCodeOutputStream topStream = tcos.getTopLevelStream();

        if (_kind == tk_indirect) {
            // The encoding used for indirection is the same as that used for recursive ,
            // TypeCodes i.e., a 0xffffffff indirection marker followed by a long offset
            // (in units of octets) from the beginning of the long offset.
            int pos = topStream.getPositionForID(_id);
            int topPos = tcos.getTopLevelPosition();
            tcos.writeIndirection(tk_indirect, pos);
            return;
        }

        tcos.write_long(_kind);

        // Bug fix 5034649:
        // Do this AFTER the write of the _kind in case the alignment
        // for the long changes the position.
        topStream.addIDAtPosition(_id, tcos.getTopLevelPosition()-4);

        switch (typeTable[_kind]) {
            case EMPTY:
                // nothing more to marshal
                break;

            case SIMPLE:
                switch (_kind) {
                    case TCKind._tk_string:
                    case TCKind._tk_wstring:
                        // marshal the bound on string length
                        tcos.write_long(_length);
                        break;

                    case TCKind._tk_fixed:
                        tcos.write_ushort(_digits);
                        tcos.write_short(_scale);
                        break;

                    default:
                        // unknown typecode kind
                        throw wrapper.invalidSimpleTypecode() ;
                }
                break;

            case COMPLEX:
                TypeCodeOutputStream _encap = tcos.createEncapsulation(tcos.orb());

                switch(_kind) {
                    case TCKind._tk_objref:
                    case TCKind._tk_abstract_interface:
                        _encap.write_string(_id);
                        _encap.write_string(_name);
                        break;

                    case TCKind._tk_union:
                        _encap.write_string(_id);
                        _encap.write_string(_name);
                        _discriminator.write_value(_encap);
                        _encap.write_long(_defaultIndex);
                        _encap.write_long(_memberCount);

                        for (int i=0; i < _memberCount; i++) {
                            if (i == _defaultIndex) {
                                _encap.write_octet(_unionLabels[i].extract_octet());
                            } else {
                                switch (realType(_discriminator).kind().value()) {
                                    case TCKind._tk_short:
                                        _encap.write_short(_unionLabels[i].extract_short());
                                        break;
                                    case TCKind._tk_long:
                                        _encap.write_long(_unionLabels[i].extract_long());
                                        break;
                                    case TCKind._tk_ushort:
                                        _encap.write_short(_unionLabels[i].extract_ushort());
                                        break;
                                    case TCKind._tk_ulong:
                                        _encap.write_long(_unionLabels[i].extract_ulong());
                                        break;
                                    case TCKind._tk_float:
                                        _encap.write_float(_unionLabels[i].extract_float());
                                        break;
                                    case TCKind._tk_double:
                                        _encap.write_double(_unionLabels[i].extract_double());
                                        break;
                                    case TCKind._tk_boolean:
                                        _encap.write_boolean(_unionLabels[i].extract_boolean());
                                        break;
                                    case TCKind._tk_char:
                                        _encap.write_char(_unionLabels[i].extract_char());
                                        break;
                                    case TCKind._tk_enum:
                                        _encap.write_long(_unionLabels[i].extract_long());
                                        break;
                                    case TCKind._tk_longlong:
                                        _encap.write_longlong(_unionLabels[i].extract_longlong());
                                        break;
                                    case TCKind._tk_ulonglong:
                                        _encap.write_longlong(_unionLabels[i].extract_ulonglong());
                                        break;
                                    case TCKind._tk_wchar:
                                        _encap.write_wchar(_unionLabels[i].extract_wchar());
                                        break;
                                    default:
                                        throw wrapper.invalidComplexTypecode() ;
                                }
                            }
                            _encap.write_string(_memberNames[i]);
                            _memberTypes[i].write_value(_encap);
                        }
                        break;

                    case TCKind._tk_enum:
                        _encap.write_string(_id);
                        _encap.write_string(_name);
                        _encap.write_long(_memberCount);

                        for (int i=0; i < _memberCount; i++) {
                            _encap.write_string(_memberNames[i]);
                        }
                        break;

                    case TCKind._tk_sequence:
                        lazy_content_type().write_value(_encap);
                        _encap.write_long(_length);
                        break;

                    case TCKind._tk_array:
                        _contentType.write_value(_encap);
                        _encap.write_long(_length);
                        break;

                    case TCKind._tk_alias:
                    case TCKind._tk_value_box:
                        _encap.write_string(_id);
                        _encap.write_string(_name);
                        _contentType.write_value(_encap);
                        break;

                    case TCKind._tk_struct:
                    case TCKind._tk_except:
                        _encap.write_string(_id);
                        _encap.write_string(_name);
                        _encap.write_long(_memberCount);

                        for (int i=0; i < _memberCount; i++) {
                            _encap.write_string(_memberNames[i]);
                            _memberTypes[i].write_value(_encap);
                        }
                        break;

                    case TCKind._tk_value:
                        _encap.write_string(_id);
                        _encap.write_string(_name);
                        _encap.write_short(_type_modifier);

                        if (_concrete_base == null) {
                            _orb.get_primitive_tc(TCKind._tk_null).write_value(_encap);
                        } else {
                            _concrete_base.write_value(_encap);
                        }

                        _encap.write_long(_memberCount);

                        for (int i=0; i < _memberCount; i++) {
                            _encap.write_string(_memberNames[i]);
                            _memberTypes[i].write_value(_encap);
                            _encap.write_short(_memberAccess[i]);
                        }
                        break;

                    default:
                        throw wrapper.invalidTypecodeKindMarshal() ;
                }

                // marshal the encapsulation
                _encap.writeOctetSequenceTo(tcos);
                break;
        }
    }
    ...
}

Object Reference，对象引用

传送对象引用一般情况下传送它的IOR就可以了，IOR至少包含了以下信息：

1、版本信息，以保证低版本的ORB不会乱去解析高版本的IOR表示。

2、传输层面对象宿主机器的地址。

3、对象ID，用于唯一定位目标对象 。

Abstract Interface，抽象接口

Abstract Interface是一种比较特殊的类型，它是一个方法集合，interface和valuetype类型可以继承它，比如：

abstract interface Describable {
string get_description();
};
interface Example {
void display (in Describable anObject);
};
interface Account : Describable {// passed by reference
// add Account methods here
};
valuetype Currency supports Describable {// passed by value
// add Currency methods here
};

如上面，如果在运行时anObject参数是Account，那么在序列化的时候，首先用一个boolean为true的值以表明它是一个Object Reference，然后紧接着这个对象的IOR。

---------------
   TRUE
---------------
   IOR
---------------

如果在运行时anObject参数是Currency，那么在序列化的时候，首先用一个boolean为false值以表明它是一个valuetype，然后紧接着它的值。

---------------
   FALSE
---------------
   Value
---------------

GIOP消息格式

首先我们来看一下GIOP消息的IDL声明：

module GIOP { // IDL extended for version 1.1 and 1.2
    struct Version {
    octet major;
    octet minor;
    };

    #ifndef GIOP_1_1
    // GIOP 1.0
    enum MsgType_1_0 { // Renamed from MsgType
        Request, Reply, CancelRequest,
        LocateRequest, LocateReply,
        CloseConnection, MessageError
    };
    #else

    // GIOP 1.1
    enum MsgType_1_1 {
        Request, Reply, CancelRequest,
        LocateRequest, LocateReply,
        CloseConnection, MessageError,
        Fragment
    // GIOP 1.1 addition
    };

    #endif // GIOP_1_1

    // GIOP 1.0
    struct MessageHeader_1_0 { // Renamed from MessageHeader
        char magic [4];
        Version GIOP_version;
        boolean byte_order;
        octet message_type;
        unsigned long message_size;
    };

    // GIOP 1.1
    struct MessageHeader_1_1 {
        char magic [4];
        Version GIOP_version;
        octet flags;
        // GIOP 1.1 change
        octet message_type;
        unsigned long message_size;
    };

    // GIOP 1.2
    typedef MessageHeader_1_1 MessageHeader_1_2;
};

magic表明这是一个GIOP消息，它的值为字符串GIOP的byte："GIOP".getBytes("ISO8859-1")

GIOP_Version包含这个消息所使用的GIOP协议的版本信息，需要注意的是，它和IIOP版本号是两码事，虽然它们的IDL描述是一样的

byte_order只在GIOP 1.0版本中被使用，它指定后面元素如message_size（比如占据4个字节整形）是大端表示还是小端表示的。

flags在GIOP 1.1和1.2版本中使用，它和byte_ordfer一样都只占据一个字节，只不过flag中用bit表示一些信息：

|7|6|5|4|3|2|1|0|
 | | | | | | | |
 | | | | | | | ->byte order, 0: big-endian, 1: little-endian
 | | | | | | ---->后面是否还有fragments, 0: No, 1: Yes
 ---------------->保留

message_type，它的值表明了消息的类型，下面是消息类型的列表。

Message Type	Originator	Value	GIOP Versions
Request	Client	0	1.0, 1.1, 1.2
Reply	Server	1	1.0, 1.1, 1.2
CancleRequest	Client	2	1.0, 1.1, 1.2
LocateRequest	Client	3	1.0, 1.1, 1.2
LocateReply	Server	4	1.0, 1.1, 1.2
CloseConnection	Server	5	1.0, 1.1, 1.2
MessageError	Both	6	1.0, 1.1, 1.2
Fragment	Both	7	1.1, 1.2

message_size表明消息头后面的还有多个字节 （消息体Message Body的长度，不包括12个字节的消息头），这是一个unsigned long类型，它的字节顺序与上面byte_order域与flags域所指定的字节顺序是一致的。注意对于GIOP1.2，message_size + 12（消息头长度）的和一定需要可以被8整除（也许为了内存对齐）。

下面介绍一下消息类型，因为篇幅原因，这里只对Request Message和Reply Message介绍。

Request Message

Request Header的IDL定义：

module GIOP { // IDL extended for version 1.1 and 1.2

    // GIOP 1.0
    struct RequestHeader_1_0 { // Renamed from RequestHeader
        IOP::ServiceContextList
        service_context;
        unsigned long request_id;
        boolean response_expected;
        sequence <octet> object_key;
        string operation;
        Principal requesting_principal;
    };

    // GIOP 1.1
    struct RequestHeader_1_1 {
        IOP::ServiceContextList service_context
        unsigned long request_id;
        octet reserved[3];
        sequence<octet> object_key;
        string operation;
        Principal requesting_principal;
    };

    // GIOP 1.2
    typedef short AddressingDisposition;
    const short KeyAddr=0;
    const short ProfileAddr=1;
    const short ReferenceAddr=2;

    struct IORAddressingInfo {
        unsigned long selected_profile_index;
        IOP::IOR      ior;
    };

    union TargetAddress switch (AddressingDisposition) {
        case KeyAddr: sequence<octet> object_key;
        case ProfileAddr: IOP::TaggedProfile profile;
        case ReferenceAddr: IORAddressingInfo ior;
    };

    struct RequestHeader_1_2 {
        unsigned long request_id;
        octet response_flags;
        octet reserved[3];
        TargetAddress target;
        string operation;
        IOP::ServiceContextList service_context;
        // Principal not in GIOP 1.2
    };
};

request_id用于将服务器的响应信息与客户端发送的请求信息对应起来，因为客户端的同时可能向服务端发送多个对象的请求，而它们可以共用一个连接，服务器返回的信息将包含客户端发送的request_id，客户端利用request_id来完成响应信息的分发。

response_flags用于表示此请求是否需要返回值，它的最低位是1的话表示需要返回值，如何需要返回值，并且在DII中INV_NO_RESPONSE标志位没有被设置，那么response_flags必须设置为0x03。

如果此请求不需要返回值，或者在DII调用中设置了INV_NO_RESPONSE标志位，那么response_flags可以设置为0x00或者0x01

reserved的值应该设置为，它为未来保留使用。

object_key，在GIOP 1.0和1.1中，用于标识服务端的目标对象，它其实就是IOR IIOPProfile中的object_key的值。

target，但从GIOP 1.2开始，更换为使用target域来标识调用的目标。

operation是idl中定义的interface中的目标方法名。

service_context包含了从客户端传递到服务端的Service Context信息。

requesting_principal，在GIOP 1.0和GIOP 1.1版本中，它包含了关于客户端身份信息的类，用于访问控制和其它目的。在它已经被弃用，并且在GIOP 1.2中不再包含这部分信息。

Request Body

在GIOP 1.0和1.1中，Request Body被序列化成Encapsulation并立即被附在消息头的后面。从GIOP 1.2开始，Request Body的开始位置是对齐到8字节的，如果消息头被修改之后，Request Body不需要重新序列化。Request包括了以下几项内容（按顺序序列化）：

1、所有的in和inout参数，按照它们在方法参数中出现的先后顺序（从左到右）。

2、可选的Context pseudo object（Context伪对象），这些Context pseudo object被序列化成sequence<String>，每个Context pseudo object被序列化成一对String，Property Name和Property Value。只有操作的IDL定义包含有一个Conext Expression的情况下才会出现Context pseudo object，并且只会包含Context Expression中声明的成员。

比如下面方法的

double example(in short m, out string str, inout p)

它的Request Body的将会是下面的结构：

struct example_body{
    short m;
    long p;
}

Reply Message

只有Request Message中的response expected位被设置为TRUE的情况下，服务器才会发送对应的Reply Message。Reply Message包括了所有的inout和out参数，并且可以包含有异常值。同样Reply Message包括了Reply Header和Reply Body两部分。

Reply Header

首先来看一下它的IDL定义：

module GIOP { // IDL extended for 1.2

#ifndef GIOP_1_2
    // GIOP 1.0 and 1.1
    enum ReplyStatusType_1_0 { // Renamed from ReplyStatusType
    NO_EXCEPTION,
    USER_EXCEPTION,
    SYSTEM_EXCEPTION,
    LOCATION_FORWARD
    };

    // GIOP 1.0
    struct ReplyHeader_1_0 { // Renamed from ReplyHeader
        IOP::ServiceContextList service_context;
        unsigned long           request_id;
        ReplyStatusType_1_0     reply_status;
    };

    // GIOP 1.1
    typedef ReplyHeader_1_0 ReplyHeader_1_1;
    // Same Header contents for 1.0 and 1.1
#else
    // GIOP 1.2
    enum ReplyStatusType_1_2 {
        NO_EXCEPTION,
        USER_EXCEPTION,
        SYSTEM_EXCEPTION,
        LOCATION_FORWARD,
        LOCATION_FORWARD_PERM,// new value for 1.2
        NEEDS_ADDRESSING_MODE // new value for 1.2
    };

    struct ReplyHeader_1_2 {
        unsigned long          request_id;
        ReplyStatusType_1_2    reply_status;
        IOP:ServiceContextList service_context
    };
#endif // GIOP_1_2
};

request_id用于把Reply Message与对应的Request Message关联起来，并不是每个对象的请求会单独占用整个连接，多个对象的请求可以通过单个连接发送到服务端。Reply Message中的request_id与对应的Request Message中的request_id的值是一致的。

reply_status用于表示对应请求的完成状态和Reply Body的内容 ，如何方法请求调用成功完成，那么它的值是NO_EXCEPTION，并且Reply Body中包含返回值。否则Reply Body中的内容将会是：

1、异常值。

2、要求客户端重发请求到另一个服务端地址上的对象。

3、要求客户端提供更多用于定位对象的信息。

service_context包含了服务端发送给客户端的ORB service信息

Reply Body

和Request Body一样，在GIOP 1.0和1.1中，Reply Header紧接着就是Reply Body。从GIOP 1.2开始，Reply Body的起始位置需要对齐到8字节。Reply Body的内容由Reply Header中的reply_status的值决定：

如果reply_status的值为NO_EXCEPTION，那么Reply Body首先序列化返回值，然后是IDL方法定义中的out和inout参数（从左到右顺序），如下面方法

double example(in short m, out string str, inout long p)

那么该方法请求在NO_EXCEPTION的情况下的返回值为：

struct{
    return double;
    string str;
    long p;
}

如果reply_status为USER_EXCEPTION或者SYSTEM_EXCEPTION的话，那么reply body包含方法抛出的异常值。

当reply_status为SYSTEM_EXCEPTION，那么reply body的结构如下：

module GIOP { // IDL
    struct SystemExceptionReplyBody {
        string     exception_id;
        unsigned long minor_code_value;
        unsigned long completion_status;
    };
};

minor_code_value的高20位表示厂商Minor Codeset ID（VMCID），低12位表示minor code。一些厂商（可以是多个）可能想定义一些特有的异常MInor code，那么它们应该向OMG去申请这个VMCID。注意OMG标准的VMCID为0x4f4d0（'O', 'M'）。

如果reply_status的值为LOCATION_FORWARD的话，那么Reply Body包含了一个对象的IOR，然后客户端ORB负责将原来的请求重新发送到这个IOR指定的对象上，这个过程对于客户端应用程序是透明的（客户端并不能知道这些过程）。

如果replay_status的值为LOCATION_FORWARD_PERM，它的行为表现和LOCATION_FORWARD几乎是一样的，另外它被服务器用来向客户端表明 ，它可能要将当前对象的IOR替换成新的，并且新的IOR和旧的还是有效的，但推荐使用新的。

如果reply_status的值为NEED_ADDRESSING_MODE的话，Reply Body包括了一个GIOP::AddressingDisposition，客户端负责使用request addressing mode(提供更多对象信息)重新发送请求到这个对象上。同样的，重发过程对于用于程序是透明的，ORB并不会通知客户端的程序这个过程。

completion_state根据Standard Exception Definitions的IDL定义，它有COMPLETED_YES, COMPLETED_NO, COMPLETED_MAYBE三种状态。