Discussion: Starting a second node

Starting the second node in the hosting service was different to the first. Why did we only need an initialisation script for telnet? What about SAS? Don't we want to put that on this new node, too? And why did we reuse the Hospitality boot descriptor? The answers, in short, are because they are different applications of varying levels of sophistication...

The Hospitality boot descriptor has to be reused. It includes an identifier, hos01, for this particular hosting service. That same netlet descriptor executes the same netlet, which, when it initialises, will scour the LAN for another hosting netlet with the same identifier. It finds the original and they join together.

The telnet netlet is very simple-minded. All it does it listen on a given port and provides command line access to the hosting service. It doesn't have the intelligence to distribute itself. Also, assuming this second node is on the same machine as the first, they couldn't both listen on the same port, so it does need to be given its port number.

SAS, on the other hand, is very sophisticated. It is built with Beatrix which makes good use of the hosting service. So as soon as the hosting service is running on two nodes Beatrix will realise this and spread SAS out across both of them.

Starting our second node raises some other interesting issues. For example, SAS delivers netlet descriptors and JAR files via URLs. Both SAS netlets do this. Are they listening on different ports? If they're on the same machine then yes, they must be. Does this mean the descriptors and JARs are available at different URLs? Yes, it does. And a warrant references a service, which is really a location it can get netlet descriptors and JARs. So how does a warrant cope with multiple locations like this? Well, it simply contains several alternative URLs...

But suppose we started a SAS on one node, uploaded a service to it, and then made a warrant referencing the service in this SAS. It would only contain one URL, right? Right. And suppose we the started a second node and SAS spread itself out to that. What would our warrant say then? Well, a warrant is an XML file; it doesn't change magically just because some server's started up somewhere in the world. It still references the same one node, the first one. Okay, so what happens if the first node shuts down? By the magic of Jtrix SAS is still running on the second node, but isn't our warrant now out of date, since it points only to the first node? Yes, the warrant is out of date. So isn't that a problem? Well, it's a general problem of the Internet--if you rely on a service from one location and that location disappears then can't access the service--but, yes, that warrant is now useless. So what can we do about that? There are several things...

From the warrant-holder's point of view they should update their warrant from time to time. When they are connected to the service as a consumer they may do all their consumer tasks and also say ``Please give me an updated warrant''. The service, if it supports such a function, can give them a warrant with all they lastest SAS URLs. Beatrix helps applications support this function very easily.

The warrant holder, if they still find themselves with a useless warrant, could contact the service administrator directly and ask for an update. Of course this could be very inconvenient. At worst it would mean phoning them up, remembering their contract number and providing proof of who they are.

The real onus is on the service provider. For one thing they shouldn't give out warrants if they know their service only lives on one server which is likely to go down. They should pick their hosting service with care. This is helped further if they spread their service over several hosting services, which is exactly the kind of thing that Jtrix is designed for.

Second, this problem really only occurs if the single SAS URL is specified by IP address. If it's specified by a fully qualified host name then the DNS can be repointed. An even smoother version of this is possible when the DNS service is itself a Jtrix service, as is used in the Webtrix example below. If SAS is a consumer of the Jtrix DNS service then as soon as it notices its first server has gone down it can repoint the host name to the second server. The warrant-holder will never know the difference.