Radar Simulation Project

1
Radar Simulation Project

• System Overview
• JMS
• Publish/Subscribe
• Architecture
• Lessons learned/results

2
System Overview

• Radars will track a number of different objects.
• A track has position, velocity, timestamp and id
• A correlator associates objects from different
  radars.
• The display visualizes the tracks.
• Logger stores the tracks for later use.

3
System Overview

• There is a many to many relationship between
  producers and consumers
• Old data is not that important. Data becomes
  stale after a while. Data is time critical

4
Radar Coverage
There is an overlap between the coverage of
radars. More than one radar may be tracking the
same plane. Correlator, associates tracks from
different Radars.
Radar 1
Radar 2
Radar 3
Radar 5
Radar 4
5
Data Flow
Radar
Display
Correlator
Radar
Radar
Logger
Note each data producers has many data
consumers. It is many to many relationship.
6
JMS

• J2EE standard to integrate various messaging
  system in Java.
• Data is sent from producers to the consumers.
• Decouples producers from consumers.
• Supports two different paradigms
• Publish/Subscribe
• Queueing

7
Publish Subscribe

• An extension of the Observer Pattern.
• Adds a channel that receives data from publishers
  and forwards the data to subscribers
• Subscribers register with the channel not with
  the producers.
• Loose coupling between publishers and
  subscribers.
• Useful when a producers sends data to many
  consumers

Channel
Publisher
Subscriber
8
JMS

• Message have header
• Header has property list
• Filters for properties
• JMS supports 5 message body types
• Object, primitive, stream, byte, text

9
Java vs RMI (CORBA)

• JMS
• Data is pushed to consumers
• Loose typing
• Receive any type of Message

• RMI
• Clients make requests
• Strong typing
• Parameters type are specified

10
Distributed Technology Choices

• RMI
• Simple but it would require each consumer to
  register with each producer.
• Not very scalable approach, too much book
  keeping.
• JavaSpaces
• Loose coupling between consumer and producers
• Data could be shared in same space
• Good possible choice.

11
Distributed Technology Choices

• JMS
• JMS works well with a many to many relationship.
• No book keeping
• Loose coupling
• Easy to use
• It won the toss up.

12
Architecture

• StartSync
• Starts the components are almost the same time
• Radar and correlator send ready message, wait for
  a start message
• Radar
• Simulates a radar, produces tracks

13
Architecture

• Correlator
• Associates tracks
• Logger
• Logs the data in ASCII or SQL using JDBC
• Display
• Visualizes track information for users

14

Starter
SyncChannel
Radar
Correlator
RadarChannel
CorrelateChannel
Radar
Radar
Display
Logger
Display
Logger
15
Future work

• Use filtering
• Improve performance by reducing bandwidth
• Use J2EE
• Use EJBs for storing
• Use message driven beans for receiving
• Use multiple messaging servers.
• Use JavaSpaces
• May reduce need for synchronization

16
Conclusion

• Some issues with the weak typing.
• Used a lot of synchronization primitives
• Data arrives asynchronous
• Easy to use
• API was simple to learn and use.
• Easy to add new clients.
• Scalable
• New consumer had to subscribe to the topic.