Mock question on messaging and design pattern

[Kisito MOMO]

Which JMS messaging model should be use to implement durable messaging? (choose one)

i)jms.Asynchronous
ii)jms.Queue
iii)jms.Synchronous
iv)jms.Topic
v)jms.Durable

The answer in mock exam is iv).
But I think that choice ii) is correct, because jms.Topic make durable messaging only if consumer is created by createDurableSubscriber session method.

Which of the following statements correctly describe the publish/subscribe messaging model and the point to point messaging model respectively?

i)publish/subscribe messaging=one sender and one receiver
ii)publish/subscribe messaging=one sender and n receivers
iii)publish/subscribe messaging=m sender and n receivers
iv)point to point messaging is a message queue system
v)point to point messaging=n senders and one receiver
vi)point to point messaging=one sender and one receiver

Mock answer: choice ii) and vi)
my answer: v) (because more than one sender may send message to the same receiver at a time), iii) and iv) ( but i�m not sure what is message queue system exactly?)

Which of the following j2ee describes mediator design pattern?
i)Session bean receiving request from remote clients and invoking several entities beans
ii)Servlet receiving request from Web browser and sending to multiple jsp pages
iii)MDB receiving asynchronous messages and invoking multiple enterprise bean
iv)Filter servlet , checking and setting client request and response encoding

Answer in mock exam: ii). For me it�s obvious that iii) is the correct answer.

[David Follow]

Hi Kisito,

your first question:
I believe Queues don't provide durable messages, therefore Topic is correct.
Messages stay in a Queue until they get picked up by a receiver.

your second question:
ii) and vi) look like the official answers and what the documentation says.
However, I agree with you that for Queues there can be n senders and 1 receiver.
Maybe the mock was refering to the official answer and not what other things are also possible.

your third question:
Let's see. With Mediator senders and receivers know of the mediator.
With Facade only the facade knows the entity beans and not vice versa, so i) and iii) are incorrect, concidering the MDB as some sort of Facade to the entity beans.
iv) sound more like a Decorator
which leaves ii) open. however I must admit that's a toughy...

Any ideas on that one...anyone...

D.

[Byron Estes]

It's really a poorly worded question. Several of those could be interprette to be correct. The mediator and the facade are related patterns. The first is behavioral and the second is structural.
The mediator involves workflow or interaction which it incapsulates so that the caller does not need to know how the various objects in the work scenario need to interact. These keeps the coupling low and makes sure they don't reference the participating objects directly. The mediator handles the details. In the case of a facade. It's simply a structural aggregation. Many objects may support it but it's the act of gathering them together in one place that makes a facade. In fact you can have a facade over the top of one or more mediators.

Let's look at each answer...

i) Session bean receiving request from remote clients and invoking several entities beans

I like this one. The idea that you are getting a single request and that it is handling the interaction with multiple other objects implies a form of mediation.

ii) Servlet receiving request from Web browser and sending to multiple jsp pages

This is a serial kind of interation so it's more like a chain. Definitely not a mediator scenario even though it may seem to be at first glance.

iii) MDB receiving asynchronous messages and invoking multiple enterprise bean

This is actually very similar to i) the only difference is the MDB vs a session bean. Asynchronous versus synchronous. Although I tend to view what the MDB does for us as more structural and therefore more indicative of a facade.

iv) Filter servlet , checking and setting client request and response encoding.

This is more a chain of responsiblity thing.

I think the best answer is i).

[ May 04, 2005: Message edited by: Byron Estes ]
[ May 04, 2005: Message edited by: Byron Estes ]

[David Follow]

Hi,

I thought one of the features of the Mediator patterns ist that it knows each colleague. In answer i) the colleques would be the remote clients and the entity beans.
With the answers from abouve, the mediator (session bean) only knows one colleague (entitiy beans) unless you interpret the synchronous response of the session bean as "knowing" the remote client as a colleaque.

D.

[Byron Estes]

There are some pretty bad examples used out there that are misleading.

The one you've probably seen is the chatroom example. It's not incorrect, but it does make you think that a colleague must be an external entity like the calling client. In reality the mediator is simply the idea of keeping the number of objects/participants, and the amount of knowledge that each needs to know about the other to a minimum. The idea is to centralize it into one object/participant that can work with the calling client and all the worker objects. Put one object/participant "in charge".

Real world (non-IT) example:

Think about building a house. You could act as your own subcontractor, in which case you must interface with the framing guys, the roofing guys, the brick guys, the city for permits, the plumber etc. You also need to know dependencies; you don't want the roofer brought in before the framing is done. If you have a subcontractor (read mediator), then you simply say build me a house and he/she handles all the details of who to call and when. The plumber doesn't talk to the framer, just the subcontractor. That is the power of the mediator.

Hope this helps.