Introduction to COBRA

Common Object Request Broker Architecture

https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CORBA uses an interface definition language (IDL) to specify the interfaces that objects present to the outer world. CORBA then specifies a mapping from IDL to a specific implementation language like C++ or Java. Standard mappings exist for Ada, C, C++, C++11, COBOL, Java, Lisp, PL/I, Object Pascal, Python, Ruby and Smalltalk. Non-standard mappings exist for C#, Erlang, Perl, Tcl and Visual Basic implemented by object request brokers (ORBs) written for those languages.

The CORBA specification dictates there shall be an ORB through which an application would interact with other objects. This is how it is implemented in practice:

• The application simply initializes the ORB, and accesses an internal Object Adapter, which maintains things like reference counting, object (and reference) instantiation policies, and object lifetime policies.
• The Object Adapter is used to register instances of the generated code classes. Generated code classes are the result of compiling the user IDL code, which translates the high-level interface definition into an OS- and language-specific class base for use by the user application. This step is necessary in order to enforce CORBA semantics and provide a clean user process for interfacing with the CORBA infrastructure.

基本概念

IOR

可互操作对象引用。

ORB（Object Request Broker）

ORB 是一个中间件，他在对象间建立客户-服务器的关系。通过 ORB，一个客户可以很简单地使用服务器对象的方法而不论服务器是在同一机器上还是通过一个网络访问。ORB 截获调用然后负责找到一个对象实现这个请求，传递参数和方法，最后返回结果。客户不用知道对象在哪里，是什么语言实现的，他的操作系统以及其他和对象接口无关的东西。

ORB守护程序

负责查找 IOR 指定的对象实现，以及建立客户机和服务器之间的连接。一旦建立了连接，GIOP 将定义一组由客户机用于请求或服务器用于响应的消息。

GIOP（General Inter-ORB Protocol）

GIOP（通用对象请求代理间通信协议）元件提供了一个标准传输语法（低层数据表示方法）和ORB之间通信的信息格式集。GIOP只能用在ORB与ORB之间，而且，只能在符合理想条件的面向连接传输协议中使用。它不需要使用更高一层的RPC机制。这个协议是简单的（尽可能简单，但不是简单化），可升级的，使用方便。它被设计为可移动的、高效能的表现、较少依靠其它的低层传输协议。当然，由于不同传输使用不同版本的GIOP，它们可能不能直接协作工作，但它能很容易的连接网络域。

IIOP （Internet Inter-ORB Protocol）

IIOP（Internet对象代理间通信协议) 元件指出如何通过TCP/IP连接交换GIOP信息。IIOP为Internet提供了一个标准的协作工作协议，它使兼容的ORB能基于现在流行的协议和产品进行“out of the box”方式的协作工作。它也能被用于两个半桥（half-bridges ）之间的协议。该协议能用于任何ORB与IP（Internet Protocol）域之间的协作工作，除非ORB选择了特殊的协议。这时，它是TCP/IP环境下基本的inter-ORB 协议，最普遍的传输层。 GIOP 不基于任何特别的网络协议，OMG 在最广泛使用的通信传输平台 -- TCP/IP 上标准化 GIOP，GIOP 加 TCP/IP 等于 IIOP

IDL

IDL全称接口定义语言，是用来描述软件组件接口的一种规范语言。用户可以定义模块、接口、属性、方法、输入输出参数，甚至异常等等。IDL在不同的语言下都有相应的实现，可以把IDL描述的接口编译为目标语言，包括客户端代理和服务器端框架，以及相应的帮助类等等。比如Java中提供过了idlj命令用来编译。

---

架构

 

On the client side, a client is the process that request to use the operations (methods) of an ORB object through its reference, the IDL stub works as a proxy that converts the method calls of the client into messages.

On the server side, the IDL skeleton works as an adapter that converts messages generated by IDL stubs into method calls. The servant on the server is the entity that actually implements the request on the object. Then the return value / error would be transformed by the IDL skeleton and send back to the client via the ORBs.

