CORBA, GIOP, IIOP, ORB, IOR

http://www.cnblogs.com/luluping/archive/2010/02/09/1666183.html

http://blog.chinaunix.net/uid-20387638-id-1952964.html

http://wenku.baidu.com/view/ea7746671ed9ad51f01df246.html

http://zh.wikipedia.org/zh-cn/CORBA

http://wenku.baidu.com/view/056e4944b307e87101f69654.html

• CORBA（Common Object Request Broker Architecture）
  • CORBA（Common Object Request Broker Architecture,公共对象请求代理体系结构）是OMG(对象管理组织)的分布式对象应用标准，其核心————对象请求代理ORB是在对象间建立客户/服务器对象关系的中间件。
  • CORBA是基于面向对象技术。
  • 
    
  • CORBA上的服务用IDL描述，IDL将被映射为某种程序设计语言如C++或Java，并且分成两分，在客户方叫IDL Stub（桩）, 在服务器方叫IDL Skeleton（骨架）。两者可以采用不同的语言。服务器方在Skeleton的基础上编写对象实现(Object Implementation)，而客户方要访问服务器对象上的方法，则要通过客户桩。而双方又要通过而ORB（Object Request Broker，对象请求代理）总线通信。
  • 与传统的Client/Server模式（我们称为Two-tier client/server）不同，CORBA是一种multi-tier client/server architecture，更确切的说，是一种three-tier client/server模式。双重客户/服务器模式存在的问题是两者耦合太紧，它们之间采用一种私有协议通信，服务器的改变将影响到客户方。多重客户/服务器与此不同，两者之间的通信不能直接进行，而需要通过中间的一种叫代理的方式进行。在CORBA中这种代理就是ORB。通过它，客户和服务器不再关心通信问题，它们只需关心功能上的实现。从这个意义上讲，CORBA是一种中间件(Middleware)技术。
  • Stub code 和Skeleton Code 是由IDL Complier自动生成的，前者放在客户方，后者放在服务器方。
  • 
    
  • 现在存在众多CORBA实现，既有商用的ORBacus、VisiBroker，也有一些优秀的开源实现，如：TAO、omniORB、MICO等。
  • 支持的服务: Naming、Event、Notification、Security、Time、Scheduling、Logging、Lifecycle、Trading、Concurrency、Lifecycle、A/V Streaming、Load balancing等。OMG Naming Service is the simplest and most basic of the standardized CORBA services.
    
  • Object Adapter (对象适配器)
    对象适配器是ORB的一部分。它主要完成对象引用的生成、维护，对象定位等功能。对象适配器有各种各样。Basic Object Adapter(BOA, 基本对象适配器)实现了对象适配器的一些核心功能。而Portable Object Adapter（POA，可移植对象适配器）则力图解决对象实现在不同厂商的ORBs下也能使用的问题。最新的ORB产品一般都支持POA。
    
  • 
    
  • GIOP架构提供了如下具体协议：详见ACE/ACE_wrappers/TAO/docs/ORBEndpoint.html。格式如protocol://V.v@addr1,...,W.w@addrN。V.v and W.w 是可选的版本号。-ORBListenEndpoints 'iiop://foo:1234/option1=value1&option2=value2'
    • 因特网 ORB 间协议 (IIOP) — 定义了基于因特网的GIOP实现，提供了TCP/IP到GIOP的映射。-ORBListenEndpoints iiop://V.v@hostname1:port1,...,W.w@hostname2:port2。格式可能如下：
      • -ORBListenEndpoints iiop://foo2:1234
      • -ORBListenEndpoints iiop://foo2:my_protocol ------ my_protocol能通过/etc/services解析
      • -ORBListenEndpoints iiop:// 
      • -ORBListenEndpoints iiop://:1234 ------- 所有interface
      • -ORBListenEndpoints iiop://192.168.10.24:1234
      • -ORBListenEndpoints iiop://[01ef::1]:123 -ORBListenEndpoints iiop://[01ef::1:123]  只有大于1.2的版本才支持IPv6.
    • 加密 ORB 间协议 (SSLIOP) — SSLIOP是基于SSL加密层的IIOP，提供了加密和认证。使用TLS。如-ORBListenEndpoints iiop://foo:1234/ssl_port=1235。
    • 超文本 ORB 间协议 (HTIOP) — HTIOP是基于HTTP的IIOP，提供了透明代理穿越
    • DIOP --- 使用UDP，必须制定端口。如-ORBListenEndpoints diop://1.0@foo1:2345
    • UIOP --- 使用unix domain socket
    • shmiop --- 使用共享内存作为传输机制，如-ORBListenEndpoints shmiop://
  • 
    

