Package com.objectwave.appArch.admin

Allow applications to dynamically add commands that can be invoked by outside requests.


Class Summary
CallbackHolder Holder for callback objects in the Command Callback Service
CallbackHolder.Test Unit test of the ProcessDescriptor.
CallbackObject Holder for callback objects in the Command Callback Service Might make this an Inner class Needs to include argument accessors
CallbackService Use this service register command callbacks and properties.
HTTPCommandImpl Expose Command Callback functions through HTTP.

Exception Summary

Package com.objectwave.appArch.admin Description

Allow applications to dynamically add commands that can be invoked by outside requests. Think of it as a simple, low effort way of exposing services by your running process.

Sometimes you just want a 'command' to be exposed by your java application so external applications can communicate with your application. You don't want to deal with CORBA idl, or RMI, or some other messaging mechanism to provide these commands. More so, you may even want to remove the ability for others to invoke commands once the system is in production. Perhaps these commands only exist to facilitate you. These classes allow for 'back door' commands to be added to your process with minimal effort.
It is NOT intended to replace any of the previously mentioned mentioning mechanisms. Use the technology and solution that right for your situation.

There are two elements to using the solution in this package. The first is the command definition. The commands are registered with the CallbackService.
The method to use is :

public void 
registerForCommandCallback(Object callbackObject, String externalCallName, String methodName, String methodDescription, String[] arguments, String[] argumentDescriptions);
String externalName = "User.add";
String description = "Add a new user to the system";
String method = "addNewUser";
String argTypes = new String [] { "java.lang.String", "java.lang.String" };
String argDesc = new String [] { "The first name of the user", "The second name of the user" };
CommandCallback.getInstance().registerForCommand( this, externalName, method, description, argTypes, argDesc );

And you would have dynamically added a command. The method being invoked when the command is called is "addNewUser". It takes two arguments of type String. The first argument represent the first name of the user.... I think you got it.

What may not be clear is the external call name paramter. To avoid problems with similar method names, it is required that you create an external name for your command. Each external call name MUST be unique within the process. If a name already exists when registering a command, and exception is generated. The external call name is the mechanism used to lookup and execute the dynamic command. With the right client side UI you can leverage the '.' delimeted call name to create groups of commands. There may be a "User.remove", and a "User.update". As well as some adminstration commands "Test.runConsistencyTests", or "App.shutdown".

Once the commands are registered, exposing them to the outside world is matter of using an adapter. You could build CORBA, RMI, or even a SOAP adapter to use the CommandService. These adapters expose the list of dynamic commands and is responsible for their invokation. In the current package there is only one adapter. This adapter exposes commands through a trivial HTTP server that can be embeded in your process!

Using the HTTP adpater is really quite simple:

new HTTPCommandImpl().initialize();

This will create an HTTP server listening on port 3003. Point your browser to it, and invoke your commands!

To test the CallbackCode in your browser, run ' java com.objectwave.appArch.admin.HTTPCommandImpl$Test'. Point to http://localhost:3003/ and see a simple default command. When you invoke the command, you'll be taken to a results page. This page will show the return value (if there is one) of the invoked command. Have fun!