User’s Manual Thomas Jefferson National Accelerator Facility

Preface

Software application development is a process of writing, testing, debugging, and maintaining the source code of particular algorithms. The source code is usually written in one of the high level programming languages (such as Java, C++, Python, etc.). As a result, software applications represent a set of instructions that computers use to perform specific operations to achieve required behaviors. The process of designing a software application requires expertise in many different subjects including knowledge of the application domain, specialized algorithms, formal logic, and of course, syntactic and semantic knowledge of the chosen high level programming language. This is a description of a widely adopted traditional approach that is used to design and develop software applications. So, what if a user is an expert in a specific application domain yet has a limited knowledge and experience in software programming. Obviously this user cannot actively contribute to the process of developing domain specific software applications. However, the same user can very efficiently design an application using available software building blocks: a process that does not require source code writing and compiling.

The ClaRA application design process is different from a traditional approach in two major ways. First, ClaRA application design is performed by linking together graphical icons (representing selected software building blocks, called services) on the design canvas of the ClaRA designer graphical interface, which is then “compiled” into a coherent application ready for the execution. The second and critical difference is that ClaRA applications execute according to the rules of data flow instead of a more traditional programming approach, where sequential series of instructions (lines of code) are written to perform a required algorithm. In this respect ClaRA application design promotes data and data flow as the main concept behind any physics data processing algorithm. ClaRA service execution is data-driven and data-dependent. The flow of data between services in the application determines the execution order of services within the application. These differences may seem minor at first, but the impact is revolutionary because it allows the data paths between application parts (services) to be the application designer’s main focus. A ClaRA service has inputs, is capable of processing data, and producing the output data. Once a given service receives valid data, that service executes its engine, produces output data, and passes that data to the next service in the dataflow path.

This guide shows how to develop ClaRA services (application building blocks) and compose data processing applications based on these services. In this guide, the term ClaRA service has a very specific meaning. It is similar to the SOA (Service Oriented Architecture) service definition and functionality. A ClaRA service provides an independent software component that is combined with other ClaRA services to assemble a final physics data processing application.

Let us elaborate on this definition, assuming that the reader is familiar with the object-oriented programming. Consider the difference between objects and services. An object represents an entity in a specific domain, being nothing more than data combined with associated processing routines. A service, on the other hand, is an atomic, self-contained piece of software. The ClaRA framework is responsible for locating, loading into memory, and connecting/linking services at runtime. ClaRA provides a unique environment for an application designer to load services dynamically as needed, deploy services at a desired granularity, link services across the network and across multiple virtual machines, combine services written in different programming languages, etc. Service specific information, including meta-data, is available through the ClaRA service interface. This is a guide to a new approach for developing physics data processing applications using self-contained, compiled applications, called services, which interact with other services through a well-defined interface.