The messages formed through IDL stubs and received by IDL skeleton are transmitted through a layer called “ORB Core” and this layer actually provide the message passing through the standard communication protocol such as General Inter-ORB Protocol (GIOP) and Internet Inter-ORB Protocol (IIOP). These protocols defines how the ORBs should pass information back and forth and with this message passing layer, distributed programs that works on different computers can communicate with each other over the internet.

Servants

A servant is the invocation target containing methods for handling the remote method invocations. In the newer CORBA versions, the remote object (on the server side) is split into the object (that is exposed to remote invocations) and servant (to which the former part forwards the method calls). It can be one servant per remote object, or the same servant can support several (possibly all) objects, associated with the given Portable Object Adapter. The servant for each object can be set or found "once and forever" (servant activation) or dynamically chosen each time the method on that object is invoked (servant location). Both servant locator and servant activator can forward the calls to another server. In total, this system provides a very powerful means to balance the load, distributing requests between several machines. In the object-oriented languages, both remote object and its servant are objects from the viewpoint of the object-oriented programming.

Incarnation is the act of associating a servant with a CORBA object so that it may service requests. Incarnation provides a concrete servant form for the virtual CORBA object. Activation and deactivation refer only to CORBA objects, while the terms incarnation and etherealization refer to servants. However, the lifetimes of objects and servants are independent. You always incarnate a servant before calling activate_object(), but the reverse is also possible, create_reference() activates an object without incarnating a servant, and servant incarnation is later done on demand with a Servant Manager.

The Portable Object Adapter (POA) is the CORBA object responsible for splitting the server side remote invocation handler into the remote object and its servant. The object is exposed for the remote invocations, while the servant contains the methods that are actually handling the requests. The servant for each object can be chosen either statically (once) or dynamically (for each remote invocation), in both cases allowing the call forwarding to another server.

On the server side, the POAs form a tree-like structure, where each POA is responsible for one or more objects being served. The branches of this tree can be independently activated/deactivated, have the different code for the servant location or activation and the different request handling policies.

Features

Objects By Reference
Object references are lightweight objects matching the interface of the real object (remote or local). Method calls on the reference result in subsequent calls to the ORB and blocking on the thread while waiting for a reply, success or failure. The parameters, return data (if any), and exception data are marshaled internally by the ORB according to the local language and OS mapping.

Data By Value
The CORBA Interface Definition Language provides the language- and OS-neutral inter-object communication definition. CORBA Objects are passed by reference, while data (integers, doubles, structs, enums, etc.) are passed by value. The combination of Objects-by-reference and data-by-value provides the means to enforce strong data typing while compiling clients and servers, yet preserve the flexibility inherent in the CORBA problem-space.

Objects By Value (OBV)
Apart from remote objects, the CORBA and RMI-IIOP define the concept of the OBV and Valuetypes. The code inside the methods of Valuetype objects is executed locally by default. If the OBV has been received from the remote side, the needed code must be either a priori known for both sides or dynamically downloaded from the sender. To make this possible, the record, defining OBV, contains the Code Base that is a space-separated list of URLs whence this code should be downloaded. The OBV can also have the remote methods.

CORBA Component Model (CCM)
CORBA Component Model (CCM) is an addition to the family of CORBA definitions.[3] It was introduced with CORBA 3 and it describes a standard application framework for CORBA components. Though not dependent on "language dependent Enterprise Java Beans (EJB)", it is a more general form of EJB, providing four component types instead of the two that EJB defines. It provides an abstraction of entities that can provide and accept services through well-defined named interfaces called ports.

The CCM has a component container, where software components can be deployed. The container offers a set of services that the components can use. These services include (but are not limited to) notification, authentication, persistence and transaction processing. These are the most-used services any distributed system requires, and, by moving the implementation of these services from the software components to the component container, the complexity of the components is dramatically reduced.

Portable interceptors
Portable interceptors are the "hooks", used by CORBA and RMI-IIOP to mediate the most important functions of the CORBA system. The CORBA standard defines the following types of interceptors:

