DAROC TECHNOLOGY

A SEMINAR REPORT

Submitted in partial fulfillment of requirements for the award of Degree of

BACHELOR OF TECHNOLOGY
IN
COMPUTER SCIENCE AND ENGINEERING

Submitted By
K PRIYANKA

Regd. No:153T1A0548

Under the Esteemed guidance of

Dr. K. SRINIVAS

Professor and Head of the

Dept of CSE.

RAVINDRA COLLEGE OF ENGINEERING FOR WOMEN

An ISO 9001:2008 Certified Institution, Approved by A.I.C.T.E.-New Delhi,
Affiliated to J.N.T. University-Anantapur, Ananthapuramu.
Nandikotkur Road, Venkayapally, Kurnool, Andhra Pradesh – 518452. [Link].

2018-2019
 RAVINDRA COLLEGE OF ENGINEERING FOR WOMEN
An ISO 9001:2008 Certified Institution, Approved by A.I.C.T.E.-New Delhi,
Affiliated to J.N.T. University-Anantapur, Ananthapuramu.
Nandikotkur Road, Venkayapally, Kurnool, Andhra Pradesh – 518452. [Link].

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

CERTIFICATE

The seminar report entitled “DAROC TECHNOLOGY” is prepared and submitted by M

K PRIYANKA (153T1A0548). It has been found satisfactory in terms of scope, quality and
presentation in partial fulfillment of the requirements for the award of the degree of Bachelor of
Technology in Computer Science & Engineering in Ravindra College of Engineering for Women,
Kurnool, AP.

SEMINAR GUIDE SEMINAR COORDINATOR

Dr. K. SRINIVAS K. SHOURYADHAR
Prof & Head of the Department Assistant Professor
Department of C.S.E Department of C.S.E
Ravindra College of Engineering for Women Ravindra College of Engineering for Women
Kurnool. Kurnool.

HEAD OF THE DEPARTMENT

DR. [Link],
Prof.& Head of the Department
Department of C.S.E
Ravindra College of Engineering for Women
Kurnool.

I
RAVINDRA COLLEGE OF ENGINEERING FOR WOMEN
An ISO 9001:2008 Certified Institution, Approved by A.I.C.T.E.-New Delhi,
Affiliated to J.N.T. University-Anantapur, Ananthapuramu.
Nandikotkur Road, Venkayapally, Kurnool, Andhra Pradesh – 518452. [Link].

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

DECLARATION

I hereby declare that this seminar report titled “DAROC TECHNOLOGY” is an

authentic work carried out by me as a student of Department of Computer Science and
Engineering, RAVINDRA COLLEGE OF ENGINEERING Kurnool, during December 2018 –
April 2019, in partial fulfillment of the requirements for the award of the Degree of Bachelor of
Technology in Computer Science & Engineering is a bonafide report of the work carried out
by me under the supervision of [Link]. I further declare that the work reported in
this seminar has not been submitted and will not be submitted, either in part or in full, for the
award of any other degree or diploma of this institute or any other institute or university.

SIGNATURE
K PRIYANKA (153T1A0548)

ii
 ACKNOWLEDGEMENT

First and foremost, I thank the almighty-God, from the depth of my heart, which has been the
unfailing source of strength, comfort & inspiration in the completion of this seminar report.

I would like to extend my gratitude to my guide Asst. Prof Dr. K. Srinivas Department of Computer
Science and Engineering. Under whose able guidance I have completed my seminar report. His
contribution is immense in order to cherish and add value to a student’s career.

I would like to extend my gratitude to [Link], Prof & HOD of Computer Science
Department for their cooperation and valuable support in every way during the period of the seminar report.

I would like to extend my gratitude to [Link] Babu, principal of Ravindra College of

Engineering for Women, Kurnool for their cooperation and valuable support in every way during the period
of the seminar report.

At last, I would like to thank Management and chairman Sri G.V.M .Mohan Kumar giving me an
opportunity to work on this seminar report and supporting me throughout the period of work at Ravindra
College of Engineering for Women, Kurnool.

SIGNATURE
K PRIYANKA (153T1A0548)

iii
 Table of contents

Chapter Title Page

Certificate I

Declaration II

Acknowledgement III

Contents IV

List of Abbreviations V

List of Tables VI

Abstract VII

1 Daroc Objectives 1

2 History of Blackboards 3

3 Importance of Blackboard 5

4 Goals of DAROC 6

5 DAROC External Architecture Details 7

6 DAROC Implementation Details 10

7 Performance and Bottlenecks 16

8 Hardware and Software needs 17

9 DAROC Toolkit 18

Conclusion 20

References 21

IV
 LIST OF ABBREVIATIONS

Abbreviation Expansion

DAROC Data -Activated Replicated Object Communications

FE
Functional Elements
DO
Data Objects
SWR
Single Writer Rule
FEBAR
FE Buffer Address Resolution
DONAR DO Name Address Resolution

