Hi Emran,
I'm answering your points in order:
1) (disclaimer: I'm a Spring guy) : we could also have MDB work outside a
JEE container (which is useful for batches, or when you don't need a
container - I'm currently working on a very specific Netty-based http server
for a client, and we don't even have the Servlet API).
2) Batching JMS messages is a huge issue, I'm all for it. I'd never had the
need for timed messages, but now that you speak of it, it looks like a very
good idea too (instead of using TimerTasks like I'm used to do). Concerning
API enhancements, the transactions/acknowledgement part should also be
clarified in the current spec.
3) In ActiveMQ you can specify a lot of things in your connection string:
the IPs of the servers, the timeout, etc... This could be interesting to
standardize this.
Cheers,
Julien.
On Mon, Jun 6, 2011 at 11:28 AM, emran <emrans_at_pramati.com> wrote:
> Hello All,
>
> 1) Support for seamless portability of MDBs across Message Servers
> Today, we don't have a standard set of activation-config properties that
> can be provided for a message-driven bean. Every Resource Adapter provides
> its own set of activation-config properties thus making it difficult for
> MDBs to switch from one Message server to another. Standardizing the
> activation-config properties thus helps in seamless portability of MDBs.
>
> 2) API enhancements
> Multiple features like bulk send, batched acknowledgements, security, timed
> messages (ability to deliver the message at a configured time),
> compression/decompression are supported in almost all the message servers in
> proprietary ways. We can probably think of the feasibility of adding these
> features to the API itself. Something like :
> - Bulk send / Batched acknowledge support, with failure callbacks to
> handle failures.
> - Introducing a new message header to deal with delivery time
> configuration.
> etc ..
>
> 3) A high-level abstraction on clustering & failover
> We can think of providing some high-level abstraction about what the
> clients can expect from a clustered Message server. Issues like:
> - What a provider must guarantee the client when a failover happens (Say
> Node A goes down and Node B becomes the primary) etc..
>
> I am jotting down rough ideas here. I will expand them in further emails.
>
> Regards,
> Emran.
>
>
--
Julien Dubois
Twitter: @juliendubois <http://twitter.com/#!/juliendubois>
Phone: +33 (0)6 25 02 34 18