User’s Manual Thomas Jefferson National Accelerator Facility



Download 415.94 Kb.
Page1/17
Date conversion28.01.2017
Size415.94 Kb.
  1   2   3   4   5   6   7   8   9   ...   17
C L A R A
CLAS12 RECONSTRUCTION AND ANALYSIS FRAMEWORK


User’s Manual



Thomas Jefferson National Accelerator Facility

12000 Jefferson Avenue, Newport News, Virginia, 23606



Document Control Sheet



Title

CLARA Users Manual

Version

3.1

Issue

2

Author

Vardan Gyurjyan

Date

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
17

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
64


Appendix A
69

Clas12 Java coding standards 69



Packages

 69


Variables
70


Methods

 70



Naming Conventions
71


Recommendations

72


Appendix B
73

Object model design recommendations 73

Has a” versus “Is a” relationship 74

More on using “is a” relationship 74

74



Interface based design 74

Contexts in which interfaces help 74

References 75


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.


  1   2   3   4   5   6   7   8   9   ...   17


The database is protected by copyright ©ininet.org 2016
send message

    Main page