Mini-MVC's for Multiple Chatrooms

COMP 310 Java Resources Eclipse Resources

Since individual chatrooms are completely decoupled from each other, their architecture should reflect this decoupling.

Each room can be considered a semi-isolated application on its own, with its own "mini-MVC" to handle its own model and view processing.

Note how each "mini-model", representing the management of a single "room", is broken down into inbound and outbound parts:

Inbound message handling contains:
- Its own message receiver (referred to as the "msg recv" rin the diagram),
- Its own message-processing visitor (the "algo") and
Outbound message handling contains:
- An implementation of the set of stubs of remote message receivers (pluse the stub to the local message receiver) (the "set of stubs") being managed by the mini-model for that room.

The ChatApp program consists of layers of of MVC (one MVC that holds multiple MVC's).

Neither the mini-MVC nor the mini-model is equivalent to the actual entity that is modeling the chatroom! The mini-MVC is infrastructure that manages the chatrooms operations and displays the chatroom to the user.

Problems in both design and implementation are often directly traceable to vague articulations of exactly what a "room" is! The expression of the separation of inbound and outbound processes is crucial for understanding what a "room" is actually doing.

In the diagram below, the following terms have these meanings:

"Msg Recvr" = the message receiver for the room, an RMI server object. There is only one message receiver per "room"!

"Algo" = the visitor algorithm used to process the received messages. Each "room" has its own visitor instance.

"Set of Stubs" = the set of remote message receiver stubs (proxies) used for sending messages to the remote message receiver instances (RMI server instance) representing a presence in the room by other remote applications. The stub for the local message receiver is usually included in this set as well so that the local system can receive its own messages.

(Note that this diagram does not include the "mini-controllers" that would be responsible for instantiating the mini-MVCs)

Multiple Chat Room Support

(For more explicit detail, please see the Java Resources web page on How To Make Mini-MVC's Inside a Main MVC)

"Mini-model" != "chatroom"!

Do NOT equate the chatroom with the mini-model -- they are NOT the same thing! The mini-models above contain and manage their respective chatrooms, message receivers and message processing algorithms (visitor).

NO Routing Required!

It may seem at first glance that in order to support multiple simulataneous chatrooms, the ChatApp system must be able to route messages to their correct chatroom destinations. While there are API implementations that do force the applications to perform message routing, message routing is NOT fundamentally required to support multiple chatrooms! If you want a message to go to a particular chatroom (what exactly does this mean?) then simply send the message directly to its intended target rather than relying on the receiving application to properly figure out the desired recipient. See the page on Message Routing.

Developing multiple chat room support:

Start simple and send and process only one chat room at a time.
Supporting multiple chat rooms has tremendous implications for the design of how your system handles joining a chat room and the subsequent creation of the various support entities (input/output, IUser stub, etc).
- Encapsulate, encapsulate, encapsulate!!
- Remember that controllers build MVCs. The "mini-controller" that builds the mini-MVC is not shown in the above diagram.
  - Who manages the mini-controllers?