I spoke with Tim at the time and the message store they've got in JBM is pretty basic and doesn't have much in the way of search capabilities. Although what we've got is a store, it needs to be more than that from our perspective. Ultimately we need to tie this into SLAs, audit trails, complex search criteria etc. It's not just for the reliable delivery of messages, which is what the JBM implementation is there for.

(i) Someone deploying the ESB and wanting reliable messaging may need a store in order to guarantee delivery in the presence of failures. That store should be optimised for the transport and probably comes with the transport. In this case, the store with always store the entire message, either permanently or for the duration of the delivery.

(ii) Someone deploying the ESB and wants to maintain audit trails for all (or a select) messages. Messages stored here may need to be searched in a variety of ways. Also, the entire message may not need to be stored. It may be possible to just store the header information. Or it may actually be illegal to store the entire message (some contracts exist where only the sender and receiver can ever have the entire message and intermediaries aren't allowed to do so).

If we were only looking at (i), then JBM would be fine. However, we're really looking at (ii). Whether we should use the current Message Store to achieve (i) is a different discussion. My 2 cents is that we shouldn't: these are really two different entities, even if they have the same name.

On 5 Jun 2007, at 15:15, Bill Burke wrote:

What exactly does this ESB Message Store do? This is what I wrote to kurt in a private email:

"BTW, I still think you guys are reimplementing (in a half-ass way) what JBoss Message and JBoss MQ have in a Message Store. If you want an FTP message to be persisted, then:

1) Make the FTP inbound transactional so that it doesn't change the status of the FTP file until tx commit
2) Post a persistent message to a JMS Queue.
3) Do 1 and 2 within a transaction.

I don't see anything wrong with using JMS under the covers. It shouldn't be "heavyweight" intra-JVM."

Its fine if the ESB team's goal is to write JMS++, but it should be done on top of a messaging solution like JBoss Messaging. I don't see the added value to our users for the ESB team to writing similar functionality to JBoss Messaging.

--
Bill Burke
JBoss, a division of Red Hat Inc.
_______________________________________________
esb-dev mailing list
esb-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/esb-dev

----

Mark Little

mlittle@redhat.com

JBoss, a Division of Red Hat

Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire,

SI4 1TE, United Kingdom.

Registered in UK and Wales under Company Registration No. 3798903

Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)