Let's make sure we know what we're asking here. Do you mean real-time or real-world? I wouldn't expect there to be ANY real-time scenarios since J2EE is not built for real-time programming (at least not hard real-time. Soft real-time on the other hand...) Kyle
Let me give you an example: you are designing an application used in airports, with the possibility for the users to book tickets on-line. When a user clicks the submit button for the ticket request to be processed, the system may be havy loaded so the user shouldn't be kept waiting for an answer. Here you can use MDBs because these are used in asynchronous situations. After the request is processed the response (success or failure of booking a new ticket) can be sent to the user by email. This is one situation I can think of right now. I'm sure you can find more now that you have an idea.
My project will expose an API to the rest of the company to allow them to record historical information about what they do. Because the potential clients are built on many different platforms - Microsoft, proprietary IVR/VRU, mainframe, outsourced, etc, we cannot expect all of them to be J2EE clients and use the remote object interfaces of EJB. But, almost every system in the company is using MQ-Series to get to legacy data, so we will ask them to use MQ-Series to send us data. MDB to the rescue! There was also a neat discussion recently about distributed caches using JMS/MDB synchronization messages. When data is changed in one cache, it sends a message to all the other caches.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi