Discussion: Launching and running

As we've already mentioned, the above is discussed more in Programming with Jtrix: The Beatrix application framework at http://www.jtrix.org and Appendix . But here's a summary.

First we announce the use of whichever hosting service we're going to use. After this point the launcher knows where to launch any applications to.

Next we announce which SAS we're going to use. This is not obligatory, but it's incredibly helpful. It tells the launcher that when we launch an application it can upload the JARs into that SAS, which saves it serializing them into any netlet descriptors and warrants each time it wants to generate one.

Then we run (i.e. launch) the skeleton application on the hosting service. The launcher takes the application descriptor, skeleton-launcher.xml, and sees which JARs it needs. It reads them out of the local file system and uploads them into the SAS. Then it creates a netlet descriptor which references those JARs by URL and runs that on the hosting service. The application initialises on the remote node and returns a warrant. At this point we are the application's administrator and have admin-level access to it.

We have labelled the application sk and our admin warrant is in variable $sk. Listing all our applications confirms we're only connected to that one. Listing the commands in that application gives various options. We dump the admin warrant into file skadmin.xml.

One of the commands allows us to get a warrant from the skeleton application, so we create a new basic warrant in variable $bw. This gives us access to the basic ``skeleton'' consumer-level service. The backticks allow us to execute a command and return the result in-line.

We connect with this warrant. Listing all our applications confirms we have two application connections. Listing the commands in the skbasic connection shows it presents a different set of commands. This makes sense--consumers have different requirements to administrators. One of the commands allows us to get a message, so we issue that command.

Finally we dump the basic warrant into a file and quit the launcher. Quitting the launcher does not quit the application, however; that keeps running until told to quit by the sk.quit command. Now we can e-mail the basic warrant to others so they too can access our service as consumers, from anywhere in the world.

Notice that we've also saved our admin warrant into its own file. We can use this to reconnect to the application at any time in the future to perform admin work.

Another point to note is that the different levels of service here (admin and consumer, called skeleton) are entirely up to the application. Other applications may have any kinds they wish, with any names they wish.