|
||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |
See:
Description
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. |
CallbackService.Test | |
Command | |
DataItem | |
HTTPCommandImpl | Expose Command Callback functions through HTTP. |
HTTPCommandImpl.Test |
Exception Summary | |
UnsupportedCommand |
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.
public void
registerForCommandCallback(Object callbackObject, String externalCallName, String methodName, String methodDescription, String[] arguments, String[] argumentDescriptions);
//
//Usage
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!
|
||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |