Hi Blair, Andrew and Jim,
Andrew:
The issue I see with your design is that for every request & response you will be sending a class with all it's methods over the network. This will result in greater bandwidth usage and slower responses.
If you used a Transfer Object then you would be passing a much smaller, more generic object. All the Transfer Object contains is the data to be worked on and an indicator to say what the sender is sending. Three comments.
When you send a serialized object, your are not "sending a class with all it's methods over the network", just its signatures IMO.
The main purpose of TransferObject seems to be to avoid
multiple remote calls just to access multiple individual attributes : "The client usually requires values for more than one attribute or dependent object from an enterprise bean. Thus, the client may invoke multiple remote calls to obtain the required data.". The context here is quite different : your client calls some executable command once, bringing with itself all the data needed to perform the task.
If you really want to optimize the way your commands are serialized, look at the Externalizable interface. But if you use it, it will be at the cost of maintability.
Jim:
Also, giving this Command object responsibilities on both client and server seems a bit much to me. That means that any time you want to change anything on the client or the server, the Command classes will have to change. 100% agreed.
Blair,
quote:I'd consider having a Command class for passing messages from client to server, and maybe a separate Response class for sending data from server to client.
...resulting in a doubling in the number of classes. Not necessarily doubling. You just need a separate Response class per possible result type, meaning that - at least in theory - you may have multiple commands using the same response class.
Blair,
If the server does need to initiate a message, my messaging should be generic enough to do this. I was intending to use the same MessagingPort object (sends and receives messages) the client and the server. I think that by coupling server-side commands with client-side ones, your system is not generic at all. When a server initiates a message to the client, it performs a "callback" to the client. As such a callback is not related to any server-side command, it's easier to keep them separate. While most server commands return something to the client, callbacks will typically be void commands. Moreover, if you use callbacks as I do, the server must be able to talk to any client independantly of the current client connection context (initiating a command, or waiting for a result or doing nothing). So I think that you need a separate communication way for callbacks
if you want to implement them (the client acting as a server on some callback port).
I like your ServerContext context parameter in your performServerTask method. I suppose that your connections are permanent and stateful and that your ServerContext object is what I called Session in my Command interface :
Blair,
I wasnt aware of the Value or Transfer Object Pattern in this context, I think its a good idea. The only drawback is that you have these horrible if or switch statements at either end to determine what sort of action it is. With a Command object, one simply needs to call performTask() and doesnt need to interpret it in a switch statement. I agree that such a switch statement is ugly and that
you should avoid it.
Best,
Phil.