Command System
A command is the basic mechanism for communication from users to
Distributed Objects and between Distributed Objects. A command is
actually a method of a Component.
CORBA provides full support for inter-process communication.
CORBA objects have a public interface defined with the IDL
language[RD01 - 10.3.4. IDL]
CORBA objects can be remotely accessed by creating stubs and
invoking the defined IDL interface.
Any language supported by CORBA can talk to any remote object,
independently from implementation language and architecture. The
Object Request Broker (ORB) does mapping of calls and marshalling.
CORBA defines a standard Internet Inter-ORB Protocol (IIOP) that
guarantees interoperability between any CORBA implementation and
vendor based on TCP/IP. Any implementation must comply with IIOP, but
a vendor can choose to additionally implement high performance
transport protocols. For example there are native ATM
implementations. Same-process messages are usually implemented as
direct function calls while same-CPU messages are based on operating
system message queues.
Other non-IIOP CORBA messaging protocols, supported by the ORBs
used in ACS, can be used to satisfy special communication and
security requirements.
A call to a method of a CORBA Component, based on its IDL
interface, is what can and has to be mapped into the concept of
Commands (the method call concept is very similar to RPC).
A command has a well-defined syntax and set of call and return
parameters. Full context validation and syntax check of commands is
always done when the command is received by the server
application[RD01 - 6.1.4.
Validation]. A command can also be checked by the sender, but
this is not mandatory except in the case of generic command-sending
GUIs[RD01 - 6.1.3. Syntax
Check]. The syntax check would check that the command is valid
and that the parameters are within the static ranges.
Commands are synchronous (the caller blocks and waits for a
return reply, up to a defined timeout) [RD01
- 6.1.7. Mode] [RD01 -
6.1.8. Timeout]. Applications should take care of the fact that a
synchronous call can block the whole application unless it is issued
from a dedicated thread. Replies can be normal replies or error
replies[RD01 - 6.1.1.
Messages].
CORBA Asynchronous Method Invocation (AMI) [RD29]
can be used to implement asynchronous calls on the client side using
synchronous methods on the servant side. AMI is only supported by a
few ORBs, for example TAO and JacORB, but not by omniORB.
Asynchronous command handling using synchronous methods on the
servant side can also be done by starting a separate thread, which
sends a synchronous command. This way the main thread is not blocked.
Asynchronous command handling can also be implemented using
callbacks, in particular when multiple replies need to be sent. ACS
provides support for Callbacks and uses callbacks for Monitors.
Using synchronous commands, time-outs are handled using CORBA
messaging (implemented in TAO but not in other ORBs) [RD01
- 6.1.6 Command delivery]. Intermediate replies are not handled
by ACS, but must be taken care of by the application. ACS cannot
therefore warranty that requirement [RD01
- 6.1.9 Intermediate replies] is satisfied. This is let to
applications.
Commands can be invoked from generic applications, that are able
to browse the objects in the systems, show the available commands
with the corresponding syntax, check dynamically the syntax of
commands and send them[RD01 -
6.1.5. Programmatic use].
A server sub-system handling a command shall continue to operate
if the client that has issued the command disappears, e.g. between a
command being initiated and completed. In this case the server logs a
non-critical error, since a well-behaving client should always wait
for replies to initiated actions, and continues.
Components publish their interfaces via IDL interfaces. IDL
allows use of inheritance to build new types. IDL allows only
defining the pure interface in terms of parameters and types; it does
not allow specifying range checking for the parameters. This checking
has to be performed by the applications. IDL interfaces are
registered in the CORBA Interface Repository (IREP) and made public.
Figure
3.19: Command System architecture
The implementation of checking functions and tools to implement
command syntax checking both at the sender and receiving side of
commands is provided by the Parameter package and Parameters have to
be used when command checking is necessary.