1. IOR interceptors mediate the creation of the new references to the remote objects, presented by the current server.
2. Client interceptors usually mediate the remote method calls on the client (caller) side. If the object Servant exists on the same server where the method is invoked, they also mediate the local calls.
3. Server interceptors mediate the handling of the remote method calls on the server (handler) side.

The interceptors can attach the specific information to the messages being sent and IORs being created. This information can be later read by the corresponding interceptor on the remote side. Interceptors can also throw forwarding exceptions, redirecting request to another target.

General InterORB Protocol (GIOP)
Main article: General Inter-ORB Protocol
The GIOP is an abstract protocol by which Object request brokers (ORBs) communicate. Standards associated with the protocol are maintained by the Object Management Group (OMG). The GIOP architecture provides several concrete protocols, including:

1. Internet InterORB Protocol (IIOP) – The Internet Inter-Orb Protocol is an implementation of the GIOP for use over the Internet, and provides a mapping between GIOP messages and the TCP/IP layer.
2. SSL InterORB Protocol (SSLIOP) – SSLIOP is IIOP over SSL, providing encryption and authentication.
3. HyperText InterORB Protocol (HTIOP) – HTIOP is IIOP over HTTP, providing transparent proxy bypassing.
4. Zipped IOP (ZIOP) – A zipped version of GIOP that reduces the bandwidth usage.

VMCID (Vendor Minor Codeset ID)
Each standard CORBA exception includes a minor code to designate the subcategory of the exception. Minor exception codes are of type unsigned long and consist of a 20-bit “Vendor Minor Codeset ID” (VMCID), which occupies the high order 20 bits, and the minor code proper which occupies the low order 12 bits.

Minor codes for the standard exceptions are prefaced by the VMCID assigned to OMG, defined as the unsigned long constant CORBA::OMGVMCID, which has the VMCID allocated to OMG occupying the high order 20 bits. The minor exception codes associated with the standard exceptions that are found in Table 3-13 on page 3-58 are or-ed with OMGVMCID to get the minor code value that is returned in the ex_body structure (see Section 3.17.1, “Standard Exception Definitions,” on page 3-52 and Section 3.17.2, “Standard Minor Exception Codes,” on page 3-58).

Within a vendor assigned space, the assignment of values to minor codes is left to the vendor. Vendors may request allocation of VMCIDs by sending email to tagrequest@omg.org. A list of currently assigned VMCIDs can be found on the OMG website at: http://www.omg.org/cgi-bin/doc?vendor-tags

The VMCID 0 and 0xfffff are reserved for experimental use. The VMCID OMGVMCID (Section 3.17.1, “Standard Exception Definitions,” on page 3-52) and 1 through 0xf are reserved for OMG use.

The Common Object Request Broker: Architecture and Specification (CORBA 2.3)

Corba Location (CorbaLoc)
Corba Location (CorbaLoc) refers to a stringified object reference for a CORBA object that looks similar to a URL.

All CORBA products must support two OMG-defined URLs: "corbaloc:" and "corbaname:". The purpose of these is to provide a human readable and editable way to specify a location where an IOR can be obtained.

An example of corbaloc is shown below:

corbaloc::160.45.110.41:38693/StandardNS/NameServer-POA/_root

A CORBA product may optionally support the "http:", "ftp:" and "file:" formats. The semantics of these is that they provide details of how to download a stringified IOR (or, recursively, download another URL that will eventually provide a stringified IOR). Some ORBs do deliver additional formats which are proprietary for that ORB.

Problems and criticism

https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture#Problems_and_criticism

 

---

思考：

1. 作为最早的跨平台中间件，CORBA尝试定义一套语言无关的IDL——或者说是一种新的语言——而所有其他的编程语言与此转换。实际上用户对IDL并不十分买账，对于任何人来说，学习一门新的语言都是一种成本。所以到了D-Bus中，ORB被保留 了，但IDL却被XML代替了。毕竟IDL与XML做的是同一件事——作为语言无关的接口描述文本，定义哪些 Method / Signal 可以被调用，传入什么参数并返回哪些信息。（当然，IDL的强类型也有自身的优势）

转载于:https://www.cnblogs.com/brt3/p/9657413.html