• GIOP(General Inter-ORB Protocol)，IIOP（Internet Inter-ORB Protocol）
  • GIOP为ORB之间的通信指定了一套消息格式和公共数据表示，使CORBA可以在不同的操作系统和编程语言的环境下实现客户和服务器对象的互操作。
  • GIOP 不基于任何特别的网络协议，如 IPX 或 TCP/IP。为了确保互操作性，OMG 必须将 GIOP 定义在所有供应商都支持的特定传输之上。
  • 如果使用 GIOP 的结构和格式，并将它们应用于 TCP/IP，那么就得到 IIOP（Internet Inter-ORB Protocol）。
  • GIOP消息格式：
    • 客户机将发送消息类型 Request、LocateRequest、CancelRequest、Fragment 和 MessageError。
    • 服务器可以发送消息类型 Reply、LocateReply、CloseConnection、Fragment 和 MessageError。
  • IIOP当前支持有1.0，1.1，1.2。
    • GIOP 1.1 添加了对消息存储碎片的支持；
    • GIOP 1.2 添加了双向通信支持；
    • 更新的版本都是向下兼容的；
• IOR 可互操作对象引用(Interoperable Object Reference)

提供了关于类型、协议支持和可用ORB服务的信息。ORB创建、使用并维护该IOR.

IOR对IIOP是至关重要的，任何要对某个对象调用方法的客户机都要将“请求”消息发送到IOR中详细说明的主机和端口地址。在主机上，服务器进程在请求进入时会监听端口，并将那些信息发送到对象，这就要求服务器主动监听请求。

• naming service：

http://blog.csdn.net/billdavid/article/details/726351

直接将IOR串在程序间传递的做法往往比较不方便，特别是，对于非持久servant来说，每次重启Server程序时，这个IOR都会发生变化，在使用上比较不便，而且，当我们需要访问的servant不是一个，而是多个时，使用IOR就更加不便了。为此，CORBA定义了Naming Service服务，命名服务（Naming Service，不过大家叫的更多的是命名服务）是CORBA最基本的服务之一。Server程序将servant注册到Naming Service中，Client程序就可以借助助记符，而不是一大串IOR来访问到相应的Servant了。
TAO对标准的名字服务进行了扩展，使得可以利用multicast来得到名字服务。此外，TAO还提供了NT_Naming_Service，可以将名字服务注册为NT服务进行管理。

CORBA ORB_init需要参数和naming service参数需要匹配。如-ORBEndpoint IIOP://vmw:12345 -ORBInitRef NameService=corbaloc:iiop:vmw:12346/NameService -ORBDebug -ORBCollocation no

• 举例：

Corba/ACE_TAO/bin64-# ls -l

total 9800

-rwxr-xr-x 1 ainet snlog 266567 Feb 17  2012 Basic_Logging_Service

-rwxr-xr-x 1 ainet snlog 163942 Feb 17  2012 Concurrency_Service

-rwxr-xr-x 1 ainet snlog 133463 Feb 17  2012 CosEvent_Service

-rwxr-xr-x 1 ainet snlog 134587 Feb 17  2012 Dump_Schedule

-rwxr-xr-x 1 ainet snlog 271250 Feb 17  2012 Event_Logging_Service

-rwxr-xr-x 1 ainet snlog 263256 Feb 17  2012 Event_Service

-rwxr-xr-x 1 ainet snlog 778520 Feb 17  2012 FT_ReplicationManager

-rwxr-xr-x 1 ainet snlog 539623 Feb 17  2012 Fault_Detector

-rwxr-xr-x 1 ainet snlog 376750 Feb 17  2012 Fault_Notifier

-rwxr-xr-x 1 ainet snlog 284600 Feb 17  2012 IFR_Service

-rwxr-xr-x 1 ainet snlog 130401 Feb 17  2012 ImR_Activator

-rwxr-xr-x 1 ainet snlog  94343 Feb 17  2012 ImplRepo_Service

-rwxr-xr-x 1 ainet snlog 453675 Feb 17  2012 LifeCycle_Service

-rwxr-xr-x 1 ainet snlog 450104 Feb 17  2012 LoadManager

-rwxr-xr-x 1 ainet snlog 514543 Feb 17  2012 LoadMonitor

-rwxr-xr-x 1 ainet snlog 150798 Feb 17  2012 Naming_Service

-rwxr-xr-x 1 ainet snlog 279926 Feb 17  2012 Notify_Logging_Service

-rwxr-xr-x 1 ainet snlog 110583 Feb 17  2012 Notify_Service

-rwxr-xr-x 1 ainet snlog 272105 Feb 17  2012 RTEvent_Logging_Service

-rwxr-xr-x 1 ainet snlog 651712 Feb 17  2012 Scheduling_Service

-rwxr-xr-x 1 ainet snlog  64036 Feb 17  2012 TAO_Service

-rwxr-xr-x 1 ainet snlog 259834 Feb 17  2012 Time_Service_Clerk

-rwxr-xr-x 1 ainet snlog 218885 Feb 17  2012 Time_Service_Server

