Why Byte Arrays?

[Jeff]

Floresh writes:

One thing I noticed. All of the send methods take a byte array. This does lend itself well to Filter chains etc that I saw in previous releases. If you assume it will always be a string then it might not be as a big an issue to encode/decode/encode/decode etc in that filter chain. But more complex messages that would add a great deal of overhead.

It would be better to define an interface called Message or something like that. Maybe Data that defines one mehod. getID() or getName() or something like that. Then define two other interfaces. Encoder and Decoder that can be configured in the application properties. public byte[] encode(Message msg) and public Message decode(byte[] data). Thus the system could pass the messages around as objects (Serializable have you) but objects none the less until they reach a point in the chain where they need to be transmitted across the network. At that point the server could use the application specified encoder to encode them and send them. Likewise, when messages are received they could automattically be decoded.

Of course this is only necessary in the context of Filter chains where encoding/decoding over and over again for each Filter makes no sense unless the encoding is basic. Take for example a message that was built using ASN objects that is encoded/decoded using DER or an object parsed from XML or something. Just a couple of examples of messages that would not benefit from constant encoding/decoding through the Filter chain..

[Jeff]

To quote the client tutorial (page 6) :

All communication in the SGS is done by sending and receiving byte arrays. To a Java coder this may seem a somewhat old-fashioned way of doing things. The SGS, however, is a client-agnostic system. The SGS team intends to deliver client APIs for J2SE, J2ME, and C/C++.  Other platforms may also be identified as later client targets by the SGS team or by the community.
While a few cross-language object systems exist, they are either platform-specific (for example, DCOM) or very complex, with serious overhead (for example, CORBA). The conclusion of the team was that it was best for the system to provide the common and efficient base of sending and receiving arrays of bytes, and to let specific applications build on top of that according to their needs.