Applications Messaging - Initial Questions for the Community

To spark off the discussion of what we want from an Applications Messaging System, we've prepared some questions and topics for discussion. If you have opinions on these issues, then please add your views to the appropriate page. Following this we'll try to distill people's views into some sort of consensus (if possible!), considering what is achievable in the time we have.

Questions to kick off the IVOA Applications Messaging discussion

General Questions

• Which messaging systems might we want to look at for ideas to steal? e.g.
  • D-Bus (http://www.freedesktop.org/wiki/Software/dbus)
  • MPI and friends (http://www-unix.mcs.anl.gov/mpi/)
  • PLASTIC (http://plastic.sourceforge.net)
  • PVM (http://www.csm.ornl.gov/pvm/)
  • XPA (http://hea-www.harvard.edu/RD/xpa/)

Comment

There is a general acceptance that message infrastructure and messaging syntax&semantics should be treated separately:

Infrastructure

• Which set of platforms/languages should be able to access the messaging system? Comment
• Do we need....?
  • Security?
    • How much?
  • Encryption?
  • Guaranteed delivery?
  • Guaranteed ordering?
  • Queuing of messages?
  • Transactions?

Comment

• Everything changes: how do we deal with versioning of the protocol? Comment
• Should the system be dynamic (apps discover each other at runtime), or static (apps can be discovered even when not running?)
  • Is there/should there be a mechanism to start non-running apps?

Comment

• How do applications discover each other's capabilities?
  • Dynamically?
  • Through the registry?
  • Statically for apps they already "know"

Comment

Messages

• Who should define messages? Comment
• What should be the format of a message? Comment
• What are the message categories? Comment
• How do we balance the need for messages to be general enough for max interop, with the specificity needed to exploit the full power of an app? Comment
• Messages might mean different things to different apps. E.g. a 'loadImage'message might mean to render it for display to one app, plot its histogram to another, or stage it for processing to third. How do we deal with this? Comment
• Do we need to be concerned with obsolescence of messages? Comment
• In a Hub-based architecture, should the hub have any concept of the meaning of messages? Comment

Data Transport

• What data formats should we use?
• Do we need to send a data subset (i.e. rows from a table or image ROI only)?
• Do we need to share access to data (rather than passing references and each app making a copy)?

Comment

Intradesktop Messaging Questions

General

• Is a hub-based architecture best or should it be peer to peer or something else?
• Do we need to be able to partition apps within a hub into separate mutually inaccessible groups?
• Do we want a request-reponse style messaging?
  • Asynchronous messaging?
  • Polling?

Comment

PLASTIC-specific Questions

The following questions are to gauge how suitable PLASTIC is as a foundation for the restricted case of intradesktop application messaging:

Compatibility

• Can your application send and receive messages via PLASTIC?
  • If not, why not?
• Could you embed a PLASTIC Hub in your application?
  • If not, what's stopping you?

Ease of use

• Should PLASTIC have more underlying transport protocols?
• Should PLASTIC have fewer underlying transport protocols?
• What would you change in the PLASTIC API?
• How do we deal with a multi Hub world?
  • Do we need a protocol for "handover" as one hub shuts down?

Power

• Is the PLASTIC model of a message as a simple string accompanied by arguments, with "method call"-like semantics adequate?
• If you could use PLASTIC, but it doesn't do enough for you, what is missing?
• If PLASTIC were replaced by something else, what features of PLASTIC do you like and would like to retain?

Comment

Beyond the desktop

Inter-application messaging will typically be only on a single machine, however there may be cases where a general application messaging system might involve more than one computer. For instance, a remote compute cluster pushing data to a desktop app for visualization, a server process providing access to a remote resource, etc

Desktop2Desktop

• Is there a demand for collaborative data exploration?
• What technologies are there that could facilitate this, and cope with firewalls, NATS etc?

Comment

Desktop2Server

• Is this any of our business or is this a GWS issue?

Comment

And finally...

• The term 'Applications' should not be limited to the current suite of desktop tools, we should consider any application one might imagine
• What should our target be for May?

Comment

-- JohnTaylor & MikeFitzpatrick - 07 Feb 2007