Grid Builder Status Rui Wang July 16, 2007

Grid Builder The Grid Builder uses a management console to deploy grids dynamically and remotely –The user UI monitors the status of all accessible resources –After receives the command from the user, each managed node starts building the required grids/services Meta data is saved in a so-called Registry, from which the console can retrieve information like: –Host IP Address –Status –UUID –Service Adapter Type –SA manager Type –Operating System, etc

Improvements based on feedbacks More types of useful metadata are added The user UI console can refresh the status information automatically A monitoring thread is added to the service adapter –the user UI can show the output from the remote resource at real time A prototype resource matching algorithm –E.g., based on OS type A dialog for user to choose a grid to deploy

User Interface (1)

User Interface (2)

User Interface (3)

Status A stable version of the grid builder tool is developed and serves as a benchmark for future development QuakeSim2 portals are installed on Ball’s cluster Installation manual and demo instructions are created

Future Work More grid applications for testing purpose –Sensor grids –Collaboration grids (Impromptu) –DoD grids Metadata repository to replace the current registry Daemon for maintaining and updating deployed grids automatically Grid profiles to facilitate feature matching

Deploy, Discover and Manage Sensors in the Grid Builder Rui Wang July 24, 2007

Sensor Grids To develop a flexible computing environment for coupling real-time data sources to High Performance Geographic Information Systems (GIS) applications Real Time Data (RTD) server –GPS device and a server –GML encoding for describing the data Integrate NaradaBrokering to provide real-time access to streaming data

Major Sensor Grid Components

Sensor Discovery Approaches Top-down –User pre-defined Bottom-up –Follows the WS Dynamic Discovery specification –Multicast group to discover existing sensor services

Message Exchanging between Sensor Adapter and Client

Sensor Discovery Process Initially a sensor sends a multicast Hello when it joins a network The client (the Grid Builder herein) multicasts a Probe to discover existing sensors A sensor may receive a multicast Probe and send a unicast Probe Match (PM) if it matches that Probe The same manner for a Resolve When a sensor dies or leaves a network, it sends a multicast Bye

Specifications The probe and reply messages are formatted according to WS_Discovery protocol and enveloped in SOAP Protocol assignments: –Discovery_Port: port 3702 –IPv4 multicast address: –IPv6 multicast address: FF02::C (link-local scope)

Make Sensors Manageable Resource Manager Side Service Side Service Adapter cgl.hpsearch.wsmgmt.WSManProcessor cgl.hpsearch.sensor.SensorServiceAdapt er Sensor to Manage Manager cgl.hpsearch.core.services.manager.Reso urceManager cgl.hpsearch.sensor.SensorManager cgl.hpsearch.wsmgmt.WSManClient cgl.hpsearch.sensor.SensorClientAdapter

Sensors in Grid Builder Deploy a new sensor Discover existing sensors over the network Provide up-to-date information on detected sensors Manipulate managed sensors: –Add/remove sensors –Assign sensors

RTD Server Currently the sensor grid takes archived data from a specific repository We developed a filter service to obtain the real time data from a GPS device (I-blue) –NMEA format –Example: $ MRK,0 ZDA, ,17,06,2001,13.0 GLL, ,N, ,W, 75.97,M VTG,218.7,T,2.38,H,0.18,V SGD,-1.0,G,-1.0,M SYS,3T,9 ZEV, E-006 A host running the filter service, which could be a laptop, PDA or Tablet, can work as the RTD server

Additional Slides HSD demo? Group/Sharedlets?