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
>
Received on 2007-02-12Z19:41:27