Things to try yourself

Once you've got the skeleton application running, here are some things to try in increasing order of complexity:

1. Change the name of it.

   Put the application in your own package, rename it, create a new launch descriptor and launch it.

2. Change the number of workers and managers.

   The application starts up with 2-4 managers and 2-4 workers. But if you're only running a one-node cluster then it will fail to create more than one of each since WorkerPool tries to start them on different nodes. It will keep trying from time to time and keep failing. Change it to one manager and one worker.

3. Rewrite the getMessage() command.

   Currently this is generated with a ConsoleFactory. Avoid this, and instead provide a get-message command by implementing your own IConsoleFacet. Then you can return a JointConsole again.

4. Add a set-worker-redundancy command.

   Add a command that changes the number of workers at will, so you can take it down from 2-4 to 1 remotely. The command will take effect next time the WorkerPool does its periodic check. It should be added to the admin service; make sure you don't lose all the commands in Beatrix's own IConsoleFacet.

5. Add another worker pool.

   Then amend the set-worker-redundancy command to apply to either pool by name.

6. Ensure your warrants are signed

   Create the launch descriptor using a key pair. This ensures all the warrants will then be signed. Check this as follows: launch the application with label, say, sk6; the variable $sk6 will then have the application's admin warrant; use the console's dump command to write the warrant XML to a file; look at the contents of the file.

   Then you can also try the following:

   1. Modify the warrant and try to bind it. You should find it won't bind.
   2. Remove the signature, change the warrant, sign it with a new key, and try to bind this. You should find the binding fails before completion. Of course, this process is more involved. To change the warrant you need to use org.jtrix.project.libjtrix.warrant.WarrantBean. Construct a new instance using the unsigned XML from an InputStream; apply the sign method using the new private key and an X.500 name; then write out the new XML using the writeWarrant() method.
7. Use a third party service.

   No doubt your re-implementation of get-message above simply calls the getMessage() method from a SkeletonFacet object. Adapt this so it gets the message as if it was from a third party service.

   First, change the get-message command so that it takes a warrant as a parameter. Then the command's implementation should bind the warrant and get the ISkeletonFacet, just like in Section .

   To test this works, first get a warrant using get-warrant from the skeleton application's admin service. This command is part of the standard Beatrix console. Make sure you get a warrant for the skeleton service. Next connect to this service and use the get-message command.

8. Use the management MIB with a set-message command.

   Create a set-message command which allows the default message to be changed. Store this string in the management MIB using the IManagementState plugin. Make sure each worker is updated with the new message, either by alerting the workers when the message changes via an internal facet. Also ensure that new workers get the latest message when they start.

9. Use the warm start argument.

   Ensure the latest message is stored in the warm start argument. This way, if the message is changed and the service crashes, when it's restored it will still output the most up to date message.