Applications Messaging Standard

[John Taylor]

On 9 Feb 2007, at 17:13, Mike Fitzpatrick wrote:

>
>
> 	Lastly, people are still talking about the/a 'hub':  My
> understanding is that this is an artifact of the RMI used in  
> PLASTIC, but
> some apps have embedded hubs and in other cases it's a standalone  
> process.
> PLASTIC apps all connect to the hub in a point-to-point manner (please
> correct me if I'm wrong so far).  So, is the 'hub' in question a  
> simple
> registry of apps and mini-router or does it, or the idea of it,  
> serve some
> other purpose we need to preserve?

Hi Mike,
This isn't quite right.  In the PLASTIC architecture, the apps never  
talk to each other directly, but all go through the Hub.  The Hub  
serves a number of purposes:
a) It provides a registry of currently running applications that can  
receive messages, including information about which messages each app  
supports
b) It routes messages from the sender to any recipients.  The sender  
can specify "broadcast to all", or "send only to this/these apps" and  
the hub transmits the message to the intersection of this set and the  
set of registered apps that support the message.
c) It provides a translation from one wire format to another.   Thus,  
my apps speaks Java RMI, your app speaks XML-RPC.  We both speak to  
the Hub in our native tongue and it handles the translation.  In my  
opinion this is one of the most valuable services it provides.  It  
also is why I keep insisting that PLASTIC != Java RMI ... one of its  
main features is that it handles multiple wire protocols and does the  
translation.   We would have used a Hub even without JavaRMI being  
one of those protocols.

Now, originally there was a single Hub implementation that you needed  
to have running in order to use PLASTIC.  This was distributed as  
part of the Astro Runtime.  However, it soon became clear that  
authors of many applications would want to embed a Hub inside their  
application, obviating the need for the user to start a separate  
application just to use PLASTIC.   It doesn't matter which  
application contains the Hub...it doesn't really make any difference  
as far as the client application goes.  At any one time you have a  
single Hub running and it will usually be hosted by the first  
application to start.
I think this approach is turning out rather well...it means that the  
user doesn't need to be so aware of a Hub.
A problem we haven't yet tackled is how to deal with a Hub dropping  
out when an application closes - we would then need a new one to  
start to pick up the slack.  I'm interested to know if we could do  
this without the user even being aware of it.


> Can a "$HOME/.ivoamsgrc" directory
> containing user preferences, a local app capability registry,  
> caches, etc
> serve the same purpose (it's a well-known location to all apps so
> provides separation between users on the same machine, apps can update
> their capabilities db w/ each new version, scribble a file saying  
> who's
> "connected",  no real Registry lookups so it'll continue to work
> while you're on the plane, etc)

We arrived at the same idea as you (or rather, Noel did, and I stole  
the idea): we use a $HOME/.plastic file to contain the information an  
application needs to make its initial connection to the Hub.  We  
don't use it to store application metadata; that is what we use the  
Hub for.
A few weeks back, I did actually propose that if we were to do away  
with multiple wire protocols and only support (say) XML-RPC, then we  
could consider dispensing with the Hub completely, and instead use a  
directory or file just as you suggest to store application  
metadata.   However, we concluded that even if the Hub was no longer  
needed for wire protocol translation, the other services it provides  
make a Hub-based architecture simpler to program to and more robust.

You seem to be thinking about getting app metadata out of an IVOA  
registry.  This is something we haven't done: the Hub only knows  
about applications that are currently running.  I think this is an  
idea well worth exploring.

>
> -Mike
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/apps/attachments/20070212/70d8e6bc/attachment.html>