-rwxr-xr-x 1 ainet snlog 139840 Feb 17  2012 Trading_Service

-rwxr-xr-x 1 ainet snlog 309842 Feb 17  2012 ace_gperf

-rwxr-xr-x 1 ainet snlog 247314 Feb 17  2012 ftrt_eventservice

-rwxr-xr-x 1 ainet snlog 385886 Feb 17  2012 ftrtec_factory_service

-rwxr-xr-x 1 ainet snlog 193622 Feb 17  2012 ftrtec_gateway_service

-rwxr-xr-x 1 ainet snlog 160601 Feb 17  2012 tao_catior

-rwxr-xr-x 1 ainet snlog 243899 Feb 17  2012 tao_idl

-rwxr-xr-x 1 ainet snlog 264636 Feb 17  2012 tao_ifr

-rwxr-xr-x 1 ainet snlog 416157 Feb 17  2012 tao_imr

-rwxr-xr-x 1 ainet snlog 147812 Feb 17  2012 tao_nsadd

-rwxr-xr-x 1 ainet snlog 211805 Feb 17  2012 tao_nsdel

-rwxr-xr-x 1 ainet snlog 376402 Feb 17  2012 tao_nslist

启动naming service的命令：

              Corba/ACE_TAO/bin64/Naming_Service -ORBEndpoint iiop://hostname1:12348 -ORBEndpoint iiop://hostname2:12348 &

building a complete application involves four basic steps:

Step 1.

Define the IDL.

Step 2.

Compile the IDL.

Step 3.

Write and compile the server.

Step 4.

Write and compile the client.

1、

-_ptr  which is equivalent to a pointer on the object (you can dereference it with - >),

-_var  which is the same but with automatic memory management (like auto_ptr). ------ 相当于是auto_ptr

如果要返回_var，因为内存会被释放，所以必须返回return xxx_var._retn()  。

2、

CORBA::Object 是所有对象的基础，使用_narrow来确定具体类型；

如：

CORBA::ORB_var orb = CORBA::ORB_init(msArgc, msArgv);

CORBA::Object_var naming_srv = orb->resolve_initial_references("NameService"); //resolve_initial_references返回CORBA::Object_ptr，此处相当于用智能指针存储，需要转换成NameService的。一般会有如下判断 if (CORBA::is_nil( naming_srv.in())){   in函数相当于取智能指针内存储的原始指针。

CosNaming::NamingContext_var root_cxt = CosNaming::NamingContext::_narrow(naming_srv);

其他例子：

CORBA::Object_var object =

orb_->resolve_initial_references ("RootPOA");

/// Reference to the root poa.

PortableServer::POA_var root_poa_;

root_poa_ = PortableServer::POA::_narrow (object.in ());

PortableServer::POAManager_var poa_manager =

root_poa_->the_POAManager ();

poa_manager->activate ();

  /// RT ORB

RTCORBA::RTORB_var rt_orb_;

object = orb_->resolve_initial_references ("RTORB");

this->rt_orb_ = RTCORBA::RTORB::_narrow (object.in ());

3、对于name service，有两个处理方法：bind和resolve。

bind、bind_context --- create and destroy a naming graph.

resolve --- only in lookup, to locate references

• 标准 + 例子：

3GPP TS 32.603 Configuration Management (CM); Basic CM Integration Reference Point (IRP); Common Object Request Broker Architecture (CORBA) Solution Set (SS)

• IDL (Interface Definition Language) 

WWW.OMG.ORG

Goal: Abstract language for separating object interface from their implementation

Establishes a contract (service interface) between client/server

Language-independent IDL specifications are compiled by an IDL compiler into sources (classes) for a specific implementation language (C++,JAVA,…)

IDL is purely declarative. You can neither write executable statements in IDL nor say anything about object state.

IDL specifications are analogous to C++ type and abstract class definitions. They define types and interfaces that client and server agree on for data exchange.

IDL source files must end in a .idl extension.

IDL is a free-form language. You can use white space freely to format your specification. 

IDL source files are pre-processed by the C++ pre-processor. You can use #include, macro definitions #define, etc.

Definitions can appear in any order, but you must follow the “define before use” rule. 

IDL keywords are in lower case (e.g. interface), except for the keywords TRUE, FALSE, Object, and ValueBase

Avoid identifiers that are likely to be keywords in programming languages, such as class or package, etc…   bypass

Basic types: 

short, long, unsigned short, unsigned long, float, double, octet, char, wchar, void, any, string, wstring…

Complex types:

Struct  (struct Node {long value; string info;};)

Enum (enum Color { red, green, blue, black, orange };)

Array (typedef long IdVector[20];)

Sequence (typedef sequence<long> Listlong;)

Union :union U switch (char) { case 'L': long mem1;case 'c': char mem2; default: string mem3};