User’s Manual Thomas Jefferson National Accelerator Facility

Download 415.94 Kb.
Size415.94 Kb.
  1   2   3   4   5   6   7   8   9   ...   17

User’s Manual

Thomas Jefferson National Accelerator Facility

12000 Jefferson Avenue, Newport News, Virginia, 23606

Document Control Sheet


CLARA Users Manual






Vardan Gyurjyan


27 July 2012

Table of Contents

Preface 3

Who is this guide for? 4

Acknowledgements 5

Glossary of terms 6

Chapter 1

Physics Data Processing: A Contemporary Approach 7

Data processing requirements 7

Increasing physics output 8

Choice of computing model and architecture 9

Chapter 2

The Framework 10

Programming paradigm 10

Data vs. algorithm 10

Data classification 11

Design architecture 12

Services 13

Service categories 13

Service couplings 13

Service compositions 14

Service deployment 14

Data processing environment, service container, and SaaS implementation 14

Service registration and discovery 16

Service granularity 17

Service accessibility 17

Service invocation

Transient data envelope 18

Service communication monitoring 20

Exception propagation and reporting 20

Cloud formation 21

ClaRA batch deployment 22

Chapter 3

ClaRA SaaS In Nutshell 23

All you need to convert a software application into a ClaRA service. 23

It is perhaps best explained through an example. 24

Chapter 4

Service Developer’s Workshop 28

How to install ClaRA? 28

Environment Setup 28

JToolBox 29

Clara Platform 29

What if I also need the source code? 29

How do I start a platform? 30

Environment Setup 30

Platform Name Definition 30

Running the Platform 30

How to start an additional data processing environment? 31

My first hello-world service 32

How do I make my service available to the public? 34

How do I check if my service is up and running? 38

How do I request a service? 40

How can I request a service based on a keyword in a description? 42

Asynchronous service request 44

Configuring a service 46

Services that read/write EvIO files 51

Application design or service composition 56

ClaRA application debugging and communication logging service 57

Chapter 5

Application Designer 58

Designing software applications 58

Graphical interface 59

Toolbar menus 60

Clas12 PDP engine deployment and testing

Appendix A

Clas12 Java coding standards 69






Naming Conventions



Appendix B

Object model design recommendations 73

Has a” versus “Is a” relationship 74

More on using “is a” relationship 74


Interface based design 74

Contexts in which interfaces help 74

References 75


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.

Download 415.94 Kb.

Share with your friends:
  1   2   3   4   5   6   7   8   9   ...   17

The database is protected by copyright © 2024
send message

    Main page