www.SeminarsTopics.

com

DATA -ACTIVATED REPLICATED

OBJECT COMMUNICATIONS(DAROC)

Contents

Topic Page Number

Abstract 1

1. DAROC Objectives. 1

2. History Of Blackboards. 1

3. Importance Of Blackboard. 2

4. Goals Of DAROC. 2

5. DAROC External Architecture Details. 3

6. DAROC Implementation Details. 4

7. Performance And Bottlenecks. 8

8. Hardware And Software Needs. 8

9. DAROC Tool Kit (DTK). 8

10. Conclusion. 9

References. 9

www.SeminarsTopics.com

Submitted By,

K.V.Sudheer1,
D. B. Purna Chandra Rao2

1,2: MCA IV sem,

Vishakapatnam-530 047
www.SeminarsTopics.com
DATA-ACTIVATED REPLICATED OBJECT COMMUNICATIONS
(DAROC)
Abstract:
DAROC is a middleware architectural
model, which is loosely based upon on the
blackboard model. This architecture will
decrease distributed software development
time by abstracting away much of the
communication overhead and scheduling,
which most software developers are
burdened with in their application. This
approach will still provide a flexible
architectural framework that allow for
modularity in its components, which then in
turn facilitates overall system upgrades and
modifications. The combination of reduced
communication and synchronization
overhead and flexibility will reduce software
development time, which has a direct impact
on the overall cost of development and
testing.
1. Objectives:
The short-term goal of DAROC is to
provide a programming environment that
will allow both undergraduate and graduate
students the ability to gain some exposure
and experience in programming distributed
applications.
The long-term goal is a bit more
ambitious. The DAROC architecture will
address problems such as distributed
simulation and battle management scenarios.
Major DAROC Objectives:
• Eliminate message-passing code
implemented by the programmer,
communication achieved by the
reading and writing of objects on the
blackboard.
• Eliminate control component, burden
of scheduling is placed on the OS
not on the application program.
• Activate functional elements in
DAROC periodically or based on
data changes when performing
computations.
• Reduce code complexity allowing an
“average” programmer to rapidly
develop distributed applications.
• Capability for fault recovery via data
replication
DAROC consists of two primary
components; functional elements (FE) are
active and perform computations and
analyze the system state, and the blackboard,
which is the structure that holds data objects
(DO) that make up the blackboard. Unlike
functional elements, data objects are passive
and do not perform computations.
DAROC At A Glance:
The desire of DAROC is to empower
programmers to be able to write
components of distributed systems without
being a distributed systems expert.
2. History of Blackboards:
The following are the various speech
engines that implement blackboard concepts
• HEARSAY-II
• HASP/SIAP
• OPM
• HEARSAY-III
• AGE
• BB1
 • TRICERO
