Having more complex, in-depth samples is something we are working on for the next release if JBossRemoting (1.4.0) as is badly needed. Until then, can find one I just posted at http://wiki.jboss.org/wiki/Wiki.jsp?page=Remoting_sample_code.
Thanks for posting those examples.
After gleaning the javadocs for the Client class, I also found that arbitrary objects can be sent to the server by using the invoke(Object, Map) method, where I am using a Hashtable (implements Map) to send objects to the server. One deficiency of the set of invoke() methods is that it forces one to send a serializable object when, in some cases, none might be required (in case there are no params to send). In other words, I would like to see a
public java.lang.Object invoke(java.util.Map metadata)
method included in the API in the future.
We are working on not requiring Serializable object to be passed (which will be done via JBoss Serialization project).
After this is available, not sure if:
public java.lang.Object invoke(java.util.Map metadat)
would be needed any more, since could do the same using:
Map myMap = new HashMap(); //add map entries myClient.invoke(myMap);
and would do the same thing. Let me know if you disagree and why. The metadata map was meant to provide extra information not related to the invocation payload object itself. Without a payload object, not sure what good the metadata would be.
I am using the metadata object to send a set of objects that my custom handler on the server side uses to determine the stateless session bean to use, the method to invoke on that session bean, and finally, an array of objects representing the arguments for that method. This lets me write a generic handler, which after using some reflection, can invoke *any* method on *any* server side object accessible by this generic handler. This helps me avoid writing multiple handlers for different types of tasks. I am not sure how I would use the Object in the invoke call. It does not provide the flexibility I need. Perhaps if I had a one to one mapping between handler and service method, I could use the Object to send arguments (as an Object) for the service method I am invoking from the client side. I think that instead of viewing the Map in invoke as a metadata object, you should view it as a container that may be used to send arbitrary objects over to the handler. In many, if not most, of the cases, the programmer (if he/she is like me) will not really need the Object in the invoke call. Perhaps renaming the metadata object to something else will help reduce confusion if you decide to implement my suggestion, because I agree that the term metadata would sound "odd" if there is no accompanying data.