BLM
Blocking Lock Mechanism

V
 LIST OF TABLES

Table No. Title Page

Table 1 Initialization of Data object 8
Table 2 Initialization of Functional Elements 8
Table 3 DAROC’s Locking Mechanism 13

VI
 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.

VII
DAROC Technology

CHAPTER 1
OBJECTIVES
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.

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.

Dept of CSE, RCEW, Kurnool-518002 Page 1

DAROC Technology

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.

Dept of CSE, RCEW, Kurnool-518002 Page 2

DAROC Technology

CHAPTER 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:

 Pipe and Filter

 Layered Systems
 Client/Server
 Object Oriented

Dept of CSE, RCEW, Kurnool-518002 Page 3

DAROC Technology

A close look into the history of educational technology will reveal that an invention from over
two hundred years ago remains arguably the most influential technological innovation of our
time. It was Josiah F. Bumstead who first declared in his 1841 essay, The Blackboard in the
Primary Schools, that the chalkboard is a groundbreaking technological invention (Krause,
2000). Numerous scholars have agreed with Bumstead’s pronouncement citing in reference to
the chalkboard that “the inventor or introducer of the system deserves to be ranked among the
best contributors to learning and science, if not among the greatest benefactors of mankind”
(Krause, 2000, p.11; Ressler, 2004, p.71; Tyack & Cuban, 1995, p.121). With the advent of
compulsory schooling in the United Kingdom in the late eighteen hundreds and the significant
increase in student population in public schools, the British acknowledged a sudden need to
adopt a unified education program. The chalkboard stood at the core of this new teaching culture.
This report will argue that the chalkboard gave rise to the standardization of public education,
and its integration into English classrooms in the nineteenth century led to the widespread
advancement of rote memorization as the dominant teaching pedagogy in the United Kingdom.

Dept of CSE, RCEW, Kurnool-518002 Page 4

DAROC Technology

CHAPTER 3

Importance of Blackgrounds

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 object oriented 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.

Dept of CSE, RCEW, Kurnool-518002 Page 5

DAROC Technology

CHAPTER 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 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.

Dept of CSE, RCEW, Kurnool-518002 Page 6

DAROC Technology

CHAPTER 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. [Link].
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.

Dept of CSE, RCEW, Kurnool-518002 Page 7

DAROC Technology

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 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.

Parameter Description
User Parameters O.N Parameters defined by user
Data Object Name String, User defined name
Number of Functional Elements Subscribers Integer, number of FE’s that read and write it
Size of the Instances Integer value of DO in bytes
Figure 5: Initialization of Data object

Initialization of a Functional Element:

Functional elements have five required parameters and as many user defined parameters as
deemed necessary by the programmer.

Parameter Description
User Parameters O.N Parameters defined by user
Functional Element Name String, User defined name
Number in input list Integer, number of FE’s that reads
Number in output list Integer, number of FE’s that writes
Activation criteria delay Integer, total delay in seconds
Ignore input conditional patterns Integer, 1=yes, 0=no
Figure 5.1:Intialization of Functional Elements

Dept of CSE, RCEW, Kurnool-518002 Page 8

DAROC Technology

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
[Link](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.

Dept of CSE, RCEW, Kurnool-518002 Page 9

DAROC Technology

CHAPTER 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 lock attr data members are used to lock the data
object during a read or a write to that object. Update count 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:

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. Ignore IC 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 input size 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 output size 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.

Dept of CSE, RCEW, Kurnool-518002 Page 10

DAROC Technology

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 is input buffer 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
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 FEBAR post is
another essential part of the FE activation cycle. The FEpost function finds all of the data objects

Dept of CSE, RCEW, Kurnool-518002 Page 11

DAROC Technology

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.

Dept of CSE, RCEW, Kurnool-518002 Page 12

DAROC Technology

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.

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.

Class Name Number of Locks Implemented

Data Object 2
Functional Elements 1
DO Name Address Resolution(DONAR) 1
FE Buffer Address Resolution(FEBAR) 1
Figure 6: DAROC’s Locking Mechanism

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

Dept of CSE, RCEW, Kurnool-518002 Page 13

DAROC Technology

obtains this lock, in order to access the critical section. 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 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 [Link]
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 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.

Dept of CSE, RCEW, Kurnool-518002 Page 14

DAROC Technology

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.

Dept of CSE, RCEW, Kurnool-518002 Page 15

DAROC Technology

CHAPTER 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

Dept of CSE, RCEW, Kurnool-518002 Page 16

DAROC Technology

CHAPTER 8

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

Dept of CSE, RCEW, Kurnool-518002 Page 17

DAROC Technology

CHAPTER 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.
 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 template Simple 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

Dept of CSE, RCEW, Kurnool-518002 Page 18

DAROC Technology

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.

Dept of CSE, RCEW, Kurnool-518002 Page 19

DAROC Technology

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.

Dept of CSE, RCEW, Kurnool-518002 Page 20