• PROTEAN
These speech engines offer speech
processing and search technologies in a
single package.
The blackboard model is an
opportunistic and incremental problem-
solving model that defines how to organize
the sources of knowledge, along with the
reasoning steps and the domain knowledge
needed to build a solution to a problem.
The blackboard model consists of three
major components:
• Knowledge source
• Blackboard structure
• Control component.
Software Architectural Styles::
“Architectural styles are key design
idioms that enable exploitation of suitable
structural and evolution
patterns and facilitate component, connector,
and process reuse.”
Common Architectural Styles [16]:
• Pipe and Filter
• Layered Systems
• Client/Server
• Object Oriented
• Implicit Invocation
3.Why the Blackboard was Chosen
as the Style of Choice?
The blackboard style has a big
advantage when it comes to simplicity.The
blackboard style consists of one connector
that all components use, which of course is
the blackboard itself. Another big advantage
is evolveability, because new types of
components can be easily written.The
blackboard style naturally lends itself to
increased concurrency. Multiple components
can read and write blackboard data and
perform their assigned computations
concurrently if possible. The DAROC
architecture has a partial influence from the
objectoriented approach, in that DAROC
data objects consist of data and associated
operations that the functional elements can
exploit in an object-oriented fashion.A
functional element can’t communicating
directly with another functional element
DAROC uses a data-activation approach to
activate functional elements,which cause
functional elements to be implicitly
activated, based on changes to data object
states or periodic changes.
4.Goals of DAROC:
• Reduce software development
costs, error-proneness and
inflexibility associated with
distributed systems applications.
• Reduce code complexity so that
the “average” programmer is able to
build distributed systems.
• Provide a tool to better prepare
students for the ever-growing need in
the job market for experienced
distributed systems programmers.
Implementation of DAROC
Objectives::
The first objective is to eliminate
message-passing code that is written
by the programmer. In addition,
communication is achieved by the reading
and writing of objects on the blackboard.
This objective was first achieved because of
the use of the underlying blackboard
architecture.
The second objective is that there is no
control component and the burden of
scheduling is placed on the operating system
not on the application program. DAROC is
not implemented with a control component.
1
It uses a data-driven technique to schedule
the activation of functional elements.
The third objective is that DAROC
uses data-driven activations as opposed to an
event driven approach. In DAROC, the
data-activation approach is implemented via
a list of input conditionals associated with
each data object in a functional elements
subscription list. When a data object is
changed, the input conditional for that data
object is changed in the subscription list.
The functional element continuously checks
the input conditionals of its subscription list
until all have been updated since the last
activation.
The final objective of DAROC is to
provide fault recovery capability via data
replication. The DAROC space that makes
up the blackboard contains all the state
information of the system. No state
information is to be stored in the functional
elements.
5.DAROC: External Architecture
Details:
Data Objects:
DAROC currently supports data
objects defined as any standard ANSI/ISO
C++ data type such as integers, floats,
doubles, characters, and arrays.
However, these data types must be
wrapped in a trivial abstract data class to be
able to be integrated into DAROC. The
“build” function is part of DAROC and is
used to build and initialize the DAROC
components around the newly created
object. DAROC fully supports any abstract
data type the user creates.
Data object is stored contiguously in
memory that is to say that compound data
objects, such as link lists of data objects, and
other any other types of a non-contiguous
fashion are currently not supported because
pointers have no meaning in the memory
space of distributed machines.
Functional Elements:
Functional elements are always created
as an abstract data type. In their simplest
form, they consist of a “build” function to
create and instantiate the DAROC
components around the functional element
and the FEactivation Function. There are no
data members in this functional element.
Constraints:
Each functional element and data
object consists of a name and an ID field.
The name field is any unique generic name
that the user calls the object. The ID, which
is also unique, is defined internally within
DAROC and can be used to better describe
the object. The ID field consists of three
parts. It always starts with a ‘/DO’ or a ‘/FE’
to discern between a data object and a
functional element. The next part that is
appended is the local host name, i.e.
east.ece.uci.edu. Finally, there is a dash and
monotonically increasing integer appended
to the name.One final constraint of mention,
is that of the error manager. Currently there
are eighteen statically defined error
messages. The error manager in its current
state can hold up to one hundred error
messages. All of the data object and
functional element name and ID constraints
can be changed in the bblib.h file, and the
error manager can be expanded in the
errorman.h file.
.Single Writer Rule (SWR):
DAROC is implemented with a
single-writer rule as part of the application
implementation. This simple means that
only one functional element may write to a
particular data object at all times. There can
2
never be a situation where two different
functional elements may need to write to the
same data object. By implementing a single
writer rule, we eliminate race conditions,
ambiguity, and complex locking
mechanisms found in other distributed
frameworks that allow the capability of
shared writes. Due to SWR there is a
problem of starvation and deadlocking.
Initialization of a Data Object:
Data objects have three required
parameters and as many user-defined
parameters as deemed necessary by the
programmer.
Initialization of a Functional Element:
Functional elements have five required
parameters and as many user defined
parameters as deemed necessary by
the programmer.
The activation of the functional element
does not depend on updates to data objects
but only on changes in time. The ignore IC
parameter must be a 0 or 1, while the
activation delay is any real number greater
than or equal to 0.
DAROC’s Error Manager:
The error manager is an attempt to
provide a consolidated error messaging
system for future DAROC developers and
application programmers. The error manager
is not intended to be a static entity and
should be amended by the programmer.
sample call to the error manager
BBerror.Send(0, "FE::FE()");
The first parameter is the index of the
error message to be displayed. The second
parameter consists of a character string.
Garbage Collection within DAROC:
DAROC currently deallocates any
memory that was dynamically
allocated for a functional element or data
object along with all pthread mutexes if the
program exits cleanly. The linked lists that
make up the DONAR and FEBAR managers
are also properly deallocated when the
program exits cleanly.
6.DAROC:Implementation Details:
Data Object:
When a programmer creates a data
object, they inherit all of the standard
components of a DAROC data object. All
data objects contain a unique ID, which is
set by the system and a name, which is set
by the user. The lock and lockattr data
members are used to lock the data object
during a read or a write to that object.
Updatecount is a monotonically increasing
integer that is increased each time a write
occurs to the data object. This is the
parameter that functional elements reads to
see if a data object has been updated since
its last activation and in turn may need to
activate.
Functional Element:
3
 Functional elements also have a unique
ID defined by the system and a name, which
is user defined. The status tag is currently
set every time a FE activates and is reset and
the end of the activation cycle.
The timetag and tms data members are
used for the periodic time checks that often
occur as part of the FE activation. The
ACdelay, stands for activation cycle delay,
this is the time in seconds between
activation cycles, which is set when the FE
is created. IgnoreIC is another tag set when
a FE is created.
If this parameter is set to “1” then the
input conditionals are ignored and the FE is
periodic is nature. Input is the buffer that
contains the name of all data objects the FE
reads from and needs to have changed to
start its activation. The inputsize and curin
are the size and index for this list
respectively.
Output is the buffer that contains the
name of all data objects the FE writes to at
the end of its activation. The outputsize and
curout are the size and index for this list
respectively. IC is an integer buffer that
mirrors the input buffer.
When a DO in the buffer list is known
to have changed. The corresponding entry in
the IC buffer is set to “1”. So once the entire
IC buffer has “1’s” in all of its entries then it
is time to activate the FE.
Error Manager:
The error managers data member is
just an array of strings that contain the
statically defined messages. Error messages
can be called using the send member
function with the appropriate index and any
additional information can passed to the
function as a string in the second parameter.
DONAR::
The DONAR acts as a local name
services manager. All data objects that are
created on a node register themselves with
the DONAR. When a functional element
needs to find the address of data object it
sends its request to the DONAR. The
DONAR is nothing more than a global link
list of data objects on that particular node. A
DONAR node consists of the name of the
data object, its ID, its address in memory
and a pointer to the next node. The actual
link list contains all of the standard items
such as a pointer to the first node and last
node and its size.
FEBAR::
The FEBAR like the DONAR is a link
list. However, the FEBAR is not a global
name services manager. Every functional
element has its own FEBAR, which it uses
to store copies of the data objects that it
needs to read from to perform its
computation. It also contains the copies of
data objects that will eventually be written
back to the blackboard. FEBAR node
consists of the name of the data object, the
address of the data object, and a tag specify
if it is an input buffer or not. All buffers
with an isinputbuffer set to “0” will be
written back to the blackboard. The buffer
data member is the storage location of the
DO. The actual l ink list contains all of the
standard items such as a pointer to the first
node and last node and its size. The FEBAR
retrieves data objects to be operated on
based on their name. The three main
member functions of the FEBAR are
• FEBARgetbuffer,
• FEBARoverwritebufferlist and
• FEBARpost.
The FEBARgetbuffer function
retrieves the data object and passes it to the
user’s application function where it is cast
4
and the data members and functions can
then be exploited.
The FEBARoverwritebufferlist is an
essential part of the FE activation. This
function finds all the latest copies of data
objects the FE needs and overwrites their
old copies of data objects with fresh copies.
The FEBARpost is another essential
part of the FE activation cycle. The FEpost
function finds all of the data objects in its
FEBAR list that is tagged as an output
buffer and copies the newly calculated data
object back to its blackboard location. Until
this function completes, the results of the
calculation are not committed.
DO Packaging in the FEBAR
Manager:
Data objects throughout DAROC are
stored merely as character buffers. This
allows for the simple transfer of objects in
the system and will facilitate replication.
When the user operates on data objects
in an application function, they are in
actuality operating on the copies of data
objects stored in the FEBAR manager.
Parsing and Data Object Wrapping:
Parsing is an essential piece of
reducing code complexity. The ‘$’ is used in
DAROC in front of a data object to wrap
that object with DAROC code once it is run
through the parser.
All data objects must have the ‘$’
parse symbol in front. The code will not be
able to be compiled after it is run through
the parser if a data object is missing the
parse symbol.
Retrieval of a Data Object Step by
Step::
The wrapped application code calls the
FEwrap function and passes the name of the
data object that the user requests. The data
object request is passed to the FEgetbuffer
function code, which is still part of the
functional element source code.
The FEgetbuffer function passes
control and the request to its associated
FEBAR. The FEBAR uses its own
FEBARgetbuffer function and calls the
findDOname, whichsearches through the
FEBAR’s link list for the requested data
object.
An error message is generated if no
object is found. If the object is found, the
data object is passed back as a character
buffer until it reaches the FEwrap function.
The FEwrap function does not pass the
object back to the application function as a
character buffer, but instead casts it as an
abstract DAROC data object type.
FE Activation Cycle:
The FE handler is the initial point of
control when the FE is created.
Assuming the functional element if not
periodic based, it will continuously check
the data objects in its input list.
Once they all have been updated since
the last activation, the input condition
parameter is set to true and control is passed
to the user execution logic which is just the
application function.
Once the application function
completes, control is passed back to the FE
handler, which subsequently writes back the
newly calculated data objects to the
blackboard.
There are comments about
preconditions and post-conditions in the FE
handler.
This intelligence is currently not in
DAROC but most likely will be added in the
future.
5
Explicit use of the Wrap and Post
Commands::
The FEwrap and FEpost functions can
be called explicitly by the programmer in
the application function.
One of DAROC’s primary goals is to
hide the any explicit reading and writing of
data objects.
If the user’s programme is an infinite
loop then the objects can never be written
back to the blackboard.
DAROC’s Locking Mechanisms:
Lockings are used for data integrity
will others are used to insure uniqueness of
various object names.
Locking in DAROC is implemented
via POSIX mutexes.
One of the locks in the data object
class is defined as type static. Data members
of type static have class scope. Therefore,
this lock is shared among all data objects on
the local node. The purpose of this lock is to
ensure the uniqueness of all data object ID’s
created on that node. When a data object is
instantiated, a unique ID is created as a
system identifier. The data object obtains
this lock, in order to access the critical
sectionThe data object uses this integer as
part of its ID, increases the integer value of
the critical section and releases the lock for
the next instance to grab the lock. The data
object uses this integer as part of its ID,
increases the integer value of the critical
section and releases the lock for the next
instance to grab the lock. The other lock in
the data object class is not shared among all
data objects but private to that data object
only. It is used to lock a data object before a
write begins on the object. Before a
functional element writes any of its newly
computed results back to the respected data
object it must obtain this lock before doing
so. Also before a functional element reads
fresh copies into its buffer before it performs
its computation it must obtain this lock for
each data object before the read is allowed.
Threading:
DAROC is a multithreaded
architecture. IEEE POSIX libraries are used
for its thread support. Using POSIX threads
does not improve the scalability of the
system but helps to facilitate the portability
of the architecture. Whenever a new
instance of a functional element is initialized
with the build member function, a new
thread is spawned which serves as a control
mechanism for the functional element.
The single thread attached to each
functional element runs continuously
processing information gathered from the
blackboard.
To prevent a situation where a
functional element begins running before all
data objects and functional elements have
been properly initialized, a global barrier is
shared by all functional elements running on
the same node.
The barrier is simple a static variable
that when set to one lifts the barrier
condition.The start and stop barrier
condition is not the only barrier that exists
with a functional element.
There is also a pause and unpause
barrier condition. When the pause barrier
condition is set, functional elements do not
immediately enter the paused state. All
functional elements first finish their current
6
activation cycle before suspending their
operations.
How are DO’s and FE’s Linked
Together?::
Functional elements maintain a
subscription list of all data objects in their
data set that they either read or write. Data
objects also have the ability of maintaining a
list of functional elements that can operate
on them.
The current implementation of
DAROC is one in which the functional
elements pull update changes from the
blackboard as opposed to the blackboard
pushing update changes out to the
appropriate functional elements. Data
objects of type “input” are those that are
read only. Data objects of type “output” are
those data object it will write its results back
to.
7.Performance and Bottlenecks::
There are three components in the
DAROC architecture that can be a future
source of bottlenecks that result in
performance hits. DAROC currently
is not in a stage of maturity in which
distributed simulations can be performed.
DAROC Bottlenecks:
• Centralized Name Services
• Blocking Lock Mechanism
• Inflexibility of Functional Element
Activation’s
• Copies of Data Objects
Activation Analysis:
The systems specifications are as
follows:
• Intel 810 Chipset
• GHz celeron processor
• 384 MB of memory
• Mandrake Linux 9.0 OS
8.Hardware and Software Needs::
Resource Needs:
DAROC has been compiled to run on
both Intel’s x86 architecture as well as the
SUN systems at UCI. DAROC was written
completely in C++ and uses standard POSIX
thread libraries. Therefore, in turn, the
porting of DAROC code from one platform
to another should be facile as long as the
C++ and POSIX standards are fully
supported on the platform in question.
Platforms Tested On:
• Linux (with GUI)
• Sun (without GUI)
Software Recommendations:
• Mandrake Linux 9.0
• g++ bundled with Mandrake 9.0
• GTK+ 1.2
9.DAROC Tool Kit (DTK)::
A tool kit is currently under
development to further increase the
programmers ability to rapidly program data
objects and functional elements. The tool kit
will not be static and will continue to grow
to meet the needs of the users as time
progresses. The initial revision of the tool kit
will contain three components: the
blackboard parser, single-writer rule
checker, and DAROC code nugget
generator.
Current DTK Components:
• Blackboard Parser: The user runs
their source code through this utility
to wrap their code around the
appropriate DAROC functions and
cast the data objects to their
respected type.
7
 • Single Writer Rule (SWR) Checker:
