Hi, karmaGfa, I'm one of the developers who worked on that API. We spoke for awhile at GDC.
The classes "com.sun.sgs.client.ClientChannel" and "com.sun.sgs.app.Channel" are both a channel that allow to send some messages to another network entity, but they share absolutly no type at all, making the API totally asymetric.
Good point! The short answer is: this is by design. Let's take it in pieces:1. Why do the server-side channels have more funtionality than the client-side channels?
Since this is the core SGS API, we want to include only the necessary functionality. We (or you!) can always build utilities to implement extra features, like letting clients join or leave channels directly. But if we put that into the core API, everyone would have to support it: all network wire protocols, and all client API implementations (even C++, Java Micro Edition, Flash, etc.).
The core operations let you send a client-to-server session message requesting a join, and your application logic can parse such a request and join the client to the channel. So while it makes sense to provide a utility for this, it doesn't need to be in the core, so it isn't.
Note that this decision has a design impact far beyond a couple of convenience methods. If the SGS API directly allowed clients to join or leave channels, we would also need to provide hooks for policy decisions (are all clients allowed to join any channel? None? Some?) and so on. Each bit of extra functionality can exponentially increase the complexity of the other pieces; we chose simplicity.
The main reason to keep it simple is so that we can make a lean, fast, scalable core.2. Why don't server-side channels inherit from the client-side channels (or from a common supertype)?
The server and client APIs are separate; we were careful to design them not to share anything.
The client API we provide is a reference implementation (and hopefully a very good one). But we allow any client that speaks the appropriate wire protocol to interoperate with the SGS server, so we don't want to require Java client API implementations to extend a certain class for their session or channel representation, nor do we want the server to depend on a particular client API implementation detail.
<troll joke>Was it because you had a client team and a server team?</troll joke>
Heh, not so much. In fact, the same set of individuals (myself included) designed the server-side IO and client-side IO interfaces, so these were all conscious decisions
Feel free to follow up with additional questions, and I'll try to explain in more detail.
For your application, where you want to share objects between the client and server even though they don't inherit from the same base class, you need to provide a common interface and write an adaptor class for the server side and client side to that interface. This is the approach taken in the MPK20 demo, and when that is open-sourced you can see exactly how that works; it sounds like you're using a similar technique.
Thanks for the question!