Heddle Hall B Tax-Day-1, 2008 Visualization in a Service Oriented Architecture.

Heddle • Hall B • Tax-Day-1, 2008

Visualization in a Service Oriented Architecture


Outline

• Service Oriented Architecture (SOA)

• Visualization in a SOA

• ced for 12 GeV

• Plugin Architecture (new, important)


Service

Service: An application accessible on the Web (or an intranet) through a URL. It is accessed by clients using well defined (often XML-based) protocols, over standard protocols. Access to a service is through its interface, often defined by an XML document.

An architecture comprised of Services is called a Service Oriented Architecture (SOA).

Now that’s a really boring definition.Let’s try to make it “real.”


Visualization, like life: Thin is better than fat

• Fat Client: Most/all of the application resides on, and runs on, the user workstation. – Pluses: standalone, power, speed– Minuses: maintenance, deployability, tight coupling

• Thin Client (or Smart Client): Application split between client and one or more server computers. (Google Earth)– Pluses: easy to deploy, loose coupling– Minuses: synchronization, speed-hit

• Browser Client: An extremely thin client that uses a browser to deliver a small application (MapQuest)– Pluses: auto-deploy, synchronized (~no coupling!)– Minuses: custom graphics hard, sluggish

fat

thin


Fat Clients in the 21st Century

• Fat clients are considered anachronisms—and are especially bad as complexity grows and environments become more heterogeneous (UNIX, Linux flavor du jour, XP, Vista, Mac,…)

• Thin clients that interconnect services to solve a “larger” problem are the “in” way to go.

• Successful thin clients should consider becoming, in turn, services. (Egalitarianism: everyone takes, everyone gives.)


Fat Client Example: ced

† Including the long-in-tooth graphics library Hv†† #ifdef AIX, #ifdef ULTRIX, #ifdev HPUX, #ifdef SPARC, #ifdef LINUX, #ifdef IRIX, …††† Non-standard not by choice—there is no standard.

~250K lines of C †

• Custom geometry specification• Custom magnetic field format• Private “noise” finder• Custom graphics• Conditional compilation hell ††

• Nonstandard C-FORTRAN calls†††

• Hideous make (Imake) deploymentHard to maintain, hard to deploy


More SOA Rhetoric

• Migrate from fat clients, each tightly coupled to its functional units, to a thin clients, each loosely coupled to a common set of services. (It is the vision of utility libraries writ large.)

• Even though a fat client might be “modular” the purpose of a SOA is to make the entire suite modular and interoperable (and extensible).

• SOA is not meant to solve computabilty intractability. (Not a new parallel processing/distributed computing/shared-memory paradigm.) It is meant to make complex architectures more maintainable, useful, interoperable, deployable, extensible, accessible, …

Slice O’ apple pie


Modular and User Friendly

Decade Modular Means: User-Friendly Means: Interoperable?

1970’s Use subroutines! Run again?(Y)es (N)o (Q)uitEnter choice:

No

1980’s Break your program into many files, use C, use common libraries

No

1990’s OOP, Remote Method Invocation, Messaging

Within an application

2000’s Service Oriented Architectures

JAVA and Microsoft graphics developed for the web

Within an architecture

http://stevenjohnevans.co.uk/photos/sample/images/515/425x295.aspx


Litmus Test: The unanticipated User

AmazonServer

Classic Amazon: Amazon’s server talks to its website

Specialty resellers spring up to sell books for Amazon

Author SearchGenre Search

Publisher Search

Purchase

Decomposes its business logic into public web services

DHS Report:

Material Science textbook purchasing trends

Unanticipated User


What Services?

• Authentication• Events

– Live events– Archived events

• Trigger related• Run related• Calibration• DAQ • Coordinate System

• Display• Simulation• Histogram• Geometry• Analysis• File System• Magnetic Field• Mathematical• Logging

To be determined, but would include some of these: †

† One overlooked “benefit” of a SOA is that non-programmers will participate in selection of the services—i.e., the functional decomposition.


Visualization in a SOAGeometry Services getWireLocations() getScintillatorVertices()

Run Services getRunDescription()

Analysis Services getDriftChamberNoise() fullReconstruction()

EventServicesgetRawEvent()getAnalyzedEvent()

Display Services getEventImage()

Magnetic Field ServicesgetField()

Display Services provides images to embed into web pages—for remote monitoring and PR. It could be a headless event display turned into a web service.

For ced, approximately 200K of the 250K SLOC are in functions shown here as services. Thus the same functionality would require many fewer lines—much more manageable. (Not to mention that the relocated code is now shared.)

File System Servicesopen()getTempFile()

Service consumer

Service provider


Ced2 (ced for 12 GeV)

• Written entirely in Java

• Available as a stand alone application or

• Available as a “Web Start” application

• Service consumer, service provider

• MDI (Multiple Document Interface) paradigm

• Plug-In Architecture


Basic Architecture

Geometry service

Event service

Cached Data

(e.g., geometry)

Config-uration

XML

Event Files

Other Service

Other Service

Other Service

File System

Event Stream

ImageService

XMLParsing

bCNUlibrary

Servicebackbone

ced2 “proper”(MDI paradigm, as was ced)

cMSGlibrary

CNU provided code


At Startup

Read ced_config.xml–Load possible server connections–Present the user with a menu (or use

default)–Connection is made (or not)–Geometry Service is queried as to

version– If fails, or version is same as local,

cashed version, read from the local file system rather than from the service


Plug-in Architecture

• Based on inheritance and reflection

Abstract class Ced_Plugin

class My_Plugin

public class MyPlugin extends Ced_Plugin

public static Ced_Plugin getInstance() {}

public void newEvent()

public void newState()

public void postData()

(etc)

Plugin implements getInstance

Plugin gets-for-free newEvent, newState, etc.


Reflection based Plugin: True extensibility• (Anyone) writes a class implementing getInstance().• Can override service methods, such as newEvent().• No recompilation of ced2 is required—the plugin is

simply “dropped” anywhere into the Class Path• At startup, ced2 looks in its Class Path for plugins• The plugin will be instantiated. If it is graphical, it will

show up on the desktop and in the menus• It will receive events, state change notifications, etc.

plugin

plugin

+


Current Status

• bCNU graphics library (Swing based) (bulk of work up to now)– This handles all the infrastructure, drawing objects on the

screen, converting to pixel coordinates, generic xml, etc.– In repository, est. 75% done.– None CLAS specific (could be used by Hall D)

• Ced2– Specifics of CLAS, CLAS geometry, events, etc– Plugin extendibility being tested– In repository, est. 10% done– Version 0.9 (SVT, Drift Chambers, Plugins) end of summer

Heddle Hall B Tax-Day-1, 2008 Visualization in a Service Oriented Architecture.

Documents

Transcript of Heddle Hall B Tax-Day-1, 2008 Visualization in a Service Oriented Architecture.