Within DAROC, data objects can
only be written by a single functional
element at all times. This rule
eliminates the need for a complex
distributing locking mechanism. The
user runs their source code through
the SWR checker to verify the
integrity of this rule. Later revisions
will do this check at run time.
• Code Nuggets: Skeleton code of data
object’s and functional element's can
be created on the fly and be free of
syntactical errors by simply filling
out a specifications form.
DTK Rationale:
The initial tool kit contains three main
components. The first component is the
DAROC parser. All FE application source
code is first run through this parser before it
is compiled. The parser automatically wraps
the referenced data objects with the
appropriate DAROC code and casts the data
objects to their corresponding data types.
The second component is the single writer
rule checker.
The single writer rule is a main part of
the initial DAROC architecture, however no
part of the initial architecture prevents the
programmer from breaking this rule. The
third component is the DAROC nugget code
creator.
All data objects and functional
elements the user creates can be built off of
a standard code templateSimple data objects
are created by initializing their private
members and calling DAROC’s data object
constructor. data objects and functional
elements have their standard lists consisting
of which entities they need to communicate
with. programmer will enter things like the
name of the FE, its type, whether it has a
periodic activation or whether it is based on
specific data objects. In addition, the
programmer will enter how many data
objects it can read or write to as well as the
names of these objects, respectively.
The programmer can then simply click
a button and have the code generated for
them, with no missing commas, parentheses,
or other similar syntactical programming
errors that so often occur. The code nugget
will be generated in a separate file, so it will
be up to the programmer to inject the code
pieces into the appropriate segments of the
application.
10.Conclusion::
Current distributed programming
paradigms force communication and
scheduling code into the application code of
the program. This method is highly error
prone due to the complexity of programming
in a distributed environment and leads to
limited scalability.
DAROC, a data-activated middleware
approach whose goal is to ease distributed
programming for people who are not
distributed systems experts. DAROC is a
network transparent environment in which
all accesses are seen as local from the
programmer’s point of view. Data-activation
in a loosely based blackboard model
simplifies scheduling while providing a
mechanism for data replication. The
evolving tool kit will also enhance this
simple, yet powerful distributed
programming environment.
References::
http://projectstopics.com/
http://www.seminarstopics.com/
www.LecturerNotes.com
www.LecturerNotes.com
8
 www.SeminarsTopics.com

Welcome To www.SeminarsTopics.com For Download Latest Seminar Topics.

We are adding More Research Seminar Topics Please keep visiting

www.SeminarsTopics.com for Regular Updates

www.SeminarsTopics.com
SeminarsTopics.com is now a true collaboration of the best minds in education,
with more than 1000 students/ Professors, subject experts and editors
contributing to it every day.

Students/Professors are most welcome to contribute here by Uploading Seminar

Thanks