Container somhow resolves the issue with loosing events/messages in case your application goes down. If you use durable subscription model, any message that has been sent during the down time of you application will be persisted until they are processed by the subscribers. So when you app comes up, you won't loose any messages. Having said that this brings a bit of overhead due to its persistancy. For more information  I recommend you to have a look at EJB spec.

Regarding the point Reza is making, it's good but not for J2EE as this is framework internal responsibility. Although I want to argue with the idea  somehow, because there are drawbacks to it. specially the concept of predefined sleep interval. I understand that you keep the interval in a property file  so it can be modified later according to the condition, but, if the network throughput is too high or too low, you can never know what interval to specify, so I rather keep the applicaton smart enough to adapt to the network load and to be flexible.

For instance  if object A is sending message to B (B is consumer)

I go with a psuedo code as follow:

A->queueTheMessage();
A->signalB();

B::queueConsumerThread()
{
 while(true) {
   waitForSignalFromA();
   while(there are messages in the queue){
       read_Off_The_Queue();
       process_Message();
   }
} // considering the proper lock and unlock stuff (out of scope)

Important note: The above sample does NOT apply to J2EE as container takes care of everything completely transparent of MDB so you shouldn't be worry about such implementation.

To answer the question as how to do the subscription, You can find loads of examples  in JMS tutorial and java.sun.com