Learning notes for CORBA/Tao

Object: a corba programming entity, which consists of an identifier, an interface, and an implementation. Objects are also called servant and also called proxies.

Object Reference: a strongly-typed opaque handle that identifies the location of an object, that is, the IOR.

CUSTOMER: The program entity that calls the interface implemented by the object.
Send a request to an object by referencing it.

Object Request mediation (ORB): provides a mechanism for transparent transfer of requests between customers and objects. For distributed programs, it allows customers to call remote functions just as they call local functions.

Orb interface: an orb is a logical entity that can be implemented in multiple ways. To separate the application from the implementation details, the CORBA specification defines an abstract interface for each ORB. This interface provides some useful tool functions, such as converting an object reference to a string.
To be specific, a CORBA interface is like a pure virtual C ++ class. It has no data members, no protected or private members, and all functions are public and pure virtual.

Corba idl stubs and skeletons: they stick the client and service application respectively with orb like glue. These are usually completed by the corba idl compiler.

Dynamic call interface (DiI): This interface allows the client to directly access the underlying request mechanism provided by orb.

Dynamic skeleton interface: This is equivalent to the server (DiI ).

Object Adapter: it helps orb to pass the request to the object and activate the object. More importantly, the Object Adapter associates the object implementation with orb.

Each operation on the OMG interface must have:
1. A name
2. A return type, which can be void
3. Zero or multiple parameters
It can also include:
1. A raises statement that indicates the exceptions that this operation may cause.
2. a oneway modifier indicating that the caller does not expect any results (generally, this modifier is not used)
3. A context statement. (This is outdated and cannot be transplanted and should not be used again)
In addition, the operation does not support overloading.

Rules for IDL ing IDL to C ++:
1. Each module is mapped to a namespace or class.
2. Each interface is mapped to a class.
3. Each operation is mapped to a method in C ++.
4. Each attribute is mapped to a pair of get/set methods.

Basic Design Principles of CORBA:
1. Separate interfaces from implementations
2. Transparent location. The service usage is irrelevant to the service location.
3. transparent access. You can call an object directly.
4. typed interfaces.
5. interfaces support multi-inheritance.

Parameter transfer in CORBA/C ++:
1. built-in input type parameters, such as char, long, and pass by value
2. User-defined input parameters, such as struct/class, are passed by constant reference
3. Use const char * to pass a string
4. inout parameters are passed by reference.
5. The out type parameters and return values of a fixed length are passed by reference.
6. Dynamic Allocation of variable-length out parameters and return values
7. Copy the out parameter and return value of the object reference type.

Object Reference:
An object reference is a strongly typed opaque handle pointing to an instance of the interface.
It has the following semantics:
1. Each object reference points exactly to an object instance (one and only one ).
An object can have multiple references.
2. The reference can be empty. (That is, do not point to any instance, just like the NULL pointer in C ++)
3. A reference can point to an instance that has been destroyed.
4. references are not transparent and customers are not allowed to view their contents.
5. References are strongly typed.
6. Support delayed binding of references
7. The reference can be persistent.
8. You can collaborate with each other.

All IDL interfaces are implicitly inherited from an interface named object.
When a customer uses an object reference to perform an operation, ORB performs the following steps:
1. Locate the target object
2. if the service process is not running, activate the service program.
3. If you want to pass a parameter, pass all the parameters of the call to the object.
4. Activate a servant for the object if necessary.
5. Wait for the request to be completed
6. After the request is complete, return the data (out-type parameters and return values) to the customer.
7. If the operation fails, an exception is returned.

Internal Implementation of Object Reference:
It mainly includes the following three types of content:
1. repository ID. Identifies an ior type.
2. endpoint info. All information required by ORB for establishing a physical connection to the object implemented by server.
3. Object key. Identifies an object.

To develop a CORBA application, follow these steps:
1. determine the application objects and describe their interfaces using IDL.
2. Run the IDL compiler to generate the required files.
3. Declare and implement various C ++ servant classes.
4. Write the main function of the server, compile it, and link it.
5. Implement the client.

CORBA Event Service:
The producer generates an event and the consumer receives the event. The producer and consumer are connected by event channel.
OMG event service provides two event delivery models: push and pull. That is, active delivery or passive acquisition. Both producers and consumers can be active or passive. So there is a 2*2 = 4 mode. Or you can adopt a hybrid mode, that is, some consumers are active and some consumers are passive...
Pushsupplier actively pushes events.
Pushconsumer passively receives events and calls Disconnect when it does not want to receive them again.
When a supplier no longer wants to send events, it calls the disconnect_push_consumer method to disconnect all consumers.

 

From: http://www.sunchangming.com/blog? P = 2511