CORBA stands for:
- Common Object Request Broker Architecture.
- Component Objects Remote Broker Architecture.
- Collective Objects and Remoting Background Agents.
- Component and Object Remoting Business Architecture.
- Corba is not an acronym.
Too easy!
The Object Management Architecture is:
- Composed of an Object Model and a Reference Model.
- The group that certifies CORBA implementations.
- Composed of Application, Object, and Domain Interfaces, as well as Common Facilities and ORB.
- A subset of CORBA.
- The Java implementation of CORBA.
Object Services, as defined by the OMG (as part of the Reference Model), are:
- Domain-independent interfaces that are used my many distributed object programs.
- Any interface.
- The constructor, destructor, and reference counting.
- Interfaces used for the construction and destruction of object.
- Any service that an object might provide.
Common Facilities, as defined by the OMG (as part of the Reference Model), are:
- Interfaces that are oriented towards end-user applications.
- Interfaces used for the construction and destruction of object.
- Facilities that have to be provided by all objects.
- Well-known interfaces.
- Simple interfaces that are easy to code.
Domain Interfaces, as defined by the OMG (as part of the Reference Model), are:
- Interfaces oriented towards specific application domain.
- Interfaces oriented towards specific implementation domain.
- Interfaces oriented towards specific programming language domain.
- Interfaces oriented towards specific platform domain.
- Interfaces oriented towards specific CORBA domain.
CORBA components (at a high level) communicate with each other on a:
- Peer-to-peer basis.
- Client-server basis.
- Centralized manner.
- N-tier basis.
- Reflective disjunctive basis.
Reflective disjunctive is a made-up term.
CORBA object references:
- Are immutable and opaque.
- Can be made to point to various CORBA objects.
- Can be turned into a string whose contents can be analyzed to determine the objects location.
- Are always obtained from the ORB.
- Once valid, always remain so.
Object references can be obtained by:
-
- Object creation
- Directory service
- Convert to string and back
-
- Object creation
- Convert to string and back
-
- Invoking a factory.
-
- ORB invocation.
- Object reference modification
-
- ORB invocation.
- Determination of server host and creation of reference string from it.
The creation of a new CORBA object is achieved by:
- Invoking a creation request on a factory object.
- Starting with an object reference and asking the ORB to create an object from it.
- Asking the Naming Service to create a new one.
- Asking the ORB to create a new one.
- Issuing a
new
command.
The CORBA ORB serves to hide the following from the client:
- The object's location, implementation, execution state, and communication mechanism.
- The object's location, implementation, execution state, communication mechanism, and interface.
- The object's location, implementation, and communication mechanism.
- The object's location, and execution state.
- The object's location.
CORBA is
- The dominant remoting architecture.
- The dominant component architecture.
- A yet-to-be certified standard.
- A specific implemenation.
- An extension of Java RMI.
The difference between CORBA's Naming Service and Trading
Service is that:
- The Naming Service stores object references by name, while the Trading Service stores them by thier properties.
- The Naming Service stores object names, while the Trading Service stores object references.
- The Naming Service stores object references, while the Trading Service helps components share resources.
- The Naming Service gives objects their stringified name, while the Trading Service stores object references.
- The Naming Service gives objects their stringified name, while the Trading Service helps components share resources.
One of the main reasons CORBA needs to use an IDL is because
- CORBA's goal was to support multiple implementation languages.
- CORBA is a consortium of companies with different interests.
- IDL allows for the implementation of remote objects.
- It allows multiple ORBs to talk to each other.
- It makes it harder to implement a CORBA service.
Well, it does make it harder, but thats not why it was used :-)
The CORBA IDL is:
- Declarative.
- Procedural.
- Functional.
- A subset of C++.
- A subset of C.
Which one of the following lists contains one or more keywords
not supported by the CORBA IDL?
- class, interface, int.
- int, long, short.
- module, struct, string.
- string, sequence, short.
- any, fixed, octet.
When you want to pass a parameter that is the type of a CORBA
object reference, the type of this argument on the IDL
declaration should be:
- The type of the desired interface.
- The type of a class that implements the desired interface.
any
.
corba_ref
.
Corba::Object
.
Type Corba::Object
would work, but is not the best solution.
interface A {
Object aFoo();
};
interface B {
string bFoo();
};
interface C : A, B{
A cFoo();
};
Given the above CORBA IDL declaration, any class that implements C
must:
- Implement
aFoo()
and bFoo()
and cFoo
.
- CORBA IDL does not allow for multiple interface inheritance.
- Implement
cFoo
.
- Inherit from classes
A
and B
.
- Inherit implementations of
aFoo
and bFoo
.
All CORBA interfaces
- Inherit from
CORBA::Object
.
- Must define a factory method.
- Must be defined as part of the same module.
- Have a limit on the number of methods.
- Must follow the proper naming scheme for method names.
A CORBA IDL file is mapped into a domain language by
- Following the standarized language mapping defined by the OMG for that language.
- Converting the keywords to their closest semantic equivalent in the target language.
- Various conversion programs from various vendors, each optimized for a language or platform.
- The programmer.
- The CORBA Translation Service.
The CORBA Translation Service is made-up.
The CORBA IDL module
keyword maps to:
- C++
namespace
and Java package
.
- C++
class
and Java package
- There is no
module
keyword on CORBA IDL.
- C++ abstract
class
and Java interface
.
- C++ abstract
class
and Java package
.
When mapping CORBA IDL to C, CORBA objects are implemented as:
- A
struct
and a bunch of functions.
- There is no mapping since C is not object-oriented.
- A set of
class
- A special data type.
- An array of function pointers.
The CORBA Interface Repository
- Allows the OMG type system to be accessed and written programmatically at runtime.
- Stores the interfaces for a given CORBA
module
- Is an interface that can be implemented by any CORBA object, if it wishes to do so.
- Maps operation invocation to the equivalent of a function call in the programming language.
- Does not exist.
Say I give your program a reference to a CORBA object (using its
interface type as the type), and your program wants to determine
what are the functions the interface implements. The program can
find these out by:
- Using the
get_interface
operation.
- Using the
Reflection
API.
- Asking the Naming Service.
- It cannot be done by the program. The programmer must read the IDL interface definition.
- Calling the
narrow
operation.
Say you have a reference to a CORBA object and you want to call
one of its methods but do not wish to wait for the method call
to return (because it might take a long time to execute). How
could you do this?
- By using the Dynamice Invocation Interface.
- It cannot be done.
- It depends on the ORB implementation being used.
- By calling
async_call
.
- By wrapping the object in an
Corba::AsynchronousObject
.
The CORBA IIOP is:
- The CORBA Internet Inter-ORB Protocol.
- The CORBA International Interaction Object Protocol.
- The CORBA Interactive Inter-Object Platform.
- The CORBA Internet Interactive Object Platform.
- The CORBA Interactive Internet ORB Platform.
The CORBA IIOP allows for:
- ORBs implemented by different vendors to talk to each other.
- CORBA objects to be called asynchronously.
- ORBs to be distributed across the Internet.
- CORBA IDL to be mapped to Java.
- CORBA/COM interoperability.
The end goal of the development of standard OMG specifications is:
- The realization of a true commercial off-the-shelf software components marketplace.
- The development of next-generation web technolgies.
- The creation of an open alternative to COM.
- The subsumption of the OS as the platform of choice.
- The generation of More Confusing Acronyms (MCA).
In Sun's Java CORBA implementation, the Naming Service is provided by:
- tnameserv
- namingservice
- omg.corba.Object
- omg.corba.Object.NamingService
- registry
In Sun's Java (jdk 1.3) CORBA implementation, the mapping from
IDL to Java code is achieved by:
- idlj
- idl2java
- rmic
- idlic
- idljava
Typically, given one module defined in one IDL file, how many
files can we expect the Java IDL to Java compiler to generate?
Say you define a CORBA IDL interface called Hello
and generate the appropiate Java files from it. In order to
implement the methods declared in Hello
, you must
define a class which:
- Extends
_HelloImplBase
.
- Implements
Hello
- Implements
HelloBase
- Extends
omg.corba.Object
- Extends
_HelloStub
omg.corba.Object
extension is implicit, but this is not the best answer.
In Java CORBA, the narrow
function is defined:
- In the ...Helper.java file.
- In the omg.corba.Object class.
- In the ...Holder.java file.
- In the ...Operations.java file.
- In the ...Narrow.java file.
There is no ...Narrow.java file.
Stringification is the process of:
- Turning a CORBA object reference into a string.
- Turning a CORBA object into a string.
- Extracting the properties of a CORBA object as strings.
- Translating a CORBA IDL definition into a programming language definition.
- Translating a CORBA IDL definition into a string.
In Java CORBA, a reference to the Naming Service is obtained with:
- A call to
resolve_initial_references
with argument "NameServices".
- A call to
resolve_initial_references
with no argument.
- A call to
get_naming_service
.
- A call to
naming_service
.
- A call to the ORB's constructor.
A CORBA system can be run without a Naming Service:
- Yes, but object references will have to be obtained in some other way.
- Yes, the ORB's built in Naming Service can take the place of an independent Naming service.
- Yes, object references can be created by concatenating the server's machine name and other data into a string, then de-stringifying it.
- No, object references need to be stored in the Naming Service.
- No, a corba object cannot run unless it has access to a Naming Service.
The ORB's built-in service can only handle looking for a Naming Service.
The stringified version of a CORBA object reference can be obtained with a call to:
object_to_string
toString
getString
get_string
to_string
Its always the ugliest one, isn't it?
When using CORBA with C++:
- The user is responsible for allocating and de-allocating CORBA objects as needed.
- The user must give all functions a particular name.
- The user must perform reference-counting on all the data members his CORBA object uses.
- The user must link with the provided reference-counting libraries.
- The user must use the C++ virtual machine for garbage collection.
The minimum requirements for a Java class to be consitered a Java Bean are:
- Implement
Serializable
and have the name of all member-variable changing methods
start with either "get" or "set".
- Extend
Bean
and have the name of all member-variable changing methods
start with either "get" or "set".
- Implement
Bean
.
- Extend
Bean
.
- Implement the proper event-handling member functions.
A Java Bean is (pick one that matches Sun's definition):
- A reusable software component that can be manipulated visually in a builder tool.
- A distributed object implementation that can be manipulated visually in a builder tool.
- An object implementation with a graphical representation.
- An applet with special properties that allows its display on a builder tool.
- An RMI object that can be manipulated visually in a builder tool.
A CORBA C++ object must declare a method that handles its deletion. This method must be called:
destroy
delete
clean
free
collect