Applications Messaging - Initial Questions for the Community

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/)

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?

• 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?

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

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)?

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?

PLASTIC-specific Questions

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?

Beyond the desktop

Desktop2Desktop

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

Desktop2Server

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

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?

-- JohnTaylor & MikeFitzpatrick - 07 Feb 2007

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

Applications Messaging - Initial Questions for the Community

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/)

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?

• 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?

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

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)?

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?

PLASTIC-specific Questions

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?

Beyond the desktop

Desktop2Desktop

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

Desktop2Server

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

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?

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

Applications Messaging - Initial Questions for the Community

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/)

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?

• 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?

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

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)?

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?

PLASTIC-specific Questions

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?

Beyond the desktop

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

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

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?

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

Applications Messaging - Initial Questions for the Community

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/)

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?

• 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?

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

Messages

• Who should define messages? Comment
• What should be the format of a message? 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)?

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?

PLASTIC-specific Questions

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?

Beyond the desktop

Client2Client

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

Client2Server

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

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?

-- JohnTaylor & MikeFitzpatrick - 07 Feb 2007

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

Applications Messaging - Initial Questions for the Community

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/)

Infrastructure

• Do we need....?
  • Security?
    • How much?
  • Encryption?
  • Guaranteed delivery?
  • Guaranteed ordering?
  • Queuing of messages?
  • Transactions?

• 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?

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

Messages

• What are the message categories?

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)?

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?

PLASTIC-specific Questions

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?

Beyond the desktop

Client2Client

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

Client2Server

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

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?

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

Applications Messaging - Initial Questions for the Community

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/)

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?
• Do we need....?
  • Security?
    • How much?
  • Encryption?
  • Guaranteed delivery?
  • Guaranteed ordering?
  • Queuing of messages?
  • Transactions?
• Everything changes: how do we deal with versioning of the protocol?
• 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?

Messages

• Who should define messages?

• What are the message categories?

• 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?

• Do we need to be concerned with obsolescence of messages?
• In a Hub-based architecture, should the hub have any concept of the meaning of messages?

• • How?

General

• Do we want a request-reponse style messaging?

PLASTIC-specific Questions

• Can your application send and receive messages via PLASTIC?

• Could you embed a PLASTIC Hub in your application?
  • If not, what's stopping you?

• 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 PLASTIC were replaced by something else, what features of PLASTIC do you like and would like to retain?

Beyond the desktop

Client2Client

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

Client2Server

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

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?

-- JohnTaylor - 01 Feb 2007

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

Applications Messaging - Initial Questions for the Community

Questions to kick off the IVOA Applications Messaging discussion

General Questions

Infrastructure

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

• 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?

Messages

• Who should define messages?

• Do we need to be concerned with obsolescence of messages?
• In a Hub-based architecture, should the hub have any concept of the meaning of messages?
• Do we need to share access to data (rather than passing references and each app making a copy)?
  • How?

Intradesktop messaging Questions

• Is a hub-based architecture best or should it be peer to peer?

PLASTIC-specific Questions

Compatibility

• Can your application send and receive messages via PLASTIC?
  • If not, what is missing?
• 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

• Can PLASTIC cope with the widely different capabilities of different applications?

Beyond the desktop

Client2Client

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

Client2Server

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

And finally...

• What should our target be for May?

-- JohnTaylor - 01 Feb 2007

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

Applications Messaging - Initial Questions for the Community

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

Applications Messaging - Initial Questions for the Community