Image Processing Reference
In-Depth Information
we reused concepts, interfaces, mechanisms, and formats from TAO's implementation of the CORBA
standard.
2.2.3 Problem: No Explicit Support for Temporal Coordination in the
Simulation Environment
As the last row of Table . suggests, none of the potential middleware solutions we found was able
to support the kind of temporal coordination between simulated and actual infrastructure that is
needed in the simulation environment described in Section ...
BecauseTAOisopen-source,itwouldbepossibletointegratespecial-purposemechanismsthat
intercept GIOP messages exchanged between simulated nodes, and perform accounting of simulation
time whenever a message is sent or received. However, TAO does not explicitly address time-triggered
dispatching of method invocations, which also must be subject to simulation time accounting.
Kokyu is designed for time- and event-triggered dispatching, but does not intercept messages
exchanged through the ORB without transiting a dispatcher. herefore, neither TAO nor Kokyu alone
is able to provide the kind of temporal coordination needed in the simulation environment.
2.2.4 Solution: Virtual Clock Integrated with Real-Time Dispatching
and Distribution Features
In the target system, both time-triggered local method invocations and remote method invocations
must be dispatched according to real-time constraints. hose constraints and the corresponding tem-
poral behavior of the application and middleware must be modeled and enforced effectively in the
simulation environment as well.
To support both the target and simulation environments, we integrated a dispatcher based on the
Kokyu model with distribution features based on TAO, in nORB. We then used the dispatcher as a
single point of real-time enforcement, where both local upcalls and method invocation request and
reply messages are ordered according to dispatching policies. Within that single point of control,
we then integrated a virtual clock mechanism that is used only in the simulation environment, to
enforce both causal consistency and real-time message and upcall ordering on the simulation's logical
time-line.
2.3 ORB Middleware for Networked Embedded
Systems: A Case Study
In this section, we describe the design and implementation of nORB, and the rationale behind
our approach, to address the networked embedded system design and implementation challenges
described in Section ...
2.3.1 Message Formats
We support a limited subset of the messages supported by the CORBA specification, so that we do
not incur unnecessary footprint, but at the same time support the minimum features required by the
application. The following messages are supported by nORB: Request, Reply, Locate Request, and
Locate Reply.
Figure . shows the formats of the messages supported by nORB. he format of the Request and
Reply messages in nORB closely resembles that of the GIOP Request and Reply messages, respec-
tively. We use the Common Data Representation [] to encode the messages themselves. he nORB
client builds a Request message and sends it to the nORB server, which sends a Reply back to the
client.
