Applications Messaging Standard

[John Taylor]

On 12 Feb 2007, at 21:44, Mike Fitzpatrick wrote:

> On 2/12/07, Doug Tody <dtody at nrao.edu> wrote:
>> I think we are talking about two different things here.  The VO  
>> registry
>> would be used to discover applications or services available  
>> somewhere
>> on the Internet; the scope is world wide.  A "message bus" on the  
>> other
>> hand (PLASTIC is a simple version of one), registers connected  
>> apps for
>> a desktop session.  The types of apps used in a desktop session often
>> would not be available as services via the Internet (but they might
>> still be described in the VO registry just so that one can find out
>> about them).  The "hub" or message bus type of registry is more a  
>> type
>> of naming service.
>
> I don't think using the Registry for runtime access to capabilities  
> is practical
> or being suggested (although I might have said something along  
> those lines).
> As you say, using it to find an app when configuring a system is quite
> different,
> but then we need a separate discussion of how to register an app as  
> being
> V1.0 IVOAMsg (or whatever) compliant, as being a display/plot tool,  
> etc.

An idea we've toyed with in the past is that an application's  
registry entry would include which messages it understands.  Don't  
have an app running that can plot a VOTable?  No problem....search  
the registry for both "scatter plot" and the loadVOTable message and  
locate a suitable app.  In certain cases it would even be possible to  
automatically download and run it.  This task of locating and  
(possibly) starting applications, whether in a remote registry or a  
local cache, could indeed be completely decoupled from the messaging  
issue.

>
>> On the issue of using files to store/exchange metadata: this is just
>> too problematic for a distributed system (except maybe for simple
>> startup stuff).  Messaging is often used to link together modules  
>> in a
>> distributed system, and this may well span multiple computers.  Files
>> may not be visible from all participating nodes, plus there can be
>> synchronization, caching, and platform issues.  Best to avoid files
>> except perhaps for startup on the login/head node.
>
> The idea of a .ivoamsgrc directory was intended simply to be a  
> startup file/
> directory mechanism.  The thought being that each app could write  
> it's own
> "capabilities database" file indicating the messages it handles,  
> preferred type,
> of transport, task launch command, etc.  Other apps could read the  
> same DB
> file to decide whether/how to send messages.  These would be static
> files updated
> perhaps only with a new version of the software.  For startup, another
> file would
> keep track of who is 'connected' and in a world where users manually
> launch tasks
> every few seconds this normally would be manageable.  Firing up a  
> "system' of
> multiple tasks (e.g. a small pipeline or an alias for multiple GUI  
> tasks) could
> well have the syncronization problems you mention.
>
> Perhaps a .whatever directory as a local capabilities database  
> (similar to the
> .plastic file) and a runtime registry (hub, embedded functionality,  
> etc) of some
> kind is the simplest compromise?
>
> I'm still interested in ideas about how we keep the message  
> contexts separated,
> i.e. how do I avoid seeing *your* data on *my* window if we're both  
> on the same
> machine?

The .plastic file for each user includes the required connection  
info.  So, when I start my Plastic Hub it takes port 1099 for JavaRMI  
connections and 8001 for XMLRPC connections and writes these values  
into my .plastic.  When you start your Hub on the same machine it  
takes 1100 for RMI and 8002 for XMLRPC and writes these values into  
your .plastic.  Currently, we don't have anything to stop me guessing  
your ports and sending you unsolicited messages, except the fact that  
you will complain to the sysadmin who will then close my account.

John



>
> -Mike
>